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: https://www.cisco.com/c/en/us/td/docs/wireless/controller/technotes/8-3/b_RRM_White_Paper.html

Cisco Wireless Controller Configuration Guide, Release 8.3: https://www.cisco.com/c/en/us/td/docs/wireless/controller/8-3/config-guide/b_cg83.html

CCNP Wireless (642-747 IUWMS) Quick Reference guide: http://www.ciscopress.com/store/ccnp-wireless-642-747-iuwms-quick-reference-9781587143090

The comprehensive blog “mrncciew” for CCIE Wireless studies, Configuring Coverage Hole Detection (CHD): https://mrncciew.com/2013/03/17/configuring-coverage-hole-detection-chd

Difference between Coverage hole and Pre-coverage hole, Cisco Support Community: https://supportforums.cisco.com/t5/wireless-mobility-documents/difference-between-coverage-hole-and-pre-coverage-hole/ta-p/3111420