NFV, MANO & NFVI
Last updated 12 Oct 2026
At a glance
5GC functions, and the remaining virtual EPC and IMS functions, run as virtual machines or containers. ETSI MANO (NFVO, VNFM, VIM) manages their lifecycle on top of an NFVI built on OpenStack or Kubernetes. Day 2, running the functions for years, is where most of the cost and most of the product gaps sit.
The picture
Click any layer to explore its responsibilities, interfaces, and state ownership
How it works
Why MANO sits with the mobile core
MANO can in theory manage any virtualised workload. In practice its dominant production use in telcos is the mobile core and IMS, with vCPE and SD-WAN a smaller footprint.
The components
| Component | Responsibility | Key inputs | Day focus |
|---|---|---|---|
| NFVO | Network service lifecycle: instantiate, scale, terminate; onboards NSDs and VNF packages | Network Service Descriptor (NSD), VNF package, policy | Day 0 design, Day 1 instantiation; coordinates Day 2 across functions |
| VNFM | Lifecycle of one VNF or CNF: instantiate, scale, heal, terminate | VNF Descriptor (VNFD), Helm chart for CNFs | Day 1 and Day 2 |
| VIM | Allocates compute, storage and networking to functions | NFVI capacity, placement constraints | Day 1 allocation, Day 2 reallocation under load |
| NFVI | The compute, storage and networking that hosts functions | Servers, storage, switching, hypervisor or Kubernetes | The substrate, not a lifecycle actor |
Day 0, 1 and 2
- Day 0, design: descriptors and packages are written and onboarded. Done once per function version.
- Day 1, instantiate: the function is deployed and configured. Event-driven.
- Day 2, operate: scaling under load, healing failed pods, patches, rolling upgrades. Runs for the life of the function.
Many MANO products were built for Day 1 first and grew Day 2 later. Day 2 is where the operating cost sits.
Two NFVI generations
| Aspect | Gen 1: OpenStack | Gen 2: Kubernetes |
|---|---|---|
| Unit of deployment | Virtual machine (VNF) | Container / pod (CNF) |
| Startup time | Minutes | Seconds |
| Resource efficiency | Full OS per VM | Shared kernel |
| Scaling | Manual or Heat templates | Native auto-scaling |
| Typical workload | Legacy VNFs (vEPC, vIMS) | Cloud-native 5GC functions (AMF, SMF, UPF) |
| VNFM coupling | Per-vendor VNFM, often heavy | Helm-based, increasingly standard |
Most operators run both: legacy VNFs on OpenStack, cloud-native functions on Kubernetes. That hybrid will last for years.
Where MANO stops
MANO manages function lifecycle on existing NFVI. It does not set up bare metal, install OpenStack or build Kubernetes clusters; that is separate infrastructure tooling, such as MAAS, Terraform, OpenStack-Ansible or a managed Kubernetes platform. Above MANO, SOM asks for network services and does not touch the NFVI directly. Service state and infrastructure state stay independent: a function MANO reports healthy may belong to a service SOM has not finished activating.
Who owns what
| Entity | System of Record | System of Engagement | System of Reference | Notes |
|---|---|---|---|---|
| Network service and VNF descriptors (NSD, VNFD, Helm charts) | NFVO catalog | — | VNFM | Infrastructure detail lives here, never in the service catalog or SOM payloads. |
| Network service instance | NFVO | — | Resource Inventory, SOM | Instantiated and scaled on request from SOM or the cross-domain orchestrator. |
| VNF / CNF instance state | VNFM | — | NFVO, Resource Inventory | Changes constantly under Day-2 scaling and healing; inventory is fed from the VNFM. |
| NFVI capacity and placement | VIM | — | NFVO | OpenStack or Kubernetes; built by infrastructure tooling outside MANO. |
In practice
Gen-1 VNFs typically come with a per-vendor VNFM, so estates with several core vendors end up with several VNFMs under one NFVO, or with vendor stacks side by side. Cloud-native functions push towards Helm and standard Kubernetes tooling, which reduces the VNFM’s role but does not remove the need for network-service-level orchestration.
The trade-off
What it solves
A standard lifecycle layer lets network functions be instantiated, scaled, healed and upgraded on shared infrastructure, separately from the services they carry.
What it does not solve
- Building the infrastructure itself; MANO assumes NFVI already exists.
- Service activation; a running function is not an active service.
- Vendor VNFM fragmentation in multi-vendor cores.
What it adds
- Two NFVI generations to run in parallel, with different scaling and packaging models.
- Day-2 automation (scale, heal, upgrade) that must be tested as rigorously as the functions.
- Inventory that has to follow instances that move and scale constantly.
Architecture decision
How should a new cloud-native core function be deployed and managed?
Through the existing NFVO and VNFM
Choose when the estate already runs MANO for its VNFs and wants one lifecycle and inventory view across both generations.
Kubernetes-native tooling, NFVO for network services only
Choose when the functions are fully cloud-native and the platform team owns Helm-based lifecycle well.
The core vendor’s own stack
Choose when one vendor supplies the core and the coupling is accepted for consistency.
Breaks if the choice is made on Day-1 instantiation alone. Day-2 scaling, healing and upgrades are where the gaps appear, after the contract is signed.
Takeaways
Key Takeaways
- NFVO runs network services, VNFM runs individual functions, VIM allocates infrastructure, NFVI hosts it.
- Day 2 (scale, heal, patch, upgrade) runs for the life of the function and carries most of the cost.
- OpenStack and Kubernetes NFVI will run side by side for years.
- MANO does not build infrastructure, and a healthy function is not an active service.
Check yourself
A MANO programme’s scope includes installing the Kubernetes clusters. Why is that a risk?Show answerHide
Cluster build is infrastructure tooling, outside MANO. Folding it in turns a lifecycle project into an infrastructure build, a common reason MANO programmes overrun.
MANO reports all UPF instances healthy, yet a new slice is not carrying traffic. Is MANO wrong?Show answerHide
Not necessarily. MANO reports infrastructure state. The slice may not be fully activated: subscriber data, slice policy or the transport slice may be incomplete. Service state comes from SOM and the orchestrator.