Artificially Intelligent OctopOSS

The question of whether computers can think is like the question of whether submarines can swim.”
Edsger W. Dijkstra

Artificial intelligence (AI) and fuzzy logic is a field that has fascinated me since being taught the topic as part of an Electronic Engineering subject at University.

The concept of machines/software that can measure, analyse, refine their logic (ie learning) and then provide feedback into the system seemed to have almost unlimited applications.

The field of OSS seems to have huge opportunities to use AI because it has so many data feeds and so much information that is awaiting refinement and derivation of insightful knowledge.

Telecommunications has a long history of methods for avoiding payment and these fraudulent techniques are constantly being refined to avoid detection by pre-defined algorithms. Evolving algorithms are undoubtedly already being used in Revenue Protection systems. They are also being used in contact centres and other parts of the OctopOSS.

But the one that really intrigues me is in Alarm / Fault Management. On all systems that I’m currently aware of, alarm correlation techniques require expert engineers to identify a pattern of events and then write fixed correlation rules. In many cases, the engineers aren’t able to speak the same language as the algorithm coders so whatever capability exists in the OSS is often not used to its full extent. Furthermore, correlation is often possible within a single domain, but across complicated cross-domain networks it becomes much more difficult. Similarly, in the modern packet switched networks with new technologies arising as well as evolving routing and label algorithms it is nearly impossible to re-use correlation rules from one network to the next.

Are we looking at alarm correlation backwards? Rather than looking at patterns of alarms as they are created, should we actually looking at building AI engines to analyse patterns at alarm closure (ie manual resolution of the route cause leading to automatic resolution of all downstream alarms)? The alarm closure findings can alert operators when similar patterns arise in future, with the engine learning more with each new alarm.

The network engineers would continue to resolve alarm situations as they currently do and the algorithm would just sit in the background and learn from what they’ve done. As the algorithm learns which actions have caused the quickest resolutions to problems, it can provide recommendations when future events arise. The best of the engineers’s resolutions will evolve and the weakest will be killed off with Darwinian efficiency.

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

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.