# A Survey on Open Radio Access Networks: Challenges, Research Directions, and Open Source Approaches
## 6 Challenges and Future Research Directions
### O-RAN Alliance Architecture Issues
In [62], the terms lookaside and inline accelerators are explained. However, these specifications still lack the details needed for standardization. The method to access or utilize those accelerators, the accelerator's API design and usage, and the definition of whether the accelerator is \"dedicated or not\" are not defined yet by O-RAN. Since accelerators are used in O-DU low, and Intel is the company responsible for developing OSC's O-DU, the only accelerator that is compatible with the O-RAN code reference in the market right now is only the field-programmable gate array (FPGA) by Intel. Nevertheless, some vendors implement the DU independent of Intel, such as using Nvidia graphics processing unit (GPU) and Xilinx's FPGA [77] as accelerators. Qualcomm will also introduce its accelerator card to bring more competition to the market. Using accelerators makes vDUs more expensive than regular DUs [5]. Another solution to x86's need for accelerators is changing to a reduced instruction set computer (RISC) or RISC-V-based processors like ARM or C5 that have more powerful computation power for the L1 and L2 processing that O-DU needs to handle. This solution will eliminate the need to use accelerators. Besides having better computation power, ARM-based processors are also more cost-efficient compared to traditional processors [78]. We will dig into details about this comparison in the next subsection. Aside from the accelerator issue, interesting research studied the RU-DU resource assignment problem. The construction and maintenance cost of the O-DU is proportional to the amount of O-DU resources the cluster of connecting O-RUs uses over the operating time. MNOs are looking for intelligent assignment strategies for minimizing this resource, thus saving energy and providing free physical resources to support other services. The research carried out by [79] mentioned that efficient RU and DU resource management can be achieved by embedding a deep RL (DRL)-based self-play approach in RAN architecture, thus making the operation of RAN more cost-effective. Future research could be directed towards RU-DU resource assignment with multiple resources and large-scale RAN, leading to cost and latency problems. O-FHI's M-Plane is currently still being defined, just as we have mentioned before. Regarding this problem, a design of an M-plane for the next 5G O-FHI is proposed [80]. It is planned that the M-plane will support the initialization, configuration, and management of the O-RU. They also embedded several functions for the M-plane, including a \"start up\" installation, software configuration and performance, software fault, file management, and many more. The M-plane is designed based on O-RAN's YANG model and includes O-RU controllers powered by a network configuration (NETCONF) protocol over Secure Shell (SSH). As it happens, the O-RAN Alliance has released a few specification documents for the M-Plane, which are [81; 82]. Security in the M-Plane has received attention. The prior specification uses SSH version 2 with a simple public key and password authentication. This approach has weak security, does not meet industry best practices, and violates USG guidance [44]. Transport layer security (TLS) with public key infrastructure (PKI) X.509 certification usage in the M-Plane was recommended for improved security [44; 83]. Nonetheless, this new additional specification is optional for the MNOs to consider. For further details, please refer to [81]. While the O-RAN Alliance has already specified the security protocol for the M-Plane, no requirements are defined about the CUS plane. Adding a security protocol would compromise the latency budget and performance. The usage of MAC security (MACsec) for the CU-plane security of the O-FHI is proposed [84]. MACsec will be added with an ephemeral key exchange in the CP, while MACsec authentication only is proposed for the UP. MACsec is an optional security protocol in the eCPRI, so this proposal aligns well with the O-RAN Alliance specifications.