Versions Compared

Old Version 2

changes.mady.by.user Martin Skorupski

Saved on

compared with

New Version Current

changes.mady.by.user ravi.pendurty

Saved on

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

In order to convert a NetConf notification into a VES7.1.1 format a mapping between a specific YANG set of YANG modules and the VES:commonEventHeader and its domain "notification. In the example below we need the BBF-TR069 implemented in the OAM-TR069-Adapter for such mapping.

BBF-TR069 defines 4 kind of CM notifications: VALUECHANGE, BOOT, BOOTSTRAP and PERIODIC. However, the mapping to VES:notification is the same. 


VES:commonEventHeader

implementation of TR069 yang

domain

Static text "notification"

eventId

Concatenation of:

  • The notification name (root-xml-tag) as specified in the YANG model, so one of the following values
    • "VALUECHANGE"
    • "BOOT"
    • "BOOTSTRAP"
    • "PERIODIC"
    ConfigurationChange
  • "-"
  • Value of: notification VALUECHANGEas  discovered when NetConf connection is established: /device/device-info/serial-number
  • "-"
  • value of an increasing sequence number (uint64int (32 bits); even so, please implement wrap around)

eventName

Static text: "ConfigurationChange

The notification name (root-xml-tag) as specified in the YANG model, so one of the following values

  • "VALUECHANGE"
  • "BOOT"
  • "BOOTSTRAP"
  • "PERIODIC"

eventType

Static text: "OAM-TR069_RAN_notification"

internalHeaderFields

not mapped

lastEpochMicrosec

TimeStamp of the represented by <eventTime> field in NetConf notification header in unix time format - as microseconds elapsed since 1 Jan 1970 not including leap seconds.

nfcNamingCode

not mappedalways ""

nfNamingCode

not mappedalways ""

nfVendorName

Value of: notification VALUECHANGEas  discovered when NetConf connection is established: /device/device-info/manufacturer

priority

Static text "Normal"

reportingEntityId

not mapped

reportingEntityName

TODO add definition of as configured by helm charts for the ODL cluster name - default "ONAP SDN-R node id here (fqdn?)"

sequence

An As per NetConf notification increasing sequence number as unsigned integer 64 32 bits. The value is reused in the eventId field.

sourceId

Value of: notification VALUECHANGEas  discovered when NetConf connection is established: /device/device-info/serial-number

sourceName

Always use ODL/node-id (mountpoint name). Also compare against Value of: notification VALUECHANGE/device/device-info/x-0005b9-operator-name

startEpochMicrosec

not mapped/services/fap-service[index]/cell-config/lte/ran/s1-ap/x-0005b9-e-nb-name if it exists and if different then log a warning. If the aforementioned field (x-0005b9-e-nb-name) does not exist then warning message not required

startEpochMicrosec

TimeStamp represented by <eventTime> field in NetConf notification header in unix time format - as microseconds elapsed since 1 Jan 1970 not including leap seconds.

timeZoneOffset

Static text: "+00:00" - Please note that times from NetConf Notification Header may need to be converted to UTC.

version

Static text: "74.1.1"

vesEventListenerVersion

Static text "7.1.1"



VES:notificationFields


additionalFields

not mapped

arrayOfNamedHashMap

That field is used to transport the information which has changed, basically as key value pair. As key the xpath to the leaf should be used.

Example:

"/notification/VALUECHANGE[@xmlns=\"urn:org:onap:ccsdk:features:sdnr:northbound:onecell-notification\"]/device/services/fap-service[2]/fap-control/lte/rf-tx-status": "false",

changeContact

not mapped

changeIdentifier

ODL/node-id (mountpoint name)

changeType

The notification name (root-xml-tag) as specified in the YANG model, so one of the following values

  • "VALUECHANGE"
  • "BOOT"
  • "BOOTSTRAP"
  • "PERIODIC"

newState

not mapped

oldState

not mapped

notificationFieldsVersion

Static text: "2.0"

stateInterface

not mapped - alternative: the most common part of the keys of arrayOfNamedHashMap (would be redundant)