Network slicing allows a 5G network to support services with very different requirements on the same radio infrastructure. An eMBB service may need sustained throughput, while a URLLC service may require strict reliability and low delay. The challenge is not simply creating separate slices. The RAN must continuously decide how much radio capacity each slice should receive, and how that capacity should be distributed among the users within each slice.
Slice-ML builds on a hierarchical deep learning approach to resource allocation in network slicing, applying the underlying ideas to an open, real-world RAN implementation. Rather than treating intelligent slicing as a simulation-only problem, this work brings the two-level decision process into the OCUDU-RAN Distributed Unit, with dedicated intelligence for both slice-level resource allocation and per-UE scheduling.
Static resource allocation cannot respond effectively to changing traffic conditions. A slice that requires more capacity at one moment may need considerably less a few seconds later. At the same time, scheduling users within a slice is a much faster problem that must be solved for every transmission opportunity.
Slice-ML addresses these two problems at their respective timescales. A slow ML controller dynamically adjusts the PRB boundary between the eMBB and URLLC slices, while independent per-slot attention models determine which users should be prioritised within each slice.
A hierarchical approach to RAN resource allocation
Resource slicing involves decisions that operate at very different speeds.
The first is the allocation of radio resources between slices. This decision does not need to change every slot. The controller evaluates recent network conditions and determines whether the balance between eMBB and URLLC should change. Slice-ML performs this decision once every second.
The second is user scheduling inside each slice. Once resources have been assigned to a slice, the scheduler still needs to determine which UE should receive them. This decision operates on the scheduling timescale and therefore requires a lightweight inference path that can execute within the slot budget.
Slice-ML keeps these two decisions independent. The slice controller observes network-level metrics and selects one of 19 candidate PRB allocation actions. The per-slice attention schedulers then rank users and resource units inside their respective slices. This separation allows each model to focus on a well-defined problem instead of attempting to learn the entire resource allocation process as a single decision.
Dynamic slice-level resource allocation
The slice controller uses an LSTM-based policy to determine the appropriate resource split between the two slices.
At each one-second interval, the controller receives observations representing the current state of the RAN: throughput, load, SLA satisfaction and PRB usage. The current allocation action is also included in the input, giving the model 23 inputs in total.
The controller selects from 19 discrete actions. Each defines minimum and maximum PRB ratios for the two slices. The minimum provides a guaranteed floor, while the maximum defines how much additional capacity a slice can use when resources are available.
The objective is not simply to maximise aggregate throughput. The controller is trained around a reward that combines eMBB throughput with penalties for failing the service requirements of either slice. This matters because an allocation that produces higher total throughput is not necessarily a better slicing decision: a small increase in throughput is not useful if it comes at the expense of URLLC reliability, or causes the eMBB service to fall below its target.
Per-UE scheduling with attention models
Changing the slice boundary is only one part of the problem. Once resources reach a slice, the scheduler must still decide which UE should transmit.
Slice-ML introduces independent attention-based schedulers for URLLC and eMBB. Each observes the users and resource units available within its slice and produces a ranking of user and resource-unit pairs.
The model does not directly place PRBs on the physical carrier. It determines which users should receive priority and how much of the available resource they should receive. The existing DU allocator remains responsible for the final frequency-domain placement.
This division is deliberate. The ML model provides the scheduling intelligence while the established RAN allocator continues to enforce the underlying resource placement constraints, so machine learning improves the decision-making process without having to reproduce every constraint the RAN scheduler already implements.
Real-time inference in the DU
AI inference in a RAN must satisfy a fundamentally different requirement from conventional machine learning applications. A model can have excellent prediction accuracy and still be unsuitable if its inference time exceeds the scheduling deadline.
For this reason the Slice-ML runtime uses native C++ inference without linking a machine learning framework into the DU. Models use single-precision arithmetic and avoid dynamic memory allocation on the hot path, and the attention scheduler uses cached projections to reduce repeated computation.
Before deployment, every trained model can be checked against the C++ implementation to verify that the runtime reproduces the arithmetic used during training. The attention models are then benchmarked across different user and resource-unit counts to confirm inference stays within the available slot budget. At 30 kHz subcarrier spacing a slot is 500 microseconds, and a model that cannot meet that is not suitable for the corresponding deployment configuration.
This makes runtime performance a deployment criterion rather than an afterthought.
Data collection, training and model validation
The Slice-ML lifecycle begins with data collected from normal RAN operation. The DU records two complementary datasets: a slice-level dataset with one observation per slice for each one-second control period, and a UE-level dataset recording the corresponding per-user information.
Traffic must represent the conditions the controller is expected to handle. A dataset in which only one slice is active does not provide sufficient information for learning resource contention between slices, so the training environment needs to expose the controller to different combinations of eMBB and URLLC demand.
The four models are trained in stages. The URLLC scheduler is trained first, followed by the eMBB scheduler, which learns against the resulting URLLC scheduling behaviour. The slice controller is trained from collected RAN observations.
The pipeline also includes validation against a majority-class baseline. If the learned controller cannot outperform a simple constant policy, it should not be promoted to live operation.
Controlled deployment and runtime safety
Introducing ML directly into a running RAN requires controlled deployment. Slice-ML provides four stages:
- Collect, where the DU records data without running inference.
- Shadow, where the models receive live traffic and generate decisions, but those decisions do not affect the network.
- Slice control, where the ML controller may modify the allocation between slices while conventional per-UE scheduling remains in place.
- Full deployment, where both the slice controller and the per-slot ML schedulers are active.
The two control loops remain independent, so they can be enabled separately.
Safety mechanisms are built into the actuation path. A proposed slice change must pass hysteresis and runtime safety gates before it is applied, and the controller reads back the allocation actually applied by the cell rather than assuming a requested reconfiguration succeeded. If an ML model becomes unavailable or repeatedly exceeds its runtime deadline, the system falls back to the conventional scheduler.
This makes conventional RAN operation the safety net, rather than making network operation dependent on the continuous availability of an ML model.
Measured results
Compared against the conventional baseline on the same configuration:
| Metric | Baseline | ML | Improvement |
|---|---|---|---|
| Average reward | -3.605 | -3.188 | +11.6% |
| eMBB duty cycle | 75.40% | 85.70% | +10.3 pp |
| eMBB peak throughput | 100.9 Mbps | 101.5 Mbps | +0.6 Mbps |
| URLLC SLA satisfaction (SSR) | 0.189 | 0.307 | +62% |
| URLLC backlog | 495k | 420k | -15.2% |
The shape of the result matches the objective the controller was trained on. Peak eMBB throughput barely moves, while URLLC satisfaction rises by 62% and backlog falls by 15%. The reward weights an SLA breach far more heavily than a megabit of throughput, so a controller trained on it is expected to trade throughput for reliability whenever the two conflict.
Building a reusable AI-RAN capability
Slice-ML extends the AI-RAN principles already established in OCUDU into network slicing.
The important capability is not a single LSTM or attention model. It is the complete lifecycle around those models: RAN data collection, offline training, model verification, lightweight DU-side inference, controlled actuation, runtime monitoring, model validation and safe fallback.
Models can also be replaced without restarting the running DU. A validated model can be loaded and atomically swapped into the runtime while the RAN continues operating. This creates a foundation where new intelligent RAN applications can be developed without rebuilding the entire AI infrastructure for every use case.
Towards adaptive RAN resource management
Traditional slicing provides isolation and policy-driven resource allocation. Slice-ML adds another capability: adapting those resource decisions according to observed network conditions.
The RAN can move beyond a fixed allocation and continuously respond to changing traffic demand. At the slower timescale, intelligence determines how much capacity each service should receive. At the faster timescale, intelligence determines which users should receive that capacity. This hierarchical approach reflects the structure of the RAN itself: different decisions have different timescales, different constraints and different computational budgets.
As AI moves deeper into Open RAN, the goal is not to replace the RAN with machine learning. The goal is to make the RAN capable of using intelligence where it provides measurable value, while retaining the standards, timing guarantees, operational controls and safety mechanisms a real network requires.
Slice-ML is a step in that direction: from static resource slicing toward adaptive, hierarchical and intelligent RAN resource management.
Availability
- Documentation: Slice-ML: Hierarchical Deep Learning for RAN Resource Slicing
- Source: github.com/TOSSI-Foundation/OCUDU-RAN, branch
slice_ml
Related AI-RAN work: ML-based UL MCS, ML-based BSR periodicity and predictive CSI for link adaptation.