Learn NFV Fast and the Easy Way!


Well ! I have done all the efforts and made concepts simple through the Free NFV Mind Map. Get it now before I take it off. Plus get free updates to my blog.

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

17 thoughts on “Beginners Guide to MEC Architecture (Multi-access Edge Computing)”

  1. Pingback: MEC in NFV : How does MEC fit in NFV architecture? – TelcoCloud Bridge

  2. Thanks mate , always good to read your thoughts . Just one observation Telco main direction for MEC will follow GSMA TEC platform and as Telco except America’s I do not see much cooperation will happen with hyper scalers . This is due to EU based organization which prefer 3GPP like standardization . it will be interesting to see who will win and whether coexistence is possible . In either cases COVID has proved investment on Edge is mandatory both for use cases and commercial perspective . We are doing lot of experiments with MEC now and will love to Sync with you soon. BR Saad

    1. Thanks Saad for sharing your thoughts, appreciated. Lets wait to see more on GSMA MEC platform . Its too early for them but looks promising. i think hyperscalers are a fact of life. It would be too naive to ignore hyperscalers. By the way, MS Azure has already partnered for Edge cloud with a leading operator in our neighborhood…

  3. Thanks Fasial
    Does it need to be from single VIM provider or it has to be from one VIM , also where does it cross with E2E SO?

    1. Dear Bader, thanks for reaching out. Stay tuned as I am writing a blog on how does MEC setup fits within NFV context which will clarify the VIM role. For your information, you dont need any other VIM. Your current VIM in NFV is sufficient. ( More on that in my upcoming blog). As far as E2E SO is concerned, the MEC Orchestrator can expose APIs directly to your E2E SO. MEC orchestrator is your domain orchestrator in this case.

  4. What is Mp2 interface ? Why do Services need a specialised interface when applications sit tightly on Virtualisation layer ?

    1. Hi Surendra, As per standard “The Mp2 reference point between the MEC platform and the data plane of the virtualization infrastructure is used to instruct the data plane on how to route traffic among applications, networks, services, etc. This reference point is not further specified.” As far as reusing your current virtualization layer is concerned, you can re-use your current NFVI and VIM. More on this in my upcoming blog

  5. xiaoqun.huang@nokia-sbell.com

    What different is between the MEC app LCM Management and VNF LCM management in VNFM?

    1. Hello xiaoqun, thanks for getting in touch. I intend to upload an article soon on how MEC works inside NFV architecture,as I would need to explain this in detail with diagrams to answer your question. Stay tuned !

  6. Thanks Faisal. I needed information on MEC for a project that I am working on and this is a big help!

    Regards

  7. 1. How does this gets hooked up with the NFVI / NFVO ?
    Can we reuse the same VIM / NFVO for delivery ?

    2. Who monitors application performance ?

    3. In restropect can MEC used in a fixed Network environment ? To deliver regional content ( low latency ) ? What modifications woulbe be needed?
    IF not suitable how would ideally be served for this kind of environment at a cost effective manner .

    1. Thanks Aruna,
      1. I need to write a second post to explain the concept as it needs more attention.
      2. Great question. I had to review the standard again GS MEC 003 once more. Could not find any clear explanation here. However it is written the the MEC Platfrom does monitor the application availability. But PM is much more than just application availability. My take is that MEC App can expose the PMs on north bound to OSS where you can get all these metrics.
      3. MEC is evolving standard. Effectively it will cover the fixed networks also. The challenge would be how and what kind of services MEC platform will expose to the MEC App. The initial ones are focused on radio only.

Leave a Comment

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.