Checklist for Planning a Voice Over Wi-Fi Network: LAN Planning (Part 1 of 4)

By ozerdo posted Feb 06, 2012 07:56 PM


Back to the future with this Airheads Online article from 2007. 



Most Enterprises installing Wi-Fi networks today do so with the expectation that they will be able to support voice traffic, either immediately or in the future.  Our experience at Aruba is that when customers come to add voice to an existing Wi-Fi network, even one that was installed one or two years previously, there is seldom a need to re-engineer the network.  (Since voice over Wi-Fi technology is continually advancing, we usually recommend upgrading to the latest software when deploying voice on a previously data-only network).

However, many customers have expressed interest in a brief guide to the state-of-the-art in voice, and particular network design considerations for voice over Wi-Fi networks.  This note lists what we have found to be the most significant areas for consideration – clearly we cannot speak in detail for all Wi-Fi vendors, but it includes many generalizations which we believe would apply to most state-of-the-art WLAN infrastructure.


LAN planning

Since voice is an end-to-end application, ensuring the LAN is ready for voice traffic is essential.

  • If the Enterprise already has VoIP applications on the LAN, there should be minimal extra work required to extend the applications to voice over Wi-Fi.
  • Start with a quick check of capacity:  assume each voice call takes 100kbps each way over the LAN (200kbps for both directions).  This is assuming G.711, a 64kbps codec:  there is some bandwidth reduction if compressed voice is used, but this is not usually significant, due to the overhead of many headers.
  • The LAN should support QoS (802.1p or DSCP).  Exceptions if the available LAN bandwidth comfortably exceeds the peak traffic, but it depends how lucky you feel.
  • Currently, voice is often configured on its own VLAN.  Some WLAN architectures require this VLAN to be present at every LAN port where an AP is installed, with a voice-specific SSID that maps to this VLAN.  There is no such restriction with the Aruba architecture.  Indeed, with the proliferation of voice-and-data capable devices, provisioning of separate VLANs for voice and data is not possible.
  • The number of devices on a VLAN should be limited to avoid excessive background traffic.  This can become a problem from 100-200 devices on the VLAN.  There are various ways to design to this limit:  often ‘mobility zones’ are limited, for instance if a building is covered for Wi-Fi but the surrounding car parking area is not, the building is a ‘zone’ as there will never be a need to handover Wi-Fi voice calls outside the building.
  • For large areas with continuous coverage (for instance several buildings on a campus with the intervening outdoor areas), most vendors offer a choice of L2 or L3 mobility architectures for voice handover.  The former involves bridging between VLANs while the latter uses some form of Mobile IP.  These are well-understood features, but often they bring in some complexity and a performance hit in the form of increased handover times between mobility zones (in the order of a few hundred msec), so these boundaries require attention at the planning phase.
  • Most modern APs can accept Power over Ethernet and/or local power.  The former reduces cabling and installation costs, particularly if the AP is in the plenum (ceiling) space.