# On the Rollout of Network Slicing in Carrier Networks: A Technology Radar
## 6 RAN Domain
### Functionality
These assetsare aimed at reducing the impact that virtualization overheads may introduce on DU packet-processing performance. Industry stakeholders (including operators) have started to test these two solutions, validating their performance and assessing their techno-economic viability in typical scenarios where the vDU is shared across slices. In parallel, operators have launched a new activity on RIC, pushed by the O-RAN momentum. Unlike the first workstream, focused on searching for a baseline RAN slicing environment that can be easily scaled and replicated across the operator's service footprint, this new workstream has the goal of checking how the RIC can further enhance RAN slicing features. As noted in [55], the RIC is a non-mandatory O-RAN component consisting of two modules: (i) near-RT RIC, which hosts ms-level RRM logic with embedded intelligence; and (ii) non-RT RIC, which provides delay-tolerant functionality including service and policy management, RAN analytics and AI/ML model training. Figure 12 provides details on these two modules. In this testing phase, the focus is on the **near-RT RIC** (near-Real Time RIC), and in particular on the capabilities of the E2 interface [58]. In the long run, when the commercial O-RAN solutions are relatively stable, operators may focus on how to include the entire RIC in the day-to-day operation of RAN slices, making it more agile and intelligent [59]. In this regard, the following solutions are currently being explored:  
* **xApps**. As seen from Figure 12, the near-RT RIC delivers a robust, scalable and secure platform for xApp hosting. These xApps are third party control applications that complement traditional RRM functionality, by bringing advanced algorithms applicable to real-time use cases, including QoS/QoE optimization, per-UE controlled load balancing, traffic steering and seamless handover control. Operators together with third party developers are exploring the possibility of implementing slice-specific RRM procedures through xApps, in order to decouple life cycles of slicing related innovation (e.g., 4/6-month release cycle) from CU-CP hosted RRM policies (e.g., 1/2-year release cycle). * **Non-RT RIC**. The non-RT RIC (non-Real Time RIC) will be the main driver for AI-powered RAN slicing. This module will host and manage all AI/ML models that will later be pushed into the near-RT RIC down to the individual RAN slices. In the exploratory phase, where the operators are now, the main entry barrier they have encountered is its complex integration. In fact, the non-RT RIC needs to communicate with (i) the RU and the vEMS, using O1 interface [60]; (ii) the near-RT RIC, using A1 reference point [61]. In addition, it needs to interact with 3 GPP management system, something that today is still under discussion in O-RAN community. Figure 12 illustrates the integration of all the O-RAN components into the network slicing system architecture, including the reference points (E2, O1 and A1 interfaces) across them. To illustrate the information exchanged between these interfaces, we propose an example of the use of the RIC to make an AI assisted resource control for RAN slice SLA assurance. The logic of this resource control is hosted by xApps. Further details on this example can be found at the end of Section 6.2, once the details on radio resource allocation are explained.