Designing for Voice is a Big Deal!

I’ve had the following discussion with many ‘CMR’-type folks. (Certified Magazine Readers). I thought it might make a good blog-post, and perhaps even a white paper.

I am totally open to your critique on this – please send feedback with your comments!

The discussion usually starts when the client already has a working Wireless Network, and is asking me to simply add voice to the existing Data Wi-Fi system.  They always make is sound so easy, “just add the voice thing”… but it isn’t easy at all.

Data networks and Voice networks have different design parameters. Different packet flows, and way different expectations with respect to coverage, continuity, etc.

Controllers and APs will use the ‘Automagic’ function… yeah, right…

In the ‘old days’ we designed networks for coverage – only spec was to get signal to the designed areas at a specific RSSI (dBm).  To verify the design, we could easily go out and walk around watching the signal strength and ‘prove’ we had a good wireless network.

No longer is mere coverage measured by RSSI (dBM) sufficient, you also have to meet ALL the other design constraints for Voice. By the way, these each might have different answers depending on the VoWiFi handset of choice.

After going through the following list with clients, they either push back hard asking why I’m asking them so many questions—they just want it to work without any work on their part.

Or, they get overwhelmed with all the details and think their Controllers and APs will use the ‘Automagic’ function and all will be well with the world.

Designing Wireless LANs to actually work… is WORK. Designing for Voice takes even more work. (and a lot more money!)

By the way, I haven’t even touched the client side of this equation, or the call manager, or RF interference… we’re just getting started folks!

Oh, and one more thing… all of these delays listed below are on top of VoIP network latency caused by Propagation Delays, Handling Delays, and Queuing Delays on the Wired Network. Fun, Fun, Fun!

To get a Wireless Network that actually works, be sure to design, measure, and verify the following Wireless LAN Specs:

First AP Coverage

  • Usually something like −67dBm or better
  • I describe this at the ‘want’ area

Second AP Coverage

  • Perhaps −70dBm or better (Cisco phones want −67dBm)
  • Some people call this ‘overlap’ but it’s not measured in percent of area, but in dBm for the ‘backup’ coverage
  • You can’t measure the ‘overlap’ in percentage, but you can measure ‘backup coverage’ in dBm.

Co Channel Interference

  • Above −67dBm and less than −85dBm on same channel equals Interference
  • In my terms I describe this as the ‘Don’t Want’ area – less than −85 is the ‘Don’t Care’ zone
  • By the way, this is the HARDEST to achieve, but when you don’t achieve it, you have large collision domains, where many clients and APs must ‘share’ the frequency, resulting in many additional problems

Client to AP Density

  • Usually something like 10:1 or for some VoWiFi handsets 7:1
  • (you actually need to do an Erlang analysis to find how many ‘average’ minutes of call per hour for this calculation)
  • You need to be able to measure and verify there is appropriate number of APs for clients

Additional Density

  • Areas where there might be an abnormally high concentration of devices
  • (Auditoriums, around nursing stations, etc.)
  • You need to be able to measure and verify there is appropriate number of APs for the clients IN that area

Data Throughput

  • First would test for ‘gross’ data rate, like 1, 2, 5.5, 6, 11, 12, up to 54Mb/Sec
  • More importantly, check for NET throughput with iPerf to meet design standards
  • You can check data rates *to* the AP (wireless rates) by sending packets to the AP
  • You can check data rates *through* the AP by placing the iPerf server directly behind the AP
  • Or check data rates *through* the Network by placing iPerf server back near your core where your servers are


  • Less than 5 msec
  • Variation of latency between packets
  • Measure both upstream and downstream jitter during a two-way conversation call in progress


  • Less than 50 msec – total end-to-end delay

Packet Loss

  • VoIP really likes to see less than 1% packet loss
  • Achieving a 1% packet loss is highly unlikely given the physics of Wi-Fi

AP Handoff

  • Less than 50 msec
  • This can be improved with a proprietary Distribution System (all APs enterprise-class from same vendor)
  • Fast Secure Roaming can also help
  • Try testing on an ‘Open’ SSID first, then test again with your Authentication system in place


  • Use a Codec that has the highest potential MOS score
  • Don’t try to use compressed Codecs, we have lots of bandwidth, it’s a quality issue with Wi-Fi


  • Data usually has a ‘Portability’ need for coverage
  • Portability – loose session, but not IP upon roaming – Like sleeping your laptop as you move to another room
  • Voice has a ‘Mobility’ need for coverage
  • Mobility – can’t loose session at all during any roam


  • Open is the fastest for supporting Voice over Wi-Fi, but has no security
  • WPA-PSK still requires a key exchange upon roaming
  • WPA-Radius might require a full authentication cycle clear to Radius Server
  • Some vendors support key caching or fast secure roaming

Coverage Areas

  • Usually designs for Data include areas where laptops go (carpeted or vinyl floors)
  • Voice designs also need Elevators, Stairwells, bathrooms, parking structures, etc.

Collision Domains

  • You can’t change the Physics of Wi-Fi, it will always be a Shared Medium
  • Design accordingly

Quality of Service

  • Choose your Priority Queues appropriately; realize with Wi-Fi we don’t have an Absolute Priority
  • Only a statistical advantage, Data WILL sometimes get in front of Voice traffic
  • Make sure ALL your APs and Clients can support the QoS system you choose
  • Put Voice and Data on separate frequencies to guarantee they don’t share the same medium

Error Rates

  • Set parameters and design goals for Retry Rates and CRC rates on your Wireless Network
  • Measure and be sure to verify before starting the Voice clients on the Wireless Network

Translation Delays

  • 802.11 Wi-Fi to 802.3 Ethernet translation adds a slight delay

Transport Delays

  • Lightweight APs have to send their frames back through Access and Distribution switches prior to reaching the Controller at the Core, then forward back through same process from Core back to Access layer devices

End to End QoS

  • Check to see your QoS set at the client carries those priority bits clear through your network to the receiving client

Whew! – and those CMRs thought it was going to be easy to add voice to your Wi-Fi network.

Protection Mode

  • When designing around a b/g mixed mode environment the Protection Mode adds overhead to every packet exchange
  • Get rid of all 802.11b clients on your network, as well as within range of your network – if possible
  • Set expectations accordingly if you must support mixed b/g networks—at least ½ data rate loss minimum plus additional packet overhead

Power Management

  • Use the most efficient Power Mode supported by your clients and APs
  • Some of the older versions were terribly inefficient, especially with respect to Voice packets


  • When configuring a unique SSID for Voice, remember adding a VLAN to Wi-Fi does NOT break up any broadcast domain, you are still in a collision domain and broadcast domain with all other devices on same frequency within hearing range

Oh, and did I forget to mention you still have all the wired side issues to deal with as well. Passing QoS up and down, Propagation Delays over the network, Handling Delays in preparing the voice packets, and Queuing Delays on each router hop?

Oh, and did I also forget to mention all the issues of working with the new 802.11n header structures, new power management schemes, MSDU lack of Priority in the header, MPDU size delays, and Non-Greenfield protection delays, as well as overhead caused by DIFS, Preambles, Headers, SIFS, Preamble, ACK — plus the whole Contention Window Delays?

Oh, and did I also mention you need to have the correct tools and skills needed to test and VERIFY all these items?

Whew! – and those CMRs thought it was going to be easy to add voice to your Wi-Fi network.