SMO - Service Management and Orchestration

From O-RAN point of view, the SMO terminates A1, O1 and O2 interfaces.

For now, the O2 interface is out of scope of this page (Please update, if you have publicly available information, it is assumed that all SMO software components can be deployed as docker containers. Larger SMO deployments may use kubernetes, smaller may use docker-compose)

• A1 termination: is covered by the O-RAN-SC Non-RT-RIC project
• O1 termination is covered by the O-RAN-SC OAM project

While A1 uses REST as communication protocol, O1 uses NetConf/YANG for configuration (GET and SET) and REST/VES for asynchronous notifications from O-RAN components.

Therefore we can say that as a bare minimum an SMO for O-RAN includes:

• A1 termination (REST Client)
• O1 NetConf/YANG termination (NetConf-Client)
• O1 VES termination (HTTP/REST/VES-server - also called VES collector)

All these O-RAN interface terminations on the SMO require communication between each other. In order to avoid the architectural and maintenance complexity of several point-to-point interfaces, a message bus between the SMO components is preferred. In order to view details and function, several dashboards would be beneficial and also a persistent database cluster and a certification server and logging capabilities. All the mentioned components should be dockerized for easy deployment and dynamic scaling.

SMO internal software components and its mapping existing open-source project - proposed components for an O-RAN-SC SMO distribution highlighted.