BPDG - Voice Over IP

an ARRIS company
Deploying Voice over IP for Wi-Fi

Design and Configuration Guide
Best Practices Design Guide
June 2018
Table of Contents
Intended Audience......................................................................................................................................... 5
Voice Application Requirements ................................................................................................................... 7
Network Transmission Delay .................................................................................................................................. 7
Interpacket delay/Jitter ............................................................................................................................................ 7
Quality of Service (QoS) .......................................................................................................................................... 8
Why Queue Traffic? ................................................................................................................................................................ 9
End-to-End QoS ................................................................................................................................................................... 10
Voice and VLANs.................................................................................................................................................................. 11
Packet Loss .......................................................................................................................................................................... 11
Evaluating Voice Quality ....................................................................................................................................... 11

Mean Opinion Score (MOS) .................................................................................................................................................. 11
R-Factor ............................................................................................................................................................................... 12
Roaming ....................................................................................................................................................... 14
Authentication Delays ........................................................................................................................................... 14
PMK Caching.......................................................................................................................................................... 14
Opportunistic Key Caching .................................................................................................................................................... 16
802.11r (Fast BSS Transition) ............................................................................................................................................... 16
802.11k................................................................................................................................................................................. 17
Client Admission Control (CAC) ............................................................................................................................................ 17
Channel Selection ................................................................................................................................................................. 18
Handsets ...................................................................................................................................................... 19
Dual-band (5 GHz support) .................................................................................................................................... 19
WMM ....................................................................................................................................................................... 19
Roaming ................................................................................................................................................................. 19
Handoffs ............................................................................................................................................................................... 19
IP Roaming ........................................................................................................................................................................... 20
Sticky Clients ........................................................................................................................................................................ 20
Power-Save Mode .................................................................................................................................................. 21

Legacy Power Save .............................................................................................................................................................. 22
U-APSD ................................................................................................................................................................................ 22
Capacity.................................................................................................................................................................. 22
802.11ac .................................................................................................................................................................. 23
Environmental Factors ................................................................................................................................ 24
RF Interference....................................................................................................................................................... 24
Site survey.............................................................................................................................................................. 24
Signal Strength ..................................................................................................................................................................... 24
Construction Materials .......................................................................................................................................... 24

©Ruckus Networks 2
June 2018
Configuration Optimizations ...................................................................................................................... 26

WLAN Prioritization ............................................................................................................................................... 26
Configuring WLAN Prioritization (Web UI) ............................................................................................................................. 26
Configuring WLAN Prioritization (CLI) ................................................................................................................................... 27
Client Admission Control (CAC) ........................................................................................................................... 27
2.4 GHz Voice Clients ........................................................................................................................................................... 27
5 GHz Voice Clients .............................................................................................................................................................. 27
Configuring CAC for a WLAN (Web UI) ................................................................................................................................. 27
PMK Caching.......................................................................................................................................................... 28
802.11r .................................................................................................................................................................... 28
Configuring 802.11r (Web UI)................................................................................................................................................ 28
DTIM Configuration................................................................................................................................................ 29
SmartRoam............................................................................................................................................................. 29
OFDM and CCK Rates............................................................................................................................................ 30
ChannelFly ............................................................................................................................................................. 31
Configuring ChannelFly (Web UI).......................................................................................................................................... 31
Configuring ChannelFly (CLI) ................................................................................................................................................ 32
Background Scanning ........................................................................................................................................... 33

Configuring Background Scanning (Web UI) ......................................................................................................................... 33
Background Scanning vs. ChannelFly ................................................................................................................................... 34
Power Symmetry .................................................................................................................................................... 34

Mitigation: ............................................................................................................................................................................. 35
Configuring Transmit Power Per AP (Web UI) ....................................................................................................................... 35
Configuring Transmit Power Per AP Group/Zone (Web UI).................................................................................................... 36
Minimum Power Settings ...................................................................................................................................................... 37
Backhaul....................................................................................................................................................... 38
VoIP and Wi-Fi Mesh.............................................................................................................................................. 38
VoIP and Wireless Bridging .................................................................................................................................. 38
Summary ...................................................................................................................................................... 39
Tips and Best Practices .............................................................................................................................. 40
©Ruckus Networks 3
June 2018
Copyright Notice and Proprietary Information
Copyright © Ruckus, an ARRIS Company 2018. All rights reserved. The Ruckus, Ruckus Wireless, Ruckus logo, Big Dog design, BeamFlex,
ChannelFly, Xclaim, ZoneFlex and OPENG trademarks are registered in the U.S. and other countries. Ruckus Networks, MediaFlex, FlexMaster,
ZoneDirector, SpeedFlex, SmartCast, SmartCell, and Dynamic PSK are Ruckus trademarks worldwide. Other names and brands mentioned in
this document or website may be claimed as the property of others. 17-6-A
Destination Control Statement
Technical data contained in this publication may be subject to the export control laws of the United States of America. Disclosure to nationals
of other countries contrary to United States law is prohibited. It is the reader’s responsibility to determine the applicable regulations and to
comply with them.
Disclaimer
THIS DOCUMENTATION AND ALL INFORMATION CONTAINED HEREIN (“MATERIAL”) IS PROVIDED FOR GENERAL INFORMATION
PURPOSES ONLY. RUCKUS AND ITS LICENSORS MAKE NO WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, WITH REGARD TO THE
MATERIAL, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY, NON-INFRINGEMENT AND FITNESS
FOR A PARTICULAR PURPOSE, OR THAT THE MATERIAL IS ERROR-FREE, ACCURATE OR RELIABLE. RUCKUS RESERVES THE RIGHT TO
MAKE CHANGES OR UPDATES TO THE MATERIAL AT ANY TIME.
Limitation of Liability
IN NO EVENT, SHALL RUCKUS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL OR CONSEQUENTIAL DAMAGES, OR
DAMAGES FOR LOSS OF PROFITS, REVENUE, DATA OR USE, INCURRED BY YOU OR ANY THIRD PARTY, WHETHER IN AN ACTION IN
CONTRACT OR TORT, ARISING FROM YOUR ACCESS TO, OR USE OF, THE MATERIAL.
Ruckus Networks | 350 West Java Drive | Sunnyvale, CA 94089 USA | T: (650) 265-4200 | F: (408) 738-2065 ruckuswireless.com
©Ruckus Networks 4
June 2018
Intended Audience
This document addresses factors and concerns related to Voice over IP in Wi-Fi environments commonly found in enterprise deployments.
VoIP has specific requirements that are more stringent than simple data service and therefore requires more consideration before
deployment.
This document is written for and intended for use by technical engineers with some background in Wi-Fi design, VoIP and 802.11/wireless
engineering principles.
©Ruckus Networks 5
June 2018
Overview
Voice over IP, also known as VoIP or Internet Telephony is a method of transmitting voice calls over packet-based networks. This technology
uses the Internet to make voice and video calls. The use of IP phones has gained immense popularity among small, medium and large
businesses. This is largely because it reduces the expense of call transmission.
As it grows in popularity, the demand for reliable networks capable of transmitting voice without losing voice quality has increased.
The popularity of mobile phones, interestingly enough, has reduced most people’s expectations for voice quality. Mobile phones can have a
much lower quality than a traditional landline. Therefore, people have become more tolerant of occasional blips in a call.
FIGURE 1: APPLICATIONS OF V OIP
Wi-Fi in particular can pose challenges for voice. It is a packet-based network that has potential for high latency, jitter, and dropped
connections versus a traditional circuit based network. These factors can contribute to poor voice quality and can impede a VoIP.
A good VoIP design however should be able to deliver high quality voice transmission that is at least as good as a mobile phone and ideally
much better. Before the actual design of a VoIP network can start, there are some issues that should be considered. These can dramatically
impact the final design, deployment and performance.
These include the following:
• VoIP handset capabilities
• Deployment environment
• Site survey
• Wi-Fi configuration to support voice
• Backhaul
Fortunately, with the right Wi-Fi technology and careful planning, most if not all of these problems can be avoided. This document discusses
best practices for planning and deploying VoIP over Wi-Fi.
©Ruckus Networks 6
June 2018
Voice Challenges in a Packet-based Network
Voice Application Requirements

The first thing to consider is what VoIP requires from a network to function correctly. Voice is considered the most time-sensitive application on
a network. It does not tolerate any kind of delay.
When planning a voice network, the following guidelines should be used:
• Network transmission delay (latency)
• Inter-packet delay/jitter
• Quality of Service (QoS)
• Packet loss
Network Transmission Delay

When a person on a VoIP call begins to speak, the handset immediately packetizes the data and transmits it to the network. The network is
then responsible for getting this data to the other handset as quickly as possible. Delay, or network latency, introduces a lag in the time one
person speaks and the other person hears them. Minor delays are unavoidable, and VoIP can be tolerant of some delay, but not much as
discussed above.
Audio latency consists of two parts: the time it takes to encode the audio and the travel time of the packet. The latency itself doesn’t affect the
quality of the delivered audio, but it can affect the interaction between the two end users. At 100 msec of latency, the users start talking on top
of each other, and at 300 msec, the conversation becomes impossible to follow.
With the advent of VoIP, a number of testing organizations set out to determine the range of delays that users would find acceptable. What
they found was that one-way delays up to 70 or 100 msec were essentially unnoticeable. Once that one-way delay went past 100 msec, some
people began to complain. When the delays reached 150 msec, virtually everyone was complaining. To get an idea of what that delay is like, a
cell phone-to-cell phone call has a one-way delay of around 140 msec. Users are willing to trade-off voice quality of the convenience of
mobility, so we should not try to equate that directly with user expectations on wired telephone systems.
FIGURE 2: E FFECTS OF D ELAY ON VO IP
Most Wi-Fi handset manufacturers recommend network latency that is less than 150ms (end-to-end). Higher latency can impact the quality of
the call and can be perceived as an echo, lag time, clicks, voice cutting in and out or a dropped call. Keep in mind; the latency time includes
the entire network path from one handset to the other. This might involve transmission over Wi-Fi, a wired network, a public network or VPN.
Interpacket delay/Jitter
Jitter is the variation in the delay of received packets. High jitter results in choppy voice or temporary glitches. VoIP devices implement jitter
buffering algorithms to compensate packets that arrive at highly variable times, and packets can even get dropped if they arrive with excessive
delay.
©Ruckus Networks 7
June 2018
Jitter is related to network delay and represents the inter-packet delay variation. A good voice call should have a consistent delay (low)
between all of the voice packets. This helps create a smoother call that is more consistent with delivering toll-quality voice.
The human ear is more sensitive to packets that arrive too late or out of order than to dropped packets. Therefore, it is better to drop a packet
that has too much delay. The human brain is adept at pattern recognition and can compensate for a relatively high percent of lost packets
much better than it can deal with the echo of a delayed packet. (Sending an audio file that has 10% packet loss). This is the opposite of
traditional data transmission, which is very delay tolerant but does not tolerate dropped packets. CS-ACELP (G.729’s algorithm for code
compression using linear predictive analysis) includes packet loss concealment. Most codecs include this (sometimes called packet loss
protection)—it simply blends the time between packet A and packet C so that it is less noticeable that packet B was dropped. The human
brain does the rest.
FIGURE 3: T HE E FFECTS OF VARIABLE NETWORK D ELAY (J ITTER )
With respect to jitter, one of the first things to check are the QoS settings of the network. If the QoS has not been configured or improperly set
up, voice packets will not be receiving priority. This will result in missed or discarded packets, leading to higher jitter.
Quality of Service (QoS)
Quality of Service (QoS) can prioritize network traffic to ensure that the voice calls have priority over less delay sensitive traffic so that users can
make a voice call regardless of what other traffic exists on the same network (streaming videos, downloading large files, etc.).
Whenever a device transmits data, a priority should be applied to that traffic. QoS is a standardized method to do this. Ultimately, it ensures
that the users can make good quality voice calls without the calls being dropped.
QoS divides data into four types: voice, video, data and background. The highest priority is typically voice. This means that whenever a device
transmits data it should always send the voice traffic before any other type of data.
Wi-Fi was not originally designed to carry voice so 802.11, the wireless networking standard, now includes modifications to increase reliability
and add QoS. How a device classifies traffic becomes extremely important. There are several ways it can occur. WMM (Wi-Fi Multi-Media) is a
Wi-Fi Alliance interoperability certification based on the IEEE 802.11e standard. This method is based on the transmitting device tagging the
packet, indicating its prioritization. This allows a single device to transmit different types of data (voice, video, etc.) in an order of priority that
protects the more delay sensitive applications.
©Ruckus Networks 8
June 2018
The 802.11e amendment specifies eight user priorities (UP) that align with previous standards such as 802.1d and 802.1p. These are used to
determine Layer 2 link layer frame prioritization. The eight UPs are further grouped into four (4) access categories (AC). Each AC contains two
user priorities. Note that User Priority zero (0) as shown below is placed into the Best Effort AC instead of the Background AC for backwards
compatibility with non-QoS stations.
User Priority
Priority (UP) 802.1d Tag Access Category Designation
Lowest 1 BK AC_BK Background
2 - AC_BK Background (Spare)
0 BE AC_BE Best Effort
3 EE AC_BE Excellent Best Effort
4 CL AC_VI Video (Controlled Load)
5 VI AC_VI Video
< 100ms latency & jitter
6 VO AC_VO Voice
< 10ms latency & jitter
Highest 7 NC AC_VO Voice/Network Control
WMM requires a minimum of one set of four (4) queues per WLAN. Each queue maps back to one of the four Access Categories (ACs)
mentioned above. Ideally, a Wi-Fi solution will support four queues per client rather than per WLAN. This allows for much finer granularity and
network access control.
Why Queue Traffic?
There are several ways traffic enters a network. The default, if no QoS mechanisms are used, is First In, First Out (FIFO). In this case, traffic is
sent as soon as it is received.
©Ruckus Networks 9
June 2018
FIGURE 4: FIRST IN , FIRST O UT (FIFO)
In the diagram shown above, FIFO is used, i.e. no traffic prioritization. When this happens, traffic transmission can become unpredictable. The
above example shows how a laptop might “grab” more airtime because it transmits first and/or faster than one of the phones. Therefore, the
second phone’s traffic is delayed.
When traffic is queued, the network (AP) can choose how and when to transmit each frame of traffic.
FIGURE 5: Q OS C LASSIFICATION AND Q UEUING
In the figure shown above, the traffic from all three devices is sorted into the appropriate queue. The phones are put into the high priority
(voice) queue and are transmitted before the lower priority data traffic from the laptop.
End-to-End QoS
©Ruckus Networks 10
June 2018
To fully support WMM, the entire network must support it. The VoIP client must identify the traffic correctly, then the Wi-Fi AP and finally
whatever device sits between the Wi-Fi network and the wired network. Wired networks have a similar mechanism to WMM called TOS (Type
of Service) and COS (Class of Service) are bits that can be set within a frame to indicate its priority. Most network switches and routers
recognize and honor this setting.
A more recent method is DSCP (Differentiated Services Code Point) also known as DiffServ. This is a more sophisticated replacement for TOS
and COS and should be preferred. Most enterprise-class switches and routers support DiffServ.
Another way to implement QoS is for the network itself to recognize and automatically classify traffic based on the application. This is
something Ruckus APs already do. The AP will classify traffic into voice, video, data and background queues and transmit the data
accordingly. Although the WMM standard does not require it, Ruckus APs also implement per-client traffic queues to further differentiate and
priority service amongst multiple devices contending for network access.
Voice and VLANs
Voice devices are often placed on a separate VLAN from non-handset devices. Isolating voice traffic makes it easier to assign separate priorities
and configuration optimizations that may not be necessary or desired for non-voice traffic.
Packet Loss
Like network delay and jitter, packet loss is to be avoided at all costs. Even a 1% packet loss can significantly degrade a call. Packet loss in a
Wi-Fi network is a particular concern since it is a contention-based, half-duplex medium in which only one device may transmit at a time.
Multiple transmissions will result in collisions, retransmissions, data corruption and packet loss.
FIGURE 6: E FFECTS OF P ACKET L OSS
Another source of packet loss in a Wi-Fi network is RF interference. The largest source of RF interference in any Wi-Fi network is Wi-Fi itself.
This is usually the most significant source of RF by far. However, there are cases where other devices may transmit on the same frequency. This
is particularly true of the 2.4 GHz spectrum and is a major reason why it should be avoided if possible.
Evaluating Voice Quality
Determining an acceptable voice connection is somewhat subjective. Connections that stutter, echo or drop are definitely not acceptable.
Beyond this however, the rating becomes a little harder to define.
Mean Opinion Score (MOS)

A MOS or Mean Opinion Score assigns a numerical value as an indication of the perceived quality of received voice. This score is based on the
final connection: after transmission and code compression. The scores range from 1.0 (worst) to 5.0 (toll quality).
MOS is a highly subjective scoring system typically based on actual user experience and perception. Different codecs are given different
maximum (perfect) scores. The less compressed the codec, the higher the voice quality. The following table shows how this score is used:
June 2018
Perceived Quality MOS Value
Very satisfied 4.3 – 5.0
Satisfied 4.0 – 4.3
Some users satisfied 3.6 – 4.0
Many users dissatisfied 3.1 – 3.6
Nearly all users dissatisfied 2.6 – 3.1
Not recommended 1.0 – 2.6
Unusable 1.0 or less
A non-compressed codec - G711, will give the best voice quality, as no compression and decompression are required. This in turn makes this
G711 less susceptible to packet loss, which even in small amounts will quickly degrade voice quality.
Such uncompressed, high-quality codec is typically expected to have a maximum score of 4.4. Generally speaking, voice deployments should
be at a MOS value of 4.0 or better.
R-Factor
R-value is a score that is used to quantitatively express the subjective quality of speech in VoIP networks. The R-value score, which is used in
conjunction with voice testing processes, can range from 1 (worst) to 100 (best), and is based on the percentage of users who are satisfied with
the quality of a test voice signal after it has passed through a network from a source (transmitter) to a destination (receiver).
It uses a formula that takes into account both user perceptions and the cumulative effects of hardware and network performance (packet drops,
etc.) to arrive at a numeric expression of voice quality. The most common way to calculate the R-Factor is defined by the E-Model (ITU-T Rec.
G.107). This specification outlines specific metrics and their relationship with each other and the overall score. The range is defined as 0 to 100
which 0 as the poorest and 100 as perfect.
Each metric is reported as a single number on a per-call basis, typically in the range of 15 to 94. Lower numbers indicate lower voice quality. In
general, calls with values greater than 80 tend to have few quality problems while values under 50 tend to be associated with poor voice
performance.
Perceived Quality MOS Value R-Factor (Combined)
Toll quality 4.4 – 5.0 94 - 100
Desirable 4.0 – 4.4 80 – 94
Acceptable 3.6 – 4.0 70 – 80
June 2018
Reach connection 2.6 – 3.6 50 - 70
Not recommended 1.0 – 2.6 15 - 50
Unusable 0 – 1.0 0 - 15
R-Factor scoring has the advantage of taking non-subjective characteristics such as latency and jitter into consideration as well as user-oriented
perception values. Some network testing tools offer VoIP analysis and scoring. These are sometimes broken down into MOS and R-Factor
separately however R-Factor values are typically used to derive the final score and the MOS value (if reported) is mapped from that.
FIGURE 7: V OIP Q O S T EST
This screenshot shows a VoIP QoS test running the Ixia Chariot test platform. It shows the results of a live test between two wireless devices.
The test simulated VoIP traffic between the two devices using a specific codec. The measured MOS is reported as 3.62 out of an estimated
maximum of 4.37 (based on the codec used). The R-Factor is also reported as an average over the time of the test run.
June 2018
Roaming
The most obvious difference between wired IP telephony and Wi-Fi telephony is the roaming aspect. Roaming isn’t an issue for most home
networks, but enterprise Wi-Fi telephone users need to be able to maintain a telephone call as they move throughout the workplace. Wired IP
telephones don’t move, at least not in the middle of a telephone call, but Wi-Fi telephones can move at any time. Hence, roaming is a critical
part of any network design.
IEEE 802.11 clients typically decide to roam when the connection to the current AP becomes degraded. These mobile devices continuously
authenticate and synchronize while roaming thus requiring seamless roaming changes from one AP to the next. Especially the voice
applications running on these mobile devices depend on a persistent network connection and even a momentary loss of that connection could
possibly be disruptive to the communication and negatively impact a user’s productivity. Hence, Seamless roaming between wireless access
points has now become a crucial requirement.
As a client starts scanning other channels for alternative APs, reassociates, and authenticates to the new AP, there is an impact on the client
traffic. Anything that adds to the delay of voice traffic can impact quality and connection stability. Several techniques have been developed to
assist with roaming, authentication delays and handoffs.
Authentication Delays
One of the largest delays in a roaming event is authentication. Any encrypted traffic requires at least some security/key negotiation. This is
particularly true of 802.1X, which requires a full negotiation every time the device connects to a new AP.
There are several supported authentication mechanisms over Wi-Fi. The most popular are:
• Open (no authentication/encryption): Roaming in an open network is simple as there is no delay due to authentication
negotiation. The downside of an open network is data is not encrypted.
• WPA2 with a pre-shared key (PSK): WPA2 with a pre-shared key provides encryption via a shared secret (PSK). Since the
authentication happens with the WLAN, it is also fairly quick. When a device roams to a new AP, it presents the PSK, which
the AP can verify very quickly. Since data is encrypted and roam times are low, this is a popular choice for VoIP
implementations.
• WPA2 with 802.1X: WPA2 with 802.1X is the most secure option that authenticates the device with the user’s credentials
rather than a single, shared key. Because of this, outside devices are introduced into the authentication process such as a
RADIUS server, routers, etc. The delay introduced can be significant and negatively impact voice quality. Remember the
standards require the handset authenticate every time it roams. So not only does this authentication delay happen when the
handset first connects to the WLAN, it occurs every time the handset moves through the network.
• To get around this delay, there are several techniques in use today: PMK caching, Opportunistic Key Caching (OKC) and
802.11r.
PMK Caching
After every successful authentication between a wireless client and an AP, a Pairwise Master Key (PMK) is generated. This PMK is stored in the
client and the AP with associated context information such as the AP’s MAC addresses, the lifetime of PMK, etc. The collection of this
information is called PMK Security Association (PMKSA).
In PMK Caching, AP and the client maintain PMKSA for a period of time while a client station roams to a target AP and establishes a new
PMKSA.
June 2018
FIGURE 8: PMK C ACHING
If both the handset and the AP support PMK caching, the client device can save the master session key on an AP. When the client roams to
another AP, it must do a full authentication again, however if it roams back to the first AP it can use the PMK to skip the full authentication
process (RADIUS server, etc.) and only do the 4-way handshake. This allows the client to roam much faster. But it does have the disadvantage
of only helping a client roam back to a recently visited AP. It does not help when the handset moves to a new AP it has not visited.
June 2018
First connection to AP 1 First connection to AP 2 Second connection to AP 1
FIGURE 9: PMK C ACHING W ORKFLOW
Opportunistic Key Caching
Opportunistic Key Caching attempts to solve this problem. In this case the Wi-Fi network distributes the client device’s PMK to APs near the
client that are likely to be roaming candidates. When the handset moves, it can offer its PMK to the AP, which already has it cached and skip
full authentication and handshaking.
First connection to AP 1 AP’s exchange cached PMK IDs to neighbors First connection to AP 2
FIGURE 10: OKC W ORKFLOW
If 802.1X authentication will be used, the handsets and APs must support OKC. This should be a requirement for any handset selection.
Otherwise it is highly likely the latency introduced from full authentication during roaming will degrade voice quality.
Ruckus offers a compromise that can be useful for those who dislike the weak security of a single shared PSK and yet want to avoid the
potential roaming issues inherent with 802.1X or have devices that do not support OKC. The solution is Dynamic PSK. With Dynamic PSK, each
Wi-Fi device is given its own PSK, which is bound to that device’s specific MAC address.
This is a superior solution to typical PSK networks; each device has a unique key and yet there is no 802.1X service, which side steps many
support issues.
802.11r (Fast BSS Transition)

IEEE 802.11r standard offers better roaming assistance and elaborates Basic Service Set (BSS) transitions specification. It redefines security
negotiation to allow both the key negotiation and request for wireless resources to occur in parallel; saving time. Like OKC, this involves key
caching across the wireless network. Unlike OKC, 802.11r fully specifies the key hierarchy and protocol making it more fully interoperable
across a wider variety of devices. 802.11r is a mandatory component of the WFA’s Voice- Enterprise certification.
The difference between OKC and 802.11r is briefly outlined as follows:
Step OKC 802.11r
1 Scanning for APs Scanning for APs
2 Exchange 802.11 authentication/ Exchange 802.11 authentication/re-
June 2018
re-association messages association messages, QoS admission

control and PMK cached key check
3 802.1X PMK ID (key caching 802.11i 4-way handshake

check)
4 802.11i 4-way handshake (PTK Client connected

key creation)
5 QoS admission control
6 Client connected
FIGURE 11: OKC VS. 802.11R W ORKFLOW
By combining QoS and cached key exchange early on in the process, 802.11r offers significant reduction in time spent negotiating QoS and
security during a roaming event for 802.11r-enabled devices.
NOTE: Non-802.11r devices will still be able to use other roaming techniques such as PMK caching and OKC.
802.11k
The 802.11k specification is complementary with 802.11r and also a mandatory component of WFA Voice- Enterprise certification. It works with
802.11r by identifying nearby APs that are good roaming candidates before the device actually needs to roam. This saves time that would
otherwise be spent scanning for APs during the roaming event.
Client Admission Control (CAC)
Client Admission Control (CAC) allows the AP to adaptively allow or deny the association of clients based on the potential throughput of the
currently associated clients.
This improves the user experience for a subset of clients rather than provide a poor experience for all clients.
The administrator specifies the desired user experience with several settings such as:
Minimum client count, Maximum radio load, Minimum client throughput.
It is impossible to accurately calculate the average potential throughput per client and hence CAC relies on several policies to determine the
admission state of the client. The policies include minimum number of associated clients, airtime utilization (busy+Tx+Rx), average throughput
per client (est. channel capacity / no. of active clients) and capacity utilization. The following flow chart explains the logic with which client
admission decisions are taken by the AP.
June 2018
2G 5G
Min Client Count 10 20
Max Radio Load 75 75
Min Client Throughput 0 (disabled) 0 (disabled)
FIGURE 12: CAC ADMISSION C ALCULATIONS
Channel Selection
All wireless devices support a specific set of Wi-Fi channels it can use to connect. The regulatory domain (country code) determines which
channels are available. This means the device will not connect to an AP operating on a channel it does not support. To ensure a voice handset
can always connect to a nearby AP, the APs must be configured to only use the channels supported by the voice client. In a high-density
environment, this may not be necessary if the client has a large selection of candidate APs (of which at least one has a compatible channel).
Even if the voice client and the AP share the same country code they are not guaranteed to be compatible. For example, some regulatory
domains support the U-NNI-1, 2, 2e and 3 bands for 5 GHz clients. But clients are not required to support all available channels and might only
support U-NNI-1 and U-NNI-3. In this case, the U-NNI-2/e channels should be avoided on the APs.
June 2018
Handsets
Choosing a suitable Wi-Fi mobile device and overcoming their unique challenges with supporting VoIP is another critical piece of VoIP
deployment. It must not only interact with the backend PBX, it needs to seamlessly integrate with the Wi-Fi network as well. Not all handsets
are the same. Some support more Wi-Fi integration options than others. This can dramatically affect voice quality and reliability. Therefore,
selection of the handset is the single largest factor in the probable success of a deployment. Ideal features for a handset include dual-band (5
GHz support), WMM, Roaming, Power save/battery life and 802.11ac. Let us consider each of these capabilities separately.
Dual-band (5 GHz support)

The most critical piece in a deployment is the dual-band support of the mobile handset. The 2.4 GHz spectrum (802.11b/g/n) is the mostly
heavily used in Wi-Fi. This means it is potentially subject to more interference than other spectrums. If a handset is able to operate on the 5
GHz spectrum (802.11a/n/ac), the chances of interference are much lower. The 5 GHz band offers far more non-overlapping channels, lower
propagation (smaller cell size), and much less RF interference.
WMM
WMM maintains the priority of audio, video and voice, over other applications which are less time critical. Using QoS (Quality of Service) Wi-Fi
Multi-Media (WMM) ensures that the applications that require better throughput and performance, are inserted in queues with higher priority.
In this way, in a phone conversation, you are less likely to hear delays.
In order for the QoS to work it is extremely necessary that the AP and the client (mobile handset) both support WMM.
Roaming
Just as with the network side, mobile devices have to deal with roaming issues too. There is a wide discrepancy in how Wi-Fi devices are
designed to deal with mobility. Most VoIP deployments occur in a multi-AP environment. Therefore, the handset must be able to roam quickly
and seamlessly to avoid call disruption. This is where many handset manufacturers differ in their implementations.
Handoffs
In general, a Wi-Fi device of any type is the one that makes the decision to roam. Contrary to popular belief, the Wi-Fi infrastructure (with one
rare exception) has no way to tell a client device to move to another AP.
The main way a handset decides to roam is signal strength. When the signal strength drops below a certain threshold, the device will move to
another AP with a stronger signal if one is available. To assure smooth handoffs and minimal service interruption, it is important to make sure
there is always at least one AP with a strong signal (~ -65 dBm) within range of a handset.
Some handsets expose the roaming settings to an administrator. These may vary by manufacturer. If supported, some parameters that may
need to be configured include the following:
• Scan Start (dBm) – When the signal strength reaches this level, the handset will look for a better AP with a stronger signal.
• Handoff Start (dBm) – Threshold at which the handset will roam if a better AP is available.
• Handoff Delta (dBm) – Difference between signal strength to current AP vs. another available AP.
Each deployment may require different settings; however, the following table could be good to start with:
Action Signal Strength
Scan -60 dBm

Start
Handof -64 dBm

f Start
June 2018
Handof a. Bm
f Delta
IP Roaming
One significant delay that can occur during roaming is when a handset moves from an AP on one subnet to an AP on a different subnet.
Moreover, as soon as the handset’s IP address changes, any active sessions (RTP, etc.) will be broken.
The simplest way to avoid this is a flat network for the voice SSID. This way the handset can keep its address as it moves between APs in the
WLAN. Sometimes different subnets are unavoidable however. In that case, voice traffic should be tunneled back to the controller.
The controller acts as a proxy for the handset and forwards its traffic to the second subnet while allowing the client to keep its original address.
This is completely transparent to the handset and will not affect voice calls. This type of solution, although not typically a good choice for data,
works very well for voice due to the low bandwidth requirements.
FIGURE 13: IP R OAMING
The figure above shows IP roaming in action. The handset originally connects to AP1 and receives an address from VLAN 100. The phone then
roams to AP2, which is on VLAN 200. Instead of forcing the phone to drop its IP address and acquire a new one, the AP creates a tunnel to the
SmartZone100 containing the phone’s traffic on VLAN 100. The SmartZone100 is connected to the router via a trunked port and forwards the
phone’s traffic to the network. In this way, the phone’s original IP address is preserved, and it does not need to drop its connection after a
Layer 3 roam.
Sticky Clients
In a multi-AP environment, a client will always be looking for the best AP to connect to. It will remain connected to its current AP and roam to
an adjacent AP once the signal level falls below a certain threshold. This behavior ensures best possible performance at all times.
To achieve this, a client must be doing background scanning to learn about its environment. The frequency of this background scan can
determine the roaming behavior. "High" setting will make the client to perform background scanning more often to learn about available APs
to connect. While the "Low" setting will make the client to do less frequent scanning. Unfortunately, this tweaking is not readily available on all
client types. For example, various smartphones and Apple clients do not provide this setting to encourage roaming.
For these type of clients, it is obvious to look towards infrastructure for help. Ruckus has added firmware support to disconnect a client if its
signal falls below user definable threshold. This feature is called SmartRoam. With this feature there will be an explicit disassociate message to
kick-off the client.
June 2018
Some clients will not automatically move to an AP with a stronger signal. Instead they stay connected to an AP even though they are so far
away the signal is so badly degraded it is unusable. This behavior is considered “sticky”. Disconnecting a sticky client and reconnecting will
force it to connect to the closest and strongest signal.
SmartRoam assists sticky clients by encouraging them to disconnect from the original AP when a better AP is available.
This is a per-SSID setting as illustrated above. "smart-roam" parameter takes values from 1 to 10.
This is called roam factor, and it maps to a RSSI value in dB as per the list below:
FIGURE 14: S MART R OAM TO RSSI VALUES
SmartRoam settings can be done through the AP CLI. After logging into the CLI to get the current roam factor of your SSID use:
get roam_factor <wlan-name>
To enable smart-roam on SZ100 use the following commands:

TME-SZ100# config
TME-SZ100 (config)# domain <domain-name>
TME-SZ100 (config-domain)# zone <zone-name>
TME-SZ100 (config-domain-zone)# roam 2.4
TME-SZ100 (config-domain-zone)# roam 5
TME-SZ100 (config-domain-zone)# wlan <wlan-name>
TME-SZ100 (config-domain-zone-wlan)# roam-factor 2.4g <roam-factor vlaue>
SmartRoam is disabled by default. If it is enabled without a specified roam factor, a value of 1 is used.
It is recommend testing first with a very conservative setting like a roam factor of 2 or 3.
QA testing suggests NOT to use a value greater than 5.
Power-Save Mode
Battery life is the next big challenge in VoIP. Wi-Fi radio technology is less mature and hasn’t been optimized to the same degree as cellular.
So many Wi-Fi enabled devices suffer from significantly reduced battery life when the Wi-Fi radio is turned on. Wi-Fi QoS solutions improve
battery life by giving the device more control over when the Wi-Fi radio is turned on and off. But again, purpose-build Wi-Fi telephones take
advantage of these power saving mechanisms, while most dual mode cellular phones and PDAs do not.
June 2018
Handsets have a very limited battery life. Constant radio use for Wi-Fi can quickly drain the battery. To get around this problem, there are
standardized ways a device can inform the Wi-Fi network that it needs to go into power save mode. When a handset is not off hook (active
voice call) it can use this to reduce the amount of time it uses the radio and increase battery life.
There are several ways to implement power save in a Wi-Fi network. Any handset selected for a VoIP implementation should support at least
one of the following:
• Legacy mode
• U-APSD
Legacy Power Save

The 802.11 standard specifies the use of legacy power-save operation. There are two modes defined: Active-mode and PS-mode (Power-Save-
mode).
Active Mode
When a client is in active mode, the AP transmits its traffic immediately. This means the device must be turned on constantly in order to receive
a frame at any time. Essentially, this means the device can never go into power save mode and battery life is reduced.
PS-Mode
A client in Power Save Mode (PS-Mode) is allowed to turn its radio off from time to time to conserve battery life. This means the AP must
temporarily buffer traffic destined for that device until it wakes up.
Whenever traffic is buffered, the AP announces the presence of buffered frames for each device. This announcement is done in the AP’s
periodical beacon transmission. The announcement is called TIM (Traffic Indication Message). A DTIM period is also used to indicate a
recurring period of time (in number of beacons). A device can choose to only wake up during the DTIM transmission to check for broadcasts or
buffered traffic.
In PS-Mode, the device informs the AP it is entering power save mode. Then the client wakes up periodically to check beacons. If a beacon
indicates buffered traffic for that device, it will transmit a polling frame (PS-Poll) to the AP. This tells the AP to transmit the buffered traffic. A
device is free to send uplink frames to the AP at any time however.
The AP considers a device in whichever power save mode it was last told.
U-APSD
U-APSD (Unsaved Automatic Power Saving Delivery) is a power-save mechanism that is an optional part of the IEEE amendment 802.11e, QoS.
U-APSD is also known as WMM Power Save, and the behaviour and operation are exactly the same, except for coding of some information
elements. U-APSD works in conjunction with WMM and is tied with usage of the 4 EDCA access categories differentiate packets and priorities.
U-APSD offers the highest level of power saving performance and can extend battery life significantly.
U-APSD is basically a polling scheme, like legacy 802.11 PS-Mode, except any uplink frame from the device acts as a polling frame and is called
a “trigger frame”. The device can selectively retrieve traffic based on the EDCA access category.
An AP can support both legacy mode devices and U-APSD on the same WLAN. This is the default for Ruckus equipment.
Capacity
Because a VoIP connection transmits relatively little traffic, ranging in the hundreds of kilobits per second, it seems strange to discuss network
capacity. But capacity is even more important for voice than data. The reason for this requirement comes back to latency and jitter. If multiple
phones are on the same AP, the AP will rotate receive or transmit that data for that phone before moving to the next phone. If there are
enough phones on an AP, the time between each phone getting access to the network can be long and add to network delay and jitter.
For this reason, it is recommended no more than about 20 phones should be on a single AP.
June 2018
802.11ac
Applications like Voice over Wi-Fi, streaming video, database searches, file transfers, real-time security applications require consistent
bandwidth.
The 802.11ac IEEE standard is designed to deliver wireless data networking rates of three to more than six times faster than earlier 802.11a and
n networks. 802.11ac products accomplish this by evolving the 802.11n technologies rather than a revolution in technology.
Features include:
• Increases in multiple transmit and receive antennas, with a maximum of 8 spatial streams.
• Channel bonding from 40MHz to 80MHz, potentially 160MHz.
• Transmissions using 256QAM modulation.
• Multi User (MU) MIMO
Also, a 802.11ac wireless network is more robust as it will not be subject to the interference that plagues the 2.4GHz band caused by
Bluetooth, microwave ovens, analog security cameras and DECT phones etc. However, radar will be a consideration when choosing channels in
some countries where they broadcast in the 5GHz band.
802.11ac is backwards compatible with the other 5GHz band technologies (802.11a and n). This means that "a" and "n" clients will still be able
to connect to APs that have been migrated to 802.11ac.
Hence, it is better to have 802.11ac network for voice applications as it promotes faster speeds, higher throughput, consistent bandwidth and
lesser interference.
June 2018
Environmental Factors
The physical location of a Wi-Fi deployment can have a significant impact on the overall design and eventual performance. Key factors that can
affect this include:
• RF interference
• Site surveys
• Construction materials
RF Interference
As mentioned previously, RF interference can affect overall Wi-Fi network performance and introduce significant delay/jitter. VoIP requires a
reliable, predictable connection to function well. Therefore, anything the Wi-Fi network can do to improve its connection to the handset or
reduce overall RF noise/interference will greatly improve voice quality.
Environmental factors that can introduce noise: the Wi-Fi network itself, other Wi-Fi networks and non-802.11 RF (microwaves, non-DECT
phones, RFID, etc.)
Some noise is unavoidable. Every Wi-Fi network will produce some level of noise that can interfere with its own operations. There are also other
sources of noise that may or may not be under control for mitigation: neighboring companies’ Wi-Fi, non-802.11 security systems, etc.
Site survey
Whenever a Wi-Fi network must support voice, a site survey is crucial. As noted above, every location has its own unique combination of RF
noise, construction materials, layout, etc. that can affect Wi-Fi performance.
Signal Strength
Most VoIP handset manufacturers recommend minimum signal strength of -65 dBm. This is contrasted with laptops, which can often function
with signal strength of -75 dBm. A good site survey will take this into account and survey to -65 dBm rather than a lower rate.
SNR (Signal to Noise Ratio) must be part of any signal strength analysis since it takes into consideration the proportion of interference to the
signal. For example, a survey might yield signal strength of -65 dBm in the surveyed area. This seems like good coverage, however if the noise
floor (background noise) is very high, it will reduce the effectiveness of that signal. If the noise factor is large enough, e.g. -70 dBm, that yields
an effective SNR of only 5 dBm, which is very poor. Effectively, the noise is so loud it is drowning out the real signal. To maintain excellent
signal strength and quality, an SNR between 20-25 dBm is usually recommended.
It is also important to perform the survey to ensure the correct signal strength is being recorded. This includes:
• Passive vs. active survey tools – in particular, Ruckus APs with BeamFlex should always be surveyed in active mode (passing
traffic to the client device)1
• Use the right client device for the survey
A common mistake when surveying for voice is to measure signal strength with a laptop. This can result in insufficient signal strength for
phones, which typically have much weaker radios. Instead, always make sure the survey is performed with the exact handset that will be
deployed. If this is not feasible, use a device with similar radio/power characteristics. Using the right client device will help ensure the survey is
useful and yields accurate results for the design.
Construction Materials
RF will degrade as an inverse square over distance in free space. Within a building it typically degrades much faster due to walls, doors,
elevators, etc. The amount a signal is reduced as it goes through a wall is the attenuation rate. This is a primary reason why physical site surveys
are recommended for VoIP deployments. Only an on-site analysis can fully compensate for building construction and layout.

June 2018
Not all construction materials are conducive to good Wi-Fi operations. In particular, if pre 802.11n handsets are used, multipath can cause
problems. Multipath occurs when there is reflection, diffraction or scattering of the signal. Highly reflective materials such as mirrors and glass
can cause this.
RF absorption should also be mentioned here. When planning coverage, the materials must be taken into consideration. A large number of
glass walls, metal, etc. can reduce the Wi-Fi signal to the point that it is not useable by a handset. Given their weaker radios, handsets typically
need a much stronger connection than other devices such as laptops.
Voice typically requires 100% coverage to ensure seamless service for users. This means it is particularly important to ensure the minimum
signal strength is available everywhere.
June 2018
Configuration Optimizations
The previous sections described general guidelines to determine project performance requirements. This section describes further
optimizations that may be configured on the Ruckus ZoneFlex products. These include the following:
• WLAN prioritization
• Client Admission Control (CAC)
• PMK Caching
• 802.11r/k
• DTIM settings
• SmartRoam
• OFDM and CCK rates
• ChannelFly
• Background scanning
• Transmit power symmetry
The rest of this section includes descriptions of when and how to use these features as well as step-by-step instructions.
WLAN Prioritization
One option to help maintain the highest level of prioritization for voice traffic is to give it priority over other WLANs. Normally, an AP queues
traffic and sends the highest priority first – but if multiple WLANs have the same type of traffic they are transmitted in order. WLAN
prioritization can be used to give an additional priority to a voice WLAN when other WLANs contain high priority traffic as well.
To configure WLAN prioritization, each SSID must be configured as either low or high priority. If only one voice SSID is in use, it is
recommended to configure the other SSIDs as low priority. This ensures no other SSIDs can contend with the voice SSID for the highest
priority.
NOTE: The default value SSIDs is set to “High”. Therefore, any non-voice SSIDs should be edited and set to “Low”.
Configuring WLAN Prioritization (Web UI)

To enable prioritization on an SSID:
1. Go to Configure->WLANs
2. Click the Edit link next to the SSID
3. Check the Priority radio button – if this is a voice SSID, set it to High, if it is not, set it to Low
4. Click Apply to save the changes
June 2018
FIGURE 15: WLAN P RIORITIZATION C ONFIGURATION
Configuring WLAN Prioritization (CLI)
To configure prioritization on an SSID
ruckus(config-wlan)# priority high
Setting the WLAN’s priority to Low does not mean QoS is no longer applied to traffic for that SSID. Different prioritization for clients on that
SSID is still honored. The only difference is in whether their traffic is prioritized against a similar level of traffic from a high priority SSID.
Client Admission Control (CAC)

2.4 GHz Voice Clients
Because this spectrum is considered the “dirtiest” subject to a lot of Wi-Fi and non-802.11 RF interference, it should be avoided if possible. If a
5 GHz option does not exist, careful management is required. In particular, a trial evaluation should be performed to see if the RF environment
is sufficiently clean enough for acceptable performance.
5 GHz Voice Clients

Since the 5 GHz spectrum is typically subject to less interference, it is recommended as a best practice for the best performance. In general, a
higher number of calls and better-quality connections should be expected versus a 2.4 GHz deployment.
Client Admission is configured on a per-WLAN basis in conjunction with AP radios. This allows CAC to only be enabled on certain APs if
desired. This feature is disabled by default.
If CAC is configured on per AP per radio basis, the AP radio must also be configured for CAC to work.
Configuring CAC for a WLAN (Web UI)

To enable CAC on a radio:
1. Select the AP you want to configure and click on Configure.

2. Scroll down and select Advanced Options
3. Under Call Admission Control, Check the box next to the radio which has voice WLAN associated with it.
4. Enter the desired values for min client count, max radio load and min client throughput.
June 2018
FIGURE 16: C ONFIGURING CAC FOR A WLAN
PMK Caching
PMK caching may be selectively enabled or disabled on a per-SSID basis. If a WLAN supports voice clients, this should always be enabled.
PMK caching is enabled by default for all WLANs.
To enable PMK caching:
ruckus(config-wlan)# pmk-cache
To disable PMK caching:
ruckus(config-wlan)# no pmk-cache
The default time a PMK is cached before it is discarded is set to 720 minutes by default. This value may be changed via the CLI only:
ruckus(config-wlan)# pmk-cache timeout 600
If only OKC is required (no PMK caching), PMK may be disabled with the following command:
ruckus(config-wlan)# no pmk-cache-for-reconnect
802.11r
As discussed in the above section, 802.11r is a key component to facilitate standards-based fast roaming between APs. This is only useful for
devices that support 802.11r.
NOTE: Enabling 802.11r will disable PMK caching and OKC on that SSID.
Configuring 802.11r (Web UI)

To configure 802.11r BSS Fast Transition:
1. Go to Configure->WLANs
2. Scroll down towards the encryption options
3. Select Method - WPA2 or WPA-Mixed and then select AES. (802.11r Fast BSS Transition option is available for WPA2 and WPA-Mixed
only)
June 2018
4. Check the Fast BSS Transition box

5. Click OK to save the configuration.
FIGURE 17: C ONFIGURING 11 R FOR A WLAN
Note: The option to enable/disable 802.11r in SZ WebUI is available only when there is a Zone configured on that
(new) WLAN.
If you create a new WLAN and directly go to the encryption section and enable WPA2, the options for 802.11r are not there. If you select a
Zone (above in the "General" section), the 802.11r options become available.
DTIM Configuration
A Delivery Traffic Indication Message (DTIM) is included in the AP beacon. An AP uses this to notify a client that there is data waiting. This is
particularly important for devices, such as handsets, that use power save mode to conserve battery life.
The DTIM option is the number of Beacon Intervals that an Access Point will buffer broadcast traffic allowing devices in power save mode to
remain dormant for longer periods of time to save on battery power. By default it is set to 1, so the power save devices will have to wake up
each beacon interval (typically 100msec) to receive broadcast traffic. Please note power save mode will drastically reduce the throughput
available for the power save client and introduce latencies to the traffic.
Optimal DTIM settings can vary by handset manufacturer depending on how they implement power save and wake up. A good number to start
with is 1 or 2. This variable is set on a per-WLAN and per AP basis via the CLI only.
rkscli: set dtim-period wlan0 2
SmartRoam
SmartRoam is disabled by default. If it is enabled without a specified roam factor, a value of 1 is used. For detailed configuration, see here.
ruckus(config)# wlan voice-ssid
ruckus(config-wlan)# smart-roam 2
This factor should be based on the lowest common denominator (i.e. stickiest) client. The best way to determine this is start with a very low
(conservative) number sure as 1 or 2 and increase if needed.
June 2018
OFDM and CCK Rates

Connection rates are important to ensure high performance. Even though a voice connection sends relatively little data, it requires quick access
to the medium when it needs to transmit. The higher the connection rate for all clients, the faster they can get on and off the air. This means
faster access time for voice handsets.
One way to achieve higher data rates is through the use (or disuse) of two other mechanisms: Orthogonal Frequency Division Multiplexing
(OFDM) rates and Complementary Code Keying (CCK) rates. Each of these are modulation schemes used in 802.11 networks. CCK is a legacy
system that is only used by 802.11b networks. Newer technologies such as 802.11g, and 802.11a and 802.11n use OFDM as well.
OFDM and CCK are distinguished by a different set of basic rates as well as different receiver sensitivities:
CCK Rates OFDM Rates
Transmit Rx Sensitivity Transmit Speed* Rx Sensitivity

Speed
11 Mbps -82 dBm 54 Mbps -68 dBm
5.5 Mbps -85 dBm 48 Mbps -68 dBm
9 Mbps -87 dBm
6 Mbps -88 dBm
FIGURE 18: OFDM AND CCK R ATES
Two obvious pieces of information that can be extracted from these tables is that OFDM has much better receive sensitivity as well as higher
overall rates. If a client has a choice, OFDM will give much better performance. It cannot be assumed that an 802.11g device will always use
OFDM however. If there are devices present on the network that use CCK, OFDM devices must go into protection mode and could drop to
CCK rates.
Much better overall performance can be achieved if all Wi-Fi devices are restricted to OFDM only. This would improve sensitivity as well as
allow higher connection speeds.
Note: Removing CCK rates will effectively prevent any 802.11b devices from connecting to that SSID. Make sure there are no 802.11b
devices that need access before disabling CCK.
Ruckus equipment can be configured to not support CCK rates and require OFDM only. This is configured on a per-SSID basis via the CLI.
ruckus(config)# wlan voice-ssid
ruckus(config-wlan)# ofdm-only
This command removes CCK rates as an acceptable connection rate by a new client. Note that this does not prevent a connected client from
dropping to lower rates; it simply disallows it at the initial client association. Clients that later drop to very low rates typically do so due to
excessive interference and other PHY errors.
June 2018
ChannelFly
ChannelFly assesses channel capacity every 15 seconds, and change channel when, based on historical data, a different channel is likely to offer
higher capacity than the current channel
The algorithm looks for approximation to a global optimal in a probabilistic manner in a large search space, derived from simulated annealing
mechanism. In general, ChannelFly can react to large measured drops in capacity in as little as 15 seconds. Smaller drops in capacity will take
longer to react. Initially (in first 30 minutes or longer) there will be more frequent channel changes as ChannelFly learns the environment.
ChannelFly is a sophisticated method of determining the optimal channel selection for an AP. It is unique in that it not only takes the current
noise into consideration (both 802.11 and non-802.11) it also looks at the potential capacity available on a channel as well. Unlike many other
vendor solutions, ChannelFly might choose any possible channel rather than restricting itself to the traditional non-overlapping channels. This is
perfectly fine. Theoretically, this can cause co-channel interference with other devices on nearby channels but in reality, it may not be a
problem. In particular, when APs and devices are subject to attenuation, the signal strength drops off more quickly. This is particularly true for
the energy transmitted outside the center channel.  
For example, an AP might be said to transmit on channel 6, but it is actually transmitting across the “overlapping” nearby channels 4 and 5 and
7 and 8. But the main power and highest signal strength will be on the center frequency, channel 6. The RF energy across all occupied sub-
channels will drop as the power drops. With enough attenuation, the energy on the non- center channels can drop below an acceptable noise
floor and be used by another AP. This means ChannelFly might move APs to occupy an “overlapping” channel but not see as much of the
other device’s transmissions due to the signal drop-off beyond the center frequency.  
Note: ChannelFly uses the 802.11h channel announcement method of notifying clients that it is about to change channels on an AP. Support
for 802.11h is mandatory in 5 GHz clients but not 2.4 GHz. Because of this, some 2.4 GHz clients not deal as well with channel changes. If this is
a problem, please turn ChannelFly off for the 2.4 GHz radios. ChannelFly is enabled on a system-wide level per radio.
Configuring ChannelFly (Web UI)

1. Select the AP for the available AP list and click ‘Configure’.
2. Scroll down towards ‘Advanced Options’.
3. Go to ‘Auto Channel Selection’ and click on override check box for your desired radio.
FIGURE 19: C ONFIGURING C HANNEL FLY
June 2018
As shown in the screenshot below, select ‘ChannelFly’ from the drop-down list and keep the performance setting range.
FIGURE 20: C ONFIGURING C HANNEL FLY ( CONTINUED )
Configuring ChannelFly (CLI)

ChannelFly may also be enabled via the CLI:
rkscli: get channelfly wifi1 mtbc
wifi1 mtbc: 480
hi-memory backup: available
persistent: enabled
age: 1195082 second(s)
last-backup: 509 second(s)
OK
rkscli: set channelfly wifi1 mtbc 100
OK
rkscli: set channelfly wifi1 mtbc 480
OK
rkscli: set channelf
Commands starting with 'set channelf' :
set channelfly : set channelfly <wifi name> {options}
-> [ mtbc {1...1440} (Set mean time between channels) ]
-> [ persistent {enable|disable} (Clean hi-memory backup after rebooting) ]
-> [ reset (Reset channelfly and clean backup immediately) ]

June 2018
-- Set mtbc/persistent of channelfly
Note that ChannelFly is enabled at the same time the Mean Time Before Change (MTBC) is set. The default is 100 minutes.
See if ChannelFly is appropriate for your environment. If this doesn't suit, switch to background scanning and increase the scan interval to a
higher value as mentioned above.
Background Scanning
Background scanning allows an AP to periodically go off-channel and scan the other channels. This information is used in many ways:
• Gather information to determine optimal channel selection
• Discover neighboring AP candidates for load balancing
• Discover neighboring APs for Opportunistic Key Caching (OKC)
• Discover rogue APs
Background scanning provides many important services – in particular channel selection and OKC are vital for good voice connections. The
downside is that whenever the AP is off-channel it is not available to service clients. Background scanning happens fairly quickly, but it can
impact overall performance in a busy network.  This is particularly true of voice clients; when a handset wants to transmit, it wants to do it
immediately. If the AP is not on-channel this adds delay.
To take advantage of background scanning and maintain performance, the scanning interval can be tuned for specific environments.
Background scanning can be set on a global basis as well as a per-SSID basis from either the ZoneDirector’s Web UI or via the CLI. Background
scanning is enabled by default every 20s. Best practices for voice deployments should set this to a longer interval – at least 1 hour (3600
seconds).
Configuring Background Scanning (Web UI)

1. Select the AP for the available AP list and click ‘Configure’.
2. Scroll down towards ‘Advanced Options’.
3. Go to ‘Auto Channel Selection’ and click on override check box for your desired radio.
4. As shown in the below screenshot, select ‘Background Scanning’ from the drop-down list and keep the performance setting range.
June 2018
FIGURE 21: C ONFIGURING BACKGROUND SCANNING
Background Scanning vs. ChannelFly

Some form of channel optimization is recommended for any deployment. Whether that is ChannelFly or background scanning will depend on
the particular devices and environment. ChannelFly is generally a superior method but it does have drawbacks – namely there can be a lot of
channel switched in the initial settling period or if a major change in the RF occurs. If the clients support 802.11h this is not a problem, but
many 2.4 GHz-only devices do. They may become confused if they see the AP changing channels too much for them to properly handle.
Best practices in this case is:
1. If all handsets support 802.11h – use ChannelFly

2. If handsets do not support 802.11h – use background scanning
Power Symmetry
A commonly overlooked optimization is matching AP and handset transmit (Tx) power. Depending on local regulatory restrictions, APs can
transmit at 100 mW or higher. This is in contrast to a typical handset, which transmits at around 14 mW2.
When Tx power is not balanced (symmetric) a situation can occur in which the handset can hear the AP quite well and thinks it has a solid
connection. The weaker handset radio means the signal received at the AP is much lower. If the delta gets too great the handset will not roam
and yet packets are dropped between it and the AP due to the lower strength signal.
2
Transmit power can vary by manufacturer.
June 2018
FIGURE 22: T X P OWER ASYMMETRY
Symptoms of this condition include client stickiness (does not roam), dropped calls and constant connects/disconnects from the WLAN.
Mitigation:
The simplest way to reduce this problem is to reduce the Tx power of the AP. The power should match the handset power. Reducing Tx power
on an AP will reduce its coverage area, so implementing this change will change coverage. However, the need to have consistently high signal
strength everywhere would mandate a similar configuration anyway. So, this is rarely a problem.
Configuring Transmit Power Per AP (Web UI)

1. Go to Configure->Access Points
2. Click ‘Configure’
3. Click the checkbox next to Tx Power for each radio desired
4. Select the Tx power from the drop-down box.
FIGURE 23: C ONFIGURING T X P OWER PER AP
June 2018
FIGURE 24: C ONFIGURING T X P OWER PER AP ( CONTINUED )
Configuring Transmit Power Per AP Group/Zone (Web UI)

1. Select Zone in which the AP is present.
2. Click Configure
3. Click the checkbox next to Tx Power for each radio desired
4. Select the Tx power from the drop-down box
June 2018
FIGURE 25: C ONFIGURING T X P OWER PER AP G ROUP
Minimum Power Settings

It can be tempting to lower the transmit power to the lowest possible setting for a very dense environment. But this is only rarely
recommended. In general, the interference mitigation mechanisms built into Ruckus APs does a very good job. The advantages that lower
power might provide (smaller cell size) are usually outweighed by performance losses. Keeping the APs at a higher setting will nearly always
result in better performance. The key to successful voice deployment is keeping the AP and handset power balanced for optimal performance.
June 2018
Backhaul
Since most VoIP installations will traverse some type of backhaul (wired, wireless, etc.) to reach the PBX and other handsets, the backhaul can
also be optimized for voice deployments. In particular: latency and preservation of QoS.
VoIP and Wi-Fi Mesh

A common question in Wi-Fi design is whether voice may be deployed over a mesh network. In general, mesh should be avoided since it will
introduce some delay. How much depends on the connection speed of the mesh backhaul, reliability, etc.
Latency is a mesh network increases with the number of mesh hops, i.e. how many times a client’s data must hop from one AP to another
before it reaches the wired network. In a multi-hop mesh network this can introduce considerable delay. Delay can be even worst if there are
two Wi-Fi handsets involved – traffic must traverse the Wi-Fi from one handset and then downlink to a handset somewhere else. This effectively
doubles the latency introduced by the mesh network.
Ideally, any Wi-Fi network that supports voice should avoid mesh. Wired APs will give the fastest performance and introduce the least delay. If
mesh is absolutely required, the network designer could consider a single hop mesh network.
To ensure the reliability and performance of a mesh backbone, the following guidelines should be used:
• All mesh nodes must be connected with a very high signal strength/transmit rates/SNR
• The mesh nodes should be dual-radio with the backbone traffic on the 5 GHz radios only.
Following these simple steps will greatly increase the performance of VoIP over a mesh network.
VoIP and Wireless Bridging

If VoIP traffic must traverse two buildings over a wireless bridge, much of the previous section is also true. A bridge with a poor connection
between the bridge endpoints will not be able to maintain voice calls well.
June 2018
Summary
This document was written to provide an overview of the important design issues involved in deploying VoIP over a Wi-Fi network. Voice
network requirements are very stringent requiring minimal latency and jitter.
Some critical design issues that must be considered as part of any deployment include:
• VoIP handset selection
• Handset radio (spectrum) capability
• Quality of Service/WMM support
• Fast roaming/authentication
• 100% coverage with high signal strength
• Minimal RF interference
• Site surveys
• WLAN optimization for voice
June 2018
Tips and Best Practices

1. Dedicated SSID for voice clients. Use a dedicated VLAN as well.
2. Tunnel traffic to the controller
3. Enable Client Admission Control (CAC)
4. DTIM value of 2 (this will ensure decent battery life without compromising call quality)
5. Enable OFDM-only
6. BSS minrate of 5.5 Mbps
7. Use particular channels only (e.g.: channels 1, 6, and 11 only)
8. Enable 802.11d
9. Increase background scan interval to a higher value - 5 or 10 minutes
10. See if ChannelFly is appropriate for your environment. If this doesn't suit, switch to background scanning and increase
the scan interval to a higher value as mentioned above.
11. Disable mesh
12. Avoid any additional load on the APs
13. Enable RTS/CTS
14. Eliminate rogue APs and mobile hotspots
Please note that not all these settings may be appropriate for your deployment and VoIP handset you are using. Use only the ones that are
recommended by your VoIP handset maker.
Here are some of the configuration settings to consider that are specific to a VoIP handset:
1. Enable voice DSCP marking
2. Operate at max transmit power
3. Prefer 5 GHz frequency mode if available. This might require more number of APs. So site survey is the key.
4. Disable DHCP request on roam if there is a single VLAN for all voice clients
5. Control roaming if the device permits fine tuning

6. QoS preference. Some handset makers recommend using Continuously Awake Mode (CAM). Some may recommend
legacy power save.
June 2018
About Ruckus Networks

Ruckus Networks enables organizations of all sizes to deliver great connectivity experiences. Ruckus delivers secure access networks to delight
users while easing the IT burden, affordably. Organizations turn to Ruckus to make their networks simpler to manage and to better meet their
users’ expectations. For more information, visit www.ruckuswireless.com.
Copyright © Ruckus, an ARRIS Company 2017. All rights reserved. The Ruckus, Ruckus Wireless, Ruckus logo, Big Dog design, BeamFlex,
ChannelFly, Xclaim, ZoneFlex and OPENG trademarks are registered in the U.S. and other countries. Ruckus Networks, MediaFlex, FlexMaster,
ZoneDirector, SpeedFlex, SmartCast, SmartCell, and Dynamic PSK are Ruckus trademarks worldwide. Other names and brands mentioned in
this document or website may be claimed as the property of others.
Ruckus Networks | 350 West Java Drive | Sunnyvale, CA 94089 USA | T: (650) 265-4200 | F: (408) 738-2065 ruckuswireless.com
About ARRIS
ARRIS International plc (NASDAQ: ARRS) is powering a smart, connected world. The company's leading hardware, software and services
transform the way that people and businesses stay informed, entertained and connected. For more information, visit www.arris.com.
For the latest ARRIS news:
Check out our blog: ARRIS EVERYWHERE
Follow us on Twitter: @ARRIS

BPDG - Voice Over IP

Încărcat de

Informații document

Titlu original

Drepturi de autor

Formate disponibile

Partajați acest document

Partajați sau inserați document

Opțiuni de partajare

Vi se pare util acest document?

Este necorespunzător acest conținut?

Drepturi de autor:

Formate disponibile

BPDG - Voice Over IP

Încărcat de

Drepturi de autor:

Formate disponibile

an ARRIS company

Deploying Voice over IP for Wi-Fi

Evaluating Voice Quality ....................................................................................................................................... 11

Power-Save Mode .................................................................................................................................................. 21

Construction Materials .......................................................................................................................................... 24

Configuration Optimizations ...................................................................................................................... 26

Background Scanning ........................................................................................................................................... 33

Power Symmetry .................................................................................................................................................... 34

Copyright Notice and Proprietary Information

Destination Control Statement

FIGURE 1: APPLICATIONS OF V OIP

These include the following:

• VoIP handset capabilities

• Wi-Fi configuration to support voice

Voice Challenges in a Packet-based Network

Voice Application Requirements

When planning a voice network, the following guidelines should be used:

• Network transmission delay (latency)

• Quality of Service (QoS)

Network Transmission Delay

FIGURE 2: E FFECTS OF D ELAY ON VO IP

FIGURE 3: T HE E FFECTS OF VARIABLE NETWORK D ELAY (J ITTER )

Quality of Service (QoS)

Lowest 1 BK AC_BK Background

2 - AC_BK Background (Spare)

0 BE AC_BE Best Effort

3 EE AC_BE Excellent Best Effort

4 CL AC_VI Video (Controlled Load)

< 100ms latency & jitter

< 10ms latency & jitter

Highest 7 NC AC_VO Voice/Network Control

Why Queue Traffic?

FIGURE 4: FIRST IN , FIRST O UT (FIFO)

FIGURE 5: Q OS C LASSIFICATION AND Q UEUING

Voice and VLANs

FIGURE 6: E FFECTS OF P ACKET L OSS

Evaluating Voice Quality

Mean Opinion Score (MOS)

Perceived Quality MOS Value

Very satisfied 4.3 – 5.0

Satisfied 4.0 – 4.3

Some users satisfied 3.6 – 4.0

Many users dissatisfied 3.1 – 3.6

Nearly all users dissatisfied 2.6 – 3.1

Not recommended 1.0 – 2.6

Unusable 1.0 or less

Perceived Quality MOS Value R-Factor (Combined)

Toll quality 4.4 – 5.0 94 - 100

Desirable 4.0 – 4.4 80 – 94

Acceptable 3.6 – 4.0 70 – 80

Reach connection 2.6 – 3.6 50 - 70

Not recommended 1.0 – 2.6 15 - 50

FIGURE 7: V OIP Q O S T EST

negotiation. The downside of an open network is data is not encrypted.

FIGURE 8: PMK C ACHING

First connection to AP 1 First connection to AP 2 Second connection to AP 1

FIGURE 9: PMK C ACHING W ORKFLOW

Opportunistic Key Caching

FIGURE 10: OKC W ORKFLOW

802.11r (Fast BSS Transition)

The difference between OKC and 802.11r is briefly outlined as follows:

Step OKC 802.11r

1 Scanning for APs Scanning for APs