...
- Flow 1 (Write) - VES Configuration information coming from PNF xNF via e.g. CM Notify
- Flow 2 (Write) - New xNF is added or deleted from ONAP; A&AI notification xNF update.
- Flow 3 (Write) - Controller - Micro-Service or ONAP component writing & updating operational information
- Flow 4 (Read) - Data is read from RunTime Config DB
...
- RunTime Config DB
- Operations Specialist (ONAP user)
- Controller/ONAP Component, A&AI, VES collector/DMaaP
...
wiki describes a more detailed figure and description of the component.
PURPOSE OF RUNTIME CONFIG DB:
REPOSITORY - The types of data that is stored in the Run-Time data storage repository for:
(1) CONFIGURATION PARAMETERS used by xNFs in run time. For example 5G Network run-time instance configuration information. and
(2) OPERATIONAL PARAMETERS used by ONAP and xNFs. Exo-inventory information is information that doesn't belong in A&AI.
- (3) POLICY INFORMATION - FUTURE - Policy, CLAMP Control Loops, Operational Views
- DATA LAKE - It is designed to be a common services data layer which can serve as a data lake.
- SYNCING - The RunTime Config DB enables the ability to sync data between ONAP & the xNFs. (The source of truth can be define).
- CM FUNCTIONS - Enables OSS configuration, optimization, and LCM operations. (FUTURE)
- CM FUNCTIONS - Enables future CM & Data management functions such as xNF Crash restoration, data restoration, data history management and auditing. (FUTURE)
- 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. (FUTURE)
- SCOPE - The Run Time DB could also serve as the data storage to store for example ONAP Policy Rules, CLAMP Control Loop, Operational Views (FUTURE) and also accommodate other resources.
...
- READ ONLY - Run-Time parameters can be READ by any ONAP platform component and any ONAP plug-in. Examples of ONAP platform components are A&AI, SDC, SDNC etc.
READ/WRITE - Parameters can be READ/WRITE from Controllers, DCAE (future), VES Collector/DMaaP, A&AI, Policy/CLAMP (future) and other components with permission settings.
- DEFAULT - SO (future), DCAE, A&AI (indirectly), Controllers (CDS, APPC, SDNC) will have default read/write access to RunTime DB
- DEFINABLE - Other components will have default read-only access to RunTime DB but can be given Read/Write access on a per record basis.
...
ELEMENT SYNC - Software keeps the A&AI elements with the elements in the RunTime Config DB in Sync. . When the network first being established, a GetAllPNFs function from A&AI can be used on startup.
- A&AI - A&AI is still the master of valid entities in the network and provides a dynamic view of the assets (xNFs) available to ONAP
- RUN TIME DB - The RunTime DB is a master of the associate (exo-inventory) data associated with the entities.
- DYNAMIC VIEW - When a xNF appears or is removed from the system, RunTime DB records will be added/removed based on A&AI entries.
...
- INDEXING - Data Records will be indexed by xNF (VNF, PNF, ANF). It would be an objective to have a similar indexing mechanism as A&AI. May also need an index to be a logical object ID.
- RETRIEVAL - How are data records retrieved efficiently. This relates how the records are indexed.
...
1 INFORMATION FLOW DATA WRITTEN TO RUNTIME Config DB:
Information Flows show data being written to the Runtime Config DB
...
2 INFORMATION FLOW DATA READ FROM RUNTIME Config DB:
Information Flow from RunTime DB
...
The Run Time Config is schema for the records RunTime Config DB are defined in advance. In the future (later releases) the RunTime Config DB schema may defined data structures on the fly.
Topology-type can be represented through the xNF associations in the schema
DESIGN TIME - The schema of data structure of RECORDS the run Time Config DB can support are created and defined in advance.
...