Source-linked AI summary
Network-Aware Forecasting on Wireless Access Points
Niloo Bahadori, Swadhin Pradhan, Peiman Amini
TL;DR
Enterprise AP forecasting must share resources with network services, but proxy hardware and isolated inference do not establish deployability. The paper defines two gates for target-AP qualification and load-dependent validation, finding model-dependent device behavior and service trade-offs under contention. These results frame AP forecasting as network-aware co-location rather than one-time model placement.
Problem
Enterprise APs must run predictive inference alongside packet processing, radio operations, control-plane functions, and client management, creating uncertainty about interference-free deployment.
Method
The paper defines network-aware deployability as target-AP qualification of the complete model and execution path followed by validation under packet-service and forecasting constraints.
Results
Model-dependent target behavior and contention determine feasibility: AP/Pi latency slows by 6.1–19.1×, while default execution at saturation raises p99 RTT by 76% and lowers throughput by 7.06%.
Takeaways & Limitations
Deployable AP forecasting requires an execution profile that preserves networking while meeting forecast deadlines, not merely low isolated inference latency.
Takeaways & Limitations
Forecast-accuracy thresholds and resource budgets are defined by each use case, with capacity reserved for networking and service-specific throughput and latency limits.
Abstract
from arXiv · showhide
Enterprise wireless access points (APs) are promising platforms for predictive machine learning (ML), but their primary responsibility remains providing wireless connectivity and network services. Predictive inference must therefore share an AP's CPU and memory with packet processing, Wi-Fi and IoT radio operations, and client management. This resource contention creates two risks: a model that performs well on proxy hardware may be too slow on the target AP, while a model that fits in isolation may still degrade network services under load. We define \textit{network-aware deployability} using two gates: qualification of the model and its execution path on the target AP, followed by validation of its execution profile under packet-service and forecasting constraints. Our benchmarks show that edge testbeds do not reliably capture target behavior. Across matched artifacts and serving settings, five model implementations run 6.1--19.1$\times$ slower on an AP than on a Raspberry Pi~5, while peak memory usage differs by up to 22\%. Moreover, two forecasting foundation models of similar size differ in AP latency by 19$\times$. When serving a smaller model across 13 parallel streams at a 30~s cadence under network saturation, default execution increases p99 round-trip time (RTT) by 76\% and reduces throughput by 7.06\%. Understanding these trade-offs is essential for live deployment if we aim to use APs for both networking and ML workloads.
1 Introduction
Enterprise APs can support forecasting because they observe relevant telemetry, but inference must share resources with uninterrupted network services. The paper therefore asks when recurring inference can run without harming packet service.
- APs provide wireless access, traffic processing, radio and control-plane functions, client management, and telemetry useful for forecasting.
- Available inference headroom shrinks with traffic, client count, and control-plane activity, while network service remains the priority.
- Two independent failure modes motivate deployment checks: proxy latency may misidentify production behavior, and isolated inference may disrupt services under contention.
- The proposed methodology first qualifies the complete model and execution path on the target AP, then validates recurring multi-stream execution against service and forecast budgets.
- The characterization compares AP and Raspberry Pi 5 latency, while the workload evaluation serves 13 forecast streams under network contention.
2 Two-Gate Deployability
Network-aware deployability is defined as two feasibility gates: target-AP qualification of the model and execution path, followed by load-dependent validation against service and forecasting constraints.
- Context: The deployment context specifies the target AP, service class, forecast quality, resource budgets, forecast age, and tolerable packet-service degradation.
- Gate 1: target-AP qualification: Gate 1 evaluates a candidate comprising model f and execution configuration e, including artifact, precision, runtime, threading, placement, priority, and parallelism.
- Gate 1: target-AP qualification: Forecast quality, available memory, and forecast-cycle deadline determine target-AP qualification requirements.
- Gate 2: load-dependent operating envelope: Gate 2 compares recurring-inference throughput and p99 RTT with a matched no-ML baseline for a networking workload and execution profile.
- Gate 2: load-dependent operating envelope: Observed throughput improvements or RTT reductions are recorded as zero degradation rather than as ML-attributed service benefits.
- Deployment constraints: Memory and compute budgets reserve capacity for networking, while throughput and tail-latency limits follow network-service requirements.
3 Evaluation
Evaluation separates target-device qualification from load-dependent service validation on a production-class AP. Results show strong model-dependent latency transfer and a trade-off between network protection and forecast-cycle speed.
- Setup: The test platform is an accelerator-free AP with four ARM cores and approximately 2 GB of RAM, serving APEX 2 across 13 streams every 30 s.
- Evaluation design: The experiments measure target-AP latency and memory, then test recurring inference under approximately 100 Mbps, 250 Mbps, and saturation.
- Target device characterization: 6.1–19.1× AP/Pi latency slowdowns vary by model, ruling out a fixed proxy-to-target scaling factor and showing parameter count is insufficient.
- Target device characterization: Peak RSS differs by at most 22% between Raspberry Pi 5 and AP measurements, while latency reflects model-platform interaction.
- Network protection and inference speed: 76% p99 RTT inflation and 7.06% throughput loss occur under default ML execution at network saturation.
- Network protection and inference speed: Service-prioritized execution removes measured nonnegative network degradation but lengthens the 13-stream cycle from 8.31 s to 17.5 s p99; both remain below the 30 s deadline.
4 Related Work
Prior work spans hardware-aware mobile inference and temporal forecasting models. This paper connects those lines by defining deployability around target-AP execution and network-service constraints.
- Hardware-aware edge inference: Mobile-systems research shows that FLOPs and parameter counts poorly predict latency, motivating target-device measurement and hardware-aware optimization.
- Hardware-aware edge inference: Prior methods include mixed-precision quantization, device-specialized subnetworks, model-software co-design, mobile-GPU acceleration, and resource adaptation.
- Temporal forecasting: Temporal-forecasting work includes general foundation models, lightweight RAN analytics models, and APEX's network-native pre-training evaluated on AP-class proxy hardware.
- Paper's positioning: The paper bridges these areas by fixing the forecasting task and validating target-AP qualification together with packet-service and forecasting constraints.
5 Conclusion
On-AP predictive inference is an asymmetric co-location problem: target-device feasibility does not guarantee service feasibility under contention. Deployment must preserve packet service while meeting forecast deadlines across a network-load-dependent operating envelope.
- Target-device qualification does not guarantee service feasibility under contention.A model and execution path can be qualified on the AP yet become infeasible when network workloads compete for resources.
- Deployment must protect networking and forecast freshness as network load changes.The required execution profile must preserve packet service while meeting forecast deadlines.
- The deployment objective is an execution profile, not merely minimum inference latency.The profile must balance packet-service preservation with forecast-deadline requirements.