Beginners Guide to MEC Architecture (Multi-access Edge Computing)

Welcome to the guide to MEC Architecture !

MEC or Multi-access Edge computing will draw the next wave of investments by Mobile operators who want to take advantage of low latency services that 5G promises. Which means running services closer to the consumers ( that is close to radio sites).

This opens a new range of services and new ways to monetize for service providers. For example, faster gaming experience, Augmented/Virtual Reality, connected cars, etc.

And it has potential, that’s why you see the web scalers like Azure, AWS, Google have jumped to the bandwagon and suddenly started putting their cash in building their own MEC platforms.

This guide to MEC Architecture is based on ETSI model – the defacto body for MEC standards. This guide builds up the MEC architecture from ground up and expects no prior knowledge.

By understanding the MEC architecture, You

• As service provider, will know how to evolve to a standard based MEC platform/architecture.
• As vendor/developer, will enable you to tell your customer how your solution fits the ETSI MEC model

So without further ado, lets start jump in!

We build the MEC architecture in sequence, block by block starting from Ground Zero 🙂

Definition of MEC

According to the ETSI, the MEC is defined as following

“Multi-access Edge Computing (MEC) offers application developers and content providers cloud-computing capabilities and an IT service environment at the edge of the network. This environment is characterized by ultra-low latency and high bandwidth as well as real-time access to radio network information that can be leveraged by applications.”

MEC Architecture according to ETSI

So lets see complete MEC ETSI architecture as shown below.

There are three distinct blocks, MEC Host, MEC Platform Manager and MEC Orchestrator

But before these three blocks. Lets start from the very basic block which Virtualization Infrastructure Manager ( VIM).

Because in every virtual network, you need to have servers so you can spin your Virtual Machines ( VMs) on them and these VMs need a management layer.

Virtualization Infrastructure Manager (VIM)

It has similar functionality to VIM in NFV. Its purpose is to manage the virtual machines (VMs) on top of physical infrastructure ( compute, storage, and networking). It is responsible for allocating, maintaining, and releasing virtual resources of the “virtualization infrastructure”. On the left side you see the servers that are turned into virtualized infrastructure, while on the right site is VIM that manages virtual resources on top of these servers.

After understanding VIM and Virtual resource, lets build up the MEC platfrom and MEC Apps on top of it.

MEC Host

Together the Virtualization Infrastructure, MEC Apps and MEC Platfrom are called MEC Host.

Lets start with MEC Apps.

MEC Application

Why we are running MEC?. To run some applications. correct ?

These are the actual applications that are run in MEC on top of VMs. In plain language, these are the actual apps in MEC like an application for gaming or Virtual Reality or Augmented Reality.

Diagram below shows that we have spin up MEC Apps on top of our virtual machines inside the virtualization infrastructure.

MEC Platform

Lets move forward and add MEC platform to our buidling blocks. There are multiple components inside the MEC platform. The most important of them is the MEC Service.

MEC Service

“MEC Service” is an important block in MEC. The network-related APIs are exposed by MEC service to MEC Apps through reference point Mp1 shown above. Also, the MEC platform can consume these services.

Still confused ?

The beauty of MEC ETSI architecture is that MEC Apps are network-aware ( so that MEC Apps can take action based on that ) and that is where MEC Service can help by exposing the network information through APIs.

According to ETSI, at least three types of following services must be exposed by “MEC service” and they are ( they are part of service registry)

• Radio Network conditions.
• Location information ( for example, location of a User Equipment(UE))
• Bandwidth Manager- The Bandwidth Manager service, when available, allows allocation of bandwidth to certain traffic routed to and from MEC applications and its prioritization

( PS: UE stands for User Equipment and can mean here a cell phone. It can also mean a laptop with mobile dongle)

After discussing MEC Service, we need to be aware of two other components of MEC Platform:

Traffic Rules Control

This is important piece of MEC Platform. As MEC Platform is serving multiple applications, simultaneously, It should be able to assign priorities priorities through “Traffic rules control”

DNS Handling

The mobile edge platform shall provide functionality that supports routing all DNS traffic received from any UE to a local DNS server/proxy.

Why this is important? The benefit of the MEC is to process a lot of information locally in MEC instead of sending it to the internet. Thus it should have a way to handle DNS redirection to a local DNS server so that the traffic can be diverted for local processing instead of sending to the internet.

Also note that there could be other MEC hosts connected to the exiting MEC host through Mp3 interface.

Up to this point we have covered VIM, MEC Platform, and MEC Apps, but what about the management of MEC platform and applications themselves. That is where MEC Platform Manager comes into the picture.

MEC Platfrom Manager

You Know of VNFM in NFV, correct ?

MEC Platform manager performs same functions or a little more then the VNFM, It includes the following functions.

• MEC Apps’ Life-cycle management: instantiating, maintaining and tearing down MEC Apps on VMs
• Element Management: FCAPS ( Fault, Configuration, Accounting, Performance, Security) management for the MEC platform
• managing the application rules, traffic rules, DNS configuration

So far so good, we are able to manage MEC platform, but we are not yet finished. There may be multiple MEC Host(s) ( so multiple MEC Platform manager(s). So there should be a layer above MEC platform manager that can coordinate between different MEC platform managers. That is where MEC orchestrator comes into the picture and this effectively completes our ETSI architecture.

Multi-Access Edge Orchestrator

The analogy for MEC Orchestrator can be drawn to NFVO Orchestrator here.

It does the following functions

• Lifecycle management of MEC Apps ( Compare this with MEC Platform manager, which can do a similar function). The Orchestrator achieves this function by talking to the application through the MEC platform manager.
• on-boarding of application packages, including checking the integrity and authenticity of the packages.
• Last but not the least, selecting appropriate MEC host(s) for application instantiation based on constraints, such as latency, available resources, and available services

A last couple of things, that need mention:

CFS Portal

CFS standards for “Customer Facing Service”. Through CFS, the mobile operators’ customers can order new MEC applications or monitor the service SLAs.

User App LCM Proxy

This is an optional feature in MEC system. For this the system should support feature called “UserApps”

When the mobile edge system supports the feature UserApps, the system shall allow the establishment of connectivity between a UE ( that runs device application) and a specific instance of a mobile edge application.

The user application lifecycle management proxy allows device applications to request on-boarding, instantiation, termination of user applications, and when supported.

In simple words, the user can now trigger specific applications in MEC system from his device if this feature is supported by MEC system.

That’s it from my side and this completes the beginners guide to MEC Architecture, Now it’s your turn to ask me any questions regarding this architecture.

References

• ETSI GS MEC 002 V1.1.1
• ETSI GS MEC 003 V2.1.1