The real change that the Internet brought about, in network service terms, is a shift from human consumption of connectivity to human consumption of applications through connections. If low-latency services are the future of telecom, then what do the “services” serve, in terms of applications, and how do the applications develop? That’s the key question that any talk of a new telco spending initiative has to answer, so let’s try to answer it based on carrier comment.
First, the only low-latency services that telcos themselves mention are those related to some form of real-time process control. Process control means control of things that take action in the real world, that do things. This category divided into two main segments—processes bound to fixed machinery and processes linked to mobile elements, which might be mechanical, human, or both. There is general agreement among telcos that bound processes are not likely to generate real-time service opportunities for them unless mobile elements are introduced in some way, so it’s fair to say that mobility of process elements is an essential feature of applications that credibly consume low-latency services.
The challenge with mobility is that there’s an inverse relationship, generally, between the latency requirements and the geographic scope of the process. The further a process is spread, the greater the mechanical delay associated with movement within it, and thus (if we neglect, for this discussion, the issue of autonomous vehicles, which we’ll get to later) the less valuable low-latency is. If I want to coordinate the dispatch of something between facilities that will take minutes or more to complete, there’s little to be gained by asking for it with microseconds-level latency. But if a process is confined to a single facility, the control of it can be locally hosted there, eliminating the need for a connection service, it’s practical to replace it with WiFi or private cellular.
Most process control apps, according to enterprises, are hosted on their own process controllers (which today are most often “embedded control” or “real-time” systems) local to the processes themselves. This is true of facility-mobile applications like warehouse stocking and removal, as well as bound processes, simply because it gives enterprises the most control and because the suppliers of the mechanical elements of these processes often also provide the applications and control hosting tools, which expect local connectivity. Telcos think that the evolution of these applications to include more mobile elements and greater geographic scope would create the opportunities for low-latency services, but enterprises are more skeptical.
This gets us to the notion of autonomous vehicles. Enterprises say that they would not expect to see the ROI in creating autonomous transport vehicles for passage between facilities absent any broad autonomous vehicle support. In most cases, the cost of a driver isn’t a large enough component of total cost of the process elements to make displacing human drivers worthwhile, especially given that it would mean replacing the current fleet elements. Today, they say, mobile process elements tend to be introduced into new facilities, as a part of the process of opening one and equipping it. Given that, it’s not surprising that enterprises suggest it could be smarter to aggregate related processes into a larger facility controlled by and connected with their own resources.
It’s hard to say how realistic this is, though. It is true that cloud computing is generally less economical than self-hosting; it justifies primarily where demand is too highly variable to permit cost-effective self-hosting. Might that also be true for edge hosting services, and thus justify low-latency connections to them? This is another place where there’s a diverging viewpoint in the market, this time both among telcos and among enterprises.
The “cloud-like-side” perspective is that if somebody deployed edge hosting, applications to exploit it would evolve. Absent the proactive deployment, there’s no reason for enterprises to plan such applications since they’d lack a mechanism to be run. The “cloud-unlike” perspective says that the cloud worked because self-hosting highly variable applications was the only option prior to the cloud, and so applications that could benefit from cloud hosting existed, latent opportunity for cloud services existed. A whole distributed and coordinated multi-process relationship would have to exist for a WAN service opportunity to host and connect their control existed. How would it be supported?
You can see sense, value, in each of these approaches, but I think you can also see that cloud hosting of highly variable application elements could be justified by simple economy of scale, but what about edge hosting? Real-time control is hard to “schedule” resources for. You have them or you don’t, and if you don’t what happens to the control process? This is way more complex to analyze, which is why there’s a debate.
Complicating the debate, for the telcos, is the issue of OTT competition, meaning at least the cloud providers but perhaps others as well. One telco planner told me that his company believes that electrical utilities and even local governments might get into the edge hosting business. The cloud providers have taken steps to make their cloud middleware tools available on customer-owned servers, which means that they can encourage enterprises to build applications around a cloud model, making them easier to migrate to future edge services. The same telco planner says that in any event, metro-level latency might well fit with current cloud hosting, at least for companies proximate to current cloud hosting points. In all, there’s a lot of credible competition for edge hosting, so why not let someone else do that, and simply connect that which emerges?
Because, others say, it might take a long time to emerge, time telcos might not have. Furthermore, since telcos have no experience with nor credibility in the application-hosting market, couldn’t those who develop it do so while minimizing the low-latency service opportunity? Chip improvements, in cost and performance, could well make it possible to build more intelligence into mobile devices, and we already know that autonomous vehicles that need connectivity all the time to stay operating pose a major risk that regulators could use as an excuse to bar their operation. How long until connectivity can be fully guaranteed, fully trusted, at any latency? My Internet was down yesterday for a brief time, long enough to have caused a lot of crashes or traffic problems.
I think we know that an event-driven, model (digital-twin-world-model) structure is what’s needed to make real-time process control work. I think we know that the components of the application would be functions whose input is the model-element needed and the event triggering it. I think we know that this makes the application naturally distributable, which means we can host a piece where the constraints like cost and latency are optimally balanced. What we don’t know is how this gets started so as to maximize the capabilities for all concerned, and since this future is an ecosystem as complex as any we’ve attempted to build, we need to get on the stick and figure that out.
