arXiv CSopen access

METIS: A Declarative Slice Orchestrator for Application-Centric 5G/6G Networks

1

METIS: A Declarative Slice Orchestrator for Application-Centric 5G/6G Networks

arXiv:2607.29282v1 [cs.NI] 31 Jul 2026

Arman Divband∗ , Ali Yaghoubian∗ , and Navid Nikaein∗ ∗ EURECOM, Sophia-Antipolis, France Email: {Arman.Divband, Ali.Yaghoubian, Navid.Nikaein}@eurecom.fr

Abstract—Network slicing is the cornerstone of applicationaware 5G-Advanced and 6G networks, yet dynamic lifecycle management of network slice instances with coordinated qualityof-service enforcement across the radio access network and core network remains an unresolved challenge. Existing orchestrators rely on network-centric data models, imperative workflows, and static slice templates, while O-RAN addresses radio-side slice control independently of 3GPP core-side control, leaving slice-level quality-of-service enforcement uncoordinated across domains. This paper introduces METIS, a declarative slice orchestrator that manages the complete Day-0/1/2 lifecycle of network slice instances through cascaded reconciliation loops. METIS defines an application-centric data model for service profiles, enabling customers to describe the semantics and quality-of-experience requirements of their applications. From these, METIS derives 3GPP-aligned slice profiles via hierarchical aggregation following the 5G quality-of-service model, eliminating static templates, and jointly coordinates O-RAN and 3GPP slicing for slice instantiation and enforcement. Our central finding is a structural asymmetry in end-to-end slice control: downlink traffic can be shaped at the core before reaching the radio access network, but uplink leaves the user equipment unregulated, so core-only slicing cannot reliably satisfy uplink service-level agreements—radioside enforcement is necessary, not merely complementary. Evaluated on a 5G cloud-native testbed in a campus-event scenario, METIS completes slice creation, update, upgrade, and deletion within 22.4, 5.1, 52.2, and 32.1 seconds, respectively; sustains full service-level-agreement satisfaction under concurrent multi-slice overload; scales to 63 slice instances across nine zones consuming under 0.03 processor cores total; and recovers slices from injected failures across four levels in under 19 seconds. Index Terms—Network slicing, 5G, O-RAN, Kubernetes, cloudnative, declarative orchestration, lifecycle management, QoS enforcement, Service Level Agreement.

I. I NTRODUCTION As envisioned in Recommendation ITU-R M.2160-0 [1], 5G-Advanced and 6G networks are expected to support services with diverse requirements in terms of latency, reliability, throughput, security, coverage, and energy efficiency. Network slicing is a primary enabler for creating customized and isolated logical networks, Network Slice Instances (NSIs), over a shared physical infrastructure, allowing each service to receive the specific resources and performance guarantees it requires. However, supporting a wide range of services with varying lifespans makes dynamic NSI lifecycle management a key operational challenge. This challenge stems from the reliance on network-centric data models, which typically leads to static, template-based slice descriptors and limits the ability Corresponding authors: [email protected]))

Arman

Divband

(email:

Ar-

of Communication Service Customers (CSCs) [2] to dynamically express evolving service requirements throughout the NSI lifecycle without requiring expertise in 5G-Advanced or 6G technologies. To automate NSI lifecycle management, 3GPP TS 28.533 [3] defines an architecture that integrates the Network Slice Management Function (NSMF) [2] with the ETSI Network Functions Virtualisation (NFV) Management and Orchestration (MANO) framework [4]. In this architecture, CSCs express the communication service requirements—formulated largely as 5G network slice attributes—to the Communication Service Management Function (CSMF) [2], which captures them as Service Profiles for the NSMF to derive the corresponding Slice Profiles and then orchestrate the associated NSIs. The O-RAN specification [5] reuses these 3GPP-defined management functions within its Service Management and Orchestration (SMO) framework [6] to support NSI orchestration in the Radio Access Network (RAN) domain. Although 3GPP TS 28.541 [7] specifies the data model for Service Profiles, this model is network-centric (expressing 5G network-slice service-requirement attributes) rather than application-centric (capturing the semantic and Quality of Experience (QoE) requirements of the application). Moreover, while O-RAN reuses the 3GPP management functions, its RAN slicing control operates independently of 3GPP-defined Core Network (CN) slicing: the Policy Control Function (PCF) governs Quality of Service (QoS) policies in the CN while the Non-Real-Time (Non-RT) and Near-Real-Time (Near-RT) RAN Intelligent Controllers (RICs) do so in the RAN, with no coordination mechanism between the two domains—yet aligning them is crucial to establish and preserve slice-level QoS throughout the NSI lifecycle. Existing NSI orchestration frameworks, such as the Open Network Automation Platform (ONAP), rely on imperative, workflow-driven principles, characterized by step-by-step deployment procedures and intricate state machines [8], [9]. This design style is also reflected in the operation- and procedureoriented provisioning model of 3GPP TS 28.531 [10], which specifies NSI lifecycle actions through allocation, modification, activation, deactivation, and deallocation procedures. Such approaches remain insufficient for enabling a zero-touch NSI orchestration framework that dynamically performs NSI lifecycle management operations in an idempotent fashion, i.e., re-applying the same operation produces the same NSI state as applying it once, without side effects on the NSI or on other NSIs sharing its Network Functions (NFs). Specifically, if a single step in a deployment procedure fails, the orchestra-

2

tion process may stall and require manual intervention [11]. Although recent cloud-native frameworks, Nephio [12] and Athena [13], adopt declarative and reconciliation-driven principles, their orchestration scope remains primarily limited to NFs and Network Services (NSs), respectively, rather than treating Service Profiles, Slice Profiles, and NSIs as lifecyclemanaged resources. To bridge these gaps, this paper presents METIS, a cloudnative NSI orchestration framework that treats NSIs as declarative, application-driven resources spanning the RAN and CN domains. METIS introduces a new, application-centric data model for Service Profiles that captures the semantic and QoE requirements of services directly from CSCs, from which 3GPP-aligned Slice Profiles are automatically derived. Its key design principle is to distribute NSI orchestration logic across cascaded reconciliation loops, where each loop manages one abstraction level and propagates its desired state to the loops below. These cascaded loops coordinate O-RAN and 3GPP slicing providers for domain-specific NSI orchestration across a geographical area and enforce slice-level QoS through a coordinated control plane. They allow METIS to dynamically perform Day-0/1/2 NSI lifecycle operations, reconciling toward the desired state rather than stalling under failures. In summary, this paper makes the following contributions: • Application-centric Service Profiles: A data model that captures the semantic information and QoE requirements of applications by focusing on application-level attributes rather than network-centric slice attributes, and automatically derives QoS profiles of 3GPP-aligned Slice Profiles following the 5G QoS model (Subsection IV-A). • Joint O-RAN and 3GPP slicing: A declarative design coordinating O-RAN and 3GPP slicing providers for NSI orchestration and QoS enforcement across the RAN and CN domains (Sections III and IV). • Full Day-0/1/2 NSI lifecycle management: A novel multi-level operator design based on cascaded reconciliation loops for dynamic NSI creation, termination, update, and upgrade while preserving idempotency (Section IV). • Prototype and experimental validation of METIS: A concrete implementation validated through a realistic use case (campus event) covering dynamic NSI lifecycle management and joint RAN–CN slicing with QoS enforcement. The evaluation uses a set of well-defined NSI lifecycle metrics and considers both scalability and failure-recovery experiments (Subsection IV-D and Section V). II. R ELATED W ORK Management and Orchestration. Early MANO frameworks such as OSM [14] and OpenStack Tacker [15] were designed in line with the ETSI NFV MANO architecture [16] and primarily focused on orchestrating Virtualized Network Functions (VNFs) to support the lifecycle management of NSs. With the emergence of cloud-native technologies, the ETSI NFV MANO specifications [17], [18] were extended to support the orchestration of CNFs. Consequently, OSM and OpenStack Tacker extended their existing imperative and

TABLE I: Classification of Network Slice Orchestration Frameworks App-Centric NSI Solution Orch. Service Profile Control Logic OSM[14] × × IW Tacker[15] × × IW Nephio[12] × × DR Athena[13] × × DR MANO–OSS/BSS[21] Partial/✓ × IW ORANSlice[22] Partial/✓ × IW CLiSO[23] ✓ × IW NASP[24] ✓ × IW ONAP[8] ✓ × IW METIS ✓ ✓ DR

LCM D-0/1 D-0/1 D-0/1 D-0/1 D-0/1/pD-2 pD-2 D-0/1/pD-2 D-0/1/pD-2 D-0/1/pD-2 D-0/1/2

IW: Imperative Workflow-driven logic; DR: Declarative Reconciliation-driven logic; pD-2: partial Day-2 support.

workflow-driven orchestration logic [19], [20] to operate over Kubernetes, rather than redesigning it around declarative and reconciliation-driven principles. To bridge this gap, recent orchestration frameworks such as Nephio [12] and Athena [13] employ orchestration logic based on declarative and reconciliation-driven principles. Nephio orchestrates CNFs across multi-cluster and multi-vendor environments, while Athena performs the lifecycle management of NSs by orchestrating O-RAN and CN CNFs using two hierarchical Operators and a unified data model that serves as a descriptor for CNFs. Despite representing a new generation of MANO frameworks, both Nephio [25] and Athena remain focused on CNF and NS orchestration. Although Athena states that it ”natively accepts slices as first-class citizens and performs full lifecycle operations on them” [13], its treatment of slices remains at a different level of abstraction from NSI lifecycle management: it does not explicitly address Service Profiles, Slice Profiles, or NSIs as lifecycle-managed entities, nor does it provide an evaluation focused on NSI lifecycle management. Slice Orchestration. Existing slice orchestration works can be broadly categorized according to whether they address slice management within a single network domain or provide endto-end NSI lifecycle management across multiple domains. Some works focus on single-domain slice management and control. Chang and Lin [21] coordinate OSS/BSS and MANO for NSI-related management in the CN domain. Their Day-0 operations are limited to template-driven preparation of CN slice descriptors, including NSD, VNFD, and NSST design, which are later used to realize the CN part of NSIs during Day1 operations. Their Day-2 support is partial and mainly targets VNF or VM failure handling. ORANSlice [22], in contrast, focuses on the RAN domain by extending OpenAirInterface with 3GPP-compliant RAN slicing, multi-PDU support, and Near-RT RIC-based slice control through an E2SM-CCC service model and a slicing xApp. ORANSlice provides Day2-like RAN control capabilities, such as runtime PRB-policy adaptation and minimum radio-resource guarantees, but does not provide orchestration-level Day-0 Service Profile modeling, Day-1 end-to-end NSI instantiation, or coordinated RAN– CN QoS enforcement. Other works target end-to-end NSI lifecycle management by considering both RAN and CN domains. Frameworks such

3

Service Profile #1

Service Profile_1

Service Profile_N

Slice Profile_1

Slice (PLMN A) Profile_N

NSI_1

NSI_N

Service Profile_1

Service Profile_N

Slice Profile_1

Slice (PLMN B) Profile_N

NSI_1

NSI_N

1:1 Slice Operator (SO) Operator Plane

K8s Control Plane

Orchestration & Management Plane Telco Infrastructure Plane

Service Profile #N

Network Operator (NO)

1:1

1:1 Service Provider

Slice Operator (Network Slices)

1:1

N:1 Service Consumer

NF Operator (NFO)

Network Operator (Network Services)

N:1

Network Service (PLMN A)

Network Service (PLMN B)

1:N Worker Nodes

Worker Nodes

Worker Nodes

Isolated NF of Slice #1

NFMF Agents

NFMF Agents

NFMF Agents

Shared NF between Slice #1 and Slice #N

TA #M

TA #1

Edge Cloud

Regional Cloud

Central Cloud

Isolated NF of Slice #N

NF Operator (Network Functions)

NF_1

NF_2

1:N

NF_n 1:1

NF_1

NF_2

NF_m 1:1

K8s Control Plane (Deployments/Pods)

Fig. 1: High-level METIS Architecture. Fig. 2: Hierarchical Mapping for NSI Orchestration. as ONAP [8], CLiSO [23], and NASP [24] provide broader slice orchestration capabilities than single-domain approaches, but they generally rely on imperative or workflow-driven lifecycle logic and predefined slice templates. As a result, the mapping from application-level requirements to slicespecific configurations often depends on static descriptors or human intervention, rather than being dynamically derived from application-centric Service Profiles. Moreover, coordination between the RAN and CN domains for orchestration and QoS enforcement is not natively part of their lifecycle management for NSIs. In contrast, as shown in Table I, METIS (a) treats NSIs as first-class logical resources, (b) dynamically derives 3GPP-aligned Slice Profiles rather than relying on static templates, (c) natively coordinates O-RAN and 3GPP slicing across the RAN and CN domains, and (d) supports full Day-0/1/2 lifecycle management with coordinated QoS enforcement. III. D ESIGN OVERVIEW The principal contribution of this work, METIS, is a declarative and reconciliation-driven network slice orchestrator. It jointly coordinates 3GPP slicing and O-RAN slicing, thereby enabling the dynamic optimization of QoS guarantees across different service categories. Moreover, it addresses an unresolved operational challenge for NSIs in cloud-native environments: the simultaneous lifecycle management of NSIs across both RAN and CN domains while dynamically enforcing NSIlevel QoS. Towards this end, the Orchestration & Management Plane is distinguished from the Telco Infrastructure Plane (Fig. 1). The Telco Infrastructure Plane comprises radio equipment and computational resources (worker nodes across Edge, Regional, and Central Clouds), on which Containerized NFs (CNFs) run. These NFs are configured, started, and terminated by NFMF agents—per-NF agents realizing the Network Function Management Function role defined in 3GPP TS 28.533 [3]— based on general or slice-specific configurations issued by the Orchestration & Management Plane. In addition, NFMF agents resolve inter-NF dependencies through inter-agent communication; such dependencies arise either from Day-0/1/2 NSI operations or from the functional requirements of the NFs.

The Orchestration & Management Plane governs all the discussed components in the Telco Infrastructure Plane. It consists of the Kubernetes Control Plane and the Operator Plane. The Operator Plane hosts declarative and reconciliationdriven operators that are designed and developed using the Operator Pattern [26]. The NF Operator, Network Operator, and Slice Operator constitute the Operator Plane, responsible for the lifecycle management of NFs, NSs, and NSIs, respectively. This layering establishes a chain of dependent lifecycles: the lifecycle of NSIs is coupled with that of NSs, which is in turn coupled with that of NFs, which in turn depends on the lifecycle of Pods and worker nodes managed by the Kubernetes Control Plane. Therefore, as shown in Fig. 1, the Operator Plane and the Kubernetes Control Plane coordinate by consuming each other’s services. In METIS, the Slice Operator is the core component that performs the lifecycle management of NSIs across a geographical area by consuming the Network Operator’s services. To this end, it creates, updates, and deletes NSs to manage the lifecycle of NSIs. Upon receiving a Service Profile, the Slice Operator derives the corresponding Slice Profile as part of Day-0 operations for NSIs following the 5G QoS model (Subsection IV-A), resulting in a one-to-one (1:1) mapping between each Service Profile and each Slice Profile, as shown in Fig. 2. In METIS, each Slice Profile describes the specification of one NSI that should be established by mapping its components to the appropriate NFs within the NS. The Slice Operator establishes this mapping following the slicing and scaling principle: it slices existing NFs within the NS across NSIs when sharing is permitted, and otherwise scales out new NFs subject to admission control (e.g., available resources). To elaborate, if the NS already contains a suitable NF that can host the relevant component of the NSI, that NF is sliced by assigning the NSI’s slice identifier and resources to it. Otherwise, the Slice Operator scales out one or more new NFs into the NS—e.g., when existing NFs are dedicated to other NSIs, no NF is deployed in the requested geographical area, or the deployed NFs serve a different slice/service type (see Subsection IV-B). Moreover, the Slice Operator determines which NFs in the NS should be connected to one another by specifying the NSI serving scope for each NF, which is

4

Application-centric Service Profile

OSS/BSS

Service Profile #N

Semantic Information

SO-1

QoE Requirements

SO-CSMF

Slice Operator (SO)

PDU Session #1

SO-2

SO-NSMF

SO-Validator

SO-ran-nssmf

AI/ML Digital Twin

SO-CSMF

SMO

CN SO-NSSMF

SO-Monitor

Service Provider Service Consumer

Network Operator (NO) RAN Operator NFMF

Non-RT RIC

Slice Identification

PDU Session #2 QoS Profile

3GPP-aligned Slice Profile CN Operator NFMF

QoS Flow #1 QoS Flow #2

SO-cn-nssmf

RAN SO-NSSMF

NSI / SliceID

QoS Flow #1 QoS Flow #2

O-RAN Slicing Provider

UDR

3GPP Slicing Provider

Fig. 4: Service Profile to Slice Profile derivation by the SOCSMF.

Fig. 5: Hierarchical relationship among NSI, PDU Session, and Flow.

Network Service

NF Operator (NFO)

Slice #1

Slice #N

Isolated NF of Slice #N

IV. SYSTEM DESIGN & IMPLEMENTATION

Isolated NF of Slice #1

This section presents the system design and implementation of METIS, detailing the key components of the Slice Operator, Network Operator, and NF Operator, as well as their interactions for full lifecycle management of NSIs. It further describes how Day-0 (Service Modeling and NSI Design), Day1 (NSI Instantiation and Resource Orchestration), and Day-2 (NSI Runtime Control and Lifecycle Operations) operations are realized through coordinated management, control, and monitoring mechanisms.

Shared NF between Slice #1 and Slice #N

Fig. 3: METIS Detailed Architecture. later used by the NFMF agents to configure each NF with its serving NSIs. Since the NSIs of other Slice Profiles are established in the same NS, this results in a many-to-one (N:1) mapping from NSIs to NS. Furthermore, as can be seen in Fig. 2, the Slice Operator maintains a separate NS for each Mobile Network Operator (MNO), identified by its Public Land Mobile Network (PLMN), and the NSIs of an MNO are mapped to its associated NS, which yields a one-to-one (1:1) mapping between each PLMN and its NS1 . Upon receiving the specification of an NS determined by the Slice Operator, the Network Operator creates, updates, or deletes the specifications of the NFs as input to the NF Operator, which results in a one-to-many (1:N) mapping between each NS and its constituent NFs. Based on the action defined for an NF—creation, update, or deletion— the NF Operator performs the lifecycle management of the corresponding Deployment (a native Kubernetes resource), maintaining a one-to-one (1:1) mapping between each NF and its associated Deployment. All operations involved in this hierarchical mapping— whether for NSI establishment or for subsequent updates, upgrades, and deletions—are designed to be idempotent, ensuring consistent state convergence under repeated executions (see Subsection IV-C). This property is particularly critical in scenarios where NSIs share underlying NFs, as lifecycle actions on one NSI must not adversely affect others. To guarantee this, the reconciliation loops of the Slice Operator and Network Operator enforce idempotent control actions through an observe–compare–act paradigm, ensuring that only the necessary changes are applied by observing the actual state of each NSI, comparing it with its desired state, and acting to make them converge. 1 For simplicity, we assume that each MNO operates on dedicated infras-

tructure, i.e., no infrastructure is shared among MNOs.

A. Service Modeling & NSI Design (Day-0) The highest level of abstraction in METIS, represented by the first Day-0 operation in the Slice Operator, is realized by transforming application-centric Service Profiles into 3GPPaligned Slice Profiles. The data model for application-centric Service Profiles introduced by METIS comprises semantic information and QoE requirements. The semantic information defines the application-level meaning of the service traffic, including the use-case type, target data networks, DNS endpoints, traffic type and pattern, application and transport protocols, port information, and payload/content types. The QoE requirements specify the expected performance and deployment characteristics, including content rates, traffic class, isolation requirements, latency class, reporting period, coverage region and zone, user density, and user-equipment type 2 . CSCs express the network requirements of their applications in these application-centric Service Profiles, and using the SO-1 interface (Fig. 3), they submit them to the SO-CSMF. To design an NSI, the SO-CSMF derives its 3GPP-aligned Slice Profile from the corresponding application-centric Service Profile as shown in Fig. 4. The data model of a Slice Profile consists of slice identification attributes and QoS profile based on 5G QoS model in TS 23.501 [27]. The slice identification attributes, composed of PLMN, S-NSSAI, and SliceID, are determined based on the semantic information of Service Profiles. For instance, based on the defined use-case category (e.g., online gaming, data transfer), the SST (Slice/Service 2 An example of an Application-centric Service Profile is publicly available in the https://bubbleran.com/docs/v3.0.0/user-guide/slice-training/lab02 (accessed: Jul. 6, 2026).

5

Type) value of an S-NSSAI is specified. Then, to ensure uniqueness, the SD (Slice Differentiator) value is calculated based on the number of existing Slice Profiles with the same SST value. Finally, the SO-CSMF calculates the numeric value of the corresponding SliceID as SliceID = (SST ≪ 24) | SD, in which the SST occupies the 8 most significant bits and the SD occupies the 24 least significant bits. To derive the QoS profile of a Slice Profile, the SOCSMF employs a bottom-up hierarchical aggregation approach that is aligned with the granularity of the 5G QoS model. As illustrated in Fig. 5, an NSI can support multiple PDU sessions, each associated with a DNN, and each PDU session may comprise one or more QoS Flows, each identified by a QFI. Accordingly, the SO-CSMF starts from the QoS Flow level, the finest granularity, and progressively aggregates QoS requirements toward the PDU session level and, finally, the NSI level, the coarsest granularity. This process uses both the semantic information and the QoE requirements contained in the corresponding Service Profiles. To this end, the SO-CSMF uses the semantic information, particularly the traffic type of each data flow within the data networks, to determine the QFI and the corresponding QoS Flow parameters (e.g., ARP (Allocation and Retention Priority), PLR (Packet Loss Rate), GBR (Guaranteed Bit Rate), and MBR (Maximum Bit Rate)) through a traffic-type-to-QoS model inspired by Table 5.7.4-1 of 3GPP TS 23.501 [27]. In parallel, the SO-CSMF uses the QoE requirements, especially the content rate, to adjust the GBR and MBR parameters of the corresponding QoS Flows. It then determines the AMBR (Aggregate Maximum Bit Rate) of each PDU session by aggregating the requirements of one or more QoS Flows associated with that PDU session. Ultimately, by aggregating the AMBR values across PDU sessions, the SO-CSMF determines the NSI AMBR, which represents the NSI-level QoS 3 . B. NSI Instantiation & Resource Orchestration (Day-1) To jointly realize O-RAN and 3GPP slicing across the RAN and CN domains, METIS introduces an O-RAN slicing provider (comprising the RAN SO-NSSMF and the RAN Operator) and a 3GPP slicing provider (comprising the CN SO-NSSMF and the CN Operator), as shown in Fig. 3. Acting as the coordinator, the SO-NSMF declaratively drives the RAN SO-NSSMF and the CN SO-NSSMF to instantiate NSIs and orchestrate resources across both domains according to the Slice Profiles issued in Day-0 by the SO-CSMF. To trigger the Day-1 operations, the SO-NSMF derives domain-specific Slice Profiles, namely RAN Slice Profiles and CN Slice Profiles, from these Slice Profiles and delegates them to the corresponding SO-NSSMFs. The RAN Slice Profile contains low-level parameters required to create the NSI in the RAN domain, such as PLMN, S-NSSAI, coverage area, user density, isolation requirements, UE type, and Slice AMBR. Similarly, the CN Slice Profile contains low-level parameters required to create the NSI in the CN domain, such as PLMN, S-NSSAI, 3 An example of a 3GPP-defined Slice Profile is publicly available in the https://bubbleran.com/docs/v3.0.0/user-guide/slice-training/lab01 (accessed: Jul. 6, 2026).

DNN, PDU session type (IPv4 or IPv6), Slice AMBR, session AMBR, isolation requirements, and QoS flow parameters. In the RAN domain, the RAN SO-NSSMF instantiates an NSI by determining whether the O-RAN NFs within the requested geographical coverage area should be scaled out or sliced. To this end, it first checks whether suitable O-RAN NFs (i.e., those already deployed with sufficient PRBs) are available to host the requested NSI in the target area, which is mapped to a Tracking Area (TA). If so, it instructs the RAN Operator to slice the selected O-RAN NFs by assigning the S-NSSAI of the NSI to them. Otherwise, if sufficient radio and computational resources exist (as declared in the Resource Inventory Profiles) to deploy or expand the required O-RAN NFs, it instructs the RAN Operator to scale them out and assign the NSI to them. Similarly, in the CN domain, the CN SO-NSSMF instantiates an NSI by determining whether the 5G CN NFs associated with the data plane or control plane should be scaled out or sliced. The CN SO-NSSMF takes this decision based on the SST, isolation requirements, latency class, already-deployed 5G CN NFs, 5G CN characteristics, and the computational resources available in the target area. Specifically, if an NSI does not require an isolated 5G CN control plane, the CN SO-NSSMF instructs the CN Operator to slice the currently deployed 5G CN control-plane NFs by assigning the NSI to them. As another case, if the latency class of the NSI is MEC (Mobile Edge Computing) and no 5G CN data-plane NFs with the same SST have been deployed in the target area, the CN SO-NSSMF instructs the CN Operator to scale out 5G CN data-plane NFs, provided that sufficient resources are available. Instantiating NSIs by adding or updating O-RAN/5G NFs in the associated NS does not by itself define the NF interconnection topology. To this end, the RAN SO-NSSMF and CN SO-NSSMF declaratively specify the NSI serving scope of NFs. Accordingly, two or more NFs are interconnected when: (1) their NSI serving scopes overlap, and (2) a corresponding O-RAN interface or 3GPP reference point exists between them. This enables both SO-NSSMFs to abstractly specify the inter-NF topology without directly managing low-level configurations, which are delegated to the NFMF within the RAN and CN Operators. Regarding admission control and resource allocation for NSIs, METIS does not prescribe a specific optimization algorithm; rather, it defines the SO-Validator as a declarative extension point attached to the SO-NSMF, through which external AI/ML- or Digital-Twin-based mechanisms can plug in their optimization decisions. While remaining agnostic to the optimization mechanisms, the SO-NSMF exposes necessary information such as Slice Profiles, the current NS, and monitoring information through this interface. These decisions indicate whether a requested NSI can be admitted while satisfying the slicing or scaling rules for O-RAN/5G NFs described above, and would be consumed by the SO-NSMF, RAN SO-NSSMF, and CN SO-NSSMF during the Day-1 operations.

6

C. NSI Runtime Control & Lifecycle Operations (Day-2) Day-2 operations are where the effectiveness of declarative and reconciliation-driven logic for NSI orchestration becomes evident. Once instantiated, an NSI must remain aligned with the evolving requirements of the applications or services it serves throughout its operational lifetime. METIS achieves this by propagating the NSI orchestration logic across the cascaded reconciliation loops in a multi-level manner, as shown in Fig. 3: the outputs of upper-level components (target states) are cascaded as desired states for lower-level reconciliation loops, thereby enabling idempotent lifecycle management for NSIs. The following sub-subsections describe how METIS realizes Day-2 monitoring, QoS enforcement, NSI modification, and NSI termination. 1) NSI Monitoring: The SO-Monitor, within the Slice Operator (Fig. 3), collects NSI-level metrics and derives the actual state of each NSI with respect to lifecycle progress and performance. In particular, it determines whether an NSI has been created, modified, or deleted by computing the lifecycle management metrics, as defined in Table IV. In addition, it evaluates the performance of each NSI by assessing whether the QoE requirements requested by CSCs are satisfied, according to the SLA ratio defined in Eq. 1. The SO-Monitor then updates the status of the NSIs, enabling the SO-NSMF reconciliation loop to detect deviations between the desired and actual states and trigger the required corrective actions. 2) NSI-level QoS Enforcement: In METIS, QoS enforcement is treated as a built-in part of the NSI lifecycle and is performed once an NSI has been instantiated across the RAN and CN domains. Unlike typical O-RAN control operations, which optimize radio resources independently of CN QoS policies, METIS harmonizes O-RAN and 3GPP control operations to enforce NSI-level QoS across both domains. To this end, the SO-NSMF coordinates enforcement by instructing the RAN SO-NSSMF and the CN SO-NSSMF to enforce NSI-level QoS in their respective domains. The following paragraphs detail this enforcement. The RAN SO-NSSMF derives the RAN SLA assurance requirements—including slice identification, the target NearRT RIC, the scope of the monolithic or disaggregated OgNB, and the NSI-level QoS—from the RAN Slice Profile and the list of O-RAN NFs serving the NSI. It then uses the declarative R1 interface to convey the RAN SLA assurance requirements to the Non-RT RIC within the RAN Operator (Fig. 3). Upon receiving the SLA assurance requirements, the Non-RT RIC forwards them to the target Near-RT RIC over the A1 interface, where the SLA xApp is deployed to process and enforce them. To this end, the xApp subscribes to E2SM-KPM reports for monitoring and invokes E2SM-CCC control actions over the E2 interface between the Near-RT RIC and the target O-gNB. Once the required E2 procedures are established, the SLA xApp operates in a closed observecompare-act loop to dynamically adjust PRB allocation for the NSI: if the allocated PRBs are insufficient to satisfy the NSIlevel QoS, it increases the allocation; otherwise, it decreases the allocation to constrain NSI traffic to the requested QoS. The CN SO-NSSMF derives the slice subscription information, including slice identification and QoS rules, from the

corresponding CN Slice Profile and stores it in the UDR serving that NSI for use by the PCF. To enforce NSI-level QoS, each CN data-plane NF is paired with a Traffic-Shaper (realized as a sidecar workload; see Section IV-D), to which the CN SO-NSSMF provides the NSI-level QoS configuration. The Traffic-Shaper then constrains the traffic of an NSI in the CN domain according to its QoS requirements by placing the downlink and uplink traffic into two separate queues and regulating their rates at the CN data plane based on the NSIlevel QoS (Slice AMBR). 3) NSI Modification (Update and Upgrade): CSCs may update their Service Profiles during Day-2 operations to reflect the evolving requirements of their customers, applications, or services. The SO-CSMF observes these changes in Service Profiles and modifies the corresponding Slice Profiles accordingly. The modified Slice Profiles represent a new desired state for the associated NSIs. However, not every Slice Profile modification requires the same type of operation on the corresponding NSI. If the modified parameters only affect the runtime QoS behavior of the NSI, the SO-NSMF treats the modification as an NSI update. In this case, only control operations are required to re-enforce the requested QoS in the RAN and CN domains, which is similar to NSI-level QoS enforcement. In contrast, if the modified Slice Profile changes structural properties of an NSI, the SO-NSMF identifies the modification as an NSI upgrade. Such structural properties include the set of NFs in the NS, their placement, their sharing model, or their interconnection topology. In this case, the currently deployed NSI can no longer satisfy the new desired state through re-enforcing NSI-level QoS alone. Specifically, if an NSI’s coverage area changes entirely, the existing NSI is no longer valid for the requested geographical scope and must be terminated, re-onboarded, and re-instantiated to realize the upgrade. For the above reasons, an NSI upgrade requires multiple reconciliation steps. First, during an upgrade, the SO-NSMF reconciles the system toward a state in which the old NSI is no longer associated with the modified Slice Profile by initiating the termination of the old NSI (see Sub-subsection IV-C4). Second, it reconciles the system toward the onboarding and instantiation of the new NSI based on the modified RAN and CN Slice Profiles. Finally, it reconciles the system toward enforcing QoS for the new NSI. 4) NSI Termination and Resource Release: When a CSC no longer requires an NSI, it can request termination by deleting the corresponding Service Profile. The SO-CSMF detects this deletion and removes the corresponding Slice Profile, which represents the termination of the associated NSI as the new desired state. The SO-NSMF identifies this and marks the NSI as dangling (i.e., its Slice Profile no longer exists). To propagate this new desired state, the SO-NSMF deletes the RAN and CN Slice Profiles derived from the Slice Profile, which triggers the RAN SO-NSSMF and CN SO-NSSMF to terminate the NSI within their respective domains. Terminating a dangling NSI may require updating or deleting the O-RAN/5G NFs and their interconnections in the associated NS. If one or more NFs exclusively serve the

7

dangling NSI, the corresponding SO-NSSMF deletes those NFs. Otherwise, for shared NFs, the SO-NSSMF updates their annotations and NSI serving scopes by removing the identifiers of the dangling NSI. This prevents the termination of one NSI from disrupting other NSIs that share the same underlying NFs. However, the mentioned operations alone are not sufficient, because any RAN and CN resources or configurations allocated during QoS enforcement must also be released. For instance, the CN SO-NSSMF removes the slice subscription information of the dangling NSI from the relevant UDR or database. Similarly, the RAN SO-NSSMF releases the PRBs allocated to the dangling NSI by deleting its SLA assurance requirements over the R1 interface of the Non-RT RIC, which implicitly triggers the SLA xApp to release them. After these management and control operations are completed, the dangling NSI is safely removed without affecting other active NSIs. D. Implementation Details We implemented a prototype of METIS that follows the system design described above. All Slice Operator components were developed from scratch in Go (v1.22) using the Operator SDK [28]. For the Network Operator and NF Operator, we reused two components from Athena [13], namely the Base Operator and the Manager, to orchestrate and configure ORAN/5G NFs. In addition, we implemented the Non-RT RIC from scratch in Go using the Operator SDK to support the QoS enforcement in the RAN domain as part of lifecycle management through control operations. For the O-RAN/5G NFs, we built container images based on OpenAirInterface (OAI) [29] and Open5GS [30], respectively, and stored them in a private container registry for reuse throughout the lifecycle of NSIs. The Traffic-Shaper and SLA xApp, which are used for QoS enforcement, were also developed from scratch in Go and C, respectively, and containerized to automate their deployment. Overall, the METIS prototype includes approximately 20K lines of code for the components developed from scratch. The Traffic-Shaper runs as a sidecar workload alongside the UPF workload, whereas the SLA xApp runs as a separate workload in its own Pod and connects to FlexRIC [31], a Near-RT RIC implementation, through the E42 interface. In the following, we describe the implementation details of NSI lifecycle management. Day-0 Operations. In our implementation, the logic of the SO-CSMF is realized by a Service Profile Controller, a custom Kubernetes controller. Through the Kubernetes API Server, the Service Profile Controller watches ServiceProfile resources defined by CSCs and transforms each into a SliceEntity—the implementation-level representation of a Slice Profile—inside a Slice object that serves as the internal desired-state model consumed by the Slice Controller for Day1 and Day-2 operations. During reconciliation, the Service Profile Controller creates the Slice object if it does not already exist, then computes the corresponding SliceEntity and adds it to the Slice object. To support idempotent reconciliation and later Day-2 modifications, the Service Profile Controller stores the last-applied Service Profile specification

as a JSON annotation and updates the SliceEntity only when the desired state changes. Finally, it attaches a finalizer to each Service Profile, ensuring that deletion first removes the associated SliceEntity from the Slice object before the resource is garbage-collected. Day-1 Operations. In our implementation, the SO-NSMF, RAN SO-NSSMF, CN SO-NSSMF, and SO-Monitor are jointly realized by the Slice Controller, another custom Kubernetes controller. It observes the Slice object created during Day-0 operations and maps its desired state into a Network object, the implementation-level representation of an NS. The Slice Controller maps each SliceEntity to the O-RAN/5G NFs required to instantiate the corresponding NSI. Slicing and scaling decisions are reflected either by assigning an NSI to suitable shared NFs or by adding new NF instances when isolation or capacity requirements demand it. The resulting Network object is then handled by the reused Base Operator, which decomposes the networklevel desired state into NF-level Element objects, one per NF, and deploys the corresponding containerized workloads. Slice-specific configurations are issued through the reused Manager, enabling the configuration of inter-NF connectivity and assigning each NSI to the appropriate O-RAN/5G NFs. Finally, a slice-level finalizer ensures that changes in slice membership are propagated to the Network object before the Slice resource is reclaimed. Day-2 Operations. In our implementation, Day-2 operations are mainly handled by the Service Profile Controller and the Slice Controller. The Service Profile Controller detects changes in ServiceProfile objects by comparing the current specification with the last-applied specification stored as an annotation. If the Service Profile Controller detects an NSI update, it updates the QoS parameters of the corresponding SliceEntity in the Slice object. Otherwise, if it detects an NSI upgrade, it deletes the old SliceEntity from the Slice object and adds the new one so that the Slice Controller deletes the old NSI and recreates a new one. Regarding NSI monitoring, the Slice Controller reconciles the Slice object every minute so that SliceMonitor, the implementation-level representation of the SO-Monitor, determines the status of each SliceEntity by retrieving the status of the Pods, Deployments, and Elements from the Kubernetes control plane. The SliceID is used as an identifier to filter and classify the information of these components for each SliceEntity. With the SliceID, SliceMonitor also retrieves the performance metrics of SliceEntities from the time-series database stored by the SLA xApp and the Traffic-Shaper. For the QoS enforcement, the Traffic-Shaper generates the Linux Traffic Control rules [32] based on the NSI-level QoS (Slice AMBR) and binds them to the tunnel network interface (TUN) in UPF that serves an NSI. Additionally, it captures the performance metrics to be collected by Prometheus. Finally, NSI termination is implemented through finalizers across the ServiceProfile, Slice, Network, and Element resources, ensuring that slice membership, NF configuration, and associated workloads are released in the correct hierarchical order.

8

TABLE II: Specifications of Traffic Types in the Campus Event. Service Profile

Use Case Type

QoE Requirement

Organizers (Video Chat)

Participants (Data Transfer)

Service Profile 1

Service Profile 2

Service Profile 3

Slice Profile 1

Slice Profile 2

Slice Profile 3

NSI 1

NSI 2

NSI 3

MAX (DL: 12 Mbps, UL: 12 Mbps) AVG (DL: 10 Mbps, UL: 10 Mbps) GTD (DL: 8 Mbps, UL: 8 Mbps) TCT: 80%

Security Cameras

Video Streaming

Organizers

MAX (DL: 60 Mbps, UL: 9.6 Mbps) AVG (DL: 50 Mbps, UL: 8 Mbps) Video Chat GTD (DL: 40 Mbps, UL: 6.4 Mbps) TCT: 80%

Data Participants Transfer

Security Cameras (Video Stream)

MAX (DL: 48 Mbps, UL: 3.6 Mbps) AVG (DL: 40 Mbps, UL: 3 Mbps) GTD (DL: 32 Mbps, UL: 2.4 Mbps) TCT: 80%

MAX: Maximum; AVG: Average; GTD: Guaranteed; TCT: Time Compliance Threshold.

Near-RT RIC

UE 1 UE 2 UE 3

Uu

Uu Uu

E2

O-gNB N2

SBA

0 DB UDM NRF BSF SCP AUSF NSSF UDR PCF

AMF

SBA

N3

UPF

N3

UPF

N3

UPF

N4

SMF

N4

SMF

N4

SMF

DNN 1 DNN 2 DNN 3

TABLE III: Hardware Specification of the Testbed Node

OS

CPU

RAM

Equipment

CP U22.04 i9-10920X 64 GB – Worker 1 U22.04 i9-10920X 64 GB QTL RM520NGL (UE) Worker 2 U22.04 Ryzen 9950X 64 GB USRP B210 (RU) Worker 3 U22.04 i9-10980XE 32 GB QTL RM520NGL (UE) Worker 4 U22.04 i9-10980XE 32 GB QTL RM520NGL (UE) CP: Control Plane; UE: User Equipment; RU: Radio Unit; QTL: Quectel.

V. E VALUATION & U SE C ASE This section evaluates METIS in terms of (1) network slice lifecycle management, (2) joint RAN and CN slicing with QoS enforcement, (3) scalability, and (4) failure recovery. Results for the first two are obtained from a realistic use case, Campus Event, deployed on a 5G cloud-native testbed with an overthe-air interface. For scalability, RAN instances instead run in RF-simulated mode on the same testbed, spanning multiple regions and zones. For failure recovery, faults are injected at four levels—O-RAN NF, CN NF, NS, and NSI—demonstrating how the cascaded reconciliation loops of METIS recover these resources through the observe–compare–act paradigm. As shown in Table II, the campus event comprises three traffic categories with distinct QoE requirements and application use-case types: (1) security cameras, involving video streaming from cameras to the event’s security room; (2) organizers, involving peer-to-peer video chat among the event’s organizers; and (3) participants, involving data transfer traffic for the event’s participants. Accordingly, three distinct Service Profiles are defined to capture the network requirements of each traffic type. Fig. 6 shows the realization of NSIs when METIS receives three Service Profiles, automatically derives the corresponding Slice Profiles, and instantiates the NSIs by slicing and scaling O-RAN/5G NFs, exemplifying the hierarchical mapping concept of Fig. 2 in Section III. In this deployment, the O-RAN NFs (O-gNB and Near-RT RIC) and all 5G CN NFs except the SMF and UPF are shared across the three NSIs, whereas a dedicated SMF and UPF are instantiated per NSI as isolated NFs. To validate the created NSIs, three Quectel modules acting as real UEs connect to their respective NSIs and exchange uplink and downlink traffic.

Fig. 6: Deployed NSIs for the Campus Event by METIS. For the testbed, a 5G cloud-native cluster is built using Kubernetes (v1.31.3), and the hardware specifications are summarized in Table III. Additionally, Cilium (v1.18.2) is employed as the Container Network Interface (CNI) to enable network connectivity among CNFs, while Containerd (v1.7.27) is installed on each node to support CNF deployment. To collect time-series metrics, Prometheus (v2.38.0) is used. OpenAirInterface5G (v2.3.0) and Open5GS (v2.7.5) are used to deploy the RAN and CN, respectively. A. Network Slice Lifecycle Management To evaluate the full lifecycle management of NSIs, a representative and realistic scenario based on the campus event is considered, as illustrated in Fig. 7. In this scenario, different actions take place at different time instants. For instance, at time instants T0 , T1 , and T2 , the NSIs for security cameras, organizers, and participants are created, respectively. Subsequently, at time instants T3 and T4 , the NSIs for organizers and participants are updated, respectively. At T5 , the organizers’ NSI is further upgraded by changing the use-case category from video chat to push-to-talk. At the end of the event, as participants and organizers leave the campus, their NSIs are terminated in reverse order of their creation. The entire scenario is executed 20 times to assess reproducibility and reduce the impact of experimental variability. Before presenting the results, we note that the NSI lifecycle management operations defined in 3GPP TS 28.530 [2]— namely creation, modification (update or upgrade), and termination—are abstractly specified. Therefore, we decompose these operations into finer-grained lifecycle management metrics of NSIs to enable a more precise measurement of their execution time. Furthermore, to measure these metrics in a cloud-native environment, we propose measurement models, consistent with their definitions, that derive them primarily from Kubernetes-reported timestamps, complemented by runtime events at the UE and QoS-enforcement plane. Table IV

9

TABLE IV: Lifecycle management metrics of NSIs for cloudnative environments. Term Onboarding

Description / Formula Mapping an NSI to NFs. create − T max (N SI ) Tonboard (SPi ) = TSP i D i

Instantiating+ commissioning

Instantiating NFs or reconfiguring them to establish an NSI max (N SI ) − T max (N SI ) Tinst (SPi ) = TD i i Pod

PDU / UE Connection

Validating NSI by establishing a PDU session. TPDU (SPi ) =

Re-commissioning

max (N SI ) − T PDU (N SI ) TPod i i UE

Reconfiguring NFs. modify reinf (SP ) Tre-comm (SPi ) = TSP − TQoS i i

Re-onboarding

TABLE V: Notation Used in Table IV Symbol

Description

SPi

i-th Service Profile

N SIi

N SIi corresponding to SPi

N (N SIi )

Set of NFs serving N SIi

N Fj

j-th NF, where N Fj ∈ N (N SIi )

max (·)

Maximum operator taken over all N Fj N (N SIi )

create TSP i

creationTimestamp of SPi

modify TSP

lastModifiedTime of SPi

delete TSP i create TD,j

deletionTimestamp of SPi

update TD,j

lastUpdatedTime of the Deployment corresponding to N Fj   create , T update max TD,j D,j   max maxN (N SIi ) TD,j

i

Remapping an NSI to NFs. modify max (N SI ) Tre-onboard (SPi ) = TSP − TD i i

Reinstantiating+recommissioning

Reinstantiating or reconfiguring NFs after reonboarding. max (N SI ) − T max (N SI ) Tre-inst (SPi ) = TD i i Pod

Decommissioning

Deactivation

max TD,j max (N SI ) TD i

creationTimestamp of the Deployment corresponding to N Fj

Removing NSI from serving NFs.

ready TPod,j

lastTransitionTime for the Pod corresponding to N Fj

delete − T max (N SI ) Tdecomm (SPi ) = TSP i D i

delete TPod,j

deletionTimestamp for the Pod corresponding to N Fj   ready maxN (N SIi ) TPod,j   ready delete maxN (N SIi ) TPod,j , TPod,j

Disconnecting UEs and disabling an NSI. max (N SI ) − T discon (N SI ) Tdeact (SPi ) = TD i i UE

Offboarding

∈

N (N SIi )

Scaling down or reconfiguring NFs to delete an NSI. Toffboard (SPi ) =

max (N SI ) − T purge (N SI ) TD i i Pod

presents these metrics along with their corresponding measurement models, and Table V defines the notation used in these models. To the best of our knowledge, these cloudnative lifecycle management metrics for NSIs are presented for the first time in this paper. These metrics can be used to evaluate the lifecycle management of similar cloud-native NSI orchestrators. Using the lifecycle management metrics as legend items, Fig. 8a reports the average results across the 20 runs of the scenario in Fig. 7. The corresponding distributions and summary statistics are shown as box plots in Fig. 8b. As discussed in Section III, each Deployment represents a single NF in the Kubernetes cluster. To be precise, creating, updating, or deleting a Deployment is the outcome of the orchestration logic, while those operations are realized in the corresponding Pods, managed transitively through the ReplicaSet. Therefore, when NSIs for the corresponding Service Profiles are created by mapping them to NFs, the creationTimestamp of a Deployment indicates the instantiation of an NF, while the lastUpdatedTime or deletionTimestamp of a Deployment indicates a slicing-related update or deletion applied to the corresponding NF. Accordingly, the readiness or deletion timestamp of the corresponding Pods marks the realization of these operations. In Fig. 8a, the PDU/UE Connection metric reflects the UE-driven time to (re)establish a PDU session for NSI verification and is not controlled by METIS. The (re)instantiating+(re)commissioning metric captures the time required by the Kubernetes cluster and NFMF agents to deploy and initialize the Pods hosting NFs; once this phase

max (N SI ) TPod i purge TPod (N SIi ) PDU (N SI ) TUE i

Time at which a UE establishes a PDU session for N SIi

discon (N SI ) TUE i

Time at which a UE is disconnected from N SIi

reinf (SP ) TQoS i

Time at which QoS is re-enforced for SPi

completes, the corresponding NSI can be considered created. As explained in Sub-subsection IV-C3, upgrading an NSI requires terminating the established NSI and recreating it with the new features. The re-onboarding phase of an NSI upgrade therefore combines termination and creation operations, making the re-onboarding time longer than the onboarding time in an NSI creation procedure. The same applies to the re-instantiation+re-commissioning phase during upgrades: although its measurement model mirrors that of the instantiation+commissioning phase during NSI creation, it reports the time taken for the new NSI to be revived. By considering the above explanation, the fine-grained NSI lifecycle management operations are defined as follows, and Table VI reports the measured execution time using the results of Fig. 8a. • Creation time: defined as the sum of the onboarding time and the instantiating+commissioning time. • Update time: defined as the re-commissioning time. • Upgrade time: defined as the sum of the re-onboarding time and the re-instantiating+re-commissioning time. • Deletion time: defined as the sum of the decommissioning, deactivation, and offboarding times. The results demonstrate the ability of METIS in dynamically performing NSI lifecycle management operations, thereby enabling NSIs to adapt to the evolving behavior of applications and services over time. For instance, the total time required to create an NSI is approximately 22.4 s, whereas updating, upgrading, and deleting an NSI take approximately

10

Creating

Updating

Organizers Slice

Organizers Slice

T0

T2

Upgrading Organizers Slice (Video Chat -> PTT)

T6

T4

T1

T3 Creating Participants Slice

Creating Security Cameras Slice

Deleting Organizers Slice

T5 Updating Participants Slice

T7

Timeline

Deleting Participants Slice

Fig. 7: Lifecycle Management Storyline for the Campus Event. A: Onboarding B: Instantiating+Commissioning

A

B

C

3.4

17.1

34.0

ORG-CRT (T1)

A

B

3.6

18.6

PAR-CRT (T2)

A

B

3.8

17.6

18.4

ORG-UPD (T3)

5.1

25.7

35

C

30 Time (s)

5.0

ORG-UPG (T5)

ORG-DEL (T7)

C B

C

G

E

F

C

25.6

26.6

23.4

H

G

H

1.4 10.9

0

19.7

5

I

0 40

60

B

80

Time (s)

(a) Average NSI lifecycle management execution times.

I

E

I

A A

A

10

18.9

20

FC C

15

I

1.4 11.0

B

25 20

H: Deactivation

C

40

D

G: Decommissioning I: Offboarding

E: Re-onboarding F: Re-instantiating+Re-commissioning

45

D

PAR-UPD (T4)

PAR-DEL (T6)

D: Re-commissioning

D

D

H

H

G

G

SC -C RT O (T RG 0) -C RT (T PA 1) RCR T O (T RG 2) -U PD (T PA 3) RU PD O (T RG 4) -U PG (T PA 5) RD EL O (T RG 6) -D EL (T 7)

SC-CRT (T0)

C: Pdu / UE_Connection

(b) Distribution of NSI lifecycle management execution times across 20 runs.

Fig. 8: Campus Event NSI lifecycle management results.

5.1 s, 52.2 s, and 32.1 s, respectively. Notably, the measured upgrade latency (≈ 52.2 s) closely approximates the sum of the creation and deletion latencies (≈ 54.5 s), consistent with the fact that METIS realizes an upgrade as a termination of the existing NSI followed by instantiation of the new one. This correspondence serves as an internal consistency check on the proposed lifecycle measurement models. Table VI also positions METIS against two cloud-native NSI orchestration baselines, NASP [24] and CLiSO [23]. Two distinctions are important when interpreting this comparison. First, the scale differs: METIS results are measured for three concurrent NSIs, whereas both baselines report a single slice, making the comparison conservative. Second, the scope of orchestration differs. NASP primarily renders and deploys a slice template, reporting only a per-scenario creation time and a single AMF replace-and-redeploy reconfiguration (≈9 s outage); it does not perform a managed update, a true category upgrade, or a measured termination. METIS, in contrast, executes each TS 28.530 operation as a managed, decomposed phase. CLiSO reports creation and deletion for a multi-domain slice but issues an asynchronous DELETE over the Kubernetes REST API, which returns once the request is accepted rather than once the Pods are fully torn down; its ≈1– 3.5 s deletion therefore reflects deletion requested, whereas the METIS deletion time (≤32.1 s) measures decommissioning,

TABLE VI: Network Slice Lifecycle Management Operation Latency (s). Operation Phase

METIS NASP [24] CLiSO [23]

Creation

Onboarding Inst.+Comm. Total

≤ 3.8 ≤ 18.6 ≤ 22.4

– – 22–53†

– – 43.0‡

Update

Total (Re-comm.)

≤ 5.1

≈ 9§

–

Upgrade

Re-onboarding ≤ 25.6 Re-inst.+Re-comm. ≤ 26.6 Total ≤ 52.2

– – –

– – –

Deletion

Decommissioning Deactivation Offboarding Total

≤ 1.4 ≤ 11.0 ≤ 19.7 ≤ 32.1

– – – –

– – – 3.5‡

† Scenario-dependent (Shared ≈22, mMTC ≈42, non-3GPP ≈50, URLLC

≈53). ‡ Table 4 in [23]. § Similar to NSI update: AMF replace-and-redeploy reconfiguration outage.

deactivation, and offboarding through to complete teardown. Takeaway. The results show that declarative, reconciliationdriven orchestration enables dynamic NSI lifecycle management: not only Day-0/1 design and instantiation but also Day2 adaptation and termination, allowing NSIs to evolve with changing network conditions and application requirements.

11

With three concurrent NSIs, METIS completes creation, update, upgrade, and deletion in at most 22.4 s, 5.1 s, 52.2 s, and 32.1 s, respectively. B. Joint RAN and Core Network Slicing with QoS Enforcement In this subsection, we evaluate METIS in terms of its ability to provide joint RAN and CN slicing with QoS enforcement, as defined in Table II for the campus event. We conduct an overload test in which each UE, belonging to its corresponding NSI, simultaneously transmits traffic exceeding its declared QoE. The purpose of the overload test is not only to evaluate the isolation of established NSIs but also to assess whether traffic is constrained within the specified QoE limits, thereby ensuring that the SLAs of the NSIs are met. To compare the results of this section, we also conducted two more scenarios: (1) Without RAN and without CN slicing, and (2) Without RAN slicing but with CN slicing. Before presenting the results, we describe the SLA ratio (SLA(%)) metric, defined in (1). This metric assesses whether the requested QoE for an NSI is satisfied during its observation period from the Slice Operator’s perspective, regardless of the QoS enforcement mechanisms applied at the RAN and CN. To this end, starting from the initiation of an NSI, time-series traffic samples are collected, where the function T raf f ic(tn ) represents the downlink or uplink throughput at the sampling instant tn . Let t0 , t1 , . . . , tN −1 denote the discrete sampling instants, and N denotes the total number of captured traffic samples from t0 to tN −1 in (1), with a sampling interval of 100 milliseconds. Depending on an NSI, tN −1 corresponds to the reporting period declared by the use case owner in its Service Profile. The analysis is performed over time windows of duration tN −1 − t0 , repeated over the NSI lifetime. Under the overload test, a traffic sample at tn is considered valid and assigned the value 1 in (1) if it lies within the range defined by the guaranteed traffic and the maximum allowable traffic for the NSI, as specified in Table II. Therefore, the SLA ratio for an NSI is computed as the ratio of valid samples to the total number of captured samples during the observation period of the NSI. This value must be greater than or equal to the required time compliance threshold T CT specified in Table II; otherwise, the SLA status is considered not satisfied for the NSI over the considered time window. ( 1, if GTD ≤ Traffic(tn ) ≤ MAX n=0 0, otherwise

PN −1 SLA(%) =

N

× 100 (1)

Therefore, in the overload test, each of the three Quectel modules (UEs) was connected to its corresponding NSI in the Campus Event use case and generated downlink and uplink traffic exceeding its QoE, namely 100 Mbps for downlink and 20 Mbps for uplink. In this context, an observation window with a duration of one minute—during which all three UEs simultaneously transmit traffic—was considered. This yields 600 samples (with a sampling interval of 100 milliseconds) for each of the four traffic conditions: TCP downlink, TCP uplink,

UDP downlink, and UDP uplink. This test was repeated for the other two scenarios as well; 1) Without RAN and without CN slicing, and 2) Without RAN slicing but with CN slicing; and Table VII presents the average throughput and SLA ratio measured over the collected samples under the overload test for all three scenarios—No slicing, CN only, and RAN+CN—across the four traffic conditions. Given that, in the RAN+CN scenario shown in Table VII, the measured SLA ratio metric for all four traffic conditions is greater than or equal to the defined T CT in Table II, the SLA is satisfied under the overload test. In contrast, in the No slicing scenario, the SLA is violated in almost all traffic conditions. This is because there is neither isolation nor QoS enforcement, and network resources are fairly shared among UEs. In the CN only scenario, isolation and QoS enforcement are applied only at the CN. As a result, downlink traffic is controlled for NSIs based on their QoE, and the measured SLA ratio metric is satisfied for both TCP and UDP downlink traffic. However, since there is neither isolation nor QoS enforcement on the RAN side, RAN resources are fairly shared among UEs across NSIs. Consequently, for uplink traffic, the SLA is violated for TCP across all NSIs, while for UDP, it is violated only for the security cameras’ slice and remains satisfied for the other NSIs. These results highlight the importance of joint RAN and CN slicing with QoS enforcement, and show why the isolation among NSIs configured by the Slice Operator is key for satisfying SLAs. In the following paragraphs, we analyze the behavior of transport protocols—TCP and UDP—under both downlink and uplink traffic conditions. To this end, Fig. 9 shows the 600 time-series traffic samples for each of the four traffic conditions for the RAN+CN scenario. Based on the subfigures in Fig. 9, several questions may arise. To address some of them, we performed a detailed analysis. The first question is why Fig. 9b exhibits an almost flat downlink traffic pattern that closely follows the requested QoE for the NSIs. The main reason is that Linux Traffic Control is configured and applied to the dedicated tunnel network interface (TUN) at the UPFs in the CN for each NSI, based on the requested QoE. This effectively shapes and throttles the downlink traffic in the overload test before it reaches the RAN; thus, the traffic arriving at the RAN is already regulated, resulting in stable and nearly constant throughput. Note that these experiments were conducted under stable channel conditions: the over-the-air interface operated in band n48, no external interference was observed, and the measured RSRP at the UEs was approximately −60 dBm. In contrast, Fig. 9d shows that UDP-based uplink traffic does not exhibit the same flat pattern, despite sufficient PRBs being allocated to each NSI in the RAN via the xApp based on its QoE. This is because the configured PRB percentage only determines the average share of radio resources that the MAC scheduler should allocate to each NSI over time. It does not regulate the traffic generation rate at the UE side and does not perform traffic shaping within the RAN. Therefore, it does not enforce a strict PRB reservation or rate limit. In the uplink direction, traffic originates from UE-side

12

TABLE VII: Average throughput and SLA ratio for DL/UL (TCP/UDP) under overload across slicing configurations. Downlink (DL) Scenario

Slice

Target

Uplink (UL)

Measured

Target

TCP

Measured

UDP

TCP

UDP

Avg. (Mbps)

Avg. (Mbps)

SLA (%)

Avg. (Mbps)

SLA (%)

Avg. (Mbps)

Avg. (Mbps)

SLA (%)

Avg. (Mbps)

SLA (%)

No slicing

Security Cameras Organizers Participants

10 50 40

54.15 53.37 54.24

0.17 × 98.12 ✓ 0.68 ×

54.57 53.08 53.99

0.17 × 89.50 ✓ 3.50 ×

10 8 3

10.62 11.00 10.58

71.33 × 9.17 × 0.00 ×

10.79 10.97 11.02

67.67 × 15.33 × 0.00 ×

CN only

Security Cameras Organizers Participants

10 50 40

9.94 47.24 39.00

84.14 ✓ 80.67 ✓ 84.67 ✓

10.12 50.30 40.22

99.33 ✓ 99.33 ✓ 99.67 ✓

10 8 3

9.90 7.93 3.00

64.17 × 67.67 × 71.50 ×

8.31 8.05 3.05

51.50 × 91.17 ✓ 99.67 ✓

RAN+CN

Security Cameras Organizers Participants

10 50 40

9.46 47.48 38.08

94.83 ✓ 86.83 ✓ 86.83 ✓

9.86 49.03 39.27

96.50 ✓ 96.67 ✓ 97.17 ✓

10 8 3

9.61 7.68 2.73

81.50 ✓ 84.67 ✓ 80.67 ✓

9.77 7.68 2.71

88.33 ✓ 88.50 ✓ 81.17 ✓

Note: ✓ indicates SLA ≥ TCT, while × indicates SLA < TCT. Security Cameras

0

15

30

45

Time (s)

(a) DL TCP

60

20 10 0

Mbps

20 10 0

50 40 0

15

30

45

Time (s)

60

(b) DL UDP

Participants

15

15

10 8 5 3

10 8 5 3

0

Mbps

60

50 40

Mbps

Mbps

60

Organizers

0

15

30

45

Time (s)

(c) UL TCP

60

0

0

15

30

45

Time (s)

60

(d) UL UDP

Fig. 9: Throughput time-series for DL/UL (TCP/UDP) with joint RAN and CN slicing.

applications, which inject UDP traffic at a maximum rate of 20 Mbps, and reaches the 5G UE modems, i.e., the Quectel modules, without prior regulation. As a result, the RLC TX buffers of the Quectel modules fill faster than the allocated PRB percentage can drain them. When the MAC scheduler receives Buffer Status Reports (BSRs), it observes only the volume of buffered uplink data awaiting transmission, with no visibility into the application-level target rate of each NSI—e.g., 3 Mbps for participants, 8 Mbps for organizers, or 10 Mbps for security cameras. As a result, the scheduler cannot distinguish a legitimately bursty application from an unregulated constant-rate UDP source with a saturated buffer. Regarding the behavior observed in Fig. 9a and Fig. 9c, the main reason behind the fluctuations around the requested average traffic for all three NSIs is the congestion control mechanism applied by TCP. Takeaway. The three slicing configurations show that joint RAN and CN slicing is necessary, not merely beneficial. CNside shaping can satisfy the downlink SLA by regulating traffic before it reaches the RAN, but it cannot satisfy the uplink SLA because UE-originated traffic reaches the RAN unregulated and the MAC scheduler cannot impose per-NSI rates from BSR reports alone. Thus, only the RAN+CN configuration meets the TCT across all four traffic conditions. More broadly, NSI resource allocation alone cannot guarantee the required QoS; SLA-aware traffic shaping must also be enforced across the UE, RAN [33], and CN.

C. Scalability To evaluate the scalability of METIS under increasing orchestration complexity in distributed environments, a multiregion deployment scenario is considered, consisting of three regions with three zones each, i.e., nine geographically distributed zones in total. In this setup, 63 NSIs are deployed under three different scenarios: (1) sequential deployment of 63 NSIs, (2) parallel deployment in three batches of 21 NSIs, and (3) parallel deployment of all 63 NSIs in a single batch. The choice of 63 NSIs is constrained by the available infrastructure, namely the nine zones, and by the limitations of the adopted 5G CN, Open5GS, which supports up to seven network slices per SMF instance. For each scenario, we measure the CPU utilization of the Slice Operator (SO), the Network Operator (NO), and the Kubernetes API server, as well as the corresponding NSI creation time. The CPU utilization results for both the SO and NO across the three scenarios are shown in Fig. 10a, while the corresponding results for the Kubernetes API server are presented in Fig. 10b. A fine-grained breakdown of NSI creation, including onboarding and instantiation+commissioning, is shown in Fig. 10c for the same scenarios. As shown in Fig. 10a, in the sequential deployment scenario, the CPU utilization of both the SO and NO gradually increases as the number of created NSIs grows. In contrast, when the NSIs are deployed in parallel using three batches of 21 NSIs, the CPU utilization shows an approximately linear increase

13

0.008

40

Time (s)

0.012

50

Seq. 3x21 1x63

0.7

0.016

CPU Cores

CPU Cores

0.8

SO, NO seq. SO, NO 3x21 SO, NO 1x63

0.020

0.6 0.5

20

40

(a) SO and NO CPU usage

60

30 23.3

20 10 3.3

0.3

Number of Created NSIs

42

36.0

13.0

0.4

0.004

0

51

Onb., Inst. seq. Onb., Inst. 3x21 Onb., Inst. 1x63

0 0

20

40

60

Number of Created NSIs

(b) Kubernetes API server CPU usage

0

20

40

60

Number of Created NSIs

(c) Onboarding and tion+commissioning times

instantia-

Fig. 10: Scalability results in terms of CPU Utilization and NSI creation time.

across the batches. Interestingly, the CPU load observed during the deployment of the third batch of 21 NSIs is higher than that observed during the simultaneous deployment of all 63 NSIs. This behavior can be explained by the dependency between newly requested NSIs and already deployed NSIs. In the sequential scenario, each step processes one new NSI request while the number of active NSIs accumulates over time. In contrast, when all 63 NSIs are deployed in a single batch, all requests are processed simultaneously, with no previously deployed NSIs in the system. This indicates that the CPU utilization of the SO and NO depends not only on the number of newly arriving NSIs processed in parallel, but also on the number of NSIs already deployed. This interpretation is supported by the results shown in Fig. 10b, where the CPU utilization of the Kubernetes API server is higher during the deployment of the third 21-NSI batch compared to the other two scenarios. Note that the Kubernetes API server does not exclusively serve the SO and NO: its measured utilization includes the cluster’s baseline control-plane load (≈0.3 CPU cores before any NSI is created), so the METISattributable portion is the increment above this baseline, a cost inherent to any operator-based orchestrator interacting with the Kubernetes API. Furthermore, Fig. 10c shows how the deployment scenario affects NSI creation time: the mean creation time is 26.6 s for sequential deployment, 49.0 s for the three 21-NSI batches, and 93 s for the single 63-NSI batch. The sequential result is directly comparable to the creation time reported in Table VI: sequentially creating 3 NSIs in the campus event takes up to 22.4 s, whereas sequentially creating 63 NSIs here yields a mean of 26.6 s—a difference of roughly 4 s. Decomposing this difference shows that the onboarding times are nearly identical (within 0.5 s), while instantiating+commissioning accounts for approximately 4.7 s of additional time. The reason is scale: the campus event deploys 18 O-RAN/5G NFs (Fig. 6), whereas the scalability test deploys 62 O-RAN/5G NFs across nine zones, increasing the load on cluster nodes and the NFMF agents that resolve inter-NF dependencies in a more complex topology. Finally, Figs. 10a and 10c together reveal a trade-off: deploying all 63 NSIs in a single batch yields the lowest CPU utilization among the three scenarios but the longest creation time (93 s), whereas sequential deployment inverts both.

Takeaway. METIS orchestrates 63 NSIs across nine geographically distributed zones with modest control-plane overhead (≤0.03 CPU cores for the SO and NO combined). The deployment strategy trades CPU utilization against creation time—a single 63-NSI batch minimizes the former while sequential deployment minimizes the latter—and, notably, control-plane load grows with the number of already-deployed NSIs, not merely with the arrival rate of new requests. D. Failure Recovery To evaluate how METIS recovers NSIs from failures without human intervention, we use Chaos Mesh [34] to inject failures at the O-RAN NF, CN NF, NS, and NSI levels by removing the corresponding resources from the Kubernetes cluster. The reconciliation loops of METIS then observe the actual state of each resource, compare it against the desired state, and act to recover the removed resources. To perform this evaluation, an NSI is created by applying the corresponding Service Profile, and Chaos Mesh is then used to inject the failures. For each injected failure, Table VIII reports the time for the reconciliation loops to observe the failure (≤ 0.07 s), to compare the desired state of the resource against its actual state and act to make them converge (≤ 0.09 s), and for the resources to fully recover (≤ 18.6 s). Notably, because the orchestration logic is distributed across the reconciliation loops, the loop at the failed level detects and repairs the failure without involving the higher-level loops: when the O-RAN NF or CN NF is deleted, the Network Operator observes and handles the failure, whereas the Slice Operator handles the deletion of the NS and NSI. As shown in the Recovery column of Table VIII, the recovery time for the O-RAN NF (O-gNB) is ≈1.5 s longer than that for the CN NF (PCF), while the recovery time for the NSI is around 1 s longer than that for the NS. The former difference arises because the NFMF agent of the O-gNB must resolve two dependencies— the IP addresses of the target AMF and Near-RT RIC—and additionally issue an I/O request to access the USRP serving as the RU. In contrast, the NFMF agent of the PCF resolves only the IP address of the NRF—the Service-Based Architecture allows other NFs, such as the UDM and BSF, to be discovered through it—and requires no I/O request. Regarding the NS and NSI, recovering the NS requires all deleted O-RAN/5G

14

TABLE VIII: Failure Recovery Times of METIS Across Four Failure Levels (seconds). Failure

Observe

Compare/Act

Recovery

Total

O-RAN NF CN NF NS NSI

0.065 0.061 0.062 0.058

0.075 0.089 0.045 0.025

7.910 6.456 17.551 18.554

8.050 6.606 17.658 18.637

NFs to be re-instantiated and re-commissioned before the NS becomes operational, whereas recovering the NSI requires one additional reconciliation step beyond NS recovery. Takeaway. METIS recovers NSIs from failures at all four levels autonomously, detecting each failure in under 0.07 s and fully restoring the affected resources in under 19 s. Because orchestration logic is distributed across the cascaded loops, each failure is handled at its own level without escalating to higher loops—localizing recovery and confirming that resilience is a structural property of the reconciliation design rather than a dedicated recovery mechanism. VI. C ONCLUSION & F UTURE W ORK This paper presented METIS, a declarative, applicationdriven Slice Orchestrator that manages NSIs as firstclass declarative resources through cascaded reconciliation loops. By extending the modern, declarative orchestration paradigm—previously limited to the scope of NFs and NSs— to the full NSI lifecycle, METIS bridges a critical gap between existing cloud-native orchestration frameworks and the operational demands of 5G-Advanced and future 6G networks. At its core, METIS introduces an application-centric design in which vertical industries express the network requirements of their applications through Service Profiles, through which 3GPP-aligned Slice Profiles are automatically derived. This eliminates reliance on static, preconfigured slice templates and enables adaptive Day-0, Day-1, and Day-2 operations—all realized through a multi-level operator design in a declarative, idempotent, and automated manner. A central finding of this work is that joint RAN and CN slicing is not merely beneficial but necessary for SLA satisfaction. Under concurrent overload conditions, CN-only slicing fails to control uplink traffic in the absence of RANlevel QoS enforcement, while METIS, coordinating traffic shaping at the UPF with dynamic PRB allocation via the SLA xApp, successfully satisfies the defined SLA for all NSIs across all traffic conditions. This result underscores a fundamental asymmetry in end-to-end slice control: downlink traffic can be shaped at the CN before reaching the RAN, whereas uplink traffic originates at the UE and reaches the RAN unregulated, making RAN-side enforcement indispensable. More broadly, the results confirm that resource allocation alone is insufficient; traffic shaping must be enforced across all three elements of an end-to-end NSI—the UE, the RAN, and the CN. The lifecycle management evaluation shows the agility of METIS, with NSI creation completing up to 22.4 s and updates requiring up to 5.1 s, enabling NSIs to adapt dynamically to evolving application and service requirements. The scalability

evaluation further shows that METIS orchestrates 63 NSIs across a nine-zone, multi-region deployment while consuming well below 0.03 CPU cores, indicating that its cascaded reconciliation loops impose modest control-plane overhead as the number of NSIs grows. The failure recovery results additionally show that METIS observes NSI failures across four levels and fully recovers them in under 19 s. Future work will focus on integrating AI/ML- and DigitalTwin-based mechanisms into the SO-Validator for admission control and resource allocation, extending the applicationcentric service modeling to capture richer traffic behavior beyond rate-based QoE parameters, and evaluating METIS under dynamic NSI workloads in fully disaggregated, multivendor O-RAN and CN deployments. ACKNOWLEDGMENT This work is supported by the European Commission as part the Horizon Europe 6Green and 6GCloud Projects under Grant 101096925 and 101139073 as well as the Intention-6G project under the France 2030 programme and co funded by Bpifrance. The authors would like to thank the BubbleRAN team for their support. They also thank Prof. Roberto Bruschi and Dr. Chiara Lombardo of the University of Genova for their valuable comments during the 6Green project collaboration. R EFERENCES [1] ITU-R, “Framework and overall objectives of the future development of IMT for 2030 and beyond,” International Telecommunication Union, Radiocommunication Sector, Geneva, Switzerland, Tech. Rep. Recommendation ITU-R M.2160-0, 2023. [2] 3GPP, “Management and orchestration; concepts, use cases and requirements,” 3rd Generation Partnership Project (3GPP), Tech. Rep. TS 28.530, 2024, release 17. [3] ——, “Management and orchestration; architecture framework,” 3rd Generation Partnership Project (3GPP), Tech. Rep. TS 28.533, 2024, release 17. [4] ETSI, “Network functions virtualisation (NFV) release 5; management and orchestration; architectural framework specification,” European Telecommunications Standards Institute, Tech. Rep. ETSI GS NFV 006 V5.2.1, 2024. [5] O-RAN Alliance, “O-RAN slicing architecture,” O-RAN Alliance, Working Group 1, Tech. Rep. O-RAN.WG1.TS.Slicing-ArchitectureR004-v14.01, 2024. [6] ——, “O-RAN operations and maintenance architecture,” O-RAN Alliance, Working Group 10, Tech. Rep. O-RAN.WG10.OAMArchitecture, 2023. [7] 3GPP, “Management and orchestration; 5G network resource model (NRM); stage 2 and stage 3,” 3rd Generation Partnership Project (3GPP), Tech. Rep. TS 28.541, 2024, release 17. [8] ONAP Project, “ONAP service orchestrator architecture,” https://docs. onap.org/projects/onap-so/en/latest/architecture/architecture.html, 2026, accessed: Jun. 3, 2026. [9] ——, “ONAP service orchestrator repository,” https://github.com/onap/ so, 2026, accessed: Jun. 3, 2026. [10] 3GPP, “Management and orchestration; provisioning,” 3rd Generation Partnership Project (3GPP), Tech. Rep. TS 28.531, 2023, release 17. [11] Microsoft Azure Architecture Center, “Compensating transaction pattern,” https://learn.microsoft.com/en-us/azure/architecture/patterns/ compensating-transaction, 2026, accessed: Jun. 3, 2026. [12] Nephio Project, “Nephio: Cloud native network automation,” https:// nephio.org/, 2026, accessed: Jun. 3, 2026. [13] A. Mohammadi and N. Nikaein, “Athena: An intelligent multi-x cloud native network operator,” IEEE Journal on Selected Areas in Communications, vol. 42, no. 2, pp. 460–472, 2024. [14] ETSI OSM, “Open source MANO,” https://osm.etsi.org/, 2026, accessed: Jun. 3, 2026. [15] OpenStack, “Tacker: OpenStack NFV orchestration,” https://wiki. openstack.org/wiki/Tacker, 2026, accessed: Jun. 3, 2026.

15

[16] ETSI, “Network functions virtualisation (NFV); management and orchestration,” European Telecommunications Standards Institute, Tech. Rep. ETSI GS NFV-MAN 001 V1.1.1, 2014. [17] ——, “Network functions virtualisation (NFV); management and orchestration; report on NFV-MANO architectural framework options,” European Telecommunications Standards Institute, Tech. Rep. ETSI GS NFV-IFA 036, 2021. [18] ——, “Network functions virtualisation (NFV); management and orchestration; requirements and interfaces specification for containerized VNF management,” European Telecommunications Standards Institute, Tech. Rep. ETSI GS NFV-IFA 040, 2021. [19] ETSI OSM, “OSM lifecycle manager,” https://osm.etsi.org/gitlab/osm/ lcm, 2026, accessed: Jun. 5, 2026. [20] OpenStack, “Tacker source code,” https://github.com/openstack/tacker, 2026, accessed: Jun. 5, 2026. [21] W.-C. Chang and F. J. Lin, “Coordinated management of 5G core slices by MANO and OSS/BSS,” Journal of Computer and Communications, vol. 9, no. 6, pp. 52–72, 2021. [22] H. Cheng, S. D’Oro, R. Gangula, S. Velumani, D. Villa, L. Bonati, M. Polese, T. Melodia, G. Arrobo, and C. Maciocco, “ORANSlice: An open source 5G network slicing platform for O-RAN,” in Proc. 30th Annu. Int. Conf. Mobile Computing and Networking (ACM MobiCom), Washington D.C., USA, 2024, pp. 2297–2302. [23] S. Arora, A. Ksentini, and C. Bonnet, “Cloud native lightweight slice orchestration (CLiSO) framework,” Computer Communications, vol. 213, pp. 1–12, 2024. [24] F. H. Grings, G. Z. Bruno, L. R. Prade, J. M. C. Brito, and C. B. Both, “NASP: Network slice as a service platform for 5G networks,” Journal of Network and Computer Applications, vol. 250, p. 104479, 2026. [25] Nephio Project, “Nephio source code,” https://github.com/ nephio-project/nephio, 2026, accessed: Jun. 5, 2026. [26] Kubernetes Documentation, “Operator pattern,” https://kubernetes.io/ docs/concepts/extend-kubernetes/operator/, 2026, accessed: Apr. 30, 2026. [27] 3GPP, “System architecture for the 5G system (5GS),” 3rd Generation Partnership Project (3GPP), Tech. Rep. TS 23.501, 2023, release 17. [28] Operator Framework, “Operator SDK repository,” https://github.com/ operator-framework/operator-sdk, 2026, accessed: Apr. 30, 2026. [29] OpenAirInterface Software Alliance, “OpenAirInterface repository,” https://gitlab.eurecom.fr/oai/openairinterface5g, 2026, accessed: Apr. 30, 2026. [30] Open5GS Project, “Open5GS repository,” https://github.com/open5gs/ open5gs, 2026, accessed: Apr. 30, 2026. [31] R. Schmidt, M. Irazabal, and N. Nikaein, “FlexRIC: An SDK for nextgeneration SD-RANs,” in Proc. 17th Int. Conf. Emerging Networking EXperiments and Technologies (CoNEXT), 2021, pp. 411–425. [32] Linux man-pages Project, “tc(8): Show / manipulate traffic control settings,” https://man7.org/linux/man-pages/man8/tc.8.html, 2025, accessed: Apr. 30, 2026. [33] M. Irazabal and N. Nikaein, “Tc-ran: A programmable traffic control service model for 5g/6g sd-ran,” IEEE Journal on Selected Areas in Communications, vol. 42, no. 2, pp. 406–419, 2024. [34] Chaos Mesh Authors, “Chaos mesh: A powerful chaos engineering platform for Kubernetes,” https://chaos-mesh.org/, 2026, accessed: Jun. 18, 2026. [35] J. Dobies and J. Wood, Kubernetes Operators: Automating the Container Orchestration Platform. Sebastopol, CA, USA: O’Reilly Media, 2020. [36] K. Hightower, B. Burns, and J. Beda, Kubernetes: Up and Running. Sebastopol, CA, USA: O’Reilly Media, 2017. [37] 3GPP, “Procedures for the 5G system (5GS),” 3rd Generation Partnership Project (3GPP), Tech. Rep. TS 23.502, 2024, release 17. [38] ——, “Numbering, addressing and identification,” 3rd Generation Partnership Project (3GPP), Tech. Rep. TS 23.003, 2023, release 17. [39] ——, “5G system; network exposure function northbound APIs; stage 3,” 3rd Generation Partnership Project (3GPP), Tech. Rep. TS 29.522, 2025, release 17. [40] O-RAN Alliance, “Study on O-RAN slicing,” O-RAN Alliance, Working Group 1, Tech. Rep. O-RAN.WG1.Study-on-O-RAN-Slicing-v02.00, 2022. [41] ——, “O-RAN A1 interface: General aspects and principles,” O-RAN Alliance, Working Group 2, Tech. Rep. O-RAN.WG2.A1GAP, 2023. [42] ——, “O-RAN E2 application protocol (E2AP),” O-RAN Alliance, Working Group 3, Tech. Rep. O-RAN.WG3.E2AP, 2023. [43] ——, “O-RAN R1 interface: General aspects and principles,” O-RAN Alliance, Working Group 2, Tech. Rep. O-RAN.WG2.R1GAP, 2023.

[44] NGMN Alliance, “Cloud native manifesto: An operator view,” Next Generation Mobile Networks Alliance, Tech. Rep., 2023, version 1.0, approved 6 September 2023. [45] Kubernetes Documentation, “Controllers,” https://kubernetes.io/docs/ concepts/architecture/controller/, 2026, accessed: Jun. 3, 2026. [46] Operator Framework, “Operator lifecycle manager,” https://github.com/ operator-framework/operator-lifecycle-manager, 2024, accessed: Apr. 23, 2026. [47] Linux man-pages Project, “inotify(7): Monitoring filesystem events,” https://man7.org/linux/man-pages/man7/inotify.7.html, 2025, accessed: Apr. 30, 2026.