8.7. Service: VES Event Listener 7.1.1

Legal Disclaimer

Licensed under the Apache License, Version 2.0 (the “License”); you may not use this file except in compliance with the License. You may obtain a copy of the License at

http://www.apache.org/licenses/LICENSE-2.0

Unless required by applicable law or agreed to in writing, software distributed under the License is distributed on an “AS IS” BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. See the License for the specific language governing permissions and limitations under the License.

Document

VES Event Listener

Revision

7.1.1

Revision Date

January 28th, 2020

Author

Rich Erickson

Contributors:

Min Chen – AT&T

Fred Delaplace - AT&T

Andrew Egan – AT&T

Alok Gupta – AT&T

Marge Hillis – Nokia

Gerard Hynes – AT&T

Ken Kelly – AT&T

Mark Scott – Ericsson

Tim Verall – Intel

Sumit Verdi – VMWare

Table of Contents

8.7.1. Introduction

This document describes the RESTful interface for the VES Event Listener. 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 Event Listener is capable of receiving any event sent in the VES Common Event Format. The Common Event Format is expressed in JSON schema in section 4 of this document. In the Common Event Format, an event consists of a required Common Event Header block (i.e., object) accompanied by zero or more event domain blocks.

It should be understood that events are well structured packages of information, identified by an eventName, which are asynchronously communicated to subscribers who are interested in the eventName. Events can convey measurements, faults, syslogs, threshold crossing alerts and other types of information. Events are simply a way of communicating well-structured packages of information to one or more instances of an Event Listener service.

This document describes a RESTful connectionless push event listener can receive single events or batches of events in the Common Event Format. In future, additional documents may describe other transports which make use of persistent TCP connections for high volumes of streaming events.

8.7.1.1. Compatibility with ONAP

Unless otherwise stated, this version of the Event Listener specification is compatible with the release of ONAP the specification is released under. In other words, if the specification is released under the Frankfurt ONAP Release, then the VES Event Collectors provided by DCAE will also be compatible with the specification.

8.7.1.2. Event Registration

All events must be compliant with the common event format, but specific events identified by their eventNames, may require that certain fields, which are optional in the common event format, be present when they are published. For example, a specific eventName may require that specific name-value pairs be present in the extensible structures provided within the Common Event Format.

Events are registered using an extensible YAML format (defined in a separate document), which specifies, for each eventName, the fields that are required, what field values may be sent, and any special handling that should be performed on those eventNames.

8.7.1.3. Naming Standards for eventName

To prevent naming collisions, eventNames sent as part of the commonEventHeader, should conform to the following naming convention designed to summarize the purpose and type of the event, and to ensure the uniqueness of the eventName:

{DomainAbbreviation}_{PublisherName}_{Description}

Each underscore-separated subfield above should start with a capital letter and use camel-casing to separate words and acronyms. Acronyms should capitalize only the first letter of the acronym. Spaces and underscores should not appear within any subfield.

The DomainAbbreviation subfield derives from the ‘domain’ field in the commonEventHeader, as specified below:

  • ‘Fault’ for the fault domain

  • ‘Heartbeat’ for the heartbeat domain

  • ‘Measurement’ for the measurement domain

  • ‘MobileFlow’ for the mobileFlow domain

  • ‘Notification’ for the notification domain

  • ‘Other’ for the other domain

  • ‘Perf3gpp’ for the perf3gpp domain

  • ‘PnfReg’ for the pnfRegistration domain

  • ‘SipSignaling’ for the sipSignaling domain

  • ‘StateChange’ for the stateChange domain

  • ‘Syslog’ for the syslog domain

  • ‘Tca’ for the thresholdCrossingAlert domain

  • ‘VoiceQuality’ for the voiceQuality domain

The PublisherName subfield describes the vendor product or application publishing the event. This subfield conforms to the following conventions:

  • Vendor products are specified as:

    {productName}-{vendorName}

    For example: Visbc-Metaswitch or Vdbe-Juniper, where a hyphen is used to separate the productName and vendorName subfields. Note that the productName and vendorName subfields must not include hyphens themselves.

    Organizing the information in this way will cause an alphabetical listing of eventNames to sort similar network functions together, rather than to sort them by vendor.

    The productName subfield may describe a NF or a NFC. Where NFC names may be reused across different NF’s, they should be specified as:

    {NfName}:{NfcName}

    where a colon is used to separate the NfName and NfcName subfields. Note that the NfName and NfcName subfields must not include colons themselves.

    The ProductName may also describe other types of vendor modules or components such as a VM, application or hostname. As with NFs and NFCs, parent:child relationships may be communicated using colon as a subfield delimiter.

  • Service providers who adopt the VES Common Event Format for internal use, may provide PublisherName without the vendorName subfield. They would typically identify an application, system, service or microservice publishing the event (e.g., ‘Policy’, ‘So’, ‘MobileCallRecording’ or ‘Dkat’). As with NFs and NFCs, parent:child relationships may be communicated using colon as a subfield delimiter (e.g., ApplicationName:ApplicationComponent).

The final subfield of the eventName name should describe, in a compact camel case format the specific information being conveyed by the event. In some cases, this final subfield may not be required (e.g., in the case of certain heartbeats).

Examples of eventNames following the naming standards are provided below:

  • Tca_Vdbe-Ericsson_CpuThresholdExceeded

  • Heartbeat_Visbc:Mmc-Metaswitch

  • Syslog_Vdbe-Ericsson

  • Fault_MobileCallRecording_PilotNumberPoolExhaustion

  • Other_So:WanBonding_InstantiationPart1Complete

8.7.1.4. EventId Use Cases Examples

eventId Examples:

NOTE: Please note, the following are only examples, and other formats can be used provided they meet the requirement that the eventId is unique for all events or unique fault occurrence.

Example 1: assumes a unique key for each domain consisting of domain followed by an integer domain<n> or domainId<n>, where <n> is a positive integer, e.g. fault000001, heartbeat000001, measurement000005, notification3gppPerfFileReady0005

Example 2: assumes a unique integer key for all events across all domains <n>: 000000001, 00000002, 000000003

Rules:

  1. All domains except Fault: each time a subsequent event is sent the integer part of eventId will increment by 1. Repeat of eventId assumes duplicate event. Sequence number is set to 0 for all domains except fault.

  2. eventId construction for Fault Events:

    1. Most likely scenario

      • The sourceName on each Fault event is the NF Instance Name (pnf-name or vnf-name or vm-name) as entered in A&AI uniquely identifying this instance of the NF.

      • The eventId on Fault events is the same every time a given fault is raised (including onset and re-raise)

        1. The startEpochMicrosec value for the Fault event is the timestamp for when the fault onset occurs. Subsequent events for the same fault will keep the same startEpochMicrosec value.

        2. lastEpochMicrosec indicates the current event time. This value will be updated for each subsequent event for a given fault.

        3. The sequence number for each Fault event is set to 1 when the fault is raised and increments each time the same fault event is raised, until a clear is sent.

      • After the fault is cleared, a new eventId is used.

    ../_images/Use-Case-1.png
    1. Alternative Scenario: Network Function When Fault Event Status is Not Maintained.

      • The sourceName on each Fault event is the NF Instance Name (pnf-name or vnf-name or vm-name) as entered in A&AI uniquely identifying this instance of the NF.

      • The eventId on Fault events is the same every time a given fault is raised or cleared, even if it is re-raised after it had previously cleared. So, for example, if EMS loses contact with a particular device then a Fault event might be sent for a raise, re-raise (because EMS has re-tried and still can’t contact the device), clear (because EMS has re-tried and it can contact the device) and then raise again (because EMS has lost contact with the device again). The same eventId is used for all 4 of those Fault events.

      • The startEpochMicrosec value for each Fault event is the timestamp for when that event is generated, not when the fault first occurred. So all 4 of the Fault events in the previous bullet point would have a different timestamp.

      • lastEpochMicrosec indicates the current event time.

      • The sequence number for each Fault event is currently set to 0 on a raise and 1 on a clear. We could change that so that each Fault event is given a new monotonically increasing sequence number whether it is a raise or a clear if that is helpful (which is reset to 0 if the VM restarts) but they won’t be consecutive.

      • Normally, a clear is expected for each fault to be sent from a network function. However a few fault notification types will never be re-raised or cleared. In this case, general rules for VES events shall be followed with a new eventId for each event and sequence number set to 0.

    ../_images/Use-Case-2.png

8.7.1.5. Measurement Expansion Fields

When expansion fields are used, the goal is to avoid custom development by the service provider collecting the fields, since custom development adds obvious cost, delay and resource overhead. In the domain of measurements, it is expected that a high percentage (perhaps as high as 90 percent) of use cases for extensible fields can be satisfied by using the additionalMeasurements arrayOfNamedHashMap data structure in combination with a YAML registration file (provided at design time). The YAML registration file conveys meta-information about the processing of additionalMeasurements. For more information, please see the VES Event Registration specification and in particular the aggregationRole, castTo and isHomogeneous keywords.

8.7.1.6. Syslogs

Syslog’s can be classified as either Control or Session/Traffic. They differ by message content and expected volume:

  • Control logs are generally free-form human-readable text used for reporting errors or warnings supporting the operation and troubleshooting of NFs. The volume of these logs is typically less than 2k per day.

  • Session logs use common structured fields to report normal NF processing such as DNS lookups or firewall rules processed. The volume of these logs is typically greater than 1k per hour (and sometimes as high as 10k per second).

VES supports both classes of syslog, however VES is only recommended for control logs or for lower volume session logs, less than 60k per hour. High volume session logging should use a file-based transport solution.

8.7.1.7. Support for Protocols Other Than HTTPS

This API specification describes an HTTPS RESTful interface using the JSON content-type.

Alternative API specifications may be provided in future using Google Protobuf, websockets, or Apache Avro.

8.7.1.8. Configuration Requirements

This section provides network function configuration requirements for connectivity to a VES Event Listener via a RESTful API, using a VES JSON event.

There are several methods available to provide configuration settings to a network function. This document does not specify the exact manner in which the configuration elements described below must be required. The configuration can be provided during instantiation (e.g. preload), provided by an ONAP controller action, or provided manually.

  • VES Event Listener IP Addresses or FQDNs resolved via DNS: Two FQDNs and/or IP Addresses are required. NF shall select one of the 2 FQDNs/IP Addresses for sending events and if the NF is unable to get an acknowledgement within predefined configurable time interval or unable to establish a TCP connection due inability to resolve DNS query or if the VES Event Listener is unresponsive, then the NF shall attempt to use the other FQDN/IP Address to connect to VES Event Listener to deliver the VES Events. The events shall only be sent to one VES Event Listener at a time. Please note: If a FQDN is used, the DNS query would return a single IP address.

  • The active VES Event Listener (either the primary or secondary) will handle all VES events regardless of domain.

  • VES Credentials: If the NF is using Basic Authentication, then the NF must support the provisioning of security and authentication parameters (HTTP username and password) in order to be able to authenticate with the VES Event Listener. The Username and Password should be set unique per NF instance and should be configured during the NF deployment through a Controller or other means. The same password must also be configured into VES Event Listener instance for successful handshake.

  • VES Heartbeat Interval: This must be a configurable parameter; current default is 60 seconds. Note: the heartbeat interval should be greater than the ack timeout value.

  • Measurement Interval: For measurement events, the measurement interval must be configurable and a default of 300 seconds.

  • ACK Timeout Interval: Configurable, default 5 seconds.

8.7.1.9. Event Domain Requirements/Expectations

  • Heartbeat: Heartbeat events must be sent to VES Event Listener based on configurable parameter.

  • Faults: Fault events must be sent to the VES Event Listener as soon as they occur.

  • Measurements: All measurement events must be sent at the configured measurementInterval. If the NF provides both application and GuestOS metrics, then they must both use the same measurementInterval.

  • Syslogs: Syslog events should be sent to the VES Event Listener as soon as created, unless the NF is in debug mode (verbose logging enabled to get additional data to diagnose a problem), in which case the syslogs must be stored locally in the NF, for later access and possible secure transfer.

  • Pre-defined Events Formats (Domain: Mobile Flow, TCA, State Chang, etc): Other events (State change, TCA, Mobile Flow, etc) may use other pre-defined VES domains from the VES Common Event Format specification based on the role of the NF.

  • otherFields: The otherFields Record defines fields for events belonging to the otherFields domain of the Technology Independent domain enumeration. This record provides a mechanism to convey a complex set of fields and is purely intended to address miscellaneous needs such as addressing time-to-market considerations or other proof-of-concept evaluations. Hence, use of this record type is discouraged and should be minimized.

8.7.1.9.1. Use of Collector FQDNs and/or IP Address

  • The NF must support two configurable endpoints for the VES Event Listener. One will be the active, primary event listener endpoint. The other will be a standby event listener in the event the active endpoint is unavailable.

  • When sending an event (FM, PM, Syslog, HB), the NF shall establish an HTTPS connection to one VES Event Listener FQDN/IP Address (if not already established) and send a VES event to it. Note that connections are not persistent. The events shall only be sent to only one VES Event Listener at a time.

  • The NF must be able to detect that a VES Event Listener endpoint is unavailable, and trigger the fail-over to the backup endpoint. The mechanism for detecting unavailability must be configurable by the Service Operator (e.g. number of attempts, timeout value).

  • If the NF is sending events to the VES Event Listener backup endpoint, then the NF must poll the primary endpoint on a configurable interval to check if the primary endpoint is now available. The NF may use the Heartbeat event or another mechanism to test availability. If the primary endpoint becomes available, then the NF must fallback to the primary endpoint.

  • A NF must only send a unique event to a single VES Event Listener endpoint at a time. In other words, the NF must not send a duplicate event to the secondary endpoint unless the delivery to the primary endpoint failed.

  • If both Primary and Secondary endpoints are not available, then the NF shall buffer the events locally. Refer to the Buffering of Events section for full details.

  • If a NF is unable to establish a connection with a VES Event Listener or does not get an acknowledgement within a specified time, then it should log this failure and, optionally, send a fault event indicating connection/acknowledgement failure via the alternate FQDN/IP Address. The intent of this fault is to inform the Service Operator that the VES Event Listener endpoint has become unreachable by the NF.

8.7.1.10. Versioning

Three types of version numbers supported by this specification:

  • The API specification itself is versioned. Going forward, the major number of the specification version will be incremented whenever any change could break an existing client (e.g., a field name is deleted or changed). All other changes to the spec (e.g., a field name is added, or text changes are made to the specification itself) will increment only the minor number or patch number. Note that the major number appears in REST resource URLs as v# (where ‘#’ is the major number). Minor and patch numbers are communicated in HTTP headers. For more information, see the API Versioning writeup in section 6.1.

  • The JSON schema is versioned. Going forward, the major number of the JSON schema will be incremented whenever any change could break an existing client (e.g., a field name is deleted or changed). All other changes to the schema (e.g., a field name is added or text changes are made to the field descriptions) will increment only the minor number or patch number.

  • The field blocks are versioned. Field blocks include the commonEventHeader and the domain blocks (e.g., the faultFields block). Going forward, the major number of each field block will be incremented whenever any change to that block could break an existing client (e.g., a field name is deleted or changed). All other changes to that block (e.g., a field name is added or text changes are made to the field descriptions) will increment only the minor number.

8.7.1.10.1. Field Block Versions

A summary of the latest field block version enums as of this version of the API spec is provided below:

  • commonEventHeader version 4.1 (note: the enum with support 4.0, 4.0.1, 4.1 to avoid breaking clients of earlier versions of major version 4)

  • commonEventHeader vesEventListenerVersion enum: 7.1 (note: the enum will support 7.0, 7.0.1, 7.1 to avoid breaking clients of earlier versions of major version 7)

  • faultFieldsVersion:4.0

  • heartbeatFieldsVersion: 3.0

  • measurementFieldsVersion: 4.0

  • mobileFlowFieldsVersion: 4.0

  • notificationFieldsVersion: 2.0

  • otherFieldsVersion: 3.0

  • perf3gppFieldsVersion: 1.0

  • pnfRegistrationFieldsVersion: 2.0

  • sigSignalingFieldsVersion: 3.0

  • stateChangeFieldsVersion: 4.0

  • syslogFieldsVersion: 4.0

  • thresholdCrossingFieldsVersion: 4.0

  • voiceQualityFieldsVersion: 4.0

8.7.2. Security

Event sources must identify themselves to the VES Event Listener.

There are 2 methods of HTTP authentication supported: Certificate Authentication and Basic Authentication.

Basic authentication is supported in VES Event Listener for backward compatibility for existing NFs that are already managed by ONAP. New NFs should support Certificate Authentication. Because the security is better, NFs may choose to only support Certificate Authentication and not support Basic Authentication.

8.7.2.1. Basic Authentication

When using Basic Authentication, the event source must not pass credentials on the query string. Credentials must be sent in an Authorization header as follows:

  1. The username and password are formed into one string as username:password

  2. The resulting string is Base64 encoded to produce the encoded credential.

  3. The encoded credential is communicated in the header after the string Authorization: Basic

Because the credentials are merely encoded but not encrypted, HTTPS (rather than HTTP) should be used. HTTPS will also encrypt and protect event contents.

8.7.2.2. Sample Request and Response

8.7.2.2.1. Sample Request

POST /eventListener/v7 HTTP/1.1
Authorization: Basic QWxhZGRpbjpvcGVuIHNlc2FtZQ==
content-type: application/json
content-length: 12345
{
    "event": {
        "commonEventHeader": {
            "version": "4.1",
            "vesEventListenerVersion": "7.1.1",
            "domain": "heartbeat",
            "eventName": "Heartbeat_vIsbcMmc",
            "eventId": "heartbeat0000249",
            "sequence": 0,
            "priority": "Normal",
            "reportingEntityId": "cc305d54-75b4-431b-adb2-eb6b9e541234",
            "reportingEntityName": "ibcx0001vm002oam001",
            "sourceId": "de305d54-75b4-431b-adb2-eb6b9e546014",
            "sourceName": "ibcx0001vm002ssc001",
            "nfVendorName": "Ericsson",
            "nfNamingCode": "ibcx",
            "nfcNamingCode": "ssc",
            "startEpochMicrosec": 1413378172000000,
            "lastEpochMicrosec": 1413378172000000,
            "timeZoneOffset": "UTC-05:30"
        }
    }
}

8.7.2.2.2. Sample Success Response

HTTPS/1.1 202 Accepted
X-MinorVersion: 1
X-PatchVersion: 1
X-LatestVersion: 7.1

8.7.2.3. Mutual TLS Certificate Authentication

When using Certificate Authentication, the event source must initialize the HTTPS connection with TLS 1.2 or higher and execute mutual authentication procedures according to RFC5246. The event source must authenticate the VES Listener certificate and must provide its own X.509v3 end-entity certificate to the VES Listener for authentication. The Subject Name in the end-entity certificate must be used according to RFC5280. If a certificate is provided by the NF but it is invalid, the VES Listener is expected to reject the connection and not fall back to basic authentication.

8.7.3. Resource Structure

REST resources are defined with respect to a ServerRoot:

ServerRoot = https://{Domain|IP}:{Port}/{optionalRoutingPath}

The resource structure is provided below:

{ServerRoot}
    |
    |--- /eventListener/v{apiVersion}
             |
             |--- /eventBatch

Figure 1: REST Resource Structure

The {Port} above is typically 8443.

8.7.4. Common Event Format

A JSON schema describing the Common Event Format is provided below and is reproduced in the tables that follow.

JSON

Note on optional fields:

If the event publisher collects a field that is identified as optional in the data structures below, then the event publisher must send that field.

Note on extensible fields:

VES contains various extensible structures (e.g., hashMap) that enable event publishers to send information that has not been explicitly defined in VES data structures.

  • Event publishers must not send information through extensible structures where VES has explicitly defined fields for that information. For example, event publishers must not send information like cpuIdle, through an extensible structure, because VES has explicitly defined a cpuUsage.cpuIdle field for the communication of that information.

  • Keys sent through extensible fields should use camel casing to separate words and acronyms; only the first letter of each acronym shall be capitalized.

8.7.4.1. Common Event Datatypes

8.7.4.1.1. Datatype: arrayOfJsonObject

The arrayOfJsonObject datatype provides an array of json objects, each of which is describ ed by name, schema and other meta-information. It consists of the following fields:

Field

Type

Required?

Description

arrayOfJsonObject

jsonObject [ ]

Yes

Array of jsonObject

8.7.4.1.2. Datatype: arrayOfNamedHashMap

The arrayOfNamedHashMap datatype provides an array of hashMaps, each of which is associated with a descriptive name. It consists of the following fields:

Field

Type

Required?

Description

arrayOfNamedHashMap

namedHashMap [ ]

Yes

Array of namedHashMap

8.7.4.1.3. Datatype: event

The event datatype consists of the following fields which constitute the ‘root level’ of the common event format:

Field

Type

Required?

Description

commonEventHeader

commonEventHeader

Yes

Fields common to all events

faultFields

faultFields

No

Fields specific to fault events

heartbeatFields

heartbeatFields

No

Fields specific to heartbeat events

measurementFields

measurementFields

No

Fields specific to measurement events

mobileFlowFields

mobileFlowFields

No

Fields specific to mobility flow events

notificationFields

notificationFields

No

Fields specific to notification events

otherFields

otherFields

No

Fields specific to other types of events

perf3gppFields

perf3gppFields

No

Fields specific to perf3gpp events

pnfRegistrationFields

pnfRegistrationFields

No

Fields specific to pnfRegistration events

sipSignalingFields

sipSignalingFields

No

Fields specific to sipSignaling events

stateChangeFields

stateChangeFields

No

Fields specific to state change events

syslogFields

syslogFields

No

Fields specific to syslog events

thresholdCrossingAlertFields

thresholdCrossingAlertFields

No

Fields specific to threshold crossing alert events

voiceQualityFields

voiceQualityFields

No

Fields specific to voiceQuality events

8.7.4.1.4. Datatype: eventList

The eventList datatype consists of the following fields:

Field

Type

Required?

Description

eventList

event [ ]

Yes

Array of events

8.7.4.1.5. Datatype: hashMap

The hashMap datatype is an ‘associative array’, which is an unordered collection of key-value pairs of the form “key”: “value”, where each key and value are strings. Keys should use camel casing to separate words and acronyms; only the first letter of each acronym should be capitalized.

8.7.4.1.6. Datatype: jsonObject

The jsonObject datatype provides a json object schema, name and other meta-information along with one or more object instances that conform to the schema:

Field

Type

Required?

Description

objectInstances

JsonObjectInstance [ ]

Yes

Contains one or more instances of the json object

objectName

string

Yes

Name of the json object

objectSchema

string

No

json schema for the object

objectSchemaUrl

string

No

URL to the json schema for the object

nfSubscribedObjectName

string

No

Name of the object associated with the nfSubscriptionId

nfSubscriptionId

string

No

Identifies an openConfig telemetry subscription on a network function, which configures the network function to send complex object data associated with the jsonObject

8.7.4.1.7. Datatype: jsonObjectInstance

The jsonObjectInstance datatype provides meta-information about an instance of a jsonObject along with the actual object instance:

Field

Type

Required?

Description

jsonObject

jsonObject

No

Optional recursive specification of jsonObject

objectInstance

object

No

Contains an instance conforming to the jsonObject schema

objectInstanceEpochMicrosec

number

No

the unix time, aka epoch time, associated with this objectInstance–as microseconds elapsed since 1 Jan 1970 not including leap seconds

objectKeys

key [ ]

No

An ordered set of keys that identifies this particular instance of jsonObject (e.g., that places it in a hierarchy)

8.7.4.1.8. Datatype: key

The key datatype is a tuple which provides the name of a key along with its value and relative order; it consists of the following fields:

Field

Type

Required?

Description

keyName

string

Yes

Name of the key

keyOrder

Integer

No

Relative sequence or order of the key (with respect to other keys)

keyValue

string

No

Value of the key

8.7.4.1.9. Datatype: namedHashMap

The namedHashMap datatype is a hashMap which is associated with and described by a name; it consists of the following fields:

Field

Type

Required?

Description

name

string

Yes

Name associated with or describing the hashmap

hashMap

hashMap

Yes

One or more key:value pairs

8.7.4.1.10. Datatype: requestError

The requestError datatype defines the standard request error data structure:

Field

Type

Required?

Description

messageId

string

Yes

Unique message identifier of the format ‘ABCnnnn’ where ‘ABC’ is either ‘SVC’ for Service Exceptions or ‘POL’ for Policy Exception. Exception numbers may be in the range of 0001 to 9999 where 0001 to 2999 are defined by OMA (see section 5.1) and 3000-9999 are available and undefined.

text

string

Yes

Message text, with replacement variables marked with %n, where n is an index into the list of <variables> elements, starting at 1

url

string

No

Hyperlink to a detailed error resource e.g., an HTML page for browser user agents

variables

string

No

List of zero or more strings that represent the contents of the variables used by the message text

8.7.4.1.11. Datatype: vendorNfNameFields

The vendorNfNameFields provides vendor, nf and nfModule identifying information:

Field

Type

Required?

Description

vendorName

string

Yes

Network function vendor name

nfModuleName

string

No

Name of the nfModule generating the event

nfName

string

No

Name of the network function generating the event

8.7.4.2. Common Event Header Data Types

8.7.4.2.1. Datatype: commonEventHeader

The commonEventHeader datatype consists of the following fields common to all events:

Field

Type

Required?

Description

domain

string

Yes

Event domain enumeration: ‘fault’, ‘heartbeat’, ‘measurement’, ‘mobileFlow’ , ‘notification’, ‘other’, ‘perf3gpp’, ‘pnfRegistration’, ‘sipSignaling’, ‘stateChange’, ‘syslog’, ‘thresholdCrossingAlert’, ‘voiceQuality’

eventId

string

Yes

Event key that is unique to the event source. The key must be unique within notification life cycle similar to EventID from 3GPP. It could be a sequential number, or a composite key formed from the event fields, such as domain_sequence. The eventId should not include whitespace. For fault events, eventId is the eventId of the initial alarm; if the same alarm is raised again for changed, acknowledged or cleared cases, eventId must be the same as the initial alarm (along with the same startEpochMicrosec but with a different sequence number). Note: see section 1.3 for eventId use case examples.

eventName

string

Yes

eventType

string

No

internalHeader Fields

internalHeader Fields

No

Fields (not supplied by event sources) that the VES Event Listener service can use to enrich the event if needed for efficient internal processing. This is an empty object which is intended to be defined separately by each service provider (e.g., AT&T) implementing the VES Event Listener.

lastEpochMicrosec

number

Yes

the latest unix time aka epoch time associated with the event from any component–as microseconds elapsed since 1 Jan 1970 not including leap seconds

nfcNamingCode

string

No

Network function component type: 3 characters (aligned with vfc naming standards)

nfNamingCode

string

No

Network function type: 4 characters (aligned with vnf and pnf naming standards)

nfVendorName

string

No

priority

string

Yes

reportingEntityId

string

No

UUID identifying the entity reporting the event or detecting a problem in another vnf/vm or pnf which is experiencing the problem. (Note: the AT&T internal enrichment process shall ensure that this field is populated). The reportingEntityId is an id for the reportingEntityName. See ‘reportingEntityName’ for more information.

reportingEntityName

string

Yes

Name of the entity reporting the event or detecting a problem in another vnf/vm or pnf which is experiencing the problem. May be the same as the sourceName. For synthetic events generated by DCAE, it is the name of the app generating the event.

sequence

integer

Yes

Ordering of events communicated by an event source instance (or 0 if not needed)

sourceId

string

No

UUID identifying the entity experiencing the event issue, which may be detected and reported by a separate reporting entity (note: the AT&T internal enrichment process shall ensure that this field is populated). The sourceId is an id for the sourceName. See ‘sourceName’ for more information.

sourceName

string

Yes

Name of the entity experiencing the event issue, which may be detected and reported by a separate reporting entity. The sourceName identifies the device for which data is collected. A valid sourceName must be inventoried in A&AI. If sourceName is a xNF (vnf or pnf), xNFC or VM, then the event must be reporting data for that particular xNF, xNFC or VM. If the sourceName is a xNF, comprised of multiple xNFCs, the data must be reported/aggregated at the xNF level. Data for individual xNFC must not be included in the xNF sourceName event.

startEpochMicrosec

number

Yes

the earliest unix time aka epoch time associated with the event from any component–as microseconds elapsed since 1 Jan 1970 not including leap seconds. For measurements and heartbeats, where events are collected over predefined intervals, startEpochMicrosec shall be rounded to the nearest interval boundary (e.g., the epoch equivalent of 3:00PM, 3:10PM, 3:20PM, etc…). For fault events, startEpochMicrosec is the timestamp of the initial alarm; if the same alarm is raised again for changed, acknowledged or cleared cases, startEpoch Microsec must be the same as the initial alarm (along with the same eventId and an incremental sequence number). For devices with no timing source (clock), the default value will be 0 and the VES collector will replace it with Collector time stamp (when the event is received)

timeZoneOffset

string

No

Offset to GMT to indicate local time zone for device formatted as ‘UTC+/-hh:mm’; see time_zone_abbreviations for UTC offset examples

version

string

Yes

Version of the event header as “#.#” where # is a digit; see section 1 for the correct digits to use.

vesEventListenerVersion

string

Yes

Version of the ves event listener api spec that this event is compliant with (as “#” or “#.#” or “#.#.#” where # is a digit; see section 1 for the correct digits to use).

8.7.4.2.2. Datatype: internalHeaderFields

The internalHeaderFields datatype is an undefined object which can contain arbitrarily complex JSON structures. It is intended to be defined separately by each service provider (e.g., AT&T) implementing the VES Event Listener. The fields in internalHeaderFields are not provided by any event source but instead are added by the VES Event Listener service itself as part of an event enrichment process necessary for efficient internal processing of events received by the VES Event Listener.

8.7.4.3. Technology Independent Datatypes

8.7.4.3.1. ‘Fault’ Domain Datatypes

8.7.4.3.1.1. Datatype: faultFields

The faultFields datatype consists of the following fields:

Field

Type

Required?

Description

alarmAdditional Information

hashMap

No

Additional alarm information.

  • Note1: for SNMP mapping to VES, for hash key use OID of varbind, for value use incoming data for that varbind).

  • Note2: Alarm ID for 3GPP should be included (if applicable) in alarmAdditonalInformation as ‘alarmId’:’alarmIdValue’.

Could contain managed object instance as separate key:value; could add probable cause as separate key:value.

alarmCondition

string

Yes

Short name of the alarm condition/problem, such as a trap name. Should not have white space (e.g., tpLgCgiNotInConfig, BfdSessionDown, linkDown, etc…)

alarmInterfaceA

string

No

Card, port, channel or interface name of the device generating the alarm. This could reflect managed object.

eventCategory

string

No

Event category, for example: ‘license’, ‘link’, ‘routing’, ‘security’, ‘signaling’

eventSeverity

string

Yes

Event severity enumeration: ‘CRITICAL’, ‘MAJOR’, ‘MINOR’, ‘WARNING’, ‘NORMAL’. NORMAL is used to represent clear.

eventSourceType

string

Yes

Examples: ‘card’, ‘host’, ‘other’, ‘port’, ‘portThreshold’, ‘router’, ‘slotThreshold’, ‘switch’, ‘virtualMachine’, ‘virtualNetworkFunction’. This could be managed object class.

faultFieldsVersion

string

Yes

Version of the faultFields block as “#.#” where # is a digit; see section 1 for the correct digits to use.

specificProblem

string

Yes

Description of the alarm or problem (e.g., ‘eNodeB 155197 in PLMN 310-410 with eNodeB name KYL05197 is lost’). 3GPP probable cause would be included in this field.

vfStatus

string

Yes

Virtual function status enumeration: ‘Active’, ‘Idle’, ‘Preparing to terminate’, ‘Ready to terminate’, ‘Requesting Termination’

8.7.4.3.2. Heartbeat’ Domain Datatypes

8.7.4.3.2.1. Datatype: heartbeatFields

The heartbeatFields datatype is an optional field block for fields specific to heartbeat events; it consists of the following fields:

Field

Type

Required?

Description

additionalFields

hashMap

No

Additional expansion fields if needed

heartbeatFieldsVersion

string

Yes

Version of the heartbeatFields block as “#.#” where # is a digit; see section 1 for the correct digits to use.

heartbeatInterval

Integer

Yes

Current heartbeatInterval in seconds

8.7.4.3.3. ‘Measurements’ Domain Datatypes

Note: NFs are required to report exactly one Measurement event per period per sourceName.

8.7.4.3.3.1. Datatype: codecsInUse

The codecsInUse datatype consists of the following fields describing the number of times an identified codec was used over the measurementInterval:

Field

Type

Required?

Description

codecIdentifer

string

Yes

Description of the codec

numberInUse

integer

Yes

Number of such codecs in use

8.7.4.3.3.2. Datatype: cpuUsage

The cpuUsage datatype defines the usage of an identifier CPU and consists of the following fields:

Field

Type

Required?

Description

cpuCapacityContention

number

No

The amount of time the CPU cannot run due to contention, in milliseconds over the measurementInterval

cpuDemandAvg

number

No

The total CPU time that the NF/NFC/VM could use if there was no contention, in milliseconds over the measurementInterval

cpuDemandMhz

number

No

CPU demand in MHz

cpuDemandPct

number

No

CPU demand as a percentage of the provisioned capacity

cpuIdentifier

string

Yes

CPU Identifier

cpuIdle

number

No

Percentage of CPU time spent in the idle task

cpuLatencyAvg

number

No

Percentage of time the VM is unable to run because it is contending for access to the physical CPUs

cpuOverheadAvg

number

No

The overhead demand above available allocations and reservations, in milliseconds over the measurementInterval

cpuSwapWaitTime

number

No

Swap wait time, in milliseconds over the measurementInterval

cpuUsageInterrupt

number

No

Percentage of time spent servicing interrupts

cpuUsageNice

number

No

Percentage of time spent running user space processes that have been niced

cpuUsageSoftIrq

number

No

Percentage of time spent handling soft irq interrupts

cpuUsageSteal

number

No

Percentage of time spent in involuntary wait which is neither user, system or idle time and is effectively time that went missing

cpuUsageSystem

number

No

Percentage of time spent on system tasks running the kernel

cpuUsageUser

number

No

Percentage of time spent running un-niced user space processes

cpuWait

number

No

Percentage of CPU time spent waiting for I/O operations to complete

percentUsage

number

Yes

Aggregate cpu usage of the virtual machine on which the xNFC reporting the event is running

8.7.4.3.3.3. Datatype: diskUsage

The diskUsage datatype defines the usage of a disk and consists of the following fields:

Field

Type

Required?

Description

diskBusResets

number

No

Number of bus resets over the measurementInterval

diskCommandsAborted

number

No

Number of disk commands aborted over the measurementInterval

diskCommandsAvg

number

No

Average number of commands per second over the measurementInterval

diskFlushRequests

number

No

Total flush requests of the disk cache over the measurementInterval

diskFlushTime

number

No

Milliseconds spent on disk cache flushing over the measurementInterval

diskIdentifier

string

Yes

Disk Identifier

diskIoTimeAvg

number

No

Milliseconds spent doing input/output operations over 1 sec; treat this metric as a device load percentage where 1000ms matches 100% load; provide the average over the measurement interval

diskIoTimeLast

number

No

Milliseconds spent doing input/output operations over 1 sec; treat this metric as a device load percentage where 1000ms matches 100% load; provide the last value measurement within the measurement interval

diskIoTimeMax

number

No

Milliseconds spent doing input/output operations over 1 sec; treat this metric as a device load percentage where 1000ms matches 100% load; provide the maximum value measurement within the measurement interval

diskIoTimeMin

number

No

Milliseconds spent doing input/output operations over 1 sec; treat this metric as a device load percentage where 1000ms matches 100% load; provide the minimum value measurement within the measurement interval

diskMergedReadAvg

number

No

Number of logical read operations that were merged into physical read operations, e.g., two logical reads were served by one physical disk access; provide the average measurement within the measurement interval

diskMergedReadLast

number

No

Number of logical read operations that were merged into physical read operations, e.g., two logical reads were served by one physical disk access; provide the last value measurement within the measurement interval

diskMergedReadMax

number

No

Number of logical read operations that were merged into physical read operations, e.g., two logical reads were served by one physical disk access; provide the maximum value measurement within the measurement interval

diskMergedReadMin

number

No

Number of logical read operations that were merged into physical read operations, e.g., two logical reads were served by one physical disk access; provide the minimum value measurement within the measurement interval

diskMergedWriteAvg

number

No

Number of logical write operations that were merged into physical write operations, e.g., two logical writes were served by one physical disk access; provide the average measurement within the measurement interval

diskMergedWriteLast

number

No

Number of logical write operations that were merged into physical write operations, e.g., two logical writes were served by one physical disk access; provide the last value measurement within the measurement interval

diskMergedWriteMax

number

No

Number of logical write operations that were merged into physical write operations, e.g., two logical writes were served by one physical disk access; provide the maximum value measurement within the measurement interval

diskMergedWriteMin

number

No

Number of logical write operations that were merged into physical write operations, e.g., two logical writes were served by one physical disk access; provide the minimum value measurement within the measurement interval

diskOctetsRead Avg

number

No

Number of octets per second read from a disk or partition; provide the average measurement within the measurement interval

diskOctetsRead

Last

number

No

Number of octets per second read from a disk or partition; provide the last measurement within the measurement interval

diskOctetsRead Max

number

No

Number of octets per second read from a disk or partition; provide the maximum measurement within the measurement interval

diskOctetsRead Min

number

No

Number of octets per second read from a disk or partition; provide the minimum measurement within the measurement interval

diskOctetsWrite Avg

number

No

Number of octets per second written to a disk or partition; provide the average measurement within the measurement interval

diskOctetsWrite Last

number

No

Number of octets per second written to a disk or partition; provide the last measurement within the measurement interval

diskOctetsWriteMax

number

No

Number of octets per second written to a disk or partition; provide the maximum measurement within the measurement interval

diskOctetsWriteMin

number

No

Number of octets per second written to a disk or partition; provide the minimum measurement within the measurement interval

diskOpsReadAvg

number

No

Number of read operations per second issued to the disk; provide the average measurement within the measurement interval

diskOpsReadLast

number

No

Number of read operations per second issued to the disk; provide the last measurement within the measurement interval

diskOpsReadMax

number

No

Number of read operations per second issued to the disk; provide the maximum measurement within the measurement interval

diskOpsReadMin

number

No

Number of read operations per second issued to the disk; provide the minimum measurement within the measurement interval

diskOpsWriteAvg

number

No

Number of write operations per second issued to the disk; provide the average measurement within the measurement interval

diskOpsWriteLast

number

No

Number of write operations per second issued to the disk; provide the last measurement within the measurement interval

diskOpsWrite Max

number

No

Number of write operations per second issued to the disk; provide the maximum measurement within the measurement interval

diskOpsWriteMin

number

No

Number of write operations per second issued to the disk; provide the minimum measurement within the measurement interval

diskPendingOperationsAvg

number

No

Queue size of pending I/O operations per second; provide the average measurement within the measurement interval

diskPendingOperationsLast

number

No

Queue size of pending I/O operations per second; provide the last measurement within the measurement interval

diskPendingOperationsMax

number

No

Queue size of pending I/O operations per second; provide the maximum measurement within the measurement interval

diskPendingOperationsMin

number

No

Queue size of pending I/O operations per second; provide the minimum measurement within the measurement interval

diskReadCommandsAvg

number

No

Average number of read commands issued per second to the disk over the measurementInterval

diskTime

number

No

Nanoseconds spent on disk cache reads/writes within the measurement interval

diskTimeReadAvg

number

No

Milliseconds a read operation took to complete; provide the average measurement within the measurement interval

diskTimeRead Last

number

No

Milliseconds a read operation took to complete; provide the last measurement within the measurement interval

diskTimeRead Max

number

No

Milliseconds a read operation took to complete; provide the maximum measurement within the measurement interval

diskTimeRead Min

number

No

Milliseconds a read operation took to complete; provide the minimum measurement within the measurement interval

diskTimeWrite Avg

number

No

Milliseconds a write operation took to complete; provide the average measurement within the measurement interval

diskTimeWrite Last

number

No

Milliseconds a write operation took to complete; provide the last measurement within the measurement interval

diskTimeWrite Max

number

No

Milliseconds a write operation took to complete; provide the maximum measurement within the measurement interval

diskTimeWrite Min

number

No

Milliseconds a write operation took to complete; provide the minimum measurement within the measurement interval

diskTotalReadLatencyAvg

number

No

Average read time from the perspective of a Guest OS: sum of the Kernel Read Latency and Physical Device Read Latency in milliseconds over the measurement interval

diskTotalWriteLatencyAvg

number

No

Average write time from the perspective of a Guest OS: sum of the Kernel Write Latency and Physical Device Write Latency in milliseconds over the measurement interval

diskWeightedIoTimeAvg

number

No

Measure in ms over 1 sec of both I/O completion time and the backlog that may be accumulating. Value is the average within the collection interval.

diskWeightedIoTimeLast

number

No

Measure in ms over 1 sec of both I/O completion time and the backlog that may be accumulating. Value is the last within the collection interval.

diskWeightedIoTimeMax

number

No

Measure in ms over 1 sec of both I/O completion time and the backlog that may be accumulating. Value is the maximum within the collection interval.

diskWeightedIoTimeMin

number

No

Measure in ms over 1 sec of both I/O completion time and the backlog that may be accumulating. Value is the minimum within the collection interval.

diskWriteCommandsAvg

number

No

Average number of write commands issued per second to the disk over the measurementInterval

8.7.4.3.3.4. Datatype: filesystemUsage

The filesystemUsage datatype consists of the following fields:

Field

Type

Required?

Description

filesystemName

string

Yes

File system name

blockConfigured

number

Yes

Configured block storage capacity in GB

blockIops

number

Yes

Block storage input-output operations per second

blockUsed

number

Yes

Used block storage capacity in GB

ephemeralConfigured

number

Yes

Configured ephemeral storage capacity in GB

ephemeralIops

number

Yes

Ephemeral storage input-output operations per second

ephemeralUsed

number

Yes

Used ephemeral storage capacity in GB

8.7.4.3.3.5. Datatype: hugePages

The hugePages datatype provides metrics on system hugePages; it consists of the following fields:

Field

Type

Required?

Description

bytesFree

number

No

Number of free hugePages in bytes

bytesUsed

number

No

Number of used hugePages in bytes

hugePagesIdentifier

string

Yes

HugePages identifier

percentFree

number

No

Number of free hugePages in percent

percentUsed

number

No

Number of used hugePages in percent

vmPageNumberFree

number

No

Number of free vmPages in numbers

vmPageNumberUsed

number

No

Number of used vmPages in numbers

8.7.4.3.3.6. Datatype: ipmi (Intelligent Platform Management Interface)

The ipmi datatype provides intelligent platform management interface metrics; it consists of the following fields:

Field

Type

Required?

Description

exitAirTemperature

number

No

System fan exit air flow temperature in Celsius

frontPanelTemperature

number

No

Front panel temp in Celsius

ioModuleTemperature

number

No

Io module temp in Celsius

ipmiBaseboardTemperatureArray

ipmiBaseboard Temperature [ ]

No

Array of ipmiBaseboard Temperature objects

ipmiBaseboardVoltageRegulator Array

ipmiBaseboard VoltageRegulator [ ]

No

Array of ipmiBaseboard VoltageRegulator objects

ipmiBatteryArray

ipmiBattery [ ]

No

Array of ipmiBattery objects

ipmiFanArray

ipmiFan [ ]

No

Array of ipmiFan objects

ipmiGlobalAggregateTemperatureMarginArray

ipmiGlobalAggregateTemperatureMargin []

No

ipmi global aggregate temperature margin

ipmiHsbpArray

ipmiHsbp [ ]

No

Array of ipmiHsbp objects

ipmiNicArray

ipmiNic [ ]

No

Array of ipmiNic objects

ipmiPowerSupplyArray

ipmiPowerSupply [ ]

No

Array of ipmiPowerSupply objects

ipmiProcessorArray

ipmiProcessor [ ]

No

Array of ipmiProcessor objects

systemAirflow

number

No

Airflow in cubic feet per minute (cfm)

8.7.4.3.3.7. Datatype: ipmiBaseboardTemperature

The ipmiBaseboardTemperature datatype consists of the following fields which describe ipmi baseboard temperature metrics:

Field

Type

Required?

Description

baseboardTemperature

number

No

Baseboard temperature in celsius

baseboardTemperatureIdentifier

string

Yes

Identifier for the location where the temperature is taken

8.7.4.3.3.8. Datatype: ipmiBaseboardVoltageRegulator

The ipmiBaseboardVoltageRegulator datatype consists of the following fields which describe ipmi baseboard voltage regulator metrics:

Field

Type

Required?

Description

baseboardVoltageRegulatorIdentifier

string

Yes

Identifier for the baseboard voltage regulator

voltageRegulatorTemperature

number

No

Voltage regulator temperature in celsius

8.7.4.3.3.9. Datatype: ipmiBattery

The ipmiBattery datatype consists of the following fields which describe ipmi battery metrics:

Field

Type

Required?

Description

batteryIdentifier

string

Yes

Identifier for the battery

batteryType

string

No

Type of battery

batteryVoltageLevel

number

No

Battery voltage level

8.7.4.3.3.10. Datatype: ipmiFan

The ipmiFan datatype consists of the following fields which describe ipmi fan metrics:

Field

Type

Required?

Description

fanIdentifier

string

Yes

Identifier for the fan

fanSpeed

number

No

Fan speed in revolutions per minute (rpm)

8.7.4.3.3.11. Datatype: ipmiGlobalAggregateTemperatureMargin

The ipmiGlobalAggregateTemperatureMargin datatype consists of the following fields:

Field

Type

Required?

Description

globalAggregateTemperatureMargin

number

No

Temperature margin in Celsius relative to a throttling thermal trip point

globalAggregateTemperatureMarginIdentifier

string

Yes

Identifier for the ipmi global aggregate temperature margin metrics

8.7.4.3.3.12. Datatype: ipmiHsbp

The ipmiHsbp datatype provides ipmi hot swap backplane power metrics; it consists of the following fields:

Field

Type

Required?

Description

hsbpIdentifier

string

Yes

Identifier for the hot swap backplane power unit

hsbpTemperature

number

No

Hot swap backplane power temperature in celsius

8.7.4.3.3.13. Datatype: ipmiNic

The ipmiNic datatype provides network interface control care metrics; it consists of the following fields:

Field

Type

Required?

Description

nicIdentifier

string

Yes

Identifier for the network interface control card

nicTemperature

number

No

nic temperature in Celsius

8.7.4.3.3.14. Datatype: ipmiPowerSupply

The ipmiPowerSupply datatype provides ipmi power supply metrics; it consists of the following fields:

Field

Type

Required?

Description

powerSupplyCurrentOutputPercent

number

No

Current output voltage as a percentage of the design specified level

powerSupplyIdentifier

string

Yes

Identifier for the power supply

powerSupplyInputPower

number

No

Input power in watts

powerSupplyTemperature

number

No

Power supply temperature in Celsius

8.7.4.3.3.15. Datatype: ipmiProcessor

The ipmiProcessor datatype provides ipmi processor metrics; it consists of the following fields:

Field

Type

Required?

Description

processorDimmAggregateThermalMarginArray

processorDimm AggregateThermal Margin [ ]

No

Array of processorDimmAggregate ThermalMargin objects

processorDtsThermalMargin

number

No

Front panel temperature in celsius

processorIdentifier

string

Yes

Identifier for the power supply

processorThermalControlPercent

number

No

Io module temperatue in celsius

8.7.4.3.3.16. Datatype: latencyBucketMeasure

The latencyBucketMeasure datatype consists of the following fields which describe the number of counts falling within a defined latency bucket:

Field

Type

Required?

Description

countsInTheBucket

number

Yes

Number of counts falling within a defined latency bucket

highEndOfLatencyBucket

number

No

High end of bucket range (typically in ms)

lowEndOfLatencyBucket

number

No

Low end of bucket range (typically in ms)

8.7.4.3.3.17. Datatype: load

The load datatype provides metrics on system cpu and io utilization obtained using /proc/loadavg; it consists of the following fields:

Field

Type

Required?

Description

longTerm

number

No

number of jobs in the run queue (state R, cpu utilization) or waiting for disk I/O (state D, io utilization) averaged over 15 minutes using /proc/loadavg

midTerm

number

No

number of jobs in the run queue (state R, cpu utilization) or waiting for disk I/O (state D, io utilization) averaged over 5 minutes using /proc/loadavg

shortTerm

number

No

number of jobs in the run queue (state R, cpu utilization) or waiting for disk I/O (state D, io utilization) averaged over 1 minute using /proc/loadavg

8.7.4.3.3.18. Datatype: machineCheckException

The machineCheckException datatype describes machine check exceptions; it consists of the following fields:

Field

Type

Required?

Description

correctedMemoryErrors

number

No

Total hardware errors that were corrected by the hardware (e.g. data corruption corrected via ECC) over the measurementInterval. These errors do not require immediate software actions, but are still reported for accounting and predictive failure analysis

correctedMemoryErrors In1Hr

number

No

Total hardware errors that were corrected by the hardware over the last one hour

uncorrectedMemoryErrors

number

No

Total uncorrected hardware errors that were detected by the hardware (e.g., causing data corruption) over the measurementInterval. These errors require a software response.

uncorrectedMemoryErrors In1Hr

number

No

Total uncorrected hardware errors that were detected by the hardware over the last one hour

vmIdentifier

string

Yes

Virtual machine identifier associated with the machine check exception

8.7.4.3.3.19. Datatype: measurementFields

The measurementFields datatype consists of the following fields:

Field

Type

Required?

Description

additionalFields

hashMap

No

Additional measurement fields if needed

additionalMeasurements

arrayOfNamedHashMap

No

Array of named hashMap if needed

additionalObjects

arrayOfJsonObject

No

Array of JSON objects described by name, schema and other meta-information, if needed

codecUsageArray

codecsInUse []

No

Array of codecs in use

concurrentSessions

integer

No

Peak concurrent sessions for the VM or xNF (depending on the context) over the measurementInterval

configuredEntities

integer

No

Depending on the context over the measurementInterval: peak total number of users, subscribers, devices, adjacencies, etc., for the VM, or peak total number of subscribers, devices, etc., for the xNF

cpuUsageArray

cpuUsage []

No

Usage of an array of CPUs

diskUsageArray

diskUsage []

No

Usage of an array of disks

featureUsageArray

hashMap

No

The hashMap key should identify the feature, while the value defines the number of times the identified feature was used

filesystemUsageArray

filesystemUsage [ ]

No

Filesystem usage of the VM on which the xNFC reporting the event is running

hugePagesArray

hugePages [ ]

No

Array of metrics on hugePages

ipmi

ipmi

No

Intelligent platform management interface metrics

latencyDistribution

latencyBucketMeasure [ ]

No

Array of integers representing counts of requests whose latency in milliseconds falls within per-xNF configured ranges; where latency is the duration between a service request and its fulfillment.

loadArray

load [ ]

No

Array of system load metrics

machineCheckExceptionArray

machineCheckException [ ]

No

Array of machine check exceptions

meanRequestLatency

number

No

Mean seconds required to respond to each request for the VM on which the xNFC reporting the event is running

measurementFieldsVersion

string

Yes

Version of the measurementFields block as “#.#” where # is a digit; see section 1 for the correct digits to use.

measurementInterval

number

Yes

Interval over which measurements are being reported in seconds

memoryUsageArray

memoryUsage []

No

Memory usage of an array of VMs

nfcScalingMetric

integer

No

Represents busy-ness of the network function from 0 to 100 as reported by the nfc

nicPerformanceArray

nicPerformance [ ]

No

Performance metrics of an array of network interface cards

numberOfMediaPortsInUse

integer

No

Number of media ports in use

processStatsArray

processStats [ ]

No

Array of metrics on system processes

requestRate

number

No

Peak rate of service requests per second to the xNF over the measurementInterval

8.7.4.3.3.20. Datatype: memoryUsage

The memoryUsage datatype defines the memory usage of a virtual machine and consists of the following fields:

Field

Type

Required?

Description

memoryBuffered

number

No

Kibibytes of temporary storage for raw disk blocks

memoryCached

number

No

Kibibytes of memory used for cache

memoryConfigured

number

No

Kibibytes of memory configured in the virtual machine on which the xNFC reporting the event is running

memoryDemand

number

No

Host demand in kibibytes

memoryFree

number

Yes

Kibibytes of physical RAM left unused by the system

memoryLatencyAvg

number

No

Percentage of time the VM is waiting to access swapped or compressed memory

memorySharedAvg

number

No

Shared memory in kilobytes

memorySlabRecl

number

No

The part of the slab that can be reclaimed such as caches measured in kibibytes

memorySlabUnrecl

number

No

The part of the slab that cannot be reclaimed even when lacking memory measure in kibibytes

memorySwapInAvg

number

No

Amount of memory swapped-in from host cache in kibibytes

memorySwapInRateAvg

number

No

Rate at which memory is swapped from disk into active memory during the interval in kilobytes per second

memorySwapOutAvg

number

No

Amount of memory swapped-out to host cache in kibibytes

memorySwapOutRateAvg

number

No

Rate at which memory is being swapped from active memory to disk during the current interval in kilobytes per second

memorySwapUsedAvg

number

No

Space used for caching swapped pages in the host cache in kibibytes

memoryUsed

number

Yes

Total memory minus the sum of free, buffered, cached and slab memory measured in kibibytes

percentMemoryUsage

number

No

Percentage of memory usage; value = (memoryUsed / (memoryUsed + memoryFree) x 100 if denomintor is nonzero, or 0, if otherwise.

vmIdentifier

string

Yes

Virtual Machine identifier associated with the memory metrics

8.7.4.3.3.21. Datatype: nicPerformance

The nicPerformance datatype consists of the following fields which describe the performance and errors of an of an identified virtual network interface card:

Field

Type

Required?

Description

administrativeState

string

No

Administrative state: enum: ‘inService’, ‘outOfService’

nicIdentifier

string

Yes

Network interface card identifier

operationalState

string

No

Operational state: enum: ‘inService’, ‘outOfService’

receivedBroadcastPacketsAccumulated

number

No

Cumulative count of broadcast packets received as read at the end of the measurement interval

receivedBroadcastPacketsDelta

number

No

Count of broadcast packets received within the measurement interval

receivedDiscardedPacketsAccumulated

number

No

Cumulative count of discarded packets received as read at the end of the measurement interval

receivedDiscardedPacketsDelta

number

No

Count of discarded packets received within the measurement interval

receivedErrorPacketsAccumulated

number

No

Cumulative count of error packets received as read at the end of the measurement interval

receivedErrorPacketsDelta

number

No

Count of error packets received within the measurement interval

receivedMulticastPacketsAccumulated

number

No

Cumulative count of multicast packets received as read at the end of the measurement interval

receivedMulticastPacketsDelta

number

No

Count of multicast packets received within the measurement interval

receivedOctetsAccumulated

number

No

Cumulative count of octets received as read at the end of the measurement interval

receivedOctetsDelta

number

No

Count of octets received within the measurement interval

receivedPercentDiscard

number

No

Percentage of discarded packets received; value = (receivedDiscardedPacketsDelta / receivedTotalPacketsDelta) x 100, if denominator is nonzero, or 0, if otherwise.

receivedPercentError

number

No

Percentage of error packets received; value = (receivedErrorPacketsDelta / receivedTotalPacketsDelta) x 100, if denominator is nonzero, or 0, if otherwise.

receivedTotalPacketsAccumulated

number

No

Cumulative count of all packets received as read at the end of the measurement interval

receivedTotalPacketsDelta

number

No

Count of all packets received within the measurement interval

receivedUnicastPacketsAccumulated

number

No

Cumulative count of unicast packets received as read at the end of the measurement interval

receivedUnicastPacketsDelta

number

No

Count of unicast packets received within the measurement interval

receivedUtilization

number

No

Percentage of utilization received; value = (receivedOctetsDelta / (speed x (lastEpochMicrosec - startEpochMicrosec) )) x 100, if denominator is nonzero, or 0, if otherwise.

speed

number

No

Speed configured in mbps.

transmittedBroadcastPacketsAccumulated

number

No

Cumulative count of broadcast packets transmitted as read at the end of the measurement interval

transmittedBroadcastPacketsDelta

number

No

Count of broadcast packets transmitted within the measurement interval

transmittedDiscardedPacketsAccumulated

number

No

Cumulative count of discarded packets transmitted as read at the end of the measurement interval

transmittedDiscardedPacketsDelta

number

No

Count of discarded packets transmitted within the measurement interval

transmittedErrorPacketsAccumulated

number

No

Cumulative count of error packets transmitted as read at the end of the measurement interval

transmittedErrorPacketsDelta

number

No

Count of error packets transmitted within the measurement interval

transmittedMulticastPacketsAccumulated

number

No

Cumulative count of multicast packets transmitted as read at the end of the measurement interval

transmittedMulticastPacketsDelta

number

No

Count of multicast packets transmitted within the measurement interval

transmittedOctetsAccumulated

number

No

Cumulative count of octets transmitted as read at the end of the measurement interval

transmittedOctetsDelta

number

No

Count of octets transmitted within the measurement interval

transmittedPercentDiscard

number

No

Percentage of discarded packets transmitted; value = (transmittedDiscardedPacketsDelta / transmittedTotalPacketsDelta) x 100, if denominator is nonzero, or 0, if otherwise.

transmittedPercentError

number

No

Percentage of error packets received; value = (transmittedErrorPacketsDelta / transmittedTotalPacketsDelta) x 100, if denominator is nonzero, or 0, if otherwise.

transmittedTotalPacketsAccumulated

number

No

Cumulative count of all packets transmitted as read at the end of the measurement interval

transmittedTotalPacketsDelta

number

No

Count of all packets transmitted within the measurement interval

transmittedUnicastPacketsAccumulated

number

No

Cumulative count of unicast packets transmitted as read at the end of the measurement interval

transmittedUnicastPacketsDelta

number

No

Count of unicast packets transmitted within the measurement interval

transmittedUtilization

number

No

Percentage of utilization transmitted; value = (transmittedOctetsDelta / (speed x (lastEpochMicrosec - startEpochMicrosec))) x 100, if denominator is nonzero, or 0, if otherwise.

valuesAreSuspect

string

Yes

Enumeration: ‘true’ or ‘false’. If ‘true’ then the vNicPerformance values are likely inaccurate due to counter overflow or other conditions.

8.7.4.3.3.22. Datatype: processorDimmAggregateThermalMargin

The processorDimmAggregateThermalMargin datatype provides intelligent platform management interface (ipmi) processor dual inline memory module aggregate thermal margin metrics; it consists of the following fields:

Field

Type

Required?

Description

processorDimmAggregateThermal MarginIdentifier

string

Yes

identifier for the aggregate thermal margin metrics from the processor dual inline memory module

thermalMargin

number

Yes

the difference between the DIMM’s current temperature, in celsius, and the DIMM’s throttling thermal trip

8.7.4.3.3.23. Datatype: processStats

The processStats datatype provides metrics on system processes; it consists of the following fields:

Field

Type

Required?

Description

forkRate

number

No

The number of threads created since the last reboot

processIdentifier

string

Yes

processIdentifier

psStateBlocked

number

No

The number of processes in a blocked state

psStatePaging

number

No

The number of processes in a paging state

psStateRunning

number

No

The number of processes in a running state

psStateSleeping

number

No

The number of processes in a sleeping state

psStateStopped

number

No

The number of processes in a stopped state

psStateZombie

number

No

The number of processes in a zombie state

8.7.4.3.4. ‘Notification’ Domain Datatypes

8.7.4.3.4.1. Datatype: notificationFields

The notificationFields datatype consists of the following fields:

Field

Type

Required?

Description

additionalFields

hashMap

No

Additional notification fields if needed

arrayOfNamedHashMap

namedHashMap [ ]

No

Array of named hashMaps

changeContact

string

No

Identifier for a contact related to the change

changeIdentifier

string

Yes

System or session identifier associated with the change

changeType

string

Yes

Describes what has changed for the entity, for example: configuration changed, capability added, capability removed…

newState

string

No

New state of the entity, for example: ‘inService’, ‘maintenance’, ‘outOfService’

notificationFieldsVersion

string

Yes

Version of the notificationFields block as “#.#” where # is a digit; see section 1 for the correct digits to use.

oldState

string

No

Previous state of the entity, for example: ‘inService’, ‘maintenance’, ‘outOfService’

stateInterface

string

No

Card or port name of the entity that changed state

The fileReady notification event is used by 3GPP-compliant NFs to notify ONAP that a PM file is available for upload. The notificationFields are populated as follows:

arrayOfNamedHashMap: The array is named for the PM file as defined in 3GPP TS 28.550. The array contains the following key value pairs:

  • location in the form protocol://ipAddress:port/path/filename; e.g. “location” : “ftpes://135.3.1.44:21/pmfiles/A20180531.1030+0600-1045+0600A20000626.2315+0200-2330+0200_NodeBId.gz”

  • compression containing the compression type used for the PM file; e.g. “compression” : “gzip”

  • fileFormatType containing the format type of the PM file; e.g. “fileFormatType” : “org.3GPP.32.435#measCollec”

  • fileFormatVersion containing the format version of the PM file; e.g. “fileFormatVersion” : “V10”

  • other vendor-defined key-value pairs as needed

changeIdentifier: set to PM_MEAS_FILES

changeType: set to fileReady

Other notificationFields are not used for fileReady.

8.7.4.3.5. ‘Other’ Domain Datatypes

8.7.4.3.5.1. Datatype: otherFields

The otherFields datatype defines fields for events belonging to the ‘other’ domain of the commonEventHeader domain enumeration; it consists of the following fields:

Field

Type

Required?

Description

arrayOfNamedHashMap

arrayOfNamedHashMap

No

Array of named hashMaps

hashMap

hashMap

No

Array of name-value pairs

jsonObjects

arrayOfJsonObject

No

Array of JSON objects described by name, schema and other meta-information

otherFieldsVersion

string

Yes

Version of the otherFields block as “#.#” where # is a digit; see section 1 for the correct digits to use.

8.7.4.3.6. ‘perf3gpp’ Domain Datatypes

8.7.4.3.6.1. Datatype: measDataCollection

The measDataCollection datatype defines a 3GPP measurement collection structure aligned with the 3GPP PM format; it consists of the following fields:

Field

Type

Required?

Description

formatVersion

string

No

3GPP PM reporting file format version from pre-standard TS 28.550 v2.0.0

granularityPeriod

string

Yes

Granularity period for the PM report in seconds

measInfoList

measInfo [ ]

Yes

Array of measInfo measurements

measObjInstIdList

string [ ]

No

Array of monitored object local distinguished name ids per 3GPP TS 32.300

measuredEntityDn

string

Yes

Distinguished name per 3GPP TS 28.550

measuredEntitySoftwareVersion

string

No

Software version for the NF providing the PM data as specified in 3GPP TS 28.550

measuredEntityUserName

string

No

User Definable name for the measured object per 3GPP TS 28.550

8.7.4.3.6.2. Datatype: measInfo

The measInfo datatype provides measurement information; it consists of the following fields:

Field

Type

Required?

Description

jobId

string

No

Name of the measurement job

measInfoId

oneOf [ measInfoIdInteger , measInfoIdString ]

No

Measurement group Identifier

measTypes

oneOf [ measTypesInteger , measTypesString ]

Yes

Array of measurement identifiers associated with the measurement results expressed as integers for efficiency rather than strings

measValues

measValues [ ]

Yes

Array of measValues

8.7.4.3.6.3. Datatype: measInfoIdInteger

The measInfoIdInteger datatype provides an integer measurement group identifier; it consists of the following fields:

Field

Type

Required?

Description

iMeasInfoId

integer

Yes

Integer measurement group Identifier

8.7.4.3.6.4. Datatype: measInfoIdString

The measInfoIdString datatype provides a string measurement group identifier; it consists of the following fields:

Field

Type

Required?

Description

sMeasInfoId

integer

Yes

String measurement group Identifier

8.7.4.3.6.5. Datatype: measResultInteger

The measResultInteger datatype provides an integer 3GPP PM measurement result; it consists of the following fields:

Field

Type

Required?

Description

p

integer

Yes

Integer reference to the counter

iValue

integer

Yes

Integer counter value

8.7.4.3.6.6. Datatype: measResultNull

The measResultNull datatype provides a null 3GPP PM measurement result; it consists of the following fields:

Field

Type

Required?

Description

p

integer

Yes

Integer reference to the counter

isNull

string

Yes

Enumeration: ‘true’ or ‘false’

8.7.4.3.6.7. Datatype: measResultNumber

The measResultNumber datatype provides a number 3GPP PM measurement result; it consists of the following fields:

Field

Type

Required?

Description

p

integer

Yes

Integer reference to the counter

rValue

number

Yes

Number counter value

8.7.4.3.6.8. Datatype: measResultString

The measResultString datatype provides a string 3GPP PM measurement result; it consists of the following fields:

Field

Type

Required?

Description

p

integer

Yes

Integer reference to the counter

sValue

string

Yes

String counter value

8.7.4.3.6.9. Datatype: measTypesInteger

The measTypesInteger datatype provides an array of integer measurement identifiers associated with the measurement results; it consists of the following fields:

Field

Type

Required?

Description

iMeasTypesList

integer [ ]

Yes

Array of integer measurement identifiers associated with the measurement results

8.7.4.3.6.10. Datatype: measTypesString

The measTypesString datatype provides an array of string measurement identifiers associated with the measurement results; it consists of the following fields:

Field

Type

Required?

Description

sMeasTypesList

string [ ]

Yes

Array of string measurement identifiers associated with the measurement results

8.7.4.3.6.11. Datatype: measValues

The measValues datatype provides 3GPP measurement values; it consists of the following fields:

Field

Type

Required?

Description

measObjAddlFlds

hashMap

No

Additional key-value pairs if needed

measObjInstId

measDataCollection

Yes

Monitored object local distinguished name per 3GPP TS 32.300 and 3GPP TS 32.432

measResults

Array of items where each item is oneOf [ measResultInteger, measResultNull, measResultNumber, measResultString ]

Yes

Array of results

suspectFlag

string

No

Enumeration: ‘true’, ‘false’. Indicates if the values are suspect

8.7.4.3.6.12. Datatype: perf3gppFields

The perf3gppFields datatype defines fields for 3GPP PM format events, based on 3GPP TS 28.550, belonging to the ‘perf3gpp’ domain of the commonEventHeader domain enumeration; it consists of the following fields:

Field

Type

Required?

Description

eventAddlFields

hashMap

No

Additional key-value pairs if needed

measDataCollection

measData Collection

Yes

3GPP measurement collection structure

perf3gppFieldsVersion

string

Yes

Version of the perf3gpp event

8.7.4.3.7. ‘pnfRegistration’ Domain Datatypes

8.7.4.3.7.1. Datatype: pnfRegistrationFields

The pnfRegistrationFields datatype defines fields for events belonging to the ‘pnfRegistration’ domain of the commonEventHeader domain enumeration; it consists of the following fields:

Field

Type

Required?

Description

additionalFields

hashMap

No

Additional pnfRegistration fields if needed

lastServiceDate

string

No

TS 32.692 dateOfLastService = date of last service; e.g. 15022017

macAddress

string

No

MAC address of OAM interface of the unit

manufactureDate

string

No

TS 32.692 dateOfManufacture = manufacture date of the unit; 24032016

modelNumber

string

No

TS 32.692 versionNumber = version of the unit from vendor; e.g. AJ02. Maps to AAI equip-model

oamV4IpAddress

string

No

IPv4 m-plane IP address to be used by the manager to contact the PNF

oamV6IpAddress

string

No

IPv6 m-plane IP address to be used by the manager to contact the PNF

pnfRegistrationFieldsVersion

string

Yes

Version of the pnfRegistrationFields block as “#.#” where # is a digit; see section 1 for the correct digits to use.

serialNumber

string

No

TS 32.692 serialNumber = serial number of the unit; e.g. 6061ZW3

softwareVersion

string

No

TS 32.692 swName = active SW running on the unit; e.g. 5gDUv18.05.201

unitFamily

string

No

TS 32.692 vendorUnitFamilyType = general type of HW unit; e.g. BBU

unitType

string

No

TS 32.692 vendorUnitTypeNumber = vendor name for the unit; e.g. Airscale

vendorName

string

No

TS 32.692 vendorName = name of manufacturer; e.g. Nokia. Maps to AAI equip-vendor

8.7.4.3.8. ‘State Change’ Domain Datatypes

8.7.4.3.8.1. Datatype: stateChangeFields

The stateChangeFields datatype consists of the following fields:

Field

Type

Required?

Description

additionalFields

hashMap

No

Additional stateChange fields if needed

newState

string

Yes

New state of the entity: ‘inService’, ‘maintenance’, ‘outOfService’

oldState

string

Yes

Previous state of the entity: ‘inService’ , ‘maintenance’, ‘outOfService’

stateChangeFieldsVersion

string

Yes

Version of the stateChangeFields block as “#.#” where # is a digit; see section 1 for the correct digits to use.

stateInterface

string

Yes

Card or port name of the entity that changed state

8.7.4.3.9. ‘Syslog’ Domain Datatypes

8.7.4.3.9.1. Datatype: syslogFields

The syslogFields datatype consists of the following fields:

Field

Type

Required?

Description

additionalFields

hashMap

No

Additional syslog fields if needed Ex: {“name1”: “value1”, “name2: “value2” … }

eventSourceHost

string

No

Hostname of the device

eventSourceType

string

Yes

Examples: ‘other’, ‘router’, ‘switch’, ‘host’, ‘card’, ‘port’, ‘slotThreshold’, ‘portThreshold’, ‘virtualMachine’, ‘virtualNetworkFunction’

syslogFacility

integer

No

Numeric code from 0 to 23 for facility:

0 kernel messages

1 user-level messages

2 mail system

3 system daemons

4 security/authorization messages

5 messages generated internally by syslogd

6 line printer subsystem

7 network news subsystem

8 UUCP subsystem

9 clock daemon

10 security/authorization messages

11 FTP daemon

12 NTP subsystem

13 log audit

14 log alert

15 clock daemon (note 2)

16 local use 0 (local0)

17 local use 1 (local1)

18 local use 2 (local2)

19 local use 3 (local3)

20 local use 4 (local4)

21 local use 5 (local5)

22 local use 6 (local6)

23 local use 7 (local7 )

syslogFieldsVersion

string

Yes

Version of the syslogFields block as “#.#” where # is a digit; see section 1 for the correct digits to use.

syslogMsg

string

Yes

Syslog message

syslogMsgHost

string

No

Hostname parsed from non-VES syslog message

syslogPri

integer

No

0-192

Combined Severity and Facility(see rfc5424)

syslogProc

string

No

Identifies the application that originated the message

syslogProcId

number

No

The process number assigned by the OS when the application was started

syslogSData

string

No

A <space> separated list of key=”value” pairs following the rfc5424 standard for SD-ELEMENT.

*Deprecated *

The entire rfc5424 syslogSData object, including square brackets [ ], SD-ID and list of SD-PARAMs

syslogSdId

string

No

0-32 char in format name@number,

i.e., ourSDID@32473

syslogSev

string

No

Level-of-severity text enumeration defined below:

Text Sev Description

Emergency 0 system is unusable

Alert 1 action must be taken immediately

Critical 2 critical conditions

Error 3 error conditions

Warning 4 warning conditions

Notice 5 normal but significant condition

Info 6 Informational messages

Debug 7 debug-level messages

syslogTag

string

Yes

Also known as MsgId. Brief non-spaced text indicating the type of message such as ‘TCPOUT’ or ‘BGP_STATUS_CHANGE’; ‘NILVALUE’ should be used when no other value can be provided

syslogTs

string

No

Timestamp parsed from non-VES syslog message

syslogVer

number

No

IANA assigned version of the syslog protocol specification:

0: VES

1: IANA RFC5424

Examples of syslogSData :

Preferred

ts=”1985-04-12T23:20:50.52Z” tag=”BGP_NEIGHBOR_DOWN” msg=”The BGP session to neighbor 10.10.10.10 is down”

Deprecated

[attinc@1234 ts=”1985-04-12T23:20:50.52Z” tag=”BGP_NEIGHBOR_DOWN” msg=”The BGP session to neighbor 10.10.10.10 is down”]

Syslog references:

https://tools.ietf.org/html/rfc5424#section-6

8.7.4.3.10. ‘Threshold Crossing Alert’ Domain Datatypes

8.7.4.3.10.1. Datatype: counter

The counter datatype consists of the following fields:

Field

Type

Required?

Description

criticality

string

Yes

Enumeration: ‘CRIT’, ‘MAJ’

hashMap

hashMap

Yes

Key is the name of the counter and value is the current value of the counter

threshholdCrossed

string

Yes

Last threshold that was crossed

8.7.4.3.10.2. Datatype: thresholdCrossingAlertFields

The thresholdCrossingAlertFields datatype consists of the following fields:

Field

Type

Required?

Description

additionalFields

hashMap

No

Additional threshold crossing alert fields if needed

additionalParameters

counter [ ]

Yes

Array of performance counters

alertAction

string

Yes

Enumeration: ‘SET’, ‘CONT’, ‘CLEAR’

alertDescription

string

Yes

Unique short alert description (e.g., NE-CPUMEM)

alertType

string

Yes

Enumeration: ‘CARD-ANOMALY’, ‘INTERFACE-ANOMALY’, ELEMENT-ANOMALY’, ‘SERVICE-ANOMALY’

alertValue

string

No

Calculated API value (if applicable)

associatedAlertIdList

string [ ]

No

List of eventIds associated with the event being reported

collectionTimestamp

string

Yes

Time when the performance collector picked up the data; with RFC 2822 compliant format: ‘Sat, 13 Mar 2010 11:29:05 -0800’

dataCollector

string

No

Specific performance collector instance used

elementType

string

No

Type of network element (internal AT&T field)

eventSeverity

string

Yes

Event severity or priority enumeration: ‘CRITICAL’, ‘MAJOR’, ‘MINOR’, ‘WARNING’ , ‘NORMAL’

eventStartTimestamp

string

Yes

Time closest to when the measurement was made; with RFC 2822 compliant format: ‘Sat, 13 Mar 2010 11:29:05 -0800’

interfaceName

string

No

Physical or logical port or card (if applicable)

networkService

string

No

Network name (internal AT&T field)

possibleRootCause

string

No

Reserved for future use

thresholdCrossing FieldsVersion

string

Yes

Version of the thresholdCrossingAlertFields block as “#.#” where # is a digit; see section 1 for the correct digits to use.

8.7.4.4. Technology Specific Datatypes

8.7.4.4.1. Mobile Flow’ Domain Datatypes

8.7.4.4.1.1. Datatype: gtpPerFlowMetrics

The gtpPerFlowMetrics datatype consists of the following fields:

Field

Type

Required?

Description

avgBitErrorRate

number

Yes

Average bit error rate

avgPacketDelayVariation

number

Yes

Average packet delay variation or jitter in milliseconds for received packets: Average difference between the packet timestamp and time received for all pairs of consecutive packets

avgPacketLatency

number

Yes

Average delivery latency

avgReceiveThroughput

number

Yes

Average receive throughput

avgTransmitThroughput

number

Yes

Average transmit throughput

durConnectionFailedStatus

number

No

Duration of failed state in milliseconds , computed as the cumulative time between a failed echo request and the next following successful error request, over this reporting interval

durTunnelFailedStatus

number

No

Duration of errored state, computed as the cumulative time between a tunnel error indicator and the next following non-errored indicator, over this reporting interval

flowActivatedBy

string

No

Endpoint activating the flow

flowActivationEpoch

number

Yes

Time the connection is activated in the flow (connection) being reported on, or transmission time of the first packet if activation time is not available

flowActivationMicrosec

number

Yes

Integer microseconds for the start of the flow connection

flowActivationTime

string

No

Time the connection is activated in the flow being reported on, or transmission time of the first packet if activation time is not available; with RFC 2822 compliant format: ‘Sat, 13 Mar 2010 11:29:05 -0800’

flowDeactivatedBy

string

No

Endpoint deactivating the flow

flowDeactivationEpoch

number

Yes

Time for the start of the flow connection, in integer UTC epoch time aka UNIX time

flowDeactivationMicrosec

number

Yes

Integer microseconds for the start of the flow connection

flowDeactivationTime

string

Yes

Transmission time of the first packet in the flow connection being reported on; with RFC 2822 compliant format: ‘Sat, 13 Mar 2010 11:29:05 -0800’

flowStatus

string

Yes

Connection status at reporting time as a working / inactive / failed indicator value

gtpConnectionStatus

string

No

Current connection state at reporting time

gtpTunnelStatus

string

No

Current tunnel state at reporting time

ipTosCountList

hashMap

No

Array of key: value pairs where the keys are drawn from the IP Type-of-Service identifiers which range from ‘0’ to ‘255’, and the values are the count of packets that had those ToS identifiers in the flow

ipTosList

string

No

Array of unique IP Type-of-Service values observed in the flow where values range from ‘0’ to ‘255’

largePacketRtt

number

No

large packet round trip time

largePacketThreshold

number

No

large packet threshold being applied

maxPacketDelayVariation

number

Yes

Maximum packet delay variation or jitter in milliseconds for received packets: Maximum of the difference between the packet timestamp and time received for all pairs of consecutive packets

maxReceiveBitRate

number

No

maximum receive bit rate”

maxTransmitBitRate

number

No

maximum transmit bit rate

mobileQciCosCountList

hashMap

No

array of key: value pairs where the keys are drawn from LTE QCI or UMTS class of service strings, and the values are the count of packets that had those strings in the flow

mobileQciCosList

string

No

Array of unique LTE QCI or UMTS class-of-service values observed in the flow

numActivationFailures

number

Yes

Number of failed activation requests, as observed by the reporting node

numBitErrors

number

Yes

number of errored bits

numBytesReceived

number

Yes

number of bytes received, including retransmissions

numBytesTransmitted

number

Yes

number of bytes transmitted, including retransmissions

numDroppedPackets

number

Yes

number of received packets dropped due to errors per virtual interface

numGtpEchoFailures

number

No

Number of Echo request path failures where failed paths are defined in 3GPP TS 29.281 sec 7.2.1 and 3GPP TS 29.060 sec. 11.2

numGtpTunnelErrors

number

No

Number of tunnel error indications where errors are defined in 3GPP TS 29.281 sec 7.3.1 and 3GPP TS 29.060 sec. 11.1

numHttpErrors

number

No

Http error count

numL7BytesReceived

number

Yes

number of tunneled layer 7 bytes received, including retransmissions

numL7BytesTransmitted

number

Yes

number of tunneled layer 7 bytes transmitted, excluding retransmissions

numLostPackets

number

Yes

number of lost packets

numOutOfOrderPackets

number

Yes

number of out-of-order packets

numPacketErrors

number

Yes

number of errored packets

numPacketsReceivedExclRetrans

number

Yes

number of packets received, excluding retransmission

numPacketsReceivedInclRetrans

number

Yes

number of packets received, including retransmission

numPacketsTransmittedInclRetrans

number

Yes

number of packets transmitted, including retransmissions

numRetries

number

Yes

number of packet retrie

numTimeouts

number

Yes

number of packet timeouts

numTunneledL7BytesReceived

number

Yes

number of tunneled layer 7 bytes received, excluding retransmissions

roundTripTime

number

Yes

Round Trip time

tcpFlagCountList

hashMap

No

Array of key: value pairs where the keys are drawn from TCP Flags and the values are the count of packets that had that TCP Flag in the flow

tcpFlagList

string

No

Array of unique TCP Flags observed in the flow

timeToFirstByte

number

Yes

Time in milliseconds between the connection activation and first byte received

8.7.4.4.1.2. Datatype: mobileFlowFields

The mobileFlowFields datatype consists of the following fields:

Field

Type

Required?

Description

additionalFields

hashMap

No

Additional mobileFlow fields if needed

applicationType

string

No

Application type inferred

appProtocolType

string

No

Application protocol

appProtocolVersion

string

No

Application version

cid

string

No

Cell Id

connectionType

string

No

Abbreviation referencing a 3GPP reference point e.g., S1-U, S11, etc

ecgi

string

No

Evolved Cell Global Id

flowDirection

string

Yes

Flow direction, indicating if the reporting node is the source of the flow or destination for the flow

gtpPerFlowMetrics

gtpPer FlowMetrics

Yes

Mobility GTP Protocol per flow metrics

gtpProtocolType

string

No

GTP protocol

gtpVersion

string

No

GTP protocol version

httpHeader

string

No

HTTP request header, if the flow connects to a node referenced by HTTP

imei

string

No

IMEI for the subscriber UE used in this flow, if the flow connects to a mobile device

imsi

string

No

IMSI for the subscriber UE used in this flow, if the flow connects to a mobile device

ipProtocolType

string

Yes

IP protocol type e.g.,TCP, UDP, RTP…

ipVersion

string

Yes

IP protocol version e.g., IPv4, IPv6

lac

string

No

Location area code

mcc

string

No

Mobile country code

mnc

string

No

Mobile network code

mobileFlowFieldsVersion

string

Yes

Version of the mobileFlowFields block as “#.#” where # is a digit; see section 1 for the correct digits to use.

msisdn

string

No

MSISDN for the subscriber UE used in this flow, as an integer, if the flow connects to a mobile device

otherEndpointIpAddress

string

Yes

IP address for the other endpoint, as used for the flow being reported on

otherEndpointPort

integer

Yes

IP Port for the reporting entity, as used for the flow being reported on

otherFunctionalRole

string

No

Functional role of the other endpoint for the flow being reported on e.g., MME, S-GW, P-GW, PCRF…

rac

string

No

Routing area code

radioAccessTechnology

string

No

Radio Access Technology e.g., 2G, 3G, LTE

reportingEndpointIpAddr

string

Yes

IP address for the reporting entity, as used for the flow being reported on

reportingEndpointPort

integer

Yes

IP port for the reporting entity, as used for the flow being reported on

sac

string

No

Service area code

samplingAlgorithm

integer

No

Integer identifier for the sampling algorithm or rule being applied in calculating the flow metrics if metrics are calculated based on a sample of packets, or 0 if no sampling is applied

tac

string

No

Transport area code

tunnelId

string

No

Tunnel identifier

vlanId

string

No

VLAN identifier used by this flow

8.7.4.4.2. ‘SipSignaling’ Domain Datatypes

8.7.4.4.2.1. Datatype: sipSignalingFields

The sipSignalingFields datatype communicates information about sip signaling messages, parameters and signaling state; it consists of the following fields:

Field

Type

Required?

Description

additionalInformation

hashMap

No

Additional sipSignaling fields

compressedSip

string

No

The full SIP request/response including headers and bodies

correlator

string

Yes

Constant across all events on this call

localIpAddress

string

Yes

Ip address on xNF

localPort

string

Yes

Port on xNF

remoteIpAddress

string

Yes

IP address of peer endpoint

remotePort

string

Yes

Port of peer endpoint

sipSignalingFieldsVersion

string

Yes

Version of the sipSignalingFields block as “#.#” where # is a digit; see section 1 for the correct digits to use.

summarySip

string

No

The SIP Method or Response (‘INVITE’, ‘200 OK’, ‘BYE’, etc)

vendorNfNameFields

vendorNf NameFields

Yes

Vendor, NF and nfModule names

8.7.4.4.3. ‘Voice Quality’ Domain Datatypes

8.7.4.4.3.1. Datatype: endOfCallVqmSummaries

The endOfCallVqmSummaries datatype provides end of call voice quality metrics; it consists of the following fields:

Field

Type

Required?

Description

adjacencyName

string

Yes

Adjacency name

endpointAverageJitter

number

No

Endpoint average jitter

endpointDescription

string

Yes

Enumeration: ‘Caller’, ‘Callee’

endpointMaxJitter

number

No

Endpoint maximum jitter

endpointRtpOctetsDiscarded

number

No

Endpoint RTP octets discarded

endpointRtpOctetsLost

number

No

Endpoint RTP octets lost

endpointRtpOctetsReceived

number

No

Endpoint RTP octets received

endpointRtpOctetsSent

number

No

Endpoint RTP octets sent

endpointRtpPacketsDiscarded

number

No

Endpoint RTP packets discarded

endpointRtpPacketsLost

number

No

Endpoint RTP packets lost

endpointRtpPacketsReceived

number

No

Endpoint RTP packets received

endpointRtpPacketsSent

number

No

Endpoint RTP packets sent

localAverageJitter

number

No

Local average jitter

localAverageJitterBufferDelay

number

No

Local average jitter buffer delay

localMaxJitter

number

No

Local maximum jitter

localMaxJitterBufferDelay

number

No

Local max jitter buffer delay

localRtpOctetsDiscarded

number

No

Local RTP octets discarded

localRtpOctetsLost

number

No

Local RTP octets lost

localRtpOctetsReceived

number

No

Local RTP octets received

localRtpOctetsSent

number

No

Local RTP octets sent

localRtpPacketsDiscarded

number

No

Local RTP packets discarded

localRtpPacketsLost

number

No

Local RTP packets lost

localRtpPacketsReceived

number

No

Local RTP packets received

localRtpPacketsSent

number

No

Local RTP packets sent

mosCqe

number

No

Decimal range from 1 to 5(1 decimal place)

oneWayDelay

number

No

one-way path delay in milliseconds

packetLossPercent

number

No

Calculated percentage packet loss based on endpoint RTP packets lost (as reported in RTCP) and local RTP packets sent. Direction is based on endpoint description (Caller, Callee). Decimal (2 decimal places)

rFactor

number

No

rFactor from 0 to 100

roundTripDelay

number

No

Round trip delay in milliseconds

8.7.4.4.3.2. Datatype: voiceQualityFields

The voiceQualityFields datatype provides statistics related to customer facing voice products; consists of the following fields:

Field

Type

Required?

Description

additionalInformation

hashMap

No

Additional voice quality fields

calleeSideCodec

string

Yes

Callee codec for the call

callerSideCodec

string

Yes

Caller codec for the call

correlator

string

Yes

Constant across all events on this call

endOfCallVqmSummaries

endOfCallVqm Summaries

No

End of call voice quality metric summaries

phoneNumber

string

No

Phone number associated with the correlator

midCallRtcp

string

Yes

Base64 encoding of the binary RTCP data (excluding Eth/IP/UDP headers)

vendorNfNameFields

vendorNf NameFields

Yes

Vendor, NF and nfModule names

voiceQualityFieldsVersion

string

Yes

Version of the voiceQualityFields block as “#.#” where # is a digit; see section 1 for the correct digits to use.

8.7.5. Exceptions

8.7.5.1. RESTful Web Services Exceptions

RESTful services generate and send exceptions to clients in response to invocation errors. Exceptions send HTTP status codes (specified later in this document for each operation). HTTP status codes may be followed by an optional JSON exception structure described below. Two types of exceptions may be defined: service exceptions and policy exceptions.

Field Name

Data Type

Required?

Description

messageId

xs:string

Yes

Unique message identifier of the format ‘ABCnnnn’ where ‘ABC’ is either ‘SVC’ for Service Exceptions or ‘POL’ for Policy Exception.

Exception numbers may be in the range of 0001 to 9999 where :

  • 0001 to 2999 are defined by OMA (see OMA’s Common_definitions for details)

  • 3000-9999 are available and undefined

text

xs:string

Yes

Message text, with replacement variables marked with %n, where n is an index into the list of <variables> elements, starting at 1

variables

xs:string [0..unbounded]

No

List of zero or more strings that represent the contents of the variables used by the message text

url

xs:anyUrl

No

Hyperlink to a detailed error resource (e.g., an HTML page for browser user agents).

8.7.5.2. Service Exceptions

When a service is not able to process a request, and retrying the request with the same information will also result in a failure, and the issue is not related to a service policy issue, then the service will issue a fault using the service exception fault message. Examples of service exceptions include invalid input, lack of availability of a required resource or a processing error.

A service exception uses the letters ‘SVC’ at the beginning of the message identifier. ‘SVC’ service exceptions used by the VES Event Listener API are defined below.

MessageId

Description / Comment

Text

Variables

Parent HTTP Code

SVC0001

General service error (see SVC2000)

<custom error message>

None

400

SVC0002

Bad parameter

Invalid input value for message part %1

%1: message part

400

SVC1000

No server resources

No server resources available to process the request

None

500

SVC2000

More elaborate version of SVC0001

The following service error occurred: %1.

Error code is %2.

%1: human readable description of the error

%2: error code

400

Table - Service Exceptions

8.7.5.3. Policy Exceptions

When a service is not able to complete because the request fails to meet a policy criteria, then the service will issue a fault using the policy exception fault message. To clarify how a policy exception differs from a service exception, consider that all the input to an operation may be valid as meeting the required input for the operation (thus no service exception), but using that input in the execution of the service may result in conditions that require the service not to complete. Examples of policy exceptions include privacy violations, requests not permitted under a governing service agreement or input content not acceptable to the service provider.

A Policy Exception uses the letters ‘POL’ at the beginning of the message identifier. ‘POL’ policy exceptions used by the VES Event Listener API are defined below.

MessageId

Description / Comment

Text

Variables

Parent HTTP Code

POL0001

General policy error (see POL2000)

A policy error occurred.

None

401

POL1009

User not provisioned for service

User has not been provisioned for service

None

401

POL1010

User suspended from service

User has been suspended from service

None

401

POL2000

More elaborate version of POL0001

The following policy error occurred: %1. Error code is %2.

%1: human readable description of the error

%2: error code

401

POL9003

Message size exceeds limit

Message content size exceeds the allowable limit

None

400

Table - Policy Exceptions

8.7.6. RESTful Web Services Definition

8.7.6.1. REST Operation Overview

8.7.6.1.1. REST Operation Summary

Operation Action

HTTP

Verb

Resource URL relative to {ServerRoot}, which is defined in section 3

publishAnyEvent

POST

/eventListener/v{apiVersion}

publishEventBatch

POST

/eventListener/v{apiVersion}/eventBatch

Table - REST Operation Summary

8.7.6.1.2. Api Versioning

apiVersion is used to describe the major version number of the event listener API (which is the same as the major version number of this specification). When this number changes, the implication is: the new major version will break clients of older major versions in some way, if they try to use the new API without modification (e.g., unmodified v1 clients would not be able to use v2 without error).

The Event Listener shall provide the following HTTP headers in response to all requests. Additionally, clients may populate these headers on requests to indicate the specific version they are interested in.

  • X-MinorVersion: 1

  • X-PatchVersion: 1

  • X-LatestVersion: 7.1

If a client requests major version 7 (per the REST resource URL) and does not specify the above headers, then they will be provided with the latest patch version of 7.0.x (which is 7.0.1). If the client wants a minor version of major version 7, then they need to supply the X-MinorVersion header with their request. For example, if they request major version 7 with X-MinorVersion: 1, they will get the latest patch version of 7.1, which is 7.1.1.

8.7.6.1.3. Buffering of Events

{ServerRoot} is defined in section 3 of this document, which defines the REST resource URL. One or more FQDNs may be provisioned in an event source when it is instantiated or updated. If an event source is unable to reach any of the provisioned FQDNs, it should buffer the event data specified below, up to a maximum of 1 hour, and re-transmit them once a connection has been established.

The following events should be buffered:

  • Faults with eventSeverity of MINOR, MAJOR, NORMAL, or CRITICAL with following expected behavior:

    • NF keeps a First-In-First-Out buffer.

    • Until the collectors are working again, it is desired that the NF sends the final state events only, and not intermediate ones. However, it is acceptable to buffer all events and send them over to the collector in the same order in which they were generated/received.

  • When one VES Event Listener connectivity is re-established, NF should first send the buffered events and then start sending the new events.

    • Syslog with syslogSev of Emergency, Alert, Critical, Error, or Warning

  • All measurements events

8.7.6.1.3.1. publishEventBatch Requirements

Buffered events can be sent in batch using publishEventBatch. However, a NF vendor must only include multiple events for the same domain in the publishEventBatch. The publishEventBatch event must also conform to event size limits.

publishEventBatch events are handled similarly to a single event. The acknowledgement from the VES Event Listener is for the publishEventBatch and not individual events within the publishEventBatch.

8.7.6.1.3.2. Debug Mode

NFs acting as event sources should not send syslog events to the VES Event Listener during debug mode, but should store syslog events locally for access, and possible FTP transfer, via the NF console (e.g., command line interface).

8.7.6.1.4. Message Size

The maximum allowed message size is 2 megabytes of uncompressed text. However,messages of this size have been known to cause performance and data loss. It is strongly recommended,that messages not exceed 1 megabyte. In a future version of the specification, a 1 megabyte limit will become a mandatory requirement.

8.7.6.2. Operation: publishAnyEvent

8.7.6.2.1. Functional Behavior

Allows authorized clients to publish any single event to the VES event listener.

  • Supports only HTTPS access.

  • Uses the HTTP verb POST

  • Supports JSON content types

  • Provides HTTP response codes as well as Service and Policy error messages

8.7.6.2.2. Call Flow

publishAnyEvent Call Flow

8.7.6.2.3. Input Parameters

Header Fields (note: all parameter names shall be treated as case-insensitive):

Parameter

Data Type

Required?

Brief description

Accept

string

No

Determines the format of the body of the response. Valid values are:

  • application/json

Authorization

string

No

The username and password are formed into one string as username:password. This string is then Base64 encoded to produce the encoded credential which is communicated in the header after the string “Authorization: Basic “. See examples below. If the Authorization header is missing, then an HTTP 400 Invalid Request message shall be returned. If the string supplied is invalid, then an HTTP 401 Unauthorized message shall be returned.

Content-length

integer

No

Note that content length is limited to 2 Megabyte (see Message Size)

Content-type

string

Yes

Must be set to one of the following values:

  • application/json

X-MinorVersion

integer

No

The minor version of the API requested by the client

X-PatchVersion

integer

No

The patch version of the API requested by the client

X-LatestVersion

string

No

The full version of the API requested by the client expressed as {major}.{minor}.{patch}

Body Fields:

Parameter

Data Type

Required?

Brief description

Event

event

Yes

Contains the JSON structure of the common event format.

8.7.6.2.4. Output Parameters

Header fields:

Parameter

Data Type

Required?

Brief description

Content-length

integer

No

Used only in error conditions

Content-type

string

No

Used only in error conditions

Date

datetime

No

Date time of the response in GMT

X-MinorVersion

integer

Yes

The minor version of the API service

X-PatchVersion

integer

Yes

The patch version of the API service

X-LatestVersion

string

Yes

The full version of the API service expressed as {major}. {minor}.{patch}

Body Fields (for success responses): no content is provided.

Body Fields (for error responses):

Parameter

Data Type

Required?

Brief description

requestError

requestError

Yes(for errors)

Used only in error conditions

8.7.6.2.5. HTTP Status Codes

Code

Reason Phrase

Description

202

Accepted

The request has been accepted for processing

400

Bad Request

Many possible reasons not specified by the other codes (e.g., missing required parameters or incorrect format) . The response body may include a further exception code and text. HTTP 400 errors may be mapped to SVC0001 (general service error), SVC0002 (bad parameter), SVC2000 (general service error with details) or PO9003 (message content size exceeds the allowable limit).

401

Unauthorized

Authentication failed or was not provided. HTTP 401 errors may be mapped to POL0001 (general policy error) or POL2000 (general policy error with details).

404

Not Found

The server has not found anything matching the Request-URI. No indication is given of whether the condition is temporary or permanent.

405

Method Not Allowed

A request was made of a resource using a request method not supported by that resource (e.g., using PUT on a REST resource that only supports POST).

500

Internal Server Error

The server encountered an internal error or timed out; please retry (general catch-all server-side error).HTTP 500 errors may be mapped to SVC1000 (no server resources).

8.7.6.2.6. Sample Request and Response

8.7.6.2.6.1. Sample Request
POST  /eventListener/v7 HTTP/1.1
Authorization: Basic QWxhZGRpbjpvcGVuIHNlc2FtZQ==
content-type: application/json
content-length: 12345
X-MinorVersion: 1

{
    "event": {
        "commonEventHeader": {
            "version": "4.1",
            "vesEventListenerVersion": "7.1.1",
            "domain": "fault",
            "eventName": "Fault_Vscf:Acs-Ericcson_PilotNumberPoolExhaustion",
            "eventId": "fault0000245",
            "sequence": 1,
            "priority": "High",
            "reportingEntityId": "cc305d54-75b4-431b-adb2-eb6b9e541234",
            "reportingEntityName": "ibcx0001vm002oam001",
            "sourceId": "de305d54-75b4-431b-adb2-eb6b9e546014",
            "sourceName": "scfx0001vm002cap001",
            "nfVendorName": "Ericsson",
            "nfNamingCode": "scfx",
            "nfcNamingCode": "ssc",
            "startEpochMicrosec": 1413378172000000,
            "lastEpochMicrosec": 1413378172000000,
            "timeZoneOffset": "UTC-05:30"
        },
        "faultFields": {
            "faultFieldsVersion": 4.0,
            "alarmCondition": "PilotNumberPoolExhaustion",
            "eventSourceType": "other",
            "specificProblem": "Calls cannot complete - pilot numbers are unavailable",
            "eventSeverity": "CRITICAL",
            "vfStatus": "Active",
            "alarmAdditionalInformation": {
                "PilotNumberPoolSize": "1000"
            }
        }
    }
}
8.7.6.2.6.2. Sample Success Response
HTTPS/1.1 202 Accepted
X-MinorVersion: 1
X-PatchVersion: 1
X-LatestVersion: 7.1.1
8.7.6.2.6.3. Sample Error Responses
8.7.6.2.6.3.1. Sample Policy Exception
HTTPS/1.1 400 Bad Request
content-type: application/json
content-length: 12345
Date: Thu, 04 Jun 2009 02:51:59 GMT
X-MinorVersion: 1
X-PatchVersion: 1
X-LatestVersion: 7.1.1

{
  "requestError": {
    "policyException": {
      "messageId": "POL9003",
      "text": "Message content size exceeds the allowable limit",
    }
  }
}
8.7.6.2.6.3.2. Sample Service Exception
HTTPS/1.1 400 Bad Request
content-type: application/json
content-length: 12345
Date: Thu, 04 Jun 2009 02:51:59 GMT
X-MinorVersion: 1
X-PatchVersion: 1
X-LatestVersion: 7.1.1

{
  "requestError": {
    "serviceException": {
      "messageId": "SVC2000",
      "text": "Missing Parameter: %1. Error code is %2"
      "variables": [
        "severity",
        "400"
      ]
    }
  }
}

8.7.6.3. Operation: publishEventBatch

8.7.6.3.1. Functional Behavior

Allows authorized clients to publish a batch of events to the VES event listener.

  • Supports only HTTPS access.

  • Uses the HTTP verb POST

  • Supports JSON content types

  • Provides HTTP response codes as well as Service and Policy error messages

8.7.6.3.2. Call Flow

publishEventBatch Call Flow

8.7.6.3.3. Input Parameters

Header Fields (note: all parameter names shall be treated as case-insensitive):

Parameter

Data Type

Required?

Brief description

Accept

string

No

Determines the format of the body of the response. Valid values are:

  • application/json

Authorization

string

No

The username and password are formed into one string as “username:password” . This string is then Base64 encoded to produce the encoded credential which is communicated in the header after the string “Authorization: Basic”. See examples below. If the Authorization header is missing, then an HTTP 400 Invalid Request message shall be returned. If the string supplied is invalid, then an HTTP 401 Unauthorized message shall be returned.

Content-length

integer

No

Note that content length is limited to 2 megabyte (see Message Size).

Content-type

string

Yes

Must be set to one of the following values:

  • application/json

X-MinorVersion

integer

No

The minor version of the API requested by the client

X-PatchVersion

integer

No

The patch version of the API requested by the client

X-LatestVersion

string

No

The full version of the API requested by the client expressed as {major}.{minor}.{patch}

Body Fields:

Parameter

Data Type

Required?

Brief description

eventList

eventList

Yes

Array of events conforming to the common event format.

8.7.6.3.4. Output Parameters

Header fields:

Parameter

Data Type

Required?

Brief description

Content-length

integer

No

Used only in error conditions

Content-type

string

No

Used only in error conditions

Date

datetime

No

Date time of the response in GMT

X-MinorVersion

integer

Yes

The minor version of the API service

X-PatchVersion

integer

Yes

The patch version of the API service

X-LatestVersion

string

Yes

The full version of the API service expressed as {major}.{minor}.{patch}

Body Fields (for success responses: no content is provided.

Body Fields (for error responses):

Parameter

Data Type

Required?

Brief description

requestError

requestError

Yes(for errors)

Used only in error conditions

8.7.6.3.5. HTTP Status Codes

Code

Reason Phrase

Description

202

Accepted

The request has been accepted for processing

400

Bad Request

Many possible reasons not specified by the other codes (e.g., missing required parameters or incorrect format) . The response body may include a further exception code and text. HTTP 400 errors may be mapped to SVC0001 (general service error), SVC0002 (bad parameter), SVC2000 (general service error with details) or PO9003 (message content size exceeds the allowable limit).

401

Unauthorized

Authentication failed or was not provided. HTTP 401 errors may be mapped to POL0001 (general policy error) or POL2000 (general policy error with details).

404

Not Found

The server has not found anything matching the Request-URI. No indication is given of whether the condition is temporary or permanent.

405

Method Not Allowed

A request was made of a resource using a request method not supported by that resource (e.g., using PUT on a REST resource that only supports POST).

500

Internal Server Error

The server encountered an internal error or timed out; please retry (general catch-all server-side error).HTTP 500 errors may be mapped to SVC1000 (no server resources).

8.7.6.3.6. Sample Request and Response

8.7.6.3.6.1. Sample Request
POST /eventListener/v7/eventBatch HTTP/1.1
Authorization: Basic QWxhZGRpbjpvcGVuIHNlc2FtZQ==
content-type: application/json
content-length: 12345
X-MinorVersion: 1

{
   "eventList": [
      {
         "commonEventHeader": {
            "version": "4.1",
            "vesEventListenerVersion": "7.1.1",
            "domain": "fault",
            "eventName": "Fault_Vscf:Acs-Ericcson_PilotNumberPoolExhaustion",
            "eventId": "fault0000250",
            "sequence": 1,
            "priority": "High",
            "reportingEntityId": "cc305d54-75b4-431b-adb2-eb6b9e541234",
            "reportingEntityName": "ibcx0001vm002oam0011234",
            "sourceId": "de305d54-75b4-431b-adb2-eb6b9e546014",
            "sourceName": "scfx0001vm002cap001",
            "nfVendorName": "Ericsson",
            "nfNamingCode": "scfx",
            "nfcNamingCode": "ssc",
            "startEpochMicrosec": 1413378172000000,
            "lastEpochMicrosec": 1413378172000000,
            "timeZoneOffset": "UTC-05:30"
         },
         "faultFields": {
            "faultFieldsVersion": 4.0,
            "alarmCondition": "PilotNumberPoolExhaustion",
            "eventSourceType": "other",
            "specificProblem": "Calls cannot complete - pilot numbers are unavailable",
            "eventSeverity": "CRITICAL",
            "vfStatus": "Active",
            "alarmAdditionalInformation": {
                "PilotNumberPoolSize": "1000"
            }
         }
      },
      {
         "commonEventHeader": {
            "version": "4.1",
            "vesEventListenerVersion": "7.1.1",
            "domain": "fault",
            "eventName": " Fault_Vscf:Acs-Ericcson_RecordingServerUnreachable",
            "eventId": "fault0000251",
            "sequence": 0,
            "priority": "High",
            "reportingEntityId": "cc305d54-75b4-431b-adb2-eb6b9e541234",
            "reportingEntityName": "ibcx0001vm002oam0011234",
            "sourceId": "de305d54-75b4-431b-adb2-eb6b9e546014",
            "sourceName": "scfx0001vm002cap001",
            "nfVendorName": "Ericsson",
            "nfNamingCode": "scfx",
            "nfcNamingCode": "ssc",
            "startEpochMicrosec": 1413378172000010,
            "lastEpochMicrosec": 1413378172000010,
            "timeZoneOffset": "UTC-05:30"
         },
         "faultFields": {
            "faultFieldsVersion": 4.0,
            "alarmCondition": "RecordingServerUnreachable",
            "eventSourceType": "other",
            "specificProblem": "Recording server unreachable",
            "eventSeverity": "CRITICAL",
            "vfStatus": "Active"
         }
      }
   ]
}
8.7.6.3.6.2. Sample Success Response
HTTPS/1.1 202 Accepted
X-MinorVersion: 1
X-PatchVersion: 1
X-LatestVersion: 7.1.1
8.7.6.3.6.3. Sample Error Responses
8.7.6.3.6.3.1. Sample Policy Exception
HTTPS/1.1 400 Bad Request
content-type: application/json
content-length: 12345
Date: Thu, 04 Jun 2009 02:51:59 GMT
X-MinorVersion: 1
X-PatchVersion: 1
X-LatestVersion: 7.1.1

{
  "requestError": {
    "policyException": {
      "messageId": "POL9003",
      "text": "Message content size exceeds the allowable limit",
    }
  }
}
8.7.6.3.6.3.2. Sample Service Exception
HTTPS/1.1 400 Bad Request
content-type: application/json
content-length: 12345
Date: Thu, 04 Jun 2009 02:51:59 GMT
X-MinorVersion: 1
X-PatchVersion: 1
X-LatestVersion: 7.1.1

{
  "requestError": {
    "serviceException": {
      "messageId": "SVC2000",
      "text": "Missing Parameter: %1. Error code is %2"
      "variables": [
        "severity",
        "400"
      ]
    }
  }
}

8.7.7. Terminology

Terminology used in this document is summarized below:

A&AI. Active & Available Inventory is the ONAP component that provides data views of Customer Subscriptions, Products, Services, Resources, and their relationships.

Alarm Condition. Short name of the alarm condition/problem, such as a trap name.

APPC (formerly APP-C). Application Controller. Handles the life cycle management of Virtual Network Functions (VNFs).

ASDC. AT&T Service Design and Creation Platform: the original name for the SDC. Replaced by SDC.

Common Event Format. A JSON schema describing events sent to the VES Event Listener.

Common Event Header. A component of the Common Event Format JSON structure. This datatype consists of fields common to all events.

DCAE. Data Collection Analysis and Events. DCAE is the ONAP subsystem that supports closed loop control and higher-level correlation for business and operations activities. DCAE collects performance, usage, and configuration data, provides computation of analytics, aids in trouble-shooting and management, and publishes event, data, and analytics to the rest of the ONAP system for FCAPS functionality.

DMaaP. Data Movement as a Platform. A set of common services provided by ONAP, including a Message Router, Data Router, and a Data Bus Controller.

Domain. In VES, an event ‘domain’ identifies a broad category of events (e.g., ‘fault’ or ‘measurement’), each of which is associated with a VES domain field block, which is sent with the commonEventHeader when events of that category are generated.

Epoch. The number of seconds that have elapsed since 00:00:00 Coordinated Universal Time (UTC), Thursday, 1 January 1970. Every day is treated as if it contains exactly 86400 seconds, so leap seconds are not applied to seconds since the Epoch. In VES Epoch times are measured in microseconds.

Event. A well-structured packet of network management information identified by an eventName which is asynchronously communicated to one or more instances of an Event Listener service to subscribers interested in that eventName. Events can convey measurements, faults, syslogs, threshold crossing alerts, and others types of information.

Event Id. Event key that is unique to the event source. The key must be unique within notification life cycle similar to EventID from 3GPP. It could be a sequential number, or a composite key formed from the event fields, such as sourceName_alarmCondition_startEpoch. The eventId should not include whitespace. For fault events, eventId is the eventId of the initial alarm; if the same alarm is raised again for changed, acknowledged or cleared cases, eventId must be the same as the initial alarm (along with the same startEpochMicrosec and an incremental sequence number.

Event Name. Identifier for specific types of events. Specific eventNames registered by the YAML may require that certain fields, which are optional in the Common Event Format, be present when events with that eventName are published.

Event Streaming. The delivery of network management event information in real time.

Extensible Data Structures. Data structures (e.g., hashMap) that allow event sources to send information not specifically identified in the VES schema.

Hash Map. A hash table, or data structure, used to implement an associative array, a structure than can map keys to values. In VES 6.0, all name-value pair structures were changed to hash maps (i.e., {‘name’: ‘keyName’, ‘value’: ‘keyValue’} was replaced with {‘keyName’: ‘keyValue’}).

ICE. Incubation and Certification Environment. Facilitates vendors and third-party in developing virtual network functions using ONAP and a network cloud.

IPMI. The Intelligent Platform Management Interface.

JSON. Java Script Object Notation. JSON is an open-standard file format that uses human-readable text to transmit data objects consisting of attribute–value pairs and array data types (or any other serializable value). It is a very common data format used for asynchronous browser–server communication.

NF. Network Function. Generalized name for a VNF or PNF.

NFC. Network Function Component. Generalized name for a VNFC or a component of a PNF.

ONAP. Open Network Automation Platform.

PNF. Physical Network Function.

Policy. Course of action for the management of the network. The ONAP Policy Framework is a comprehensive policy design, deployment, and execution environment. The Policy Framework is the *decision making* component in an ONAP system. It allows you to specify, deploy, and execute the governance of the features and functions in your ONAP system, be they closed loop, orchestration, or more traditional open loop use case implementations. The Policy Framework is the component that is the source of truth for all policy decisions.

Reporting Entity Name. Name of the entity reporting the event or detecting a problem in another vnf/vm or pnf which is experiencing the problem. May be the same as the sourceName. Not used for performance measurements currently.

SDC. Service Design and Creation Platform: The ONAP visual modeling and design tool. It creates internal metadata that describes assets used by all ONAP components, both at design time and run time. The SDC manages the content of a catalog, and assemblies of selected catalog to define how and when VNFs are realized in a target environment.

Source Name: Name of the entity experiencing the event issue, which may be detected and reported by a separate reporting entity. The sourceName identifies the device for which data is collected. A valid sourceName must be inventoried in A&AI.

Specific Problem. Description of the alarm or problem.

VES. Virtual Function Event Stream. In 6.0, the definition of VES was expanded to include event streaming for VNF, PNF and infrastructure. The VES Event Listener can receive any event sent in the VES Common Event Format.

VES Event Listener. A RESTful connectionless push event listener capable of receiving single events or batches of events sent in the Common Event Format.

VM. Virtual Machine.

VNF. Virtual Network Function. A VNF is a virtualized task formerly carried out by proprietary, dedicated network hardware. (Examples: virtual firewall, virtual DNS). A VNF can also be defined as a specific kind of Vendor Software Product.

YAML. A data serialization language and superset of JSON.

VNFC. Virtual Network Function Component. A VNFC is a part of a VNF. It is a stand-alone executable that is loosely-coupled, granular, re-usable, and responsible for a single capability.

8.7.8. Appendix: Historical Change Log

For the latest changes, see the Change Block just before the Table of Contents.

Date

Revision

Description

5/22/2015

0.1

Initial Release - Draft

5/29/2015

0.2

  • Introduction: removed all system names and references to internal AT&T components

  • Security: changed ‘event publisher’ to ‘event source’

  • Generic Event Format: updated the JSON schema per the below:

  • eventHeader: clarified the description of id, made sourceId a required field, changed the datatype of timestamps to timestamp [ ]

  • performanceFields: removed overflowFields

  • tmestamp: added a description of this datatype

  • Exceptions: fixed indentation of sections

  • Approvers: updated the list of approvers and added attuids

6/3/2015

0.3

  • Updated the security section to use HTTP Basic Authentication per AT&T REST standards. Updated the input parameters and messaging examples to use the new security scheme.

6/5/2015

0.4

  • Added otherFields sub section to the defined datatypes

  • Added locale field to the eventHeader.

6/5/2015

0.5

  • Updated the embedded event format json schema to match the changes made in v0.4

6/10/2015

0.6

  • Updated the {ServerRoot} format to contain an optional routing path (for D2 service modules).

7/7/2015

0.7

Common Event Format updates:

  • EventHeader: added ‘measurement’ to the ‘domain’ enumeration; changed ‘locale’ to ‘location’ and clarified in the description that this should be a clli code

  • Added a MeasurementFields datatype, which required the addition of the following datatypes: codecsInUse, cpuUsage, diskUsage, featuresInUse, memoryUsage

7/15/2015

1.0

  • Changed sourceInstance in the eventHeader to be an array of name value pairs

  • Changed the performanceFields block to thresholdCrossingAlertFields. Updated the domain field of the eventHeader to match.

7/23/2015

v1.1

Changes to eventHeader data format:

  • moved sourceInstance to internalHeaderFields

  • moved serviceInstanceId to internalHeaderFields

  • moved productId to internalHeaderFields

  • moved subscriberId to internalHeaderFields

  • moved location to internalHeaderFields

  • added the following new fields in internalHeaderFields: policyType, policyName, correlationEventType, correlationType, correlationName, correlationRootEventId

Changes to faultFields data format:

  • moved the eventSourceDeviceDescription to internalFaultFields and renamed it equipmentVendorModel

  • moved eventSourceHostname to internalFaultFields

  • changed alarmObjectInterface to alarmInterfaceA

  • changed alarmRemoteObject to alarmRemoteObjectZ and

    moved it to internalFaultFields

  • changed alarmRemoteObjectInterface to alarmInterfaceZ and moved it to internalFaultFields

Changes to thresholdCrossingFields data format:

  • changed several references from the old ‘performanceFields’ block to the new ‘thresholdCrossingFields’ block

Other:

  • Fixed several comma and colon syntax errors in the JSON schema as detected by a JSON schema syntax checker.

8/11/2015

v1.2

Timestamp format:

  • Section 4.18: added a note in the datetime field of the Timestamp datatype specifying the (GMT) format required

  • Updated the JSON schema with the same information

Event Header Severity Enumeration:

  • Section 4.8: modified the severity enumeration to remove the numbers in parentheses that followed the names. The names were not changed.

  • Updated the JSON schema with the same information.

8/20/2015

v1.3

JSON Schema rev’d to v9:

  • Alphabetized all fields in the JSON schema

  • Fixed the way arrays were specified (JSON schema syntax issue)

Sample Responses:

  • 2.1.1.1: alphabetized fields, fixed timestamps array depiction, fixed severity enum value to conform to latest format

  • 6.2.6.1: alphabetized fields, fixed timestamps array depiction, fixed severity enum value to conform to latest format

  • 6.3.6.1: alphabetized fields, fixed timestamps array depiction, fixed severity enum value to conform to latest format

  • 6.4.6.1: alphabetized fields, fixed timestamps array depiction, fixed eventList array depection, fixed severity enum value to conform to latest format

9/16/2015

v1.4

JSON Schema rev’d to v10:

  • Fixed an error in the way that the top level “event” object was specified in the v9 json schema. This was discovered when validating examples against the schema using this site: http://json-schema-validator.herokuapp.com/index.jsp

  • Changed the embedded json file in section 4

Sample Responses:

  • Removed an extra comma after the timestamp brace in section 6.2.6 and 6.3.6.

11/11/2015

v1.5

Section 4 was the only section changed: JSON Schema rev’d to v11 and Datatype tables were updated to match . Numerous data structure changes were made based on VNF vendor proof of concept feedback. Modified sample requests and responses to match.

11/12/2015

v1.6

  • The internalFaultFields were merged into the internalHeaderFields; then the internalFaultFields datatype was deleted.

  • Updated the JSON schema to v12.

  • Also corrected some background color issues in the sample requests and responses.

1/18/2016

v1.7

  • Section 2 changes: updated the sample request to conform with the changes below

  • Section 4 datatype changes:

  • Changed ‘eventHeader’ to ‘commonEventHeader’

  • Moved ‘eventSeverity’ from the ‘commonEventHeader’ to ‘faultFields’

  • Added ‘priority’ to ‘commonEventHeader’

  • moved ‘vFstatus’ to ‘faultFields’

  • removed ‘firstDateTime’ and ‘lastDateTime’ and changed ‘firstEpoch’ to ‘startEpochMicrosec’ and changed ‘lastEpoch’ to ‘lastEpochMicrosec’.

  • Added ‘functionalRole’ to the commonEventHeader

  • In the commonEventHeader, changed the ‘eventDomain’ enumeration to remove ‘measurements’ and add ‘measurementsForVfScaling’.

  • Changed the ‘measurementFields’ to ‘measurementsForVfScalingFields’

  • In the commonEventHeader, changed the following fields:

  • ‘eventDomain’ to ‘domain’

  • ‘eventSequence’ to ‘sequence’

  • ‘eventSourceId’ to ‘sourceId’

  • ‘eventSounceName’ to ‘sourceName’

  • Updated the JSON schema to v13

  • Section 6 changes: updated the input parameters and sample requests to conform to the changes above.

  • Section 7: changed the section from Approvers to Contributors.

1/22/2016

v1.8

  • Section 4: Added support for ‘mobileFlow’ in the commonEventHeader ‘domain’ enumeration. Added the mobileFlowFields datatype and the gtpPerFlowMetrics datatype referenced by that datatype.

  • Section 7: alphabetized the contributors

2/11/2016

v1.9

  • Added section 1.3: Naming Standard for Event Types

2/12/2016

v2.0

  • Updated request – response examples to reflect the naming standards for event types introduced in v1.9

  • Added a paragraph on use of Avro as a transport in section 1.4

3/11/2016

v2.1

  • Updated the embedded JSON schema to v15 to fix a typo in the required fields for the measurementsForVfScalingFields, namely, changed ‘configuredEntites’ to ‘configuredEntities’. Additionally, added an ‘Event Listener’ title block at the bottom of the file with a single required event object.

3/15/2016

v2.2

  • Added mobileFlowFields to the event datatype definition in section 4.7 and updated the embedded json schema at the top of section 4 to v16.

4/26/2016

v2.3

  • Generic Event Format updates: 1) made ‘priority’ lowercase in the Word doc table for commonEventHeader; 2) added ‘requestError’ data structure to the Word doc and JSON schema (which is now at v17)

4/27/2016

v2.4

  • JSON Schema: In the ‘event’ data structure, changed ‘thresholdCrossingFields’ to ‘thresholdCrossingAlertFields’ to product v18 of the schema.

  • ‘codecsInUse’ data structure: changed ‘numberInUse’

    to ‘codecUtilization’

5/26/2016

v2.5

  • Changed responses from ‘204 No Content’ to ‘202 Accepted’ and added a body to the response that enable AT&T to throttle the events being sent and/or to request the current state of throttling at the event source.

  • Added new datatypes to support the above: eventDomainThrottleSpecification, eventDomainThrottleSpecificationList, eventThrottlingState, suppressedNvPairs

  • Modifed the commonEventFormat json schema to v19

  • Note: for the VendorEventListener: added new licensing language on the back of the title page; added an “attCopyrightNotice” definition at the top of the commonEventFormat_Vendors.json file; also removed all references to internalHeaderFields from this file and from the VendorEventListener spec.

8/9/2016

v2.6

  • commonHeader: added a note on the description of sourceId and sourceName in the commonHeader: “use reportingEntity for domains that provide more detailed source info”

  • commonHeader: deleted the capacity, measurementsForVfScaling and usage domains in the domain enumeration

  • commonHeader: added the following domains to the domain enumeration: licensingKci, scalingKpi, stateChange

  • event: removed references to capacityFields, measurementsForVfScalingFields and usageFields and added references to licensingKciFields, scalingKpiFields, stateChangeFields

  • licensingKciFields: added this section along with ‘additionalMeasurements’, which is an optional list of measurementGroup structures. Changed the name of kciFieldsVersion to licensingKciFieldsVersion.

  • scalingKpiFields: added this section but changed measurementFieldsVersion to scalingKpiFieldsVersion

  • stateChangeFields: added this section along with ‘additionalFields’, which is an optional list of name-value pairs. Other fields included newState and oldState which were enumerations of the following possible states: ‘inService’, ‘maintenance’, ‘outOfService’

  • sysLogFields: added ‘additionalFields’, which is an optional list of name-value pairs

  • vNicUsage: added two required fields to the vNicUsage data structure: packetsIn and packetsOut

8/10/2016

v2.7

  • commonHeader: removed the note on the description of sourceId and sourceName in the commonHeader: “use reportingEntity for domains that provide more detailed source info”

  • commonHeader: added measurementsForVfScaling domain back and removed the licensingKci and scalingKpi domains

  • event: removed references to licensingKciFields and scalingKpiFields; added references to measurementsForVfScalingFields

  • measurementsForVfScalingFields: combined the kciDetail and kpiDetail structures into the measurementsForVfScalingFields structure; referenced the errors structure

  • errors: added a new structure to capture the receive and transmit errors for the measurements domain

  • removed the following structures: kci, kpi, scalingKpiFields and licensingKciFields

  • eventDomainThrottleSpecification: updated the reference to commonEventHeader domain field

  • faultFields: removed the numbers from the enumerated strings for eventSourceType

  • vNicUsage: made the broadcast, multicast and unicast fields optional

  • contributors: updated Alok’s organizational area

8/12/2016

v2.8

  • commonHeader: copied the descriptions of sourceId and sourceName from the JSON schema into the word document tables.

  • sample request examples: moved the reportingEntityId and reportingEntityNames to the same relative place in all sample requests in the document

  • Fixed the sample request shown for publishEventBatch to take an eventList as input.

  • Fixed the sample request shown for publishSpecificTopic to put the topic in the URL

  • errors: changed the receiveErrors and transmitErrors fields to be datatype number

  • codesInUse: changed ‘codecUtilization’ to ‘numberinUse’

  • vNicUsage: updated the description of the fields

8/27/2016

v2.9

  • Added a note “(currently: 1.1)” in the descriptions of the following fields: commonEventHeader:version, faultFields:faultFieldsVersion, measurementsForVfScalingFields:measurementsForVfScalingFieldsVersion, stateChangeFields:stateChangeFieldsVersion, sysLogFields:syslogFieldsVersion, thresholdCrossingAlertFields:thresholdCrossingFieldsVersion

  • stateChangeFields: made stateInterface mandatory

  • changed ‘enum’ to ‘enumeration’ throughout section 4 of the document (note: this can’t be done in the JSON schema).

  • measurementsForVfScalingFields: made the following fields optional: conurrentSessions, configuredEntitites, cpuUsageArray, fileSystemUsageArray, memoryConfigured, memoryUsed, requestRate, vNicUsageArray

  • measurementsForVfScalingFields: concurrentSessions and configuredEntities: changed the description to support both VMs and VNFs

  • measurementsFor VfScalingFields: clarified the descriptions of latencyDistribution, measurementInverval and requestRate

  • syslogFields: clarified the descriptions of syslogSData, syslogTag, syslogVer

  • thresholdCrossingAlertFields: made the following fields optional and clarified their descriptions: elementType, networkService

  • command and commandList: created a list of command structures to enable the event collector to request changes of event sources. Commands consist of a commandType along with optional fields (whose presence is indicated by the commandType). Three command types are currently supported: ‘measurementIntevalChange’, ‘provideThrottlingState’ and ‘throttlingSpecification’.

  • eventDomainThrottleSpecificationList: removed this and replaced it with commandList.

  • Operations and Sample Requests: modified the operations and samples to support the new command and commandList structures.

9/1/2016

v2.10

  • measurementsForVfScaling block: made the following fields optional: latencyDistribution (which is an array of latencyBucketMeasure structures) and meanRequestLatency. Updated the JSON schemas (now v24) to match.

9/16/2016

v2.11

  • 1 Introduction: updated the introduction to clarify the usage of eventTypes and the possibility of support for other protocols.

  • 6.1 REST Operation Overview: added two new subsections (6.1.2 and 6.1.3) discussing Api Version and Commands Toward Event Source Clients.

  • 6.2 publishAnyEvent: fixed the sample to conform to the latest changes

  • 6.3 publishSpecificTopic: fixed the sample to conform to the latest changes

  • 6.4 publishEventBatch: fixed the sample to conform to the latest changes

  • 6.5 provideThrottlingState operation: added the Input Parameters section heading back and fixed the sample request to provide eventThrottlingState (instead of eventThrottlingClientState).

  • The remaining bullets describe changes made to section 4 datatypes in alphabetical order:

  • command datatype: referenced the new section 6.1.3 which provides an explanation of command state expectations and requirements for a given eventSource:

  • commonEventHeader datatype:

    • made sourceId and reportingEntityId fields optional (although the internal Generic Event Listener spec indicates, in the field descriptions, that the AT&T enrichment process shall ensure that these fields are populated)

    • domain enumeration: changed measurementsForVfScalingFields to measurementsForVfScaling

  • eventDomainThrottleSpecificationList: added this array of eventDomainThrottleSpecification stuctures back to the schema because it is used by the provideThrottlingState operation.

  • eventList: added eventList back to the vendor version of the commonEventFormat. This is used by the publishEventBatch operation.

  • faultFields datatype:

    • eventSourceType: made this a string (and provided the previous enumerated values as examples)

  • filesystemUsage datatype:

    • changed vmIdentifier to filesystemName

  • gtpPerFlowMetrics datatype:

    • flowActivationTime: changed the format and description to be compliant with RFC 2822.

    • flowDeactivationTime: changed the format and description to be compliant with RFC 2822.

  • internalHeaderFields datatype:

    • Added the following optional fields: firstDateTime, lastDateTime compliant with RFC 2822. Noted in the description that these fields must be supplied for events in the following domains: fault, thresholdCrossingAlerts and measurementsForVfScaling.

    • ticketingTimestamp: changed the format and description to be compliant with RFC 2822.

  • syslogFields datatype:

    • eventSourceType: made this a string (and provided the previous enumerated values, without the numbers, as examples)

  • thresholdCrossingAlerts dataypte:

    • collectionTimestamp: changed the format and description to be compliant with RFC 2822.

    • eventStartTimestamp: changed the format and description to be compliant with RFC 2822.

    • added the same eventSeverity field as from the faultFields and made it required

9/23/2016

v2.12

  • Section 4 Datatypes: commonEventHeader: made reportingEntityName a required field (note: the JSON schema already had this field as required)

11/29/2016

v3.0

  • Introduction:

    • Introductory paragraph: changed ‘…Common Event Header Block followed by zero or more event domain blocks’ to ‘…Common Event Header Block accompanied by zero or more event domain blocks’ since the order of the blocks on the wire is not guaranteed.

    • Added Section 1.5 Versioning

  • Section 4: codec processing:

    • CommonEventFormat_Vendors schema only: codesInUse: changed required field from “codecUtilization” which was removed previously to “numberInUse” which is the new field name.

    • added ‘codecSelected’ datatype

    • added ‘codecSelectedTranscoding’ datatype

  • Section 4 and section 6: command processing:

    • Added commandListEntry which is an object that references the command object.

    • commandList: changed commandList to contain an array of commandListEntry objects.

    • Updated sample responses in section 6 where commands are used

  • Section 4: commonEventHeader:

    • Incremented version to 1.2

    • added two new values to the ‘domain’ enumeration: ‘serviceEvents’ and ‘signaling

  • Section 4: added endOfCallVqmSummaries datatype

  • Section 4: ‘event’: added two fields: ‘serviceEventsFields’ and ‘signalingFields’

  • Section 4: added ‘eventInstanceIdentifier’datatype

  • Section 4: CommonEventListener only: internalHeaderFields:

    • added ‘internalHeaderFieldsVersion’(initially set to 1.1)

    • added ‘correlationFirstEpoch’

    • added ‘closedLoopControlName’

    • added ‘closedLoopFlag’

    • added ‘collectorTimeStamp’

    • added ‘eventTag’

    • added ‘tenantName’

    • changed ‘operationalStatus’ to ‘inMaint’

    • added required fields in the schema to match the word doc: ‘equipmentNameCode’, ‘equipmentType’, ‘equipmentVendor’, ‘inMaint’, ‘provStatus’

  • Section 4: added ‘marker’datatype

  • Section 4: added ‘midCallRtcp’ datatype

  • Section 4: mobileFlowFields:

    • added ‘mobileFlowFieldsVersion’(initially set to 1.1)

  • Section 4: added ‘serviceEventsFields’datatype

  • Section 4: added ‘signalingFields’ datatype

  • Section 4: syslogFields:

    • Incremented syslogFieldsVersion to 1.2

    • added ‘syslogPri’

    • added ‘syslogSev’

    • added ‘syslogSdId’

  • Section 4: thresholdCrossingAlertFields:

    • Incremented thresholdCrossingFieldsVersion to 1.2

    • added ‘additionalFields’ which is an optional list of name value pairs.

  • Section 4: schema v26.0 embedded reflecting the above changes.

  • Section 6 and Section 2: changed all sample requests to use /v3 in the REST Resource URL.

12/1/2016

v3.1

  • Section 6: Updated the call flow diagrams to show ‘v3’

1/5/2017

v4.0

  • Combined the Generic Event Listener and Vendor Event Listener into a single API service specification with version 4.0.

  • Changed the title to VES (Virtual Function Event Streaming) Listener.

  • Changed references to ‘generic event’ to ‘common event’ or ‘VES event’ (depending on the context) throughout the document.

  • Used the Legal Disclaimer from the Vendor Event Listener on the back of the title page.

  • Section 1: Introduction changes:

    • modified wording to reference ‘VES’

    • removed the ‘Audience’ section, which described various AT&T groups the documented was intended for

    • tweaked the naming standards for event types to clarify the purpose of the naming conventions

  • Section 3: Resource Structure: added a sentence describing the FQDN and port used in the resource URL.

  • Section 4: Common Event Format changes:

    • renamed the section to ‘Common Event Format’ from ‘Generic Event Format’

    • reorganized the datatypes into separate sections ; sections were defined for each of the domains as well as for common event, common event header and command list processing

    • codecSelected datatype: removed this datatype

    • codecSelectedTranscoding datatype: removed this datatype

    • command datatype: added an enumerated value to commandType: ‘heartbeatIntervalChange’

    • commonEventHeader: added internalHeaderFields to the commonEventHeader, defined as “Fields (not supplied by event sources) that the VES Event Listener service can use to enrich the event if needed for efficient internal processing. This is an empty object which is intended to be defined separately by each provider implementing the VES Event Listener.”

    • commonEventHeader: removed two enumerated values , ‘serviceEvents’ and ‘signaling’ from the domain enumeration

    • commonEventHeader version: incremented the version to 2.0

    • endOfCallVqmSummaries datatype: removed this datatype

    • event: changed the description of the event datatype to: “fields which constitute the ‘root level’ of the common event format”

    • event: removed ‘serviceEventFields’ and ‘signalingFields’ from the definition

    • event: fixed a misspelling of ‘thresholdCrossingAlertFields’, which was only present in the Word document

    • eventInstanceIdentifier datatype: removed this datatype

    • internalHeaderFIelds datatype: defined this as follows: “The internalHeaderFields datatype is an undefined object which can contain arbitrarily complex JSON structures. It is intended to be defined separately by each provider implementing the VES Event Listener. The fields in internalHeaderFields are not provided by any event source but instead are added by the VES Event Listener service itself as part of an event enrichment process necessary for efficient internal processing of events received by the VES Event Listener”

    • marker datatype: removed this datatype

    • measurementsForVfScalingFields datatype: clarified that memoryConfigured and memoryUsed are measured in MB

    • midCallRtcp datatype: removed this datatype

    • mobileFlowFields datatype: added ‘additionalFields’

    • mobileFlowFields datatype: incremented the version number for this field block to 1.2

    • serviceEventsFields datatype: removed this datatype

    • signalingFields datatype: removed this datatype

    • syslogFields: added three fields to the schema that were previously described in the document but not incorporated into the schema: syslogPri, syslogSev, syslogSdId

    • syslogFields version: incremented the version to 2.0

  • Modified the Common Event Format JSON schema to v27.0 to incorporate the above changes. Also, added the AT&T Copyright Notice from the top of the retired CommonEventFormat_Vendors schema.

  • Section 6 and 2: changed all sample requests to use /v4 in the REST Resource URL and call flow diagrams

  • Section 6.1.3: added a row to the table in this section describing the ‘heartbeatIntervalChange’ command.

  • Section 6.1.4: added this new section describing expectations for buffering of events should all REST resource URL FQDNs be unreachable.

  • Section 6 Sample Requests: modified all sample requests showing the return of a commandList toward the event source to incorporate a heartbeatIntervalChange command; also corrected the spelling in the samples for the measurementIntervalChange command.

  • Section 7: Contributors: removed this section

3/21/2017

v4.1

  • JSON Schema changes to produce v27.2 (note: an earlier draft version of v27.1 had been distributed to a few individuals):

    • To support use of the schema with event batches, removed the following statement near the end of the schema file:

    “required”: [ “event” ]

  • Fixed the characters used in some of the quotes

  • Fixed some typos in the descriptions.

  • Removed the booleans, which were non-essential and which were causing problems across different implementations.

  • Section 4.5.7 measurementsForVfScalingFields:

    • Fixed the spelling of measurementsForVfScalingFields in the Word document

  • Section 2 and 6 sample requests and responses:

    • Removed quotes from numbers: sequence, and first/lastEpochMicrosec.

    • Fixed all quote characters, some of which were using unusual symbols that wouldn’t validate with the json-schema Python package.

  • Section 6.2.6.1, 6.3.6.1, 6.4.6.1 sample requests:

    • Added an alarmAdditionalInformation field array to the sample requests.

    • Added missing commas.

  • Section 6.5.6.1 provideThrottlingState sample requests:

    • Fixed the eventDomainThrottleSpecificationList to pass an array of anonymous eventDomainThrottleSpecification objects.

    • Added missing quotes.

  • Fixed the suppressedNvPairsList to pass an array of anonymous suppressedNvPairs objects.

4/14/2017

v5.0

  • Section 1 Introduction:

    • Clarified the Introduction (Section 1).

    • Changed Section 1.1 title from ‘Terminology’ to ‘Event Registration’ and referenced the YAML event registration format, defined in a separate document.

    • Clarified naming standards for eventName.

  • Section 3: updated the REST resource structure

  • Section 4.1 command list processing datatypes:

    • Got rid of commandListEntry and returned commandList to a simple array of commands.

    • Added heartbeatInterval to the command datatype.

    • Changed the datatype of measurementInterval from number to integer.

  • Section 4.2 common event datatypes:

    • event dataType: Added heartbeatFields, sipSignalingFields and voiceQualityFields to the event datatype as optional field blocks

    • Added jsonObject which provides a json object schema, name and other meta-information along with one or more object instances.

    • Added jsonObjectInstance which provides meta-information about an instance of a jsonObject along with the actual object instance

    • Added the ‘key’ datatype

    • Added the namedArrayOfFields datatype

    • Added vendorVnfNameFields

  • Section 4.3 common event header fields:

    • Add two new enumerations to domain: ‘sipSignaling’ and ‘voiceQuality’

    • Renamed eventType to eventName. Note that the original usage of eventType was formally described in the Introduction back on 2/11/2016 with v1.9.

    • Made eventName a required field

    • Created a new field called eventType with a meaning that is different than the old eventType

    • Removed functionalRole, which was replaced by the following two fields.

    • Added nfNamingCode

    • Added nfcNamingCode

    • Changed version to 3.0 (major version change) and made it a required field

  • Section 4.4: faultFields:

    • added one optional field: eventCategory

    • made faultFieldsVersion a required field

    • changed faultFieldsVersion to 2.0 (major version change)

    • fixed a typo on the spelling of alarmInterfaceA

    • clarified field descriptions

  • Section 4.5: added heartbeatFields datatype which can be used to communicate heartbeatInterval. Note: this change was previously made in v4.2

  • Section 4.6 measurements for vf scaling datatypes: changed the following datatypes from number to integer:

    • In measurementsForVfScalingFields: concurrentSessions, configuredEntities, numberOfMediaPortsInUse, vnfcScalingMetric

    • In codecsInUse: numberInUse

    • In featuresInUse: featureUtilization

  • Section 4.6.2 modified cpuUsage

  • Section 4.6.3 added diskUsage

  • Section 4.6.7 measurementsForVfScalingFields:

    • fixed the spelling of the measurementsForVfScalingFields in the Word document

    • added additionalFields, which is an array of fields (i.e., name-value pairs)

    • changed additionalMeasurements to reference the common datatype namedArrayOfFields (instead of referencing measurementGroup)

    • added additionalObjects which is an array of jsonObjects described by name, keys and schema

    • deleted aggregateCpuUsage

    • added diskUsageArray

    • deleted measurementGroup (which was replaced by the common datatype: namedArrayOfFields

    • added memoryUsageArray

    • deleted memoryConfigured and memoryUsed

    • deleted errors and vNicUsageArray

    • added vNicPerformanceArray

    • changed the measurementsForVfScalingVersion to 2.0 (major version change) and made it a required field. Also changed the name of this version field in the Word document to match that in the JSON schema.

  • Section 4.6.8 added memoryUsage

  • Section 4.6.9 vNicPerformance: replaced vNicUsage and errors with vNicPerformance

  • Section 4.7 mobile flow fields changes:

    • Made mobileFlowFieldsVersion a required field and changed the mobileFlowFieldsVersion to 2.0 (major version change).

    • Changed the datatype of flowActivationTime and flowDeactivationTime in the Word doc to string.

    • changed the following datatypes from number to integer: otherEndpointPort, reportingEndpointPort, samplingAlgorithm

  • Section 4.8: otherFields:

    • Added otherFieldsVersion (set at 1.1)

    • Added hashOfNameValuePairArrays

    • Added jsonObjects

    • Added nameValuePairs

  • Section 4.9: added sipSignaling domain datatypes with 4.8.1 sipSignalingFields. sipSignalingFieldsVersion is set at 1.0

  • Section 4.10 stateChangeFields: made stateChangeFieldsVersion a required field and set it to 2.0 (major version change).

  • Section 4.11 syslogFields:

    • Changed the following datatypes from number to integer: syslogFacility, syslogPri

    • Changed additionalFields from a field [ ] to a string which takes name=value pairs delimited by a pipe symbol.

    • Changed syslogFieldsVersion to 3.0 (major version change) and made it a required field

    • Made syslogSev an enumerated string (previously just a string)

  • Section 4.12 thresholdCrossingAlertFields: made thresholdCrossingFieldsVersion a required field and set it to 2.0 (major version change).

  • Section 4.132: added voice quality domain datatypes with 4.13.1 endOfCallVqmSummaries and 4.13.2 voiceQualityFields. voiceQualityFieldsVersion is set at 1.0

  • JSON Schema: changed the schema to v28.0 and incorporated all of the changes above.

  • Additional JSON Schema changes that are part of v28: Note: The following changes are provided relative to API Spec v4.0 (which embedded JSON schema v27.0), but they were also made in an interim release v4.1 (which embedded JSON schema v27.2):

    • To support use of the schema with event batches, removed the following statement near the end of the schema file:

    “required”: [ “event” ]

  • Fixed the characters used in some of the quotes

  • Fixed some typos in the descriptions.

  • Removed the booleans, which were non-essential and which were causing problems across different implementations.

  • Section 2 and 6 sample requests and responses (also incorporated in interim release 4.1):

    • Removed quotes from numbers: sequence, and first/lastEpochMicrosec.

    • Fixed all quote characters, some of which were using unusual symbols that wouldn’t validate with the json-schema Python package.

  • Section 2 and 6 sample requests and responses (only in v5.0):

    • Changed the version numbers in the URL string.

    • Added nfNamingCode and nfcNamingCode and removed functionalRole

  • Section 6 call flows: updated the version number (only in v5.0).

  • Section 6: removed the publishSpecificTopic operation

  • Section 6.1.4: Buffering: clarified event source expectations for buffering (only in v5.0).

  • Section 6.2.6.1, 6.3.6.1 sample requests (also incorporated in interim release 4.1):

    • Added an alarmAdditionalInformation field array to the sample requests.

    • Added missing commas.

  • Section 6.2.6.3, 6.3.6.3 commandList sample responses (only in v5.0):

    • Fixed the commandList sample responses to pass an array of anonymous command objects (rather than an array of commandListEntry objects).

    • Fixed the heartbeatIntervalChange commandType to pass a heartbeatInterval value instead of a measurementInterval value.

    • Removed quotes from the measurementInterval and heartbeatInterval values since they are numbers.

  • Section 6.4.6.1 provideThrottlingState sample requests(also incorporated in interim release 4.1):

    • Fixed the eventDomainThrottleSpecificationList to pass an array of anonymous eventDomainThrottleSpecification objects.

    • Added missing quotes.

    • Fixed the suppressedNvPairsList to pass an array of anonymous suppressedNvPairs objects (also incorporated in interim release 4.1).

5/22/2017

v5.1

  • Footers: removed proprietary markings and updated copyrights to 2017

  • Section 4.2.3: field:

    • Changed the API spec to make ‘name’ and ‘value’ start with lowercase letters. Note: this did not affect the schema, which already had them as lowercase.

  • JSON Schema:

    • measurementGroup: deleted this object since it was replaced with ‘namedArrayOfFields’ in v28.0 and was no longer being used.

    • namedArrayOfFields: Fixed an error in the specification of required fields: from ‘measurements’ to ‘arrayOfFields’.

  • Changed the version of the JSON schema to 28.1

6/14/2017

v5.2

  • JSON Schema: created v28.2 by changing the field descriptions in the memoryUsage object to refer to ‘kibibytes’ instead of ‘kilobytes’. There were no changes to the 28.1 structure.

  • Word Document: measurementsForVfScaling Domain: memoryUsage object: changed the field descriptions in this object to refer to ‘kibibytes’ instead of ‘kilobytes’. There were no changes to the memoryUsage structure.

  • Reorganized the Word document to group the data structures in Section 4 into three broad categories to better align with the VNF Guidelines documentation that has been prepared for vendors:

    • Common Event Datatypes:

      • Command List Processing Datatypes

      • Common Event Datatypes

      • Common Event Header Datatypes

    • Technology Independent Datatypes:

      • ‘Fault Domain Datatypes

      • ‘Heartbeat’ Domain Datatypes

      • ‘Measurements For Vf Scaling’ Domain Datatypes

      • ‘Other’ Domain Datatypes

      • ‘State Change’ Domain Datatypes

      • ‘Syslog’ Domain Datatypes

      • ‘Threshold Crossing Alert’ Domain Datatypes

    • Technology Specify Datatypes:

      • ‘Mobile Flow’ Domain Datatypes

      • ‘Sip Signaling’ Domain Datatypes

      • ‘Voice Quality’ Domain Datatypes

  • Section 6.1.3: Commands Toward Event Source Clients: Added a statement: “Note: Vendors are not currently required to implement support for command processing; in addition, command processing may be supported by an App-C interface in future.”

6/22/2017

v5.3

  • JSON Schema: created v28.3 by correcting an error in the sipSignalingFields: changed vnfVendorNameFields to vendorVnfNameFields. Embedded the new schema at the top of section 4.

9/12/2017

v5.4

  • Note: There no changes to any data structures or operations in this version.

  • JSON Schema: created v28.4 embedded at the top of section 4:

    • Added a reference to eventList in the properties defined under the schema title. This enables the schema to correctly validate event batches in addition to just events.

    • Moved the schema title to the top of the schema and changed the text from “Event Listener” to “VES Event Listener”

    • Added a schema header block under the title to clearly communicate the schema version, associated API and last-modified information

  • Changed the date in the copyright notice to 2017

9/19/2017

v5.4.1

  • Note: There no changes to any data structures or operations in this version.

  • Back of Cover Page: updated the license and copyright notice to comply with ONAP guidelines

  • JSON Schema: updated the JSON schema to v28.4.1: updated the copyright notice and license to comply with ONAP guidelines

6/28/2018

v6.0

  • Added contributors to the title page.

  • Updated references to ‘vnf’ ‘vnfc’ to either ‘nf’ and ‘nfc’ or ‘xNf’ and ‘xNfc’ to generalize support across both vnfs and pnfs.

  • Section 1:

    • clarified the meaning of the VES acronym

    • changed references from ASDC to SDC and from MSO to SO

    • clarified the requirements for eventNames.

    • Added a section of EventId use case examples

    • Added a new section on measurement expansion fields

    • Added a new section of syslogs

    • clarified the versioning section and referenced the new API Versioning section in section 6.

    • Added a list of all the latest field block version numbers in this version of the API spec.

  • Section 2: updated the sample to show use of new HTTP versioning headers. Added a note indicating that support for mutual SSL would be provided in future.

  • Section 3: updated the resource structure remove the clientThrottlingState resource.

  • Section 4: hashMaps. Changed all name-value pair structures to hashMaps causing the following data model and JSON schema (to v29.0) changes:

    • 4.1.1: Common Event Datatypes:

      • removed “field” and added “hashMap”

      • removed “namedArrayOfFields” and added “namedHashMap”

      • added arrayOfNamedHashMap

      • added arrayOfJsonObject

    • 4.2.1: Fault Domain Datatypes:

      • changed the faultFields version to 3.0 (major change)

      • changed faultFields.alarmAdditionalInformation to reference a hashMap

    • 4.2.2: Heartbeat Domain Datatypes:

      • changed the heartbeatFieldsVersion to 2.0 (major change)

      • changed heartbeatFields.additionalFields to reference a hashMap

    • 4.2.3: Measurement Domain Datatypes:

      • changed the measurementFieldsVersion to 3.0 (major change)

      • changed measurementFields.additionalFields to reference a hashMap

      • changed measurement.additionalMesurements to reference a namedHashMap [ ]

      • modified measurementFields.featureUsageArray to reference a hashmap and removed ‘featuresInUse’

      • added the following datatypes which are now referenced as items in arrays within measurementFields: hugePages, load, machineCheckException, processStats

    • 4.2.5: Other Domain Datatypes:

      • Change the otherFieldsVersion to 2.0 (major change)

      • changed otherFields.nameValuePairs to reference a hashMap and renamed it hashMap

      • changed otherFields.hashOfNameValuePairArrrays to reference a namedHashMap and renamed it arrayOfNamedHashMap

    • 4.2.7: State Change Domain Datatypes:

      • changed the stateChangeFiledsVersion to 3.0 (major change)

      • changed stateChangeFields.additionalFields to reference a hashMap

    • 4.2.9: Threshold Crossing Alert Domain Datatypes:

      • changed the thresholdCrossingAlertFieldsVersion to 3.0 (major change)

      • changed thresholdCrossingAlertFields.additionalFields to reference a hashMap

      • counter: removed name and value elements and replaced with a hashMap

    • 4.3.1: Mobile Flow Domain Datatypes:

      • changed the mobileFlowFieldsVersion to 3.0 (major change)

      • changed mobileFlowFields.additionalFields to reference a hashMap

      • gtpPerFlowMetrics: modified ipTosCountList to reference hashmap

      • gtpPerFlowMetrics: modified mobileQciCosCountList to reference hashmap

      • gtpPerFlowMetrics: modified tcpFlagCountList to reference hashmap

    • 4.3.2: Sip Signaling Domain Datatypes:

      • changed the sigSignalingFieldsVersion to 2.0 (major change)

      • changed sipSignalingFields.additionalInformation to reference a hashMap

    • 4.3.3: Voice Quality Domain Datatypes:

      • change the voiceQualityFieldsVersion to 2.0 (major change)

      • changed voiceQualityFields.additionalInformation to reference a hashMap

  • Section 4: added notes at the top of section 4 clarifying expectations and requirements for optional fields, extensible fields and keys sent through extensible fields.

  • Common Event Data Types: Section 4.1.1.9 Changed vendorVnfNameFields to vendorNfNameFields; updated Section 4.3.2 SipSignaling and 4.3.3 Voice Quality to refer to the renamed object

  • Common Event Header Section 4.1.2:

    • clarified the descriptions of eventId, reportingEntityName, sourceName and startEpochMicroseconds.

    • Added ‘notification’ and ‘pngRegistration’ to the domain enumeration.

    • added a new timeZoneOffsest field

  • Fault Domain Section 4.2.1: clarified the definitions of alarmCondition, eventSeverity and specificProblem

  • Measurements Domain Section 4.2.3: changed the name of this domain from ‘measurementsForVfScaling’ to ‘measurement’

    • measurementsForVfScaling measurement

    • measurementsForVfScalingFields measurementFields

    • measurementsForVfScalingVersion measurementFieldsVersion

    • the ‘mfvs’ abbreviation measurement

  • Measurements Domain Section 4.2.3 cpuUsage: added seven optional fields to this structure: cpuCapacityContention, cpuDemandAvg, cpuDemandMhz, cpuDemandPct, cpuLatencyAverage, cpuOverheadAvg, cpuSwapWaitTime

  • Measurements Domain Section 4.2.3 diskUsage: added ten optional fields to this structure: diskBusResets, diskCommandsAborted, diskCommandsAvg , diskFlushRequests, diskFlushTime, diskReadCommandsAvg, diskTime, diskTotalReadLatencyAvg, diskTotalWriteLatencyAvg, diskWriteCommandsAvg

  • Measurements Domain Section 4.2.3: added a new ‘ipmi’ datatype along with following ‘supporting’ datatypes: ipmiBaseboardTemperature, ipmiBaseboardVoltageRegulator, ipmiBattery, ipmiFan, ipmiGlobalAggregateTemperatureMargin, ipmiHsbp, ipmiNic, ipmiPowerSupply, ipmiProcessor, processorDimmAggregateThermalMargin

  • Measurements Domain Section 4.2.3: added a new ‘load’ datatype

  • Measurements Domain Section 4.2.3 memoryUsage: added eight optional fields to this structure: memoryDemand, memoryLatencyAvg, memorySharedAvg, memorySwapInAvg, memorySwapInRateAvg, memorySwapOutAvg, memorySwapOutRateAvg, memorySwapUsedAvg

  • Measurements Domain Section 4.2.3: modified measurementFields to include the following new fields: hugePagesArray, ipmi, loadArray, memoryErrors, processStatusArray, rdtArray

  • Measurements Domain Section 4.2.3 renamed vNicPerformance to nicPerformance and changed vNicIdentifer to nicIdentifier

  • Notification Domain Section 4.2.4: added notificationFields to support a new notification domain.

  • pnfRegistration Domain Section 4.2.7: added pnfRegistrationFields to support a new registration domain.

  • sysLog Domain Section 4.2.8: added two new fields: syslogMsgHost and syslogTs. Clarified field descriptions. Clarified syslogSData example.

  • endOfCallVqmSummaries Section 4.3.3.1:

    • converted endpointJitter into two fields: endpointAverageJitter and endpointMaxJitter

    • converted localJitter into two fields: localAverageJitter and localMaxJitter

    • added two fields: localAverageJitterBufferDelay and localMaxJitterBufferDelay

    • added endpointRtpOctetsLost and endpointRtpPacketsLost

    • added localRtpOctetsLost and localRtpPacketsLost

    • converted packetsLost into oneWayDelay

  • API Versioning:

    • Section 1.4: clarified the versioning section and linked it to the following new section 6.1.2

    • Section 6.1.2: Added requirements for HTTP headers communicating minor, patch and latest version information.

    • Section 2 and 6 sample messages: clarified examples to use the new HTTP headers

  • Section 6.1.4: Added a section specifying message size limits.

  • Section2 6.2.6.1 and 6.3.6.1: corrected additionalInformation examples to use hashMap instead of name-value pair fields.

  • Section 7: Added a section on Terminology.

  • Command List Processing: removed command list processing from the document and schema:

    • Modified the Section 3 resource structure to align with these changes.

    • Removed Section 4 Datatypes: command, commandList, eventDomainThrottleSpecification, eventDomainThrottleSpecificationList, eventThrottlingState, suppressedNvPairs

    • Removed Section 6.1 description of commands toward event source clients

  • Removed Section 6.4 operation: provideThrottlingState

7/30/2018

v7.0

  • General:

    • Fixed typos throughout

    • Changed example versions to v7

  • Section1:

    • Clarified casing and use of dashes versus colons in eventName examples

    • Updated all field block versions

  • Section 2: added a note clarifying that TLS 1.2 or higher must be used for HTTPS connections.

  • Section 4 embedded schema changed to v30:

    • Added ” ‘additionalProperties’: false ” to objects to reject events that attempt to send properties that are not listed in the ‘properties’ keyword. Note: does not affect hashmap extensible fields.

    • Changed all versions in all field blocks from number to string enum with the version number fixed by the enum so the schema can validate events that attempt to send non-standard field blocks.

    • Changed syslog additionalFields to a hashMap

  • Section 4:

    • Fixed section heading numbers that were the same

    • 4.1.1: jsonObjectInstance: added an optional recursive jsonObject and removed all required fields from this object

    • 4.1.2: commonEventHeader:

      • nfVendorName: added this optional field

      • timeZoneOffset: changed from number to string with a particular format specified

      • version was changed from number to string (as were all the version fields of all the field blocks)

      • vesCommonEventListenerVersion: added this required field as a string enumeration

    • 4.2.3: Measurements Domain:

      • Added a note clarifying that NFs are required to report exactly one Measurement event per period per sourceName

      • diskUsage: added four new optional fields: diskWeightedIoTimeAve, diskWeightedIoTimeLast , diskWeightedIoTimeMax, diskWeightedIoTimeMin

      • memoryUsage: add one new optional field: percentMemoryUsage

      • nicPerformance: added nine new optional fields: administrativeState, operationalState , receivedPercentDiscard, receivedPercentError, receivedUtilization, speed, transmittedPercentDiscard, transmittedPercentError, transmittedUtilization

      • processorDimmAggregateThermalMargin: make the thermalMargin field required

    • 4.2.8: Syslog Domain:

  • Corrected the example at the end of the section

7/31/2018

v7.0.1

  • Section 4: The schema embedded at the top of section 4 was patched to correct a header field name error—the schema version moves from 30 to 30.0.1:

    • Changed commonEventHeader field: ‘vesCommonEventFormatVersion’ field to ‘vesEventListenerVersion’ and set the enum to 7.0.1

    • Also changed the commonEventHeader ‘required’ array to reflect use the corrected field name: ‘vesEventListenerVersion’

    • Changed the commonEventHeader ‘version’ field enumeration to 4.0.1

  • Section1:

    • Changed the field block versions for the common header for ‘vesEventListenerVersion’ (to 7.0.1) and ‘version’ (to 4.0.1).

  • Sections 2 and 6:

    • Changed the commonEventHeader version fields above, in the sample message requests and responses; also updated the faultFieldsVersion to 4.0

  • Section 6.1.2: Changed the X-LatestVersion to 7.0.1 and the X-PatchVersion to 1

12/10/2018

v7.1

  • Section 1.2: Added Notification domain Perf3gpp domain and changed a reference from ‘measurements domain’ to ‘measurement domain’.

  • Section 1.7.1: Field Block Versions: added ‘perf3gppFields’ version at 1.0 and changed the following version enumerations so that existing clients of major version 7 would not be broken by this VES minor version change, in accordance with semantic versioning definitions:

    • commonEventHeader: changed to ‘vesEventListenerVersion’ enum to accept either 7.0 or 7.0.1 or 7.1.

    • commonEventHeader: changed ‘version’ enum to accept either 4.0 or 4.0.1 or 4.1

  • Section 2:

    • changed sample request and responses to reference 7.1 instead of 7.0.1 (and version 4.1 of the commonEventHeader version, instead of v4.0.1)

    • added a sub section on service provider support for mutual ssl certificate authentication

  • Section 4.1.2.1:

    • CommonEventHeader timeZoneOffset changed description from ‘UTC+/-hh.mm’ to ‘UTC+/-hh:mm’

    • Added ‘perf3gpp’ to the domain enumeration

  • Section 4.2.3: Measurement Domain Datatypes:

    • In ‘MeasurementFields’: Changed ‘ipmiArray’ to ‘ipmi’ and made the type ‘object’

    • ‘ipmiProcessor’: changed ‘pprocessorThermalControl’ to ‘processorThermalControl’

    • ‘machineCheckException’: changed ‘processIdentifier’ to ‘vmIdentifier’

  • Section 4.2.6: added the perf3gpp domain

  • Section 4 embedded schema:

    • Changed the schema version from 30.0.1 to 30.1 as a result of the changes below:

    • commonEventHeader: changed to ‘vesEventListenerVersion’ enum to accept either 7.0, 7.0.1 or 7.1

    • commonEventHeader: changed the ‘version’ field enumeration to accept either 4.0, 4.0.1 or 4.1

    • commonEventHeader: changed the ‘domain’ enumeration to add support for the perf3gpp domain.

    • ‘event’: added a reference to ‘perf3gppFields’

    • ‘hugePages’: changed the type of hugePagesIdentifier from number to string

    • ‘ipmiGlobalAggregateTemperatureMargin’: changed ‘pmiGlobalAggregateTemperatureMarginIdentifier’ to ‘globalAggregateTemperatureMarginIdentifier’

    • ‘perf3gppFields’: added this object

  • Section 6: changed references throughout from v7.0.1 to v7.1 and v4.0.1 (of the commonEventHeader version) to v4.1

  • Changed the location of the doc to VNF Requirements and changed the formatting

1/28/202

v7.1.1

  • Changed event sizes from 2Mb to 1Mb

  • Configuration Requirement comments addressed

  • Changed DCAE Collector to VES Event Listener

  • Replaced VNF with NF where appropriate

  • Updated publishAnyEvent and publishBatchEvent to clarify both one way and mutual TLS are supported

  • Changed authorization for publishEventBatch because certification authorization is also supported

  • Updated fault use case in EventId Use Case Examples based on Ericsson feedback

  • Added new Configuration Requirements section

  • Added new Event Domain Requirements section

  • Updated security requirements based on agreements in ONAP Security Committee with details on 2-way certificate support

  • Provided clarifications on event buffering

  • Added Event Handling Requirements for publishEventFlow

  • Updated Field Block Versions to support existing clients of major version 7

  • Updated sample request and response schemas

  • Updated embedded schema as follows:

    • Changed schema version to 30.1.1

    • Changed measValues to measValuesList and similar changes throughout

    • Changed iMeasTypesList to sMeasTypesList

  • Corrected publishEventBatch call flow diagram

  • Changed AuthorizationHeader to Required? = NO for publishAnyEvent operation

  • Relaxed various requirements related to camel casing of values from ‘must’ to ‘should’