Cisco Unified Wireless Network Design Guide for Nokia Eseries Phones

The purpose of this document is to provide configuration assistance for the Cisco Unified Wireless Network (CUWN) products that support the Nokia Eseries phones. This is a WNBU Technical Marketing document to support the Nokia Eseries Deployment Guide provided by IPCBU Technical Marketing. The content includes Wi-Fi coverage design recommendations that are particular to 2.4-GHz radio performance characteristics of the Eseries phone. It also contains configuration examples and recommendations for the wireless LAN controllers (WLC) and the Wireless Control System (WCS).

You should review the Voice over Wireless LAN Design Guide and Enterprise Mobility Design Guide for comprehensive insight into deploying the Nokia Eseries as a Wi-Fi phone in an enterprise WLAN. Refer to the appendix for links to any documents referenced in this document.

This document primarily focuses on QoS, RF channel coverage, and RF channel capacity because without proper design of the first hop to the wired LAN and the last hop (the wireless shared media of Wi-Fi channels) from the wired LAN, call quality suffers, regardless of the design and configuration of the infrastructure.

The Nokia Eseries Wi-Fi enabled phones have the Wi-Fi Alliance certification for Wi-Fi Multimedia (WMM). The WMM certification is based on the IEEE 802.11e specifications which determine the quality of service (QoS) mechanisms used by packets sent between the Nokia phone and the Cisco access points. When correctly enabled on the client and WLC, the voice packets have priority access to the RF channel and have shorter transmit intervals on the RF channel over video and data packets. This certification is a very important feature in voice over wireless LAN (VoWLAN) support of call quality.

•Symmetric Mobility Tunneling. This section describes the new Layer 3 functionality for clients to roam seamlessly and maintain IP addressing and session state even across boundaries.

Designing the Wi-Fi Channel

Adding VoWLAN support to an existing WLAN requires a survey audit. When considering the addition of voice over the current WLAN, you must first determine the quality and coverage of the Wi-Fi channels. The items to evaluate include the following:

Doing this evaluation reveals the existing RF conditions. These items must be addressed to produce quality calls. In most cases, moving from a data-only WLAN to a data-and-VoWLAN WLAN requires additional access points. If the same facility is considering the installation of a Wi-Fi based location services application, you should review access point placement documentation for the RFID. The RFID support design can be quite different from a data or voice design.

Channel design must be focused on the phones' signal strength at the access point. The recommendation for the coverage design is a -67 dBm RSSI value on the access point from the edge of the coverage area. In most cases, the data rate should be 11 Mb/s for 802.11b/g and 12 Mb/s for 802.11g. For a good quality link to support a client phone, the client must be heard by the access point. Client phones have limited transmit powers and antenna performance when compared to access points. The RF uplink from the client to the access point causes many quality issues; therefore, to determine if a channel design provides good quality calls, measure the signal of the phone as displayed on the access point when the phone is at the designed cell edge.

Data Rates

The throughput of a 2.4-GHz WLAN RF cell is influenced by the configured data rates. Beacons and other 802.11 management and control packets are transmitted at the lowest required or mandatory data rate. Packets at 1 or 2 Mb/s support first generation clients. In a dense access point deployment, these data rates cause high retry rates because the cell is larger than what the client easily supports from a transmit power perspective. In a dense access point deployment with data rates of 1 or 2 Mb/s, the coverage cell may contain too many clients. In most cases, today's 2.4-GHz client radios support data rates from 1 Mb/s to 54 Mb/s. The 1 Mb/s data rate provides the longest distance of coverage capable from that client radio. But in many locations, long distance coverage in the 2.4-GHz spectrum is not necessarily an advantage and may result in poor cell throughput.

The original 802.11 specification supported WLAN radio data rates of 1 Mb/s and 2 Mb/s. The modulation type (CCK) used for those data rates provides the largest distance coverage of any modulation type in an 802.11 specification to date. The highest data rates in the 802.11 specifications use the modulation type known as OFDM. The highest data rates have the smallest distance coverage. These two facts are instrumental in cell design. High data rates have the smallest coverage area but provide the highest throughput cells. Low data rates provide the largest coverage area but have the lowest throughput cells.

Another disadvantage of larger 2.4GHz cells is the increased size of the RF collision domain and lower signal-to-noise ratios (SNR). The larger the cell, the more RF level interaction between WLAN clients, but also Bluetooth, microwaves, and other RF interferers. Sites that have dense 2.4 GHz access points deployments have shown channel utilization numbers over 30% without any data or voice traffic. The bandwidth of the channel is consumed by 802.11 management and control traffic. When such sites have the data rates of 1 and 2 Mb/s removed, and only 5.5 and 11 Mb/s were required, the channel utilization dropped to 5%.

After determining which applications are used by non-phone clients and what data rates are required by those clients, you should remove as many low data rates as possible. A cell without data rates of 1 and 2 Mb/s per second is smaller, but it also has the lowest amount of interference, the highest throughput, and the most calls. A cell without 802.11b data rates of 1, 2, 5.5 and 11 Mb/s supports even more throughput and calls. The 802.11g data rate of 6 Mb/s and 12 Mb/s provides about the same cell coverage area as 802.11b when the transmit power is below 17 dBm. In deployments with a high density of access points, the transmit power in most cases is 15 dBm and lower. When 802.11 and 802.11b rates are disabled, the phones and access points no longer send clear-to-send management packets, and the number of calls in the cell can reach 14 instead of the 7 calls normally associated with 802.11b.

Channel Capacity

Figure 1 shows the data rates and relative cell sizes and which part of the cell achieves the highest number of calls. When an access point is configured with low data rates (such as 6 Mb/s and 9Mb/s), it effectively has a larger cell coverage area than an access point that has those rates disabled. More clients can be active with the access point because of the larger cell size. The larger cell will likely have a higher channel utilization and noise floor and therefore support fewer VoWLAN calls. A cell that supports the data rates of 6 through 54 Mb/s supports fewer calls than a cell that has only 36 to 54 Mb/s enabled. The packets of the clients in the 6Mb/s coverage area of the cell have longer air time than the packets sent at data rates of 12 to 24 Mb/s and longer than those packets sent at 36 to 54Mb/s. The graphic shows a cell with the combination of 54Mb/s and 6Mb/s clients. The 54Mb/s clients are slightly slower because of the lower transmission rates of the 6 Mb/s data rate clients.

Figure 1 Varying Data Rates and Cell Sizes

The data rates and cell sizes are part of the criteria for call planning. The original Cisco guidelines for call planning suggested seven calls per access point. That design logic is no longer valid. With the advent of 802.11e and WMM, the design criteria involves call streams per RF channel. An example of a call stream is a VoWLAN phone calling a wired desk phone. Two call streams would be two VoWLAN phones calling two wired desk phones or those two Nokia VoWLAN clients calling each other. If those two phones that are calling each other are associated to the same access point, then those two call streams are in the same cell and on the same RF channel. The new call planning criteria is based on the number of call streams on the same RF channel. It is important to remember that RF channels can overlap. Two access points in near proximity of each other can be sharing the same RF channel; therefore, the number of quality call streams is related to the channel and not to the number of access points.

802.11b/g VoWLAN on 802.11n

The 2.4 GHz spectrum is used by four 802.11 specifications and four 802.11 modulation types. The specifications are 802.11, 802.11b, 802.11g, and 802.11n. The 802.11n specification also includes 5 GHz. The Wi-Fi alliance has decided to not include a certification for 40 Mhz wide channels on the 2.4 GHz spectrum. Cisco supports this view but current 802.11n Aironet access points are capable of 40 Mhz 2.4 GHz channels. The Nokia Eseries Wi-Fi phones have successfully been tested with Cisco Aironet 802.11n access points. The Nokia phones perform with equal call quality on 802.11n whether the access point is in 20 Mhz or 40 Mhz channel mode; therefore, running the access point in 40GHz mode has no call quality advantage.

The 802.11n specification, like the 802.11g specification, requires the use of CTS control packets if the access point is configured to support 802.11b. The data rates for 802.11n and 802.11g are maintained. The throughput of the cell is reduced because of the CTS protection mechanism. You should disable all 802.11b data rates if support for 802.11 is not required. With 802.11b disabled, the CTS protection mechanism is turned off. The 802.11g and 802.11n 2.4 GHz clients seamlessly interoperate with each other because they both use the OFDM modulation type.

The 802.11n carries expectations to improve cell throughput, capacity, and coverage. Although this is true, an 802.11b client is still an 802.11b client even when the client is associated to an 802.11n-enabled access point. The 802.11b client still has a maximum data rate of 11 Mb/s per second and a maximum throughput of about 7.1 Mb/s. The coverage is improved by the access points because of increased receiver sensitivity and increased transmit powers, but it is unlikely to improve more than 10% for 802.11b/g clients. In a noisy environment with high multipaths, the throughput is better because the MIMO antenna technology on the access point minimizes retries.

When Nokia phones were tested with Cisco Aironet 802.11g and 802.11n access points in the cell coverage area edge of the 802.11g access points, the average mean opinion score (MOS) value improved by half a point. The number of call streams increased by one call. Two additional call streams did reduce the average MOS value.

Coverage and Roaming

The proper coverage for voice suggests a 15 to 20 percent cell overlap. The WLAN data design guidelines do not require this level of overlap. The optimal VoWLAN cell boundary recommendation is -67 dBm, and the separation of cell is 19 dBm to provide quick roams at the RF median level. However, roam times and therefore call quality during roams are affected by the time it takes to re-authenticate the roaming phone that roamed to the access point. The new link to the roamed-to access point requires a new unique encryption key. To accomplish fast and secure roaming, Cisco recommends Cisco Centralized Key Management (CCKM) with TKIP encryption.

The Eseries configurations for EAP-based 802.1X security mode with CCKM support are as follows:

The complete WLC configuration is shown in chapter 2. For more information see the Cisco Wireless LAN Controller Configuration Guide. The document link is in the appendix.

Roaming Coverage with Elevators

Elevators and elevator shafts are highly reflective of Wi-Fi signals. Reflected signals create multipath, which means multiple copies of the transmitted signal are traveling in slightly different paths and time. Multipath is likely to cause RF level retry rates of 20% to 50% for signals transmitted at higher data rates. The method used to improve call quality in high multipath areas is to disable the higher data rates and enable the lowest data rates. The lowest data rates have the best delay spread performance which in turn reduces the retries. However, this is a trade off because the throughput of the cell near the elevator is reduced (along with a reduction of multipath and retries) while the call's quality is improved. OFDM modulation is effective for multipath phenomenons, but increasing the delay spread best addresses the retry problems in high multipath areas. The lower the data rate the better the delay spread. Because simultaneous calls are unlikely in an elevator, dropping the call, and not bandwidth, is the issue. The undesirable side effect of enabling the low data rates and disabling the high data rates is the increased collision domain of nearby cells on the same channel. Also, RRM does not adjust data rates and is not multipath aware. Data rates are a global setting per controller.

No standard foolproof method ensures coverage in elevators since there are many variables to consider. As such, you should follow a series of recommendations and best practices until an approach that provides a satisfactory level of service is found for a set of wireless clients in a unique environment.

When the elevator is in motion, the wireless client is unpredictable as it reacts to the rapid crossing of cells. Roaming is the responsibility of the WLAN clients and not the access points or supporting infrastructure. As such, wireless client roaming behavior is strongly influenced by the roaming algorithm implemented in the wireless driver supplied by the vendor. You cannot expect stable connectivity in elevators because of the unique and differing environmental and wireless client characteristics.

One common technique to provide wireless coverage in elevators is to place a diversity omni antenna directly outside of the doors of the elevators. The antenna should be mounted below the ceiling tiles. For hospitals that are deploying new 2.4- and 5-GHz WLANs, the Cisco AIR-AP1131AG has been a popular choice because of its design and the integrated diversity antenna which radiates the signal in a downward direction. The AIR-AP1242AG is also another good choice when specific external antennas are required or when access point enclosures are required. When external antennas are used, the AIR-ANT5959 2.4 GHz and AIR-ANT5145-R for 5 GHz are recommended for mounting below the ceiling tiles. These antennas are colored to match ceiling tiles and provide low gain diversity omni-directional radiators.

Many wireless installations are using the 802.11n AIR-AP1250 which provides backward compatibility to 802.11a/b/g wireless clients while providing 802.11n and MIMO. The new MIMO antenna technology combined with the newer radios performs better than compared to non-MIMO technologies in areas with high multipath. Many areas of a hospital are prone to high levels of multipath interference due to the construction techniques as well as RF shielding in some areas of the building. Recommendations for MIMO-based ceiling mount antennas are the AIR-ANT2430V-R for 2.4 GHz and AIR-ANT5140V-R for 5 GHz.

In many cases, but dependent on elevator design, a closed elevator door reduces the signal inside by 7 to 10 dB or more. This necessitates that the access point and antenna are positioned just a few feet in front of the elevator doors. To provide fast secure roaming between floors, put the access points that service elevators on the same controller and ensure that they are part of the same access point group. The design of the WLANs mobility groups and access point groups is essential for mobility design. Use the links in the appendix for the Cisco Wireless LAN Controller Configuration Guide and the Enterprise Mobility Design Guide. Symmetric Mobility Tunneling is crucial to prevent a dropped call as the wireless phone rapidly associates between access points on different floors. Refer to the "Symmetric Mobility Tunneling" section. Symmetric Mobility is not enabled by default and must be enabled for Layer 3 mobility.

Note With 5.1, Symmetric Mobility Tunneling is enabled by default. When you upgrade from 5.0 or previous versions, the 5.1 code still continues with the configuration of the previous version; therefore, verify the Symmetric Mobility Tunneling setting after you upgrade to 5.0.

Configuring WLC for Access Point Radio and QoS Support

This section describes how to configure WLC for Nokia Eseries WMM certified phones.

The phones supported by this controller configuration are the Eseries running the Nokia Intellisync Internet telephone program. When that application is installed, one of the following icons appears on the menu (see Figure 2).

Figure 2 Intellisync Icons

VoWLAN calls with clients that are WMM certified and associated to an SSID (which is configured to support the WMM specification) have QoS priority over the air. The WMM specification defines eight user priorities and four access categories, each defined by 802.11e.

In the 802.11e specification, traffic for clients not using WMM is referred to as a non-QoS station and is classified as best effort.

Clients that are incapable of using WMM QoS to the access points (because of firmware or driver limitations) can be assigned SSIDs that have a voice access category. The performance of the cell is enhanced when the client is configured to associate to an access point QoS SSID. The traffic or packet sent from the access point to the client fall into one of four access categories marked with one of eight user priorities. Refer to Figure 43 in the appendix for the marking of a voice packet transitioning from the phone to the WLAPP controller and back.

Step 7 In the RF Channel Assignment section of the window, choose Custom as the Assignment Method if the site survey design requires it.

Step 8 From the drop-down menu, choose a non-overlapping RF channel.

Note Only Channels 1, 6, and 11 are non-overlapping.

Step 9 In the Tx Power Level Assignment section of the window, choose Custom as the Assignment Method if the site survey design requires it.

Configuring the 802.11b/g Global Parameters

Follow these steps to configure the 802.11b/g global parameters.

Step 1 Choose Wireless.

Step 2 From the left sidebar menu, choose 802.11b/g/n > Network.

Step 3 Ensure that Short Preamble and DTPC Support are enabled. This is supported by the Eseries phones.

Step 4 Click the Enabled check box under CCX Location Measurement.

Note Leave the Interval parameter at the default value.

Step 5 Choose the data rate that matches the coverage design. The options are as follows for the varying Mb/s (1, 2, 5.5, and 11 Mb/s):

•Disabled

•Supported—Any associated client supporting the same rate may communicate with the access point using this rate.

•Mandatory—Clients that do not support the rate specified cannot associate.

Note The client is not required to use the rates marked Supported to associate.

Note Before starting the site survey or WCS voice readiness test, you should disable the 1 and 2 Mb/s data rates on sites with dense access point placements. Only a limited number of legacy client cards and devices still use these original 802.11 specifications. When you disable these rates, channel utilization is significantly improved, and the collision domain is significantly reduced. For the Eseries phones, the data rates of 1, 2, and 5.5 are probably not necessary.

Step 6 Click Apply.

Note For WLC software release 4.0.206 to 4.2.x, you should disable network arpunicast. Use the show network summary CLI command and see how the ARP Unicast Mode parameter is set. If it is not already set to Disabled, run config network arpunicast disable.

Step 4 Click a link in the Client MAC Addr column to see the details of a Nokia phone. The CCX version number is displayed on the first page.

The Client Detail window appears and shows the phone RSSI value (see Figure 15). The RSSI value represents how well the access point hears the phone. If the value is on the high end (around -35 dBm), the phone is very near an access point. A value such as -67 dBm is near the cell edge.

Figure 15 Client Details Client MAC Addr

The window example in Figure 15 shows the client is associated to an access point configured with an 802.1 tag value of 6. The U-APSD value of 15 in Figure 15 indicates that the client is misconfigured and is using a WMM setting for video.

Step 5 Ensure that the U-APSD value is 7 for voice.

Using WCS Templates for Nokia Wi-Fi Connections

WCS is a Cisco Unified Wireless Network tool for management of the wireless LANs. WCS configures WLCs, monitors the RF channels, and reports the performance of the network. Templates are stored on the WCS, edited and maintained on the WCS, and then distributed to the controller(s). The templates are used to audit the configuration of a WLC.

This chapter provides recommendations for a Nokia WLC configuration and the steps to create the WCS templates for those recommendations. The complete configuration is not given, but the recommended settings to best configure the WLC for quality calls with a Nokia Eseries phone is provided. Refer to the Cisco Wireless Control System Configuration Guide for further information. The link to this guide is in the appendix.

The new Nokia template should be similar to the WLAN template shown in Figure 20.

Figure 20 WLAN Template Window

Creating a Template for an 802.11b/g/n Radio

The Nokia Eseries phones have 802.11b/g radios. A 2.4-GHz network is recommended. If the site does not have a requirement to support 802.11b, a configuration that does not include 802.11b data rates is recommended. The lower data rates reduce call capacity and call quality on the RF channel.

Step 20 After the templates have been saved, choose them from the Template Name list and click Apply to Controllers.

Step 21 Choose the IP address to which you want the template applied (see Figure 22).

Figure 22 Applying Template to Controllers

Step 22 Click OK.

Voice Readiness, Auditing, and Reporting

This section describes the reporting that is available on WCS and includes actual steps to run the reports. A planning tool helps determine the number of access points for a given floor space. It does a path loss calculation to graphically present the estimated coverage of the access points. Another WCS feature is a report of voice statistics and radio frequency channel utilization. WCS can run an audit across all of the controllers to ensure that they are properly configured for voice. You can export many of the generated statistical reports as a CSV file or as email.

•Choose Reports > Performance Reports to generate a report on radio utilization, transmit power and channel, or voice statistics (see Figure 24).

Figure 24 Traffic Stream Metrics (graphical) Report

The voice statistics report shows only the metrics of voice packets going from the access point to the Nokia client. The Nokia client is not providing uplink metrics (see Figure 25).

Figure 25 Voice Statistics Report

The Radio Utilization report shows any radio channel issues (see Figure 26).

Figure 26 Radio Utilization Report

•Choose Report > Client > Traffic Stream Metrics for a graphical report that shows the packet loss at an access point (see Figure 27). A traffic stream metrics report can also be in table format and provide red or green ratings of the call quality (see Figure 28).

Figure 27 Packet Loss Graphic Format

Figure 28 Packet Loss Table Format

Voice Configuration Audit

Under Tools, you can choose Voice Audit. This report compares the configurations of the controllers to each other. It verifies voice readiness and alerts you as to which parameters are not set for the best quality performance. The rules and reporting are configurable (see Figure 29).

Figure 29 Rules and Reports for Voice Audit

Voice Coverage Readiness

The readiness tool uses an imported floor plan to determine whether the current configuration is suitable for supporting VoWLAN based on signal propagation between access points (see Figure 30). The default uses the Cisco 802.11b/g phone as the client device for coverage simulation. For the current Nokia 802.11b/g Eseries phone, the Cisco Phone client type is recommended. The transmit power for most sites should be 16 dBm or less.

Figure 30 Readiness Tool

Symmetric Mobility Tunneling

Cisco Wireless LAN Controllers enable users to roam transparently across all access points in the network. Clients roam seamlessly and maintain IP addressing and session state, even where controllers reside across routed boundaries from one another.

This Layer 3 mobility functionality was designed to deliver traffic with as little added latency as possible and with the capability to roam across wireless networks of all scales without altering the wired network configuration. Controllers can be placed anywhere in the network, and as clients roam from access point to access point across these controllers, clients remain connected, IP addresses remain unchanged, and session state is preserved.

This seamless Layer 3 mobility capability was achieved within Cisco's Unified Wireless Network architecture with an asymmetric traffic pattern, whereby a roamed client's egress traffic terminates on the new, foreign subnet (sourced from its original IP address). The client's ingress traffic is routed according to the original IP address that is maintained, which means that it arrives at its original anchor controller, is then tunneled to the new foreign controller, and then delivered to the roamed client.

This Layer 3 mobility operation works flawlessly in most environments. In networks where traffic is not allowed to be sourced on non-native subnets, asymmetric mobility tunneling between controllers does not function. The RPF checks and firewall rules prevent the operation. Cisco's new Symmetric Mobility Tunneling feature is designed to correct this problem.

Background on Mobility in Cisco's Unified Wireless Network

When a wireless client associates and authenticates to an access point, the access point's joined WLC places an entry for that client in its client database. This entry includes the client's MAC and IP addresses, security context and associations, QoS context, WLAN, and associated access point. The WLC uses this information to forward frames to and receive them from the wireless client. Figure 31 depicts what happens when the wireless client roams from one access point to another if both access points are joined to the same WLC.

Figure 31 Clients Roaming Between Access Points Joined by Same WLC

When the wireless client moves its association from one access point to another, the WLC simply updates the client database with the new associated access point. If necessary, new security context and associations are established as well.

Now, consider what happens when a client roams from an access point joined to one WLC and an access point joined to a different WLC. Figure 32 illustrates an inter-controller roam in the event of a Layer 2 roam. In this example, the participating controllers are terminating the given WLAN's traffic on the same subnet.

Figure 32 Layer 2 Inter-Controller Roam

As illustrated, a Layer 2 roam occurs when the controllers bridge the WLAN traffic on and off the same VLAN and the same IP subnet. When the client re-associates to an access point connected to a new WLC, the new WLC exchanges mobility messages (via UDP port 16666, or 16667 if controllers are configured to secure these messages with AES). These messages are exchanged with the original WLC, and the client database entry is moved to the new WLC. New security context and associations are established if necessary, and the client database entry is updated for the new access point. All of this is transparent to the end user.

Figure 33 illustrates an inter-controller roam in the event of a Layer 3 roam. In this example, the participating controllers are not terminating the given WLAN's traffic on the same subnet.

Figure 33 Layer 3 Inter-Controller Roam

In Figure 33, a Layer 3 roam occurs when the controllers bridge the WLAN on and off different VLANs and IP subnets. The inter-controller roaming is similar to Layer 2 roaming in that the WLCs exchange mobility messages upon a client roaming. However, instead of moving the client's entry to the new controller's client database, the original WLAN controller marks the client with an "Anchor" entry in its own client database. The database entry is copied to the new controller client database and marked with a "Foreign" entry in the new WLC. The roam is still transparent to the wireless client, and the wireless client maintains its original IP address. Security credentials and context are re-established if necessary.

After a Layer 3 roam, data moving to and from the wireless client flows in an asymmetric traffic path. Traffic from the client to the network is forwarded directly into the network by the foreign WLC. Traffic to the client arrives at the Anchor WLC, which forwards the traffic to the Foreign WLC in an Ethernet-in-IP tunnel (EtherIP, defined in IETF RFC 3378). The Foreign WLC then forwards the data to the client.

Note If a wireless client roams to a new foreign WLC, the client database entry is moved from the original foreign WLC to the new foreign WLC, but the original anchor WLC is always maintained.

Symmetric Mobility Tunneling Operation

The 4.1 Symmetric Mobility Tunneling feature allows both roamed clients' ingress and egress traffic to be tunneled to and from the anchor controller. This means that roamed clients reside logically in their anchor controller, and traffic patterns between the anchor and foreign controllers operate fully as a point-to-point symmetric tunnel. The only difference in operation between regular, asymmetric mobility tunneling and this new symmetric traffic flow is that the upstream traffic from roamed clients is not forwarded to the destination by the foreign controller. Upstream traffic is tunneled to the anchor controller first, where delivery to the network occurs (see Figure 34):

Figure 34 Symmetric Mobility Tunneling

This feature allows the underlying wired network architecture to remain fully unchanged when such security features as reverse path forwarding or filtering (RPF) checking is enabled on intermediary Layer 3 interfaces or when firewall rules prevent such operation between controllers configured in a mobility group (a cluster of controllers between which roaming is desired).

Mobility Configuration

The first step to configure Symmetric Mobility Tunneling is to verify that all controllers between which seamless roaming must occur are properly configured for mobility operations. When basic mobility is configured and verified, Symmetric Mobility Tunneling may be enabled.

Mobility configurations can be made through WCS or through the controller's GUI or CLI (though only one configuration interface should be employed for each given configuration step).

Configuring Asymmetric Mobility in WCS

Step 3 From the left sidebar menu, choose System > General (see Figure 35).

Figure 35 System > General

Step 4 Change the Mobility Domain Name (sometimes referred to as the Mobility Group Name) for any controllers which do not share the same Mobility Domain Name.

Step 5 When the Mobility Group Name is configured, choose System > Mobility Groups from the left sidebar menu. The selected controller's mobility list appears (see Figure 36).

Figure 36 Mobility Group Window

Step 6 To add members to the list, choose Add Group Members... from the Select a command drop-down menu and click GO. All of the controllers WCS is managing that are not in the individual controller's list are displayed.

Step 7 Click the check box to the left of desired controllers and click Save.

Note To perform this operation across multiple controllers, use the WCS controller template feature. This feature (Configure > Controller Templates) forwards identical configurations to a group of controllers simultaneously.

Step 8 Choose System > Interfaces to ensure that all controllers share the same virtual interface address (see Figure 37).

Figure 37 System > Interface Window

Step 9 To change the value so that all controllers have the same address, click on the link under the Interface Name column. Change the address and click Save.

Note Note: This value must be a non-routed address and must be identical across all controllers in the mobility group.

Step 10 Return to the main list of controllers by choosing Configure > Controllers. Ensure that all other necessary controllers are properly configured with identical Mobility Group Names and have all other controllers in the group in their Mobility Lists. Also, ensure that all controllers share the same Virtual Interface address.

Configuring Asymmetric Mobility from the WLC GUI

Follow these instructions to configure basic, asymmetric mobility tunneling from the WLC GUI.

Step 1 Choose the Controller tab at the top of the screen. The General heading is shown initially (see Figure 38). Ensure that the Default Mobility Domain Name value is consistent across all necessary controllers.

Figure 38 WLC General Window

Step 2 Choose Mobility Management under the Controller tab. Click Mobility Groups and make sure that all controllers have MAC and IP addresses in the controller's mobility lists (see Figure 39).

Figure 39 Static Mobility Group Members Window

Step 3 Perform one of the following:

•Click New from the upper right-hand corner to add a single controller. Enter the controller information and click Apply.

or

•Click Edit All from the upper right-hand corner to add multiple controllers.

Step 4 Choose the Interfaces heading under the Controller tab to ensure that all WLCs have the same virtual interface address (see Figure 40).

Figure 40 Interfaces Window

Step 5 If changes are necessary, click Virtual in the Interface Name column and make the necessary changes. Click Apply.

All controllers are now properly configured for regular mobility.

Verifying Asymmetric Mobility Operation

Follow these WLC CLI instructions to verify that basic, asymmetric mobility is operational.

Note To properly trigger the asymmetric mobility tunneling feature (as well as the new Symmetric Mobility Tunneling feature), controllers must be across routed boundaries. If controllers are on the same subnet, then mobility events are not invoked. The client record is simply moved to the next controller, and traffic flows natively to and from that new controller (refer to the "Background on Mobility in Cisco's Unified Wireless Network" section for a more in-depth discussion of mobility operations).

Follow the previous configuration steps to ensure correct configuration. Use the controller CLI to view the mobility configuration.

(Cisco Controller) >show mobility summary

Symmetric Mobility Tunneling (current) .......... Disabled

Symmetric Mobility Tunneling (after reboot) ..... Enabled

Mobility Protocol Port........................... 16666

Mobility Security Mode.......................Disabled

Default Mobility Domain.......................... test

Mobility Keepalive interval...................... 10

Mobility Keepalive count......................... 3

Mobility Group members configured................ 2

Controllers configured in the Mobility Group

MAC Address IP Address Group Name Status

00:16:9d:ca:dc:c0 10.10.10.10 <local> Up

00:19:07:24:12:e0 20.20.20.20 test Up

The simplest indicators of proper mobility configuration are two ping variants run between controllers. To verify that configuration is sound and the intermediary network is properly forwarding the necessary traffic, run both the eping and mping commands from the CLI. Use the following command to test the operation of the EtherIP data tunnel between controllers.

Note To perform this operation across multiple controllers, use the WCS controller template feature. This feature (Configure > Controller Templates) forwards identical configurations to a group of controllers simultaneously.

Configuring Symmetric Mobility from the Controller GUI

Follow these steps to configure Symmetric Mobility Tunneling from the WLC GUI.