Defining a couple of alarms, which are mandatory to be supported in the comment,
defining the minimum multiplicity according to the number of mandatory alarms
(because not possible to have default, when minimum multiplicity > 0) having no default value.
This concept doesn't work, because it is not assured that devices support the mandatory alarms.
As a consequence they could not be listed in the Capability attribute.
In worst case (happened at least for HybridMwStructure and PureEthernetStructure) the device does not support any alarm at all at this interface.
Because it is a list attribute, but does not have a default value, the attribute doesn't show up in the implementation in this case.
Decision made on the 5G-xhaul meeting on 17th of March:
The supportedAlarmList attribute shall have multiplicity and default value "Supported alarms not yet defined." (supportedAlarmList : String [] = "Supported alarms not yet defined.")
"Mandatory:'signalIsLost','rslIsExceeded','signalIDMismatching','temperatureIsExceeded', 'modemIsFaulty','radioIsFaulty' and 'modulationIsDownShifted'. Further alarms might be added by the vendor." shall be removed from the attribute's comment.
openBackhaul
commented
2 years ago
The current concept of supportedAlarmList:
This concept doesn't work, because it is not assured that devices support the mandatory alarms. As a consequence they could not be listed in the Capability attribute. In worst case (happened at least for HybridMwStructure and PureEthernetStructure) the device does not support any alarm at all at this interface.
Because it is a list attribute, but does not have a default value, the attribute doesn't show up in the implementation in this case.
Decision made on the 5G-xhaul meeting on 17th of March: