Title: Sage: A Real-Time AI System for Reducing Latency in NextG Cellular Networks
Authors: Aoyu Gong, Raphael Cannatà, Arman Maghsoudnia, Néstor Lomba Lomba, and Haitham Hassanieh (EPFL); Dan Mihai Dumitriu (Pavonis LLC)
Introduction
Latency, rather than throughput, is increasingly the limiting factor for uplink-heavy NextG applications such as mobile AR/VR, cloud gaming, industrial automation, and robotic sensing. Conventional 5G grant-based access is resource-efficient but requires a UE to request and wait for uplink grants, adding at least two scheduling-related delay segments; grant-free access avoids those delays by reserving capacity in advance, but wastes spectrum when traffic is idle or bursty and scales poorly across users. Predicting demand could break this tradeoff, but previous predictors mostly operate at minute-to-day timescales or only support small periodic packets. Millisecond-scale prediction is harder because a base station observes protocol-shaped SRs, quantized BSRs, delivered payloads, and retransmissions rather than the UE’s true application arrivals, and a practical design must handle diverse and changing applications within strict real-time deadlines.
Key idea and contribution:
Sage is a software-only, real-time AI system that predicts when each UE will generate an uplink burst and how large it will be, then proactively schedules just enough radio resources. Its central abstraction is the “traffic train,” which groups closely spaced SR, BSR, payload, and retransmission observations to reconstruct a stable approximation of the original application burst. This removes much of the distortion caused by slot-level observability, BSR quantization, protocol configuration, and radio retransmissions, giving the predictor a more meaningful target.
Instead of relying on one large universal model, Sage characterizes a UE’s traffic and retrieves a lightweight, profile-specific predictor from a model database. A control loop spanning the gNB, real-time RIC, near-real-time RIC, and shared database performs model selection, low-latency inference, prediction verification, proactive scheduling, continual learning, and database updates. If prediction is unreliable, Sage safely falls back to grant-based access or to an analytically sized grant-free allocation. The prototype extends srsRAN and Open5GS, represents predictors in ONNX, and requires no changes to UE hardware or the 5G protocol.
Evaluation
The authors evaluate Sage over the air on an n78 5G testbed with commercial modems, eight real applications, multiple channel and operator configurations, and up to ten concurrent UEs. Across the applications, Sage reduces uplink latency by 2.53x relative to grant-based access while using only 1.59x more resources, and it reaches latency comparable to grant-free schemes while consuming up to 37.5x fewer resources. Arrival-time predictions generally have median absolute error below 4 ms and size predictions median relative error below 20%. With ten heterogeneous UEs, Sage reduces latency by 1.42-2.41x over grant-based access while preserving a Jain fairness index above 0.9902; it also lowers per-frame network latency by 2.07-2.54x for video streaming. This result is significant because it demonstrates that predictive scheduling can deliver much of the latency benefit of persistent resource reservation without sacrificing spectrum efficiency or multi-user fairness, using deployable software on a realistic 5G stack.
Q1: Do you assume that the application is known in advance so that you can select the appropriate model? What happens if a device runs multiple applications simultaneously and their traffic is mixed together? My second question is: perhaps I missed this point, but do the AI models run on the user devices? If so, have you considered the energy consumption of these models?
A1: Regarding the first question, a single user device may indeed run many applications. In 5G, we have a concept called network slicing. We run Sage for low-latency slices, while other background traffic can be carried on a best-effort slice. On the base-station side, there is also a mechanism called a Logical Channel Group. We can obtain the BSRs and payload information associated with the Logical Channel Group carrying the low-latency application. Therefore, Sage can operate specifically on the traffic of that application.
Regarding the second question, we run the AI models on the real-time controller on the base-station side, not on the phone. We also use lightweight, specialized AI models. As shown in our microbenchmark, the average inference time is approximately 50 microseconds. On a single CPU thread, we can execute 1,000 inferences within 50 milliseconds. Therefore, the models are very small and lightweight.
Q2: Did you include any downlink traffic in your experiments?
A2: In our experiments, we only generated uplink traffic.
Q3: In that case, what would happen if downlink traffic were also present?
A3: In a 5G system, uplink and downlink scheduling are handled separately. Downlink traffic is already available at the base station, so the base station can schedule it directly. Uplink scheduling, by contrast, is more event-driven because the base station must first learn that a user device has data to transmit. Therefore, we believe that downlink applications can run concurrently without fundamentally affecting Sage’s uplink scheduling mechanism.
Q4: My next question is for clarification. In your multi-user experiments, did all users run the same application?
A4: In the evaluation where we varied the number of users from 2 to 10, all users ran the mobile AR application. However, the paper also presents an experiment with 10 users running four different applications. We additionally evaluated different MAC-layer schedulers, including Round Robin and Proportional Fairness. Across these evaluations, Sage maintained a high level of fairness and remained effective under diverse traffic patterns and resource contention.
Q5: My understanding is that the effectiveness of your system largely depends on its forecasting capability. Your method uses multiple specialized models, or experts. Did you compare your approach with state-of-the-art forecasting methods to evaluate how they perform relative to your proposed method?
A5: In our current evaluation, the main system-level baselines are grant-based access and grant-free access. We also investigated several state-of-the-art predictors. However, we found that some of them had been evaluated only in simulation and were not open source. Their models were also relatively heavyweight. In addition, they predicted payload sizes directly rather than predicting the traffic-train abstraction introduced in our work. We provide additional comparisons among different predictor architectures in the paper.
Q6: I have a question about the traffic-classification component. How do you characterize the different traffic patterns of applications? My second question concerns the robustness of the method: what happens if the classifier makes a mistake and selects the wrong model for a traffic pattern?
A6: To characterize traffic, we use statistical features, all of which are described in detail in the paper. We also continuously track each model’s prediction error. If we retrieve an inappropriate model, or if the selected model is not actually the closest match to the current traffic, its prediction error will fail our verification process and we will not use it for proactive scheduling. We use a model only after it passes continuous error monitoring.
Q7: What about the traffic-classification mechanism? Do you need to train a classifier?
A7: In our current evaluation, we consider eight real-world applications. For each traffic flow, we collect three seconds of data and use its statistical features to retrieve the closest model. With this setup, we achieve a retrieval accuracy of nearly 100%.
As the number of applications increases, we may need to introduce more advanced retrieval techniques from the information-retrieval domain, where many effective algorithms already exist. Moreover, an application does not necessarily have to map to exactly one model. A single model can be indexed by several feature vectors, and multiple applications with similar traffic characteristics may share the same model. Therefore, model retrieval can be based on the current traffic characteristics rather than on a strict one-to-one mapping between applications and models.
Personal thoughts
The strongest aspect of Sage is that it treats real-time prediction as a complete systems problem rather than presenting only a forecasting model. Traffic trains address a concrete observability mismatch, while verification, fallback, continual learning, scheduling, and fairness experiments make the design credible as a RAN mechanism. I also like that the evaluation includes bursty real applications, commercial UE hardware, multiple schedulers, contention, retransmissions, and application-level latency rather than stopping at prediction error.
The main uncertainty is how broadly the profile database and online adaptation will generalize beyond the tested applications and a small single-cell deployment. A larger operational study should examine model-database growth, cold-start behavior, rapidly mixed foreground/background traffic, mobility and handovers, adversarial or privacy-sensitive traffic, and compute contention when hundreds of UEs require inference simultaneously. It would also be valuable to quantify the tail latency and resource cost during model transitions, since median prediction accuracy can hide rare missed bursts that matter most to interactive applications.