Overview
Enterprise wireless access points (APs) are identified as potential platforms for predictive machine learning (ML). However, their primary function involves providing wireless connectivity and network services. This dual role creates resource contention, as predictive inference must share CPU and memory resources with packet processing, Wi-Fi and IoT radio operations, and client management. This contention poses two risks: first, an ML model performing adequately on proxy hardware may operate too slowly on the target AP; second, a model functioning well in isolation may still degrade network services when the AP is under load.
To address these challenges, the concept of network-aware deployability is introduced. This concept is defined through a two-stage gating process. The initial stage involves the qualification of the ML model and its execution path on the specific target AP hardware. The subsequent stage entails the validation of the model's execution profile under defined packet-service and forecasting constraints. The necessity of understanding these trade-offs for live deployment is emphasized, particularly if APs are to simultaneously handle both networking and ML workloads.
Research Context
The integration of predictive machine learning directly onto enterprise wireless access points presents opportunities for distributed intelligence. However, APs are not typically designed as dedicated ML inference engines. Their architecture prioritizes core networking functions, requiring real-time processing of wireless traffic, management of client connections, and operation of various radio technologies (Wi-Fi, IoT). Introducing ML inference introduces an additional computational burden that directly competes for the same limited CPU and memory resources. This competition can manifest as performance degradation for either the ML task or, critically, the primary network services.
Approach
The research defines network-aware deployability through a two-step validation framework:
- Model Qualification: This step assesses the ML model and its execution path directly on the target AP hardware. This ensures that the model can technically operate within the AP's environment.
- Execution Profile Validation: This subsequent step evaluates the model's performance and resource consumption profile while simultaneously considering the AP's packet-service and forecasting operational constraints. This involves understanding how the ML workload interacts with ongoing network operations.
Benchmarking was conducted to compare the performance of ML models across different hardware platforms and under varying network conditions. Specifically, comparisons were made between AP performance and that of a Raspberry Pi 5, as well as observations under network saturation conditions.
Findings
- Performance Discrepancy Across Hardware: Benchmarks demonstrated that edge testbeds do not reliably replicate the behavior observed on target APs. Across matched artifacts and serving configurations, five distinct ML model implementations exhibited significantly slower execution on an AP. These models ran 6.1 to 19.1 times slower on an AP compared to their execution on a Raspberry Pi 5.
- Memory Usage Variability: Peak memory utilization between APs and Raspberry Pi 5s for the same ML workloads differed by up to 22%.
- Model-Specific Latency on APs: Among two forecasting foundation models of comparable size, a substantial difference in AP latency was observed, with one model exhibiting latency 19 times greater than the other.
- Impact of Concurrent ML and Network Load: When a smaller ML model was served across 13 parallel streams at a 30-second cadence, coinciding with network saturation conditions, specific network performance degradations were recorded. The p99 round-trip time (RTT) increased by 76% with default execution, and network throughput was reduced by 7.06%.
Why This Matters
The findings underscore critical considerations for the successful integration of machine learning inference capabilities directly onto wireless access points. Understanding the significant performance variances between proxy hardware and target APs, as well as the substantial impact of ML workloads on network service quality under load, is essential for practical and reliable live deployments. These insights directly inform deployment strategies, model selection, and resource allocation to ensure both ML functionality and core networking performance are maintained.