Contents

Introduction

Tool Link

Features

Components used / What is supported

RF Health

Main objectives

Worst metric selection

Data Summarization

RF Health indicators

Co-Channel Neighbor Utilization

Co-Channel Overlapping

Noise Side Channel

Noise Same Channel

Co-channel interference

Adjacent channel interference

Low SNR Clients

Radio Utilization

Cleanair Interferers

Frequently Asked Questions

What do I need to load to use this tool?

How do I use the menu?

Are all checks/messages from WLCCA ported over?

What are the main differences about the checks with WLCCA?

Is it possible to export the info into a CSV/XLS?

I have a bug report/feature request...

What are the colors in the messages?

Are the checks the same as in WLCCA?

Why does the application summarize messages now?

Introduction

This document describes the next generation tool for parsing Wireless Controll configurations.

Tool Link

https://cway.cisco.com/wireless-config-analyzer/

Features

It is designed to work on cloud/multi platform scenarios, currently supporting only WLC AireOS operating system,  with plans for future expansion.

- Parsing and analysis for Wireless LAN Controller (WLC) "show run-config", "show tech", "show log"

- Using "show run-config" is recommended, as it provides the best analysis possible

- New implementation for the WLC Config Analyzer. it is a new re-write of the application, with clean up and improved checks

- Currently supported checks: General, Access Points (AP), Radio Frequency (RF), Mobility, Security, Mesh, Flex

- RF summary: Stats summarization at WLC, AP group, Flex group level

- RF health analysis at WLC, AP group, Flex group level

Components used / What is supported

- Single WLC scenario. No support for multiple WLCs/files

- WLC version 8.0 and higher. (may load older versions)

- All WLC/Mobility Express (ME) hardware types

- "show run-config" file  is highly recommended. sh tech and sh logs are also supported, but provides less information

RF Health

The objective of the RF Health Metric is to simplify troubleshooting, and open the possibility to have “automated system” to quickly detect or easily point to bad areas

Basically, trying to answer the “where in my hundreds of APs do I look first ?” question

Main objectives

RF Health is a value from 0 to 100 to represent a simple-to-understand metric with the RF quality state of AP radio (0% is dead, 100% is fully healthy )

Each different RF metric has its own health score on 0-100 scale.  It is easier to understand a 0-100 scale, compared on how difficult to understand would be “a possible cochannel interference on RSSI -47 with 20 clients attached”, or an open scale metric.

The idea is to translate either by simple correlation or by algorithm mapping, different RF metrics into multiple simple metrics of 0-100 values.

Worst metric selection

The current implementation forces the “top level” AP health to be the lowest of all individual RF metrics, instead of averaging. Different summarization mechanisms could be implemented based on deployment type (on high density , it is more important to care about co-channel/noise/client count while on high speed deployments, it is better to focus  on low client Signal Noise Ratio (SNR) and co-channel interferer)

Data Summarization

Data is summarized per AP or flex group, per frequency band and then per WLC (in that order).

The summarization level resulting RF health is not the average of devices inside it, as it would hide several bad scenarios (0 + 100=50). It is marked as good/medium/bad, based on which percentage of elements are on good health, and so on ( if a third of elements are on <40%, it is marked as bad).

RF Health would represent the “easy to understand” 0-100 metrics, with the raw data be available through the “RF Stats” view, covering the same summarization levels. The Health part is for the common admin/user, quick to be looked at, easy to understand, and the stats view would be useful for troubleshooting/low level analysis

RF Health indicators

Co-Channel Neighbor Utilization

This gets a list of APs operating on the same channel as the current AP, and puts a weight on each one, adding a metric based on the neighbor current channel utilization versus the “distance” from the AP  (nearby data).  It correlates nearby APs versus their activity affecting current AP. Impact of each AP on same channel is added. The objective is that APs which are closer to current AP ( higher RSSI) with a higher channel utilization, have a larger impact on RF health

Co-Channel Overlapping

This gets the list of nearby Aps on the current channel, and correlates their current operating power (Transmit Power Control - TPC) versus their current RF distance (nearby data). It creates a relation of nearby Aps against their operating power on how much overlap they have on the current operating channel of the evaluated AP.

Objective is to represent that Aps which are closer to current AP ( higher RSSI) with a higher operating power, have a larger impact on RF health, independently of their current TX utilization. it is accumulative impact for all APs on same channel as the evaluated AP

Noise Side Channel

This metricl correlates a detected noise impact to the current operating channel, vs the “channel distance” where the noise was detected

It has 2 different operational modes:

- In 2.4 GHz case:

We need to assign a lowering impact depending on the distance of the channel where the noise is seen. Same channel is 100% impact, next channel is 80, then 40%, etc..

For example, if the AP is on channel 1, noise in channel 5 impact is lowered as 20% impact

Then the noise measurement is converted into a 0 to 100 scale (compensated noise). Noise below -80 dBm is considered 0 impact, noise above -50 dBm is 100% impact

- In 5.0 case:

If noise is on a side channel ( AP is on 100, noise is on 104), we subtract 36 from the detected noise power level (this is based on channel mask averaging for 11a operation. Static value obtained is as a “good enough simplification”). The tool takes into consideration channel bonding (40, 80, 160)

Noise Same Channel

Extension of the previous procedure. Noise measurement is converted into a 0 to 100 scale (compensated noise). Noise below -80 dBm is considered 0 impact, noise above -50dBm is 100% impact. No “side channel” subtraction is done, so this is basically direct conversion of received noise power level to a 0-100 scale based on the above parameters

Co-channel interference

Similar to noise correlation, but applied to other wifi activity on the channel. The range is different, as normally APs can coexist with Interference (wifi activity) better than with random noise. A value of -50 is considered 100% full impact, -90 is considered 0% impact.  Interference has a value of “time” percentage in RRM metrics. We convert anything higher than 30% time as full impact (100%),

Adjacent channel interference

Similar to noise correlation. The range is different, as normally APs can coexist with interference (wifi activity) better than with random noise. A value of -50 is considered 100% full impact, -90 is considered 0% impact/ Interference has a value of “time” percentage in RRM metrics. We convert anything higher than 30% time as full impact (100%),

Low SNR Clients

Objective is to convert clients connected on bad SNR levels (<=20dBm) to a 0 to 100 scale.

Aps that continuously have a high count of low SNR clientsl either indicate a radio problems on the nearby Aps (which causes Aps to roam/use this one) , a coverage problem (bad deployment) or a client roam bug (sticky client)

it is not evaluated for AP with less than 5 clients

Radio Utilization

This is direct translation of the radio utilization. Uses 0 as no impact, 60 as full impact

So, AP on 30% radio utilization would rate as RF health Radio Utilization of 50%

Cleanair Interferers

Target here is to convert non-wifi detected devices to a 0-100 scale. The metric checks the device Duty Cycle (40% is translated as 100% impact), versus the channel (100% impact for on channel, plus reduces impact for side-channel scenarios in 2.4), versus the RSSI measured for the signal

Frequently Asked Questions

What do I need to load to use this tool?

Currently: a "show run-config" from a AireOS WLC

Optionally: "show tech"  from AireOS. Other file types are planned to be added

How do I use the menu?

if you click on each of the options, itl toggles show/hide the respective section

Are all checks/messages from WLCCA ported over?

All checks are implemented, except for:

- Voice Audits (coming soon)

- Config comparison between controllers

What are the main differences about the checks with WLCCA?

1. AP radios are now only checked if they are on "client servicing mode", meaning, that the AP is enabled, the mode is for clients (not monitor, sniffer, etc) radio is up, and it has a valid power and channel settings. RF stats are only tracked as well on this scenario

2. AP messages, and WLC Interface, WLAN, Mobility messages are summarized by ID, with each message counting the individual elements affected.

Is it possible to export the info into a CSV/XLS?

On the current implementation, no, it is not possible, although you can copy&paste the results into Excel

I have a bug report/feature request...

Good!, please write to :wireless-analyzer@cisco.com

What are the colors in the messages?

- Light red: Error level

- Light Yellow: Warning level

- Light Green: Information

Are the checks the same as in WLCCA?

In general, yes.  We have preserved the same message IDs as in WLCCA. Some messages have been adjusted or improved, for example, theyl always refer now to radio slot number, not to 2.4 or 5 GHz radios, as now APs have multi band hardware

Why does the application summarize messages now?

The idea is to reduce total screen "real state" used by the message report. This was needed for proper integration into TAC case process