In this document Cisco TAC engineer "Michael Combs" has explained about Issue faced with CAC and channel utilization (CU) displayed on 792x series wireless handsets
Wireless Services Module (WS-SVC-WISM)
Is the channel utilization (CU) on the phone coming from the AP or is the phone itself deriving this number? When we see "network busy" on the phone, Does the phone CU derive this or is this part of CAC ?
The channel utilization (CU) information displayed on the 7925G in the site survey/neighbor list is a metric derived from the AP. The handset is extracting this information from the appropriate IE in the beacons and probe responses for the BSSID in question. Specifically in the 'QBSS Load' IE section for each of these respective 802.11 management frames.
When correlating this to call admission control (CAC), a high CU, low medium time (MT) availability, TSPEC/EDCA mismatch, and a list of other potential TSPEC/CCX related issues can all lead to a 'Network Busy' error and subsequent TSPEC rejection for the handset.
The best means of isolating the root cause of a CAC/TSPEC rejection is to gather an over-the-air (OTA) packet capture of this issue, while also running the following debug commands on the WLC in question:
- debug client <MAC_addr>
- debug cac all enable
The command debug client <MACADDRESS> is a macro that enables eight debug commands, plus a filter on the MAC address provided, so only messages that contain the specified MAC address are shown. The eight debug commands show the most important details on client association and authentication. The filter helps with situations where there are multiple wireless clients. Situations such as when too much output is generated or the controller is overloaded when debugging is enabled without the filter.
The information collected covers important details about client association and authentication (with two exceptions mentioned later in this document).
The commands that are enabled are shown in this output:
(Cisco Controller) >show debug MAC address ................................ 00:00:00:00:00:00
Debug Flags Enabled:
dhcp packet enabled.
dot11 mobile enabled.
dot11 state enabled.
dot1x events enabled.
dot1x states enabled.
pem events enabled.
pem state enabled.
These commands cover address negotiation, 802.11 client state machine, 802.1x authentication, Policy Enforcement Module (PEM), and address negotiation (DHCP).
Debug Client Variations
For most scenarios, the debug client <MACAddress> command is enough to get the information needed. However, here are two important situations where additional debugging is needed:
In this situation, mobility debugs need to be enabled after the debug client <MACAddress> command has been introduced in order to gain additional information on the mobility protocol interaction between controllers.
Note: Details on this output will be covered in future documents.
In order to enable mobility debugs, use the debug client <MACAddress>, and then use the debug mobility handoff enable command:
In order to troubleshoot the interaction between the WLC and the authentication server (external RADIUS or internal EAP server), use the command debug AAA all enable, which shows the required details. This command should be used after the debug client <MACAddress> command and can be combined with other debug commands as needed (for example, handoff).