Coverage Hole Detection and Mitigation

Coverage Hole Detection and Mitigation (CHDM) is a Cisco RRM feature whose purpose is to alert the network administrator about actual coverage issues. The detection of coverage holes is based on the wireless clients' RSSI levels seen by the AP. The mitigation will increase the AP transmit power to help the clients at the edge of the cell.

The mitigation can automatically remediate actual coverage hole issues. But in some cases, the mitigation may not be permanently effective. When a coverage hole is detected, the area probably needs to be checked. A better solution could be some re-design to relocate or to add more APs. In other cases, the coverage alerts may be caused by specific wireless clients having roaming issues.

The Coverage Hole Algorithm (CHA) runs locally on the controller, independently of the RF Group leader. In contrast, other RRM features such as TPC and DCA, are dependent on the RF Group leader.

Before AireOS 5.0 version, the Coverage Hole Algorithm was comparing the clients’ SNR to a SNR threshold calculated with the following formula

From AireOS 5.0, the new CHDM algorithm is only based on the Client received RSSI.

The AP radio interface maintains a CHD measurement, which is a 5-seconds histogram of the received RSSI values for each client. The histogram of 31 values indicates the number of packets that are received from the client at a specific RSSI from -90 dBm to -60 dBm, for the last 5 seconds. Any of the packets received at a RSSI below -90 dBm is counted as part of the -90 value, and any of the packets received at a RSSI above -60 dbm is counted as part of the -60 value.

Voice and Data packets are also tracked separately based on the received WMM User Priority.

A coverage hole pre-alarm event is triggered by the AP if the 5-seconds histogram falls below the configured RSSI threshold, meaning when:

  • A minimum number of packets (50 packets) is below the RSSI threshold (-80 dBm)

  • AND a minimum percentage of packets (50% of the packets) is below the RSSI threshold (-80 dBm)

If both the minimum of number and the percentage of packets fail the RSSI, the client is considered to be in a coverage hole pre-alarm. Those conditions reduce the number of false positive alerts that are triggered by non-quantitative samples.

When a client is in pre-alarm, an IAPP message is immediately sent from the AP to the associated controller. This message is sent to the controller adopting the AP, and not the controller chosen to manage RRM.

The following flow chart diagram illustrates the process on the AP:

Coverage hole pre-alarm detection on the AP

Note that the process could be more complex than my simplified flow diagram. The IUWMS Quick Reference guide describes a pre-alarm as when a client meets the pre-alarm conditions for more than 6 times (30 seconds) over 90-seconds.

You can notice the coverage hole pre-alarm events in the WLC traplogs:

Thu Aug 10 21:57:20 2017 Coverage hole pre alarm for client[1] ec:9b:f3:32:f1:40 on 802.11a interface of AP 00:6b:f1:87:2a:77 (LAP1). Hist: 0 0 11 8 12 28 94 213 10 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0

The histogram can be read from left to right with the number of received packets at a RSSI from -90 dBm to -60 dBm. In the example above, there are 11 packets from the client at a RSSI of -88 dBm.

CHD 5-seconds measurement

The pre-alarm is reported to the controller but no action is directly taken by the controller. Pre-alarms are only informative.

In addition, every 90 seconds (actually 85 seconds from debugging), the AP sends a CHD aggregate report including the histograms for all its clients to the controller. For each client, the WLC checks the pre-alarm conditions and sets the coverage status of the client to failed if the pre-alarm status persists for the last 90 seconds.

After checking all the AP’s clients, the controller reports a coverage hole event when:

  • The number of failed clients is equal or above this threshold. 3 clients by default (Minimum Failed Client Count).

  • AND the percentage of failed clients is equal or above 25% by default (Coverage Exception Level per AP).

Both conditions must be met to trigger a coverage hole alert and to consider mitigation. When the coverage hole report is confirmed, the controller mitigates the coverage hole by increasing the AP radio transmit power by one level, unless the radio has already reached its maximum transmit power.

The controller will also evaluate the client RSSI seen from the other APs. If any other AP can hear such a client above the RSSI threshold, the report is cancelled. This prevents some false positive alerts that could have been caused by sticky clients with poor roaming logic. This could be many alerts only triggered by specific wireless clients, in which case, the clients may also be investigated (driver, radio settings) or moved to a WLAN without CHDM enabled.

The process resets the client histograms and reiterates on the controller every 90 seconds.

Coverage hole detection on the WLC

You can notice the coverage hole alerts in the WLC traplogs:

Thu Aug 10 21:32:59 2017 Coverage Hole Detected for AP LAP1 whose Base Radio MAC is 00:6b:f1:87:2a:77. Number of Failing Clients 3

Thu Aug 10 21:32:59 2017 RF Manager updated TxPower for Base Radio MAC: 00:6b:f1:87:2a:77 and Radio Type: 802.11a New Tx Power is: 5

When the coverage hole conditions are not met anymore, the coverage hole alarm is cleared:

Thu Aug 10 21:34:25 2017 Coverage hole cleared for Base Radio MAC: 00:6b:f1:87:2a:77 and slotNo: 1

CHDM configuration and debugging

CHDM is enabled globally per radio band on the controller and on a per-WLAN basis by default.

To enable/disable globally CHDM on the controller:

(WLC) >config advanced {802.11a | 802.11b} coverage {enable | disable}

Using GUI:

In WIRELESS | 802.11a/n/ac or 802.11b/g/n | RRM | Coverage, enable/disable Coverage Hole Detection.

To check if CHDM is enabled or disabled globally on a controller:

(WLC) >show advanced {802.11a | 802.11b} coverage


Coverage Hole Detection

  802.11a Coverage Hole Detection Mode........... Enabled

Then the feature is also enabled on each WLAN by default.

To enable/disable CHDM per WLAN:

(WLC) >config wlan chd WLAN-ID {enable | disable}

Using GUI:

In WLANs | WLANs | <WLAN ID> | Advanced tab, enable/disable Coverage Hole Detection.

To verify if CHDM is enabled per WLAN:

(WLC) >show wlan WLAN-ID

CHD per WLAN.................................. Enabled

If CHDM is disabled on a WLAN, the coverage hole alerts are still sent to the controller, but there is no mitigation. For example, CHD may be disabled on Guest WLAN because of unknown/unmanaged wireless clients.

The controller allows some fine-tuning to reduce the number of false positives and to adjust to the environment. Those parameters can be specific per-band, per type of traffic (Data or Voice). Some of them can be overridden in a RF Profile.

Here are the threshold values (per band) for the CHD 5-seconds measurement and for the pre-alarm detection:

  • (Data or Voice) Failed Packet Percentage: coverage failure rate threshold for the uplink packet. 50% for Data and Voice packets by default.

  • (Data or Voice) Failed Packet Count: coverage minimum failure count threshold for uplink packets. 100 packets for Voice packets, and 50 packets for Data packets by default.

  • (Data or Voice) Coverage RSSI Threshold: minimum receive coverage level for uplink packets. -80 dBm for Data and Voice packets by default.

And there are 2 threshold parameters (per band) that can be configured for the coverage hole alarm detection:

  • Coverage Exception Level: percentage of failed clients on the AP over a 90-second period. 25% by default.

  • Client Minimum Exception Level: number of failed clients on the AP over a 90-second period. 3 by default.

To specify the CHDM parameters using CLI:

(WLC) >config advanced {802.11a | 802.11b} coverage {data | voice} fail-percentage PERCENT


(WLC) >config advanced {802.11a | 802.11b} coverage {data | voice} packet-count NUM-PACKETS


(WLC) >config advanced {802.11a | 802.11b} coverage {data | voice} rssi-threshold DBM


(WLC) >config advanced {802.11a | 802.11b} coverage exception global PERCENT


(WLC) >config advanced {802.11a | 802.11b} coverage level global CLIENTS

To verify the actual thresholds for CHDM:

(WLC) >show advanced {802.11a | 802.11b} coverage


Coverage Hole Detection

  802.11a Coverage Hole Detection Mode........... Enabled

  802.11a Coverage Voice Packet Count............ 100 packets

  802.11a Coverage Voice Packet Percentage....... 50%

  802.11a Coverage Voice RSSI Threshold.......... -80 dBm

  802.11a Coverage Data Packet Count............. 50 packets

  802.11a Coverage Data Packet Percentage........ 50%

  802.11a Coverage Data RSSI Threshold........... -80 dBm

  802.11a Global coverage exception level........ 25 %

  802.11a Global client minimum exception lev.... 3 clients

Using GUI

In WIRELESS | 802.11a/n/ac or 802.11b/g/n | RRM | Coverage, specify the parameters under the Coverage Thresholds section.

You can also configure SNMP Trap logs and System message logs related to CHDM.

The SNMP Trap logs are enabled for CHDM by default.

(WLC) >config trapflags rrm-profile coverage {enable | disable}


(WLC) >config trapflags rrm-params tx-power {enable | disable}


(WLC) >show trapflags

Auto-RF Profiles

        Load............................................ Enabled

        Noise........................................... Enabled

        Interference.................................... Enabled

        Coverage........................................ Enabled


Auto-RF Thresholds

        tx-power........................................ Enabled

        channel......................................... Enabled

The System message logs (Syslog) are disabled for CHDM by default.

(WLC) >config advanced {802.11a | 802.11b} logging coverage {on | off}


(WLC) >show advanced {802.11a | 802.11b} logging

RF Event and Performance Logging

  Channel Update Logging......................... Off

  Coverage Profile Logging....................... Off

  Foreign Profile Logging........................ Off

  Load Profile Logging........................... Off

  Noise Profile Logging.......................... Off

  Performance Profile Logging.................... Off

  TxPower Update Logging......................... Off

Finally you can enable some useful debug commands to troubleshoot issues related to CHDM:

(WLC) >debug airewave-director prealarm enable


(WLC) >debug airewave-director profile enable


(WLC) >debug airewave-director power enable


(WLC) >debug airewave-director detail enable


(WLC) >debug iapp packet enable

In the following example, a CHD aggregate report shows 3 clients failing the pre-alarm conditions and triggers a coverage hole alert:

*iappSocketTask: Aug 10 21:32:59.973: CCX: Received CHD aggregate report 00:6B:F1:87:2A:77 00:6B:F1:87:2A:77

*apfMsConnTask_4: Aug 10 21:32:59.973: Processing Client Stats Data

*apfMsConnTask_4: Aug 10 21:32:59.973: Received client stats data  for client :  EC:9B:F3:32:F1:40     AP  00:6B:F1:87:2A:77

*apfMsConnTask_4: Aug 10 21:32:59.973:    Pkts Rx  : 1843     Pkts Tx : 1707     Bytes Rx : 145111    Bytes Tx : 133048

*apfMsConnTask_4: Aug 10 21:32:59.973: Failed Link Status , prealarm event ....

*apfMsConnTask_4: Aug 10 21:32:59.973: Processing Client Stats Data

*apfMsConnTask_4: Aug 10 21:32:59.973: Received client stats data  for client :  98:5F:D3:BB:35:E8     AP  00:6B:F1:87:2A:77

*apfMsConnTask_4: Aug 10 21:32:59.973:    Pkts Rx  : 3077     Pkts Tx : 741     Bytes Rx : 159196    Bytes Tx : 71764

*apfMsConnTask_4: Aug 10 21:32:59.973: Failed Link Status , prealarm event ....

*apfMsConnTask_4: Aug 10 21:32:59.973: Processing Client Stats Data

*apfMsConnTask_4: Aug 10 21:32:59.973: Received client stats data  for client :  00:C0:AF:25:A7:10     AP  00:6B:F1:87:2A:77

*apfMsConnTask_4: Aug 10 21:32:59.973:    Pkts Rx  : 1760     Pkts Tx : 1702     Bytes Rx : 136016    Bytes Tx : 132728

*apfMsConnTask_4: Aug 10 21:32:59.973: Failed Link Status , prealarm event ....


*RRM-DCLNT-5_0: Aug 10 21:32:59.973: Airewave Director: Building client coverage data on 802.11a AP 00:6B:F1:87:2A:77(1)

*RRM-DCLNT-5_0: Aug 10 21:32:59.973: [CHD]: chdDataFalsealarmCount/chdVoiceFalsealarmCount (0/0)

*RRM-DCLNT-5_0: Aug 10 21:32:59.973: [CHD]: Actual failed client count = 3

*RRM-DCLNT-5_0: Aug 10 21:32:59.973: [CHD]: Coverage Stats || Failed Clients: 3, Client Threshold: 3, Client Exception Level: 25, Total Clients of Radio: 3, Actual Failed Clients: 3

*RRM-DCLNT-5_0: Aug 10 21:32:59.973: [CHD]: Coverage failure status = 1, clients 3 level 25

*RRM-DCLNT-5_0: Aug 10 21:32:59.973: Airewave Director: Coverage profile violation on 802.11a AP 00:6B:F1:87:2A:77(1)

*RRM-DCLNT-5_0: Aug 10 21:32:59.974: [CHD] Airewave Director: Coverage Hole Check on 802.11a AP clients 3 level 25 00:6B:F1:87:2A:77(1)

*RRM-DCLNT-5_0: Aug 10 21:32:59.974: [CHD]: failed/totalClientCount/threshold (3/3/3)


You can check the number of failed clients in the AP Radio information details:

(WLC) >show ap auto-rf 802.11a LAP1


AP Name.......................................... LAP1

  Coverage Information

    Coverage Profile............................. FAILED

    Failed Clients............................... 3 clients

With AireOS 8.0, Cisco introduces Optimized Roaming. This new feature uses the same CHDM Data RSSI Threshold to disassociate a wireless client if the RSSI fails. Mutually exclusive, Optimized Roaming requires to disable CHDM on the WLAN. In addition, 802.11v Wireless Network Management amendment which is another new feature, extends Optimized Roaming by sending a BSS Transition Request to the client instead of a disassociation. Those two new features aim to improve roaming on the clients using the CHDM settings rather than solving the coverage hole issue on the AP.

Additional Resources

Cisco Radio Resource Management White Paper:

Cisco Wireless Controller Configuration Guide, Release 8.3:

CCNP Wireless (642-747 IUWMS) Quick Reference guide:

The comprehensive blog “mrncciew” for CCIE Wireless studies, Configuring Coverage Hole Detection (CHD):

Difference between Coverage hole and Pre-coverage hole, Cisco Support Community:

Exploring DTPC and 802.11h Transmit Power Control

This article describes several wireless features to control the transmit power of wireless clients, along with some examples.

When designing, surveying or troubleshooting a wireless network, it is ideal to know the wireless clients and specifically their transmit powers.

In some cases, a mismatch of transmit power between an access point and a client can create network performance issues. A classic scenario is an access point with very strong transmit power. A packet sent by the access point will be received by a wireless client but a packet sent by a wireless client with less transmit power may not reach the access point. Matching transmit power could prevent one-way audio in Voice-over-IP.

Moreover, limiting the transmit power of the clients may help to reduce co-channel interference and to improve the network capacity, especially in high density environments.

A radio driver determines the transmit power of a wireless frame based on several factors including:

  • The radio hardware capability.

  • The regulatory domain: one or multiple country may be defined on the radio and will enforce a maximum allowed power for compliance with the regulations of the country.

  • The operational frequency: the transmit power may vary by band (2.4 GHz, 5 GHz) and subband (UNII1, UNII2, UNII2-Ex, UNII3).

  • The data rate and/or the modulation technique: the transmit power usually depends on the modulation technique (DSSS, CCK, OFDM, HT-20, HT-40) and the data rate of the transmission. Lower data rates generally have higher transmit powers than higher data rates.

  • Additional power constraints: Cisco proprietary DTPC feature minimizes power consumption and can save battery by limiting the transmit power of CCX clients to the transmit power of the access point radio. Similarly, the IEEE 802.11h amendment has a Power Constraint element to control the maximum transmit power of a client.

Standard 802.11d – and Cisco world-mode implementation

IEEE 802.11d-2001 is the 802.11 amendment that provides regulatory domain information. When enabled, a Country information element is added to the beacons and probe responses. With this element, the wireless clients can learn about the domain in term of allowed channels and maximum transmit output and can maintain compliance with the regulations of the country.

The Country element (IE number 7) contains the following information:

  • Country string: 3 octets value to indicate the regulatory domain (for example, AU – Australia). The third octet indicates if the regulations are for indoor, outdoor or both environments.

  • One or several consecutive subband triplets:

    • First Channel Number/Operating Extension Identifier: the lowest channel number of the subband.

    • Number of Channels/Operating Class: the number of channels defining the subband, starting from the first channel number.

    • Maximum transmit power level/Coverage Class: this value in dBm is an indication of either the maximum Transmit Power Output send to the antenna (TPO) or the Effective Isotropic Radiated Power (EIRP) depending on the implementation and the value of the country code.

Associated clients will limit their transmit power to the maximum value allowed for the country in the current channel.

On WLC, 802.11d is enabled by default using the country code provided at the initial WLC setup.

To change the controller’s country code:

(WLC) >config country CODE

Where the value CODE is the two-character ISO country code.

To verify the country code on a WLC:

(WLC) >show country

Configured Country............................... AU  - Australia

Using GUI:

In WIRELESS | Country, select the Country Code.

For example, when using the country code for Australia (ISO code AU), the beacon and probe response frames include the following Country element.

On an autonomous Cisco access point, IEEE 802.11d is disabled by default. You can enable it using the world-mode radio interface command:

AAP(config)#interface dot11Radio {0 | 1}

AAP(config-if)#world-mode dot11d country-code CODE {both | indoor | outdoor}

Regulatory information can restrict differently based on the access point’s location (indoor, outdoor or both).

For example, to enable 802.11d with Australia as a country code on 5GHz radio interface:

AAP(config)#interface dot11Radio 1

AAP(config-if)#world-mode dot11d country-code AU both

Selected country Australia

The world-mode legacy command is only useful for Cisco Aironet 350/CB20 NICs using earlier software versions that didn’t support 802.11d yet.

The GUI allows to enable 802.11d but the country code cannot be set (bug?).

In NETWORK | NETWORK INTERFACE | Radio1-802.11N 5GHz | Country Code section, you can only enable Dot11d.

On a captured Beacon frame, the Country element concatenates regulatory information from different subbands (UNII1, UNII2, UNII2-EX, UNII3):

You can verify the work-mode configuration from the running-configuration or the GUI.

Note that since the 1st of January 2015, manufacturers have been required by the FCC that non-SDR wireless clients do not rely on 802.11d for enforcing regulatory domains. [1]

Cisco Dynamic Transmit Power Control (DTPC)

DTPC is a Cisco proprietary feature which is part of the CCX program. When enabled on the global radio settings, Cisco access points advertise their channel and transmit power level in the beacons and probe responses. CCXv2 clients will automatically adjust their transmit power to the same level as the access point. For example, Cisco wireless phones from 7920 to 8821 series support DTPC.

This feature is particularly useful for the following reasons:

  • DTPC saves energy for low-powered devices which increases battery life.

  • DTPC reduces co-channel interference resulting from the client themselves. This is particularly true for high density environment.

  • DTPC can contribute to prevent a transmit power mismatch between the access point and the CCX client. Voice-over-IP will benefit from it.

On a WLC, DTPC is enabled by default. DTPC can be enabled/disabled per band in 2.4 GHz and for 5 GHz global settings. When enabled, it will transmit a vendor specific DTPC element (IE number 150) in the beacon and probe response frames.


config {802.11a | 802.11b} dtpc {enable | disable}

In addition, Aironet Extensions must also be enabled on the WLAN to support DTPC.

config wlan ccx AironetIeSupport enable 1


In WIRELESS | 802.11a/n/ac | Network | Advanced tab, enable Aironet IE.

In WLANs | WLANs | <WLAN ID> | General section, enable DTPC Support.

With DTPC enabled, access points advertise their transmit power in beacons and probe responses. The following picture shows the DTPC Information Element (IE number 150) captured in a beacon frame.

In this example, the access point transmit power was set to 19 dBm = 0x13 in hexadecimal. An associated CCX wireless client will limit its own transmit power to the access point’s transmit power.

To verify if DTPC is enabled:

(WLC) >show {802.11a | 802.11b}

DTPC  Status..................................... Enabled


(WLC) >show wlan 1

CCX - AironetIe Support.......................... Enabled

Let’s see an example of DTPC using a Samsung S5 mobile phone (CCX) and a Cisco 2700 access point. During this test, ICMP traffic was transmitted between the two devices. The frequency was set to 5745 MHz (channel 149) and the supported data rate was limited to 24Mbps only. Between each association, the access point transmit power level has been incremented from level 8 (2 dBm) to level 1 (23 dBm).

The RSSI of the access point frames (in blue) shows that the access point transmit power was increasing with time. The averaged RSSI of the mobile phone frames (in red) was constant at -60 dBm while the AP power was between 2 dBm and 8 dBm. When the AP power increased between 8 dBm and 14 dBm, the RSSI of the S5 frames increased up to -53 dBm. When the AP power was above 14 dBm, the RSSI of the S5 was capped at -53 dBm with no growth.

To explain this, the CCX client set its power accordingly to the access point transmit point within the client transmit power capabilities. In this example, when the access point transmit power is greater than 14 dBm, the S5 transmit power has reached its maximum. In other words, there is no more performance gain in the direction to the access point when the access point transmit power is above 14 dBm with a Samsung S5 at a data rate of 24 Mbps.

On an autonomous Cisco access point, DTPC is disabled by default and can be configured with the following radio interface command:


AAP(config)#interface dot11Radio {0 | 1}

AAP(config-if)#power client local

Notice again that Aironet extensions must be enabled to limit the power level on associated client devices. Aironet extensions are enabled by default.

AAP(config)#interface dot11Radio {0 | 1}

AAP(config-if)#dot11 extension aironet

Using GUI:

In NETWORK | NETWORK INTERFACE | Radio0-802.11N 2.4GHz, set Client Power (dBm) to Local.

The DTPC IE will be included and will match the transmit power configured for the access point radio interface.

With the IOS autonomous mode, the power client command has an extra feature. The client power can be set to any power level from -127 dBm  to 127 dBm or to the client maximum transmit power, regardless of the access point transmit power (actually limited to the maximum allowed transmit power of the access point) using the following command:

AAP(config)#interface dot11Radio {0 | 1}

AAP(config-if)#power client {-127 - 127 | maximum}

The feature uses the same DTPC IE but this time, the client power can be changed without matching the access point transmit power. This command offers a better precision in unit of dBm.

In a second example, using the same test conditions (Samsung S5, autonomous Cisco 2700 access point, channel 149, 24Mbps data rate only), the client power has been incremented from 6 dBm to 22 dBm between each association.

The RSSI of the access point frames (in blue) shows that the access point transmit power was constant. The averaged RSSI of the S5 frames (in red) increased and reached a plateau. We can see more precisely that the Samsung S5 reached its maximum transmit power at a data rate of 24 Mbps when the DTPC IE value is above 13 dBm.

802.11h – TPC Power Constraint

802.11h-2003 was an amendment called “Spectrum and Transmit Power Management Extensions in the 5GHz band in Europe” which later became enforced worldwide by both the ETSI and the FCC. Its purpose is to adjust the WLAN in order to co-exist with satellite and radar communications sharing the same frequency range.

802.11h operations consist of 2 mechanisms:

  • Dynamic Frequency Selection (DFS): to detect radar systems and to avoid co-channel operations. If the radio detects a radar signal on its operational channel, it must stop using the channel for 30 minutes and will move to another channel after checking that the new channel is free of radar for 1 minute. This mechanism is mandatory for UNII2 channels (52, 56, 60, and 64) and UNII2-EX channels (100, 104, 108, 112, 120, 124, 128, 136, and 140).

  • Transmit Power Control (TPC): to enforce an additional power constraint in dBm and to reduce the interference with satellite services. The access point and its wireless clients will ensure that they cannot transmit over the maximum regulatory transmit power minus the power constraint. This mitigation mechanism is optional.

The IEEE 802.11h mechanisms are carefully considered for outdoor wireless deployments, especially near airports, maritime ports and weather radars.

Looking at TPC specifically, a power constraint can be used to limit the transmit power of mesh access points associating to root access points for example. 802.11h Power Constraint can be configured for 5GHz radios only. When enabled, it will transmit the Power Constraint element (IE number 32) in the beacon and probe response frames.

802.11h TPC also requires the Country element. In fact the wireless client determines its local maximum transmit power with the combination of the local maximum transmit power in the Country element and the power constraint according to the following formula:

On a WLC, you can set a power constraint of 10 dB with the following command:

(WLC) >config 802.11h powerconstraint 10


Power constraint value set.

Note that DTPC and 802.11h Power Constraint are mutually exclusive. They cannot be enabled simultaneously.

If you try to modify the power constraint while DTPC is still enabled, you will see the following error:

(WLC) >config 802.11h powerconstraint 10


802.11a Dynamic Transmit Power Control (DTPC) must be disabled before enabling 802.11h power constraint. Use 'config 802.11a dtpc disable' to disable the 802.11a DTPC.

Using GUI, you can configure 802.11h Power Constraint:

In WIRELESS | 802.11a/n/ac | DFS (802.11h) | Power Constraint tab, set Local Power Constraint to a value in dB.

To check the power constraint value:

(WLC) >show 802.11h


Power Constraint................................. 10

Channel Switch................................... Enabled

Channel Mode..................................... Quiet

The following picture shows the Power Constraint element captured in a beacon frame.

The access point informs the client of a power constraint of 10 dB. The constraint will be applied from the maximum transmit power allowed by the regulatory domain, and not from the transmit power of the access point (which is unknown by the client with TPC). If the maximum power allowed by the domain is 23 dBm, the client will limit its power to 23 – 10 = 13 dBm.

On an autonomous access point, a default power constraint of 3 dB is set on 5GHz radios when 802.11d is enabled and when the power client {-127 to 127 | local} command is not used.

In the next example, an iPhone 5S is used with the same access point setup with 802.11h Power Constraint instead of DTPC. Between each association with an iPhone 5S, the Power Constraint was decremented from 28 dB to 7 dB. The configuration was the same as the previous tests (24Mbps data rate, channel 149).

Again, the RSSI of the access point frames (in blue) shows that the access point transmit power was constant. The averaged RSSI of the iPhone frames (in red) increased and reached a maximum when the Power Constraint hit 12 dB. To find out the client transmit power, use the formula: the client transmit power is limited to the maximum transmit power level specified for the channel in the Country element minus the power constraint.

In a beacon, the Country element specified that the maximum transmit power level specified for channel 149 was 30 dBm. So with a Power Constraint of 12 dB, the maximum client transmit power of the iPhone 5S for 24Mbps would be 18 dBm.

But let's just be careful with those values. One step back on the interpretation of Maximum Transmit Power Level in the Country element, it can relate to the TPO or to the EIRP. In Australia, the maximum output powers are expressed in EIRP which means antenna gain must be taken into account.

802.11h - Power Capability and TPC Report

802.11h has also introduced two Information Elements, Power Capability (IE number 33) and Supported Channels (IE number 36) which are now in every Association Request and Reassociation Request frame (2.4GHz and 5GHz). The first one specifies the minimum and maximum transmit powers in dBm with which a wireless client is capable of transmitting in the current channel. The second contains the list of channel subbands in which the wireless client is capable of operating.

The following picture shows the two IEs in an Association Request of the iPhone 5S on 5GHz channel 149:

Finally 802.11h includes TPC Report element (IE number 35) which contains the transmit power information. The TPC Report can be in beacon and probe response frames and can also be requested to any station. The reply may be in the form of an Action frame containing the power used to transmit the response. You may see the following TPC Report element with other wireless vendor access points in conjunction with 802.11k:


In addition to technical documentation and FCC ID Search information, benchmarking the wireless clients may help to understand what the client behaviour is under specific requirements (country, radio band, channel, data rate, etc). Packet analysis helps me to find lots of useful information, including:

  • Supported subbands and channels: using Country element and Supported Channels element.

  • Maximum transmit power allowed by the regulatory domain: using Country element.

  • Maximum transmit power supported by the wireless client on the current channel: using Power Capability element.

  • Client transmit power limitation: using DTPC element or 802.11h Power Constraint element. Up to the maximum transmit power supported by the wireless client.

Using benchmarking results, the wireless network can be changed in order to optimise the performance. It is generally recommended to ensure that the transmit power of the access point is not greater than the maximum transmit power of the weakest client for the desired minimum data rate.

However matching transmit power makes sense in a world using same radios and isotropic radiators. Performance may be affected by many other factors such as the antenna gain, the radiation pattern, the radio received sensitivity, the noise, Dynamic Rate Shifting and roaming algorithms to name a few.

Additional resources

Cisco Enterprise Mobility 8.1 Design Guide:

Overview on 802.11h, Transmit Power Control (TPC) and Dynamic Frequency Selection:

TPC and DFS Overview, Cisco Support Community:

TPC vs DTPC vs World mode and 802.11h parameters:

[1] FCC 594280 D01 Configuration Control:

QBSS Load element

Let’s begin this first post with a specific part of Wi-Fi Quality of Service (QoS), the QBSS Load element.

I wanted to learn which roles QBSS takes in Voice over IP deployment, and how different the Cisco implementations are.

The actual name of this Information Element (IE) is BSS Load as referred in the IEEE 802.11-2012 standard. The original name QBSS Load (QoS Basic Service Set) comes from the 802.11e amendment which has introduced QoS for wireless application in 2005.

The element is advertised in every beacon and every probe response frame of a QBSS. Which means an access point must have WMM enabled to advertise QBSS Load IE.

The IE defines some QoS information about the load of the access point:

  • Station Count: total number of STAs currently associated with the access point radio.

  • Channel Utilization: percentage of time that the access point sensed the channel was busy, by either the physical or virtual carrier sense mechanisms. The value is linearly contained into 1 octet, from 0 to 255, the highest value meaning 100% busy.

  • Available Admission Capacity: remaining amount of medium time used for admission control (2 octets long, in unit of 32 μs/s).

BSS Load element format. Source: IEEE Std 802.11™-2012

There are 3 different versions of the QBSS Load element which Cisco has implemented on wireless access points. Let’s get into the details for lightweight and autonomous access points.

Cisco proprietary QBSS Load – version 1 – non-CCA

The legacy version of QBSS is a Cisco proprietary feature based on the draft 6 of 802.11e. This feature was created before the ratification of 802.11e in 2005, so before WMM exists.

One difference with 802.11e is that the Channel Utilization value is expressed between 0 and 100, and not normalized to 255 as per-standard.

The QBSS Load V1 element is compatible with the earliest firmware releases of the Cisco 7920 phone. The 7920 is an old 802.11b wireless IP phone which does not support WMM. The 7920 determines the access point to associate, based on the RSSI and the Channel Utilization advertised by the access points.

For 7920 using QBSS Load V1, Cisco recommends to ensure that the Channel Utilization is less than 45. If the Channel Utilization is Channel Utilization is above 45% on all the potential access points, a "Network Busy" message will appear and the phone will not be able to make a call.

On a WLC, the feature is called 7920 Client CAC because the legacy 7920 handles the admission control. The QBSS Threshold can be changed temporarily on the phone via a hidden menu.

Configure QBSS Load V1 on a WLAN of a WLC with the following CLI commands:

At first, ensure that WMM is disabled on the WLAN as it is not supported with QBSS Load V1 (see the explanation later).

(WLC) >config wlan wmm disable <WLAN_ID>

Enable 7920 Client CAC support on the WLAN.

(WLC) >config wlan 7920-support client-cac-limit enable <WLAN_ID>

Using the GUI:

In WLANs | WLANs | <WLAN ID> | QoS tab, set WMM Policy to Disabled and enable 7920 Client CAC.

Notice that WMM and 7920 Client CAC are mutually exclusive. If you try to enable both at the same time, you will get the following error message. You will see the reason in the next section.

After enabling QBSS Load V1, it appears on the beacon and probe response frames in the Information Element 11. On the picture below from the packet capture of a beacon, there are 2 wireless stations associated to the access point, and the Channel Utilization is 1%.

A bigger difference with 802.11e is that the value for the Channel Utilization in QBSS Load V1 ONLY depends on the 802.11 traffic load on the access point. During some tests, when there was no data traffic (Tx Load, Rx Load) on the access point, the QBSS load element showed 1% of Channel Utilization. When an IPerf throughput test was running between the 2 stations to increase the network throughtput, the Channel Utilization went up to 66% (hexadecimal 0x42).

In another test, an IPerf test was done on the same channel via another access point with different stations to consume airtime near the original access point. On the access point with QBSS Load V1 and with no associated stations, the Channel Utilization stays low at 1% while the radio resource on the frequency is severely used. QBSS Load V1 Load does not vary with the physical carrier sense energy detection.

On an autonomous Cisco access point, you can enable the Draft 6 QBSS-Load IE with the following CLI command:

AAP(config)#dot11 phone

Regarding WMM, you can leave it enabled (by default) or disable it. The first option advertises beacons with both the QBSS Load V1 IE-11 and the WME IE-221 element, without QBSS element. Not properly WMM compliant.

AAP(config)#interface dot11Radio 0

AAP(config-if)#no dot11 qos mode wmm

Or via the GUI:

In SERVICES | QOS | ADVANCED tab, set QoS Element for Wireless Phones to Enable.

802.11e standard-based QBSS Load – version 2 - CCA

This second version of QBSS is based on the IEEE 802.11e-2005 amendment, with the format described in the introduction.

The value of Channel Utilization is between 0 and 255 as per-standard: 255 equal 100%. To obtain the Channel Utilization percentage, convert the Channel Utilization value from hexadecimal to decimal and divide by 255.

The percentage is defined in the standard by the formula:


  • channel busy time is defined to be the number of microseconds during which the CS mechanism has indicated a channel BUSY indication.

  • dot11BeaconPeriod is the interval in number of TUs (Time Unit 1024 µs) between Beacon frames that shall be scheduled by the AP. It is configurable by the AP but usually set to 102 TUs.

  • dot11ChannelUtilizationBeaconInterval represents the number of consecutive beacon intervals during which the channel busy time is measured. The default value of dot11ChannelUtilizationBeaconInterval is 50 in the standard.

Using the default values, the Channel Utilization is computed as a percentage of busy airtime for the last 5 seconds approximately.

More importantly, the Channel Utilization depends on the physical (CCA) or virtual (NAV) carrier sense mechanisms. Any radio energy detected by CCA (incoming Wi-Fi preamble detected by CCA-CS or non-Wi-Fi energy detected by CCA-ED) will be factored in the Channel Utilization.

On a WLC, you simply have to set WMM to Allowed or Required on the WLAN in order to automatically advertise the 802.11e QBSS Load IE.

Using CLI:

(WLC) >config wlan wmm {allow | require} <WLAN_ID>

Using GUI:

In WLANs | WLANs | <WLAN ID> | QoS tab, set WMM Policy to Allowed or Required.

On the picture below captured from a beacon frame, the Channel Utilization value is hexadecimal 0x9d in the third octet, equal to 157/255 = 62%. Remember that using the 802.11e version, the Channel Utilization value is normalized to 255. Wireshark does this nicely for you.

Notice also that the 802.11e QBSS Load element takes exactly the same Information Element (IE-11) as the Cisco QBSS Load V1. This is the reason why they are mutually exclusive. Therefore in the WLC implementation, you can use either WMM or QBSS Load V1.

The 802.11e QBSS Load IE can be used on the Cisco wireless IP phones supporting WMM, such as Cisco 7921G, 7925G, 7526G and 8821.

The recommendation from Cisco deployment guides is to keep the Channel Utilization below 105 (105 normalized to 255 is approximately 41%). Depending on the firmware release, newer Cisco phones may or may not make their roaming decision based on the Channel Utilization (see Cisco bugID CSCtz46981 792x on 2.4 GHz utilizes QBSS for roaming decisions, or CSCvc52145 8821 Network Busy error). Latest versions seem to display only the Channel Utilization.

On an Autonomous access point, the implementation is a bit different from enabling WMM. You can enable the 802.11e QBSS IE with the following CLI command:

AAP(config)#dot11 phone dot11e

Or via the GUI:

In SERVICES | QOS | ADVANCED tab, set QoS Element for Wireless Phones to Enable and check the Dot11e option.

When enabling QoS Element for Wireless phone with Dot11e, both 802.11e QBSS Load IE and Cisco QBSS Load V2 (see next section) are both advertised by the access point.

Cisco proprietary QBSS Load – version 2 - CCA

In mixed environment with 7920 and newer wireless IP phones (7921G, 7925G, 7926G, 8821), QBSS Load V1 and 802.11e QBSS Load issued with WMM cannot work together using the same IE. To support mixed environment with WMM devices, Cisco has developed another proprietary QBSS Load element using vendor-specific IE 221 rather IE 11. The new IE is only supported on latest versions of 7920 firmware (2.01 or later).

The element uses the same information defined by the 802.11e standard. Channel Utilization is based on CCA and expressed from 0 to 255.

An access point can advertise at the same time both:

  • 802.11e QBSS Load IE11: supported by WMM phones

  • Cisco QBSS Load V2 IE221: supported by Cisco wireless IP phones including non-WMM 7920 upgraded with firmware 2.01 or later

On a WLC, you can enable Cisco QBSS Load V2 with the 7920 AP CAC feature using with the following CLI command:

(WLC)>config wlan 7920-support ap-cac-limit enable <WLAN_ID>


(WLC)>show wlan <WLAN_ID>

WMM.............................................. Allowed

Dot11-Phone Mode (7920).......................... ap-cac-limit

Using GUI:

In WLANs | WLANs | <WLAN ID> | QoS tab, set WMM Policy to Disabled and enable 7920 AP CAC.

On the picture below, you can see the QBSS Load V2 with the IE tagged 221. The Channel Utilization value is equal to 124/255 = 48%. You can also see a maximum threshold Call Admission Limit that is defined to 105/255 = 41% by default.

The QBSS Load V2 Load element adds this extra benefit. The maximum CU threshold is customizable and advertised by the access point. The AP can handle the admission control by adjusting the Call Admission Limit, hence 7920 AP CAC.

To change the Call Admission Limit on a WLC:

(WLC) >config advanced 802.11b 7920VSIEConfig call-admission-limit <0-255>

However in the event of Network Busy issues with 7920s, you should address a high Channel Utilization issue with troubleshooting and design with best practices (use 5GHz, disable lower data rates , lower the number of SSIDs, reduce CCI, etc) before fine-tuning the Call Admission Limit.

On an Autonomous access point, you can enable Cisco QBSS Load V2 IE using the same command which enables QBSS Load V1 IE. QoS Element for Wireless Phones enables both Cisco QBSS Load V1 and QBSS Load V2:

AAP(config)#dot11 phone

Or via the GUI:

In SERVICES | QOS | ADVANCED tab, set QoS Element for Wireless Phones to Enable.

When QoS Element for Wireless Phones is enabled, the access point will also create dynamic voice classifiers for RTP-based traffic, to allow a higher priority for voice traffic even if there is no QoS.

To change the maximum threshold for Channel Utilization on an autonomous AP:

AAP(config)#dot11 phone cac-thresh <0-255>

Where can we find the Channel Utilization?

You can perform a wireless packet capture. Beacon and Probe Response will display the QBSS Load element if the QBSS Load is enabled on the WLAN.

You can also find the Channel Utilization on a WLC with the following CLI command:

(WLC) >show ap auto-rf {802.11b | 802.11a} <AP_NAME>


Load Information

Load Profile................................. PASSED

Receive Utilization.......................... 0 %

Transmit Utilization......................... 0 %

Channel Utilization.......................... 40 %

Attached Clients............................. 1 clients

On an autonomous access point, use the following command:

AAP#show controller dot11radio {0 | 1} | i QBSS

QBSS Load: 0xC5 Tx 9 Rx 13 AP 22

In this case, the Channel Utilization is hexadecimal 0xc5 equal to 197/255 = 77%.

The QBSS Load element is extremely useful as a metric for troubleshooting and performance analysis. Cisco phones in survey mode and other wireless network tools can display the Channel Utilization on screen. The Channel Utilization can also be found with Prime Infrastructure or WLCCA.

What’s next?

Applications are growing fast and wireless networks can quickly reach their throughput capabilities. Channel Utilization can be volatile in a heavily-used environment and admission control could be difficult to manage.

The next step to leverage capacity would be enabling TSPEC with Admission Control on the access point to protect high-priority calls.


Jérôme Henry,, writer of the excellent CCNP-Wireless reference guides. He has published videos going through the configuration of QBSS Load in detail:

Wireless QoS, part 2-a and 2-b, Web link:

CCNP Wireless 642-742 IUWVN Quick Reference:

Cisco Unified Wireless IP Phone 7925G, 7925G-EX, and 7926G Deployment Guide:

Cisco Wireless IP Phone 8821 and 8821-EX Wireless LAN Deployment Guide: