You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 63 Next »


1. Scope


DESCRIPTION: 5G RAN physical/logical topology information (SDN-R) Core & RAN elements. 5G Configuration, provisioning of a 5G Network. SDN-R should contain the 5G Network Topology. CM Audit. CM Mediation. CM run-time storage / data persistency (MariaDB)

WHEN EXECUTED: During Run Time, when data is written to the Runtime DB.

PURPOSE: RunTime DB serves as a data lake as a common service and data layer for ONAP components and micro-services.

INFORMATION PASSED: Configuration information (from CM Notify) or operational information (derived during ONAP operations).

ACTORS:

  • RunTime DB
  • Operations Specialist
  • Controller

For more information and exploration you can visit the RunTime DB Wiki at: 5G CONFIGURATION (RunTime DB)

OVERVIEW RUNTIME DB


See the: ARC RunTime DB Component Description - Frankfurt

A more detailed figure and description of the component.

PURPOSE:

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

  • DATA LAKE - It is designed to be a common services data layer which can serve as a data lake.
  • SYNCING - The RunTime 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.

ACCESS (READ/WRITE):

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

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 - 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:

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




OVERVIEW RUNTIME DB INFORMATION FLOW


Information Flows to Run Time DB or from RunTime DB


1 INFORMATION FLOW TO RUNTIME DB:

Information Flows to Runtime DB

New Information is written to RunTime DB from a Component or a Micro-service


2 INFORMATION FLOW FROM RUNTIME DB:

Information Flow from RunTime DB

Other components are reading from RunTime DB.

Taking information from RunTime DB and using it to send to xNF components


2. Pre-Conditions


ONAP is ready:

  • RUN TIME DB SETUP - RunTime DB has been setup properly and is ready to be used.
  • ONBOARDED ARTIFACTS - If dynamic setup is used, definition artifacts are onboarded and used to setup the RunTime DB structures
  • ONAP SOFTWARE - There is an ONAP installation. Software images loaded in OpenStack installation, where instantiation will happen (since no S/W image repository). Need to be available in Target Cloud Instances.

2.1 RUNTIME DB DATA STRUCTURE

2.1.1 DATA STRUCTURE

A data structure which is common for all different vendor xNFs will be used for the RunTime DB.

Domain oriented components can be used where all of those components share common information.

Any micro-service or ONAP platform component can define information in the data structure.


2.1.2 RUNTIME DB DATA LAYER


The RunTime DB is a Data layer common service data lake





3. Information Flow

These flows show the usage of RunTime DB

3.1 VES Information Flow

The following UML diagram shows the Information Flow for RunTimeDB


RunTime DB Information Flow PNF PNF VESCollector VESCollector DMaaP DMaaP RunTimeDB RunTimeDB RUNTIMEDB UPDATE CM Notification 1CM Notification Run Time DB Writing VES Event 2VES Event 3Subscription Writes Information 4Write Information

3.3 Flow Description: mS Information Flow


1. VES Event – VES Event Received

A VES event (CM Notify) is received from PNF

2. VES Collector – VES Collector gets the CM Notify

VES Collector gets the CM Notify

3. Publish on DMaaP – VES Collector publishes on DMaAP

VES Collector Publishes on DMaaP

4. Subscription on DMaaP – DMaaP gets the Notification

RunTime DB gets the Event and updates the information



3.1 xNF Update Flow

The following UML diagram shows the xNF Update flow from updates in A&AI for RunTimeDB


RunTime DB Information Flow AAI AAI DMaaP DMaaP RunTimeDB RunTimeDB VESCollector VESCollector RUNTIMEDB UPDATE xNF Update Notification 1Detects xNF Update 2CM Notification Run Time DB Writing Notification 3AAI Update Notification 4Subscription Updates xNF Update 5Updates xNF Information

The describes the xNF information updates and keys based on xNF update.


3.3 Flow Description: AAI Update Information Flow


1. AAI Determines update – A xNF has been removed or added

AAI determines a xNF has been removed/added

3. AAI publishes on DMaaP – AAI publishes on DMaAP

AAI publishes on DMaaP

4. Subscription on DMaaP – DMaaP gets the Notification

RunTime DB gets the AAI updates the information



3.1 mS UPDATE Flow

The following UML diagram shows Where another ONAP component or Micro-Service updates the RunTimeDB


RunTime DB Information Flow mS mS DMaaP DMaaP RunTimeDB RunTimeDB RUNTIMEDB UPDATE Info Update Notification 1Determines xNF Update 2Notification Run Time DB Writing Notification 3Update Notification 4Subscription Updates xNF Update 5Updates xNF Information

The describes the xNF information updates and keys based on xNF update.

3.2 mS Information Flow

3.3 Flow Description: mS Information Flow


1. Micro Service Determines Update Needed – fPackage.

There are multiple wayf system or any other conceivable way to deliver digital information.

2. PxY – Package is accepted into ONAP

the Vendor provided package is imported by a Technology Specialist/Asset manager into SDC.

3.4 Flow Description: PACKxK)


3. LICExCK – VNF-SDK performs a license file check within the vendor-delivered PNF package.

4. CxK – VNF-SDK performs a certificate file check within the vendor-delivered PNF package.

5. FIxCK – VNF-SDK examines the MainServiceTemplate.mf (Manifest file) and performs a cross-check of the files & pathway directories specified within the manifest faile against the actual files within the vendor-delivered PNF package. It checks that the files that have been specified in the manifest file are actually in the given destination (directories).

6. MxN – VNF-SDK performs a check of the PNF keywords in the MainServiceTemplate.mf (Manifest file). The tags are pnf_product_name, pnf_provider_id, pnf_package_version, pnf_release_data_time, and non-mano_artifact_sets.

7. TOxON – VNF checks the Meta Data file (TOSCA.meta) in the PNF package with the ETSI SOL004 validation tags. The checks performed are the Entry definition, Entry-manifest, Entry-change-log, Entry-tests, Entry certificates.

8. USxON – The end user may then inspect that the PNF package has been appropriately verified in the Certification studio.

3.5 FloxRDING

In the next steps, SDC brings that Vendor provided package into the SDC Catalog and creates an SDC internal representation of that package.



A. UUID IDENTIFIER – SDC adds a UUID identifier.

B. TOxATA – SDC adds additional TOSCA Meta-data.

C. TOxR – SDC may add a TOSCA Descriptor

D. LICxLE – SDC can add a license model file.

E. ADxCTS – The User may optionally manually add additional artifacts.


PAxING

There are two options to onboard into SDC. OPTION #1 is to "automatically" onboard a package.

In this case, a VSP model is created using an Onboarding package (PNF CSAR, VNF CSAR or Heat)

9. ONBOARD PACKAGE - The onboarding package is accessed by a Technology specialist/Asset manager

10. INTERNAL MODEL - An internal model is created in SDC with MetaData added.

11. TRANSFORM ARTIFACTS - The artifacts from the PNF or VNF package are transformed into onboarding artifacts during SDC onboarding.

12. ONBOARD DESCRIPTOR - SDC transforms the xNF onboarding descriptor (PNFD or VNFD) into an SDC internal descriptor.


4. Post Conditions

4a. Post Condition (Pre-onboarding)

The post-conditions for the pre-onboarding flow are the following. Once, pre-onboarded, the xNF is ready for onboarding.

  • PACKAGE VALIDATED - VNF-SDK has successfully validated the package (as a result of pre-onboarding) and verified the content that VNF-SDK can perform validation on (See the VNF-SDK Validation section).
  • Package SECURITY VALIDATION - The onboarding package is tested and validated for security.
  • Artifacts SECURITY VALIDATION - The artifacts of the onboarding package are tested and validated for security.

4b. Post Condition (Onboarding)

The post-conditions for the onboarding flow are the following. Once, onboarded, the xNF is ready for service creation.

  • Package SECURITY VALIDATION - The onboarded package is tested and validated for security.
  • VNFD/PNFD MODEL LOADED - The xNF Resource's Descriptor model is visible in SDC.
  • SDC INTERNAL PACKAGE EXISTS - The SDC Internal Package derived from the vendor provided xNF package has been successfully stored in SDC's catalog and is visible. All of the xNF artifacts, including the VES registration and PM dictionary/schema (for example) are visible and loaded properly.
  • Internal Package Function Tested - The internal package function is tested and validated.
  • ADDITIONAL ARTIFACTS - Additional manual artifacts can be incorporated into the Internal SDC xNF package.


REFERENCES


Wiki Page for RunTime Db 5G CONFIGURATION (RunTime DB)

Architecture component Description ARC RunTime DB Component Description - Frankfurt



SUPPORTING FILES & SLIDES

FilesFile


  • No labels