SMO - Service Management and Orchestration

Please see new O-RAN-SC Project: Service Management and Orchestration (SMO) ...

... and consider this page as outdated.

--

From O-RAN point of view, the SMO terminates O1, O2 interfaces, and the A1 interface (in the Non-RealTime RIC).

The O2 interface was out of scope of this page previously, but is considered in scope as of the July 2020 train.  (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 to existing open-source project - proposed components for an O-RAN-SC SMO distribution highlighted.