Skip to end of metadata
Go to start of metadata

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

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)

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.

Related Jiras

OAM-31 - Getting issue details... STATUS OAM-48 - Getting issue details... STATUS

SMO componentProtocol
Target release for deploymentO-RANMANOOpenNMSONAPothers
A1 Policy Agent
mandatory

Bronze

OAM-31 - Getting issue details... STATUS

Non-RT-RIC



A1 REST clientREST clientmandatory

Bronze OAM-31 - Getting issue details... STATUS

Non-RT-RIC

ODL/CCSDK/SDNC (Amber)
A1 dashboardWeb applicationpreferred

Bronze OAM-31 - Getting issue details... STATUS

RIC dashboard

(non-rt-ric, near-rt-ric)





O1 NetConf/YANG terminationNetConf/YANG clientmandatory

Bronze OAM-31 - Getting issue details... STATUS




ODL/CCSDK/SDNCOpenDaylight → Apache Karaf
O1 VES terminationVES servermandatory

Bronze OAM-31 - Getting issue details... STATUS




VES collector
HV-VES collector (optional)

O1 dashboardWeb applicationpreferred

Bronze OAM-31 - Getting issue details... STATUS




ODLUX
Message bus
mandatory

Bronze OAM-31 - Getting issue details... STATUS


Apache KafkaApache KafkaDMaaPApache Kafka
Persistent databasedatabase cluster
(no-sql, sql)
mandatory

Bronze OAM-31 - Getting issue details... STATUS


Mongo DB
mySql

ElasticSearchElasticSearch for FCAPS
mariaDB in general

ElasticSearch
mariaDB

Service provisioning
preferredCherry or later


SO
Optimization
preferredCherry or later


OOF
Policy
preferredCherry or later


Policy
Data analytics
preferredCherry or later


DCAEAcumos
InventoryREST (AAI-API)preferredCherry or later


A&AIElasticSearch
Certification server
preferredCherry or later
keystore
AAF
Logging
preferred

Bronze  OAM-48 - Getting issue details... STATUS




ElasticElasticSerach, Kibana
Logging dashboardWeb applicationpreferred

Bronze OAM-48 - Getting issue details... STATUS




Kibana



  • No labels

4 Comments

  1. When is O2 considered in scope?

    1. o2 is in scope once the O-RAN Specs are public available and O-RAN-SC and permission to use them. 

  2. If O2 is out of scope for Cherry release (as I understand from these timelines), is there an assumption that the SMO will find instances of RIC, CU, DU and RU already instantiated and ready to be used? How does the SMO learn of these instances, and has the configuration to say talk over the O1 interface using NETCONF?

    1. For O1 interfacing there is the PNF-Registration message send by the O1-O-RAN components via HTTP1.1/JSON. My understanding of the O-RAN-OAM Interface Spec (O1) is that this PNF-Registration should be also used for VNFs/CNFs - it may overlab then with O2 - I mean, if SMO deploys the O-RAN-components it should know about each instance and the O-RAN topology for A1, O1, E2 but also F1 and the interfaces towards the 5g-Core.

      (more questions than answers (wink))