Skip to end of metadata
Go to start of metadata

You are viewing an old version of this content. View the current version.

Compare with Current View Version History

« Previous Version 5 Next »

Scope

This page describes the mapping of several alarm / fault data models towards its representation in ODLUX.

CCSDK-3166 - Getting issue details... STATUS


The following data models should be considered are:

- VES 7.2
- ietf-alarms.yang (RFC 8632)
- o-ran-fm.yang (OpenFronthaul M-Plane)
- onf:air-interfaces-2.0.yang (OpenBackhaul)
- OpenROADM Alarm

ODLUX

(label)

VESIETFO-RAN-FHONF-AirInterfaceOpenROADMComments
TimestampcommonEventHeader/startEpochMicrosec

alarm/time-created

active-alarms/event-time


Node NamecommonEventHeader/sourceNameThe node-id used by OpenDaylightThe node-id used by OpenDaylight


CountcommonEventHeader/sequencen/an/a

Counts doenst seems to be the best naming, VES can send 0 or 1, depending if alarm or clear
ObjectId

faultFields/alarmInterfaceA

alarms/resource

active-alarms/fault-source


Alarm TypefaultFields/alarmCondition

alarms/alarm-type-id

(alarms/alarm-type-qualifier)

active-alarms/fault-id together with active-alarms/fault-text 


SeverityfaultFields/eventSeverityalarms/perceived-severity  together for alarms/is-clearedactive-alarms/fault-severity together with active-alarms/is-cleared 


  • No labels