Nokia is one of the companies who’s addressed the “digital twin” concept explicitly, and so when it’s Bell Labs group does a piece on digital twins in telecom, it’s worth a look. Operators have mentioned digital twins in my chats, too (53 of 88), so I have some comparative data to relate as well.
A “network digital twin” is a virtual representation of a physical network or a portion thereof. Operators tell me that they would likely deploy the technology in what we might call “administrative zones” corresponding to management/ownership scope, vendor, or other subdivisions of gear that could create real partitions that should be reflected in the virtual world too. The goal of the network digital twin is to provide “contextual system” views of a network, views that mirror the real relationship among elements and thus facilitate understanding and even simulating network-wide conditions.
The Bell Labs piece identifies 35 use cases for network digital twins, and my 53 operator chats on the topic validate 22 of them, but I think the whole list in the article is credible. The ones that operators missed from the list relate largely to the sales/design phase, and I think their omission is due mostly to the fact that my chats were focused on networks-in-being and operations missions.
I was impressed by the article’s recounting of an actual operator project analysis, which identified a potential savings of around 25% in opex. I only got impact comments from 29 operators, but their estimate of opex impacts ran from 20% to a third, so the project analysis fits in the predicted range overall. This combination of information is important in telco evolution, because cost management is critical in preserving profits when revenue growth is challenging because of limits in ARPU and TAM. Up to now, operators have done targeted opex projects that have been aimed largely at limiting interaction between craft people and customer problems, and that area has been (say operators) largely tapped out in opportunities for savings.
Network digital twins offer what’s essentially a horizontal look at the old FCAPS (fault, configuration, accounting, performance, and security management) story, a way to utilize a virtual model of a network at every step of the game. While the operators I’ve chatted with are still dominantly focused on response to conditions, it’s feasible to build a digital twin of a network that’s still in the planning stage, and to use that to refine capacity plans and simulate various operational states, then actually use the twin to commission real networks and offer real services.
One challenge for the whole network digital twin concept is shared by digital-twin technology in general; there’s no user confidence in the availability of a platform, tool, language, or whatever for use in building a twin. Only 9 operators indicated they were actively involved with the technology, and only 2 said they had it operational. None of the latter groups said their digital twin plans or implementations spanned their entire network, and all were currently focused (not surprisingly) on business services and business-specific infrastructure like carrier Ethernet access or MPLS VPNs.
In the group of 53 operators who commented on digital twins, 37 said they believed the benefits of narrow applications like this “would be limited”, but the seven who were looking at digital twins but had not yet made one operational all said they had narrow missions in mind. A big part of that seems to be related to a view that it’s easier to put the twin in place if the network isn’t yet built, because five of the seven had specific comments indicating their targets were greenfield infrastructure.
Among enterprises, things aren’t any better for the network digital twin concept. Out of 414 enterprises I chatted with on operations issues, only 22 mentioned network digital twins and none said they were deploying or even trialing them. I’ve had a few talk with me about blogs I’ve done on the topic, and that group points out that they don’t hear about the concept from vendors, and that they don’t spend a lot of time considering technologies that nobody seems to be trying to sell them. One reason why this few enterprises commented to me on blogs was to see if I did digital-twin integration, or had a reference supplier. That, to me, shows that enterprises don’t know how to go about network digital twin implementation.
Interestingly, over 50 enterprises are looking at digital twin technology in relation to IoT-oriented industrial/manufacturing or other missions. This group includes two who chatted with me on my blogs, and they didn’t mention their other digital twin missions in relation to their network digital twin interest. I asked about this, and they said that their IoT digital-twin stuff was being driven by the vendor/integrator who was working with them on the application, and in both cases this was a specialty partner and not one promoting digital twin technology broadly.
In a way, the situation with digital twins overall is similar to the situation with program languages used to build applications. There are a lot of applications and languages out there, and the former tends to be promoted by vertical-market integrators/vendors and the latter by nobody in particular. Microsoft’s Azure Digital Twins and AWS TwinMaker are the tools known to enterprises, and IBM’s initiatives are known to most of IBM’s strategic accounts, but all those who have evaluated any of these have done so in the context of IoT.
IBM has a nice tutorial on the IoT applications of digital twins, and you could easily apply the story presented to network digital twins, replacing IoT elements with network management APIs. The IBM comment that “Digital twins are benefitting from the fact that there exists an abundance of machine-generated data, which is a luxury that you don’t have in other data science disciplines” could surely be applied to network operations; in fact there’s probably more network status data and more control interfaces available than there are for most industrial/manufacturing processes. Why aren’t network vendors, particularly enterprise vendors, jumping on this?
Some are, sort of. Juniper announced a Marvis update to extend “AI-Native Digital Twin” capability. Cisco uses digital twin technology in its software update/distribution system. Extreme Networks may be the most explicit vendor promoter of digital twin technology, offering an actual implementation tool/process. Their promotion of the concept goes back to 2022, and they have the most developed online data on it. But so far, none of this from Extreme or Juniper has worked its way out into my chats with enterprises, and Nokia’s approach is the one operators cite. Extreme uses a lot of channel partners for their sales, and I wonder if perhaps the digital twin story is one that’s a bit too much education for most channel players.
I believe digital twins are essential for IoT, for network operations, and for the application of AI to real-world systems of any sort. I think vendors are coming to understand that, but the education process is only now starting to spread to enterprises and even network operators. I think that while network digital twins have almost-universal potential in both these groups, the fastest-growing area of interest is still in enterprise IoT applications, and perhaps this means that edge computing services aimed at IoT applications might translate into operator edge interest in a generalized IoT edge model, which might then spread into network digital twin applications more generally. It’s interesting to note that in the Digital Twin Consortium membership roster (as of today), none of the major network vendors are listed, including those I’ve cited in this blog. I think that if network digital twins are to gain broader support, getting key vendors on that list, and getting network missions worked on, may be essential.
