The Telco Digital Twin Problem: We’ve Modelled the Skeleton, Not the Whole Body

The previous article highlighted how my chiropractor taught me something I didn’t realise about telecoms. It then triggered another image in my head (the first diagram below), which we’ll discuss shortly.

We’re getting increasingly good at building digital representations (digital twins) of networks for assurance and AIOps. We can stitch together the various pieces of a network. Devices, topology, links, resources, etc.

But a telco ecosystem isn’t only the network.

If we genuinely aspire to achieve AO (Autonomous Operations), we need systems that can reason like our best operators, our telco ninjas, then the twin has to understand everything that our ninjas currently do. ie everything sitting above the network too.

That broader, interconnected model is what we call the telco twin.

.

The network twin is only the skeleton

When I talk about digital twins, my definition tends to be more expansive than many of the examples I read about in telecoms today.

A lot of current digital twin thinking is understandably network-centric. We’re building increasingly sophisticated models of physical infrastructure, logical networks, virtual resources, network functions, devices, links and their dependencies.

In the analogy from my chiropractor, those layers give us something like the skeleton and central nervous system.

They tell us a great deal about how the underlying body is constructed and connected.

But they don’t tell us everything we need to know.

Telcos already have extraordinary volumes of telemetry. Another alarm, event or metric doesn’t necessarily make diagnosis easier.

It’s rarely a shortage of network-related data these days. It’s more often a shortage of context.

.

The missing anatomy sits above the network

The missing parts of the telco anatomy or Telco Twin sit above the network (the full ecosystem stack represented by the blue ellipsis below), rather than just the network layers or Network Twin (orange ellipsis and call-out).

Those other layers are all the other connected tissue that impacts the health of your telco ecosystem – Virtualisation. Management systems. Platforms. Shared services. OSS and BSS. Applications. Services. Products. Users. Enterprises. Customers.

If we want a genuine telco twin, these can’t simply exist as separate inventories that happen to be queried separately and stitched together when required.

We need to understand their associations.

A customer uses a product. That product depends on services. Those services depend on applications and shared platforms. Those, in turn, rely on virtual and physical network resources.

The relationships work in both directions (ie service activation down through the stack, service assurance up through the stack, like in the diagram below).

• Starting with a customer problem, we should be able to traverse down through that graph towards potential technical causes (from north-to-south)
• Starting with a technical failure, we should be able to traverse upwards and understand which services, products and customers might be affected (from south-to-north)
• But we also need to understand the east-west associations (between domains, devices, systems, etc) as represented by the split parallelograms in the Logical Network Layer in the first diagram

We’ll get to why the extra layers in the knowledge graph matter shortly.

.

“What changed?” is often an important precursor to “What broke?”

There’s another, often overlooked, concept in the diagram that I think deserves particular attention: change management.

Anyone who has spent time around operational incidents knows how often changes of some sort are the precursor to an outage or degradation.

A software deployment. A configuration update. A network modification. A migration. A policy change. An OSS/BSS release.

The observed fault may be several layers removed from the change that caused it. Just like my sore wrist being caused by an issue under my armpit in the chiropractor story above.

That’s why I don’t think change management should simply be another dataset sitting beside the digital twin. Changes must be part of the knowledge graph itself.

What changed? When did it change? Which objects were touched? What depends on those objects? What happened before / during / afterwards? Which services and customers sit downstream?

This also means the telco twin needs something the human experts, our ninjas, have always relied upon: memory.

The current state tells us what the telco looks like now. History helps explain how it got there.

.

The real intelligence is in the associations

This is where I think the definition of a digital twin becomes important.

A list of separate objects isn’t really a twin. Not a valuable one anyway.

As we discussed in this previous article, “Is AI a digital transformation bridge or noose?” the greater the volume of associations in the knowledge graph, the greater the insights that can be derived from it. The downside is that all those extra associations are often really difficult to maintain!

Inventory tells us what exists. Network topology tells us how parts of the network connect.

But as we’ve discussed, the telco twin needs to understand much more: What depends on what? What changed? What happened previously? Which services are affected? Which customers are impacted and which don’t even care? What’s the potential business impact?

.

Autonomous Operations needs the knowledge of a telco ninja

Think about the people we turn to when the really difficult incidents occur. I call them our telco ninjas.

These ninjas don’t just know more commands or remember more alarms (not necessarily anyway). Their real super-powers come from having built a vast interconnected mental model of their entire telco ecosystem, not just the network.

They know what depends on what. They know which integrations are fragile. They remember what was changed recently, or can quickly figure out what the likely change was that led to the outage. They’ve seen similar symptoms before. They understand which applications, services and customers might be affected.

In other words, they’re carrying something remarkably similar to a knowledge graph in their heads.

If we want Autonomous Operations solutions to reason like those people, our systems need access to an equivalent (or better) knowledge graph.

AO won’t come simply from automating more tasks inside individual technology domains. They’re already quite robust anyway. AO will require systems capable of reasoning across those domains – from customers and products, through services and applications, all the way down to the network and physical infrastructure, with change and history woven through the entire graph. North-to-South. East-to-West.

The network twin is an essential part of that foundation.

But it’s still only the skeleton.

If we want to reproduce the diagnostic capability of our best telco ninjas, we need to model the rest of the body too.

If you’re thinking of developing a really advanced next-generation telco digital twin or AIOps solution or telco knowledge graph, I urge you to think of the layers above the Network Twin in the first diagram above.

Interestingly, some of our existing tools might already be a long way towards achieving this outcome. For example, the network inventory solution we use in our OSS Sandpit is already able to flexibly model almost any entity – anything that resembles a node or a connection – as well as lots of other associations. The underlying database might struggle a little with large volumes of real-time data (eg telemetry, logs, etc) though.

Alternatively, any AIOps solution that’s based around GNN (Graph Neural Networks) and topologies are a strong starting point, but might currently lack the data collection or logic to make decisions above the Network Twin layers of the ecosystem.

But clearly, and excitingly, we’re already well down the path towards a true Telco Twin.