Attribute for configuring the severity level

[openBackhaul]

While configuring the level of severity of a combination of alarm type and resource, peripheral conditions might be of relevance.
E.g. the protection configuration (e.g. 1+0 or 1+1) might influence, whether a LoS alarm would be assigned to be critical or just e.g. major.
Based on this consideration we added two attributes (“severityLevelForServiceAffecting” and “severityLevelForNotServiceAffecting”) two every combination of alarm type and resource.

While searching for a generally adopted definition of what’s “service affecting”, we found indication that the definition of severity level “critical” is that the service is affected.
If the severity level would always be “critical” in all cases the service is affected, configuration of the severity level would be obsolete in these cases.

Potential proposal to the 5G-xhaul call
Creating a single SeverityConfigurationType::severityLevel attribute with comment: “Allows configuring the severity level of alarms of the specified combination of alarm type and resource, in case they are not service affecting. If such alarm would be service affecting, severity level ‘critical’ would be assigned in general.”
Deleting SeverityConfigurationType::severityLevelForServiceAffecting and SeverityConfigurationType::severityLevelForNotServiceAffecting attributes from the modeling.

[openBackhaul]

We later decided to replace SeverityConfigurationType::severityLevelForServiceAffecting and SeverityConfigurationType::severityLevelForNotServiceAffecting attributes by a severityLevelList[*] attribute.