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 |
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 | ||
| 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 | Short overview of the Use Case |
Points of Contact | Marge Hillis Vimal Begwani Damian Nowak Oskar Malm |
Preconditions | A list of conditions that are assumed to be true before the Use Case is invoked Includes description of Information Consumed |
Triggers / Begins when | xNF emits a 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 stdDefined value which is destined for the DCAE Collector |
Steps / Flows (success) | Describes the sequence of steps and interactions that occur during the Use Case (may include: description, data exchanges, functionality, state changes) Interaction diagrams may be included or referenced |
Post-conditions | The expected results of the execution of the Use Case Includes description of Information Produced |
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 |
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 |