sniffwifi

Just another WordPress.com site

Archive for the ‘VoFi’ Category

A Voice Of Reason On Voice Over WiFi

leave a comment »

Voice over WiFi is scary.  Retries, packet errors (due to lots of Retries) and high latency (usually due to packet errors that happen because of lots of Retries) will murder a WiFi network’s ability to handle Voice and leave your users screaming (not actually screaming) like they were cast in a horror movie (or, at the very least annoyed like a character from Office Space).  But there’s one thing that sometimes scares people, but really shouldn’t: Voice Arbitration.  It’s not going to kill your WiFi voice calls.  In fact, it will almost certainly help.

Arbitration is a process defined in the 802.11 standard.  Every device (client/station and AP) goes through it.

The simplest way I can describe 802.11 Arbitration is like so:

If your AP or station has heard a quiet channel for 37 microseconds (0.000037 seconds), then your AP or station transmits a frame (what most people call a packet, but I call a frame).

If your AP or station has been hearing a busy channel for the past 37 microseconds, then it enters Arbitration. Arbitration is the process by which APs and stations go through a series of procedures in order to avoid devices sending at the same time (and, thus, causing a collision).

The big worry some people have is that Voice will mess up Arbitration.  That it will make it MORE likely that collisions will happen.  The Voice QoS category (as originally defined in the 802.11e amendment) reduces the amount of randomness in Arbitration.  For ordinary (called Best Effort in 802.11e), APs and stations choose a random value between 0 and 15 (on their first try; retries choose from exponentially larger random pools of values).  Voice applications (at least, applications that get tagged as voice by the AP or station) choose values between 0 and 3.  The problem comes when two devices (APs or stations or one of each) choose the same random value during Arbitration.  If that happens, then both devices try to transmit at the same time and most likely a collision occurs.  Two devices choosing the same number between 0 and 15 could happen, but maybe not all that often.  Two devices choosing the same number between 0 and 3 would be far more likely.

The flaw in this thinking is that devices have to be in Arbitration at the EXACT same moment for the 802.11e Voice category to become a problem.  Most likely, they won’t be.

Even though voice applications seem like they’re always running, they’re really not.  Each voice packet only uses about 300 microseconds* (assuming a 39 Mbps data rate — because smartphones don’t support MIMO — and the use of RTS/CTS) or 150 microseconds (if RTS/CTS is not used) of channel time.  And a modern voice application is going to have at most about 90 packets go over the wireless channel per second (combined send and receive).  That’s not a whole lot of channel time.  If we take the example of an iPhone on a typical WLAN — where RTS/CTS is used when the iPhone sends, but not used when the AP sends — that’s only 20,250 total microseconds being used.  20,250 microseconds is 20.25 ms.  Or 0.02025 seconds.  In other words, each phone is only using about 2% of the available channel time when a call is active.

If all of these numbers are too much, here is a visualization of how often a typical voice app is actually using the wireless channel:

The red and blue mean that the channel is occupied, while the empty boxes mean that the channel is unused**.

 Look at all of that open space.  And remember that open space is not the only way that collisions are avoided.  Collisions are avoided if:

-A phone becomes ready to send data while the channel is clear.
-A phone becomes ready to send data while another phone or AP is already sending data (assuming the devices can hear each others’ transmissions).

The only way a collision can occur due to an Arbitration match is if two or more devices begin attempting to send data at the exact same time.  For applications that use as little channel time as voice, that’s just not very likely to happen.

I have found the 802.11e Voice category to not cause problems in high density/congested environments.  In fact, I’ve found it to help.  When voice applications use the 802.11e/WMM Best Effort category instead of the Voice category, an extra 63 microseconds*** gets added to the packet transmission process.  That’s about a 20% jump in used channel time for devices that do use RTS/CTS and a whopping 40% jump for devices that don’t. That means more channel time per packet.  Using more channel time per packet is an actual problem, because it leads to the real reason that collisions tend to happen.  Collisions most often occur because one device is in the middle of sending and another device can’t hear it.  More channel time being used by each packet is most likely going to exacerbate the problem of collisions, not minimize it.

***

*All time calculations include 28 microseconds for a Voice AIFS, 18 microseconds for the Random Backoff (that’s two slot times), 10 microseconds per SIFS, 50 microseconds for non-HT physical layer headers (used by RTS, CTS and Block Ack frames) and 40 microseconds for HT physical layer headers (used by Data frames).

**That little graph has 10,000 boxes, meaning that each box could represent 100 microseconds.  The red dots are a visualization of how much channel time is being used when the iPhone sends (300 microsecs, including RTS/CTS) and the blue dots are a visualizations of the AP sending (since 150 microsecs would mean 1.5 boxes, I just represented half of the AP’s packets with two boxes and half with one box). 

***63 microseconds is calculated by adding an extra 9 microseconds to the AIFS (the Best Effort AIFS is 37 microseconds) and by adding six extra 9 microsecond slot times for the Random Backoff.

***
If you like my blog, you can support it by shopping through my Amazon link or donating Bitcoin to 1N8m1o9phSkFXpa9VUrMVHx4LJWfratseU

ben at sniffwifi dot com

Twitter: @Ben_SniffWiFi

Advertisements

Written by sniffwifi

February 24, 2015 at 10:31 pm

Now It’s AirMagnet’s Turn to Show Us QoS

with one comment

In my last (real) post, I detailed how I used WildPackets OmniPeek to solve an iPhone 5 QoS problem.  But what about AirMagnet WiFi Analyzer?  I am a fan of both of those fine WiFi sniffers, so I figure it’s a good idea to show you how QoS can be analyzed with Fluke Networks’ signature WiFi protocol analyzer.

WildPackets OmniPeek is more of a hardcore protocol analyzer than AirMagnet WiFi Analyzer is.  If you’re going to be doing the type of sniffing I detailed in the last blog post, you will have an easier go of it with WildPackets’ product.  But AirMagnet is popular and both tools are expensive.  So if you happen to be a gal (or guy) who needs to troubleshoot WiFi voice or video and you have AirMagnet, this brief tutorial should help.

To begin analyzing QoS, one must first capture on the VoFi devices channel.  In my case I associated my iPhone 5 to a network with the SSID of “R&T”.  Then I looked at the Start screen in AirMagnet:

The “R&T” access point was on channel 44.

Once you know the channel that your VoFi device is on, then next step is to start capturing and viewing frames in the Decodes screen of AirMagnet.  It is at this point that I should note that the wise Keith Parsons once told me, “If you’re looking at the decodes in AirMagnet, then you’re in the wrong place.”  And that is true, usually.  But in the specific case of needing to find out which WMM QoS categories are being used by your VoIP app, then the Decodes screen is the right place to be.

I navigated to the Decodes screen in order to view captured frames.  I selected channel 44 as my capture channel and then I applied a capture filter for my iPhone, as shown here:

Once I had my filtered capture running, my step was to generate some voice traffic so that I could test QoS.  I used Truphone, which is a WiFi-based calling app.

After capturing VoFi frames, WMM QoS categories can be seen by opening a data frame and viewing the 802.11 header.  The 802.11 header has a field called “QoS Control”, and inside that field the TID (traffic identifier) will indicate which WMM access category is being used.  For Truphone, the category was Best Effort:

AirMagnet makes it a little bit more difficult to see the WWM QoS Category than other WiFi sniffers do.  For one thing in AirMagnet a capture must be stopped before frame decodes may be viewed.  For another the TID subfield is not summarized.  When the TID value is zero that means Best Effort, which is simple to remember.  The other categories are a bit more odd.  Voice is 5 or 6.  Video is 3 or 4.  Background is 1 or 2.  Seeing the raw bits of the TID field like in the AirMagnet capture above is fine for people who have memorized those numbers.  WildPackets OmniPeek and Wireshark decipher the number and tell you the category, which makes things easier for people who spend less time focusing on WiFi.  Like in this example below, it would’ve been nice if AirMagnet made it clearer that the frame I was looking at it Voice instead of forcing me to remember that 0110 in binary is 6:

In summation, the process for figuring out whether WiFi-based QoS will help your applications is rather straightforward.  Capture on the channel.  Run the app.  View the headers.  And if you do that it can really help you predict whether your VoFi apps will work well on a crowded channel.

Written by sniffwifi

November 21, 2013 at 12:39 am

Sometimes, Two Plus Two Ain’t Four

leave a comment »

My love for WildPackets OmniPeek may be one of the few things in technology that exceeds my love for the iPhone…


Now that I’ve run off 20% of my audience, let’s talk about how the former can be used to figure out if the latter is causing a problem.

I have a lot of enemies in life, and I’m proud of that.  In my opinion, part of being an adult is recognizing who your enemies are.  UCLA football players are my enemy when they play college football.  Drivers who text while stopped at green lights are my enemy when I am running late.  (No comments from the peanut gallery on that one, GT Hill.)  And deductive reasoning is often my enemy when troubleshooting.
Deductive reasoning is oh so tantalizing.  It’s simple math; A + B = C.  The WLAN works (C) when VoFi handsets (B) connect to my APs (A).  If I switch out the VoFi handsets for SIP-based iPhones (thus changing the value of B) and the WLAN stops working, then the iPhones must be at fault.  Right?  Wrong.
Deductive reasoning only works if you eliminate all variables but one.  A switch from a VoFi handset to an iPhone is not the changing of one variable.  It is the changing of numerous variables.  The chipset changes.  The client utility changes.  The apps that run in the background change.  The SIP app changes. 
Another problem I have with deductive reasoning is that sometimes a device that we think is working really isn’t working.  That’s what was happening recently when I was doing some work on site at a health care provider.
The Problem

The health care provider had been using dedicated VoFi handsets for years.  Like many organizations, they decided to move away from dedicated voice devices and use a smartphone app instead.  In this case, it was an Avaya smartphone app running primarily on iPhone 5s.  
Once the iPhones started getting used, the WiFi folks at the health care provider immediately starting noticing problems.  Users were saying that the phones kept beeping.  Avaya said that the app will cause the phones to beep if the app gets disconnected.  It is a way to protect phone from being stolen or taken to locations where they’re not supposed to go.
The problem for the WiFi admins is that the phones were still connected when the beeping was happening.  Something was causing the iPhone to think it was disconnected when it really wasn’t.
Faulty Deductive Reasoning

The natural reaction of the WiFi admins was to blame the iPhones and/or Avaya.  The health care provider had a working VoFi solution.  They changed to iPhones and Avaya.  The solution stopped working.  The rest of the WiFi continued to work well, so the problem was thought to be the phones.

I was skeptical that the iPhones and the Avaya app were the problem right from the beginning.  iPhones have been blamed innumerable times over the years for problems that were actually the infrastructure’s fault.  What’s more, I tend to almost always blame the network.  My attitude is that networking (both wired and WiFi) is the business of support.  We don’t make money for the company.  We create infrastructure that allows saleswomen and craftsmen (see what I did there, ladies?) and executives to make money for the company.  If a user wants to use a certain device, we should try to make our infrastructure support that device.  (That is, assuming we want the company we work for to grow and be successful.)
OmniPeek to the Rescue

Armed with my natural skepticism of iPhone blame syndrome, I had the lead WiFi guy do an WildPackets OmniPeek capture with me.  (OmniPeek is the WiFi sniffer that he was already using.)  We set the capture to the channel of the nearest AP.  We associated the iPhone.  He made an received a call.
We then looked at the OmniPeek WiFi statistics (Summary -> 802.11 Analysis, for those of you OmniPeek users).  I noticed that the Retry percentages were astronomical.  Getting as high as 60% at their worst.  That told me that something was wrong.  During normal operation the WiFi channel was seeing Retry percentages well below 10%.
From the Summary screen of OmniPeek, we switched to the Packets screen to get more detail.  I turned on Auto Scroll (a little icon above the packets list that looks like a little padlock) and watched the packets come in while we repeated our iPhone test.  I kept my eye on the Flags column in my Packets window because I knew that Retry frames always caused a red colored “+” to show up in that column.
Sure enough, the next time the iPhone connected a whole slew of frames with a red “+” showed up in the Flags column.  I saw more than 5 consecutive HTTPS frames in a row all with the Retry flag and none of them were followed by acknowledgment (802.11 Ack) frames.

We Found a Problem, but Whose Fault is It?

Once we saw a flood of unacknowledged frames, we had to determine what the cause might be.  Was it the iPhone misbehaving?  A bad Avaya app?  Or the AP being unresponsive.

All of the Retry frames had the iPhone 5’s MAC address as the second address in the 802.11 header.  The second address is always the transmitter’s MAC address.  That meant that the iPhone was sending all of the frames that were failing.

After seeing that the iPhone was the device that was sending the failed data, I immediately began to suspect that the APs were the problem.  It is quite rare that a device will disconnect itself while sending a bunch of data at the same.  Remember, our initial problem was that we were getting a beeping sound that indicated a network disconnection.

Let’s Get Specific

Blaming the WiFi infrastructure for an iPhone problem is always satisfying (at least, if you’re an Apple loyalist like yours truly), but in order to get people to believe you it’s best to pile on the evidence.  My usual method is to try to find something logical.  Why would an AP just stop acknowledging iPhone data?  Why might I be using the same WiFi APs and controllers that have always worked fine with VoFi handsets and never see a problem that is the fault of the infrastructure?

I used OmniPeek to look inside the frame decodes for any unique properties of the unacknowledged frames.  I noticed that some of the problem data had the same WMM/QoS category in the QoS Control field: Background.  I immediately added the Decode column to the OmniPeek Packets screen, then selected the Traffic Identifier (TID) subfield within the QoS Control field of the 802.11 header.  In the Decode column of the OmniPeek Packets screen, whichever field or subfield selected in the frame decode below will be displayed.  So in my case, that meant that the Decode column displayed the TID for every frame.

Once I was able to easily see the TID for each captured data frame, I started quickly scrolling up and down through the capture.  Sure enough, I saw a consistent pattern.  Every time the iPhone sent a frame tagged with the Background TID to the access point, the access point would fail to send an acknowledgment in return.  We didn’t have time to identify which specific app within the phone was sending data tagged as “Background”, but at that point it was peripheral to the issue.  If an AP can’t handle Background traffic, then that AP is a potential problem that could spread beyond just iPhones and Avaya apps.

The Conclusion

The lead WiFi administrator was in the room with me looking at OmniPeek as we were investigating this iPhone disconnection problem (and, unfortunately, this is why I am unable to show screenshots of our OmniPeek captures).  He came into the day looking for an iPhone problem.  After an hour or so of using OmniPeek, he realized that the problem was his APs.  The fact that he was using 802.11a/b/g APs made things all the logical.  The AP vendor had mentioned to the lead WiFi admin that those old APs were no longer receiving firmware updates and that it could lead to problems.  Our little OmniPeek exercise convinced him that it was either time to upgrade or to look for a new vendor (and his current AP vendor shall go nameless in this blog post, because I like to avoid trashing vendors for hardware or software that is no longer kept up to date).

I am aware that I sometimes come across as too sniffer-centric.  I realize that some people find management software easier to access or spectrum analyzers easier to understand or discovery software easier to afford.  But there is a reason that I am such a zealot for WiFi sniffers.  They help me identify causes of the really difficult problems that plague so many high level wireless networks.

Written by sniffwifi

November 11, 2013 at 11:37 pm

Posted in iPhone 5, OmniPeek, VoFi