Hello All,I was checking the Service problem management API and automating the service problem management in fault management domain of NaaS.As per this process, the operational domain is concerned with performing the root cause analysis and correlations to pre-empt the service problems and identify the actual fault, location, related alarms and affected resources etc. After this should the related ticket to the TT system should be a problem ticket or an incidence ticket?
Also in cases where there is going to be prediction of service degradation, will that qualify for a problem ticket or an incidence ticket (621)?More light on the use cases and corresponding APIs in these scenarios will be very helpful.@Johanne MayerWarm Regards,Jigna
Trouble or Problem ABE
The Resource Trouble ABE manages problems found in allocated resource instances, regardless of whether the problem is physical or logical. Entities in this ABE detect these problems, act to determine their root cause, resolve these problems and maintain a history of the activities involved in diagnosing and solving the problem. Detecting problems can be done via software (e.g. responding to an alarm) and/or by hardware (e.g. a measurement or probe) and/or manually (e.g. visual inspection). This includes tracking, reporting, assigning people to fix the problem, testing and verification, and overall administration of repair activities.Regarding Fault management the best definition is from ITU alarm M3703 M.3703 : Common management services - Alarm management – Protocol neutral requirements and analysis (itu.int)The occurrence of failures in a NE may cause a deterioration of this NE's function and/or service quality and will, in severe cases, lead to the complete unavailability of the respective NE. In order to minimize the effects of such failures on the quality of service (QoS) as perceived by the networkusers, it is necessary to:• detect failures in the network as soon as they occur and alert the operating personnel as fastas possible;• isolate the failures (autonomously or through operator intervention), i.e., switch off faultyunits and, if applicable, limit the effect of the failure as much as possible by reconfigurationof the faulty NE/adjacent NEs;• if necessary, determine the cause of the failure using diagnosis and test routines; and• repair/eliminate failures in due time through the application of maintenance procedures.This aspect of the management environment is termed "fault management" (FM). The purpose ofFM is to detect failures as soon as they occur and to limit their effects on the network quality ofservice (QoS) as far as possible.This is supported by the TMF642 alarm management API which is more of a NaaS network domain function or E2E network domain function (i.e. stays within the production functional block)SID has a special addendum ID TIP Resource Alarm Management Information agreement in case you are interested.I hope this helps you further and we discussed bringing some of that information in our NaaS IG1224 work for others to benefit!Special thanks to @pierregauthier for some of the pointers!Best regards.... Johanne