WiFi Analytics Configuration Guide

Introduction

WiFi Analytics is a built-in diagnostic feature of the CONTROL ACS platform that evaluates the quality of a CPE's WiFi network. After triggering a neighboring-WiFi scan from the device's Diagnostics tab, the engine collects radio, client, and neighbor data from the CPE and produces a structured score report.

The evaluation covers six quality factors: Signal, Noise, SNR, Interference, Standard, and Speed. Each factor is scored on a scale of 1–10 and then combined into a single Overall Score using configurable weights. This lets you tune the scoring model to reflect the conditions of your own network — for example, increasing the Interference weight for dense urban deployments.

The engine supports both TR-181 and TR-098 CPEs. For standard TR-181 devices with sequential radio indexes, the engine can auto-discover the radio configuration without any additional setup. For TR-098 or vendor-specific devices with non-standard parameter paths, an explicit Service configuration is required to supply the correct path templates and JSON key names.

Prerequisites

Before configuring WiFi Analytics, ensure the following conditions are met:

Note: If ServiceType 23 is missing, contact your platform administrator to load the WiFi Analytics fixtures.

Configuration Steps

Step 1: Create a Service for WiFi Analytics

A Service instance of ServiceType 23 holds all the configuration that tells the engine how to map radio and client parameters for a specific device model.

1. Navigate to Settings > Services > Add
2. Set the Service Type field to CWMP WIFI Neighbor test (ServiceType 23)
3. Give it a descriptive name, for example: WiFi Diagnostic Score - Model XYZ
4. Check Active and Public
5. Save the Service

After saving, the Service will display four parameter groups:

Configure only the bands that are relevant to the device model. Bands that are left disabled are excluded from scoring.

Step 2: Configure Band Parameters

Each band group (2.4 GHz, 5 GHz, 6 GHz) contains the same set of fields. Repeat this configuration for every band the device supports.

Band Enable and Index Fields

Important: The {i} placeholder is the only token substituted by the engine. All other numbers in path templates (e.g., LANDevice.1) are treated as literal strings and are never modified.

Variable Override Fields

These fields allow you to supply explicit TR-181 or TR-098 parameter paths. Leave them blank for standard TR-181 devices — the engine uses the correct Device.WiFi.* defaults automatically.

For TR-098 or vendor-specific devices, enter the full path template using {i} where the radio index should appear.

Client Field Override Fields

These fields specify the JSON key names used to read per-client metrics from the AssociatedDevice table entries. These are short key names, not full parameter paths.

Leave them blank for standard TR-181 devices. For TR-098 or vendor devices, enter the vendor-specific key name.

Clients Table Path and Active Filter

Step 3: Configure Score Weights

The Score Weights parameter group controls how much each quality factor contributes to the Overall Score. The six weights must add up to 100%.

Adjust these values to match your deployment environment. For example, increase Interference weight to 40–50% for dense urban areas, or increase Signal weight if coverage is the primary concern.

Step 4: Create a Test Profile

A Test Profile links the Service to a device Type, so the engine knows which Service configuration to use when running a diagnostic.

1. Navigate to Userx > Profiles > Add
2. Give it a descriptive name (e.g., WiFi Analytics — Model XYZ)
3. Check Is active
4. In the Locations, tests and limits settings section, add the Service created in Step 1 to the Test services field
5. Save the Test Profile

Step 5: Assign the Test Profile to a Device Type

1. Navigate to Inventory > Profiles and select the device Type for the target CPE model
2. Locate the Automatic tests profile field
3. Select the Test Profile created in Step 4
4. Save the Type

From this point on, any device of this Type will use the configured Service when a WiFi diagnostic is run.

Running the WiFi Diagnostic

1. Navigate to the target device's Diagnostics tab
2. From the Operation dropdown, select WiFi neighbor diagnostics
3. The Parameter name field defaults to .WiFi.NeighboringWiFiDiagnostic. The engine automatically prefixes this with Device. for TR-181 or InternetGatewayDevice. for TR-098
4. Click Proceed
5. Wait for the CPE to scan neighboring networks (typically 10–30 seconds)

Understanding the Results

Once the diagnostic completes, a WiFi Analytics mini-dashboard appears below the form.

Header Summary

Band Cards

Each band displays its current channel, bandwidth, connected client count, a score progress bar, and a quality label (Excellent / Fair / Poor).

Recommendations and Tips

• Recommendations (yellow accent): Channel changes, bandwidth suggestions, or "No issues" when optimal
• Tips (blue accent): Missing parameters, discovery suggestions, or vendor contact recommendations
• No clients: When no WiFi clients are connected, Overall shows N/A with an info message

How the Overall Score is Calculated

The Overall Score is a weighted average of all available factor scores across all bands:

1. Each client's 6 factors are scored individually
2. Factors with N/A are excluded; remaining weights are renormalized to sum to 100%
3. The weighted average produces a per-client score (1–10)
4. All client scores within a band are averaged to produce the band score
5. All band scores are averaged to produce the Overall Score

The default weight distribution emphasizes Interference (30%) and Signal (24%) as the highest-impact factors for typical residential WiFi environments.

Quality Factors — Detailed Breakdown

Below each band card, six horizontal bars show the individual factor scores. Each factor is scored 1–10 based on specific inputs from the CPE. When a factor cannot be calculated, it shows N/A and its weight is redistributed proportionally across the remaining factors.

Signal Factor

Measures the received signal strength (RSSI) of each connected WiFi client.

Input: SignalStrength from the AssociatedDevice table (or the vendor-specific JSON key configured in the Service).

The final Signal score for the band is the average across all connected clients.

Noise Factor

Measures the background noise floor on the radio channel.

Input: Per-client Noise field from AssociatedDevice, or fallback to Device.WiFi.Radio.{i}.Stats.Noise (radio-level noise).

Lower noise is better — a value below −90 dBm indicates a very clean radio environment.

SNR Factor (Signal-to-Noise Ratio)

Measures the gap between signal and noise for each client. Higher SNR means clearer communication.

Input: Either a vendor-specific SNR field (e.g., X_ALU-COM_SNR) or auto-calculated as SignalStrength − Noise when no dedicated SNR field is available.

Interference Factor

Evaluates how much congestion the CPE experiences from neighboring WiFi networks on the same or adjacent channels.

Inputs:

• Device.WiFi.Radio.{i}.Channel — the CPE's current operating channel
• Device.WiFi.Radio.{i}.CurrentOperatingChannelBandwidth — channel width (affects adjacency range)
• Neighboring networks — the full list of detected WiFi neighbors from the NeighboringWiFiDiagnostic scan

How neighbors are scored:

Each detected neighbor contributes to a raw interference accumulator based on two criteria: whether it is on the same channel or an adjacent channel, and its signal strength:

• Proximity is a value between 0 and 1 based on how close the neighbor's channel is within the adjacency range
• Adjacency range depends on the CPE's channel bandwidth: 20 MHz covers ~4 channels, 40 MHz covers ~8, 80 MHz covers ~16, 160 MHz covers ~32 (for 5 GHz / 6 GHz)
• A bandwidth multiplier is applied to the accumulated raw score based on the CPE's own bandwidth (40 MHz ×1.5, 80 MHz ×2, 160 MHz ×3)

The raw accumulator is then mapped to a score:

N/A condition: If the CPE's Channel parameter is missing from DeviceSettings, the engine cannot determine which neighbors overlap — the Interference factor shows N/A.

Standard Factor

Evaluates the WiFi standard (protocol generation) used by the CPE's radio.

Input: Device.WiFi.Radio.{i}.OperatingStandards — the active standard(s) for this radio.

The score depends on the band:

2.4 GHz band:

5 GHz band:

Newer standards support higher throughput, better modulation, and features like OFDMA and MU-MIMO, which directly improve network quality.

Speed Factor

Measures actual throughput as a percentage of the theoretical maximum for the current standard and bandwidth combination.

Inputs:

• LastDataDownlinkRate and LastDataUplinkRate from each client (in kbps)
• OperatingStandards and CurrentOperatingChannelBandwidth from the radio

The engine calculates: average_speed = (downlink + uplink) / 2, then compares it against a reference throughput table:

N/A condition: If downlink or uplink rate data is missing for all clients, Speed shows N/A.

Additional Notes

• Without a Service/TestProfile, the system auto-discovers radios from DeviceSettings (works for standard TR-181 CPEs with sequential indexes 1, 2)
• For TR-098 or vendor-specific CPEs, explicit Service configuration is required
• Score weights are per-Service — you can create multiple Services with different weight profiles for different environments
• The {i} placeholder is the only substitution the engine performs. All other numbers in paths are literal

TR-098 Quick Reference