# A Survey on Open Radio Access Networks: Challenges, Research Directions, and Open Source Approaches
## 5 O-RAN Alliance Architecture
### Smo  
SMO is responsible for RAN domain management in the O-RAN architecture [58]. In the nutshell, SMO functions as the Management and Orchestration framework in O-RAN [5]. SMO provides RAN support in FCAPS; Non-RT RIC; and O-Cloud management, orchestration, and workflow management. The SMO framework has several components and interfaces such as the Non-RT RIC, A1, O1, O2, and open FH M-Plane. The relationships between these functions can be seen in Figure 10.  
Figure 10: O-RAN’s SMO framework.  
Figure 9: Logical architecture of O-RAN.  
The O1 interface enables SMO to support the FCAPS of other O-RAN network functions. On the other hand, O2 interface is used by SMO for O-Cloud management, orchestration, and workflow management. Open FH M-Plane is used for FCAPS functionality from SMO specifically to O-RU. The Non-RT RIC function is to support non real time intelligent RAN optimization and perform intelligent RRM. The interface between Non-RT RIC and Near-RT RIC is called A1. The responsibility of the Non-RT RIC is to facilitate the operation of Near RT RIC functions within the RAN via A1 interface. The A1 interface can support three types of services: policy management, enrichment information, and ML model management.  
As shown in Figure 10, the Non-RT RIC is further divided into two sub-functions. The first function is the Non-RT RIC Applications (rApps), which are applications to perform RAN optimization [6]. Second is internal SMO framework functionalities that terminate the A1 interface and expose services to the rApps through R1 interface. Non-RT RIC framework also hosts data management and exposure; and AI/ML workflow. There is also an internal messaging infrastructure for communication between Non-RT RIC with other SMO functions.  
O-RAN's operation and maintenance (OAM) is directly related to O-RAN's O1 and O2 interface of SMO. O-RAN's OAM architecture points out management services, managed functions, and managed elements supported in O-RAN. Figure 11 shows the logical architecture of OAM. From the figure, we can conclude that O2 is an interface to manage O-Cloud while O1 interface will manage other O-RAN building blocks from Near-RT RIC to o-eNB. Currently, OAM itself has two use cases: O-RAN service provisioning and O-RAN measurement data collection. Service provisioning focuses on supporting connectivity in/between physical network function (PNF) and VNF. MNOs can also operate and maintain the network through service provisioning. O-RAN measurement data collection focuses on collecting measurement data from the network so that the Non-RT RIC can do AI/ML training/inference/analyzing for optimization.  
Moreover, there are actually several OAM models and deployment options, which are flat, hierarchical, and hybrid management models [59]. In the flat management model, all the O-RAN architecture entities are managed by the SMO through the O1 interface. The O-eNB, O-CU, O-DU, and O-RU are called managed functions (MFs) or managed elements (MEs). In the hierarchical management model, some MFs are allowed to manage lower-level MEs. An example would be the O-DU managing the O-RU. Lastly, the O-RU  
Figure 11: O-RAN’s OAM architecture.  
management responsibility could be shared between O-DU and SMO. This model is called the hybrid management model.  
From the previous section, It is clear that WG2 and WG10 are responsible for the components within SMO. As of now, the development of SMO is led by Windriver. Ericsson focuses on the development of Non-RT RIC. In addition, the development of OAM is led by Highstreet Technologies. In the G release of OAM projects, the configuration of Network Functions (NF) using YANG models over NETCONF is supported through the O1 interface. As a whole, the O-RAN SMO standard is currently still under development.