While 5G deployment may be necessary for meeting consumer expectations it has become accepted wisdom that ROI (return on investment) can only be achieved through enterprise services as both smart phone growth and ARPUs flatten out. This has sharpened focus on ultra-low latency as one of the three primary use cases appealing largely to the enterprise market, at least in the short to medium term, apart from some gaming. But here there has been growing appreciation that ultra-low latency can only be delivered by 5G in concert with edge computing to bring both the data and processing closer to the user or application.
At one level this is not a problem, because the applications most demanding of low latency tend also to be local in nature or at least can be, such as autonomous driving, robotic collaboration and telemedicine.
However, problems can arise over cost. Edge compute requires investment, and while it is clear that would fall largely in the domain of the enterprise in the case of private 5G networks supporting industrial IoT (IIoT) processes on a factory floor, operators will also have to incorporate more IT equipment within their cell sites to offer ultra-low latency on a more generic basis. Furthermore, given that the edge has come to be recognized as an integral part of the 5G infrastructure, there is a need for it to be incorporated within the standardization process, to avoid proprietary lock in and duplication of effort.
At least that standardization effort now seems in good hands under the auspices of ETSI’s Multi-access Edge Computing (MEC) initiative, billed with harmonizing standards for edge computing generally but very much preoccupied with 5G at present. It is not the only show in town but has assumed the mantle of standards oversight, marshalling the various more 5G-specific bodies below it and aligning their efforts.
Broadly there are three other key groups here, 3GPP representing the mobile industry as a whole, GSMA for mobile operators in particular and 5GAA (Automotive Association) looking at aspects for connected vehicles given the great interest that sector has on convergence between 5G and the edge.
These are early days and only the basic requirements for standardized edge have yet been defined. So far 3GPP has been most active of these three groups through three related efforts. One is 3GPP SA6, which is defining an architecture called EDGEAPP specifying an enabling layer to facilitate communication between clients and applications deployed at the edge, covering discovery and interaction, exploiting the CAPIF (Common API Framework) as a common way of accessing APIs in the edge cloud.
Then there is 3GPP SA2 performing the corresponding architectural definition for mobile core networks including 5G, ordaining user traffic steering and routing to the appropriate application servers in the edge clouds. Thirdly there is 3GPP SA5, responsible for management and charging aspects of edge services, all-important for operators seeking that elusive ROI.
Then GSMA naturally is working on a unified platform that can help operators, collectively in many cases, make their assets and capabilities consistently available to both developers and enterprise clients across networks, and crucially national boundaries. This is currently at phase 1, focusing on federating multiple operators’ edge computing infrastructure to give application providers access to a global edge cloud to run distributed and low latency applications through a set of common APIs.
Finally, 5GAA is defining requirements for applications around the cellular V2X (Vehicle to Everything) 5G-based technology using MEC, in line with emerging specifications from ETSI.
Most recently, in September 2020, 5GAA released its ‘2030 Roadmap for Advanced Driving Use Cases, Connectivity Technologies and Radio Spectrum Needs’, which at this stage is largely a rallying call for automakers, mobile operators and infrastructure suppliers to engage more closely in developing a common digital ecosystem for automotive connectivity. A subtext here is that the 5GAA wants to expunge the alternative WiFi-related approach under the Dedicated Short Range Communication (DSRC) umbrella.
The major operators themselves do not want just to sit back and wait for standards so they are engaging in partnerships, in turn encouraged by the major cloud vendors. Amazon has been making some play here through its AWS Wavelength platform, a version of its wider AWS cloud environment comprising APIs, management console and tools geared specifically towards the 5G edge network. Verizon in December 2019 claimed to be the first operator to use AWS Wavelength for specific customers including the US NFL (National Football League) and game developer Bethesda, presumably for live streaming and remote gaming respectively.
Vodafone seemed just as quick off the draw in Europe, announcing collaborating with AWS to make AWS Wavelength available first in the UK and Germany, before expanding to other countries in the continent where its 5G network is available.
Google of course was not going to be left out and so it was not long before we heard of its collaboration with AT&T to use the latter’s network connectivity at the edge, with the announcement in March 2020 of as yet unspecified use cases. This extremely vague announcement gave a cue for stepping back and pondering just what is meant by the edge, which seems to mean different things depending on the associated vertical sector and the vantage point within the ecosystem.
Closer reflection reveals that the edge itself is not a clear line but more a distributed hierarchy comprising multiple layers whose proximity to the end user depends on the degree of latency required. In general, the closer the edge is to the consumer of the services or data, the more expensive it is. Therefore, to paraphrase Albert Einstein, the edge should be as close to the user as it needs to be, but no closer.
Applying that say to the automotive sector, it might seem that the edge would lie exclusively along major roads so as to be close enough to vehicles to support autonomous driving with its highly stringent latency requirements. But even autonomous driving does not need ultra-low latency for all its components, not for example in navigation where a few second delay can be tolerated. For delivery of infotainment a slightly longer delay still might be tolerated.
The same applies to the smart factory where process control requires ultra-low latency but say pro-active monitoring is more tolerant. Again then, there is a hierarchy of latency requirements.
Such a hierarchy is therefore being accommodated in the standards developments, leading to terms such as deep edge referring to the real periphery, which would be within cell sites for MNOs, along with regional edge serving a number of cells. Then there is the central edge, which sounds like an oxymoron, located within the data center, but still optimized to keep latency as low as can be reasonably achieved given the larger distances data has to traverse between the application and user.
These three layers then would each host services according to their latency needs. At the deep edge we would find autonomous driving control, robotic collaboration and telemedicine, calling for latencies in the 1-5ms range, noting that all these are localized anyway. Then at the regional edge we might host extended reality (ER) which would often need to operate over somewhat larger distances but can tolerate network delays in the 5-20ms range.
Finally, the centralized edge would serve applications such as office collaboration and videoconferencing, with network latencies in the 20-50ms range.
The application as a whole would have to tolerate slightly larger latencies than these network delays, which in the case of videoconferencing can be up to about 150ms, providing jitter or variation in delay is held within 40ms. This could be achieved certainly within continents but be challenging over longer intercontinental connections.
Users might object that the real network edge lies with their devices and not in the operator’s domain. It is certainly true applications that can run entirely in the device should do so, and then latency will not be an issue. But client devices lack the processing resources as well as battery capacity to run applications that are at all computationally demanding, which is one reason why a lot of the heavy lifting has to be devolved to somewherein the cloud in the first place.
This indeed points to one of the most promising generic, or horizontal use cases for edge computing, computational offloading. This of course has been happening since the dawn of mobile data, but until now latency has prevented offloading of real time applications that are at all delay sensitive.
The needs of computational offload are therefore being taken account of in the standardization work by the MEC. This covers how to make decisions over when to offload and then allocation of the resources in a fair and efficient manner. One question to resolve during this process is where the best place to execute the offloaded functions resides. The answer will depend on how low latency has to be, what resources are needed and where they are available, aiming to minimize both computational and bandwidth cost. The closer to the center the edge is, the more bandwidth will be consumed, but computational cost might be lower.
The precedent here has already been set in the world of content distribution, which has been devolved to edge caches to trade storage for bandwidth, as well as reduce latency, for some years. Distributed edge computing is an extension of that to include computation as well as storage, with a similar dynamic to the trade-offs and decisions that have to be made. In a sense then the case for edge computing has already been made and some of the underlying principles established.