Cloud Native Infographic

Don't Miss the "Cloud Native Infographic" !

Everything is cloud Native from 5G core to RAN, transport and orchestration. Either you know about it or Nothing about Cloud. In this "FREE" one page infographic poster, I have made it a QUICK and EASY reference for Cloud Native main concepts which are otherwise very complex to understand. Plus get notified when important blogs are published.

MEC in NFV : How does MEC fit in NFV architecture?

After understanding MEC architecture in my last blog, it is logical to to see the action of MEC in NFV architecture !

However, here is a question, why you need a separate MEC architecture ? Why not re-use NFV architecture.

When NFV can run itself any application, isn’t MEC one of the applications? I got quite a few questions on this, so I thought why not write a dedicated article on this one. This article will clearly position MEC vs NFV and conclude with some takeaways for you.

If you are new to NFV and MEC architecture and haven’t read about my last article you can read them here. NFV architecture here and MEC architecture here.We discussed the MEC architecture in our last blog ( link above) . I have now labelled each component with a number code so you can recognize them once we move them to NFV.

lets add to this to NFV Architecture which is below ( The famous ETSI Architecture)


Lets start moving the items from MEC to NFV.

You probably have guessed it correct, a lot of MEC architecture components are just VNFs which can be easily moved to NFV as VNFs.

MEC Components that become VNFs

I have now elaborated it through a diagram in which I have shown which components from MEC can be mapped to NFV architecture as VNFs. I have shown all of them with red arrows. ( items 1,2,3,4,6)

They are

  • All MEC Apps
  • MEC platform
  • “MEC Platform Element Management” and “MEC App Rules & Reqmts Management”
  • Other MEC Platforms
  • Data Plane of MEC Platform

After moving these components as VNFs, it would logical to ask is there anything I can re-use from NFV so that I can remove from MEC architecture.

Components that are not needed in MEC architecture as NFV already have them

Well, MEC has a virtualization stack ( the Virtualization Infrastructure manager(VIM) and Virtualization infrastructure); So does NFV- VIM and NFVI Correct ?

So why would you need a duplication here.

So we can easily remove them from MEC as NFV can handle them. As shown in the diagram below item 3a and item 5 are mapped respectively to NFVI and VIM respectively.

So far so good !

With this mapping we can see now new components added to NFV with the codes so you can track.


What about MEC VNFs life cycle management ?

Remember! the VNFM role?

The VNFM does the life cycle management of VNFs ( creation, deletion, maintenance)Now that MEC functions are converted into VNFs, we would naturally need corresponding VNFMs. This is done by two VNFMs as following.

  1. VNFM to manage life cycle of MEC Apps. ( item 4b)
  2. VNFM to mange life cycle of MEC Platfrom ( new item)

Just to elarborate more. The item 4 above in MEC is decomposed in 4a and 4b as following.

  • MEC platform Element Management and MEC App rules & requirements management” becomes a VNF labeled 4a
  • “MEC App life cycle management” is mapped to VNFM as item 4b

Lets move ahead !

Multi Access Edge Orchetrator

With all other items mapped correctly, we are left with one major component which is MEC Orchestrator.

This component ( item 7) is mapped ” as-it-is” and re-named to Multi Access Edge Orchestrator. This is now a new component in NFV. Likewise items 8,9,10 are mapped “as-they-are” in NFV as new components.

Conclusion: Does NFV cover everything MEC offers ?

Perhaps Not.

While MEC architecture can be completely mapped to NFV. What NFV cannot provide is the MEC orchestration part. Neither can NFV provide the CFS portal, Device App, Use App LCM proxy.

Among them MEC orchestration is the most important component that is missing in NFV.

If you look at the original diagram of MEC at the top. This sums up to the top layer which is “MEC System level” which is the missing part in NFV ( of course OSS stays the same). Also mapping MEC in NFV architecture results in some new reference points ( refer to the legend in above diagram), the new reference points are colored as maroun.

So thats it from my side; hope this makes the situation more clear on how MEC fits inside NFV architecture.

Now its turn to drop me a line, if you have some questions here !

Reference: ETSI GS MEC 003 – V2.1.1 – Multi-access Edge Computing

Notify of
Newest Most Voted
Inline Feedbacks
View all comments
2 years ago

Wonderful articulation as always!

Faisal Khan
Faisal Khan
2 years ago
Reply to  Ajay

Thanks Ajay, for taking time to read it.

Georgios Kalpaktsoglou
Georgios Kalpaktsoglou
1 year ago

Perfect article! I’am new to these technologies and also happy to have found your articles to clear many questions!!

Faisal Khan
Faisal Khan
1 year ago

Hi Georgios, glad that you liked it

1 year ago

Salam Faisal,

I would like to thank you for your Blog. It’s a real pleasure to read it.

I have a question related to the MEC: what did you think about Bare-metal container platforms that they are offered on the edge for Telco use cases?

Many thanks.

1 year ago
Reply to  Faisal

Hi Faisal,

Many thanks for your answer.

There is a possibility to manage different k8s clusters, which means I don’t need the VM separation like before. It’s too heavy to use VMs + Network acceleration techniques to meet the 5G requirements.
As the 5G is container-based, I think is better to avoid the Hypervisor complexity and use container-based platform. What do you think about this?

It’s the case of Mobile Edge Computing as well which requires low latency and bandwidth.

Would love your thoughts, please comment.x