This document describes how to configure the Radio Resource Management (RRM) in the Wireless LAN Controller (WLC) on AireOS to defer and disable off-channel scanning.
Contributed by Aaron Leonard, Cisco TAC Engineer.
Cisco recommends that you have knowledge of this topic:
Cisco AireOS WLC
The information in this document is based on an AireOS Wireless LAN Controller with one or more access points associated.
The information in this document was created from the devices in a specific lab environment. All of the devices used in this document started with a cleared (default) configuration. If your network is live, ensure that you understand the potential impact of any command.
RRM is a key feature of the Cisco Unified Wireless Network. The AP can monitor all 802.11 channels for rogue devices, noise and interference, as well as neighbor APs.
However, while the APs are performing off-channel scanning (typically, for 80 millisecond periods every 3 to 20 seconds), they cannot service clients on the channel they are serving. This will result in minor, intermittent delays or loss in packet delivery (from 0.05% to as much as 1.5% packet loss). For most clients, the performance impact is imperceptible; however, some unusually sensitive clients, if unable to transmit to the AP for 80 milliseconds, will roam away from the AP, or even disconnect from the network.
In such a situation, where client devices are highly intolerant of packet loss, one may need to configure RRM to defer off-channel scanning, or to disable RRM monitoring entirely. This article explains how to do that.
Off-Channel Scanning Defer
With Off-Channel Scanning Defer, if the the access point has sent or received any data traffic in the given Wireless Local Area Network (WLAN), in the specified user priorities, within the last <defer-time> milliseconds, the AP radio will refrain from performing its next off-channel scan.
By default, Off-Channel Scanning Defer is enabled for user priorities 4, 5 and 6, with a defer-time of 100 milliseconds. Thus, if there is a voice call active (which typically uses a User Priority (UP) of 6 with a sample duration of 20 milliseconds), this will prevent the AP radio from going offchannel.
Disabling RRM Off-Channel Monitoring
RRM Off-Channel Monitoring can be entirely disabled. This will require that Dynamic Channel Assignment (DCA) be disabled, Transmit Power Control (TPC) be set to Fixed, and will prevent rogue detection from working. This will cause the APs to never do off-channel scanning (unless BLE Beacon Detection is enabled.)
Disabling CleanAir BLE Beacon Detection
On an AP that supports CleanAir (such as 2700 or 2800 series), if BLE Beacon Interference Detection is enabled, then the 2.4GHz radio will perform off-channel scanning (even if RRM Off-Channel is disabled). So, disable this feature, if the application requires that the 2.4GHz radio never go off-channel.
Configure Off-Channel Scanning Defer
Graphical User Interface (GUI)
In the GUI of the WLC the settings are in the Advanced tab under the specific WLAN. In this example, Off-Channel Scanning Defer is enabled for all user priorities, 0 through 7, and the defer-time is increased to 10,000 milliseconds (10 seconds). As a result, off-channel scanning will be deferred if there is any user traffic sent or received in this WLAN, on this AP, within the last 10 seconds.
Command Line Interface (CLI)
In the CLI of the WLC these commands are used to enable Off-Channel Scanning Defer for all prioritites and to set defer-time to 10,000 milliseconds, on WLAN 2:
CLI commands to view off-channel events or the absence of off-channel events on an AP:
On a IOS AP:
debug dot11 dot11radio <0|1> trace print drvpsp
On a AP-COS AP:
debug dot11 info
debug rrm off-channel deferral
Simultaneously collect all of:
a non-promiscuous driver-layer packet capture from the client under test
an over-the-air packet capture from the AP's serving channel
the above debugs, from the AP CLI
a wired packet capture from the AP's switchport
See whether and when traffic is being delayed/lost between the client driver and the AP's switchport. Examine the AP's debug output to see whether the AP was offchannel at the time of the traffic loss. If so, then evaluate the traffic patterns (traffic periodicity and QoS priority) and set the scan deferral priorities and time to defer scanning accordingly.