Root cause rule

Have you ever built a root-cause algorithm?

Root cause is so dependent upon each individual network with all of its nuances so it’s difficult to find one-size-fits-all methods. Individuals can develop the experience and can learn to read the signs and understand the linkages. Machine learning can too.

One technique that I find transfers across networks is to build root cause algorithms around network hierarchy (if your network has a hierarchy). eg VPNs over Ethernet over MPLS over transmission over fibres bundled in cables inside conduits / trenches.

If a conduit is taken out by a backhoe then all child elements and related alarms can be ignored / suppressed.

Do you have any root-cause algorithms that transfer well across networks?

Read the Passionate About OSS Blog for more or Subscribe to the Passionate About OSS Blog by Email

2 thoughts on “Root cause rule

  1. Root cause via time window can also be an easy to implement without understanding network hierarchy. Normally with a fault the alarms from various networks will come in at the same time as the fault thus can be grouped together (assuming they are all presented in the same system). In larger networks this can group alarms not related but this can be overcome by having the ability to include or exclude alarms from a grouping.
    Another way is to understand the hierarchy of alarms from the equipment and present the alarm that is the cause. Normally these come from the same element/interface. E.g. If you get a loss of signal alarm then you can suppress the degraded signal alarm from the same interface.

Leave a Reply

Your email address will not be published. Required fields are marked *