Why you should care about standards for the Telco edge cloud
If you are a fan of distributed computing, these are heady days. In IT, cloud computing, as well as telecom, distributed Edge seems to be THE topic of conversation. Not surprisingly, web-scale cloud providers have taken the lead in enabling edge, with Microsoft (Azure IoT Edge, Azure Stack), Amazon (Greengrass, Outposts), Google (Cloud IoT Edge, Edge ML, Edge TPU) all out with offerings – some (like Azure’s) rather mature, others in an early stage.
On the telecom side, edge computing is viewed as a key enabler of 5G. Many of the applications that the 5G network is designed to enable require edge presence to either work at all, or work in an efficient, scalable – i.e. economically feasible – manner. As Chair of ETSI MEC (Multi-access Edge Computing) group, this is a space which is near and dear to me and which we shall focus on in this article.
At this point, you may wonder, “what is ETSI MEC and do I even care to wait for the answer;” or perhaps “why focus on telecom; edge computing is edge computing.” If you are more knowledgeable about the telecom industry you might even sigh, “here we go…, ETSI… shmETSI…, all that telco stuff; everyone knows the web-scale guys will just take over – why wouldn’t one just use the cloud technologies they already have? After all, it is edge cloud! And these guys know cloud better than anyone.” Well, you may turn out to be right, but even if you do, the cloudification of telecom edge is a much more complex undertaking.
To understand why this is, let’s start with what the web-scale offerings today do well. In one word, it’s Enterprise. As the names of some of the offerings suggest, the initial use case for many an edge cloud has been, and remains, IoT. More specifically, low-footprint compute capabilities, which owners of IoT devices can use to perform simple functions such as data filtering or simple inference, as part of a larger IoT application (much of which presumably runs in the provider’s public cloud). However, the owner/operator of the IoT deployment own the equipment on which the IoT Edge runs.
As the use of these “IoT Edge” offerings increased, it became apparent that the IoT Edge cloud systems can be used to run other, non-IoT workloads, provided these have a sufficiently small footprint and can be deployed using the PaaS/FaaS capabilities that the “IoT Edge” cloud platforms offer. Still, the application provider is the same as the owner/operator of the Edge Cloud. Finally, in some cases, extensions of full cloud platforms to the edge are available – through Azure Stack or AWS Outposts – under the assumption that the cloud users are also equipment owners.
Clearly, I am trying to highlight something here – the offerings from the web-scale cloud providers all assume that the entities which offer their Edge cloud services are the same as those using them. When your target customers are enterprises this makes a lot of sense.
Telco are, however, not enterprises - or rather not enterprise IT departments. These differ in two important aspects. First, the Telco edge cloud is meant to be public and global (or nationwide). Many applications that will run on it will be third party applications. Second, the telco applications that communication service providers (CSPs) are likely to run on their own edge clouds are anything but enterprise or traditional IoT applications.
Let’s dispense with the latter point first. Imagine you are running an application on the edge and it fails. No problem, your load-balancer moves the requests to another instance somewhere else and a few seconds later you are back up. Except that the application happened to be handling traffic (!) for 911 calls during an emergency (ergo the outage). During the few seconds it took you to fail over to another instance 1000 of these calls were dropped. Your CSP employer is now subject to regulatory reviews, potential lawsuits, bad publicity, etc.; and you, as the manager responsible for the cloud design, are out of a job. Thus the need for network function virtualization (NFV). Telco “applications” – or more precisely Virtual Network Functions (VNFs) – are nothing like enterprise and IoT applications. How we architect and run clouds to support these needs to be completely different. And telco edge needs to be able to support VNFs.
Let’s now return to the public aspect of telco edge and the impact this has on running your plain old vanilla cloud apps on behalf of third parties. Doing so requires the ability to answer a number of questions. For example, when should I deploy an instance of app “A” on a particular edge cloud “alpha.” Simple – when there are users of app “A” that are proximate to “alpha.” But who are these users? How do I know when they are proximate, especially when “proximate” needs to refer to network topology and latency, not geography? Oh yeah, these users use cell phones, which means they move. Here now, gone ten minutes later. Should I still run (and pay to run!) my edge instance on “alpha” – edge cloud resources are likely to be rather scarce, thus expensive.
Telcos, with information they possess about their networks, are well positioned to answer such a question, but think about doing it “over-the-top” as you would have to do with a cloud provider. Azure IoT Edge, for example, while providing significant data management and processing capabilities, contains no real services for device discovery. You manually register “your device” to “your IoT Hub.” This does not work with mobility, nor does it really scale, nor is it clear what “your IoT Hub” means in a telco Edge. There are many such questions: ones that are easy to answer in a static, private edge network, but become hard in a dynamic mobile public one.
So, let’s recap.
Why wouldn’t the web-scale cloud providers just take over the telco edge? Well, they might – I don’t really know. The point is though whoever wins in the telco edge will have solved some really difficult problems that the web-scale providers do not have solutions for today (and don’t need to for their enterprise customers!) I will say that while web-scale cloud providers are better positioned to answer some of these, CSPs are better positioned to answer others. And so, the race is on!
Why do we need all this telco, ETSI-shmETSI stuff? Because the needs of a mobile, large-scale, dynamic public cloud edge capable of running VNFs really are different.
And finally, then, “what is ETSI MEC and do I even care to wait for the answer?” ETSI MEC is a collection of standards – or a group that develops these – that aims to standardize how CSPs expose key services to application developers/provider in a telco Edge and how the CSPs manage these applications when they run on telco edge clouds. This is what ETSI MEC meant in its recent press release (https://www.etsi.org/newsroom/press-releases/1567-2019-03-etsi-multi-access-edge-computing-releases-phase-2-specifications) when it referred to “… the implementation of MEC applications as software-only entities that run on top of a virtualization infrastructure, which is located in or close to the network edge."
And you should care, because unlike web-scale cloud providers, no CSP has a global reach. Yet, application providers need to be able to reach essentially all of their potential user base – and thus they must be able to work with many, nay all, CSP providing services in the geographies where the applications are available. And if these CSPs do not expose their services in the same way – i.e. if the service interfaces are not standardized – the whole thing just doesn’t scale. Such standardization is the value that ETSI MEC provides.
Alex Reznik is an HPE Distinguished Technologist, currently driving technical customer engagement on Hewlett Packard Enterprise’s telco strategic account team. In this role he is involved in various aspects of helping a Tier 1 telco evolve towards a flexible infrastructure capable of delivering on the full promises of 5G. Since March 2017, Alex also serves as Chair of ETSI’s Multi-Access Edge Computing (MEC) ISG – the leading international standards group focused on enabling edge computing in access networks. Prior to May 2016 Alex was a Senior Principal Engineer/Senior Director at InterDigital, leading the company’s research and development activities in the area of wireless internet evolution. Alex earned his B.S.E.E. Summa Cum Laude from The Cooper Union, S.M. in Electrical Engineering and Computer Science from the Massachusetts Institute of Technology, and Ph.D. in Electrical Engineering from Princeton University. He held a visiting faculty appointment at WINLAB, Rutgers University, where he collaborated on research in cognitive radio, wireless security, and future mobile Internet. He served as the Vice-Chair of the Services Working Group at the Small Cells Forum. Alex is an inventor of over 150 granted U.S. patents and has been awarded numerous awards for Innovation at InterDigital.