ONAP/3GPP & O-RAN Alignment-Standards Defined Notifications over VES

Use Case Key Information

Topic

Description

Link

Topic

Description

Link

Architecture Subcommittee

Presentations and Jira Tickets for Architecture Subcommittee made May 19, 2020 

ONAPARC-582: Guilin-R7 Architecture Review - REQ-327 - AR-0009-R7-052020--R7 HARMONIZATION: ONAP/3GPP & O-RAN ALIGNMENT–STANDARDS DEFINED NOTIFICATIONS OVER VESClosed

Use Case Jira

Jira Ticket for Use Case Requirements

REQ-327: ONAP/3GPP & O-RAN Alignment-Standards Defined Notifications over VES (Guilin)Done



Model STORY ticket

MODELING-370: Standards Defined Notifications over VES - Modelling WorkClosed







BUSINESS DRIVER

This section describes Business Drivers needs.

EXECUTIVE SUMMARY

-This contribution introduces a new domain in VES, stndDefined, which indicates that the event contains data that conforms to format/schema defined by a separate standards organization.  In addition we propose one new field in the VES Common Header to enable further classification of such events, e g to support routing of these events to appropriate DMaaP topics.  An optional second stage validation is proposed in DCAE prior to acknowledging the event to enhance trouble shooting.

-It is proposed that the first application of this generic capability supports VES encapsulated 3GPP defined notifications as described in 28.532 version 16.3.0 Annex B (informative). The ORAN O1 specification also refers to VES-based 3GPP notifications for several management services, and in those cases is expected to further align with the approach and solution published in 3GPP in a future release.

BUSINESS IMPACT- The ability for service providers to deploy ONAP as the SMO in their O-RAN compliant network depends upon ONAP’s ability to process VES encapsulated events as defined by 3GPP and ORAN in DCAE and route these events to appropriate DMaaP topics. This proposal, in Guilin, provides the necessary capability for ONAP to process and validate events that are defined using 3GPP schema for the data. The proposal is readily extensible for the support of additional events from 3GPP, ORAN or other standards organizations adding a high degree of flexibility to the ONAP platform.

BUSINESS MARKETS- This contribution applies to any Service Provider that wants to use ONAP as an O-RAN compliant SMO or to support 3GPP compliant interfaces and can be leveraged by Service Providers wishing to support events from network functions which are aligned with other standards organizations.

FUNDING/FINANCIAL IMPACTS- This contribution helps enable ONAP to be O-RAN and 3GPP compliant which should stimulate contributions from companies that are aligned with O-RAN and 3GPP. There is no new hardware to be procured and no new licenses.

ORGANIZATION MGMT, SALES STRATEGIES- This proposal does not affect sales strategies.

Development Status

PROJECT

PTL

User Story / Epic

Requirement

A&AI

@James Forsyth

NO IMPACT



AAF

@Jonathan Gathman

NO IMPACT



APPC

@Takamune Cho

NO IMPACT



CLAMP

@Gervais-Martial Ngueko

NO IMPACT



CC-SDK

@Dan Timoney

NO IMPACT



DCAE

@Vijay Kumar

Epic 1:Standards Defined VES Event

-Update VES Event Listener

-Extend DCAE to use contents of the new stndDefinedNamespace field to route

-DCAE-SDK to execute validations of JSON objects to stnds schemas

-DCAE-SDK to perform Stage 2 validation 

-DCAE-CBS to support the schemaBroker function 

-new initContainer in DCAE to load schema information

-CBS API to load the schema info to the CBS/schemaBroker

DCAEGEN2-1769: Add stndDefined domain to VES CollectorClosed



DMaaP

@Mandar Sawant

NO IMPACT



External API

@Matthieu Geerebaert

NO IMPACT



MODELING

@Hui Deng

Epic 2: VES Data Model and Requirements Update

-Update VES Data Model with new domain enum and field

see VES 7.1

MODELING-370: Standards Defined Notifications over VES - Modelling WorkClosed





Multi-VIM /

Cloud

@Bin Yang

NO IMPACT



OOF

@Shankaranarayanan Puzhavakath Narayanan

NO IMPACT



POLICY

@Pamela Dragosh

NO IMPACT



PORTAL

@Manoop Talasila

NO IMPACT



SDN-C

@Dan Timoney

NO IMPACT



SDC

@Ofir Sonsino

NO IMPACT



SO

@Seshu Kumar Mudiganti

NO IMPACT



VID

@ittay

NO IMPACT



VNFRQTS

@Steven wright

Epic 2: VES Data Model and Requirements Update

-Add a new domain field enumeration value stndDefined 

-Add a new field in the common header, stndDefinedNamespace 

-Add a new field structure, stndDefinedFields 

VNFRQTS-892: Standards Defined Notifications over VES - VNF Requirements updateClosed



VNF-SDK

@victor gao

NO IMPACT



CDS

@Yuriy Malakov

NO IMPACT



List of PTLs:Approved Projects

*Each Requirement should be tracked by its own User Story in JIRA 

Use Case Diagram

Use cases define how different users interact with a system under design.  Each use case represents an action that may be performed by a user (defined in UML as an Actor with a user persona).

Use Case Functional Definitions

Section

Description

Section

Description

Use Case Title

ONAP/3GPP & O-RAN Alignment-Standards Defined Notifications over VES

Actors (and System Components)DC

DCAE VES Event Listener, DCAE-SDK, SchemaBroker, xNF

Description

This contribution introduces a new domain in VES, stndDefined, which indicates that the event contains data that conforms to format/schema defined by a separate standards organization.  In addition we propose one new field in the VES Common Header to enable further classification of such events, e g to support routing of these events to appropriate DMaaP topics.  An optional second stage validation is proposed in DCAE prior to acknowledging the event to enhance trouble shooting.

Points of Contact

Information Element Main Contact - @marge.hillis   Oskar Malm

Information Modeling Contact - @marge.hillis

Schema Definition Contact - @damian.nowak

Preconditions

Preconditions for a system (xNF & ONAP) before a xNF sends a stndDefined VES event:

the xNF has been onboarded (artifacts in the onboarding package describe the VES events that the xNF supports).

xNF has gone through registration with ONAP. e.g. in the case of a PNF, it has gone through Plug and Play and sent pnfRegistration event.

ONAP system that supports VES 7.2 or later.

Triggers / Begins when

xNF emits a VES notification that contains data which follows the schema defined by a standards body with a VES Common Header where the domain field is populated with the stndDefined value which is destined for the DCAE Collector.

Steps / Flows (success)

  1. Send VES Message - The xNF sends a stndDefined VES event ("msg")

  2. VES event listener - DCAE's VES Event Listener receives the event.

  3. STAGE 1 VALIDATION - Stage 1 validation verifies that it is: (1) a valid VES event, (2) payload is Json encoded (3) a schema present and (4) header has a stndDefined VES domain; which means that it must follow the schema of a standards body.

  4. STAGE 2 VALIDATION - If it is provisioned, then a second stage of validation is done against the schema in the event with a schema that is stored in the DCAE library/repository. If the event doesn't follow the schema

  5. SUCCESS CASE - Returns 200 ok

  6. FAILURE CASE - Returns 400 failure

Post-conditions

DCAE sends the stndDefined VES events to a Kafka topic.

Alternate / Exception Paths

Description of any exceptions or special process that could occur during Use Case

Related Use Cases

List of the Use Cases referenced by this Use Case

Assumptions

Describes any assumptions that are made for this use case

Tools / References / Artifacts

List of any tools or reference material associated with this Use Case as well as any JIRA trace-ability.

List of any associated diagrams or modelling artifacts associated with the Use Case

INFORMATION MODEL DETAILS

This table is taken from the generic information template: Generic Information Element Template



Information Element Name

VES Information Model

Points of Contact

Information Element Main Contact - @marge.hillis   Oskar Malm

Information Modeling Contact - @marge.hillis

Schema Definition Contact - @damian.nowak

Related Use Cases

C&PS Configuration & Persistency Service (for the CM notifications)

Configuration & Persistency Service R7

Participating ONAP Components

DCAE (DCAE VES Event Listener)

Related JIRA

MODELING-370: Standards Defined Notifications over VES - Modelling WorkClosed

Description

VES Information Model

Adding a new valid enum for the domain

and new field for the namespace only populated if the domain is stndDefined.

Related Standards

& Industry Activities

3GPP Standards TS28.532



Attributes

Domain (Existing Attribute), adding a new enum value "stndDefined"

stndDefinedNamespace (NEW Attribute); type: (string) / enum ??

stndDefined field added to VES common schema.



Relationships

VES Information Model

Does not change the VES Object class or Object class relationships in the Information Model.

Originator

The xNF sends the stndDefined Event, and is the "owner" (source of truth) of the data.

The payload (e.g. CM information) is owned by the xNF and originates sending the VES event to ONAP.

Consumers

DCAE receives this information through VES event listener

How DCAE uses it: it routes it to the proper DMaAP topic based on the stndDefined domain and namespace.

Micro-services (future) could subscribe to these events listening for these topics.

How would micro-services use it (future): Depends on the event (type of namespace events), depends what purpose of the micro-services.

Nothing outside of ONAP will access this information.

Producers

The namespace may be updated if additional standards bodies join in on the definition for the emission of events supported by ONAP.

For example IETF, broadband forum etc. It allows ONAP to process general events from various standards bodies.

Condition when they update - New category of action, (CM, PM, FM) needs to be added.

Steward

Where will this information stored and maintained in ONAP?

Valid model - in the VES event listener specification.

Impacted APIs & Schemas

VES Schema (loaded and defined in design time) in the xNF onboarded artifacts.

API/Swaggers - DCAE API for DMaaP.

DCAE to VES header (modified)

DCAE to SDK API (modified)

DCAE to CBD API (modified)

Information Modeling Status

This is scheduled in the R7 Modeling planning page. The Wiki page: ONAP R7 Modeling High Level Requirements

It is being tracked by the Modeling-370 Jira which can be found here:

MODELING-370: Standards Defined Notifications over VES - Modelling WorkClosed

Status: It is active for the current release, this use case has been accepted. The model is being developed.

Schema Definition Status

A schema is located in the presentation (on this page): https://wiki.onap.org/download/attachments/84640792/Arch%20Presentation%20STD%20Defined%20Event%20in%20ONAP%20May%2019%202020.pptx?version=1&modificationDate=1589918847000&api=v2

ONAP Release Priority

R7 Guilin - Model work has been approved to proceed.

In the R7 planning page: Guilin Release Requirements , the Modeling-370 is under REQ-327 and TSC Priority 0 "Go"

Supporting Files: