# Towards Cloud-Native Configuration Management in the 5G Core Network

Vitor Kussler Veronese, Zhiyi Zhang, Jean-François Maudoux, Ilhem Fajjari, Nadjib Aitsaadi

► To cite this version:

Vitor Kussler Veronese, Zhiyi Zhang, Jean-François Maudoux, Ilhem Fajjari, Nadjib Aitsaadi. Towards Cloud-Native Configuration Management in the 5G Core Network. 2026. hal-05515130

HAL Id: hal-05515130

https://uvsq.hal.science/hal-05515130v1

Preprint submitted on 17 Feb 2026

**HAL** is a multi-disciplinary open access archive for the deposit and dissemination of scientific research documents, whether they are published or not. The documents may come from teaching and research institutions in France or abroad, or from public or private research centers.

L'archive ouverte pluridisciplinaire HAL, est destinée au dépôt et à la diffusion de documents scientifiques de niveau recherche, publiés ou non, émanant des établissements d'enseignement et de recherche français ou étrangers, des laboratoires publics ou privés.

<figure><img src="image_1.png" /></figure>

Distributed under a Creative Commons CC BY 4.0 - Attribution - International License
# Towards Cloud-Native Configuration Management in the 5G Core Network

Vitor Kussler Veronese*†, Zhiyi Zhang‡, Jean-François Maudoux*, Ilhem Fajjari*, Nadjib Aitsaadi‡

*Orange Innovation, F-92320, Châtillon, France

†Université Paris-Saclay, UVSQ, DAVID, F-78035, Versailles, France

Emails: (firstname). (lastname)@{*orange.com, uvsq.fr}

**Abstract**—This paper proposes a novel framework for autonomous configuration management in 5G core networks, aimed at improving adaptability, efficiency, and operational resilience. The proposed architecture introduces intelligent mechanisms to automate configuration processes, enabling the network to dynamically adjust to changing conditions and service requirements with minimal human intervention. To validate our approach, we implement and evaluate the framework through a series of experimental scenarios, demonstrating its feasibility and highlighting its potential to enhance performance and simplify the management of next-generation network infrastructures.

**Keywords**—5GC, Configuration Management, Automation

## I. INTRODUCTION

Cloud-native 5G core (5GC) deployments replace a handful of monolithic network elements with hundreds of containerized microservices distributed across clusters. This shift greatly improves agility and scale, but it also multiplies configuration parameters, cross-NF dependencies, and opportunities for drift between intended and actual states. The operational stakes are high, missteps in configuration management have triggered large-scale outages, such as the 2022 incident in Canada, where an error cascaded into a national service disruption affecting more than 12 million customers and critical services [1].

Configuration management (CM) comprises coordinated processes, planning, identification, change control, status accounting, and audit, to maintain configuration integrity throughout the product/service life cycle [2]. In the 5GC context, this means managing CNF configuration that is spread across Kubernetes manifests, Helm charts, and vendor-specific artifacts, while handling frequent lifecycle events (scale, restart, migration) and cross-function relationships. Traditional manual and imperative practices are no longer sustainable at this complexity level. They are error-prone, hard to audit, and slow to recover after failures. Declarative, version-controlled approaches such as GitOps are therefore essential to ensure consistency, traceability, and rollback safety, but they must be integrated into a 5G-aware automation architecture to be effective in production.

Standards bodies have laid important foundations. 3GPP SA5 has defined the Service-Based Management Architecture (SBMA) and the 5G Network Resource Models (NRMs) to represent managed entities and their configuration. ETSI's ZSM and NFV workstreams promote zero-touch, closed-loop operations, and TM Forum's Autonomous Networks framework articulates the journey toward higher autonomy levels. Despite this progress, a practical gap remains for operators building cloud-native 5GCs: there is no de facto, standards-aligned blueprint for Kubernetes-native, declarative CM with

end-to-end auditability, and explicit GitOps integration with a Source of Truth (SoT). In particular, current specifications offer limited guidance in regards to technologies that are widely used in the industry.

This paper addresses that gap by presenting an architecture from an automation-first perspective and validating it on an OAI-based 5GC testbed. Our focus here is the architecture and operation of the Network Automation Layer. How declarative artifacts are modeled, persisted, synchronized, and enforced across CNFs with deterministic workflows. Together with a concise discussion of the hierarchical automation strategy that cleanly separates higher-level "intelligence" from execution.

Our approach is Kubernetes-native by design. It represents 5GC configuration via Custom Resource Definition (CRD) aligned to 3GPP TS 28.541 [3] and persists desired state in a Git-backed Configuration Management Database (CMDB) that acts as the SoT. Changes are propagated to CNFs via a GitOps toolchain, supporting both passive (pull) and active (push) modes. Deterministic workflows enforce idempotent execution, retries, and rollbacks, ensuring reproducibility and auditability. We also provide a brief mapping between the proposed architecture components and SBMA roles (e.g., MnS producer/consumer, managed entities), clarifying how the architecture realizes service-based management in containerized environments.

A standards-aligned, Kubernetes-native CM blueprint for cloud-native 5GC: CRDs mapped to 3GPP NRMs, GitOps-based SoT, and support for both active and passive propagation modes. A hierarchical automation model that cleanly separates higher-level intent understanding from deterministic execution, delivering auditability, fault handling, and safe rollbacks for mission-critical operations. A reference implementation using FluxCD and a workflow engine to provide deterministic orchestration, validated on an OAI 5GC testbed with representative E2E configuration scenarios. Empirical evidence on configuration and propagation latency, resource footprint, error handling, and rollback behavior, together with operational insights on sync-interval versus latency trade-offs and SBMA-aligned deployment practices.

This paper makes four contributions. Firstly, it proposes a standards-aligned, Kubernetes-native blueprint for 5GC configuration management, using CRDs mapped to 3GPP NRMs, a GitOps-backed source of truth, and both pull (passive) and push (active) propagation. Second, it introduces a hierarchical automation model that cleanly separates intelligence and decision making from deterministic execution, providing end-to-end auditability, robust fault handling, and safe rollbacks. Third, it delivers a reference implementation that
<figure><img src="image_2.png" /><figcaption>Fig. 1: Layered architecture for Configuration Management of the 5GC</figcaption></figure>

combines GitOps tools with a workflow engine and validates the approach on an OAI 5GC testbed using representative end-to-end scenarios. Finally, it presents empirical results related to configuration operations.

## II. LAYERED ARCHITECTURE FOR CONFIGURATION MANAGEMENT OF THE 5GC

Building on the analysis of current related work and standardization efforts, our proposed architecture is designed to address the limitations identified in both the state of the art and existing 3GPP management frameworks. To do so, it introduces a modular and hierarchical design that unifies deterministic automation, declarative configuration, and intelligent orchestration to address limitations of current approaches.

### A. Architecture Overview

As illustrated in Fig. 1, the architecture is organized into three complementary domains: i) Network Automation Layer, ii) Intelligence Layer, and iii) Access Layer.

* **Network Automation Layer:** it represents the operational domain where Cloud Native Function (CNF)s are instantiated, configured, and maintained within Kubernetes environments. Its main role is to translate high-level configuration intents into executable platform-level parameters, ensuring alignment between the desired and actual network states.

To do so, this layer adopts a GitOps-driven and declarative design that integrates configuration logic directly into Kubernetes. A centralized CMDB serves as the Source of Truth (SoT), providing version-controlled configurations and full auditability. Through the use of Custom Objects and API extensions, configuration and operational data are represented natively in Kubernetes, removing the need for external configuration scripts. The layer supports both active (push-based) and passive (pull-based) configuration

modes.

Controllers, such as the DB, SMF, and UPF clients, interface with the custom objects that may be dynamically changed with a GitOps engine to ensure deterministic synchronization of network states. Such controllers are also responsible for the interaction with the deployed 5GC for CNF configuration. They may follow a declarative approach or make the bridge to an imperative based implementation, such as done with SDCIO [4].

This design keeps future standardization options open by using the Network Automation Layer as a clear boundary between what should be standardized and what can remain implementation-specific. We highlight two practical paths. First, standardize the high-level data model in the SoT. This provides a stable interface to the Intelligence Layer while allowing controllers to be implemented freely. Second, standardize the controller interfaces, which reduces vendor lock-in and enables true multi-vendor management. With these choices, the Network Automation Layer replaces vendor-specific scripts and tightly coupled tooling with a standardized, declarative, and auditable model.

* **Intelligence Layer:** it serves as the coordination and intelligence plane, translating high-level service intents into executable workflows across multiple network automation layer domains. It provides a unified and contextual network view, ensuring policy consistency, operational traceability, and efficient orchestration across distributed cloud-native components.

In SBMA terms, the Intelligence Layer hosts a Configuration Management Function (CM-MnF) that aggregates across domains. It acts as an MnS Consumer to gather inputs from other MnFs (e.g., inventory/topology,
fault/performance, intent/policy) and as an MnS Pro-
ducer to expose higher-level CM services upstream. This
CM-MnF collaborates with FCAPS MnFs and intel-
ligence/policy MnFs to plan, validate, and coordinate
configuration changes.

The CM-MnF publishes composite, SBMA-compliant
MnS for configuration management, such as
intent-to-config, request execution, status, and rollback.
These services enable OSS/BSS tools to request, track,
and govern configuration changes in a vendor-neutral
way.

The CM-MnF primarily consumes lower-layer informa-
tion through SBMA's subscription/notification pattern. It
registers subscriptions to domain MnS producers (con-
trollers/CNFs) for provisioning status, inventory/topology
changes, alarms, performance KPIs, and configuration-
drift events. Such checks allow for close-loop implemen-
tations, as feedback from the implementation is acquired.
A single Intelligence Layer deployment can oversee many
Network Automation Layer domains (for example, differ-
ent clusters, regions, or vendors). This boosts scalability
by running domain tasks in parallel, isolating failures to
each domain, and allowing simple horizontal growth by
adding domains or replicating the Intelligence Layer as
load increases.

*   **Access Layer:** The access layer represents the interface domain through which human operators, higher-level orchestration systems, or external applications interact with the configuration management framework. It forms the entry point for expressing configuration intents and monitoring operational states. This layer establishes the bridge between human intent and the automated execution mechanisms managed by the intelligence and network automation layers.

The access layer enables intent-driven and human-in-
the-loop interaction through a unified and programmable
API. Operators or external systems can express configu-
ration objectives in natural language or through structured
declarative models. It also implements human-in-the-
loop controls, essential component for higher levels of
autonomy.

B. *Hierarchical Automation Strategy*

The automation strategy relies on a hierarchical model that separates intelligence from execution. At the Intelligence layer, artificial intelligence models interpret user intents and translate them into executable configuration operations, while the network automation layer focuses on accurate and deterministic application of these configurations derived from the SoT. This design centralizes cognitive processing and reasoning in a single system capable of managing multiple domains efficiently while keeping edge components lightweight and execution-oriented. By doing so, the solution mitigates the limitations of existing configuration models and the possibility of a misconfiguration, as it reduces the risk linked to weak data typing and dependency handling, and ensures a clear separation between configuration definition and implementation.

Closed-loop automation is considered as a main component
for enabling level 4 autonomy in the network. In the described
architecture two integration methods may be envisioned for

such functionality, firstly at the network automation layer, with
GitOps being the main enabler of such changes, and secondly
at the Intelligence Layer, where the loop may be closed with
intent inputs (natural language or structured). In both cases
another component would be responsible for autonomously
detecting the need for changes, such as other functions related
to FCAPS (e.g. Fault Management Function, Performance
Management Function). Such developments are expected to be
developed in the near future but are out-of-scope in regards to
this study.

While 3GPP specifications provide a solid foundation for
management automation, they require clearer guidance on
the Service-Based Management Architecture (SBMA) and its
integration within containerized environments. We address this
by extending 3GPP concepts toward Kubernetes-based man-
agement through declarative configuration, custom resources,
and GitOps-driven operations, thereby supporting both active
and passive configuration models.

III. PERFORMANCE EVALUATION

A. *Experimental Environment*

To evaluate our proposal, we develop a testbed, which includes
all the architecture's components illustrated in Fig. 1. This
testbed also includes the proposed hybrid Large Language
Model (LLM) orchestration.

To validate our framework under realistic operating condi-
tions, we deploy a Kubernetes-based environment. The ex-
perimental setup is built on a Kubernetes cluster (v1.32.0)
orchestrated using Kind (v0.26.0) and Docker (v28.1.1). The
cluster is deployed on a bare-metal Ubuntu 22.04 system run-
ning Linux kernel 6.8.0-79-generic with x86_64 architecture.
The underlying hardware configuration includes an Intel Core
i7-1185G7 CPU, 32 GB RAM, and a 938 GB NVMe SSD.
The Kubernetes cluster comprises two nodes, with the worker
node configured to provide 8 allocable vCPUs and 31 GB
of allocable memory. All Kubernetes resources are managed
through FluxCD following a GitOps-based deployment model.
For testing, we use UERANSIM [5] to simulate the radio access
network.

The proposed system architecture integrates multiple in-
terdependent components to enable dynamic, automated, and
cloud-native network management. The core network func-
tions are deployed using a modified release of the Open Air
Interface (OAI) platform (v2.1.0) [6], in which customized
Session Management Function (SMF) and User Plane Func-
tion (UPF) pods support runtime reconfiguration and adaptive
policy enforcement. Custom Kubernetes controllers are imple-
mented in Go using the Operator SDK [7] and Kubebuilder,
with data models aligned to the 3GPP Network Resource
Models (NRMs) defined in 3GPP TS 28.541 [3]. Workflow
orchestration is realized through the Temporal framework [8],
leveraging Cassandra for state persistence and Elasticsearch
for observability and event tracing.

B. Performance Metrics

To evaluate the effectiveness and efficiency of the framework,
we define the following performance metrics:

S<sub>conf</sub> **Configuration Success Rate:** The ratio of successful configuration operations to the total number of demands to the API for a configuration operation, reflecting the reliability of the system.
<caption>TABLE I: Performance comparison</caption>

Sconf: 100%
Tconf: 58 ± 0.5 (s)
Tprop: 70 ± 5.7 (s)
Cctrl: 32.5 ± 0.3 (cpu-s)
Mctrl: 57 ± 1.8 (MB)

Tconf **Configuration Operation Time:** The delay between the submission of a natural-language configuration intent to the Central Controller API and the successful persistence of the generated configuration artifact within the CMDB.

Tprop **Configuration Propagation Time:** The delay between the successful persistence of a generated configuration artifact within the CMDB and the same configuration being present in the respective CNF.

Cctrl **Central Controller CPU Consumption:** The total amount of CPU resources (in CPU-seconds) consumed by the central controller during the execution of a configuration operation.

Mctrl **Central Controller Memory Consumption:** The total amount of memory (in MB) consumed by the central controller during the execution of a configuration operation.

### C. Scenario Description

To comprehensively evaluate the proposed architecture, one comprehensive end-to-end scenario is designed and deployed in our testbed environment.

The objective of this scenario is the end-to-end evaluation of the architecture automation capabilities.

It demonstrates the full automation loop of the system, validating dynamic intent interpretation, configuration translation, and automated propagation through the OAI 5GC framework. Although current open source 5GC implementations support a limited subset of configurable parameters, this scenario effectively leverages these capabilities to assess Data Network Name (DNN) configuration management, specifically Create, Read, Update, Delete (CRUD) operations, natively supported by OAI, and involving the configuration of the SMF, UPF and subscriber database.

The reported values correspond to the mean performance and the associated 95% confidence interval.

### D. Experimental Results Analysis

The performance of the automation process across the aforementioned configuration is summarized in TABLE I.

As summarized in TABLE I, the workflow system achieves a configuration success rate ($S_{conf}$) of 100%, demonstrating high reliability in automating configuration deployment for DNN operations. The configuration operation time ($T_{conf}$) averages approximately one minute, which, while not suitable for real-time updates, remains acceptable for management-layer automation where configuration events occur less frequently. The resource consumption of the Central Controller ($C_{ctrl}$ and $M_{ctrl}$) remains moderate, confirming the efficiency and feasibility of the implemented architecture.

Regarding the configuration propagation stage (i.e, from the CMDB to the 5GC CNFs), the results show an average propagation delay of about one minute, with an additional ten seconds required for the CNFs to apply the updated configuration. This latency can be reduced through more frequent monitoring cycles at the cost of higher resource usage.

We highlight that our system has built-in fault tolerance mechanisms that ensure automation continuity in the presence of execution errors or component failures. When an error occurs at the intelligence layer, the average increase in configuration operation time ($T_{conf}$) is approximately 14.8 seconds, primarily due to the establishment of a new connection between layers and state restoration. In the event of a critical failure or an explicit rollback request, the system automatically triggers a rollback operation with an average $T_{conf}$ of 9.5 seconds. Most of this time is attributed to trace processing, validation, and database synchronization overhead.

These results confirm that the proposed architecture provides reliable end-to-end automation, combining deterministic execution with LLM-based adaptability and robust fault recovery mechanisms, ensuring stable and continuous operation even under failure conditions.

## IV. CONCLUSION

This paper presented a Kubernetes-native architecture for autonomous configuration management in cloud-native 5G cores that unifies declarative, GitOps-based execution with an intelligence layer for intent translation and policy-aware orchestration. By modeling 5GC configuration as CRDs backed by a Git-based source of truth and enforcing changes through deterministic workflows, It delivers end-to-end auditability, safe rollbacks, and clear separation between intent, planning, and execution. The access layer provides a single programmable entry point for intent and human-in-the-loop controls, while the design scales across multiple domains and supports both pull and push propagation.

A reference implementation on an OAI 5GC testbed demonstrated high reliability, acceptable management-layer latencies, modest controller resource use, and resilient recovery under faults.

Current work in progress expands upon the intelligence of the system, with more refined architecture description for AI integration.

## REFERENCES

[1] C. Radio-Television and T. Commission, "Assessment of rogers networks for resiliency and reliability following the 8 july 2022 outage – executive summary," https://crtc.gc.ca/eng/publications/reports/xona2024.htm, accessed: 2026-02-10.

[2] ISO, "Quality management — Guidelines for configuration management," ISO, Tech. Rep. ISO 10007:2017, 03 2017.

[3] 3GPP, "3rd Generation Partnership Project; Technical Specification Group Services and System Aspects; Management and orchestration; 5G Network Resource Model (NRM); Stage 2 and stage 3 (Release 19)," 3GPP, Tech. Rep. TS 28.541 V19.0.0 (2024-06), 06 2024.

[4] P. L. Vanessa Gyger, "Cloud-native network controller," Bachelor's Thesis, University of Applied Sciences Campus Rapperswil-Jona, Rapperswil, Switzerland, 2024.

[5] A. Güngör, ""ueransim: Open source 5g ue and ran (gnodeb) implementation." [Online]. Available: https://github.com/aligungr/ueransim

[6] O. A. Interface, "Developing a 5g cellular stack on commercial off-the-shelf hardware." [Online]. Available: https://openairinterface.org/

[7] O. SDK, "The operator SDK makes it easier to build kubernetes native applications, a process that can require deep, application-specific operational knowledge." [Online]. Available: https://sdk/operatorframework.io/

[8] T. Workflow, "Temporal workflows automatically capture state at every step, and in the event of failure, can pick up exactly where they left off." [Online]. Available: https://temporal.io/