Recently, one of the ETSI staff folks pinged me an e-mail that said, “Someone asked me ‘What is Edge’ and I could not quite reply. Can you help?” Well, come on! The answer is simple. 

Edge is… and this is where I got stuck. Really, the answer depends… well… on who you ask and when or where you ask them. And this, really, is how some blog posts are born.

Let’s start with examples. Amazon seems to have a clear definition of what edge is – just look at Greengrass.

Microsoft more or less agrees with them, ergo Azure IoT Edge  or AzureStack.

So there we are – the definition of the edge. Take your favorite cloud provider, one with the foresight to “extend” their cloud to on-prem deployments either on IoT devices or otherwise and that’s the edge. Well, that is an edge, and, perhaps in the world of Enterprise IT computing it is the prevalent type of edge, but in Telco (i.e. in the world of MEC) it is not – it’s just an edge.

What’s missing… well, let’s see. A superbly smart colleague suggests this classification, which I like: Enterprise/Consumer Edge, Deep Edge, Far Edge. So the Enterprise/Consumer Edge includes IoT, SD-WAN locations like uCPE, and private Enterprise clouds (note that the Amazon and Azure platforms above are targeted to only two of these three). The Deep Edge includes CS/PON/MITSO. The Far Edge includes CO (can someone say CORD), VHO, SHO. And we are still missing actual user devices, IoT gateways, and I am sure a good half-dozen other potential PoPs.

Let’s give some more examples. A key component of SD-WAN is the customer premise equipment (CPE), which many operators are now moving to a so-called “universal” CPE (uCPE) – essentially a standard compute box which runs all the CPE functions as virtualized appliances. As some of them are finding out, having such a compute presence on their customer premises creates an opportunity to offer IaaS for the customer’s workloads; and, it turns out, there is a demand for just such a service.Take another example – a wireless carrier is virtualizing its RAN infrastructure and transitioning both the remote distributed units (DUs) and Centralized Units (CUs) to a software-based implementations running on a general-purpose compute architecture. The nature of these deployments is very different – the virtualized DUs are likely out in the field in cell-site hut or a fiber aggregation point. The virtualized CUs may exist in a former Central Office converted into a data center (can someone say “CORD”?). The type of infrastructure that is deployed at these sites is likely very different (and different from the uCPE) and, yet, both are clearly “edge” sites.

This does beg the question – why are there so many options? After all, it does seem like Amazon and Microsoft are making do with just two. Both Amazon and Microsoft exist in the “over-the-top” world, in which there are only two entities: the cloud; and the customer’s premises.

The rest is just a pipe. But as we know, that “pipe” is actually a highly sophisticated global engineered system (perhaps the most sophisticated such system created by mankind) in which multiple highly sophisticated components are used to ensure that both the critical communication and a request for a youtube video receive the expected QoS. Moreover, it is a massively distributed infrastructure – perhaps the only distributed infrastructure of that scale in the world. Hence it is “edge-native” – perhaps as much as 90% of Telco systems is edge. As these components are virtualized and migrated to a generic compute platform, each becomes a cloud point-of-presence. And so, voila, we have so many options.

OK, fine…, but do we really need them? Depends on what you mean by “we.” If you mean any single telco operator, chances are the answer is no. Each operator is likely to pick a few Edge Cloud “locales,” – perhaps as few as one.

The choice is driven by the specifics of each operator:

• what is the architecture of their network: RAN, access, etc;
• what kind of population demographics are they serving;
• what use cases do they need to enable; and
• what are the business cases associated with these.

All of these can vary tremendously from one operator to another and so will their definition of “edge”. Moreover, they also change over time - hence the need for architectural malleability in each operator’s edge architecture.

However, if by “we” you mean “we the telco industry”, then my answer is yes – we need all of these various options. And we need to develop infrastructure, standards, management frameworks, etc., that can address all of these options in a simple, unified and highly scalable way.

And this, finally, brings me back full circle. What is “Edge?” The best that I can do is this: it’s anything that’s not a “data center cloud”. Think of any workload you have to support. Clearly, the most cost-effective location to do compute is as deep in your network as possible – this is your “data center cloud”. However, some of your workloads simply cannot be supported there (detailed reasons are subject of their own post, but they could be latency, cost of data transmission into the data center cloud, data retention policies, etc.).

So you find another location for them in your network, where their requirements are met. This location is an edge – i.e. it is any location in your network where compute and related infrastructure, platform, software, etc. services are offered that is closer to the user then your default data center cloud.