Use Case Key Information
Topic | Description | Link |
---|---|---|
Architecture Subcommittee | Presentations and Jira Tickets for Architecture Subcommittee made | |
Use Case Jira | Jira Ticket for Use Case Requirements | |
Model STORY ticket | ||
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 | ||
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-370Getting 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 | |||
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 |
INFORMATION MODEL DETAILS
This table is taken from the generic information template: Generic Information Element Template
Information Element Name | Name of the Information Element |
Points of Contact | Authors and maintainers of the Information Element Information Element Main Contact (typically Use Case SME) Information Modeling Contact Schema Definition Contact |
Related Use Cases | Use Cases that have interactions using this Information Element. Please provide a point of contact for each related Use Case. |
Participating ONAP Components | The list of ONAP Components that are stakeholders for the Information Element |
Related JIRA | |
Description | Overview and description of the Information Element. |
Related Standards & Industry Activities | Please refer to any standards or industry activities that should be taken into account when defining the Information Model related to this Information Element. Please provide links to relevant material. |
Attributes | Attributes: Name and describe each attribute of this Information Element. Please include the datatype of the attribute if possible. Is this attribute read-only, read-write? Are there any default values? |
Relationships | Relationships: Describe how this Information Element is related to other Information Elements. Also describe nature of the relationship: association, inheritance, dependency, etc. and multiplicity. |
Originator | Where does this information come from? (What component initially creates it) |
Consumers | Who uses this information inside & outside of ONAP? How do they use it? Includes description of information consumed (whole class, specific attributes, etc.) |
Producers | Who updates this information inside & outside of ONAP? Under what conditions do they update it? Includes description of information produced (whole class, specific attributes, etc.) |
Steward | Where will this information stored and maintained in ONAP? |
Impacted APIs & Schemas | Identify impacted ONAP schemas & APIs Are there existing schemas be used or extended? |
Information Modeling Status | What is the status of ONAP Information Modeling activities associated with this Information Element. Please provide links to relevant wiki pages & JIRA. |
Schema Definition Status | What is the status of ONAP Schema Definition activities associated with this Information Element. Please provide links to relevant wiki pages & JIRA. |
ONAP Release Priority | Prioritization for ONAP Releases |
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 |