Configuration Change Notification

Owned by Martin Skorupski
Last updated: Jul 13, 2020 by ravi.pendurty
2 min read

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"

  • "-"

  • Value as  discovered when NetConf connection is established: /device/device-info/serial-number

  • "-"

  • value of an increasing sequence number (int (32 bits); even so, please implement wrap around)

eventName

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

nfcNamingCode

always ""

nfNamingCode

always ""

nfVendorName

Value as  discovered when NetConf connection is established: /device/device-info/manufacturer

priority

Static text "Normal"

reportingEntityId

not mapped

reportingEntityName

as configured by helm charts for the ODL cluster name - default "ONAP SDN-R"

sequence

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

sourceId

Value as  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/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: "4.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)