Voice on WLAN trials 3: Roaming is an issue

Third of a series; see part 1 and part 2.

By David Newman, Network World, 2/09/05

This week, we have published the results of a multi-vendor test of voice on WLAN. On Monday we gave the basic results, and on Tuesday, we went into detail about QoS issues. Today we look at mobility and roaming.

Mobility for voice is a major driver for a WLAN deployment. Just as cellular phone users move from one coverage area to another, so too will WLAN handset users. Elsewhere on Techworld, read why roming is a hurdle for WLAN deployment and read our introduction to WLAN roaming, and roaming between subnets.

We measured the time needed for a call to migrate from one access point to another, with both access points attached to the same switch. We also tracked R-value (see our first article), delay and jitter.

How do you test roaming in a small lab?
To force the handsets to roam, we powered off the first access point. This drew objections from two vendors - Chantry and Colubris. Chantry says its roaming capabilities are designed for the case where a user physically moves from one location to another, not when there's a power loss to a given access point.

While it is desirable to test roaming under this condition, we could not put enough space between access points in our 1,200-square-foot lab for this approach to be practical. We considered using the VeriWave TestPoint as a noise generator, but rejected that option because it was no more representative of physical mobility than the power-off test. Also, loss of power is a real (if uncommon) occurrence. If the access point goes away for whatever reason, a WLAN system needs to seamlessly migrate associated users to a nearby alternative.

The Colubris CN1250 could not be tested by turning it off. The vendor handles mobility through Mobile IP, which requires a home agent - the station where a client first learns its IP credentials - to remain active. If the access point that hosts the home agent goes down, so does the ability to roam. Cisco also supports Mobile IP, but did not use that technology in our tests.

Instead of pulling the plug on the CN1250, we tested roaming by disabling the radio on the first access point. This had the same effect of forcing the clients to roam.

Colubris also requires a third access point to function as a foreign agent, which relays information about clients that roamed back to the home agent. For this purpose, we used a third Colubris CN1250 with its antennas removed; there is no requirement that the foreign agent needs wireless connectivity.

Results - Aruba does best
As before, we measured roaming in configurations involving one, six and seven calls, with and without our background data. Cisco has bragging rights in the single-call case, with a roaming time of 0.433 seconds, and all systems roamed one call in about 0.5 seconds (see graphic). A half-second gap is noticeable to the human ear - as is any gap of around 70 ms or more - but except for this dropout audio quality was generally high.

Aruba excelled in the roaming tests. Its average handoff times ranged from about a half-second for one call, to just more than 1 second for the seven-calls-with-data scenario. While that kind of delay will be noticeable to callers, it was still by far the fastest roaming performance of any product.

In Cisco's case, we could perform seven-call roaming tests, but not six-call tests because of time constraints. Average roaming times doubled from 0.433 seconds with one call, up to 1.053 seconds with seven calls - and then it leapt to 4.324 seconds with seven calls and background data.

Colubris could roam with six calls, but not seven. In the seven-call case, we could not prevent some phones from "pre-roaming" to the second access point before our test, which invalidated the results. We also had similar issues in testing with six calls, but the handsets stayed associated long enough for us to record the results, with and without background data. Even so, the results are counterintuitive - roaming took an average of more than 5 seconds without data, vs. about 2 seconds with data.

Chantry's BeaconMaster couldn't perform the roaming test with six or seven calls, even without background data present. Calls would drop rather than roam in those configurations. In troubleshooting the problem, we reduced the number of calls to see if it was a load problem. It was: In our power-off scenario, the highest number of calls that could roam through the BeaconMaster was only two. Two-call roaming times were similar to the one-call case, but we're not presenting those numbers because of the much-lower call count than the other vendors.

VeriWave's new test gear helped us contrast roaming at the 802.11 link layer and at the application layer, and the results were startling. In many cases, delays of even a few dozen milliseconds in link-layer 802.11 roaming led to delays of 10 seconds or longer at the application layer. Even vendors' engineers were surprised at the enormous disconnect between Layer 2 and Layer 7 measurements. The fact that even minor issues at the link layer had a major effect at the application layer underscores the need for well-behaved 802.11 implementations.

Remote roaming
Because WLAN switches can manage access points at remote locations, we wanted to know whether roaming times and call quality would be affected if the access points are in different locations than the switch. For example, would roaming times differ if the WLAN switch was in Boston and a user roamed between two access points in Los Angeles?

We re-ran the roaming tests, this time using an AX/4000 traffic generator/analyzer from Spirent Communications to inject a 100ms, round-trip delay. This is roughly the delay that traffic would experience going between Boston and Los Angeles.

We completed this test with only Aruba and Cisco. Chantry's BeaconMaster couldn't sustain six or seven concurrent calls. Colubris consists of an access point but no switch, ruling out remote roaming tests. For remote roaming, we tested with seven calls (time constraints prevented us from testing Cisco's gear with six calls).

Without data, local and remote roaming times were essentially identical for both vendors (see graphic). With data present, Aruba's roaming times rose from about 1 second in the local case, to about 3.5 seconds in the remote scenario. Cisco's remote roaming time was actually lower than the local test, which is counterintuitive. We cannot explain this result, but at least it validates Cisco's claim that access points can "pre-authenticate" clients, resulting in no performance penalty for remote access points.

Tomorrow: How architecture affected our results.

Recent Related Stories:

MIMO products muddle wireless market (Network World)

Back to MobileVillage News Page

This story and associated images are copyright, 1995-2003 Network World, Inc.