Building a Client-Centric WiFi Resource Management System for Enterprise Networks

Introduction

During Inter IIT Tech Meet 14.0, our team worked on a challenging problem statement from Arista Networks: rethinking how enterprise WiFi networks make decisions.

Traditional WiFi Radio Resource Management (RRM) systems are Access Point (AP) centric. They primarily rely on information collected from APs to decide channel allocation, transmit power, client steering, and other optimization parameters.

The problem is that APs only see part of the network.

A client sitting behind a wall, experiencing hidden-node interference, or suffering from transient Bluetooth or microwave interference may have a completely different experience than what the AP observes.

This visibility gap leads to slower reactions, inaccurate decisions, and degraded user experience.

Our goal was to design a Client-Centric WiFi RRM framework that continuously observes the wireless environment, understands client-side conditions, and automatically optimizes network behavior using AI-driven decision making.

The Core Idea

Instead of relying solely on serving Access Points, we introduced an Additional Sensing Radio (ASR).

This dedicated radio continuously monitors the wireless spectrum without consuming client airtime.

The sensing radio acts as an independent observer of the RF environment and provides:

• Continuous spectrum visibility
• Detection of hidden interference
• Non-WiFi signal classification
• Channel occupancy measurements
• Client-side RF insights

By combining this information with client telemetry and cloud analytics, we created a multi-timescale control system capable of making both rapid local decisions and long-term global optimizations.

Understanding the Sensing Layer

The Additional Sensing Radio became the foundation of our entire architecture.

Unlike traditional AP scans that periodically interrupt normal operation, the sensing radio continuously captures information about the wireless environment without affecting client traffic.

Its responsibilities include:

• Capturing I/Q samples
• Generating FFT outputs
• Producing spectral summaries
• Monitoring channel occupancy
• Detecting interference signatures

Raw radio-frequency samples are converted into meaningful telemetry through a processing pipeline running directly on the sensing node. This allows us to transform low-level RF observations into actionable network intelligence.

To better understand interference patterns, we also generate time-frequency representations using Short-Time Fourier Transform (STFT) processing.

These spectrograms expose patterns that are difficult to observe through conventional metrics alone. Bluetooth bursts, microwave emissions, and other non-WiFi interferers create unique signatures that become visible in the time-frequency domain.

Access Point as the Edge Intelligence Layer

While the sensing radio provides visibility, the Access Point acts as the decision-making layer.

It combines:

• Sensor telemetry
• Client-side metrics
• PHY/MAC counters
• TCP quality-of-experience indicators
• Historical network behavior

The AP continuously analyzes this telemetry using statistical monitoring techniques such as EWMA and CUSUM.

This enables it to detect performance degradation within seconds and react before users begin noticing significant quality issues.

The goal is not simply to maximize throughput, but to optimize overall client experience.

Detecting Non-WiFi Interference with Deep Learning

One of the most interesting challenges in enterprise WiFi environments is identifying interference sources that are invisible to conventional RRM systems.

Instead of only measuring channel utilization, we wanted to determine what was causing the interference.

To achieve this, we designed a CNN-based interference classifier operating on spectrogram representations generated by the sensing radio.

The model learns both temporal and spectral characteristics of different interference sources.

To further improve classification performance, we introduced specialized feature extraction and attention mechanisms that allow the network to focus on meaningful spectral regions.

The resulting classifier was capable of distinguishing between different classes of non-WiFi interference, enabling the network to apply more informed mitigation strategies.

Multi-Timescale Network Control

One of the biggest architectural decisions we made was separating network decisions by timescale.

Not all network problems should be solved the same way.

Some issues require immediate reactions, while others benefit from long-term optimization.

To address this, we designed three coordinated control loops:

• Fast Loop
• Event Loop
• Slow Loop

The Fast Loop operates directly on the Access Point and responds within sub-second timescales.

The Event Loop analyzes persistent patterns and policy-driven conditions.

The Slow Loop operates in the cloud and performs large-scale optimization across entire deployments.

To ensure stable operation, every control decision follows a strict lifecycle.

This state-machine approach prevents oscillations, unnecessary configuration churn, and unstable network behavior.

Cloud-Scale Intelligence and Optimization

While edge devices handle immediate reactions, global optimization happens in the cloud.

The cloud layer aggregates telemetry from multiple sites and transforms it into actionable policies.

The cloud platform performs:

• Telemetry ingestion
• Long-term storage
• Feature engineering
• Policy generation
• Analytics and observability

By maintaining a global view of the network, the controller can identify patterns that are invisible at the individual AP level.

This allows the system to optimize:

• Channel allocation
• Power control
• OBSS-PD thresholds
• Network-wide interference management

The resulting policies are then distributed back to edge devices through a controlled rollout process.

Building for Reliability

One important lesson from production networking systems is that every automated decision must be reversible.

Even the best optimization algorithms can occasionally make incorrect assumptions.

For that reason, reliability and safety were built into the architecture from the beginning.

Whenever a policy change is deployed, the system continuously evaluates its impact on client quality-of-experience metrics.

If degradation is detected, the network immediately restores the previous stable configuration.

This rollback capability allows the platform to remain adaptive while minimizing operational risk.

In practice, it enables experimentation and optimization without sacrificing network stability.

Key Engineering Challenges

Several engineering challenges emerged during the design process:

Client Visibility

Traditional AP-centric systems often lack accurate information about what users actually experience.

We addressed this by combining AP telemetry with client-side observations and sensing-radio measurements.

Short-Duration Interference

Many interferers operate in bursts lasting only a few milliseconds.

Capturing these events required continuous sensing and adaptive dwell scheduling strategies.

Stability vs Responsiveness

Reacting too slowly leads to degraded user experience.

Reacting too aggressively causes configuration oscillations.

Designing the control loops and safety mechanisms required carefully balancing these competing objectives.

Scalability

The architecture needed to support deployment across multiple sites while maintaining low-latency local decisions and efficient cloud coordination.

What I Learned

This project exposed me to areas rarely covered in traditional coursework:

• Enterprise networking
• Wireless spectrum analysis
• Distributed systems
• Edge AI
• Deep learning for RF applications
• Telemetry pipelines
• Safe optimization systems

More importantly, it demonstrated that machine learning is only one part of a successful production system.

Building real-world AI solutions requires robust infrastructure, observability, fault tolerance, safety mechanisms, and scalable deployment strategies.

The most valuable lesson from this project was understanding how these components come together to create an intelligent system that can operate reliably in production environments.

Conclusion