Nephio: Kubernetes Orchestration for 5G Networks

• Nephio is a cloud-native, Kubernetes-based automation substrate that converts high-level network intent into declarative deployment artifacts across distributed infrastructures.
• It integrates with GitOps practices by translating intents stored as configuration data into package artifacts and coordinating deployments through established workflows.
• Nephio supports end-to-end slice realization and resource automation in 5G and beyond networks, serving as the operational layer between intent declaration and cluster execution.

Searching arXiv for papers on Nephio to ground the article in published work. Nephio is a cloud-native automation solution used to realize intent-driven orchestration of distributed network infrastructure and containerized network functions in 5G and beyond-5G systems. In the available arXiv literature, Nephio is presented not as a radio-control algorithm or a runtime reconciler, but as an upstream orchestration substrate that accepts high-level intent, transforms it into declarative deployment artifacts, and coordinates infrastructure and workload realization across distributed Kubernetes environments (Tran et al., 2024, Ghosh et al., 17 Sep 2025). In this role, it occupies the layer between service-level intent and cluster-level execution: in one line of work it underpins end-to-end slice realization across edge, regional, and central data-center pools within an O-RAN-based testbed (Tran et al., 2024), while in another it is analyzed as a Configuration-as-Data intent-processing layer integrated with GitOps tooling, where its processing latency and orchestration overhead are explicitly benchmarked (Ghosh et al., 17 Sep 2025).

1. Definition and architectural role

Nephio is described as a Kubernetes-based, cloud-native automation substrate for multi-site environments that manages infrastructure, resources, and virtualized or containerized network functions through declarative workflows (Tran et al., 2024). Its primary architectural function is to bridge high-level operator intentions and the desired infrastructure or workload state actually deployed across clusters.

In the intent-driven networking formulation reported in the literature, Nephio accepts intent represented as configuration values in the Kubernetes Resource Model. Within that formulation, intent is treated as Configuration as Data, decoupled from application code and deployment manifests, and Nephio translates that intent into declarative deployment artifacts that are then published into Git for downstream reconciliation (Ghosh et al., 17 Sep 2025). This makes Nephio an orchestration and package-processing layer rather than the component that directly performs cluster drift detection or healthy-state convergence.

A consistent theme across the cited works is separation of concerns. Nephio realizes desired state in infrastructure and network-function deployment, whereas optimization and control logic reside elsewhere. In the INA-Infra system, for example, Nephio manages the cloud and edge substrate and the placement and configuration of containerized network functions, while a Resource Management rApp and a Network Slicing xApp perform SLA-aware optimization and radio control in the O-RAN hierarchy (Tran et al., 2024). A plausible implication is that Nephio is most accurately understood as an execution-oriented orchestration layer in a larger hierarchical control loop.

2. Position in intent-driven 5G and O-RAN systems

The most detailed system-level use of Nephio in the supplied literature is INA-Infra, an open and extensible 5G/beyond-5G infrastructure designed for intent-driven network automation and end-to-end slicing (Tran et al., 2024). In that architecture, the Service Management and Orchestration domain provides service management and orchestration, including creation of end-to-end network slices, while the O-Cloud layer manages physical resources and deployment-management services for O-RAN functions. Nephio is the mechanism through which the platform manages network infrastructure, distributed resources, and the lifecycle of containerized network functions.

The execution environment consists of distributed data-center pools labeled Central, Regional, and Edge, on which the 5G Core and RAN functions run. The core side includes AMF, SMF, UPF, and NSSF; the RAN side includes CU-CP, CU-UP, DU, and RU; RU is implemented with USRPs; and OAI software provides the 5G CN and RAN stack used in the experiments (Tran et al., 2024). The paper explicitly states that DU, CU-UP, CU-CP, UPF, and SMF are deployed as Kubernetes resources managed by Nephio.

This placement of Nephio in the system architecture is operationally significant. High-level slice SLA requirements, such as delay and throughput, originate at the management side and are translated into low-level realizations in the cloud domain. The paper states that “MNOs define the high-level intention SLA (delay and throughput) in the NSMF, which will be translated to Nephio API to be realized in the O-Cloud platform” (Tran et al., 2024). Nephio is therefore the layer that materializes standards-level lifecycle concepts into runnable deployments on distributed Kubernetes-managed infrastructure.

The same work also situates Nephio relative to O-RAN interfaces and control domains. The Non-RT RIC hosts a Resource Management rApp; the Near-RT RIC, implemented with FlexRIC, hosts a Network Slicing xApp; and Nephio operates as the infrastructure and workload automation mechanism that makes resulting topology and resource decisions actionable across the distributed clusters (Tran et al., 2024). This suggests a strict orchestration-versus-optimization decomposition rather than an all-in-one autonomic controller.

3. Declarative workflow, package processing, and GitOps integration

A second paper analyzes Nephio as the intent-processing and Configuration-as-Data orchestration layer in front of a GitOps deployment pipeline (Ghosh et al., 17 Sep 2025). This work makes explicit the internal workflow elements that are only implicit in the INA-Infra paper.

The architecture includes a Blueprint Repository holding intents as Kpt packages, referred to as Dry Packages; a Package Variant Set that tracks revisions of Dry Packages in the Blueprint Repository through webhooks; Porch, used by Nephio to hydrate Dry Packages into Hydrated Packages; a Deployment Repository holding processed declarative deployment packages; and a downstream GitOps operator, specifically Argo CD, Flux CD, or ConfigSync, which watches the Deployment Repository main branch as the Single Source of Truth (Ghosh et al., 17 Sep 2025). Kubernetes then executes the runtime deployment.

The package lifecycle during Nephio hydration is given explicitly as four states: draft, proposed, approved, and published (Ghosh et al., 17 Sep 2025). During hydration, Nephio creates a Draft branch in the Deployment Repository and later merges processed outputs into the main branch. Only after publication into the main branch do the GitOps reconcilers take over. This establishes a precise division of labor: Nephio performs intent-to-manifest transformation and package orchestration; the GitOps operator performs synchronization, reconciliation, and rollout into the cluster.

The following table summarizes the components and functions explicitly attributed to Nephio in the GitOps-integrated evaluation.

Component	Role	Repository/state
Blueprint Repository (BPR)	Holds intents as Kpt Dry Packages	Upstream intent source
Package Variant Set (PVS)	Tracks package revisions via webhooks	Revision tracking
Porch	Hydrates Dry Packages into Hydrated Packages	draft → proposed → approved → published
Deployment Repository (DPR)	Stores processed deployment artifacts	Draft branch, then main branch

This workflow is important because it formalizes Nephio as an upstream declarative orchestrator rather than a direct substitute for GitOps operators. The cited paper explicitly frames Nephio as feeding, not replacing, the GitOps benchmark pipeline (Ghosh et al., 17 Sep 2025).

4. Realization of slicing, placement, and distributed resource automation

In end-to-end slicing scenarios, Nephio’s role is to instantiate and place slice-specific cloud-native functions across data-center pools in accordance with slice intent and resource constraints (Tran et al., 2024). The cited work defines a network slice as a logical network composed of RAN resources such as CU-UP, CU-CP, DU, and PRBs, together with core services including UPF and SMF on shared distributed infrastructure. Shared functions such as AMF, CU-CP, and DU may be common across slices, whereas data-plane functions such as CU-UP and UPF may be dedicated per slice (Tran et al., 2024).

In this framework, Nephio handles slice realization in the compute and cloud domain. The core NSSF handles slice selection for UEs, and RIC applications handle SLA-aware control in the RAN domain (Tran et al., 2024). This division matters because it prevents conflation of slice instantiation with slice optimization. Nephio instantiates the functions and enforces target deployment state; it does not itself compute PRB allocations or compute-resource reallocations.

The intent-to-placement logic is motivated by delay-cost tradeoffs. Low-latency slices place CU-UP and UPF closer to the edge, while more delay-tolerant slices can use regional or central resources at lower cost (Tran et al., 2024). The relevant latency relation is reported as

$$t^s = t^s_{UE-DU} + t^s_{DU-CU} + t^s_{CU-UPF} < \tau_{SLA}^s$$

where $t^s$ is the end-to-end delay for slice $s$, $t^s_{UE-DU}$ is the UE-to-DU delay, $t^s_{DU-CU}$ is the DU-to-CU delay, $t^s_{CU-UPF}$ is the CU-to-UPF delay, and $\tau_{SLA}^s$ is the slice delay bound from the SLA (Tran et al., 2024). Within the system, Nephio affects the terms associated with placement across Edge, Regional, and Central pools by determining where CU-UP and UPF are deployed.

The same paper reports an estimated slice-throughput expression,

$$\begin{aligned} \rho_s = & \sum_{d\in \{C,R,E\}} f(c_{CU,d}^s , r_{CU,d}^s)\cdot x^s_d + \ & \sum_{d\in \{C,R,E\}} g(c_{UPF,d} , r_{UPF, d})\cdot y^s_d \end{aligned}$$

with an example linear form for CU-UP,

$$f(c_{CU,d}^s , r_{CU,d}^s) = \alpha \cdot c_{CU,d}^s + \beta \cdot r_{CU,d}^s$$

and a deployment-cost model,

$$\begin{aligned} \gamma_s = \sum_{d\in \{C,R,E\}} m(C_{CU,d} , R_{CU,d})\cdot x^s_d + \ \sum_{d\in \{C,R,E\}} n(C_{UPF,d} , R_{UPF,d}) \cdot y^s_d \end{aligned}$$

where the variables indicate whether CU-UP and UPF are deployed at a given data-center pool and how CPU and RAM allocations map to throughput and cost (Tran et al., 2024). These are not Nephio-internal formulas, but they define the decision space within which Nephio operates as the realization engine.

5. Runtime control loop and relation to rApps and xApps

The literature makes a strong distinction between Nephio’s orchestration role and the optimization functions implemented by O-RAN applications. In INA-Infra, telemetry from O1 and E2 and slice-performance monitoring feed the Resource Management rApp and the Network Slicing xApp (Tran et al., 2024). If SLA violations or resource stress occur, the Resource Management rApp computes reconfiguration actions, especially CPU and RAM reallocations for CU-UP and UPF and associated slice-management actions, while the Network Slicing xApp adjusts RAN PRB allocations via E2 (Tran et al., 2024).

Nephio’s role in this loop is to realize infrastructure and workload state changes in the Kubernetes domain after those decisions are produced. The paper describes the closed loop as intent to orchestration decision to Nephio deployment and configuration to telemetry to rApp and xApp optimization to updated orchestration actions to Nephio reconciliation (Tran et al., 2024). This formulation makes clear that Nephio is an actuator-like declarative orchestrator within a hierarchical control stack.

The practical significance of this separation is visible in the experiments. In one experiment, slices with different throughput and delay SLAs are placed in Central, Regional, or Edge pools depending on latency and cost considerations, with low-level actions consisting of data-center placement plus PRB allocation (Tran et al., 2024). Nephio is responsible for the data-center-side instantiation of per-slice functions, while the xApp handles the PRB side. In another experiment, multiple slices are concentrated at the Edge data center, producing compute overload; the Resource Management rApp then issues reconfiguration requests to adjust CPU and RAM allocations, and the orchestration layer implied by Nephio and O-Cloud makes those changes take effect for Kubernetes-managed workloads (Tran et al., 2024).

A common misconception is to treat Nephio as the component that computes optimal resource allocations. The available papers do not support that interpretation. They consistently present Nephio as the orchestration substrate that enacts desired topology, placement, and configuration state, while optimization is delegated to external logic such as rApps and xApps (Tran et al., 2024).

6. Measured performance, overheads, and operational observations

The most direct empirical evaluation of Nephio itself is provided by the benchmarking study of GitOps and intent-based networking scenarios (Ghosh et al., 17 Sep 2025). This paper measures the additional latency that Nephio introduces before standard GitOps reconciliation and Kubernetes deployment begin.

The key timing terms relevant to Nephio are $t^s$0, hydration time; $t^s$1, intent-processing time; and $t^s$2, orchestration overhead time (Ghosh et al., 17 Sep 2025). The paper explicitly defines Nephio’s timing model as

$t^s$3

with $t^s$4 including time to bring up the Package Variant Set, establish the webhook between PVS and BPR, and discover Draft Packages in the Deployment Repository (Ghosh et al., 17 Sep 2025). The paper states that $t^s$5 is proportional to the number of intents.

For single-intent processing, Nephio introduces a mean near-constant latency in the range $t^s$6 to $t^s$7, with summary statistics reporting $t^s$8 mean $t^s$9 and standard deviation $s$0 (Ghosh et al., 17 Sep 2025). For multi-intent processing, the paper reports an internal inconsistency: the narrative gives mean $s$1, while the summary table gives mean $s$2, with $s$3 and $s$4 in the table, but $s$5 in the text (Ghosh et al., 17 Sep 2025). The paper nevertheless treats the qualitative result as stable: hydration is around $s$6 seconds, orchestration overhead is several seconds, and multi-intent average processing is lower than single-intent processing because Kubernetes instantiates package variants simultaneously (Ghosh et al., 17 Sep 2025).

The following table summarizes the explicit Nephio timing values reported in that study.

Scenario	Metric	Reported value
Single intent	$s$7 mean	17.9 s
Single intent	$s$8 std dev	0.91 s
Multi-intent	$s$9 mean	7.79 s or 11.2 s
Multi-intent	$t^s_{UE-DU}$0 mean	4.97 s
Multi-intent	$t^s_{UE-DU}$1 mean	2.73 s or 6.16 s

The same paper argues that Nephio’s intent-processing latency is almost constant per intent under default Porch settings and scales linearly with the number of intents, while also observing that average per-intent processing can decrease in concurrent multi-intent batches because of simultaneous package-variant instantiation (Ghosh et al., 17 Sep 2025). This suggests that total work scales upward with the number of intents, but average per-intent delay may benefit from concurrency.

Operational observations in INA-Infra complement these timing results indirectly. That paper reports resource usage including the Nephio Workload Cluster itself, with 150 ms CPU and 1180 MB RAM for the baseline Nephio workload cluster in its testbed resource table (Tran et al., 2024). It also notes that the central data center is used for the OAI 5GC, all data centers can host OAI RAN functions, and each VM has a Nephio Workload Cluster to manage network functions (Tran et al., 2024). By contrast, the GitOps benchmarking paper explicitly does not provide separate CPU or memory utilization measurements for Nephio itself (Ghosh et al., 17 Sep 2025). The two papers therefore illuminate different aspects of operational cost: INA-Infra reports a concrete deployment footprint in one testbed, whereas the benchmarking study focuses on orchestration latency.

7. Limitations, ambiguities, and scope of current evidence

The current arXiv evidence presents Nephio primarily through system-integration and benchmarking studies rather than a dedicated low-level internals paper. Several limitations follow from that fact.

First, neither paper exposes full implementation artifacts for Nephio internals. The INA-Infra paper does not discuss package revisions, package variants, Porch package orchestration, specific custom resource definitions, or named custom Nephio resource definitions (Tran et al., 2024). The benchmarking paper provides more detail through BPR, PVS, Porch, DPR, and package states, but still omits exact Nephio and Porch versions, exact timestamp capture points for each Nephio substage, and exact reconciliation-period configuration values beyond referring to default Porch settings (Ghosh et al., 17 Sep 2025).

Second, quantitative evidence is functionally informative but incomplete. INA-Infra demonstrates end-to-end slice instantiation, placement, and adaptation on a three-VM distributed testbed aligned with edge/cloud NextG research, but does not provide formal scalability studies, reconciliation latency measurements for Nephio, provisioning-time breakdowns, or comparisons against a non-Nephio orchestration baseline (Tran et al., 2024). The GitOps benchmarking paper explicitly measures Nephio’s preprocessing delay, but does not give a full measured end-to-end timing decomposition combining Nephio processing with downstream GitOps synchronization, reconciliation, deployment, and healthy-state convergence (Ghosh et al., 17 Sep 2025).

Third, there are reporting inconsistencies. The benchmarking paper contains an internal inconsistency in the multi-intent Nephio values between narrative text and summary table (Ghosh et al., 17 Sep 2025). This does not negate the qualitative conclusion that Nephio adds a stable and nontrivial preprocessing delay, but it does limit the precision with which the exact latency budget can be cited.

Fourth, the empirical scope remains narrow. The GitOps benchmarking uses a lightweight Nginx application template as the desired-state artifact, and the authors acknowledge the need for future heterogeneous benchmarks such as standard network functions and 5G core scenarios (Ghosh et al., 17 Sep 2025). INA-Infra, meanwhile, is a small-scale research platform with three virtualized data-center pools and a limited number of slices and UEs (Tran et al., 2024). Large-scale multi-site behavior, consistency management across layered controllers, conflict resolution among policies, and broader reproducibility of the exact Nephio control-plane implementation remain open questions.

Taken together, the published evidence supports a technically specific view of Nephio. It is a Kubernetes-native, declarative orchestration substrate that turns high-level network intent into deployable desired state, manages distributed infrastructure and containerized network functions across cloud and edge environments, and provides the execution layer through which slice instantiation and subsequent reconfiguration are realized (Tran et al., 2024, Ghosh et al., 17 Sep 2025). The same evidence also indicates that this abstraction carries a measurable preprocessing cost, especially under default Porch settings, and that current public reports characterize Nephio more as an operational enabler within larger intent-driven systems than as a fully specified standalone control-plane architecture (Ghosh et al., 17 Sep 2025).