I’ve blogged about the way that a “metaverse of things” could provide the impetus for a new set of productivity-enhancing projects that would increase IT spending by increasing benefits. That’s fine for enterprises, but would the same approach (with MoT or something else) work for the network operators? It’s clear that 5G spending is tapering down, that 5G has failed to create a new wave of revenues for operators, and that 6G isn’t going to do that either. Ericsson and Nokia have both reported declines in sales, and pretty much the whole spectrum of equipment vendors have reported declines in sales to operators. Something is clearly needed, but what?
Answering that question is complicated, not the least because operators themselves don’t want to hear most of the answers. Higher-level services, what are now OTT services, have exploded while operator connection services have declined in profitability. Thus, it would make sense for operators to get into the higher-level service business. Try telling that to operators. Two thirds of them just don’t want to hear it and one third have no idea how to go about it. Even that one third would love to return to the thrilling days of yesteryear when the Lone Ranger of connection services rode tall in the saddle.
Of course, a back to the past strategy never works. What might work is a strategy that builds a new value for the old stuff operators are comfortable with. If you assume a static business case for the way networks are justified, there is no way you can increase operator revenue because users have no justification for the greater spending. In fact, they want to see costs decrease every year. So, you need to build a new incrementally more powerful business case. If we assume (and we have to assume something) that enterprises’ next big step is to harness real-time IT interactions through the digital twinning of real-world systems (what I’ve been calling the “metaverse of things” or MoT), then it might make sense to look at how MoT, or perhaps the “social metaverse”, could become the next big step for operators and their beloved connection services.
Definition-speaking, a metaverse is a computer model of a real-time system that mirrors or even creates interactions. In social-metaverse frameworks, the metaverse is a virtual location (my term was “locale”) where avatars representing distributed people are collected and are then used to create virtual interactions designed to be as realistic as possible. In the MoT framework, the metaverse is a model of a physical system whose operations can be monitored and even controlled by manipulating the model that represents them. In both cases, what we have is first and foremost software, and second a set of hardware and network resources needed to make the software work.
Today, the vast majority of MoT is based on on-premises industrial control elements, so any connectivity is local. There is therefore no real WAN dimension (mobile or wireline, VPN or the Internet) to the metaverse implementation. For operators to participate, they’d need to offer edge computing services to replace on-prem resources, putting them in the “carrier cloud” business that most appear to want to avoid.
For the social metaverse, the situation is very different. The goal here is to create a virtual community of people who are clearly not able (or willing) to co-locate for a physical gathering. By its very nature, a social metaverse has to rely on communication to synchronize the far-flung members with their avatars. There is an opportunity to provide low-latency connectivity in support of this, so there’s a way operators could profit from a broad social-metaverse success.
They could also profit from at least some MoT activity. While the vast majority of MoT is indeed connection-localized, there are already applications in verticals like utilities and transportation that demonstrate that MoT could be used to model distributed systems rather than just localized ones. Were that done, not only could these industries drive more stringent requirements for low-latency connectivity (because machine control loops are often shorter than human reaction times), they could seed distributed MoT in other industries. Think smart cities, which could be viewed as a community of connection-linked smart buildings.
Over the last year, I’ve blogged regularly about the challenges associated with synchronization of a social metaverse. The further apart community members are, the greater the “length of the control loop” that connects them to their avatars and the surroundings of the virtual locale they’ve chosen to inhabit. The latency or delay between the two creates issues in realism. We know from satellite telephony that a quarter-second propagation delay is sufficient to be intrusive. Experts in the metaverse space disagree on just how much latency could be tolerated, but the consensus is that it’s likely about a hundred and fifty milliseconds if you want to preserve the widest range of applications and the broadest range of user behaviors. Since there’s inevitably a processing delay associated with, for example, having your avatar know to reach out a hand to shake, it’s critical not to introduce too much network latency. Thus, metaverses in general may be the killer app for low-latency services.
Which is both good and bad. On the “good” side, it’s hard to plan services or service sales, or assess infrastructure needs and ROI, without any idea of what the applications of the service would look like. Saying that the metaverse is the app target solves that problem. On the bad side, saying you want a service to support the metaverse is like saying you want a bridge over a river in anticipation of there being a road to connect there. There’s a lot of work others would have to do to make a MoT-metaverse concept practical at the software level, and I’m not sure how much of it is really being done. At the social-metaverse level, the business model has to be validated and even Meta seems to be struggling to do that.
As a former software architect and programmer, I’ve decided to do some experimentation here. I’ve started work on designing a metaverse framework, one that makes social-metaverse and industrial/business metaverse applications of a common design. I’m freshening up my skills with the C++ programming language to do that, because C++ is a good language choice for object-oriented programming and I think MoT is an object-oriented application. I’m not trying to invent the future as a one-person job, but rather to gain a better understanding of what’s needed by laying out a basic implementation. I’ll blog on my efforts periodically, I promise, but in the meantime I can already see some helpful points about how metaverses could help operators.
Metaverses of any sort are real-time applications that have at least some control-loop constraints in maintaining synchronicity with the real world. They are also, because they are real time, event-driven and inherently asynchronous, meaning that events will come in at their own pace and will demand timely service. That means that events of any sort would have to be queued so that they’re not lost if they can’t be instantly processed, and that queued events would have to be steered to the proper process or process sequence for handling.
My early work on this suggests that the “front end” piece of the process, the event queue and the dispatching of events to the proper software element, is likely a single process. Events would be passed to model elements, some of which would represent real-world objects (avatars, machines, warehouse stock, etc.) and some of which might represent object collections (locales where virtual people congregate). These elements would be data structures that hold the information from the real world, and also a state/event table or graph that represents the relationship between object state, event types, and indicated software processes. These could, in theory, be shared across objects because they operate on the data structures that are passed to them; they’re “microservices” or “functions”. They could also be spun up, as noted, to replace a failed element or scale a process.
The challenge that creates is that the workflow, meaning the event flow, of the system has to be carried between elements that may no longer be co-located, which is clearly a network service mission, and be carried without interfering with control-loop requirements. This would suggest a kind of “function fabric host” not unlike the sort of thing that microservice mesh tools like Istio would create. The mission of connecting events and processes would thus be tied to the mission of hosting the processes, because you have to connect to something where it is, and the “where” has to be variable in real time.
To me, this suggests that the metaverse opportunity, whether it’s for operators or some other class of player, is a combination of network and hosting. It’s difficult to see how you could expect to have the two elements evolve from nothing (which is where we are today) to something helpful, in a vacuum. The challenge would be how you could avoid having the network piece of the puzzle commoditize in the same way that current connection services have commoditized. There’s also the chicken/egg problem. How can you justify deployment of low-latency services without the edge hosting framework needed; there’s nothing to connect. How can you justify building the hosting with nothing to connect events through it? Two parties, one network and one hosting, would have to commit together, or they’d have to be one party.
That’s the challenge for operators in addressing not only the metaverse opportunity, but the opportunity for any feature-differentiated new network service. What consumes it? How does that consuming mission develop without the service, and if it doesn’t what provides the service revenues? Operators may therefore have to accept at least some role in higher-level service feature deployments to validate any new and profit-generating connectivity services, whether they are comfortable with that or not.
Their vendors then need to get comfortable with those same new features and missions, even if they have the impact of driving market transformations that could change some network principles that have stood for decades. Might they? They almost have to, or the hoped-for impact of technology on telco profits can’t possibly materialize. We’ll look a bit deeper at that particular point later this week.
