Network Anomaly and Outage Intelligence
One network fault can generate hundreds of alarms as its effects travel through connected equipment. Conversely, one unusual metric may reflect a planned configuration change rather than a fault. Engineers therefore need a supported incident hypothesis, not a longer alarm list.
Marketways connects alarms with topology, operating state, configuration, maintenance and customer impact. The resulting incident case helps engineers decide where to investigate, which service requires protection and when an automated response must stop for review.
Distinguish an alarm from a fault
An alarm reports that a device or system observed a defined condition. It may identify the initiating failure, a downstream effect, a duplicate notification or a temporary state that requires no intervention.
Marketways defines the alarm sources, meanings, timing and dependencies before designing correlation. We preserve the raw evidence while grouping notifications that plausibly belong to one incident. This distinction reduces noise without deleting signals that engineers may need later.
Reconstruct propagation through topology
An upstream power, transport or control failure can affect many dependent nodes. Alarms from those nodes may arrive at different times because detection and transmission delays vary.
Marketways maps physical and logical relationships, redundancy and service routes. We combine topology with the temporal sequence to identify plausible propagation paths and candidate initiating nodes. The analysis remains explicit about stale or missing topology because an incorrect map can create a confident but wrong explanation.
Establish normal behaviour for each operating state
Traffic, latency, utilisation and error rates vary by hour, location, service, demand and configuration. One fixed threshold may produce continuous alerts during a predictable peak and miss deterioration during a quieter period.
Marketways develops baselines for relevant network states and peers. We separate changes in level, trend, variance and relationships between metrics. An anomaly means that the observation differs from the applicable operating pattern; it does not by itself prove a fault.
Account for planned and recent change
Maintenance, software release, routing change or customer migration can produce unusual metrics and alarms. If the incident system ignores these events, engineers may investigate a planned effect while a genuine fault develops elsewhere.
Marketways joins change and maintenance records to the incident chronology. We test whether the timing, scope and expected effect of a change explain the observation. A declared change is not accepted automatically: the observed pattern must still fit the approved change and remain within its service conditions.
Rank incident hypotheses without declaring root cause
Topology, sequence and metric contributions can rank the components most consistent with the evidence. The ranking directs investigation, especially when many nodes report related symptoms.
However, several mechanisms may produce the same pattern, and the available telemetry may omit the initiating event. Marketways presents the evidence for each material hypothesis and identifies the observation that would distinguish them. Engineers verify the cause before a consequential intervention.
Prioritise customer and service consequence
A technically severe fault may affect a protected route with no visible service loss. A smaller fault may interrupt a critical customer, emergency service or location with no alternative path.
Marketways links the affected topology to services, customers, commitments and redundancy. Priority combines likely mechanism, current consequence, deterioration risk and available response. This prevents alarm severity from substituting for business impact.
Detect weak signals before an outage
A developing microwave link, power or equipment condition may alter several metrics before it crosses a conventional alarm threshold. No single change may appear material, but the joint pattern can differ from comparable healthy operation.
Marketways tests multivariate and topology-aware detection where the data supports it. We evaluate warning lead time, stability and false alerts across operating states. The detector provides time for investigation only when engineers can understand the contributing signals and act before service fails.
Build an incident case that engineers can inspect
Operators need more than an anomaly score. They need the affected nodes, relevant metrics, changes, tickets, service impact, competing explanations and recommended evidence to collect next.
Marketways designs the incident object and chronology around that decision. Every conclusion links to its source and time. The case records uncertainty and contradictory evidence so that handovers do not turn a provisional hypothesis into an accepted fact.
Use Agentic AI for bounded incident coordination
An Agentic AI workflow can retrieve authorised alarms, topology, tickets and changes, assemble the incident case and route it to the responsible team. It can monitor an approved recovery sequence and update affected teams from verified evidence.
Marketways limits the agent's tools, configuration rights and declarations. The agent cannot execute a risky network change, suppress unexplained evidence or declare restoration without the required verification. Tool calls, decisions and escalations remain traceable.
Test cascading, ambiguous and missing-data conditions
A useful evaluation must reproduce the situations that make network diagnosis difficult. These include alarm storms, flapping signals, simultaneous faults, stale topology, missing telemetry, unavailable tools and a planned change that resembles failure.
Marketways measures incident grouping, missed faults, false cases, candidate ranking, warning lead time, restoration and customer impact. We also test whether operators can challenge the system and recover when its preferred hypothesis is wrong.
A transport failure illustrates the diagnosis
Suppose several sites report access alarms while latency rises on a shared transport path. A software change occurred in the same region, and one site already had intermittent power.
The incident case would group signals by topology and time, test the expected effect of the software change, and preserve the power condition as a competing explanation. Customer routes and redundancy would determine priority. Engineers would receive the evidence needed to verify the initiating fault rather than hundreds of independent tickets.
How Marketways develops outage intelligence
Marketways combines Risk Detection, Predictive Maintenance and Reliability and Anomaly and Novelty Detection. We map topology and operating states, correlate alarms, rank supported hypotheses and connect each incident with service consequence and accountable response.
The result tells management which signals require investigation, which customers or services face risk and where automation may coordinate response without replacing engineering verification.
Related guides and evidence
References
- A Model-Based Survey of Alert Correlation Techniques
- A Survey of Fault Localisation Techniques in Computer Networks
- Proactive Microwave Link Anomaly Detection in Cellular Networks
- Efficient Alarm Behaviour Analytics for Telecom Networks
- Topology-Aware KPI Anomaly Detection and Root-Cause Node Localisation