Page History

...

• Proposed name for the project: RunTimeConfigDB
• Proposed name for the repository: RunTimeConfigDB

Table of Contents

Project description:

The RunTime Config DB is a platform component that is designed to serve as a data repository for Run time data that needs to be persistent. The RunTime Config DB 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 run time. 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 , requested, or that are used by xNFs during run time. For example, in 5G Network, 5G PNFs may need to adjust a tower electrical antenna tiletilt. 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 orchestrates how ONAP shall operate. For example, Policy, CLAMP Control Loops, and Operational ViewsView type information.
• DATA LAKE - Architecturally, the RunTime Config DB 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).
  
• ENABLED FUNCTION - The RunTime Config DB 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.
  • CM FUNCTIONS - Enables OSS configuration, optimization, and LCM operations.
    
  • SYNCING - The RunTime Config DB enables the ability to sync data between initial and delta changes ONAP & the xNFs.
  The
  • 
    
  • DATA RECOVERY - It will allow for the recovery of data once a source of truth
  can be
  • is defined.
• CM FUNCTIONS - Enables OSS configuration, optimization, and LCM operations.
  
• • UPDATES - It will allow for updates, delta changes, and incremental updates to be performed.
  • RESTORATION - It will allow for the recovery and restoration of data to a fall back point.
  • DATA HISTORY - It will allow an operator to see a history of changes in data. This will includes the versioning of the data, which is also associated with updates, roll back, restoration.
  • AUDITING - It will allow for auditing of configuration and parameters against a "golden" template. It itself stores & provides the data for another thing to perform the auditing. Consistency checks.
  • ROLL BACK - It will allow for rollback back to "save points" or recovery points.
  • ACCESS CONTROL - A security topic, which allows the definition of policies, of who and what they can update.
  • 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)
  CM FUNCTIONS - Enables future CM & Data management functions such as xNF Crash restoration, data restoration, data history management and auditing
  • .
• 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.
  
• SCOPE - The Run Time DB could also serve as the data storage to store for example ONAP Policy Rules, CLAMP Control Loop, Operational Views and also accommodate other resources.
• The DB shall be designed to accommodate distributed operation as part of its role in the ONAP installation.

Image Added

Scope

Functionality supported by a RunTime Config DB:

   The RunTime Config DB does several functions:

Functional Flow

The flow and operation of RunTime Config DB is described at this wiki:

   ARCHCOM: InfoFlow - RunTime Config DB Information Flow

Seed Code:

RunTime Config DB code will be based on seed code implementing the design tool and cockpit.

The current functionality of this component includes:

Design

• x.

• x.
• x

Runtime

• x

Architecture Alignment

• Below we show how the RunTime Config DB application fits into ONAP

Image Added

Operational Description

RunTime Config DB operation is described:

DEPENDENCIES

ONAP Project Dependencies

RunTime Config DB depends on the following ONAP projects:

• AAF / Security
• DMaaP (DCAE)

Open Source Dependencies

RunTime Config DB depends upon the following open source projects:

RESOURCES

•Primary Contact Person:

  NGx

Other Contact/Contributor Person (LAST NAME in capital followed by first name !!):

x

Key Project Facts

Project Name:

• JIRA project name: x (suggestion to be decided)
• JIRA project prefix: x (suggestion to be decided)

Repo name:

• org.onap.x (suggestion to be decided)

Lifecycle State: incubation

Primary Contact: xT 

Project Lead: x

mailing list tag [clamp] (suggestion to be decided)

 Committers & Contributors see Resources section

TSC APPROVAL

*Link to TSC approval: 
Link to approval of additional submitters: 

ASSOCIATED FILES

USE CASES

The first use case and usage of this project will be a Run-Time Configuration data persistency application applied to the OOF/SON PCI Release 6 Use Case.

OOF (SON) in R5 El Alto, OOF (SON) in R6 Frankfurt

It may also be used in the Network Slicing Use Case in R6 as one of its first applications:

NETWORK SLICING PoC in R6 Frankfurt (Obsolete)Image Removed