Checklist for Planning a Voice Over Wi-Fi Network: Security and Performance (Part 4 of 4)

By ozerdo posted Feb 06, 2012 07:59 PM


Back to the future with this Airheads Online article from 2007



While Wi-Fi offers a number of different security options, many voice handsets only support a subset because of processing, cost and battery considerations.  Therefore design of a WLAN for voice may entail compromising over-the-air security to accommodate available handsets. 


We believe the correct approach is as below:  first choose a handset, then see if it can support the desired security model (the goal should be that voice and data work at the same level, e.g. WPA2/802.1x).  If the handset cannot attain this level, the network designer should take steps to make sure that they can be allowed onto the network, but that special security measures prevent intruders from posing as voice clients to hack into the network, as explained below.

      • First, identify the desired handset or range of handsets.  This is a general rule for adding voice services:  start with the handset.  Choice is often based on factors such as durability, aesthetics, PBX features supported, voice & data capabilities.
      • Now examine the security capabilities.  While a few months ago many handsets were limited to WEP security, a new generation is now available and the network designer should aim for WPA/PSK as a minimum level of security.  WPA2 is better, with WPA2/802.1x preferable to WPA2PSK, but performance, particularly handover performance will suffer as more sophisticated security is used.  We favour Opportunistic Key Caching (OKC) with WPA2 for excellent security with fast handover.
      • Good security design requires a comprehensive approach, so it is important to examine other aspects of the network.  Many networks use a separate VLAN to segregate voice traffic, although VLANs are not a good security tool and converged voice/data clients cannot be accommodated with this model.
      • Other approaches involve using firewall functionality to identify and police voice traffic, particularly when the voice handsets cannot offer the same level of authentication/encryption as Wi-Fi data clients.  This is obviously Aruba’s approach, as we have an integrated, Wi-Fi aware firewall.
      • At Aruba, we have found that re-keying in an 802.1x network can stress a handset’s processor to the degree that it can interrupt voice calls.  Therefore we now have a feature that delays re-keying till the handset is idle (not on a call).  An alternative, but inferior approach is to use a longer re-keying interval for voice devices.

Handover performance

Handing over a voice call from AP to AP is a function of both the infrastructure and the client.  While handover latency can be measured under laboratory conditions, there are many additional factors that affect real-life performance.

      • The target figure for interruptions in a voice call due to handover is 50-100 msec:  at these levels the user will not notice the interruption.  The state-of-the-art for lab tests is sub-20 msec.
      • Attention to AP spacing and RF planning as explained above will help to ensure that field experience is close to lab experience.
      • Security determines handover performance.  Pre-shared keys allow much faster handover than 802.1x environments, although of course they are not as secure.  There is not much inherent performance difference between WPA and WPA2 encryption levels, except that the latter requires more processing on the handset.
      • The ideal balance of security and performance today is when WPA2 is used with 802.1x and ‘opportunistic key caching’ in a centralised-controller WLAN.
      • 802.11r is a new standard, intended to improve handover performance.  In centralised WLAN architectures such as Aruba’s it offers only limited improvements, particularly if opportunistic key caching is used (see above).  But 802.11r support should be on the checklist for the WLAN vendor.

Battery Life

Good battery life is an important usability consideration for voice-over-Wi-Fi installations.  While much battery-saving technology depends on the handset, there are a variety of functions where the infrastructure can assist in extending battery life.

      • Determine desired battery life:  this will depend on applications.  For retail and hospital environments, where people pick up their phone in the morning or at the beginning of their shift, and return it to a charging cradle at the end of the day, a battery life of 12 hours may be adequate.  This is quite easily achievable today.
      • However, a dual-mode cellular/Wi-Fi phone will be treated more like a cellphone, where users expect multiple days between charges.  Performance is improving rapidly, but currently most dual-mode phones’ batteries will barely last for 24 hours with heavy business use. Handset vendors and WLAN infrastructure vendors, including Aruba, are innovating in this area.
      • U-APSD (Unscheduled, Asynchronous Power Save Delivery) is part of the 802.11e specification that the Wi-Fi Alliance is certifying as WMM-PS (Wireless MultiMedia Power Save).  This offers considerable improvement in battery life over former protocols, and while few handsets support U-APSD today, any new Wi-Fi infrastructure must be U-APSD/WMM-PS capable.
      • ARP proxy.  The key to extending battery life, particularly idle (not on-call) battery life is to reduce the LAN traffic the handset sees.  The most significant type of traffic is ARP’s, and good WLANs now proxy to reduce this traffic to voice clients.
      • Traffic filtering.  Some vendors offer features where extraneous traffic is not delivered to voice clients, thus saving the battery drain entailed in receiving and ack’ing such traffic.  Many types of multicast fall into this category.
        • Other features.  Battery life is one of the few areas in voice-over-Wi-Fi where the standards (and drafts of future standards) are not sufficient for good performance.  Therefore the customers should expect ‘proprietary’ extensions to standards in this area.  Some of these require compatible clients, whereas others work with standard clients.  At Aruba we have several of these, so please check with us and our competitors about the state of the standards and the state-of-the-art.

Wi-Fi Alliance Certifications

The Wi-Fi vendors and other interested parties take standards developed and published by the IEEE 802.11 committee, but most vendors today tend to develop to certifications of the Wi-Fi Alliance, a group of vendors formed to develop the market for 802.11 (and the originator of the term ‘Wi-Fi’, Wi-Fi logos, etc). 


Wi-Fi Alliance certifications are nearly all derived from subsets of the IEEE standards, and result in standardized tests to ensure inter-vendor interoperability.  The notes above identify the most important certifications, but they are re-stated below (this is a subjective rather than a complete list:  these are most relevant to voice-over-Wi-Fi infrastructure for Enterprise).  In selecting a WLAN vendor, it is more practical to ask for a roadmap for these certifications rather than references to IEEE standards.

    • Security certifications relevant to voice to include WPA and WPA2, which are derived from 802.11i.
    • WMM (Wireless MultiMedia) defines over-the-air QoS from subsets of 802.11e.
    • WMM-PS (Wireless MultiMedia Power Save) includes U-APSD from 802.11e.
    • WMM-AC (Access Control) is not yet finished, but will include T-Spec signalling from 802.11e for Call Admissions Control.
    • ‘Voice over Wi-Fi for Enterprise’ (name may change) will include parts of 802.11e, 802.11k, 802.11r and others in an attempt to ensure good performance and inter-vendor interoperability in Enterprise networks with multiple APs and other Enterprise requirements.