Beyond Anomaly Detection

“The server has restarted because the weather has changed.”

Every telecom engineer has experienced the moment when a network incident begins and the search for an explanation starts. A signaling anomaly appears, unexpected messages suddenly begin propagating across service nodes, and an analytics engine immediately announces that it has found the cause. The explanation sounds convincing. It is supported by graphs, timelines and impressive correlation scores. There is only one problem: it explains the incident by pointing to something else that happened around the same time. The timing may match perfectly, but the evidence is missing. That is a little like claiming your car will not start because your neighbor painted their house.

Yet, interestingly, the weather could be the cause. A hurricane, for example, might dramatically change how people behave: thousands may simultaneously seek information, check travel arrangements, contact family members, or access emergency services. The resulting surge in requests could overwhelm a service, trigger abnormal signaling patterns, and ultimately cause a server to restart. The difference is not the weather itself; it is the causal chain connecting the weather event to the observed network behavior.

This is where anomaly detection, causal modelling and evidence come together. Anomaly detection tells us that something unusual has happened. It does not, by itself, tell us why. Causal modelling allows competing explanations to be evaluated against the available evidence, while statistical inference quantifies how strongly that evidence supports each explanation. The result is not simply a correlation, but a reasoned hypothesis: the weather event caused abnormal user behavior, which increased demand, which changed signaling traffic, which overloaded the service, which ultimately caused the restart. Every link in that chain can be challenged, tested and supported (or rejected) by evidence. This distinction is fundamental: the goal is not to find a story that fits the data, but to establish which story the data can support in a fully defensible way.

This blog takes that distinction into the world of mobile core networks, exploring how anomaly detection, causal modelling, and evidence-based reasoning can work together to move from “something unusual happened” to “this is what the evidence tells us happened.” While the discussion focuses on SS7 networks and the Mobile Application Part (MAP) protocol, the same approach can be applied across all generations of mobile networks and signaling protocols, including Diameter, HTTP/2, DNS/ENUM, and SIP.

Anomaly Detection

The first step is to detect anomalies at the level where signaling behavior happens: in our case within the individual SS7 transaction. In the telco industry, this is closely related to Category 1 attack protection, where the objective is to identify abnormal messages propagating through the SS7 network. Each transaction can be represented by a sequence of transaction features, for example, the originating subsystem number and the destination subsystem number (both representing the node type), the application context, and the command code. Rather than treating these values as independent fields, the analytics preserve their order and relationships in a sequence-aware model. For this purpose, a custom trie is often fully sufficient: it represents the sequences observed during training and can determine whether a new transaction follows an established path. If the complete sequence is known, the transaction is considered nominal. If the sequence is unknown, the trie can do more than simply raise an anomaly flag: it can identify the precise point at which the observed sequence leaves the known behavioral space. For example, communication between the originating and destination node types may be perfectly valid, but the application context may not be supported for that communication; the same may then apply to the subsequent command code. The diagrams below depict such nominal (left) and anomalous (right) datapoints.

The failure point in the anomaly provides an immediate and explainable description of what is anomalous, without yet making any claim about why it happened. This is where causal modelling comes into play. Our next approach builds on Category 2 attack protection, where the objective is to identify an abnormal behavior associated with a specific identity such as user or, in our case, a network node.

Causal Modelling

The next step begins with an anomaly detected by cluster model inference. For each node type such as the Home Location Register (HLR), the model represents the composition of signalling traffic by capturing the relative proportions of configured traffic types. A shift in this composition immediately raises an interesting question: is the observed deviation still a variation of normal behaviour, or is it the first indication of a genuine change driven by a known cause? Consider a vector that has moved towards the edge of a learned cluster, with its membership strength becoming weak enough to trigger an anomaly. The diagram below depicts such an anomaly.

Statistically, the observation is unusual, but unusual does not necessarily mean abnormal. This is where causal modelling takes over. Rather than treating the anomaly as the conclusion, the model evaluates configured cause drivers, for example, a profile cleanup task, and asks whether the observed shift in traffic composition is consistent with the behaviour that such a cause would be expected to produce. The objective is not simply to detect that the network has moved, but to determine whether there is sufficient evidence to explain why it moved, while preserving the uncertainty between legitimate variation and genuine causal drift.

In this example, the causal model adds a second judgement to the anomaly detection result. Although the anomaly detection model has flagged the observed traffic composition as unusual, the causal model currently considers expected behaviour the most probable explanation, with a probability of approximately 42%. The system therefore does not automatically turn every detected anomaly into an incident. Instead, it asks whether the observed deviation can still reasonably be regarded as normal network behaviour. Here, the model favours that interpretation, but with high uncertainty. This gives the operator a meaningful choice: dismiss the anomaly as an acceptable variation or investigate the competing causes. Among the configured causes, profile cleanup is currently the strongest alternative, with a probability of approximately 29%.

The evidence for this assessment comes from the directional signature of the observed change. The observed composition shift is matching the configured signature for profile cleanup. At the same time, the observed shift remains compatible with the learned range of expected behaviour. The model therefore cannot defensibly attribute the deviation to profile cleanup; it can only identify it as a plausible competing explanation. This is where evidence-based reasoning becomes operationally useful. The outcome is neither simply “anomaly detected” nor “profile cleanup caused the anomaly.” Just as a server outage cannot be attributed to a change in weather simply because the two occurred at the same time, a traffic anomaly should not be assigned a cause without supporting evidence. In this case, the conclusion is: “An unusual traffic composition was detected, but the current evidence is more consistent with expected behavior; uncertainty remains, and profile cleanup is a plausible alternative explanation.” The operator can then accept the behaviour as normal and, where appropriate, incorporate the observed range into the cluster model, or investigate the competing causes because the evidence is not yet sufficiently conclusive. In this way, the system does not replace operational judgement; it provides a statistically grounded basis for making it.

The second inference depicted below shows how the same causal model behaves when the evidence becomes much stronger.

The traffic composition has shifted markedly with directional pattern closely matching the configured signature of a mass profile update activity, and the causal model therefore identifies increased administrative subscriber profile updates initiated from the HLR as the most probable cause. Unlike the previous example, the competing explanations are no longer similarly plausible: the model has low uncertainty and a clear causal preference. This gives the operator a much stronger basis for action, for example, reviewing subscriber update volumes, provisioning or batch processes, and recent administrative changes to confirm that the observed activity corresponds to an expected operational procedure. The important point is that the system has moved beyond detecting that the traffic is unusual: the observed anomaly now has a clear, evidence-supported explanation.

From Evidence to Action

Once the evidence has been collected and a causal explanation has been assessed, the next step is to decide what should happen operationally: should the event simply be reported, should an engineer investigate it, or is there sufficient evidence to take action? A dedicated orchestrator can make that decision by combining the strength of causal inference with operational risk and predefined guardrails. High confidence, low posterior entropy, a clear margin between the leading cause and its alternatives, and a low-risk action can provide the basis for controlled automated intervention, provided that such an operation is explicitly permitted within the configured policy. The response might range from generating an incident report, to re-provisioning subscriber data, adjusting a configuration, or scaling and redeploying a service with additional resources or pods. The important principle is that operational efficiency does not come from removing human judgement, but from knowing when the evidence is strong enough to act safely. The result is a closed operational loop in which detection, causal reasoning and action remain connected, while every decision is supported by evidence, bounded by guardrails, and therefore defensible.

Summary

Telecom networks do not need more black-box answers, they need evidence they can trust. This approach connects sequence-aware anomaly detection, statistical modelling, causal reasoning and controlled operational action into one transparent chain, turning unusual signaling behavior into defensible decisions. For communication service providers looking to move from monitoring and alarms towards explainable, efficient and increasingly automated network operations, this provides a practical path from detecting what changed to understanding why and deciding what to do next. Contact us to explore how these capabilities can be applied to your network and operational environment.

About Titan.ium

Titan.ium is a leader in signaling, routing, subscriber data management, and security software and services. Our solutions are deployed in more than 80 countries by over 200 companies, including eight of the world’s top ten communications service providers.

Titan.ium began its cloud-native journey in 2019 with the introduction of its Titan.ium cloud-native platform. In 2026, Titan.ium’s cloud-native portfolio includes several 5G network functions and numerous legacy network functions that have transitioned to cloud-native to address immediate market demands. At the same time, we continue supporting the Titan virtualized platform that can also be deployed on physical servers. This gradual shift enables communication service providers to harmonize their infrastructure while ensuring continuity.