## 3 AI/ML in the Standards and Industry
### Open RAN
#### 3.3.2 Use Cases and Challenges in Open RANs  
The O-RAN Alliance has already specified several use cases leveraging the O-RAN architecture and AI/ML. These use cases, along with their key benefits, are listed in Table 4 as potential research topics [100]. Of them, traffic steering was studied in [101], using a network architecture compliant to that proposed by O-RAN. Specifically, an LSTM is trained in the non-real-time RIC based on data collected from a real-world ultra-dense data traffic scenario. The trained NN is sent to the non-real-time RIC to predict the traffic in the considered area and proactively apply cell splitting by activating small cells inside the congested cells. Another use case, namely, scheduling control in sliced 5G networks through the non-real-time RIC, is investigated in [51]. A DRL agent selects the best scheduling policy, among water-filling, round-robin, proportional-fair, or max-min, for each base station and RAN slice. Both studies in [51,101] report promising results by adopting closed-control optimisation loops based on AI/ML in Open RANs. The adoption of Open RAN architecture does not come without challenges. Firstly, there might be conflicts between xApps developed by different vendors. Consider, for instance, ML models produced independently for load balancing and handover that run in parallel. The former might allocate a UE to a neighbouring cell that is less congested,  
Figure 9: The open interfaces in the architecture proposed by the O-RAN Alliance and the three closed-control loops. Note that some of the functionality of the DU, e.g., low PHY layer operation, might move into the RU depending on the use case and deployment constraints and is known as split 7.2. Traditional 4G deployments use split 8. Moving functions from the DU to RU reduces latency and decreases the fronthaul bandwidth requirements at the cost of added complexity in the RU. See [99] for an overview of functional splits. The RU is deployed at the cell site, the CU/DU are usually located at the edge, while the RICs might be placed at the edge or cloud depending on the use case. One near-real-time RIC can control thousands of CUs, DUs, gNBs or eNBs. and the latter might handover the UE back, creating ping-pong effects. As a result, it is incumbent to resolve inter-operability issues and xApps conflicts. Secondly, Open RAN needs to work together with the existing wireless technologies that will still occupy a significant market share in 2025. In this direction, the Open RAN project group inside TIP focuses not only on 5G, but also on implementing software-defined 2G/3G/4G RANs with general-purpose hardware. Actually, most of today's Open RAN deployments are 4G. Thirdly, customised Open RAN solutions are needed for private 5G deployments with specialised use cases. Finally, since the network elements can belong to different vendors, suboptimal performance should be expected in early developments. Therefore, it will not be possible to tell whether Open RAN is the leading choice until we witness deployments in dense urban scenarios, with integrated massive MIMO and not just Open RAN in rural environments. The O-RAN Alliance created the O-RAN software community inside the Linux foundation to professionally manage its open-source software. Since November 2019, there have been three software releases, with the fourth planned for July 2021. Rakuten was the first to implement a multi-vendor RAN in 2019. In 2020, NTT Docomo successfully connected a 5G baseband unit developed by NEC and Samsung with RRUs from other vendors complying with O-RAN specifications. In the U.K., Vodafone has already deployed rural Open RAN sites; see [102] for more case studies. Nevertheless, O-RAN deployments have so far concentrated on vendor interoperability; implementing intelligent controls (the RICs), which are key pieces in the O-RAN architecture, is not expected to run commercially until the end of 2021.