ASWi-Fi increasingly permeates our lives, it is forever changing the way that we work and communicate. Corporate IT managers can no longer ignore the influx of mobile PCs, PDAs, phones, and other devices. After all, such devices improve the productivity of people on the go. Voice over Wi-Fi (VoWi-Fi), in particular, is emerging as a powerful driver for Wi-Fi deployment. By leveraging the wireless-LAN infrastructure for phone and data traffic, it offers considerable cost savings. Of course, it's understandable for IT managers to be preoccupied with important decisions like whether to deploy 802.11a or 802.11g. Yet they also need to consider the special needs of Wi-Fi phones. The correct implementation of roaming is key to the proper operation of these phones.
When a Wi-Fi device moves from the vicinity of one access point (AP) to another, it disassociates from the original AP. It then associates with another AP that offers a better connection. Typically, roaming is triggered by low signal strength, a rise in packet error rate, or AP loading considerations. In some system implementations, central management can detect the overloading of APs. To balance the load, it directs the station to roam.
On the surface, roaming seems to be a simple operation. In reality, however, it is a complex process that involves sophisticated decision-making protocols. If the roaming protocols are implemented inadequately, VoWi-Fi is severely hampered.
At Azimuth Systems, we performed initial testing of commonly available roaming implementations. Our tests revealed a disturbing trend: Roaming times ranged from 120 ms to 28 s. Most clients' roaming performance was in the seconds range and therefore woefully inadequate for voice.
Typically, roaming decisions are made by the client (e.g., the PC, PDA, mobile terminal, or 802.11 telephone). Per FIGURE 2, the basic process is as follows:
1. Unacceptable throughput or loss of connection triggers the client to initiate roaming.
2. To find other APs, the client scans all available 802.11 channels.
3. If a target access point is available, the client selects it.
4. The client moves to the target channel.
5. The client issues a probe request and waits for a probe response or beacon.
6. The client authenticates and associates with the target AP.
7. Note that if the roam disrupted the IP session, the client may have to re-initiate it.
The qualification of roaming time and behavior is the most difficult of the Wi-Fi tests. In addition to being subject to interference, this test requires the device to be in motion. In a traditional EMI chamber, interference can be controlled. But motion is impossible in such a chamber.
Before now, the state of the art in wireless test involved finding an empty building free of interference. To make measurements, people either rolled the devices on carts or walked with them. New testing is more automated. The devices under test are subjected to controlled emulated motion and traffic load.
The test setup in FIGURE 3 , for example, contains two test modules: a wireless-LAN analyzer (WLA) and an RF port module (RFM). A phone or a PC client is connected between the two access points via 90-dB programmable attenuators. These attenuators are built into the RFM. They are programmed to force the client to roam in a controlled way from one AP to another. The integrated dual-channel WLA module performs data collection simultaneously on the source and destination channel.
In this example, the roaming test is fully automated. It can be configured to repeat the measurements for a set period of time. Roaming time and the roaming algorithm's behavior are then analyzed based on traces that were collected during the test.
The roaming-test script automatically controls the attenuators, data capture, and analysis. The script can then measure the different phases of the roaming process. Initially, one attenuator is set to minimum and the other one is set to maximum. The client then receives a strong signal from AP1 and associates with it.
Initially, AP2 is out of the client's range. Next, the attenuator between AP1 and the client is gradually increased. This increase eventually makes AP1 invisible to the client. At the same time, the attenuator between the client and AP2 is gradually decreased. Here, AP2 is "moved" within range to force roaming. The attenuators' ranges and rate of change are configurable within the test script.
As the emulated motion progresses, the data rate of the client transition down (tTRANSITION) can be observed while the connection between the client and AP1 deteriorates. The client responds by starting to scan for another access point (tSCAN). The time that it takes to associate with AP2 (tASSOCIATE) is then measured. Measurements also are taken for the time that it takes to resume data transitions (tDATA). The roaming time (tROAM) is defined as the time between the last data transmission prior to roam and the first data transmission following the roam (see "The Roaming Process," p. 32).
At the end of the roaming test, the script tabulates the details of each roam (FIG. 5). Currently, most commonly available 802.11 clients exhibit unacceptably long roaming cycles The typical roaming times that are measured in seconds are a far cry from the desired 50-ms outage tolerance for voice. They also venture deep into the territory of TCP-session timeouts.
The roaming algorithms' unacceptable performance and inconsistency have prompted the Wi-Fi industry to focus on roaming. The draft 802.11k specification, for example, contains a radio-resource measurement. This measurement can be used to obtain information on available APs before the roaming decision takes place. In addition, the IEEE recently formed a Fast Roaming task group, 802.11r. To satisfy the stringent voice requirements, this group will work to define the roaming algorithms.
The new 802.11r roaming methodology also will have to support the 802.11i security protocols. These protocols may involve lengthy authentications with the RADIUS server. Those authentications, in turn, have the potential to severely impact the roaming speed. Thankfully, the 802.11r task group is studying new protocols, such as pre-authentication. Such protocols promise to achieve the desired roaming time even when lengthy 802.11i authentication is required.
Picture the near future: A person is strolling from McDonalds to Starbucks while talking on his or her multi-mode phone. Both the wireless infrastructure and the phone will need to perform seamless roaming between disparate services, such as Wi-Fi and cellular. Wi-Fi-to-cellular roaming will have to happen in less than 50 ms. At the same time, it must maintain IP session continuity as the mobile device roams from the realm of one Wireless Internet Service Provider (WISP) to another. Currently, the IEEE 802.21 Media Independent Handover Interoperability Committee is working to enable such multi-service roaming.
As the roaming standards evolve and VoWi-Fi solutions are deployed, manufacturers and service providers will need a systematic way of qualifying the performance and behavior of Wi-Fi devices and systems (see "VoWi-Fi Requirements," p. 34). As they embark on the laborious and error-prone process of measuring roaming time and access-point voice-stream capacity, they will need specialized, automated test tools. By producing accurate and repeatable test results, those tools will help developers optimize the performance of their products. They also will aid reviewers and service providers as they work to evaluate available Wi-Fi solutions.
VoWI-FI REQUIREMENTS To achieve acceptable voice quality, VoWi-Fi solutions must meet stringent requirements for roaming time, packet loss, delay, jitter, and voice-stream capacity. To qualify these parameters, however, one needs an approach that overcomes the challenges of open-air measurements. Traditional test techniques do exist for performing measurements while Wi-Fi phones are both in motion and in open air. Yet these tests can be physically difficult, time consuming, and error prone—especially when they're combined with the VoWi-Fi requirements:Quality of Service (QoS): To ensure that packet loss, delay, and jitter are within the tolerable limits for acceptable voice quality, isochronous voice traffic must have priority over asynchronous data traffic. The prioritization of voice traffic can be achieved using the new QoS protocols: 802.11e, Wireless Multimedia Extensions (WMEs), and Wi-Fi Scheduled Multimedia (WSM). (Note that the WME and WSM specifications are pre-standard subsets of 802.11e. They may not be compatible with the future ratified version of the 802.11e standard.) Some pre-standard VoWi-Fi solutions use the Spectralink Voice Priority (SVP) protocol.
To guarantee priority access for voice traffic, the SVP protocol requires APs to use zero backoff before transmitting voice packets. It also demands that APs move the voice packets to the head of the queue or—if multiple queues are used—to a high-priority queue. This approach minimizes the delay on the voice packets in the isochronous packet streams.
The WME protocol defines four traffic priorities. Each priority uses a different backoff. Voice is assigned the shortest backoff and hence the highest priority. The APs that implement WME are expected to have four queues (one for each priority).
In contrast, the WSM protocol is based on polling. It provides a means of defining and maintaining packet loss, latency, jitter, and other criteria for packet streams. WSM holds the promise of optimizing the bandwidth efficiency for streaming media, such as VoWi-Fi.
tTRANSITION = time between the last acknowledged data packet and the first probe request. This time may be 0 if the client sends the probe request before it loses connectivity to the source AP.
tSCAN = time from sending the last data packet to the first probe response from the target AP
tASSOCIATE = time to associate and authenticate to the target access point
tDATA = time from successful association to the first acknowledged data packet
tROAM (or tSCAN + tASSOCIATE + tDATA) = time between the last acknowledged data packet before roaming and the first acknowledged data packet to the target AP after roaming