How CNF Cloud‑Native Networking Is Transforming 5G Core and Access

CNF Evolution and Core‑Network Deployment

Physical network functions (PNF) → Virtual network functions (VNF) on virtual machines → Cloud‑native network functions (CNF) as containers in Kubernetes Pods. CNF removes hypervisor overhead, enables elastic scaling, high availability, and integrates with DevOps pipelines (CI/CD, service mesh).

In 5G Service‑Based Architecture (SBA) core elements such as NRF and NSSF are packaged as CNF Pods. Each Pod runs an Istio sidecar proxy to provide service‑mesh capabilities (HTTP, gRPC, TCP). The sidecar handles inter‑pod communication, health checks and traffic routing.

Gray‑release workflow for core CNFs

Publish a new container image to a private registry.

A listener component detects the new tag.

Jenkins pulls the image and updates the deployment.

Traffic is shifted gradually according to a configurable rollout percentage.

If health checks fail, the deployment rolls back to the previous version.

SDEWAN: CNF‑based SD‑WAN for the Access Network

SDEWAN implements SD‑WAN functionality inside a Kubernetes cluster. It provides WAN link support, traffic management, NAT, firewall, IPSec, and traffic shaping, targeting edge scenarios with limited resources.

Key components

SDEWAN CNF : Exposes a RESTful API for configuring network functions.

SDEWAN CRD Controller : Watches custom resources (Firewall, IPSec, MWAN) and translates them into SDEWAN API calls.

Overlay Controller : Central controller that manages overlay networks across multiple Kubernetes clusters.

Data plane is handled by VPP, control plane by FRR, and management functions by Sweetcomb.

SDEWAN CNF internal architecture

The CNF Pod contains multiple containers: VPP – high‑performance data‑plane forwarding (L2/L3, VXLAN, IPSec, etc.). FRR – routing protocols (BGP, OSPF) and control‑plane logic. Dnsmasq – DHCP/DNS services. Sweetcomb – management plane that receives configuration from the CRD controller.

CRD Controller workflow

The controller watches the Kubernetes API for custom resources, stores the desired state in etcd, and invokes the SDEWAN CNF REST API to apply configuration. This decouples the Kubernetes control plane from the CNF data plane.

Overlay Controller

Provides a unified REST API (API Router) for managing overlay networks across clusters. It registers overlay objects, hubs, devices, IP ranges, and proposals in etcd, and exposes observability metrics for CNF health.

Design principles and future directions

Full lifecycle management aligned with cloud‑native best practices (Kubernetes orchestration, stateless configuration, CI/CD).

Performance optimizations via user‑space data planes, kernel bypass, and eBPF where applicable.

Hybrid deployment models (bare‑metal, VM, KubeVirt, Virtlet, Kube‑OVN) to balance resource efficiency and isolation.

Edge‑focused lightweight CNFs for access‑network functions; core‑network CNFs with service‑mesh enabled micro‑service architectures.

Observability, scalability, and flexible plug‑in architecture to integrate emerging services (e.g., Cloud Firewall, vCMTS).

References

CNCF. "How to migrate NF or VNF to CNF without vendor lock‑in" (2020).

Akraino. "Integrated Cloud Native NFV/App stack family / SDEWAN" (2021).

Various academic papers on NFV/CNF evolution (2021‑2022).