PROJECT NAME

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

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:

PURPOSE OF RUNTIME CONFIG DB:

• 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 that are used by xNFs during run time. 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 orchestrates how ONAP shall operate. For example, Policy, CLAMP Control Loops, and Operational View 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.
    
  • DATA RECOVERY - It will allow for the recovery of data once a source of truth is defined.
  • 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).
• 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.

SCOPE

Functionality supported by a RunTime Config DB

   The RunTime Config DB does several functions:

• RECEIVE INFORMATION - This is the ability to receive information from a source, for example DMaaP, which contains information that needs to be incorporated into the data base.
• WRITE INFORMATION - Configuration, operational and policy information is written into the database. Data received is written to the database via database write operations.
• PUBLISH CHANGES - When changes occur to the database, it shall have the capability to publish changes. This will take the form of notifications on the DMaaP bus to allow other subscribers to become aware of changes.
• REFERENTIAL INTEGRITY - When element updates occur, the component shall be able to maintain referential integrity. If elements are removed from the database, then associations or connections between elements may change and need to be updated.
• INGEST PACKAGES - SDC CSAR parser - Get SDC CSAR Service Package - getting key artifacts from vendor provided onboarded packages (CSAR).
• LOGICAL OBJECTS - The database shall support logical objects that are not PNFs, VNFs, or ANFs. These are objects that are elements that may logically represent entities that may need to be kept track of. An example might be a cell (carrier-sector) within a wireless RAN network.
• ASSOCIATIONS - These are "linkages" between elements within elements (or data records) in the database. So this database is a relational database in the connective sense of a relational database (as opposed to the composition sense of a relational database).
• CARDINALITY RULES - This allows for the specification of a cardinality of element associations.
• LINKING RESTRICTIONS - There may be rules which allow you to specify restrictions on the kind of associations that can be made.
• SYNCHRONIZATION - Real-time Synchronization allows for the database to reflect the state of the network. This also includes syncing with A&AI elements. A&AI is a real-time view of the resources and services available to ONAP to use. Thus, when a xNF gets created or deleted, these changes must be reflected also in the database.

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

• SHARED SERVICE - The diagram below shows how the RunTime Config DB project fits into the overall ONAP architecture as a shared (common) service serving as a data layer for other ONAP components.

• A&AI INDEPENDENCE - The RunTime Config DB stores information that is conceptual distinct from A&AI. The data is related because the DB also needs to keep track of the existence of xNFs; and A&AI is the master of resources & services. For more information about how information from A&AI is "synced" with the RunTime Config DB see the Operational Description section below.

• DATA LAYER - Architecture conclusions is that this component should serve as a data layer to other components and be a data lake serving as a repository for storing run-time information. It shall also be within the shared services part of the architecture. Architecture concluded that this project should be an independent component in ONAP platform.

• SCOPE (Type of Info Stored) - The type of information stored in the RunTime Config DB is run-time configuration, operational, and policy information.

• ARCHITECTURE CONSISTENCY - The project is consistent with a data-centric ONAP architecture.

The following are links to Architecture related pages that describe the flows and component interfaces:

OPERATIONAL DESCRIPTION

RunTime Config DB operation is described. The following sections describe the basic operations of RunTime Config DB.

BASIC CONCEPTS

• ASSOCIATIONS - These are "linkages" between elements within elements (or data records) in the database. Thus, this database is a relational database in the connective sense of a relational database (as opposed to the composition sense of a relational database).

• CARDINALITY RULES - This allows for the specification of a cardinality of element associations. For example, one PNF might have a limit to the number of associated logical elements, such as a Logical Cell that it is allowed to have.

• LINKING RESTRICTIONS - There may be rules which allow a operator to specify restrictions on the kind of associations that can be made. For example, an operator might want a particular kind of PNF to link to a specific kind of Logical object, such as a cell.

• DATA LAYER - This project is meant to serve as a data layer to other ONAP components. This means that it will be an intermediary for a component to write and access data.
• PERSISTENCY - The Runtime Config DB is meant to store data persistently, which means that it can hold data over time without losing it. 
• SYNCHRONIZATION - The concept of synchronization is the ability to align data between the database and something else, such as an external source, or a xNF. For example, the RunTime Config DB needs to synchronize to A&AI view of the available resources in the system. See the section on Synchronization below.

INITIAL SETUP & SYNCHRONIZATION OF DB

• A&AI GETALL - A&AI provides a "getall" function which will allow the DB to access a initial view of all of the xNFs in ONAP currently, rather than getting each of the xNFs individually from separate query requests.
• INITIAL VALUES - For each record that is setup, the individual attendant parameters associated with each record must also have some initial value. There are three cases:
  • (a) Some values may come from A&AI.
  • (b) Some values will be discovered during operation.
  • (c) Some information data may have default values defined in the schema.
• INITIAL SYNCHRONIZATION - The DB may also need to seek initial values for some of the parameters within the records, notably, those that need to come from a xNF, or external source (to ONAP). The mechanical tilt of an base station antenna value for example that value needs to come the source.
• LOADING SCHEMAS -These schemas would be loaded by an operator. There will be an initial way that it can get access to those schemas. Some schemas might be derived from a vendor package, or other information from an ONAP component. Overlapping information from A&AI will also be incorporated into the schema.

• INGEST PACKAGES - The DB must be able to get the output SDC CSAR Service Package. This will allow it to get key artifacts from vendor provided onboarded CSAR packages.

• LOGICAL OBJECTS - The database shall support logical objects that are not PNFs, VNFs, or ANFs. These are objects that are elements that may logically represent entities that may need to be kept track of. An example might be a cell (carrier-sector) within a wireless RAN network.

• 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).

DB SCHEMA

• MODEL DRIVEN - The RunTime DB is driven by its schemas. In this case the schema is the model, and it adapt the capabilities of the RunTime DB. It clarifies the type of data and relationships of those data that is stored in the DB. The schema define type of data information, its structures and relationships.
  
• PREDEFINED & DYNAMIC SCHEMA - The pre-defined schemas are basic mirroring of the topology (meaning the existence of specific xNFs and their relationship to each other) from A&AI. By topology information, the DB must have a view of the xNFs and their relationship to each other, without duplicating the specific parameters that are stored in A&AI. An operator could define manually, in a predefined manner, the data and relationships that the DB managed. A dynamic schema would be automatically composed from other sources, such as artifacts from vendor onboard packages.
  
• RULES - Rules can also be specified in the schema, and then enforced by the model. 

RECEIVE INFORMATION

• RECEIVE INFORMATION - This is the ability to receive information from a source, for example DMaaP, which contains information that needs to be incorporated into the data base. For example, a CMnotify VES event might come in from a PNF which holds a value the needs to be updated in the DB.

WRITING INFORMATION & DATA PERSISTENCY

• WRITE INFORMATION - Configuration, operational and policy information needs to be written into the database. Data received is written to the database via database write operations.
• DATA PERSISTENCY - Once data is written to the database, it must persist over time. Data must be kept with integrity over the life of the operation of the instance of the RunTime Config DB.
• WRITE NOTIFICATIONS - Write failures should result in notifications. Obviously this should be a rare occurrence.

PUBLISHING UPDATES

• PUBLISH UPDATES - When changes occur to the database, it shall have the capability to publish changes. This will take the form of notifications on the DMaaP bus to allow other subscribers to become aware of changes.

• SUCCESSFUL UPDATES - When data is updated successfully, an "ACK" takes the form of publishing updates. Which allows a subscriber to become aware of a successful update. For example, if a Micro-service requested a PCI value to be changed from a 10 to 20; the DB would publish that this PCI value has changed once it successfully updated the database.

SYNCHRONIZATION

• REFERENTIAL INTEGRITY - When element updates occur, the component shall be able to maintain referential integrity. If elements are removed from the database, then associations or connections between elements may change and need to be updated.

• SYNCHRONIZATION - Real-time Synchronization allows for the database to reflect the state of the network. This also includes syncing with A&AI elements. A&AI is a real-time view of the resources and services available to ONAP to use. Thus, when a xNF gets created or deleted, these changes must be reflected also in the database.
• SYNCING - The RunTime Config DB enables the ability to sync data between initial and delta changes ONAP & the xNFs.
• PERIODIC SYNCHRONIZATION - If there are notifications that are missed, the DB should periodically synchronize to make sure it is up to date. The operator should have some configurable period or strategy for synchronizing, for example, once a day. There should be some level of autonomy for automatically kicking off a periodic synchronization.

SCALABILITY

• SCALABILITY - I X

• ELASTICITY - I X

DATABASE MANAGEMENT FUNCTIONS

• DATA RECOVERY - It will allow for the recovery of data once a source of truth is defined.

• 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.

• SCOPE (Storage vs Ownership) - The DB STORES data, provides persistency, and gives access to data. The information is created, defined and used by other ONAP components. The OWNERSHIP and life cycle management is the responsibility of that other ONAP component. The DB stores the data but does not own the data. The result is that other ONAP components can freely access that data without other components creating new APIs. Thus, components don't have to have own data rather the database serves as steward of the data.

-

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:

• Benjamin Cheung

• Joanne Liu Rudel

Other Contact/Contributor Person:

• Sandeep Shah 
• Zu Qiang (Ericsson)
• Tony Finnerty
• David Kinsey
• KINGSLY LAWRENCE
• Swaminathan Seetharaman
• N.K. Shankaranarayanan
• Melanie Sater
• Anita Hai

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)

TSC APPROVAL

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

ASSOCIATED FILES

USE CASES

As some initial examples, to help the reader understand the use case. Some of the first uses and use cases involving 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)