Voice over Wireless LAN 4.1 Design Guide
Voice over WLAN Wireless LAN Controller Design and Configuration
Downloads: This chapterpdf (PDF - 966.0KB) The complete bookPDF (PDF - 14.12MB) | Feedback

Voice over WLAN Wireless LAN Controller Design and Configuration

Table Of Contents

Voice over WLAN Wireless LAN Controller Design and Configuration

Network Configuration

Data Rates

Radio Resource Management

RRM Architecture Overview

Logical RF Sub-groups

Channel Scanning

RF Group

Dynamic Channel Assignment

Tx Power Level Assignment

Coverage Hole Algorithm

Monitor Intervals

Dynamic Channel Allocation

Client Roaming

Voice Call Admission Control

General Cisco Unified Wireless Network Configuration

Quality of Service Policy

Mobility Groups

AP Groups

Multicast Traffic


Voice over WLAN Wireless LAN Controller Design and Configuration


Wireless LAN Controller (WLC) configuration can vary from VoWLAN handset to VoWLAN handset and specific configuration settings can also depend on the requirements of the overall WLAN data network. Variations are principally targeted to the WLAN configuration on the WLC. There are also certain key Cisco Unified Wireless configuration considerations that directly affect the overall VoWLAN design and implementation—in particular, IEEE 802.11 wireless network configurations can have an effect.

Chapter 3, "Voice over WLAN Radio Frequency Design," addresses the guidelines for AP location, AP density, and Auto-RF features. This chapter focuses on Auto-RF configuration and WLC network configuration.

RF design cannot be ignored. Implementing an architecture featuring the correct location and density of APs for a WLAN network is the equivalent of correctly installing the cable plant for a wired network. In wired network, problems in the cable plant cannot be completely overcome by advanced features. Similarly, in the WLAN network, Auto-RF is unlikely to overcome a flawed AP deployment. This chapter addresses wireless network and Auto-RF configuration.

Network Configuration

The radio configuration of each AP should be left to Auto-RF , unless there are know issues at the site that preclude the effective use of Auto-RF.. The configuration for the AP network is performed under the IEEE 802.11b/g/n and IEEE 802.11a/n subsections of the wireless menu.

Data Rates

The goal in setting the data rates for the VoWLAN network is to match the data rates of VoWLAN handsets as closely as possible. For example, if the VoWLAN RF network design was based on a 24 Mbps data-rate, lower data-rates should be excluded if possible. This would only be possible when not supporting IEEE 802.11 1Mbps and 2Mbps and IEEE 802.11b 5.5Mbps and 11Mbps clients. Any lowering of the data-rate below that used in the RF design extends the AP cell size, increases co-channel interference, and reduces call capacity. Higher data rates than the site survey rate can be enabled, but a VoWLAN client might not take advantage of these rates because some VoWLANs prefer not to data rate shift. An example of the 24 Mbps and above configuration is shown in Figure 8-1.

Figure 8-1 Channel Data Rate Setting

The general global parameters (see Figure 8-2) for a channel can normally be kept at the default values. Some VoWLAN handsets might require the delivery traffic indication Map (DTIM) to be increased to maximize battery life, but this change should only be done based on design recommendation specific to the handset. The DTIM period sets the number of beacon intervals that a WLAN client will sleep before waking up to see whether any traffic has been buffered for it (when in power save mode). Multicast and broadcast traffic must be buffered—as well as any unicast traffic—when destined for power saving clients. This can affect application performance, so DTIM should only be adjusted to the levels recommend by the VoWLAN handset vendor. DTIM settings are global for the band and are not changed on a per WLAN basis; therefore, changing the DTIM value will affect each WLAN on a given AP radio.

Figure 8-2 General Global Parameters

Radio Resource Management

Radio Resource Management (RRM) can adjust AP channels (dynamic channel assignment) and power (dynamic transmit power control) to maintain the RF coverage and quality:

It adjusts the power level of the APs to maintain a baseline signal strength with neighboring APs at -70 dBm (configurable, and default value changed from -65dBm to -70dBm in the 4.1.185 code Release).

It adjust the power levels of the APs to increase the SNR of WLAN clients that are detected with poor SNRs.

It adjusts the channel of the AP when it notices nearby interference sources on the channel which the AP is currently located.

It continues to optimize the RF coverage for the best reception and throughput for the wireless network.

RRM addresses the issue that RF environments are not static. As different RF variables change (people in the room, amount of devices stored in the facility, leaves on trees for outside deployment, interference from different RF sources, and so on), the RF coverage changes with them.

Because these variables change continuously, monitoring for the RF coverage and adjusting it periodically is necessary, and RRM is an automatic mechanism for adjusting for changes in RF variables. For more detailed information on RRM (Auto-RF), see the following URL: http://www.cisco.com/en/US/tech/tk722/tk809/technologies_tech_note09186a008072c759.shtml

RRM Architecture Overview

Each WLC is configured with a RF-Network Name (the RF-Group Name, which is by default the same as the Mobility Group Name). WLCs with the same RF-Network Name can be part of the same RF Group. The RF-Network Name configuration is found in the Controller General Configuration menu, as shown in Figure 8-3.

Figure 8-3 RF-Network Name

In each RF group (if Group Mode is enabled in the Auto-RF configuration, Figure 8-4), the WLCs elect a leader and form an RF domain. The function of the leader is to collect the network-wide neighbor information from a group of WLCs and do the channel/power computation for an optimal system-wide map. If Group Mode is not enabled, the WLCs run computations based only on the neighbor data gathered from the APs connected to that WLC via LWAPP, trying to optimize the signal to -70 dBm between APs.

The APs transmit RRM neighbor packets at full power at regular intervals. These messages contain a field that is a hash of the RF group name, BSSID, and time stamp:

The APs accept only RRM neighbor packets sent with this RF network name.

When neighboring APs receive neighbor messages, they validate them before forwarding them to the WLC.

If they can validate the message hash and confirm that it belongs to the same RF group, the packet is sent to the WLC; otherwise, the AP drops the neighbor packet.

The APs forwards validated messages to the WLC, filling in the LWAPP packet status field with the SNR and RSSI of the received neighbor packet.

Logical RF Sub-groups

Within an AP group there may be clusters of APs that do not see each other, even if they are connected to the same WLC or connected to different WLCs that are part of the same RF group. In this case, theses APs form a logical RF sub-group whose RF parameters are calculated separately( i.e., the Auto-RF algorithms are calculated per RF sub-group).

Channel Scanning

The APs goes "off-channel" for a period not greater than 60 ms to listen to the other channels. Packet headers collected during this time are sent to the WLC, where they are analyzed to detect rogue APs, whether service set identifiers (SSIDs) are broadcast or not, rogue clients, ad-hoc clients, and interfering APs. By default, each AP spends approximately 0.2 percent of its time off-channel. This is statistically distributed across all APs so that no two adjacent APs are scanning at the same time. Packets received by the AP from clients are forwarded to the WLC with the LWAPP status field filled-in, which provides the WLC with radio information including RSSI and signal-to-noise ratio (SNR) for all packets received by the AP during reception of the packet. For more detailed information on RRM (Auto-RF), see the following URL: http://www.cisco.com/en/US/tech/tk722/tk809/technologies_tech_note09186a008072c759.shtml

RF Group

Figure 8-4 shows the RF Group configuration section of Auto-RF. In this area the Group Mode is enabled (if it is not enabled. the WLC considers only its own AP information in its RRM calculations). The display also identifies the Group Leader (the WLC responsible for the RF Group).

Figure 8-4 RF Group Configuration

Dynamic Channel Assignment

The next section in the Auto RF configuration section is RF Channel Assignment, shown in Figure 8-5. This feature controls Dynamic Channel Assignment (DCA).

Figure 8-5 RF Channel Assignment

The DCA algorithm, run by the RF Group Leader (the Channel Assignment Leader), is applied on a per-RF (sub) Group basis to determine optimal AP channel settings for all the RF (sub) Group APs. With the DCA process, the RF Group Leader (a WLC) considers a group of RF metrics to determine whether a change in AP channel scheme is appropriate.

Avoid Foreign AP Interference—APs report the percentage of the medium taken up by interfering IEEE 802.11 transmissions (this can be caused by overlapping signals from foreign APs, as well as non-neighbors).This field allows the co-channel interference metric to be included in DCA algorithm calculations. This field is enabled by default.

Avoid Cisco AP Load—Every AP measures the percentage of total time occupied by transmitting or receiving IEEE 802.11 frames This field allows the utilization of APs to be considered when determining which AP's channels need changing. AP load is a frequently changing metric and its inclusion might not be always desired in the RRM calculations. As such, this field is disabled by default. The Cisco AP Load parameter is a measure of channel load seen by the APs in the RF Group. It includes the co-channel interference generated by neighboring APs and clients.

Avoid non-IEEE 802.11b Noise—APs calculate noise values on every serviced channel. This field allows each AP's non-IEEE 802.11 noise level to be a contributing factor to the DCA algorithm. This field is enabled by default.

Signal Strength Contribution—Every AP listens for Neighbor Messages on all serviced channels and records the RSSI values at which these messages are heard. This AP signal strength information is the most important metric considered in the DCA calculation of channel energy. The signal strength of neighboring APs is always included in DCA calculations. This is a display-only field and cannot be modified.

These values are used by the RF Group Leader to determine whether another channel schema will result in an improvement of at least 5 dB (SNR) for the worst performing AP. A weighting is given to APs on their operating channels to bias them into maintaining their channels. As a result, adjustments are kept local; the weighting dampens changes preventing a domino effect in which a single change triggers system-wide channel alterations. Preference is also given to APs based on utilization (derived from each AP's load measurement report). A less-used AP has a higher likelihood of having its channel changed (as compared to a heavily used neighbor) in the event a change is needed.


Note Whenever an AP channel is changed, clients are briefly disconnected. Clients can either reconnect to the same AP (on its new channel), or roam to a nearby AP depending on client roaming behavior. Fast, secure roaming—offered by both Cisco Centralized Key Management (CCKM) and Proactive Key Caching (PKC)—will help reduce this brief disruption, assuming clients are compatible.


The following WLC commands provide visibility of the RF data collected by each AP:

show ap auto-rf IEEE 802.11b ap-name 
show ap auto-rf IEEE 802.11a ap-name 

The following is an example output using the show ap auto rf command:

Cisco Controller> show ap auto-rf IEEE 802.11b AP0012.d92b.5cfa

Number Of Slots.................................. 2 
AP Name.......................................... AP0012.d92b.5cfa
 MAC Address...................................... 00:12:d9:2b:5c:fa
  Radio Type..................................... RADIO_TYPE_IEEE 80211b/g
  Noise Information
    Noise Profile................................ PASSED
    Channel 1....................................  -97 dBm
    Channel 2....................................  -96 dBm
    Channel 3....................................  -95 dBm
    Channel 4....................................  -99 dBm
    Channel 5....................................  -96 dBm
    Channel 6....................................  -96 dBm
    Channel 7....................................  -93 dBm
    Channel 8....................................  -95 dBm
    Channel 9.................................... -100 dBm
    Channel 10...................................  -96 dBm
    Channel 11...................................  -96 dBm
  Interference Information
    Interference Profile......................... PASSED
    Channel 1.................................... -128 dBm @  0 % busy
    Channel 2....................................  -82 dBm @  1 % busy
    Channel 3.................................... -128 dBm @  0 % busy
    Channel 4.................................... -128 dBm @  0 % busy
    Channel 5....................................  -76 dBm @  1 % busy
    Channel 6.................................... -128 dBm @  0 % busy
    Channel 7....................................  -75 dBm @  1 % busy
    Channel 8.................................... -128 dBm @  0 % busy
    Channel 9.................................... -128 dBm @  0 % busy
    Channel 10................................... -128 dBm @  0 % busy
    Channel 11...................................  -70 dBm @  2 % busy
  Load Information
    Load Profile................................. PASSED
    Receive Utilization.......................... 2 %
    Transmit Utilization......................... 1 %
    Channel Utilization.......................... 3 %
    Attached Clients............................. 0 clients
  Coverage Information
    Coverage Profile............................. PASSED
    Failed Clients............................... 0 clients
  Client Signal Strengths
    RSSI -100 dbm................................ 0 clients
    RSSI  -92 dbm................................ 0 clients
    RSSI  -84 dbm................................ 0 clients
    RSSI  -76 dbm................................ 0 clients
    RSSI  -68 dbm................................ 0 clients
    RSSI  -60 dbm................................ 0 clients
    RSSI  -52 dbm................................ 0 clients
  Client Signal To Noise Ratios
    SNR    0 dB.................................. 0 clients
    SNR    5 dB.................................. 0 clients
    SNR   10 dB.................................. 0 clients
    SNR   15 dB.................................. 0 clients
    SNR   20 dB.................................. 0 clients
    SNR   25 dB.................................. 0 clients
    SNR   30 dB.................................. 0 clients
    SNR   35 dB.................................. 0 clients
    SNR   40 dB.................................. 0 clients
    SNR   45 dB.................................. 0 clients
  Nearby APs
    AP 00:0b:85:51:63:60 slot 1..................  -36 dBm  on   6 (192.168.60.10)
    AP 00:0b:85:52:40:d0 slot 1..................  -36 dBm on  11 (192.168.60.10)
    AP 00:12:44:b3:c1:f0 slot 0..................  -32 dBm on   6 (192.168.60.10)
    AP 00:14:1b:59:40:20 slot 0..................  -36 dBm on  11 (192.168.60.10)
    AP 00:17:df:36:99:80 slot 0..................  -59 dBm on  11 (192.168.60.10)
  Radar Information
  Channel Assignment Information
    Current Channel Average Energy............... unknown
    Previous Channel Average Energy.............. unknown
    Channel Change Count......................... 0
    Last Channel Change Time..................... Fri Oct 12 01:37:57 2007
    Recommended Best Channel..................... 1
  RF Parameter Recommendations
    Power Level.................................. 7
    RTS/CTS Threshold............................ 2347
    Fragmentation Tnreshold...................... 2346
    Antenna Pattern.............................. 0

Tx Power Level Assignment

The Tx Power Level Assignment is controlled by the Transmission Power Control (TPC) algorithm (see Figure 8-6) is run at fixed 10-minute intervals by default. It is used by the RF Group Leader to determine AP RF proximity and adjust each band's transmit power level in order to limit excessive cell overlap and co-channel interference. Each AP reports an RSSI-ordered list of all neighboring APs and—provided an AP has three or more neighboring APs—the RF Group Leader will apply the TPC algorithm on a per-band, per-AP basis in order to adjust AP power transmit levels downward such that the third loudest neighbor AP will then be heard at a signal level of -70 dBm (default value, with the 4.1.185 code release, but earlier code default of -65dBm may be inherited from a pre-existing configuration) or lower. Power changes are only made when an AP's third loudest neighbor is heard at a signal level higher than the default value of -70 dBm (there is a 6dB hysteresis used built into the TPC algorithm to prevent it from continuously hunting for the -70dBm value).

The TPC algorithm it not aware of the physical location of the APs or of requirements to run the APs at a higher or lower power due to some deployment issues. This needs to be considered in AP planning and deployment.

TPC is not aware of AP location or the coverage requirements of the WLAN deployment following should be observed for optimal power level and coverage:

APs should be located close to the perimeters of the building to ensure that coverage extends to these areas.

APs should be distributed as evenly as possible to ensure that neighbor signals reflective of coverage requirements

As the TPC algorithm is three dimensional, and an even AP distribution assists TPC, different floors should not have the same AP layout ( i.e., APs should be staggered per floor).

TPC not is aware of the goals for RF coverage and cell overlap that drove your AP placement. Therefore you should verify that your RF needs are being met by Auto-RF by performing a site survey after deployment and Auto-RF has performed its adjustments.

Auto-RF should be monitored to track the adjustments made by Auto-RF. Auto-RF will be making adjustments to assist the WLAN network to make changes, but these change can mean that something has happened that you did not plan our design for, and this should be investigated.

Figure 8-6 Tx Power Level Assignment Algorithm

Coverage Hole Algorithm

The Coverage Hole Algorithm is used to detect holes in coverage based on WLAN client signal measurements and to adjust AP power to address low client-signal levels. A coverage hole is considered to have occurred when client SNRs falls below a predetermined level. The number of clients required to trigger action is configurable as is the signal level. The Coverage Hole Algorithm section from the Auto-RF page is shown in Figure 8-7

Figure 8-7 Coverage Hole Algorithm

Maintaining VoWLAN coverage is critical for a successful VoWLAN service, so coverage hole protection is an important component in a VoWLAN deployment. As with many design considerations, a decision must be made favoring one characteristic over another:

If the Coverage Hole algorithm is made overly sensitive, it can trigger power increases in APs that are caused by client characteristics rather than coverage issues. This issue can occur with older non-Cisco compatible extension clients that might stay associated with an AP even though that association features a poor SNR. This can result in hole coverage being triggered and AP power being set too high. Poor planning can also trigger hole coverage. VoWLAN clients might be operating in an area where WLAN coverage was not planned and this might cause hole coverage to be triggered.

If the Coverage Hole is too insensitive, VoWLAN clients might lose calls due to a coverage holes.

Given the variables involved, there are no hard-and-fast rules for specific the Coverage Hole settings. It is best to start with the default settings for the Coverage Hole Algorithm and to monitor any coverage adjustments. If many APs are increasing the power levels, there might be a client issue. If a small group of APs are making coverage adjustments there might be a RF coverage issue.

Monitor Intervals

The Monitor Intervals section for the Auto-RF page is shown in Figure 8-8. These parameters determine how often the AP stops serving clients to perform RRM and Wireless duties. There is no need to adjust these values as part of the design process and they should only be adjusted when directed by Cisco support.

Figure 8-8 Monitor Intervals

Dynamic Channel Allocation

Figure 8-9 shows the Dynamic Channel Allocation (DCA) screen of RRM. This screen allows the selection of channels for use by the DCA algorithm. Figure 8-9 shows the channels have been selected in the 5 GHz band for use in this example. In this case, the UNII-1 and UNII-3 bands have been chosen to avoid in any Dynamic Frequency Selection (DFS) issues that might affect the VoWLAN network. Channels subject to DFS may be selected if the customer is sure that DFS is not going to be triggered at that site. DFS is required to avoid radar that operates in nominated channels.

Figure 8-9 Channel Selection for DCA

Client Roaming

Figure 8-10 shows the Client Roaming Screen of RRM. The parameters presented in this screen are communicated to Cisco compatible extension clients to inform them of parameters that should trigger a client roam. The default values might be a little low for a VoWLAN deployment because the AP cell sizes of VoWLAN deployments are usually smaller. While WLAN data clients can maintain their connection at a point where a VoWLAN client should roam, data clients should also roam as close as possible to the planned cell boundary to minimize the range of co-channel interference from these clients. The minimum values for the Minimum RSSI is -80 dBm, and the minimum value for the Scan Threshold is -70 dBm. These should be tested against typical WLAN data clients and used in VoWLAN deployments unless they are found to interfere with normal WLAN data client operation.


Note If the VoWLAN deployment is using lower client boundary power levels than our example, then different thresholds should be applied.


Figure 8-10 Client Roaming Parameters

Voice Call Admission Control

Figure 8-11 shows the Voice Call Admission Control screen of RRM. The default values (Max RF Bandwidth value equals 75 percent) are set high to prevent rejection of calls when suitable capacity is available.

Figure 8-11 Voice Call Admission Control

For best performance, the most accurate assessment of call capacity—Load-based AC—should be enabled. Admission Control enabled by itself uses the APs capacity to calculate the Call Admission Control (CAC). Load-based AC incorporates the channel capacity into the CAC determination and gives a much more accurate assessment of the current call-carrying capacity of the AP. Settings for the Max RF bandwidth and Reserved Bandwidth values depend on the VoWLAN handsets, the data rates used, and the other sources of the WLAN load. However, the Max RF Reservation should not be greater than 60 percent. At levels greater than 60 percent, the IEEE 802.11 protocol itself can start to be under stress with increases in retransmission. This can impact call quality even if WMM is being used, particularly if the is a number of voice calls are already in progress. Testing with the Cisco Unified IP Phone 7921G in both the 2.4 GHz and 5 GHz bands using the recommended signal levels and SNR suggests that the minimum value for the Maximum Bandwidth Reservation parameter of between 40 to 60 percent is also the best setting for this specific phone. Call quality starts to deteriorate when the Max RF Bandwidth is set at or below these levels.

General Cisco Unified Wireless Network Configuration

This section focuses on VoWLAN specifics of the WLC network configuration. The connection to the wired network is addressed in the The Enterprise Mobility 4.1 Design Guide, as are considerations affecting the decision to implement centralized or distributed WLCs.

The centralized WLC model was used in this design guide because it is the recommended deployment model of the The Enterprise Mobility 4.1 Design Guide, but no design features or characteristics unique to the centralized WLC model were implemented. The Cisco Unified IP Phone 7921G handset deployments discussed in this guide works equally well in either a centralized or distributed WLC deployment, but only the centralized model was tested and documented in this guide.

Quality of Service Policy

The quality-of-service (QoS) per-user bandwidth and over the air QoS policy settings on the WLC should be left at their defaults. The WLC, by default, does the appropriate conversion between IEEE class of service (CoS) values and Cisco QoS baseline, when CoS marking is enabled (Wired Protocol 802.1p) Differentiated Services Code Point (DSCP) and CoS values. An example of the a QoS Profile for Platinum QoS with CoS Marking is shown in Figure 8-12.

Figure 8-12 Example Platinum QoS Profile

We recommend that the QoS policy on the router/switch interfaces connected to the WLC be set to trust the CoS settings of the WLC. This means that the wired network responds to the CoS values controlled by the QoS policy set on the WLC. The WLC does not enforce any policy that changes the WLAN client DSCP values. The WLC policy effects will only be seen in the CoS values associated with the WLAN client traffic. If the routers and switches connecting to the WLC are set to trust DSCP, then a DSCP policy must be created and maintained on those router and switch interfaces—in addition to the policies applied on the WLC. For more information on WLAN QoS and traffic classification, refer to the Chapter 3, "Voice over WLAN Radio Frequency Design."


Note CSCsi78368 means that the WLC sets incorrect CoS values in the 4.1.185 code, but this is fixed in the WLC Release 4.2.61.0.


Mobility Groups

The APs (and associated WLCs) for an area of continuous VoWLAN coverage should be part of the same Mobility Group. If this is not the case, call quality is likely to be affected during a VoWLAN client roam between mobility groups because VoWLAN client state information will not be transferred between the WLCs of the two different groups. Given that there can be up to 24 WLCs per Mobility Group, it is unlikely that there is a requirement for multiple Mobility Groups in most enterprise deployments.

AP Groups

AP Groups were not used in this design guide. Customers might wish to implement AP Groups to map different VLANs on a WLC to the same WLAN SSID on different APs. This would allow VoWLAN client associated to APs in one building to use a different subnet to the VoWLAN clients from another building. The primary purpose of using AP Groups in this manner is to minimize the size of WLAN broadcast domains, or share WLAN client traffic across multiple VLANs. Another purpose is to have the WLAN subnet size fit a standard size used in the general campus design. Unless broadcast or multicast traffic has been enabled on the Cisco Unified Wireless Network, there is no need to minimize subnet size to control the WLAN broadcast domain because the Cisco Unified Wireless Network default prevents broadcast and multicast traffic from being sent over of the WLAN. This allows all the clients on the same WLC's WLAN to be on the same subnet without broadcast/multicast domain issues.

Multicast Traffic

The transmission of multicast and broadcast traffic over the WLAN is disabled by default on the Cisco Unified Wireless Network. Unless there is a specific application requirement (such as the use of Vocera badges), it should remained disabled. When multicast is enabled on the Cisco Unified Wireless Network, it is enabled on every WLAN—although it might only be required on a single WLAN. Given that the multicast traffic on a WLAN is sent out every AP radio with clients associated to that WLAN regardless of that client(s) requirements, every effort should be made to minimize the multicast traffic on every WLC WLAN interface. You can minimize the potential affects of multicast traffic by disabling IGMP on interfaces not requiring multicast and filtering multicast traffic on interfaces that have IGMP enabled.

For more information on WLC multicast features, refer to Chapter 6 of the Enterprise Mobility 4.1 Design Guide at this URL:

http://www.cisco.com/en/US/docs/solutions/Enterprise/Mobility/emob41dg/ch6_Mcst.html


Note In WLC 4.2 software release, Internet Group Management Protocol (IGMP) snooping is introduced to better direct multicast packets, and block the unwanted multicast traffic addressed above. When this feature is enabled, an access point transmits multicast packets only if a client associated to the access point is subscribed to the multicast group. This feature was not tested and documented this guide, but it is recommended that customers implement the feature.