...
b. exports a Northbound Interface that administrators use to control Aether.
Models
ROC is driven by a versioned model defined in the YANG language. This model is an abstraction of the configuration of the underlying SD-Core and to a lesser extent the SD-RAN.
The Aether 2.1 specific model defines the top level objects like Site and sub-objects like Small Cell, Sim Card, Device, Slice etc. The Application is also a top level object that can be deployed across Sites.
Through tooling the ROC API definition is driven through the model. ROC can support several models simultaneously to support different versions of SD-CORE (e.g. during an upgrade).
ROC REST API
Through tooling, the ROC API definition and implementation is created from this model as aether-roc-api.
Config store
ROC builds on µONOS, in particular, the onos-config microservice, which is also driven off the YANG models, providing transactional updates with a distributed storage backend.
onos-config has a gNMI interface on the Northbound and pushes configuration changes to registered devices or services on the Southbound (also through gNMI).
SD-Core Adapter
ROC updates the SD-Core through the SD-Core Adapter (which is one of these registered services). As ROC pushes these changes down to SD-Core it translates them in to the REST API of SD-Core (web-config).
The SD-Core Adapter also has the ability to listen to updates from the SD-Core and to make these available through gNMI up to onos-config and up to the aether-roc-api.
ROC GUI
The ROC GUI (aether-roc-gui) is a Web UI that sits in front of the aether-roc-ui giving a user friendly view of the aether-roc-api. While some tooling exists to help update the UI for new models it is not a fully automated process.
The ROC GUI, API and onos-config are multi-tenancy capable, with Authentication through Keycloak (OIDC) and Authorization using Open Policy Agent.