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?

If this article was helpful, subscribe to the Passionate About OSS Blog to get each new post sent directly to your inbox. 100% free of charge and free of spam.

Our Solutions

Share:

Most Recent Articles

No telco wants to buy an OSS/BSS

When you’re a senior exec in a telco and you’ve been made responsible for allocating resources, it’s unlikely that you ever think, “gee, we really

2 Responses

  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 *

This site uses Akismet to reduce spam. Learn how your comment data is processed.