CPS in ONAP Architecture
The Configuration Persistence Service is a platform component that is designed to serve as a data repository for Run time data that needs to be persistent. It is characterized by the following purpose statements:
REPOSITORY - The types of data that is stored in the Run-Time data storage repository for:
(1) CONFIGURATION PARAMETERS - These are configuration parameters that are used by xNFs during installation & commissioning. Configuration parameters are typically used before the xNF has been brought up or is operational. For example, a 5G Network configuration parameter for a PNFs that sets the mechanical tilt which is a configuration setting upon installation.
(2) OPERATIONAL PARAMETERS - These are parameters that are derived, discovered, computed that are used by xNFs during run time AFTER the xNF becomes operational i.e. AFTER it has "booted up", been installed, configure. For example, in 5G Network, 5G PNFs may need to adjust a tower electrical antenna tilt. These operational parameters are Exo-inventory information, meaning it is information that doesn't belong in A&AI. In principle, some parameters might be both configuration and operational parameters depending on how they are used.
(3) POLICY INFORMATION - This type of information stores policy information that micro-services might need.
(4) APPLICATION INFORMATION - Information related to operational parameter.
DATA LAKE - Architecturally, the Configuration Persistence Service is designed to be a common services data layer which can serve as a data lake to other run time entities (ONAP components or external tools).
CPS FUNCTIONS - The Configuration Persistence Service enables functionality to be performed by other entities. It will ENABLE the capability of another components or external tools within/or external to ONAP to perform the functions.
**Configuration Management FUNCTIONS** - Enables OSS configuration, optimization, and LCM operations.
**TOPOLOGY TRAVERSAL** - It will enable the ability for something to traverse the relationship between data elements.
**MODEL ADAPTION** - Depending on the schemas used to define the DB data elements; it allows for the adaptation or transformation of models from other sources (e.g. ORAN or 3GPP models).
**CENTRAL/DISTRIBUTED** - Because it is a common service, it is part of an ONAP installation, so it could be deployed with either an Edge ONAP installation or a centralized ONAP installation. The DB shall be designed to accommodate distributed operation as part of its role in the ONAP installation.
CPS Concepts
- Dataspace is a logical separation of data
-Any application can define its own dataspace to store the model(s) and data it owns.
- Anchor is a logical separation of data within a dataspace
-e.g. can be used to distinguish (xNF) instances with of the same model
- Schema set is a representation of a Yang model
-Preserves the original format to avoid collisions and poorly defined models
- DataNode is a YANG container or YANG list
-A DataNode can have 0 or more descendants and together they form an data instance tree
- Leaves is the term used (as in Yang) for the attributes of a DataNode
OVERVIEW CONFIGURATION PERSISTENCE SERVICE INFORMATION FLOW
FLOW : micro-Service / Controller (SDN-R, SDN-C, APP-C, CC SDK) / other Component Updates for operational information - Information flow
Information Flow from CPS
Other components are reading from CPS.
Taking information from CPS and using it to send to xNF components
FLOW : Data is read from CPS
Race Conditions - a hysteresis (a time difference) between writing information (from a Kafka broker) and a read request arriving before the writing has finished.
Diagrams (sources)
the basic concepts diagram:
from CPS Internal Relation DB Schema