Don't miss the NFV mind map !

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.

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)

MEC in NFV

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.

MEC in NFV
MEC in NFV

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

Subscribe
Notify of
guest
7 Comments
Oldest
Newest Most Voted
Inline Feedbacks
View all comments
Ajay
Ajay
10 months ago

Wonderful articulation as always!

Georgios Kalpaktsoglou
Georgios Kalpaktsoglou
4 months ago

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

Mouad
Mouad
2 months 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.

Faisal
Admin
2 months ago
Reply to  Mouad

Hi Mouad, bare metal container platforms restrict you to use only that vendor’s containers and not share the platform with other vendors. ( because of security issues) Rather, putting containers on top of VM is a good idea. I hope I understood your question well.

Mouad
Mouad
1 month 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.

7
0
Would love your thoughts, please comment.x
()
x