Cloud & NFV(Network Function Virtualization) for 5G Networks
- Venkateshu
- a few seconds ago
- 9 min read
1.Introduction
Cloud and Network Function Virtualization (NFV) for 5G networks represent a fundamental shift in how telecommunication networks are designed and managed. NFV decouples network functions from specialized hardware, allowing them to run as software on standard cloud infrastructure. This virtualization enables 5G networks to be more flexible, scalable, and cost-efficient by leveraging cloud-native principles and automation. It allows operators to dynamically allocate resources and quickly deploy new services across the 5G Core and RAN components while improving network agility and reducing capital and operational expenses. NFV is key in supporting the diverse requirements of 5G, from extreme mobile broadband to massive IoT connectivity and ultra-reliable low-latency communications, facilitating the evolution to more programmable, software-driven networks.
2.Cloud and Virtualization Tools ecosystem
What is Virtualization?
Virtualization is a technology that allows one physical machine to behave like many separate machines.
Virtualization lets you use hardware more efficiently and isolate workloads.
What is Cloud?
Cloud is an on-demand delivery of compute, storage, networking, and applications over the internet.
Cloud was built using virtualization, but it adds automation, elasticity, self-service, APIs, scaling, multi-tenancy and more.
Cloud = Virtualization + Automation + Self Service + Scalability
Cloud vs Virtualization
Virtualization | Cloud |
Splits one physical machine into VMs | Provides infrastructure + services over internet |
Focus = resource utilization | Focus = scalability, automation, self-service |
Managed manually or via hypervisor | Managed via dashboards/APIs/orchestrators |
Limited elasticity | Highly elastic – scale in/out instantly |
You provision hardware yourself | Provider delivers resources on demand |
Short answer:
Virtualization is a building block.
Cloud is the entire city built using these buildings.
Where Do Containers Fit?
Virtualization runs virtual machines. Cloud runs VMs + containers + serverless workloads.
Containers(Docker, containerd, CRI-O) = lightweight and faster alternative to VMsKubernetes orchestrates containers → forming modern cloud-native systems.
VM = Heavy, includes OS, slow startup
Container = Lightweight, shares OS kernel, fast startup
The Below image shows a Cloud & Virtualization Tools Ecosystem, organized into layers.
Think of it like building a house:
Layer | What it provides | Without it… |
Infrastructure | The foundation (bare-metal, VMs, cloud) | No compute/storage/networking to run workloads |
Container Runtime | Packaging & running applications in containers | Apps would run directly on OS without isolation |
Orchestration | Managing and scaling many containers across nodes | You would manually start/stop each container |
Service Mesh & Management | Traffic control, packaging, security, monitoring | Large microservice systems would become unmanageable |
1. Infrastructure Layer
Bare Metal → Virtual Machines → Cloud ProvidersThis is the base layer where compute, memory, and networking come from.
Tool | What it is | Why it exists / Use cases |
OpenStack | Opensource private cloud IaaS platform | Create VMs, networks, storage within your data center |
VMware | Hypervisor-based virtualization | Enterprise-grade VM management, vSphere is widely used in telco |
KVM/Xen | Open-source hypervisors | Lightweight virtualization, basis for many telco clouds |
AWS / Azure / GCP | Public cloud providers | On-demand compute, managed Kubernetes, global scale |
Proxmox | Open-source virtualization platform | Small-scale labs, home labs, edge deployments |
2. Container Runtime Layer
Where applications are packaged & executed as containers.
Tool | What it does | Key points |
Docker | Most popular container runtime + image builder | Easy images, builds, registries — widely adopted |
containerd | Lightweight runtime used under Docker | Kubernetes default runtime in many distros |
CRI-O | Kubernetes-native runtime | Built specifically for Kubernetes workloads |
Podman | Daemonless Docker-compatible runtime | Rootless, more secure on hosts |
3. Orchestration Layer
Automates running hundreds or thousands of containers across nodes.
Tool | Description | Why it matters |
Kubernetes (K8s) | Self-healing, autoscaling orchestration platform | Industry standard for CNFs (Cloud-native Network Functions) |
Docker Swarm | Simple clustering for Docker containers | Easier but less powerful than Kubernetes |
Nomad | Lightweight orchestrator by HashiCorp | Multi-runtime (VMs, containers, binaries) flexibility |
Apache Mesos | Resource scheduler for large scale compute farms | Used before Kubernetes dominated |
4. Service Mesh & Management Tools Layer
Enhances communication, lifecycle management, security between microservices.
Tool | Category | Purpose |
Helm | Kubernetes Package Manager | Install/Upgrade CNFs like software packages |
Istio | Service Mesh | Traffic control, security, metrics, canary rollout |
Linkerd | Service Mesh (lightweight) | Simpler alternative to Istio |
Consul | Service Discovery + KV Store | Dynamic service registration + config management |
Envoy | Service Proxy | Forms data-plane of service meshes (sidecar proxy) |
Kustomize | Config Management | Patch/overlay Kubernetes YAML without templates |
Why Telcos Moved to Cloud + Virtualization
Benefit | Impact for Telco |
Scalability | Scale UPF/AMF/SMF during busy hours |
High Availability | Zero-downtime upgrade using Helm/K8s |
Resource Optimization | Run multiple CNFs on same nodes |
Faster Deployment | Deploy new core slice in minutes |
Multi-Site Edge Cloud | Low latency RAN workloads near users |
3.5G End-to-End Cloud & NFV Architecture
5G end-to-end deployments virtualize the core (5GC), RAN (CU/DU/RU), and RIC (Near-RT/Non-RT) on telco cloud stacks, disaggregating functions into CNFs/VNFs for scalability.
Core Components Explained
5G Core (5GC): Virtualized AMF/SMF/UPF microservices handle session management and user plane; deployed as CNFs on Kubernetes for auto-scaling during peaks.
RAN (CU/DU/RU):
CU-CP: Control plane (RRC/PDCP) in central DCs.
CU-UP: User plane (SDAP, PDCP/RLC) near DUs.
DU: Real-time MAC/PHY on edge with DPDK.
RU: Hardware radio with eCPRI to DU.
RIC (RAN Intelligent Controller):
Non-RT RIC: rApps (>1s latency) for AI/ML Optimizations, Policy decisions (e.g., QoS) in central cloud via DMaaS (Data Management).
Near-RT RIC: xApps for beamforming/handover optimization (<10ms latency).
4.Description about Cloud/Virtualization Tools
Kubernetes: CU, DU, 5GC, Edge UPF
Kubernetes (K8s) orchestrates containerized network functions (CNFs) across clusters, automating deployment, scaling, and healing for 5G CU (control/user plane), DU (baseband), 5GC (AMF/SMF/UPF), and edge UPF (user plane function near users). It uses pods for microservices, node selectors for edge placement, and Horizontal Pod Autoscaler (HPA) for traffic spikes; essential for O-RAN multi-vendor interoperability.
Docker/Container: All Containerized NFs
Docker packages NFs into portable OCI-compliant images (e.g., quay.io/5gc-amf:latest), enabling consistent deployment of all CNFs across dev/test/prod. Containers provide isolation, fast startup (<1s vs. VM minutes), and layering for updates; CRI-O/Podman run these images in K8s for 5G, caching locally to reduce pull times during DU restarts.
OpenStack: 5GC (VM-based), CU (Legacy)
OpenStack manages infrastructure-as-a-service (IaaS) for VM-based VNFs, provisioning compute/storage/networks for legacy 5GC (e.g., full AMF VM) and CU in brownfield networks. It creates flavors (e.g., highcpu-du), Neutron networks for Xn/F1, and Heat templates for orchestration; bridges VMs to CNF transition in hybrid telco clouds.
Helm: Package Management for All K8s Workloads
Helm acts as a package manager for Kubernetes, bundling charts (YAML templates + values) for repeatable 5G deployments like helm install open5gs/5gc --set replicas=3. It simplifies versioning, dependencies (e.g., Istio), and upgrades (helm upgrade), reducing manual kubectl apply errors for complex CU/DU/RIC stacks.
Istio/Linkerd: Service Mesh for 5GC, CU Inter-NF
Istio and Linkerd provide service mesh overlays with sidecar proxies (Envoy) for secure communication between 5GC microservices (N4 interface) and CU components (E1/F1). Features include mTLS encryption, traffic splitting (blue-green deploys), observability (Prometheus metrics), and circuit breaking; Linkerd is lighter for edge while Istio offers advanced policy.
KVM/Bare Metal: DU (Performance-Critical)
KVM (Kernel-based Virtual Machine) hypervisor virtualizes on bare metal x86 servers for latency-sensitive DU (MAC/PHY processing), using SR-IOV for direct NIC access and NUMA pinning (numactl) for <100μs jitter. Bare metal bypasses hypervisor overhead entirely for ultimate DU performance in 25Gbps eCPRI fronthaul; DPDK accelerates packets.
K3s/MicroK8s: Lightweight K8s for Edge/DU
K3s (lightweight Kubernetes by Rancher) and MicroK8s (Canonical's single-node K8s) run on resource-constrained edge servers for DU/UPF, embedding etcd and CRI-O with <500MB footprint. Ideal for far-edge cell sites; k3s install deploys in seconds, supporting air-gapped ops with embedded containerd—no full K8s master complexity.
Summary of Tools
Tool | Primary 5G Use | Key Benefit |
Kubernetes | Orchestration | Auto-scaling |
Docker | Packaging | Portability |
OpenStack | IaaS VMs | Multi-tenancy |
Helm | K8s Packages | Templating |
Istio/Linkerd | Traffic Mgmt | mTLS/Resilience |
KVM/Bare Metal | DU Compute | Low Latency |
K3s/MicroK8s | Edge K8s | Lightweight |
5.Telco Cloud Application deployment Workflow
7-Step Deployment Pipeline:
Development Phase - Developers write code for 5G network functions, create Dockerfiles for containerization, and define Helm charts for deployment configuration
Source Control - Code is pushed to Git repositories (GitHub/GitLab) with version tagging and code review processes
CI Pipeline (Build) - Automated testing, security scanning (SAST/SCA), Docker image building, and vulnerability scanning happen automatically when code is committed
Container Registry - Built images are stored in registries (Harbor, Quay, ECR) with proper versioning, signing, and access controls
CD Pipeline (Orchestration) - ArgoCD or Flux automatically deploys applications using Helm charts to Kubernetes clusters with rolling updates and health checks
Infrastructure - Applications run on Kubernetes clusters across different locations (central cloud, edge, RAN sites) on OpenStack VMs or public clouds
Monitoring & Logging - Continuous monitoring with Prometheus/Grafana, log aggregation with ELK/Loki, and alerting systems provide observability
Feedback Loop - Monitoring data feeds back to development for continuous improvement.
6.Cost Savings for Telco Providers:
1. Infrastructure Cost Reduction (30-50%)
Hardware Consolidation: Run multiple VNFs on shared infrastructure instead of dedicated hardware per function
Cloud Economics: Use COTS (Commercial Off-The-Shelf) servers instead of expensive proprietary hardware
Dynamic Resource Allocation: Scale resources up/down based on demand
2. Operational Efficiency (40-60% OpEx reduction)
Automation: CI/CD eliminates manual deployment (reduces human errors and time)
Self-Service: Developers can deploy without waiting for operations teams
Faster Time-to-Market: Deploy new features in hours instead of months
3. Multi-Vendor Flexibility
No Vendor Lock-in: Use best-of-breed components from different vendors
Negotiation Power: Switch vendors more easily, reducing licensing costs
Open Source: Leverage free open-source tools (Kubernetes, Prometheus, etc.)
4. Resource Optimization
Better Utilization: Increase server utilization from 20-30% to 60-80%
Energy Savings: Fewer physical servers = lower power and cooling costs
Space Savings: Reduced data center footprint
5. Faster Innovation
Rapid Testing: Test new features in isolated environments
A/B Testing: Run multiple versions simultaneously
Rollback Capability: Quick recovery from failures
6. Centralized Management
Single Control Plane: Manage all sites from one location
Consistent Deployments: Same process across all locations
Reduced Site Visits: Remote management reduces truck rolls
7.Real-World Case Study:
1) Verizon/VMware Telco Cloud
Verizon deployed vRAN on VMware Telco Cloud (KVM/OpenStack base) with Kubernetes/CRI-O for CU/DU across 20k+ sites: CU-CP on central K8s, DU CNFs on edge with Istio for F1 resilience, achieving 40% cost reduction vs. proprietary RAN. RUs used Nokia hardware with eCPRI to vDU; automated scaling handled 5G traffic spikes via Prometheus-tuned HPA.
Method of Procedure (MOP) for Design & Deployment
Capacity Planning: Model traffic (e.g., 1Gbps/DU); allocate flavors (32C/128G for DU) via OpenStack.
Cluster Provisioning:
kubeadm init --pod-network-cidr=x.x.x.x/16;
install CRI-O (crio install)
label nodes (kubectl label node edge telco-du=true).
CNF Deployment:
Helm install CU/DU charts (helm install cu-cp o-ran-chart);
configure SR-IOV (kubectl apply sriovdp.yaml).
Fronthaul Setup:
Bind RUs to DU via eCPRI sync (PTP/IEEE 1588);
apply Istio VirtualService for F1/E1.
Validation:
RIC testing (xApp deploy for O-RAN);
perf test (tmux iperf3 -c ru-sim);
HA failover (kubectl drain).
Ensures 99.999% uptime.
2) Rakuten Mobile Japan
Rakuten deployed Open RAN on OpenStack/Kubernetes (CRI-O) for 5GC (free5GC CNFs), vRAN (CU/DU on edge K8s), and Near-RT RIC (xApps for mobility). Covering 96% Japan by 2024, it achieved $1B savings using white-box hardware; Istio secured F1 interfaces, scaling to 10M subs with <5ms E2E latency. Non-RT RIC policies via rApps boosted throughput 25%.
Method of Procedure (MOP) for E2E Deployment
Infrastructure Provisioning:
Install KVM (modprobe kvm);
deploy OpenStack (devstack all-in-one for lab, Kolla-Ansible for prod);
create flavors (openstack flavor create --ram 128 du-edge).
Kubernetes Cluster Bootstrap:
kubeadm init --pod-network-cidr=x.x.x.x/16 --cri-socket unix:///var/run/crio/crio.sock (CIDR=Flannel pods, CRI=CRI-O);
taint edge nodes (kubectl taint nodes edge sched=du).
Join workers (kubeadm join).
5GC CNF Deployment:
helm repo add open5gs;
helm install 5gc open5gs/5gc --set upf.image.repository=quay.io/upf:
latest (pulls Docker images).
RAN (CU/DU/RU) Rollout:
SR-IOV: kubectl apply -f sriov-network-device-plugin.yaml.
CU/DU: kubectl apply -f cu-cp.yaml -n ran-ns (--namespace isolates); kubectl apply -f du-cnf.yaml --dry-run=client (validates first).
RU Connect: Configure eCPRI PTP (chronyd.conf); Istio istioctl install --set profile=default -y.
RIC Integration:
Non-RT: OpenStack VM for rApps.
Near-RT: kubectl apply -f near-ric.yaml; E2 SM for xApps.
Validation:
kubectl get pods -n ran; traffic test (iperf3 -c upf-svc);
scale (kubectl autoscale du --min=3 --max=10 --cpu-percent=70).
Monitor (istioctl dashboard proxy-istio).
Ensures greenfield 5G launch in 3-6 months
8.Common telco ops tasks + commands
Check pod/containers status
kubectl get pods -n telco-namespace
kubectl describe pod <pod> -n telco-namespace
kubectl logs <pod> -c containername -n telco-namespace
Scale a component (e.g., UPF dataplane)
kubectl scale deployment upf-deployment --replicas=5 -n telco
Rolling update via Helm
# change image tag in values.yaml then
helm upgrade core-network ./core-chart -n telco --reuse-values
Istio traffic shaping
Canary: modify VirtualService weights to shift traffic.
Fault injection: test resilience by injecting HTTP 500 for a percentage (for testing only).
Debugging network issues
kubectl exec -it <pod> -- /bin/bash
# inside: curl other services, netstat, ip route
Persistent storage (e.g., for HSS/DB)
Use PersistentVolume and PersistentVolumeClaim in k8s, or OpenStack Cinder volumes for VMs.
9.Summary
1. Cloud and virtualization tools let operators deploy networks rapidly without waiting for physical hardware.
2. They enable on-demand provisioning of compute, storage, and network functions as software rather than appliances.
3. New 4G/5G sites or Core instances can be spun up in minutes using automated orchestration instead of days of manual setup.
4. Containerization and Kubernetes make network functions scalable, self-healing, and easy to upgrade with zero downtime. Telcos can expand capacity instantly by adding more VNFs/CNFs rather than installing new boxes.
5. Centralized automation reduces rollout cost, accelerates time-to-market, and supports coverage expansion at scale.
Overall, these tools transform network buildout from hardware-driven to software-driven — faster, flexible, and future-ready.
10.References
1. 3GPP TS 23.501 System Architecture for the 5G System (5GS)
2. 3GPP TS 28.500 — Management concept, architecture and requirements for mobile networks that include virtualized network functions (VNFs).
3. O‑RAN Architecture Description (version v14.0)
Comments