Author: Arvind Padmanabhan
Powered by Multi-access Edge Computing (MEC)
Until a few years ago, for many decades, telecom operators had been claiming that all they provided was a “dumb pipe”. It was not their concern what those pipes carried; and they were not responsible for content that was served or consumed at both ends of the pipe. Their main goal was to ensure that the pipes had enough bandwidth to serve average and peak traffic requirements. All was well and good until over-the-top (OTT) content starting dominating the market. Such content bypassed legacy circuit-switched services and value-added services provided by the operators.
Indeed telecom operators started to lose both ends of the bargain. They now wanted control over the content and charge a premium but all they could collect from their customers was for bare bits and bytes. In a price-sensitive market, “unlimited plans” became the order of the day. When OTT content became predominant, operator revenues started to drop. Content also became rich in multimedia, particularly video that congested backhaul links. Operators couldn’t afford to upgrade these backhauls. Yes, operators were providing dumb pipes but apparently even these had a hard time keeping up with demand.
This year ETSI has taken the initiative to standardize something called Multi-access Edge Computing (MEC). It’s the telecom world’s late effort to get back control over content. In another sense, it may not be late after all. The growth of content consumption on mobile networks has made everyone realize that it’s expensive and inefficient to send every data packet deep into the core network or a cloud platform. Processing, storage and routing needs to be distributed at network edges in some use cases where they make sense.
Two developments have triggered the possibility of edge computing: 5G and IoT. There are plenty of use cases where either higher bandwidth or low latency is required. VR applications typically require high resolution and high frame rates for real-world experiences. Connected cars or emergency medical care applications require low latency. 5G promises to address these use cases. In the world of IoT, each sensor node may send just a few bytes of data but because there could be millions of such nodes, current cellular standards have to be rethought. NB-IoT attempts to address this but its success on the field is yet to be proven (LoRa and SigFox seem to have better adoption). Edge computing comes to the rescue.
Instead of sending data deep into the core network, edge processing allows us to process, store, analyze and aggregate data closer to data sources. This will lower latency and relieve congestion on backhaul links. What’s interesting is that the MEC standard provides app developers and network operators a unified framework to deploy, provision and manage apps. MEC used to be called Mobile Edge Computing but now it’s truly multi-access because it allows for wireline access as well.
None of this is really remarkable until we notice that a radio network has some valuable information that can enhance end-user experience of applications. A radio network has information about link quality (CQI), strength of signals from neighbouring cells, traffic load on the current cell, number of radio access bearers, their QoS parameters, etc. MEC allows applications to access this information and thereby adapt to real-time conditions. For example, a video streaming application can adapt it’s bitrate to current radio link conditions and save the user from annoying buffering delays.
I learned about MEC today, thanks to a seminar organized by Intel Software, who shared the latest developments in the world of NFV/SDN and what Intel has to offer. Specifically, Intel offers the NEV-SDK Release 3.0 that’s implemented to the MEC specifications. In addition, they have the Intel Select program through which they recommend best possible configurations of software and firmware that’s pre-tested in collaboration with ecosystem partners. When such configurations are tested, three data flows are kept in focus for measuring performance: network traffic, data storage and crypto/compression acceleration.
Intel’s partners gave talks on specific topics. Tech Mahindra highlighted different possible use cases. TCS gave a nice overview of various MEC deployments. For example, the MEC platform could be co-located with an eNodeB or could sit in the core network between eNodeB and S-GW. It could also be used in 2G/3G networks between SGSN and GGSN.
It’s important to note that MEC could be a game changer. Previously, deploying apps within operator networks was a specialized job that only the operator knew how to do. Much of it was proprietary. For example, Netflix integration with Reliance Jio network is pretty much proprietary. MEC will change this. Just as we have an approval and publishing process for smartphone apps, operators will have their equivalents. Anyone with permissions will be able to publish, unpublish or update their apps within operator networks. A registry of apps will exist and will enable discovery.
The hope is that big bandwidth guzzlers such as YouTube and Facebook will start using MEC architecture to reduce congestion on backhaul links. At the same time, it’s not clear how cloud platform providers such as Google, Amazon and Microsoft will leverage on MEC. Will it make sense to deploy MEC platforms at every eNodeB or elsewhere that aggregates traffic from multiple eNodeBs in the area? Many things are not clear at the moment. What’s certain is that innovation is just around the corner.
Author: Arvind Padmanabhan
Arvind Padmanabhan graduated from the National University of Singapore with a master’s degree in electrical engineering. With more than fifteen years of experience, he has worked extensively on various wireless technologies including DECT, WCDMA, HSPA, WiMAX and LTE. He is passionate about tech blogging, training and supporting early stage Indian start-ups. He is a founder member of two non-profit community platforms: IEDF and Devopedia. In 2013, he published a book on the history of digital technology: http://theinfinitebit.wordpress.com.