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)
- 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.
- VNFM to manage life cycle of MEC Apps. ( item 4b)
- 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 ?
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 !