Update requested by gh7896

Below is the update for: Section 7.4.1 Data Model for Event Records
Note: Please see attachment of update diagram for Figure 1. Data Model for Event Records.

— Existing —
This section describes the data model for the collection of telemetry data from xNFs by Service Providers (SPs) to manage xNF health and run-time life cycle. This data model is referred to as the VES Data Model. The VES acronym originally stood for Virtual-function Event Streaming, but VES has been generalized to support network-function event streaming, whether virtualized or not.
The VES Data Model describes a vendor-agnostic common vocabulary of event payloads. Vendor-specific, product-specific or service-specific data is supported by the inclusion of a flexible additional information field structure. The VES Data Models’ common vocabulary is used to drive standard and automated data analytics (policy-driven analytics) within the ONAP DCAE Framework.
While this document is focused on specifying some of the records from the ONAP perspective, there may be other external bodies using the same framework to specify additional records. For example, OPNFV has a VES project that is looking to specify records for OpenStack’s internal telemetry to manage application (xNFs), physical and virtual infrastructure (compute, storage, network devices, etc.) and virtual infrastructure managers (cloud controllers, SDN controllers). It uses ONAP’s VES Agent to generate VES events from the xNF and Intel’s collectD agent to generate infrastructure VES events. Note that any configurable parameters for these data records (e.g., frequency, granularity, policy-based configuration) will be managed using the “Configuration” framework described in the prior sections of this document. The infrastructure metrics have been funneled via the ONAP Multi-VIM Project and are now included in current specifications.
The Data Model consists of:
• Common Header Record: This data structure precedes each of the Technology Independent and Technology Specific records sections of the data model.
• Technology Independent Records: This version of the document specifies the model for Fault, Heartbeat, Measurements, Notification, pnfRegistration, State Change, Syslog, and Threshold Crossing Alerts records. In the future, these may be extended to support other types of technology independent records (work is currently progressing to define a new Performance Domain that would be able to support already defined 3GPP Metrics for xNF, e.g. 5G RAN device Use Case in Casablanca). Each of these records allows additional fields (name/ value pairs) for extensibility. The xNF provider may use these xNF provider-specific additional fields to provide additional information that may be relevant to the managing systems.
• Technology Specific Records: This version of the document specifies the model for Mobile Flow records, Signaling and Voice Quality records. In the future, these may be extended to support other types of records (e.g. Network Fabric, Security records, etc.). Each of these records allows additional fields (name/value pairs) for extensibility. The xNF provider can use these xNF-specific additional fields to provide additional information that may be relevant to the managing systems. A placeholder for additional technology specific areas of interest to be defined in the future documents has been depicted.
— End - Existing —

• • • Update ***
      This section describes the data model for the collection of telemetry data from VNFs or PNFs by Service Providers (SPs) to manage VNF or PNF health and run-time life cycle. This data model is referred to as the VES Data Model. The VES acronym originally stood for Virtual-function Event Streaming, but VES has been generalized to support network-function event streaming, whether virtualized or not.
      The VES Data Model describes a vendor-agnostic common vocabulary of event payloads. Vendor-specific, product-specific or service-specific data is supported by the inclusion of a flexible additional information field structure. The VES Data Models’ common vocabulary is used to drive standard and automated data analytics (policy-driven analytics) within the ONAP DCAE Framework.
      While this document is focused on specifying some of the records from the ONAP perspective, there may be other external bodies using the same framework to specify additional records. For example, OPNFV has a VES project that is looking to specify records for OpenStack’s internal telemetry to manage application (VNFs or PNFs), physical and virtual infrastructure (compute, storage, network devices, etc.) and virtual infrastructure managers (cloud controllers, SDN controllers). It uses ONAP’s VES Agent to generate VES events from the VNF or PNF and Intel’s collectD agent to generate infrastructure VES events. Note that any configurable parameters for these data records (e.g., frequency, granularity, policy-based configuration) will be managed using the “Configuration” framework described in the prior sections of this document. The infrastructure metrics have been funneled via the ONAP Multi-VIM Project and are now included in current specifications.
      The Data Model consists of:
      • Common Header Record: This data structure precedes each of the Technology Independent and Technology Specific records sections of the data model.
      • Technology Independent Records: This version of the document specifies the model for fault, heartbeat, measurement, notification, perf3gpp, pnfRegistration, stateChange, syslog, and thresholdCrossingAlert (TCA) records. In the future, these may be extended to support other types of technology independent records. Each of these records allows additional fields (name/value pairs) for extensibility. The VNF or PNF provider may use these VNF or PNF provider-specific additional fields to provide additional information that may be relevant to the managing systems.
      • Technology Specific Records: This version of the document specifies the model for mobileFlow, sipSignaling and voiceQuality records. In the future, these may be extended to support other types of records (e.g. Network Fabric, Security records, etc.). Each of these records allows additional fields (name/value pairs) for extensibility. The VNF or PNF provider can use these VNF or PNF-specific additional fields to provide additional information that may be relevant to the managing systems. A placeholder for additional technology specific areas of interest to be defined in the future documents has been depicted.
    • End - Update ***

• • • • • • UPDATE FIGURE 1 to include perf3gpp domain ****** (see attachment)