How you can succeed with your services edge transformation
The technology for multiaccess edge computing (MEC) should support both infrastructure and services use cases. Network functions virtualization (NFV) workloads deployed at the edge include elements of a radio stack and elements such as user plane functions or edge offload functions. Services use cases support a service provider’s own offers and third-party workloads that result in revenue.
MEC needs to satisfy the requirements of industry verticals that need some combination of radio, low latency workload deployment, data reduction, or data security (sovereignty) in their enterprise environment.
Aligned with other industry initiatives, at Cisco, we believe that MEC is an example of network as a service or NaaS
5G brings huge improvements in bandwidth and latency and the ability to tailor service experiences across different vertical markets and individual users. Applications that harness these capabilities can transform industries such as manufacturing, automotive, healthcare, and transportation. Your balance sheet also can be transformed in a positive manner. For any of these changes to occur, however, you must rethink the traditional model for building end-to-end service networks.
As costs and complexity grow each year, the current models for building and deploying basic network functions are becoming less viable. The massive wave of new devices and applications in addition to the expanding user base and traffic loads that will accompany 5G exacerbate the problems (see Figure 1).
To deliver the high-quality experiences that consumers of 5G services expect and demand, you’ll need to fundamentally reimagine the service edge. End-to-end orchestration will be most important in delivering high quality experiences economically.
Figure 1. Global internet business traffic forecast (Source: Cisco VNI Forecast 2019).
MEC is an example of NaaS and represents an important architectural shift that reimagines the service edge. It will need to address user experience, economics and network decomposition, disaggregation, and convergence.
A recently published third-party research report from Technology Business Research, Inc, 2Q19 Telecom Edge Compute Market Landscape stated three key insights that are pertinent to MEC:
The technology for MEC should support both infrastructure and services use cases. NFV workloads that are deployed at the edge include elements of a radio stack (unlicensed or licensed) as well as elements of a 5GC or R14 Evolved Packet Core (EPC) such as a user plane function (UPF) for edge offload. Services use cases are for your own operator offers or third-party workloads that result in revenue for you, either in the context of business or consumer products.
MEC exists to satisfy the requirements of industry verticals that need some combination of radio, low latency workload deployment, data reduction, or data security (sovereignty) in their enterprise environment. For example, an internal affiliate or a third-party content delivery network (CDN) provider can benefit from low latency access to viewers. Users receive better quality of experience and lower cost of transport and benefit from exciting opportunities such as augmented/virtual reality (AR/VR), gaming, connected cars, and IoT gateways.
Like several other operators in the Cisco taxonomy for edge service, we distinguish between use cases associated with enterprise-hosted dedicated capabilities and network-hosted distributed capabilities. Both use case families require common platform elements and because of the incipient nature of the market, they need a modular approach that allows for simplified systems integration. This type of integration can be performed in-house or by partners to shape the solution to suit your enterprise use cases.
Common platform elements include:
The 5G systems architecture that uses both Long-Term Evolution (LTE) and 5G New Radio (NR) is essential for MEC success. For example, a basic and fundamental enabler is the mobile systems architecture that decomposes the R14 EPC and the 5G core (5GC) into a centralized and virtualized, latency-insensitive control plane that handles session management, authentication, and access functions. It also handles multiple user planes that can be deployed anywhere the IP network allows (Control and User Plane Separation or CUPS).
The user planes can be placed at micro-clouds managed by the operator at enterprise locations (dedicated MEC) and deployed in combination with dedicated radio (Wi-Fi or licensed LTE/NR) for unique enterprise applications such as factory automation, AR/VR, and connected health. Cisco is investing significantly in CUPS architectures and in features designed to support MEC. We enable an operator-managed service that can be deployed with micro-clouds on the enterprise premise. The points of delivery (PODs) can be in form factors as small as a single server integrating the WAN router such as our Enterprise Networking Computing System (ENCS). Or the POD can be through higher scale multiple servers with associated switches in a spine-leaf configuration. The premises edge can also integrate various capabilities such as our SD-WAN and include a broad variety of managed security workloads and appliances.
In contrast, when these user plane functions are placed in larger clouds at low latency locations in the network (distributed MEC), the functions can become the basis for a multitenant hosting business that drives operator revenue from those enterprises that wish to benefit from low latency, data reduction, or both (for example, CDNs or IoT connected device platforms) in the macro network. Many operators are exploring the revenue potential of these distributed edge locations.
The range of Cisco products and solutions can satisfy a broad range of use cases and we have third-party systems that can help enable an ETSI MEC style business model. One of our partners, MobiledgeX, has deployed their solution on our virtualization platform. This innovative business model is intended to support edge innovation using an integrated ecosystem that federates operators, handsets, and third-parties.
Infrastructure (NFV) workloads that support Cloud-RAN are also being virtualized at the edge, particularly those workloads associated with the virtualized central unit (vCU) comprising packet data convergence protocol (PDCP) and radio resource control (RRC) functions as well as critical multi-band connectivity features. We are firm believers in the merits of a Cloud-RAN approach to developing a multivendor radio network. The feasibility of this approach has already been proven in the case of Rakuten, a Japanese mobile operator. We deployed third-party radio signal processing workloads on its edge OpenStack/KVM platform and interworked them with Nokia’s remote radio head (RRH).
In keeping with an enterprise-focused vision, secure API enablement is critical. Industry verticals need a trusted consumable version of NaaS to use the network “as if it where their own” but without any of the operational complexities. Our strategy is two-fold:
We are investing in development and partnerships to realize a trusted API-driven version of network resource consumption. This vision inherently relies on the underlying automation of all processes, so MEC must be integrated into an end-to-end automation strategy.
Figure 2. Drivers for MEC.
It is worth emphasizing that any approach to services edge transformation should be modular. The marketplace is exhibiting fragmentation in operator directions, so it makes little sense to settle on a definitive product-centric approach to edge computing. But there is a more fundamental reason for the modular approach. Because MEC is defined to support the needs of industry verticals, the flexibility that comes with modularity becomes even more important. It will be a requirement of enterprises of its telecommunications suppliers. System architecture will change based on the nature of the use case. You may need to employ a systems integration approach to tackle emerging unique use cases. Although high replicability is preferable and is a major objective, in an incipient market, flexibility is vital.
One final strategic consideration is the role of public clouds. As the industry at large becomes aware of the value of low-latency services, data reduction, and contextual edge information, it will become inevitable that the major public cloud providers will play a role in delivering these capabilities to enterprises. As we ponder the significance of the next strategic moves from the operator community, we believe it becomes essential to make sure that the architecture for the edge makes it easier for the operator to conclude that the public cloud is a NaaS consumer of edge, as opposed to being a direct competitor.
Figure 3. The span of service edge and MEC locations.
As the demands of mobile applications grow and the impact of 5G networks continues to emerge, it’s clear tomorrow’s edge services will look different from those we use today. Deploying a distributed MEC architecture that can facilitate those services will require new approaches and careful consideration of the placement of distributed and virtualized resources. The choices you make now to evolve your edge networks will dictate the applications you can support and the ways you can build and differentiate your services.
The time for the transformation of the services edge and edge computing deployment is upon the industry now. With our partners, we have established several references for edge deployments. These examples and their underlying architectures can be used as a starting point as you consider your specific services edge transformation and MEC deployments.