ARCHITECTURE WORK

WIKI LINK

ARCHITECTURE FLOWS

ARCHCOM: InfoFlow - RunTime Config DB Information Flow

COMPONENT DESCRIPTION

ARC RunTime DB Component Description - R6 Frankfurt

PROJECT PROPOSAL

RunTime Config DB Project Proposal (Oct 25 2019)

Calendar Entry

Calendar now open for editing ... but how?

Community Meetings & Calendar

R6

CCSDK-based Solution

Project as part of CCSDK ( @Yuriy Malakov  )

R6 Frankfurt

In release requirements page: M4 March 5, 2020

Frankfurt Release Requirements (TSC has already approved Green status for U/C).

CCSDK, SDN-C - Dan Timoney MVP (min viab. product) discussed on SDN-C call. Req not totally clear, schema model. Take what is in ConfigDB; finalize the Data Model approach.

• STEP 1: xNF (RAN Simulator) GENERATES a VES CMNotify - Wipro SON (R6)
  
  

• STEP 2: DCAE VES Collector RECEIVES the CMNotify - Nokia (R7)
  
  

• STEP 3: DCAE PROCESSES Event- Nokia (R7)
  
  

• STEP 4: DCAE PUBLISHES onto DMaaP - Nokia (R7)
  
  

• STEP 5: CCSDK (Controller) LISTENS to DMaaP - @Sandeep Shah  (R6)
  
  

• STEP 6: RTCfgDB UPDATES with info - @Sandeep Shah / Techmahindra Devendra Chauhan (R6) 
  
  

R7

Project Proposal

RunTime Config DB Project Proposal (Oct 25 2019)

Project Proposal work to be done during R6. Project Proposal for R7.

Presentation at Arch S/C and TSC during R6.

R7

Separate

Component

Email from @Dan Timoney Nov 14, 2019 

My understanding from Sandeep was that this work was very much a stretch for Frankfurt.  So, I’m okay with work starting in Frankfurt, as long as its structured so that it’s a separable component (i.e. as long as, if it’s not completed in Frankfurt, the platform is not fundamentally broken). I would NOT support creating a separate repository, since there is a fair amount of overhead involved in maintaining each repository on an ongoing basis – both machine and human resources.  The Linux Foundation itself has been pushing back on the number of repositories the ONAP projects have and there is now a new approval process needed in order to add new ones.  If a new repository is needed, then this team will need to convince me why no existing repository can be used AND will need to provide a resource who is willing to maintain that repository (i.e dealing with security vulnerabilities; policing code coverage ; doing release builds, etc).

R7 Guilin

Content / requirements

Requests for R7 Requirements are up.

Guilin release - functional requirements proposed list

Timeline -  Sign-off for R6 is May 7. Historically M0 kickoff for R7 is May 7th

PROPOSALS FOR R7 GUILIN FOR WHAT WE PLAN TO BE DOING IN R7

1. R7 Project Proposal (identify PTL, Project proposal, setup repo) - Setting up the Project

2. =STEP 0= (Design time), (Setup DB) Yang Model development ORAN specification Yang Model in line with 3GPP. SQL structure.

3. =STEP 0= Schema design/setup & API.

4. =STEP 1= CMnotify generated by RanSIM extended (final standard format).

5. =STEP 1= VES generation, Nokia Simulate DU → simulate VES CMNotify message.

6. =STEP 1-6= CMNotify (Nokia) Integration Step 2,3,4 with SON work Step 1,5,6

7. =STEP 5/6= Mapping CMnotify contents into DB

8. =STEP 6= API Updates

9. =STEP 6= Interface to RTCDB (writing DB from SDN-R or RCDB-stand-alone-component)

• STEP 0: Design time, Setup DB schema & API.
  
  

• STEP 1: xNF (RAN Simulator) GENERATES a VES CMNotify - Wipro SON (R6 Done)
  
  

• STEP 1a: Simulator of VES CMNotify (Nokia) (R7)

• STEP 2: DCAE VES Collector RECEIVES the CMNotify - Nokia (R7)
  
  

• STEP 3: DCAE PROCESSES Event- Nokia (R7)
  
  

• STEP 4: DCAE PUBLISHES onto DMaaP - Nokia (R7)
  
  

• STEP 5: CCSDK (Controller) LISTENS to DMaaP - @Sandeep Shah  (R6 Done) → (R7)
  
  

• STEP 6: RTCfgDB UPDATES with info - @Sandeep Shah / Techmahindra (R6 Done) → (R7)
  
  

Renaming the Project

RENAMING THE PROJECT ("Service" vs "Database")

Database

The original idea was a configuration database available at Runtime (Inertia). Use cases to store. Historical been with the project since the beginning. AT&T has voiced an opinion that ECOMP & AT&T ONAP installation would like to preserve the name "Configuration DB" (Inertia). At the core of the project is a Database.

Service

Since working on project proposal, it has grown, the same argument works against use. A wide variety of qualifiers could be put there and it still won't cover. Would move to something more abstract. Above and beyond a standard IT database. For example service information, policy information, CLAMP information, exo-inventory (information outside of A&AI), topology information, application information - it is conceivable that many other types of information could before. Config if someone wants to add additional information a place to hold information. The project will do more than just data functionality. The run-time operations encompass more than just an IT database, with dynamic operations.

An engine, chassis is a part of a automobile that provides a service: vehicular motion. A database is a specific technology and implementation.

Requirements around for current data & historical (temporal) careful not to talk about the technology. Potentially more than one database.

Data Persistency Service → "functional"

Data Layer Service → (Arch S/C)

RunTime Configuration DataBase → "technology"

State (of Network) Database

Configuration Operations Database (C.Op.DB) / Swami

Golden Configuration Database / Fred

Policy Topology Configuration RunTime Service Exo-Inventory Database

R7 Proposal

R7 GUILIN BUSINESS PROPOSAL

Executive Summary - The RunTime Configuration Database / Data Persistency Service is a new platform component that is designed to serve as a data repository for Run-time data that needs to be persistent. As a stand-alone ONAP component, this project provides data layer services to other ONAP platform components and use cases that require persistent configuration or operational data. The R6 development will be enhanced as well.      

Business Impact - The ability for service operators to visualize and manage data in a RAN network (PNFs, VNFs, and logical constructs) with ONAP is a critical business function because they are key Life Cycle Management (LCM) and OA&M operations. The project has business impacts to enhance the operation of data-handling within ONAP by providing efficient data layer services.

Business Markets - This project applies to any domain (wireless, transport, optical, and wireline) that ONAP may manage. It is not a market or geographical specific capability. It is expected that scaled ONAP installations such as Edge & Core ONAP deployments will also deploy the database across each installation.

Funding/Financial Impacts - This project represents a large potential Operating Expense (OPEX) savings for operators because of the ability to configure networks saving time and expenses.

Organization Mgmt, Sales Strategies - There is no additional organizational management or sales strategies for this use case outside of a service providers "normal" ONAP deployment and its attendant organizational resources from a service provider.

R7 Development

CMNotify specification

Zoom

Audio Only

Chat