Every Alarm Has a Cause: An Open Generator of Telecom Alarm Storms with Exact Root Causes, Bound to NORIA-O, RFC 8632 and TMF642

Madhulatha Mandarapu; Sandeep Kunkunuru

cs.NIOct 21, 2026

Every Alarm Has a Cause: An Open Generator of Telecom Alarm Storms with Exact Root Causes, Bound to NORIA-O, RFC 8632 and TMF642

Authors: Madhulatha Mandarapu, Sandeep Kunkunuru

Organizations: VaidhyaMegha Private Limited, India

Abstract

Alarm root-cause analysis is studied on data that cannot be shared. Operator logs are confidential, so what the field publishes is a causal graph between alarm types rather than per-incident causes, a fixed scenario set, gated, or never released. Two recent benchmarks carry per-incident root causes at scale; neither states a download location or a licence. We give a generator rather than a dataset. It runs on real backbone topologies from the Internet Topology Zoo and records the exact root cause and the propagation path of every alarm -- a by-product of generation, not a labelling pass. Every emitted field binds to a term in NORIA-O, RFC 8632, RFC 8345 or TMF642, and an unknown term fails the run. We ship fixed configurations, splits, a scorer and nine baselines. A one-line rule -- rank the device that raised the earliest critical alarm -- takes top-1 at 0.650 against 0.575 for our own temporal method, and wins 13 of 15 runs over three backbones and five seeds. An LLM given the same view reaches 0.600, the same model allowed to query the graph 0.625, and the rule wins on real operator alarms too, at 0.773: a property of alarm streams, not of our generator. One fault class separates the table: when a site loses power its PoP reports nothing, so every method that ranks alarmed devices scores 0.000 or near it, while the two that walk the topology to a silent candidate take 1.000 and 0.833.

Figures & tables

Resource	Obtainable	Labels	Topology
PCIC 2021 [ 7 ]	yes, MIT	alarm- type graph	none
Influence-based [ 15 ]	no	per-transaction (unreleased)	none
TN-RCA530 [ 5 ]	announced only	per-incident	per-scenario KG
TeleRCA [ 6 ]	announced only	per-incident, no path	none published
TeleLogs [ 8 ]	gated	8 fixed categories	none
RCAEval [ 3 ]	yes	per-case service	microservice

Table 1: Public resources for alarm root-cause analysis. “Announced only” means the paper states the resource is released and contains no repository, download or licence.

Panel of Figure 1 — Figure 1: How a run is produced. Only the top box is real; everything below it carries synthetic: true . The two outputs are written by the same pass, which is why every alarm’s cause and path are exact rather than inferred.

Panel of Figure 2 — Figure 2: What each emitted field binds to. NORIA-O references neither RFC 8632 nor TMF642; that binding is ours. specific_problem is deliberately free text, and Section 5 shows why it had to be withheld from the methods.

Alarm property	best value	Top-1	Prec.	Inc.
specific_problem (before)	root	0.700	1.000	28
perceived_severity	critical	0.625	0.893	28
specific_problem	Transmit module failure	0.225	1.000	9
probable_cause	transmitterFailure	0.225	1.000	9
alarm_type	communicationsAlarm	0.225	0.250	36

Table 2: Each alarm field’s best single value read as a one-line RCA rule, GÉANT small,

n=40

. Prec. is the share of the incidents where such an alarm exists in which its earliest one sits on a true root; Inc. is how many of the 40 those are. The top row is the leak, measured with the same tool on the dataset as it was shipped before 2026-10-21, and it is the only row not measured on the released data. The row below it is not a leak and is the highest on the current dataset, at

0.625

— level with the best method in Table 4 : perceived_severity is an RFC 8632 field a real console shows, and what its score says is that our fault model marks the root critical too reliably (Section 9 ). The two rows below that reach

1.000

precision on

9

incidents each, which the gate deliberately allows: a value that names the root whenever it appears but appears in a fifth of incidents is a narrow cause doing its job, not a free answer.

	Generated	Real (PCIC)
alarms	$1{,}572$	$34{,}838$
alarm types	21	18
devices	717	55
inter-arrival median (s)	$60.4$	$132.0$
share of gaps under 1 s	$0.041$	$0.019$
largest burst (alarms)	$\mathbf{82}$	$\mathbf{30}$

Table 3: Generated GÉANT small against real operator alarms. The type field is probable_cause , X.733’s catalogue of named causes, which is the analogue of PCIC’s alarm_id ; see the caveat below on the field this table used first. Excitation is a lift-over-base-rate proxy : for each ordered type pair, how often

B

follows

A

within 300 s divided by

B

’s base rate. No Hawkes kernel is fitted and no parameter is estimated on either side; a fit remains unmeasured. Bold marks the one axis on which the two streams differ.

Figure 3: Every method at both sample sizes, with its 95% interval. The

n=40

intervals (circles) are more than twice the width of the

n=200

ones (diamonds), and most of the table sits inside a single one of them.

rules we did not design
	$n=40$	$n=200$
Method	Top-1	Top-1	Top-3
earliest critical alarm	$0.625$	0.650	$0.650$
most alarmed device	$0.250$	$0.375$	$0.535$
random among alarmed devices	$0.225$	$0.285$	$0.545$
most recent change	$0.225$	$0.180$	$0.200$

Table 4: GÉANT, the same generator and seed at two sample sizes:

40

eval incidents and

200

. The configurations differ in scenario counts and in nothing else. Two of them raise no alarm on any device, so no method has anything to rank; each is charged a miss to every row rather than dropped (Section 9 ). A rate near

0.5

carries

\pm 0.155

at 95% on

40

trials and

\pm 0.069

200

; Figure 3 draws both. No paired test has been run. † one run of a non-deterministic method, so that row is a sample and not a repeatable number; the others are. Every row is measured after the arrival-time fix of Section 6 ; the numbers in the first version of this paper were measured before it and all of them moved.

Panel of Figure 4 — Figure 4: The fault class that separates the table. A dead PoP cannot report itself, so the answer is the one device that emitted nothing. Reaching it is a traversal over the topology, and no amount of reading the alarm stream substitutes for it.

Figure 5: Top-1 per fault type at $n=200$ . Reading down the power loss column: the two methods that walk the topology take $1.000$ and $0.833$ , and every rule, both Hawkes variants and both LLM rows take $0.000$ . No other column separates the table that way.

	GÉANT ( $40$ )		Abilene ( $11$ )		Cogentco ( $197$ )
Method	mean	range	mean	range	mean	range
earliest critical alarm	$0.585$ ( $\pm 0.038$ )	$0.550$ – $0.625$	$0.620$ ( $\pm 0.048$ )	$0.575$ – $0.700$	$0.595$ ( $\pm 0.054$ )	$0.525$ – $0.650$
temporal (ours)	$0.485$ ( $\pm 0.055$ )	$0.450$ – $0.575$	$0.565$ ( $\pm 0.076$ )	$0.475$ – $0.650$	$0.535$ ( $\pm 0.029$ )	$0.500$ – $0.575$
neighbourhood (ours)	$0.420$ ( $\pm 0.062$ )	$0.375$ – $0.525$	$0.480$ ( $\pm 0.084$ )	$0.350$ – $0.550$	$0.485$ ( $\pm 0.065$ )	$0.400$ – $0.575$
thp_causal	$0.395$ ( $\pm 0.116$ )	$0.225$ – $0.525$	$0.420$ ( $\pm 0.076$ )	$0.350$ – $0.525$	$0.380$ ( $\pm 0.021$ )	$0.350$ – $0.400$

Table 5: Top-1 over five seeds per topology, mean (

\pm

sd) and observed range;

n=40

in every run. The number in each heading is the backbone’s PoP count. llm_ranker is absent: it is a paid, non-deterministic method and was run once.

Source removed	earliest crit.	temporal	neighbourhood	thp_causal
alarms that never arrive	$+0.150$	$+0.150$	$+0.200$	$-0.025$
background alarms ‡	$+0.000$	$+0.025$	$+0.075$	$+0.075$
per-device clock skew	$+0.000$	$+0.100$	$+0.075$	$-0.075$
neighbour-cell storms	$+0.000$	$+0.100$	$+0.175$	$-0.100$
mis-grouped incidents	$+0.050$	$+0.025$	$+0.050$	$+0.075$

Table 6: Signed change in top-1 when one noise source is removed; positive means the method got better without it. GÉANT small, seed as in Table 4 ,

n=40

throughout. ‡ removing background alarms also changes how many incidents have any alarm to rank, from

0

3

: for three incidents the only alarms the NOC had attached were background ones. Three forced misses then sit inside every method’s delta on that row, so it is not a difference in difficulty and we do not read it as one.

Root Cause Analysis

Root cause analysis identifies the initiating faults behind observed failures by tracing symptoms through causal and system dependencies.

See all 80 papers

EvoCause: LLM-Guided Evolution of Causal Graphs for Root Cause Analysis
Jul 29, 2026Lei Zan, Keli Zhang, Shifeng Xie +7Causal Discovery Root Cause Analysis
Huawei Noah’s Ark Lab · Guangdong University of Technology, Peng Cheng Laboratory
NetCause: Counterfactual Learning for Root Cause Analysis in Large-Scale Networks
Jun 11, 2026Fabien Chraim, Jian Zhang, Dominik Janzing +3Anomaly Localization Causal Inference
Amazon Web Services, Seattle, Washington, USA
Where Root Cause Analysis Fails: A Retrieval-Reranking Decomposition
Sep 29, 2026Hada Melino Muhammad, Luan Pham, Laure Barrière +3Root Cause Analysis Industrial Anomaly Detection
University of New South Wales · Baker Hughes

Jul 29, 2026J/K move · Enter open · S save

EvoCause: LLM-Guided Evolution of Causal Graphs for Root Cause Analysis

Lei Zan, Keli Zhang, Shifeng Xie, Jiale Zheng+6

Huawei Noah’s Ark Lab · Guangdong University of Technology, Peng Cheng Laboratory

Causal Discovery Root Cause Analysis

Open paper AskPDF arXiv

Modern telecommunication, cloud, and microservice systems emit correlated alarm cascades when components fail. Root cause analysis (RCA) aims to identify the small set of alarms that initiate each cascade. A common approach learns a causal graph from observational logs and predicts all zero-in-degree alarms in each incident-induced subgraph. However, the learned graph remains fixed and cannot benefit from expert diagnoses of historical incidents. We close this loop with EvoCause. Expert labels constrain which alarms should be source nodes but do not specify the edge edits needed to satisfy those constraints. EvoCause uses a large language model (LLM) to propose semantically plausible graph edits, while deterministic code validates node identities and acyclicity and retains the best graph on a labeled alignment set. At test time, the refined graph alone produces transparent predictions without an LLM call. We also release TeleRCA, an expert-annotated benchmark from a production telecommunication network containing

485{,}681

alarm events spanning

194

alarm types over

5{,}621

resources. On synthetic data, EvoCause initialized with the PC causal discovery algorithm outperforms the unrefined PC baseline, raising Node F1, Case EM, and Graph F1 by

11.59

9.40

, and

4.59

percentage points, respectively, while reducing nSHD by

0.2379

. On TeleRCA, replacing human-readable alarm titles with anonymous identifiers lowers Node F1 and Case EM by

6.12

and

8.04

percentage points, respectively, indicating that alarm-name information contributes to graph refinement.

Abstract

Root Cause Analysis

Explore similar work

EvoCause: LLM-Guided Evolution of Causal Graphs for Root Cause Analysis

NetCause: Counterfactual Learning for Root Cause Analysis in Large-Scale Networks

Where Root Cause Analysis Fails: A Retrieval-Reranking Decomposition