Network Alarm & Fault Analytics · Brief 01

Critical-alarm cluster · Northeast 5G NR

One fault, not three hundred alarms

Network alarms & faults + usage + care · by region × city × vendor × element · runs on your own infrastructure

The one line you configure

After de-duplication, how many real faults sit in the alarm stream right now — where are they clustering, and which of them are subscribers already feeling?

In a nutshell

A genuine fault, and it is clustering. Critical alarms on Norvex's 5G NR estate in Northeast rose 340% in three hours, concentrated in three New York districts. De-duplicated per element, 312 raw alarms resolve to 19 affected sites and one shared fault signature. Subscriber impact is already visible: 5G→4G fallback in those districts is up 2.7× and data-speed complaints are following.

At a glance

Critical alarms+340%3 hours

Distinct faults19from 312 alarms

5G fallback+2.7×subscriber impact

Clear rate12%not self-clearing

WHAT MOVED · 312 alarms → 19 faults → 3 crews

of alarms are real faults 6%

Raw critical alarmsNortheast · last three hours312100%

After de-duplicationone per element per window4715%−85% · flapping elements re-raising the same alarm

Distinct faultsclustered by shared signature196%−60% · 88% share one signature on Norvex's 5G NR estate

Carrying subscriber impactfallback or complaints on the same district31%−84% · the only three that justify a crew in the latest hour

Every row above the last is a crew that would have been dispatched for nothing.

WHERE IT IS · Critical alarms by district × element type

5G NR radioTransportCorePower

New York942221

Queens711910

Staten Island492031

Northeast · rest6423

Three adjacent districts, one element type. Core and power are quiet, which rules out a site-infrastructure cause.

WHY IT MOVED · 312 raw alarms, resolved to their sources

Raw alarmsElement typeRoot fault

88% of the storm is one signature across 19 sites. Triaging by alarm count would have started on the 37 that need nothing.

What the connected view adds

The NOC sees an alarm storm and triages by volume. De-duplicated and clustered by element type and vendor, the storm resolves to 19 sites with one signature — and joining care and usage shows subscribers are already feeling it, which changes the priority.

So what

Treat this as one fault on 19 sites, not 312 tickets. The clustering points at a shared element type across the Norvex estate, and the low clear rate says it will not resolve itself. Dispatch against the 19 sites in fallback-impact order rather than alarm-count order, because that is the sequence that restores subscriber experience fastest — and tell care to expect data-speed contacts from those districts today.

The points that matter

312 alarms, 19 faults

De-duplicated per element and clustered by signature, the storm is one problem on nineteen sites.

19sites

One vendor's estate, not the region

Other vendors' equipment in the same districts is unaffected, which localises the cause to an element type.

flatother vendors

Subscribers already feel it

5G→4G fallback up 2.7× and data-speed complaints rising in the same three districts.

+2.7×fallback

Questions it already answers

Which of the 19 sites should be dispatched first?

Ranks them by subscriber fallback impact rather than alarm count, so the dispatch order restores experience fastest.

What can this not tell us?

Not the hardware or firmware root cause — that needs the vendor's diagnostics. It establishes the shared signature, the affected estate and the subscriber cost.