Fault Management Pipeline

Last updated 14 Oct 2026

At a glance

Fault management turns raw network events into the answer the business needs: which customers are affected, how badly, and what the contract obliges the operator to do. It is a pipeline, and each stage after filtering depends on inventory data that Lead-to-Cash wrote.

The picture

Many raw events in, one prioritised incident out. Each stage after filtering is only as good as the record it reads.

Pipeline stage

Reads from (written by L2C)

1Event collection
EMS / NMS, collectors
Traps, syslog, telemetry, notifications. One fault, many events.
2Filtering and deduplication
Alarm platformTMF642
Duplicates, transients and flapping suppressed.
3Alarm correlation
Correlation engine
Related alarms grouped into one probable failure.
Reads:Resource topology
4Root cause
Fault management
The single failure that explains the symptoms.
Reads:Resource dependencies
5Service impact
Fault / service problem mgmtTMF656
Failed resource walked up RFS → CFS. A network event becomes a service event.
Reads:Service inventory · TMF638
6Customer impact
SLA management
CFS linked to product instances, customers and SLA terms.
Reads:SLM / product inventory · TMF637
7Prioritise and act
ITSM platformTMF621
Incident with customer count and SLA exposure: dispatch, notify, escalate.
Reads:CRM, contract value

If a record is missing: the pipeline stops at that stage. Topology gaps leave alarms uncorrelated; service or product gaps leave impact unknown until customers call.

From many raw events to one prioritised incident. Correlation and root cause read resource topology; service and customer impact read service inventory and SLM. Each stage is only as good as the record it reads.

How it works

Impact analysis is the point

A fibre cut or a line-card failure is an infrastructure fact. Without impact analysis, the NOC sees alarms on equipment, the service desk sees customer complaints, and neither can connect the two in real time. Fault management’s value is the translation between them. In eTOM it spans Resource Trouble Management (1.2.3.2) and Service Problem Management (1.2.2.2), and feeds Customer Problem Handling (1.2.1.4).

The pipeline

Event collection. Network elements, probes and EMS/NMS emit SNMP traps, syslog, streaming telemetry and API notifications. One fault can produce thousands of events.
Filtering and deduplication. Duplicates, transients and flapping alarms are suppressed, leaving alarms worth managing (TMF642 carries them between systems).
Alarm correlation. Related alarms are grouped: fifty interface-down alarms below one aggregation node are one failure, not fifty. This needs topology from resource inventory.
Root cause. The correlated set is traced to the single failure that explains it, using upstream and downstream resource dependencies.
Service impact. The failed resource is walked up the RFS-to-CFS chain in service inventory to find which services are degraded or down. This is where a network event becomes a service event.
Customer impact. Affected CFS instances are linked to product instances in SLM to find customers, tiers and SLA commitments.
Prioritisation and action. The enriched fault, now carrying customer count and SLA exposure, drives the incident or trouble ticket (TMF621), dispatch, proactive notification and escalation.

Network view and business view

Question	Without impact analysis	With impact analysis
How bad is it?	Four interfaces and twelve BGP sessions down	Enterprise customers affected, VPN and SIP trunk services degraded or down, counted
Who cares?	The NOC team assigned to restore	Named customers on a four-hour restore commitment, with an estimated breach time
What should we do?	Replace the line card	The same fix, escalated on SLA exposure, with affected customers notified and credits pre-calculated
After resolution?	Interfaces up, ticket closed	Every affected service verified restored, SLA compliance calculated, data fed to capacity planning

What each stage needs from L2C

Stage	Data required	Written by	If missing
Alarm correlation	Topology, device relationships, connectivity	Resource inventory, at ROM and activation	Every alarm treated as independent; the NOC drowns in noise
Root cause	Upstream and downstream dependencies	Resource inventory relationships	Root cause guessed from experience; restore times rise
Service impact	RFS-to-CFS mappings	Service inventory, at SOM fulfilment	Impact unknown until customers report it
Customer impact	CFS-to-product-to-customer links, SLA terms	SLM, at order completion	All faults get equal priority
Prioritisation	Customer tier, contract value, penalties	CRM, SLM, billing	Priority by technical severity only

Who owns what

Entity	System of Record	System of Engagement	System of Reference	Notes
Raw events and telemetry	EMS / NMS and collectors	—	Fault management	Usually short-lived; retention is an operational choice
Alarms (filtered, correlated)	Fault management / alarm platform	NOC consoles	ITSM	TMF642
Resource topology and dependencies	Resource inventory	—	Correlation engine, CMDB	TMF639. Should be reconciled against EMS discovery.
Service instances and RFS-to-CFS links	Service inventory	—	Fault management	TMF638
Product instances, customer links, SLA terms	SLM / product inventory	—	Fault management, SLA management	TMF637
Service problem (impact view of a fault)	Fault or service problem management	—	ITSM	TMF656. Many estates hold this inside the ITSM incident instead.
Incident / trouble ticket	ITSM platform	Service desk, CRM	—	TMF621

In practice

Operators often invest in correlation engines and AIOps platforms expecting them to deliver customer impact. These tools reduce alarm noise well, but they can only work with the data they are given. If service inventory has no CFS-to-RFS topology, or product instances are not linked to service instances, no engine can say which customers are affected. That gap has to be closed at fulfilment time.

The installed base is the harder case. Services provisioned manually or before the current catalog have partial or missing lineage, so impact analysis works for recent customers and not for older ones on the same node. Network changes made directly through an EMS also cause topology drift, which produces false positives and missed impact. Reconciliation against discovery is ongoing work, not a one-off clean-up (10.3).

The trade-off

What it solves

A full pipeline turns one infrastructure failure into one prioritised incident, expressed in affected customers and SLA exposure rather than alarm counts.

What it does not solve

It does not create the inventory linkage it depends on; correlation tooling cannot compensate for missing service or customer links.
It does not keep topology current when the network is changed outside the order flow.

What it adds

Fault management depends on three inventories and SLM being available and consistent at query time.
Correlation rules and topology models need continuous maintenance as the network changes.
False positives from stale topology can mis-prioritise incidents and notify the wrong customers.

Architecture decision

Invest first in a correlation or AIOps platform, or in the inventory linkage it reads?

Correlation platform first
Choose when Inventory linkage is already largely complete and the main problem is alarm volume
Inventory linkage first
Choose when Services cannot be traced from resource to customer today, especially across the installed base

Breaks if A correlation platform is bought to deliver customer impact while service and product linkage is missing: noise falls, but impact analysis stays manual.

Takeaways

Key Takeaways

Fault management is a pipeline from raw events to a prioritised incident, and impact analysis is its purpose.
Correlation and root cause read resource topology; service and customer impact read service inventory and SLM.
Every stage after filtering depends on data written during Lead-to-Cash.
Correlation and AIOps tools reduce noise but cannot invent missing linkage.

Check yourself

The NOC correctly identifies a failed aggregation node within minutes, but nobody can say which customers are affected for over an hour. Which stage is failing?Show answerHide
Service and customer impact. Resource topology is working; the RFS-to-CFS links in service inventory or the CFS-to-product links in SLM are missing or incomplete.
Why can impact analysis work for new customers but not older ones on the same router?Show answerHide
Older services were provisioned before catalog-driven decomposition, or manually, so they have no clean resource-to-service-to-product lineage. The pipeline has nothing to walk.