Throwing lots of traffic types into the WiMiX shows 11n gear adept at handling voice and video quality

While our single frame size throughput and latency tests are useful in describing system limits, they are not representative of what's actually seen on enterprise networks in everyday use.

To model more real-world conditions, we used VeriWave's WiMix program -- so named because it involves wireless clients handling different packet sizes -- to generate enterprise application traffic. In this case, we offered a combination of VoIP, Windows Media video, Web and Windows file transfer (SMB, or server message block) traffic. WiMix not only forces access points to interleave long and short frames, but also to use QoS mechanisms to ensure timely delivery of voice and video.

We defined separate service-level agreements for each of the four traffic classes and gradually increased the overall load until one or more traffic classes violated its SLA. The highest load we could offer at which access points delivered all four traffic classes within their SLAs constituted the final result in this test.

The SLA parameters put the highest emphasis on protecting voice and video traffic. Voice had to meet a minimum R-value, a method of scoring audio quality. Video had to maintain strict boundaries on delay, jitter and loss. Web and SMB traffic could use whatever bandwidth was left over, but never less than 5% each of the total. (We used 5% minimums as a way of ensuring voice or video wouldn't "starve" the other classes.)

Well after testing concluded, we discovered an issue that caused us to offer only about a quarter as much video traffic as we intended. The other traffic classes – voice, Web and Windows file traffic – weren't affected. While the results we're presenting are valid, even for video, the traffic we offered didn’t push the systems as hard as we intended. It's possible that any or all of the systems might have delivered different results had we actually sent more video.

The good news is that all systems did an excellent job of protecting voice quality, and most handled huge numbers of concurrent calls. R-value, a VoIP scoring method, was uniformly high. All systems scored R-values of nearly 86 out of a possible 93 (though scores higher than 86 or 87 are rarely seen in live networks), with Motorola's access points slightly edging out the others.

Click to see: Chart of Wimix media scores.

The Bluesocket system carried the highest number of calls per access point. However, second-place Aerohive (tied with Siemens) said its access points could have handled more calls than we attempted. That may be true; we stopped testing at an overall load of 137Mbps per radio because, due to the "underfeeding" issue mentioned above, both Aerohive's engineers and we believed we were at the system's limit.

Motorola's access points handled many fewer calls than the other systems because it could handle only a much lower overall load. The company said its AP-7131 doubled in WiMix performance running new firmware issued after the test, but we did not verify this.

In terms of data rates, the Bluesocket system handled the highest WiMix load without violating SLAs for any traffic class. Again, though, we "underfed" video traffic by a factor of about four. It's possible all systems could have handled much higher offered loads had we offered more video.