Multi-access Edge Computing (MEC): Transforming the mobile ecosystem for service providers
Amr Alashaal, Regional Vice President – Middle East at A10 Networks writes on how Multi-access edge computing (MEC) is transforming the mobile ecosystem.
Multi-access edge computing (MEC) is transforming the mobile ecosystem. By moving mobile network traffic processing functions from a centralized location to multiple distribution points at the network edge, a MEC architecture allows much lower latency, greatly expanding the types of applications and services that can be delivered. Together with 5G, MEC extends digital reach while creating new revenue opportunities for both enterprises and service providers— and it helps businesses stay competitive in the new “digital-first” economy.
For mobile operators, MEC offers a way to address key priorities in the deployment of 5G networks and the transformation of existing 4G/3G networks, including meeting the heightened expectations of subscribers for a seamless experience with new devices and new applications, providing added value to enterprises by providing new applications and services and participating in a new ecosystem and competing or partnering with large cloud providers such as AWS and Microsoft Azure for the same enterprise revenue.
But multi-access edge computing requires pulling apart and redistributing critical functions now operating in a centralized core network. This poses practical deployment challenges around space and power constraints, security, and operational complexity.
Addressing Challenge #1 – Space & Power Constraints
In the 5G era, the number of sites, including MEC locations, is expected to be up to 100x that of the 4G era. With site maintenance costs amounting to 2 – 5 percent of total mobile operator revenue, conservation of space and energy is clearly a top priority for 5G profitability.
A key opportunity to minimize space and power requirements while improving performance and reducing latency is optimizing and consolidating functions that in 4G networks exist in the Gi-LAN. Gi-LAN functions that could be moved to the edge include firewalls such as GiFW, GTP/roaming firewall, Diameter firewall, SCTP firewall, and DNS application firewall; DDoS mitigation and detection functions; and other functions such as CGNAT, DPI, traffic steering, and load balancing.
However, in 4G networks, most operators have 10 – 12 different devices in the Gi-LAN, often from different vendors. If an operator has 1,000 MEC nodes, this would mean deploying 10,000 or more Gi-LAN devices across all the nodes, an unmanageable scenario even if each node had adequate space. As operators move to 5G and MEC, they are planning to virtualize as much as possible.
The high-performance requirements for Gi-LAN functions, which are in-line with traffic, means that many operators will choose to initially deploy physical appliances, then swap out to virtual or containers as their experience level grows. This makes a compact, consolidated physical appliance extremely valuable.
Deploying Gi-LAN functions as VMs or containers can help solve space and power limits—but it can also add unwanted latency. When functions are chained together, traffic must pass through the entire software stack for each function, and in turn, adding latency as well as compute and storage.
Consolidating Gi-LAN functions into one software stack or appliance minimizes space and power requirements and simplifies operations. Latency is also reduced by allowing just a single pass through the software stack.
Addressing Challenge #2 – Security – DDoS Landscape
With potentially thousands of additional nodes, MEC significantly increases the attack surface operators must defend. With one central data center or EPC, operators could simply overprovision capacity or DDoS protection to safely absorb a DDoS attack. Overprovisioning may not be possible in space- and power-constrained MEC nodes, and it certainly won’t be cost-effective across a large number of nodes. Each node needs its own protection against DDoS attacks and other threats.
Operators need a space and power efficient DDoS solution to protect each MEC node and its critical applications.
Addressing Challenge #3 – Operational Complexity & Automation
With MEC, operators will have dozens, hundreds, or even thousands of node sites to configure, deploy, turn up, secure, monitor, and maintain. This presents numerous challenges. To begin with, one of the objectives in 5G is to allow operators to more closely align network investment with revenue opportunity and provide capacity on demand. With MEC, though, operators must size and scale not just a single central data center or EPC, but a large number of nodes—each with its own requirements to fit the unique traffic characteristics of the service cluster it serves.
In this light, it becomes much more difficult to optimize investment on a per-site basis to achieve traffic requirements while maintaining some level of operations simplicity. As the number of sites grows, manual processes that used to be tolerated with a central location become unwieldy. Manual processes are prone to human error, and present security risks from inconsistent security updates or configuration errors.
The many unknowns in subscribers, traffic type, and demand on a per-site or per-node basis add further complexity. The services or service clusters that each node will support are often new and can vary in traffic characteristics and volume. Operators need to avoid the added cost and overhead of over-provisioning while still providing the quality of service needed for each area. They also need to be able to roll out new nodes quickly, using standard configurations to simplify operations.
Addressing this complexity calls for a three-pronged approach:
- Automation of manual processes for more scalable, efficient management
- Robust APIs to make configuration and roll-out simpler, and to eliminate many configuration or update errors
- Flexible licensing and shared elastic capacity to quickly reallocate licenses for virtual instances to different VMs based on changing demand, and to avoid overprovisioning capacity in MEC nodes