Deploying Voice over WLANs Milwaukee WI

provided by: 
Originally published at Internet.com

This is excerpt is from Chapter 7: Designing a VoWLAN Solution, pp. 147-150 Deploying Voice over Wireless LANs, by Jim Geier, from Cisco Press.

Roaming

Because of the mobile aspect of wireless voice telephony, ensure that the VoWLAN system architecture you select supports effective roaming . The voice user must be able to move about the facility, and the system needs to allow roaming at both Layer 2 and Layer 3 (see Figure 7-5, below). Without smooth roaming, users will experience dropped calls.

Figure 7-5 Layer 2 and Layer 3 Roaming

With VoWLAN systems, roaming may take place before a user places a call, which is commonly referred to as precall roaming. In this case, the user may traverse the boundaries of Layer 2 virtual local-area networks (VLAN) and layer subnets. If the wireless IP phone stays within the same subnet, the phone's IP address remains the same. If the phone moves into an area associated with a different VLAN, the wireless IP phone should automatically use Dynamic Host Configuration Protocol (DHCP) to obtain an applicable IP address .

Is Wi-Fi Roaming Really Seamless?

An extremely beneficial aspect of Wi-Fi networks is mobility. For example, a person can walk through a facility while carrying on a conversation over a Wi-Fi phone or when downloading a large file from a server. The Wi-Fi radio inside the user device automatically roams from one access point to another as needed to provide seamless connectivity. At least that is what one hopes will happen!

To determine how well roaming works with conventional wireless clients, I performed some testing. The test configuration included two access points, with one access point (AP-1) set to channel 1 and the other access point (AP-2) set to channel 6. Other settings were default values, such as beacon interval of 100 milliseconds, RTS/CTS disabled, and so on. The access points were installed in a typical office facility in a manner that provided a minimum of 25-dB signal-to-noise ratio throughout each access point's radio cell, with about 20 percent overlap between cells. This is somewhat the industry standard for wireless voice applications. The roaming client in this case, though, was a laptop equipped with an internal Centrino Wi-Fi radio (Intel 2915ABG).

While standing with the wireless client within a few feet of AP-1, I used AirMagnet Laptop Analyzer (via another Wi-Fi card inserted into the laptop's PCMCIA slot) to ensure that I was associated with AP-1. I then kicked off a File Transfer Protocol (FTP) transfer of a large file from the server to the laptop and started measuring the 802.11 packet trace using AirMagnet Laptop Analyzer. With the file downloading throughout the entire test, I walked toward AP-2 until I was directly next to it. With the packet trace, I was able to view the exchange of 802.11 frames, calculate the roaming delay, and see whether any significant disruption occurred to the FTP stream.

After the client radio reassociated, it issued several 802.11 disassociation frames to AP-1 to initiate the reassociation process. The radio then broadcast an 802.11 probe request to get responses from access points within range of the wireless client. This process is likely done to ensure that the client radio has uup-to-date information (beacon signal strength) about candidate access points before selecting which one to reassociate with.

AP-2 responded with an 802.11 probe response. Because the only response was from AP-2, the client radio card decided to associate with AP-2. As expected, the association process with AP-2 consisted of the exchange of 802.11 authentication and association frames (based on 802.11 open-system authentication).

The reassociation process took 68 milliseconds, which is the time between the client radio issuing the first disassociation frame to AP-1 and the client receiving the final association frame (response) from AP-2. This time is quite good, and I have found similar values with other vendor access points.

The entire roaming process, however, interrupts wireless applications for a much longer period of time. For example, based on my tests, the FTP process halts an average of 5 seconds before the radio card initiating the reassociation process (that is, issuing the first disassociation frame to AP-1). I measured 802.11 packet traces indicating that the client radio card retransmits data frames many times to AP-1 (due to weak signal levels) before giving up and initiating the reassociation with AP-2. This substantial number of retransmissions disrupted the file download process, which makes the practical roaming delay in my tests an average of 5 seconds! The Centrino radio card I tested is notorious for this problem, but I found this to be the case with most other radio cards as well.

Vendors are likely having the radio cards hold off reassociations to avoid premature and excessive reassociations (access point hopping). Unfortunately, this disrupts some wireless applications. If you plan to deploy mobile wireless applications, be sure to test how the roaming impacts the applications.

Every model of radio card behaves differently when roaming due to proprietary mechanisms, and some cards do better than others. Just keep in mind that roaming may take much longer than expected, so take this delay into account when deploying wireless LAN applications, especially wireless voice, which is not tolerant of roaming delays exceeding 100 milliseconds. ---------------------------------------------------------------------

Roaming that occurs during a call is referred to as mid-call roaming. For example, a user may be walking from one building to another building while talking on the phone. To avoid having the call dropped due to latency, it is very important that the mid-call roaming be accomplished as quickly as possible. This requires careful attention to the design of the network infrastructure. Strive for mid-call roam times of 100 milliseconds (ms) or less. The mid-call roam time is the amount of time that elapses after the last Reliable Transport Protocol (RTP) packet is seen from the current access point and the first RTP packet is seen from the access point that the wireless IP phone associates with.

Layer 2 roaming, which is a data link layer operation, takes place when a wireless IP phone moves out of range of an access point and reassociates with a different access point. Because this type of roaming occurs frequently as users move about a facility, such as a warehouse or hospital, be certain that Layer 2 roaming is fast. In most cases, the speed at which Layer 2 roaming occurs is highly dependent on the client radio. For example, some client radios found integrated in laptops may take anywhere from a couple seconds to several minutes to roam. These speeds are not fast enough to support roaming without dropping calls. When selecting wireless IP phones, be certain that they support fast roaming. The Cisco 7920 wireless IP phones, for example, are specially designed to make Layer 2 roaming fast enough to avoid dropped calls. For example, a Cisco 7920 phone initiates a reassociation process with a different access point if the phone doesn't