# On the Rollout of Network Slicing in Carrier Networks: A Technology Radar
## 6 RAN Domain
### Radio Resource Allocation
These solutions, listed below, are years away from being commercially available; in fact, they are still taking shape in the reference standards: 3 GPP and O-RAN Alliance. Therefore, they are captured in the explore ring in the radar. * **Static (Policy-based) Flexible Radio Resource Partitioning**. It allows for defining prioritized resources per slice, a feature which was disabled in the Hard Radio Resource Partitioning. With this new option, RAN slices can now be configured according to \"dedicated slice-profile 2\" and \"prioritized slice\" settings, as shown in Table 2. The definition of prioritized resources per slice boosts resource efficiency, at the cost of making gNB scheduler logic much more complex, with a larger number of decision-making variables that need to be computed in real-time. It is important to note that gNB scheduler can work with both hard and flexible radio resource partitioning solutions, as depicted in Figure 15. This example shows that the gNB is configured to serve four slices from two different PLMNs: PLMN#1, hosting mIoT, eMBB and uRLLC slices, and PLMN#2, hosting another eMBB slice. Looking at the slice specific quotas, one can note that the uRLLC slice is scheduled with hard approaches. For the remaining slices, flexible resource radio resource partitioning is applied, with the mIoT slice configured with \"dedicated slice-profile 2\" flavor and the eMBB ones configured with \"prioritized slice\" flavors. * **Dynamic (AI-assisted) Flexible Radio Resource Partitioning**. This solution takes the previous solution to the next level, with the possibility of changing slice resource quotas over time, depending on collected performance metrics. To cope with this dynamism, operators need to take humans out of the loop, replacing them with novel AI-assisted artifacts enabling closed-loop automation. The xApps hosted by the near-RT RIC are perfect candidates for this role; indeed, they can provide agility and context-awareness in the decisions of changing resource quotas [63]. Figure 12 illustrates an example of the usability of near-RT RIC for real-time resource control of operative RAN slices. As seen, the near-RT-RIC makes use of E2 interface to interact with associated DU, CU-UP and CU-CP instances, for both monitoring (E2 REPORT) and configuration management (E2 CONTROL/POLICY) actions. The governance of these actions lies on xApps. The logic of these xApps can be assisted with AI/ML models, which are made available for consumption by the non-RT RIC using the A1 interface. By comparing collected metrics against AI/ML models, the xApps can make real-time decisions on quota changes, enforcing them in corresponding CU-UP instances. Though the ultimate invocation and execution of AI/ML models lies on xApps, this cannot be done without the Non-RT RIC, which plays a key role in this work  
Figure 14: Feedback loop for delay controlled priority scheduling, with in-band L4S. RIC is responsible for the management of individual AI/ML model (e.g., AI/ML model deployment, configuration, performance evaluation, termination, validation and testing).