In order to process O-RU NetConf alarm-notif events in a common way on SMO level, the OAM controller converts such NetConf Notification into a VES:fault message..
''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''' ' PlantUML for O-RAN-SC closed loop use case D-release (OAM view) ' ' Copyright 2021 highstreet technologies GmbH ' 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. ' @startuml ' Diagram title OpenFronthaul Alarm to to VES-fault end title box "SMO" #gold participant "Message-Router" as mr participant "VES-Collector" as ves participant "OAM-Controller" as oam end box box “O-RU” #lightpink participant "NetConf-Server-OFH" as ncsofh end box autonumber 1 1 "<b>[00]" == init == ncsofh -> oam: NETCONF Callhome SSH ncsofh <-> oam: NETCONF <hello/> \nExchange capabilities \nincluding YANG modules for OpenFronthaul\nand <create-subscription/> RPC oam -> ncsofh: NETCONF Notification Subscription oam -> ncsofh: GET ietf-hardware oam <- ncsofh: RESPONSE ietf-hardware == use case == ncsofh -> oam: NETCONF Notification \no-ran-fm:alarm-notify(fault-id: 30 (Interface Fault) ) oam -> oam: map o-ran-fm:alarm-notify \ninto VES:fault (see below) oam -> ves : VES:domain=fault ves -> mr: publish event ' End Diagram ' Format right footer Thanks to PlantUml! License: Apache 2.0 2021-02-10 | o-ran-sc.org end footer skinparam backgroundColor #fefefe skinparam backgroundColor #fefefe 'skinparam handwritten true skinparam roundcorner 15 skinparam database { BorderColor #444444 BackgroundColor #ffffdd FontColor #444444 } skinparam sequence { MessageAlign left ArrowColor #2277dd ArrowFontColor #444444 ArrowThickness 2 ActorBorderColor #444444 LifeLineBorderColor #444444 LifeLineBackgroundColor #eeeeee LifeLineBackgroundColor #eeeeee BoxBorderColor #444444 GroupBorderColor #444444 GroupBackgroundColor #eeeeee ParticipantBorderColor #444444 ParticipantBackgroundColor #ffffdd ParticipantFontColor #444444 ActorBackgroundColor #ffffdd 'ActorFontColor DeepSkyBlue 'ActorFontSize 17 'ActorFontName Aapex } @enduml |
It is assumed that the existing generic NetConf-Notification to ves:notification service could be enhanced for a specific fault notification implementation.
The following mapping table bases on the capabilities of OpenDaylight version Aluminum and maps them to the VES 7.2.1 fields for domain 'fault'.
A couple of VES fields needs to be filled with values from a an Ietf:hardware/component which does not have the leaf "parent". If more than one component would not have the leaf "parent" then the first component should be used for such fields (e.g. manufacture name).
VES:commonEventHeader
implementation of OpenDaylight Aluminium (link)
domain
Static text "fault"
eventId
Value of 'nt:network-topology/nt:topology/nt:node/nt:node-id'.
eventName
Value of 'nt:network-topology/nt:topology/nt:node/nt:node-id'.
eventType
Static text: "O-RAN-RU-Fault"
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
The value of ietf-hardware (RFC8348) /hardware/component[not(parent)][1]/mfg-name or empty string if not found.
Under discussion: how to identify the "root" component?
Answer: /ietf-hardware:hardware/component[not(parent)][1]/mfg-name
priority
Static text "Normal"
reportingEntityId
The OAM-Controller identifier with in the SMO - e.g. the fully qualified domain name or IP-Address.
reportingEntityName
as configured by helm charts for the OpenDaylight cluster name
sequence
As per NetConf notification increasing sequence number as unsigned integer 32 bits. The value is reused in the eventId field.
sourceId
Value of ietf-hardware (RFC8348) /hardware/component[not(parent)][1]/uuid or 'nt:network-topology/nt:topology/nt:node/nt:node-id' if ietf component not found.
sourceName
Value of 'nt:network-topology/nt:topology/nt:node/nt:node-id'.
startEpochMicrosec
Current OAM-Controller Node timestamp in unix time format - as microseconds elapsed since 1 Jan 1970 not including leap seconds.
timeZoneOffset
Static text: "+00:00" - Please note, the time format in all related OAM controller times is in UTC time format - a mapping to other time formats happens in presentation layer only (e.g. on user settings, bowser settings, ...)
version
Static text: "4.1"
vesEventListenerVersion
Static text "7.2.1"
VES:fault
If an ieft-hardware component is not identified for the mapping into VES:fault or an optional leaf is not provided, then the VES:fault should be part of the message with its default value (e.g. empty string "")
The ietf-hardware component must not have the 'parent' leaf.
alarmAdditionalInformation
not mapped
alarmCondition
Value of "o-ran-fm:alarm-notif/fault-id"
alarmInterfaceA
Value of "o-ran-fm:alarm-notif/fault-source"
eventCategory
Static text "O-RU failure"
eventSeverity
Value of "o-ran-fm:alarm-notif/fault-severity"
but if "o-ran-fm:alarm-notif/is-cleared" then "NORMAL"
eventSourceType
The value of ietf-hardware (RFC8348) /hardware/component[not(parent)][1]/model-name or "O-RU" if not found.
faultFieldsVersion
Static text: "4.0"
specificProblem
A mapping of the fault-id to its description according to O-RAN OpenFronthaul specification.
vfStatus
Static text: "Active"