MEC to The Future
If there’s anything our industry is good at, it’s creating ever new hype cycles and continuing to fall into the same traps of overestimating what they can do for mankind as a whole, or at least for network operators. And now comes MEC… Multi-access Edge Computing, formerly known as Mobile Edge Computing, and it’s all the rave. To be honest, it’s been around for a while. Up till now it was mostly tied to mobile, in general and 5G specifically, but according to some people it has such potential that it was worth being renamed (keeping the same acronym) and rolled into the topologies of networks of all kinds. So why the hype, and is it real this time?
Many of these ‘new kids on the block’ that fail to deliver on their perceived promises have one thing in common: a great concept which in reality didn’t deliver the necessary benefits. SDN is a great example of a strongly regarded, but ever morphing concept, whose immediate impact was massively overrated (it will, of course, finally be successful, no doubt about it). NFV took off like a rocket as soon as useful applications like SD-WAN were available or uCPEs had become cheap enough. So, where does MEC sit from a potential for immediate success perspective? Very much on the positive side, as far as I am concerned… for delivering certain services, you really need it, and there’s no really no alternative.
What is MEC? In a nutshell, one could describe it as a bunch of servers, with different form factors, that are located in certain locations of a network. The locations are selected based on the need for distributed compute power and “intelligence”, with 2 major goals in mind: minimizing (service) latency and reducing traffic. How? Pretty simple… imagine you want to offer an IoT service which needs permanent real time information from sensors in a specific geographical area to perform a certain control function… e.g. for traffic management.
In a non-MEC environment, all sensor-based information needs to travel to a remote data center, be processed there, tagged for action and then the control commands have to travel the whole way back to the area in scope. With MEC, you can either locate a pico-datacenter or add a processor card (embedded) in the transport equipment close to the location. All sensor information is processed at point of origin, or nearby, so control commands arrive faster since the loop has shorter distance to travel and therefore, the whole process has much lower latency. The MEC device still keeps a remote datacenter informed about what’s going on, but it doesn’t need it for real time actions and reactions. It also eliminates the impact of network issues like congestion in a part of the network the traffic needs to cross. And it reduces the amount of long distance traffic to the necessary minimum. Compelling, isn’t it?
Are there any downsides? Not really… MEC appears to be one of the few technologies that are able to solve some fundamental issues by “just” being added to the network. Of course that’s an oversimplification… “just” in this case means there needs to be a fully functional SDN/NFV orchestration environment and deployment of additional new hardware and software. This additional cost needs to be covered by a gain in service profit, which brings us to the lack of sustainable business cases for a number of the “really cool” services that could be enabled. A point to take on in another blog.
But since MEC has expanded beyond its original concept, from being mobile only, to being deployable in all kinds of networks, the number of uses cases has increased by such an amount that material deployment of MEC driven solutions will not take much longer.