KPIs (Key Performance Indicators) Overview

In this post will lay out several facets of WiFi KPIs that I plan on diving into in greater detail in the future. I hinted at this already in my mcs_index post.

Intro

Many different areas of business and technical operations use KPIs as feedback for higher order decision makers to know if things are going well or not. In the context of commercial WiFi, the primary goal of KPIs is to find out if a customer is having trouble before a ticket lands on the help desk.

In general KPIs encompass any data relevant to the 802.11 connections. In practice this amounts to mainly RSSI, SNR, Noise Floor, Channel Utilization and throughput.

Ingestion

The method of ingestion varies from vendor to vendor. For CISCO, the method is via Telegraf into a special telegraf-only schema where Telegraf can create tables for itself without worrying about conflicting with other tables. These raw stats are processed slightly later into kpi metrics tables. The raw stats are stored in timescaledb tables. TimescaleDB

For RUCKUS, the method is via MQTT which allows a set of protobuf messages to be received and processed by the rXg. The output of processing these messages can be directly saved into the kpi metrics tables.

Storage

Once processed, the KPIs must be stored in the database. Depending on whether the data is primarily about clients, radios, access points or a controller as a whole, this may be done with different tables keyed differently. Each of these tables uses timescaledb for improved storage efficiency.

Presentation

Once stored, the KPIs should be presented to the user. This is done mostly through graphs.

APs can can also be visually placed on a map in order to get a location based view of how they are doing.

Exporting Data

If you have a 3rd party system of receiving and processing data, you can also export this data via creating your own periodic webhook to send the data to your system.