Use Case Key Information
Topic | Description | Link |
|---|---|---|
| Architecture Subcommittee | Presentations and Jira Tickets for Architecture Subcommittee made | ONAPARC-582 - Getting issue details... STATUS |
| Use Case Jira | Jira Ticket for Use Case Requirements | REQ-327 - Getting issue details... STATUS |
| Model STORY ticket | MODELING-370 - Getting issue details... STATUS | |
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 | NO IMPACT | ||
| AAF | NO IMPACT | ||
| APPC | NO IMPACT | ||
| CLAMP | NO IMPACT | ||
| CC-SDK | NO IMPACT | ||
| DCAE | 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 - Getting issue details... STATUS | ||
| DMaaP | NO IMPACT | ||
| External API | NO IMPACT | ||
| MODELING | Epic 2: VES Data Model and Requirements Update -Update VES Data Model with new domain enum and field see VES 7.1 MODELING-370 - Getting issue details... STATUS | ||
Multi-VIM / Cloud | NO IMPACT | ||
| OOF | NO IMPACT | ||
| POLICY | NO IMPACT | ||
| PORTAL | NO IMPACT | ||
| SDN-C | NO IMPACT | ||
| SDC | NO IMPACT | ||
| SO | NO IMPACT | ||
| VID | NO IMPACT | ||
| VNFRQTS | 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 - Getting issue details... STATUS | ||
| VNF-SDK | NO IMPACT | ||
| CDS | 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 |
|---|---|
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) |
|
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) |
Participating ONAP Components | DCAE (DCAE VES Event Listener) |
| Related JIRA | MODELING-370 - Getting issue details... STATUS |
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 - Getting issue details... STATUS 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:
| Topic | File |
|---|---|
| Architecture Subcommittee Presentation May 19, 2020 | |
Testing
Current Status
Testing Blockers
- High visibility bugs
- Other issues for testing that should be seen at a summary level
- Where possible, always include JIRA links
End to End flow to be Tested
**This should be a summary level Sequence diagram done in Gliffy**
Test Cases and Status
# | Test Case | Status |
|---|---|---|
| 1 | There should be a test case for each item in the sequence diagram | NOT YET TESTED |
| 2 | create additional requirements as needed for each discreet step | COMPLETE |
| 3 | Test cases should cover entire Use Case | PARTIALLY COMPLETE |
| 4 | Test Cases should include enough detail for testing team to implement the test | FAILED |