...

• 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) COMPONENT DATA used by ONAP components to persist data does not belong in A&AI and is not part of the xNF models.
• DATA LAKE - It is designed to be a common services data layer which can serve as a data lake for xNF data.
  
• SYNCING - The RunTime DB enables the ability to sync data between ONAP & the xNFs. (The source of truth can be definedefined). (FUTURE)
  
• 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.
  

ACCESS (READ/WRITE):

• READ ONLY xNF Data - Run-Time parameters can be READ/WRITE by any ONAP platform component and any ONAP plug-in via the xNF data access interface. Examples of ONAP platform components are A&AI, SDC, SDNC etc.
  

• READ/WRITE Non-xNF Data - 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, Controllers (CDS, APPC, SDNC) will have default read/write access to RunTime DB

• by owner.
  

• ACCESS CONTROL - The data owner may grant permission to other components to READ and/or WRITE non-xNF data.  (FUTURE)DEFINABLE - Other components will have default read-only access to RunTime DB but can be given Read/Write access on a per record basis.

SYNCING (INVENTORY):

• ELEMENT SYNC - Software keeps the A&AI elements with the elements in the RunTime DB in Sync. 

• 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 CPS (xNF Proxy) - The RunTime DB is a master CPS is the owner (within ONAP) of the associate (exo-inventory) data associated with the entitiesxNFs.
• DYNAMIC VIEW - When a xNF appears or is removed from the system, RunTime DB CPS records will be added/removed based on A&AI entries.

INDEXING:

• INDEXING - Data Records will be indexed by xNF (VNF, PNF, ANF).
• RETRIEVAL - How are data records retrieved efficiently. This relates how the records are indexed.

...

4. Known system limitations

In Honolulu, the inventory, xNF models, and initial data will be statically defined in files. This will be coordinated with other components participating in the E2E network slicing use case. Changes to these definitions will require a redeployment of CPS.

5. Used Models

RunTime DB uses the following models:

• Inventory Model (Run time platform data model)
• ran-network@2020-08-06.yang

6. System Deployment Architecture

CPS will be deployed as two micro services:

1. PostgreSQL µS – requiring a physical volume
2. CPS µS – providing all interfaces described above

7. New Capabilities in this Release

This release, RunTime DB CPS adds the following Capabilities:

• Model LCM
• Generic data CRUD
• xNF data CRUD
• xNF data write forwardingIn R6 Frankfurt.

8. References

1. In The R7 this will be PoC which is described here: High Level Design (PoC)
2. Ongoing development: