|SMO component||Protocol||Target release for deployment||O-RAN||MANO||OpenNMS||ONAP||others|
|A1 Policy Agent||mandatory||Non-RT-RIC|
|A1 REST client||REST client||mandatory||Non-RT-RIC||ODL/CCSDK/SDNC (Amber)|
|A1 dashboard||Web application||preferred|
|O1 NetConf/YANG termination||NetConf/YANG client||mandatory||ODL/CCSDK/SDNC||OpenDaylight → Apache Karaf|
|O1 VES termination||VES server||mandatory||VES collector|
HV-VES collector (optional)
|O1 dashboard||Web application||preferred||ODLUX|
|Message bus||mandatory||Apache Kafka||Apache Kafka||DMaaP||Apache Kafka|
|Persistent database||database cluster|
|ElasticSearch||ElasticSearch for FCAPS|
mariaDB in general
|Service provisioning||preferred||Cherry or later||SO|
|Optimization||preferred||Cherry or later||OOF|
|Policy||preferred||Cherry or later||Policy|
|Data analytics||preferred||Cherry or later||DCAE||Acumos|
|Inventory||REST (AAI-API)||preferred||Cherry or later||A&AI||ElasticSearch|
|Certification server||preferred||Cherry or later||keystore||AAF|
|Logging dashboard||Web application||preferred||Kibana|
Tracy Van Brakle
When is O2 considered in scope?
o2 is in scope once the O-RAN Specs are public available and O-RAN-SC and permission to use them.
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?
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 )
I have a comment related to Certification server... currently the plan is to use the AAF from ONAP, while ONAP is depreciating AAF soon.
It would make sense to use a more future-proof component, like Keycloak / Istio ServiceMesh.