Should we look at 5G in terms of edge applications? If the big benefit of 5G is lower latency, then doesn’t it follow that new 5G revenues would likely be associated with those applications, which would have to run at/near the edge? What are those applications, how much opportunity could be associated with them, and what do they need beyond just 5G, especially in terms of edge computing? I’ve been working to model this out, and here’s what I’m finding regarding the popular, and the credible, options.
If you do a bit of media research, the number one proposed low-latency application for 5G is autonomous vehicles, so that surely qualifies it as “popular”. The presumption is that low latency is essential because any delay in having the automated driving system respond to pedestrians and other vehicles could literally be fatal. One of my LinkedIn contacts offered this: “In 2018, the Finnish Ministry of Transport and Communications justified the 5G construction strategy, e.g., assume that ‘every car in 2025 will generate thousands of gigabytes a day on the network’ and ‘one car will be equivalent to a thousand smartphone users’”. A Light Reading article had another view that I quoted earlier this week: said that latency could “turn streets of autonomous vehicles into a demolition derby.”
The connected/autonomous vehicle presumption ranks near the top of the nonsense predictions that plague popular discussions of 5G or edge computing. First, there is absolutely no credibility to the assumption that remote control of autonomous vehicles would extend to driving and avoiding obstacles. Every credible approach puts collision avoidance and situational awareness in the in-vehicle functions category. Second, even if we somehow made the terrible mistake of offloading it onto a network process, it wouldn’t require “thousands of gigabytes a day” of traffic. Even if it somehow did, there’s no way on earth that users would pay for that kind of connection, much less the processing resources needed to interpret the data.
But the final nail in this coffin is that hits this application is that smart vehicles can only be introduced as fast as new vehicles are introduced, even assuming that every new vehicle is made connected/autonomous. In the US, for example, we have about 282 million vehicles on the road, and we add about a million a year. That means the first year out, we have a max of a million vehicles involved, for which we must deploy infrastructure to connect them and guide them everywhere. Not to mention that they’re a drop in an uncontrolled vehicular bucket, a bunch of stuff that the guidance system doesn’t control, or even see.
Another popular justification is IoT, by which most people seem to mean smart homes and buildings. We need 5G and edge computing to control them, right? Well, a quarter of all homes, over half of all small business sites, and almost all multi-tenant sites are already “smart” in that they have central control over lighting and environment. What horrible deficiencies have we uncovered in serving this group that require 5G and edge computing to fix? Even mobile elements can be supported in-building using WiFi with some “roaming”, and 4G also works fine for these applications today.
This example of wrong-think stems from failing to recognize the difference between an application that could use a technology and one that would justify it. If we had ubiquitous 5G, could it be exploited for mobile IoT sensors, in public or private form? Sure, but would an operator or enterprise find that exploitation added so much value that it let the investment hit the ROI targets? Doubtful, and even if it did, there’s the question of how you synchronize the availability of 5G low-latency service and edge computing with the things that need it. Who builds applications for non-existent resources? Who deploys resources for non-existent applications? Who’s the chicken and who’s the egg?
OK, enough of the hype stuff. Let’s move on to things that could actually work. My goal is to explain some of that, and also explain why each misses the pitfalls that the popular applications fall into.
There are a host of uninteresting-sounding event-processing applications that relate to IT and networking themselves. Companies that have large data centers or a lot of distributed servers and network sites often look at automating operations. These applications are driven by event logs and management events, and some of them depend on having a real-time response to a change. This class of application is actually probably the largest real-time event processing load on public cloud event tools.
Amazon’s Wavelength, Microsoft Stack, and Google’s Anthos at the Edge are all public cloud extensions aimed at placing compute resources closer to events. In all these cases, the hosting is supplied by the user, and the cloud provider offers a way of extending cloud application and operations support (in some mix) to those user-provided hosts. As I noted in an earlier blog, the cloud providers are promoting this model to network operators, but the significant thing is that it makes “edge computing” something a user can adopt with their own resources. This could provide some ready applications that could become the basis for an edge computing service.
5G could enter into this because user-deployed edge computing might well be used where reliability of wireline connections is limited, and so a good-quality 5G backup would be useful. Useful, in fact, both for the applications that are using the edge computing, and useful in ensuring management systems and operations automation remain connected to the site, even if there’s a network failure.
A more interesting application is remote medicine, not to be confused with telemedicine. Telemedicine is typically a simple video link, perhaps augmented with some ability to do common tests like heart rate, blood pressure, and temperature. Remote medicine would add in more complex testing (EKG, ECG, blood tests) and also at least some form of robotic treatment or surgery.
What characterizes this application is the dependence on end-to-end latency, not just “local” latency. The presumption of most edge computing is that the control loop stays local to the event source. With remote medicine, you’re explicitly remote, meaning likely out of area, and so not only do you have to deal with traditional local latency, but with latency over the whole event flow and response.
This application can also be launched via an edge that’s really a locally extended cloud, like the three I’ve already named. That gives it the same easier on-ramp, since many communities (including my own) become what’s in essence a city-wide medical campus with a high concentration of facilities and services. Individual “edge-clouds” could be combined into a cloud- or operator-provided edge computing facility, and 5G might serve as a backup for connecting life-critical applications in the event of an issue with normal connectivity.
Gaming is in many ways related to this application, but I list it below remote medicine because it doesn’t have as easy an on-ramp. Massive multiplayer gaming (MMPG) is surely a global phenomenon, literally, and that means that there’s an enormous explicit latency associated with simply linking all the players, a latency that’s not addressable with 5G radio alone. What would be required would be a form of that end-to-end latency control needed for remote medicine, but it’s not clear that there’s a local enclave from which you could jump off.
Many gamers play with people they know, though, and there are gaming events that could reasonably spawn related local-community involvement. I think that it might be possible to promote an edge-centric coordination of MMPG, but it may require some technical changes. In any event, while there’s a natural centralized starting point for remote medicine, that’s less true for MMPG. On the flip side, there’s every indication that players would pay more for the service.
MMPGs essentially create a broad virtual geography in which players/characters move about. If communities of players congregate in a specific area, it’s possible that area could be controlled by an edge resource close to the players. The more concentrated the players were in real-world geography, the more likely this could be done, with the effect of enhancing performance of the game by reducing latency. This creates an interesting segue into the final topic, AR/VR.
By far the largest application of VR today is gaming, and gaming illustrates a real issue with both augmented and virtual reality, which is the synchronization of the movement of the head of the player with the virtual world seen by the character. A lag creates a very unpleasant sensation that a few find downright nauseating. While some of the lag is created by the process of creating the virtual vision itself (imagine a CAD system rotating a part, but in real time, in terms of the complexity of deciding just what the character would “see” looking in a given direction), some is also attributable to latency.
Because this problem is real in gaming even today, and because at least some gamers would pay for improved game performance (and the advantage it might offer them), this could be an on-ramp for the creation of a virtual reality view at the edge. My model says that gaming applications, virtual-reality real estate and holiday applications, and similar applications could generate just short of $75 billion in service revenues.
The question is whether it’s possible, and better, to push the creation of the view to the gamer’s own system. Obviously, a dedicated edge process to support a single gamer would be expensive, so again the utility and revenue potential for this may depend on whether communities of player could, by the position of themselves in the real world and their characters in the game, share a hosting process.
But now let’s look at the broadest, most extravagant, and most complicated application of edge computing, which is contextual services. This is a term I’ve used to describe applications and services that are designed to present information and visualization to a user based on specific real-world context, meaning where the user is, what they’re trying to do, where others are relative to them, and so forth.
Contextual services and applications have three components. The first is context management, which is responsible for knowing what a user is sensitive to or interested in, and detecting when anything that fits is within a defined “range”. The second is real-world analysis, which is the process of identifying the real-world things the user might see. This would likely require a combination of a highly accurate map, accurate user location data, how the user was facing, and what mobile elements were also in the area. The final component is contextual presentation, which is the way that contextual information is integrated with the user’s real world; how they are told about a contextual hit. There are essentially three possible high-level models of contextual services developing from these two components, and we’ll have to look at each.
The first model delivers contextual information without integrating it with the visual field of the user, meaning that no VR/AR is involved. If we were to apply this to a stroll through a shopping district, a user might get an audible alert and a message if they approached a store that had a deal on something they’d been shopping for. This still requires contextual integration but presentation harnesses available and well-known channels available on every smartphone.
The second model delivers contextual information in the context of a VR display. How much of the real-world view is used as the basis for the display depends on the application? For example, a remote medicine system might show contextual information that has nothing to do with what a doctor’s eyes might actually see, but it’s still visual. Think “computer display”. The problem with this is that if there’s no boundary on just what the “real world” is, meaning that it represents what the user’s own eyes would see without VR, just presenting that real-world base is complex, and overlaying contextual information on it means integrating the information with what’s at that place in the real world. A price over a shop door, perhaps?
The final model, based on augmented reality, is really designed to deal with that problem. AR presumes that the display is “see-through” so that the user will see the real-world baseline without any system support. The contextual augmentation is displayed as an overlay on that real-world view. There’s little difference in the challenge in creating the view because it’s still essential to be able to identify real-world objects, but limitations on the display quality are reduced.
I’ve worked for several years to lay out what the potential for this final application could be. It appears, based on my current modeling, that it could generate about $250 billion in service revenues when applied to worker productivity enhancement, and about $175 billion in service revenues when applied to consumer contextual applications. A sizeable component of the latter would be generated by sales/advertising revenues.
The point is that there are edge opportunities, and that if they were to fully develop, they could promote 5G. 5G and the edge, however, are not sufficient to create them. There’s a lot of software infrastructure needed, infrastructure for which we don’t even have an architecture to work from today. Don’t get too excited about edge and 5G, then. There’s a lot of work to do, and all the hype may be hurting efforts to get it done.