If edge computing is going to happen, something has to initiate a model and drive/fund its deployment. There have always been three applications associated with the edge; 5G hosting, IoT, and (recently) metaverse hosting. My view from the first was that 5G hosting could provide an initiation kicker, but NFV is barely aligned with current cloud-think, and it doesn’t take any useful steps to create a unified edge architecture. One or both of the other two would have to take our vision of the edge from something NFV-ish to something that could be exploited by other applications in the future.
The challenge with the edge lies in that transition. We need a model of edge computing that could serve to support application development. In effect, what we need is a platform-as-a-service (PaaS) specification that defines the service set, the web services, that edge applications could call on. If this service set supported 5G hosting fully, and could also support IoT or metaverse hosting, then 5G deployment could pull through edge infrastructure that could serve other compute missions effectively.
The challenge with that is that we don’t really have a PaaS definition for either IoT or metaversing, and if we assume that these applications evolve independently, it’s almost certain that what we’ll end up with is two definitions. Would it make sense to try to formulate a single PaaS? If so, then it would make sense to try to converge the drivers in some way. I propose that we do that by considering the metaverse-of-things. MoT might be the future of the edge, and some may already realize that.
A metaverse is an alternate reality in which people and other objects/elements are represented by avatars. In some cases, the other elements may be totally generated by the metaverse software, what the old world of Dungeons and Dragons called “non-player characters” or some of the characters in computer gaming. In some cases, as with the avatars representing real people, the metaverse elements are synchronized with the real world. The metaverse software, hosting, and networking framework has to accommodate this high-level mission.
How different is this from IoT? That depends on how you look at an IoT application. One way, perhaps the dominant way in play today, is to view it as an event processing or control loop application, but there’s another way, and signals that this other IoT model is gaining traction can be seen in recent market events.
Look up “digital twin” on a search engine and you get a lot of references. In simple terms, a digital twin is a computer representation of a real-world system, a graph of relationships and interactions that model an actual process or ecosystem and that, by modeling it, facilitates the understanding of the real world. The elements of a digital twin have to be synchronized in some way with the real-world things it represents, something that can be done for statistical-type twinning by drawing from databases, or for real-time twinning through IoT.
It’s hard not to see the similarity between the concept of a metaverse and the concept of a digital twin. In the end, the difference lies in where the real-to-virtual link occurs. In the metaverse, it’s the people who use it who are the focus, and it’s their behavior that’s mirrored from the real to the virtual world. In IoT, the goal is to create a virtual model of a real-world system, like an assembly line, and sensors link the relevant conditions of the elements between the rel and the virtual. If we generalize “metaverse” to include any virtual world with a link to the real world, that single model fits both missions.
Since the value of edge computing lies in its ability to reduce process latency, which is something necessary in at least the Meta version of a metaverse and in IoT as well, it seems to me that we could indeed call an IoT digital twin a metaverse-of-things, or MoT. That then could allow us to frame a common PaaS to support both the primary drivers of edge computing at the same time, increasing the chances that we would be able to realize new opportunities from the investment in metro hosting that 5G could deliver.
As I see it, MoT’s PaaS would have to be about avatar manipulation, but the avatar could represent not only a live person/inhabitant, but also a physical object. An avatar would then be a software object that presented a series of APIs that would allow it to be visualized (including changing its representation at the sensory level), let it synchronize with real-world elements, let it bind to other objects, and so forth. The MoT PaaS would provide tools to facilitate the avatar’s use, and developers of a metaverse would use those tools to create it. Similarly, IoT developers would build digital twins using the same tools.
I envision the APIs involved in a PaaS and also a MoT application as supporting events, meaning messages or simple signals. An avatar, sending a “show” message to the PaaS service to render an avatar, would then represent the avatar in the way it was designed to be visualized, in the frame of reference in which it currently appeared. That frame of reference would depend on where the avatar’s real-world twin was, where the viewer was, and so forth.
Issues of connectivity would be resolved inside the PaaS, not by the applications using it. All avatars would “inhabit” a virtual space, and coordinating their interactions both in that space and across the real-world facilities where the avatars’ twins really lived, would be done within the platform. Network and hosting details would be invisible to the application, and to the real-world users, providing that hosting and connectivity were designed to meet the latency requirements of the mission, meaning the service the MoT is representing. Just as the cloud abstracts what we could call “point hosting” of an instance of software, MoT PaaS would abstract the way a distributed twin of the real world maps in one direction to what it represents, and in another direction how it’s hosted and connected.
MoT would also support what I’ve called “contextual services” in past blogs, services that represent not so much “virtual” or “artificial” reality but augmented reality. The metaverse of 5th Avenue in New York, for example, might contain objects representing each building, shop, restaurant. Each would have a property set that described what was available there, and a real person walking the street (with AR glasses, of course) might see indicators showing where things they were interested in or looking for might be found. The same mixture of real and virtual might be used in a new model of collaboration or hybrid work.
The question that remains is how MoT could fit with 5G. The easy way out, which may or may not be the best way, would be to say that MoT is “edge middleware” and that 5G depends on “NFV middleware”. That would mean that edge computing is standardized really only at the resource level. This means that early 5G work would do nothing to harmonize the implementation of MoT, or of the general metaverse or IoT missions. That gives us less technology to leverage as more applications develop at the edge, and more risks of creating silos.
The better way would be to think of 5G elements as a metaverse, with the elements each contributing their digital state to their virtual equivalent. Then the deployment and management of 5G could be handled the same way as it would be in the other MoT applications. That demonstrates, I think, that there’s a considerable value in thinking the MoT concept through, in generalizing the metaverse model to apply to all edge missions if possible. If we do that, we’re advancing the cloud and the network together.
This poses a threat to operators, largely because they’re unlikely to play any role in developing the MoT PaaS, and will instead rely on vendors. Not only does that cede a big piece of their future success to others, there are precious few “others” in any position to do anything for them. If cloud providers like Amazon define NaaS, it’s not only going to hurt operators, it will hurt those who hope to sell to them. If Amazon’s moves become clear, then vendors are likely to be hopping to counter public-cloud dominance. Obviously, that’s a tidal wave you’d like to stay out in front of.