Service Management and Orchestration (SMO)
SMO
Introduction
The SMO supports a number of interfaces. These include
Topology & Inventory (TEIV)
O1 Interface
The O1 interface supports the NETCONF protocol to configure and manage the network elements in the O-RAN solution. These network elements include Near RT-RIC, O-CU, O-DU and O-RU. The SMO uses data models to drive the configuration and management of the network elements. For an example of how the SMO (NETCONF client) interacts with the RIC, CU, DU and RU (each of which are NETCONF servers), see diagram below. The implementation is based on the NETCONF implementation of OpenDayLight (ODL), and User Interface (UI) is based on ODL Community GUI (DLUX).
The SMO can offer REST APIs that can be used to drive the configuration on the RIC, CU, DU and the RU.
For details on NETCONF/YANG see this page.
Developer Notes
The SMO acts as a NETCONF client on the O1 interface, with the network elements acting as NETCONF server.
The SMO is evaluating several options to implement the NETCONF client.
Implementors of NETCONF server on the network elements such as Near RT-RIC, O-CU, O-DU and O-RU have several options to use or implement from. One open source option is Netopeer2. Whatever source is used to implement the O1 interface do note that it needs to support YANG model for NETCONF monitoring. The ietf-netconf-monitoring support allows the NETCONF client to list and download all YANG schemas that are used by the device. NETCONF client can only communicate with a device if it knows the set of used schemas (or at least a subset).
Testing of Data Models
SMO is collaborating with OAM project to test and drive the data models being published for the O-RAN solution. These models could come from 3GPP or from O-RAN itself. The models themselves will reside in the NETCONF server, e.g. in the near RT RIC, O-CU-UP, O-CU-CP, O-DU and the O-RU and will be requested by the NETCONF client, e.g. the SMO at the time the NETCONF session is established. Thereafter, an application like Postman can drive the north bound APIs exposed by the SMO. Example of these configuration snippets will appear in a Gerrit repository near you. For a visual of what the test framework looks like see the following diagram:
SMO and App Onboarding
Introduction
One of the purposes of the SMO is to onboard applications, whether they are rApps running on non-RT RIC, or xApps running on near-RT RIC. After they are onboarded, the SMO needs to keep an application package catalog for what applications are available for the operator to deploy or create instances of.
To be able to onboard those applications, the SMO needs to be able to understand how the application is packaged. Details of that are discussed below. Following that is a discussion on around what an application package catalog is supposed to expose so that an operator can trigger a deployment of an application.
Application Package Schema
The SMO project is trying to define the schema for the package. For details on the proposal and the comments on the proposal, see the this link. The proposal follows the package schema defined by ETSI NFV SOL 004 that defines the schema for packaging VNF Descriptors (VNFD) for both TOSCA and YANG data model definitions. The idea is to build on the package definition, and use it for application packaging.
Application Package Catalog
See updates here on details of an application package catalog here.
O1/VES Interface
The O1/VES interface supports the monitoring side of SMO. The diagram below shows how the Network Elements interact with the O1/VES interface in the SMO.
Another view of the same can be seen in the diagram below. In this case the events are picked up by the VES Agents which formats them in the form of a VES Event and sends it towards the VES Collector. The VES Collector stores the events in InfluxdB and alternatively to the Elasticsearch engine and/or the Kafka bus. The event data can then be picked up by Grafana or any other application to perform any analysis on the data.
