Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

Attendees


ARCH WORK

DISCUSSION

TopicDiscussion
Calendar Entry

Calendar now open for editing ... but how?

Community Meetings & Calendar

R6

CCSDK-based Solution

Project as part of CCSDK ( Yuriy Malakov  )

  •  ACTION: Sandeep Shah Presentation of new architecture with CCSDK.
  •  (DONE): Architecture CCSDK component: ARC Controller Component Description – Frankfurt added in Section 6 System deployment architecture. Separate container. Added to Diagram. Updated Section 7 New Release Capabilities & Linked to U/C page.
  •  ACTION: Development demo & progress in use on OOF/PCI/SON Use Case. Validation tool & generation of schemas/tables of input conditions of yang model. Basis for Data Model 3GPP TS28.541/28.540. Planned SQL Schema model driven database work. Once we have schema can SDNR update/provision the schema. Can parsing code be model driven. (1) ORAN Yang models & data schema not available yet (waiting) & 5G Service Modeling U/C: 3GPP TS28.541/TS28.540. maps to a data structure we want to support. (2) can proceed to Dockerize solution. R4 MariaDB solution. could extend the model. (3) Review work from Ted.
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.

  •  (DONE):  CCSDK Jira ticket for RTCfgDB into CCSDK -
    Jira Legacy
    serverSystem Jira
    serverId4733707d-2057-3a0f-ae5e-4fd8aff50176
    keyCCSDK-1963

  •  ACTION: Convert yang model in SDN-R to be used into CCSDK. RTCfgDB will be used for OOF/SON/PCI first. Yang model as used by OOF/SON/PCI to convert. Yang model from SDN-R > CCSDK. SDN-C gets yang model from SDC. Yang to SQL. Need to have 1 Yang model. Martin Skorupski
    The topic will be discussed at SDN-R call 2020-02-26
  •  ACTION: Activity #1 Wipro team doing a CMNotify mock-up (demo). Sandeep Shah  ; place on DMaaP and have them parse. VES mock-up version 7.2. Not changing the VES Collector (R7). RAN-Simulator (input); Activity #2: Nokia offered to contribute the code to support the additional domain & routing & processing of CMNotify VES events in DMaaP (R7).
  • 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) 
  •  ACTION: CMNotify VES Review https://gerrit.onap.org/r/c/vnfrqts/requirements/+/100876  (VES Event Reg review) and https://gerrit.onap.org/r/c/vnfrqts/requirements/+/100867 (VES Event Listener review)
    VES 7.1 review. Trevor processing comments. Reviewers want= to see reworked document.
  •  ACTION: Common Header - David Smith calling meeting talk about how to harmonize / modify common header to deal with notifications to standard bodies. SA5 taken action defining VES events (not good). ONAP should control population of common header. SA5 to change info (CR). Meeting for a high level proposal. Nokia/ ATT/ Orange/ Ericsson. Working towards presentation to ONAP. 3GPP solution to submit CR. Vimal, Marge, Cormac, Damian. NEXT STEP: Follow up call. Deadline: in time for R7.
  •  Sandeep has checked in the code for SDN-C.
  •  PoC & Demo for R6 being planned June 2020 (Plugfest & Bronze release)

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.

  •  ACTION: For Performance (#@#) open items to get ballpark figures for # API requests.
  •  ACTION: find out the Lifecycle State "enumerations"
  •  ACTION: PTL
  •  ACTION: TSC / key points in project proposal that must be addressed for them to be considered as a project. Questions that might be asked that need answer. Mandatory fields filled out. FREEMAN, BRIAN D
  •  ACTION: What is our deadline?

R7

Separate

Component

  •  ACTION: Find PTL who wants to lead the RTCfgDB Project as independent component.

Email from Dan Timoney  

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. Abose 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, hubcap 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 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 Run-Time RunTime Configuration Database (or possibly Data Persistency Service / we are discussing the  final project name) will be continued from the R6 Frankfurt work. This R7 work will include: software enhancements to the RAN simulator, the schema design, integration with CM Notify DCAE development, API updates into the database. The project will ALSO kick off the work needed to create a stand-alone components / project. This work will entail nominating a PTL, Setting up a software repository, and transitioning the existing R6 database software into the new repository. / 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 to configure for service operators to visualize and manage data in a RAN network (CU/DU) PNF and VNF PNFs, VNFs, and logical constructs) with ONAP is a critical business function because configuration management is a core LCM/OAM operationthey are key Life Cycle Management (LCM) and OA&M operations. The project has been presented at the TSC and Architecture sub-committees, with acknowledge business impacts to enhance the operation of data-handling within ONAP to improve and augment LCM operationsby 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 the that scaled ONAP installations such as Edge & Core ONAP deployments will also deploy the database across installationseach installation.

Funding/Financial Impacts - This use case 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

  •  ACTION: R7 CMNotify VES Review https://gerrit.onap.org/r/c/vnfrqts/requirements/+/100876  (VES Event Reg review) and https://gerrit.onap.org/r/c/vnfrqts/requirements/+/100867 (VES Event Listener review)
    VES 7.1 review. Trevor processing comments. Reviewers want= to see reworked document.
  •  ACTION: R7 Common Header - David Smith calling meeting talk about how to harmonize / modify common header to deal with notifications to standard bodies. SA5 taken action defining VES events (not good). ONAP should control population of common header. SA5 to change info (CR). Meeting for a high level proposal. Nokia/ ATT/ Orange/ Ericsson. Working towards presentation to ONAP. 3GPP solution to submit CR. Vimal, Marge, Cormac, Damian. NEXT STEP: Follow up call. Deadline: in time for R7.
  •  


SUPPORTING FILES

DescriptionFile




...