1. Background and motivation
“Deploy an AI model for network optimisation” is not a single, fixed cost: a traffic-forecasting model that runs once per minute per cell has wildly different compute requirements from an agentic reasoning loop that must diagnose a fault and propose a remediation within a sub-second RIC control-loop deadline, or from an ISAC-adjacent model that must process a continuous sensing stream in near real time.
Network operators considering AI-based optimisation and configuration today face a sizing problem with almost no public methodology behind it: how many GPUs (or CPUs, or edge accelerators) does it actually take to run a given AI task, for a given number of cells/sites, at a given required latency, availability, and refresh rate? Today this tends to be answered by vendor rules of thumb or by expensive over-provisioning “to be safe,” rather than by a principled, measurement-grounded estimation method.
This project sets out to build a general, reusable, and scalable framework that takes (a) a description of an AI-driven network task and its required KPIs (latency bound, throughput/load it must handle, how frequently it must run, acceptable failure/backlog rate) and (b) empirically measured performance-per-unit-of-compute data, and returns a defensible estimate of the type and amount of compute required — with the explicit design goal that the method should scale from “one task on one testbed” up to “an operator’s estimate for their entire network.”
2. Research questions
- RQ1 (Task profiling): For a representative set of network-optimisation/configuration AI tasks (e.g. per-cell traffic/load forecasting, anomaly/fault detection, RRM parameter recommendation, an LLM-based agentic diagnosis-and-remediation loop) what is the empirical relationship between compute resource allocated (GPU/CPU type and quantity, memory, batch size) and achieved performance (inference latency distribution, maximum sustained query throughput, accuracy/quality at a given latency budget)?
- RQ2 (KPI-to-compute mapping): Given a target operational KPI set (e.g. “95th-percentile decision latency under 10ms,” “must handle up to N concurrent cell-level requests,” “must refresh its output every T seconds,” “at most X% of requests may be dropped/queued beyond the deadline”), what is the minimum compute configuration (hardware type and count) that satisfies it, and how does this minimum change as any one KPI is tightened?
- RQ3 (Load and queueing behaviour): How does the system behave under realistic, bursty network load (rather than steady-state average load), what queueing/backlog behaviour emerges near capacity, and what safety margin (headroom above the naive average-load estimate) is actually required to hold the tail-latency KPI, not just the average-latency KPI?
- RQ4 (Scalability of the estimation method itself): Can the task-level compute model built in RQ1–RQ3 be composed and extrapolated, i.e., given measurements from a small testbed (a handful of cells/tasks), can the framework produce a credible compute estimate for a much larger deployment (hundreds or thousands of cells, multiple concurrent AI tasks sharing infrastructure), including realistic effects like resource sharing/multiplexing gains and multi-tenant contention? This is the central research contribution distinguishing this from a one-off benchmarking exercise.
- RQ5 (Framework validation and sensitivity): How sensitive is the final compute estimate to the input assumptions (traffic-load model, target hardware generation, model architecture choice, accuracy-vs-latency trade-off point chosen)? Can the framework produce not just a point estimate but a defensible range with stated confidence, and does it correctly flag when it is being asked to extrapolate beyond the regime its measurements actually cover?