...
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.
...
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 CaseThis 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 | Marge Hillis Vimal Begwani Damian Nowak Oskar Malm | 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. | 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 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 stdDefined stndDefined 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 | DCAE sends the stndDefined VES events to a Kafka topic. | 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 |
...
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 |
Use Cases that have interactions using this Information Element.
Please provide a point of contact for each related Use Case.C&PS Configuration & Persistency Service (for the CM notifications) |
Participating ONAP Components |
DCAE (DCAE VES Event Listener) |
| Related JIRA |
| ||||||||
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 |
Description
. |
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)
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?
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 |
Identify impacted ONAP schemas & APIs
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:
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 |
Please provide links to relevant wiki pages & JIRA.
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" |
ONAP Release Priority
Supporting Files:
| Topic | File | ||||||
|---|---|---|---|---|---|---|---|
| Architecture Subcommittee Presentation May 19, 2020 |
| ||||||
...