Problem solve Get help with specific problems with your technologies, process and projects.

VoIP over WLANs

While users are clamoring for VoIP and wireless, network managers are realizing that the projects are on a collision course.

Fueled by inexpensive hardware and a high "gee whiz factor," wireless LAN (WLAN) technology is one of the few areas in networking that is growing as fast as IP telephony. Wireless networks, particularly the ubiquitous 802.11b, offer simple and reliable mobility, but they do have a little performance wrinkle. Curiously, the users that couldn't possibly live another minute on 10BaseT are eager to trade in their switched, 100-Mbps full-duplex connections for the freedom of a wireless NIC.

While users are clamoring for VoIP and wireless, many network managers are realizing that these projects are on a collision course. The 802.11b spec tops out at 11 Mbps and many users connect at far less. IEEE 802.11a relieves that somewhat with a 54-Mbps top end, but its bandwidth is still shared, not switched, between all the users on the subnet. Both of these standards not only divide the available bandwidth by the users, but also reintroduce the contention (collisions) of a half-duplex media. Finally, few, if any, wireless access points or wireless bridges support any quality of service (QoS) mechanisms. So how can you run VoIP over wireless? There are a few ways to answer that question.

The first is that if your wireless network is sufficiently under-subscribed, more than likely you won't have a problem. Contrary to popular opinion, an Ethernet collision doesn't really add much delay. In fact, since collisions must happen within the first 512 bit-times of a frame, at a rate of 11 million bits per second, that's roughly 0.0000465 seconds of delay plus some time for the exponential back-off algorithm and another 9.6 microseconds for the host to determine the line is no longer busy. When you factor in some slop, the net is a 2- to 3-millisecond delay per collision, which is really nominal.

However, on a heavily utilized segment, multiple collisions can add up quickly and ultimately be devastating. Even so, on such a segment, the real problem isn't the collision itself; it's the busy signal a host gets when someone else is talking. The length of the busy signal is affected by the MTU size of the segment and how many hosts are trying to transmit simultaneously. At the typical MTU of 1518 bytes, you could introduce enough jitter into the system to affect your voice quality, and obviously, the fewer hosts the better off you are.

If you're intent on moving to VoIP over wireless, you may have to take some steps to keep your ratio of wireless nodes to access points down to an acceptable level, which will really be determined by your users' habits. You may also want to consider reducing the MTU on the wireless segment.

Second, you might be able to make use of a call admission control scheme for Layer 2 known as the Subnet Bandwidth Manager (SBM). This scheme is very closely related to RSVP. At a high level, RSVP- and SBM-aware devices on a subnet communicate with each other and elect a Designated Subnet Bandwidth Manager (DSBM). Then, when one of the devices wants to request a service level guarantee for a new traffic flow, such as a voice call, instead of sending the reservation requests to the first Layer 3 hop in the path, which is usually the subnet's default gateway, the request is sent to the DSBM (even if it isn't in the Layer 2 path) which extends or rejects a reservation for the subnet, then forwards it along the path to the destination. This gives the DSBM a chance to affect the level of traffic and protect your important traffic.

Most routers and switches and hosts that support RSVP also support SBM (for example, Cisco IOS routers, Catalyst switches and laptops running Windows 2000 Workstation). The rub here is that few, if any, wireless bridges or access points support SBM, so even if call admission is successful with RSVP, it technically isn't a guarantee that you will always have the bandwidth you reserved. This is less of a problem if all the nodes on the wireless network support SBM. The success of this system will likely hinge on the queuing built into the port on the switch to which your WAP is attached.

Finally, you can dream of the day that IEEE 802.11e is baked and products start supporting it. This protocol will bring QoS as we know it to wireless networks. In theory, it won't replace the 802.11b or 802.11a standards we use now, but will work in conjunction with them to provide class of service for wireless traffic.

About the author:
Thomas Alexander Lancaster IV is a consultant and author with over ten years experience in the networking industry, focused on Internet infrastructure.

For more information:
For more information on SBM, read RFC 2814

Read more information on IEEE 802.11e

Read all of Tom Lancaster's VoIP Tips

Visit our extensive collection of Best Web Links on Voice/data Convergence

This was last published in June 2002

Dig Deeper on Wireless LAN (WLAN)

Start the conversation

Send me notifications when other members comment.

Please create a username to comment.