# Multi-Access Edge Computing

## Summary


In traditional cloud computing, apps and services are hosted in data centres. Devices connect to the data centres via multiple hops traversing the internet. If devices are smartphones, they probably connect via the RAN and the CN of the mobile network operator. Multi-Access Edge Computing (MEC) brings apps and services closer to the network edge. MEC also exposes real-time radio network and context information. The benefit is better user experience, network performance, and resource utilization. 

MEC is just one among many edge computing paradigms, others being cloudlets, fog computing and Mobile Cloud Computing (MCC). MEC is perhaps more popular since it's standardized. ETSI is the main organization standardizing MEC. 

One possible definition is that, 

> MEC offers application developers and content providers cloud-computing capabilities and an IT service environment at the edge of the network.

## Discussion

### What are the benefits of MEC for users, service providers and network operators?

MEC enables many use cases that require high bandwidth, ultra-low latency and high device density. Users get a richer experience. Safety is improved for critical applications such as industrial automation and self-driving vehicles. If 5G promises many novel use cases, it's MEC that delivers them. 

MEC helps network operators reduce their CAPEX by purchasing general-purpose equipment rather than specialized telecom equipment. By reducing bandwidth requirements between RAN and CN, OPEX is also reduced. Due to virtualization, reliability and scalability is improved. Heterogenous configurations can be supported. Network entities can be rapidly deployed leading to just-in-time service initiation. Network performance can be optimized by adapting to changing radio conditions. Operators can offer innovative applications and unlock new revenue streams by safely opening up their networks to third-parties. 

Traditionally, it made sense only for big service providers such as Netflix to deploy edge servers for their traffic. With MEC, even smaller service providers and independent software vendors can get their applications to the edge on multi-vendor platforms. This is mainly because MEC is standardized with open interfaces and protocols. 


### What are some use cases that can benefit from MEC?

MEC brings proximity, ultra-low latency, high bandwidth and virtualization. These characteristics can benefit **many use cases**: data/video analytics, location tracking services, augmented reality, IoT, local hosting of video content, data caching, remote surgery, patient management, radio-aware video optimization, autonomous vehicles, and more.  

As more and more applications become **virtualized**, MEC will become increasingly important. Applications can be dynamically deployed, scaled and moved between the cloud and the edge. 

On college campuses, business parks, hospitals or factories **private/local networks** can be deployed. For **mission critical communications**, MEC can continue delivering services even when backhaul communications fail. 

**IoT applications** require ultra-low latency, mobility management, geo-distribution, location awareness and scalability. MEC is able to provide these for diverse IoT applications such as smart home, smart city, smart agriculture, smart energy, healthcare, wearables and industrial internet. 


### Which are the main enablers for MEC?

MEC is made possible by the following technologies: 

    + **Network Functions Virtualization (NFV)**: NFV is about deploying network functions in virtual environments rather than with dedicated hardware. MEC reuses the NFV Infrastructure (NFVI) and NFV Management and Orchestration (MANO). In other words, MEC platform and applications appear as VNFs and run on the same infrastructure as RAN or CN VNF components.
    + **Software-Defined Networking (SDN)**: Involves separating the control plane and user plane, logically centralizing the control plane and programming the control plane in a more flexible manner using APIs. An SDN controller can be in the MEC server. SDN brings scalability, availability, resilience, interoperability and extensibility to MEC operation.
    + **Service Function Chaining (SFC)**: Built from NFV, operators can use SFC to interconnect multiple NFs (virtual or physical) in a specific order to achieve end-to-end services and steer traffic flows.
    + **Network Slicing**: A network slice is a logical network set up for specific performance requirements. Using SDN/NFV, slices can be dynamically instantiated, modified or terminated.
    + **Information-Centric Networking (ICN)**: Replaces client-server model of the internet with publish-subscribe model involving caching, replication and optimal content distribution.

### Could you describe ETSI's MEC reference architecture?

ETSI's MEC reference architecture has the following main entities: 

    + **MEC Host**: Contains MEC platform. Virtualized infrastructure providing compute, storage, and network resources for running MEC applications. Routes traffic among applications, services and access/local/external networks. Executes traffic rules received by MEC platform.
    + **MEC Application**: Runs on a Virtual Machine (VM) or container on the MEC host. Configured and validated by MEC management.
    + **MEC Platform**: Has essential functionality needed to run MEC applications. Enables applications to discover, advertise, offer or consume MEC services. Platform can also provide services. Receives traffic rules from MEC platform manager. May be interfaced with an API gateway for apps to access MEC service APIs.
    + **MEC Management**: Comprises of system-level and host-level management. The former oversees the complete MEC system and includes Multi-Access Edge Orchestrator (MEO) as a core component. The latter manages a particular host and its applications and includes MEC Platform Manager (MEPM) and Virtualisation Infrastructure Manager (VIM).The reference architecture contains three groups of reference points among entities: **Mp** for platform functionality, **Mm** for management, and **Mx** for external entities. 


### What are the different MEC deployment models?

MEC servers can be deployed at base station sites, aggregation points in the radio network, mobile EPC sites or regional data centres. A distributed data centre or a gateway at the edge of the CN could be MEC deployment sites. There's a trade-off: closer to the edge, greater are the benefits but so is the cost of deploying at many locations. It's therefore expected that most operators will initially deploy at a few EPC sites and central offices. As more applications emerge demanding 1ms latency, operators will start deploying closer to the edge. To reduce CAPEX, operators may even share MEC infrastructure. 

An MEC server can be indoors at a multi-RAT cell aggregation site serving an enterprise; or it could be outdoors for public coverage scenarios such as stadiums and shopping malls. Ultimately, deployment depends on scalability, physical constraints, performance criteria, cost of deployment, etc. Some MEC services may be unavailable in some deployment scenarios. 

Vendors offer equipment optimized for specific deployment locations. For example, GIGABYTE's H242-Z10 is for base station tower whereas G242-Z10 is for aggregated sites. 


### Could you mention some resources to learn more about MEC?

MEC specifications from ETSI are available for download via a search feature. 

Apart from the specifications, via the DECODE Working Group, ETSI provides API implementations, testing, a proof-of-concept framework and a sandbox environment. This makes it easier for vendors, operators and application developers to implement MEC. 

A beginner can start with ETSI's white papers on MEC. There's also an MEC blog for latest updates.

The main MEC wiki page is an entry point for MEC ecosystem, testing, sandbox, proof-of-concept updates, deployment trials and hackathons. The MEC Ecosystem page lists MEC applications and solutions. 

Among the many open source projects related to edge computing, two important ones are Akraino and EdgeX Foundry. These come under LF Edge, an umbrella organization under the Linux Foundation. A useful resource is LF Edge's own Wiki page.

## Milestones

Sep  
2014

ETSI forms the Mobile Edge Computing Industry Specification Group (ISG). 

Dec  
2014

The **first meeting** of MEC ISG takes place and is attended by 24 organizations, including network operators, vendors, technology suppliers and Content Delivery Network (CDN) providers. 

2015

ETSI's MEC ISG publishes two specification documents: *Proof of Concept Framework* and *Service Scenarios*. The group develops three PoC scenarios. These relate to video optimization and orchestration by adapting to RAN or radio conditions. 

Sep  
2016

At the MEC World Congress, at the ETSI MEC PoC Zone, six **multi-vendor proofs of concept** are demonstrated based on the MEC PoC framework. It's hoped that such PoCs lead to a diverse and open MEC ecosystem. 

2017

ETSI renames MEC from *Mobile Edge Computing* to *Multi-Access Edge Computing*. The new name reflects its relevance to mobile, Wi-Fi, and fixed access networks.  

2018

ETSI's MEC group works on **Phase 2 activities** to address charging, regulatory compliance, mobility support, containerization, support of non-3GPP mobile networks, automotive vertical, and more. This year sees approval of 12 MEC PoCs and 2 MEC Deployment Trials (MDTs). A new working group named *DECODE* is also created to focus on deployment and ecosystem development. 

Jun  
2019

**Akraino** Release 1 is released with ten "ready and proven" blueprints. Blueprints are tested by Akraino community members on real hardware. They serve as an easy starting point for real-world edge implementations and edge use cases. Akraino comes under LF Edge, an umbrella organization founded in January 2019 to bring together multiple edge-specific projects. In Release 3 (Aug 2020), **MicroMEC** is specified. By Release 4 (Feb 2021), Akraino has 27 blueprints.