Pith. sign in

REVIEW 3 major objections 5 minor 47 references

Network-slice service agreements on the uplink cannot be guaranteed by core-network traffic shaping alone; radio-side enforcement is required.

Reviewed by Pith at T0; open to challenge. T0 means a machine referee read the full paper against a public rubric. the ladder, T0–T4 →

Challenge this review Re-run · record.json Download PDF Read on arXiv ↗

T0 review · deepseek-v4-flash

2026-08-03 10:03 UTC pith:PR3PBM3G

load-bearing objection A genuine systems contribution with careful lifecycle metrics and a credible design, but the headline asymmetry claim is stronger than the evidence; deserves refereeing with requests for repetitions and artifacts. the 3 major comments →

arxiv 2607.29282 v1 pith:PR3PBM3G submitted 2026-07-31 cs.NI

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

Arman Divband , Ali Yaghoubian , Navid Nikaein This is my paper
classification cs.NI
keywords network slicingslice orchestrationQoS enforcementO-RAN3GPPlifecycle managementdeclarative reconciliationservice level agreement
verification ladder T0 review T1 audit T2 compute T3 formal T4 reserved

The pith

A machine-rendered reading of the paper's core claim, the machinery that carries it, and where it could break.

This paper tries to establish that end-to-end network-slice quality of service needs coordinated control across both the radio access network and the core network: downlink traffic can be shaped at the core before reaching the radio, but uplink traffic originates at the user device and reaches the radio unregulated. It introduces METIS, a declarative slice orchestrator that treats slices as first-class resources, derives standard 3GPP slice profiles from application-level service descriptions, and coordinates radio-side and core-side control through cascaded reconciliation loops. If the central finding is right, core-only slicing products cannot reliably meet uplink service-level agreements under overload, and future 5G/6G orchestration must join radio and core enforcement. The paper supports this with a cloud-native 5G testbed showing that only joint radio-plus-core enforcement satisfies the stated SLA targets across all tested TCP/UDP downlink/uplink conditions.

Core claim

The paper's central claim is that core-only network slicing cannot reliably satisfy uplink service-level agreements: downlink traffic passes through the core before reaching the radio and can be shaped there, but uplink traffic is generated at the user equipment and arrives at the base station unregulated, so the radio scheduler alone cannot infer per-slice target rates from buffer-status reports. METIS demonstrates that jointly coordinating radio-side PRB allocation with core-side traffic shaping satisfies the SLA ratio across TCP and UDP in both directions under overload, whereas core-only enforcement violates the uplink SLA. The same orchestrator manages the full Day-0/1/2 slice lifecycle

What carries the argument

The carrying mechanism is a hierarchy of cascaded reconciliation loops: the Slice Operator watches application-centric Service Profiles, derives 3GPP-aligned Slice Profiles through bottom-up aggregation following the 5G QoS model, and propagates desired state down to separate RAN and core domain operators. QoS enforcement pairs two components: the Traffic-Shaper, a core-side rate limiter at the user-plane function, and the SLA xApp, a radio-side controller that dynamically adjusts PRB allocations. The observe-compare-act pattern in every loop makes lifecycle actions idempotent and localizes failure recovery.

Load-bearing premise

The load-bearing premise is that the SLA ratio's pass/fail thresholds—guaranteed, maximum, and time-compliance limit—faithfully capture user-perceived quality, and because those same thresholds configure the very enforcement being tested, the joint radio-plus-core result is partly assured by construction.

What would settle it

The claim would be falsified by an overload test where core-only enforcement keeps the uplink SLA ratio at or above the time-compliance threshold for both TCP and UDP, especially under varying radio conditions; the paper's results show this failing at roughly -60 dBm RSRP. A cheaper check is to recompute the SLA ratio with a different sampling interval (for example 1 s instead of 100 ms) or different GTD/MAX values: if core-only then passes and radio-plus-core fails, the asymmetry is an artifact of the chosen thresholds.

Watch this falsifier — get emailed when new claim-graph text bears on it.

If this is right

  • Operators that enforce slicing only in the core should expect uplink SLA violations when multiple slices overload the radio; uplink guarantees require coordination with radio scheduling.
  • METIS's cascaded reconciliation loops make slice lifecycle operations idempotent and self-healing: injected failures at any of four levels recover in under 19 seconds without manual intervention.
  • The hierarchical aggregation from application semantics to 3GPP slice profiles removes static templates, so a customer can edit a service profile and the slice updates or upgrades automatically.
  • Measured latencies (creation at most 22.4 s, update 5.1 s, upgrade 52.2 s, deletion 32.1 s) show that declarative orchestration can keep pace with dynamic service lifecycles in a real 5G testbed.
  • The scalability result—63 slices across nine zones under 0.03 CPU cores of control-plane overhead—suggests that orchestration cost is modest and deployment strategy, not raw controller load, dominates creation time.

Where Pith is reading between the lines

These are editorial extensions of the paper, not claims the author makes directly.

  • If the uplink asymmetry holds beyond this testbed, standards efforts for end-to-end slicing should place a rate-control hook at the radio scheduler or the UE, not only at the core; the paper's buffer-status-report argument explains why core-side visibility is insufficient.
  • The lifecycle metrics defined from timestamps and runtime events could serve as a neutral benchmark for comparing other declarative slice orchestrators, since they do not depend on METIS internals.
  • A natural next test is to vary the radio channel and traffic mixture; the paper's stable-channel setup leaves open whether the joint radio-plus-core advantage persists under interference, mobility, or bursty application traffic.
  • The service-profile-to-slice-profile derivation is rate-centric; extending it to latency, reliability, or energy semantics could broaden the approach beyond throughput-oriented QoE.

Editorial analysis

A structured set of objections, weighed in public.

Desk editor's note, referee report, simulated authors' rebuttal, and a circularity audit.

Referee Report

3 major / 5 minor

Summary. METIS is a declarative orchestrator for the full Day-0/1/2 lifecycle of 5G/6G network slice instances. It introduces application-centric Service Profiles from which 3GPP-aligned Slice Profiles are derived via hierarchical aggregation, and it coordinates O-RAN and 3GPP slicing through cascaded reconciliation loops spanning a Slice Operator, Network Operator, and NF Operator. The implementation is evaluated on a cloud-native OAI/Open5GS testbed with real UEs: lifecycle operations are measured over 20 runs (creation 22.4 s, update 5.1 s, upgrade 52.2 s, deletion 32.1 s); overload and QoS enforcement are compared across No-slicing, CN-only, and RAN+CN configurations; scalability is tested up to 63 NSIs in nine zones; and failure recovery is measured at four levels. The paper's central claim is a structural asymmetry: downlink can be shaped in the CN, but uplink is unregulated at the UE, so core-only slicing cannot reliably satisfy uplink SLAs and RAN-side enforcement is necessary.

Significance. If the central claim is upheld, METIS would be a significant systems contribution: it treats Service Profiles, Slice Profiles, and NSIs as first-class declarative resources with coordinated RAN/CN QoS enforcement, and it provides a reusable set of cloud-native lifecycle metrics. The 20-run lifecycle evaluation, the internal consistency check between upgrade latency and creation+deletion latency, and the use of a real over-the-air testbed are notable strengths. However, the headline asymmetry claim currently rests on a single unreplicated overload run, the SLA success metric shares its thresholds with the enforcement configuration, and the missing RAN-only arm prevents the 'joint necessity' conclusion. These issues are fixable with additional experiments or restrained claims.

major comments (3)
  1. [§V-B, Table VII and Eq. (1)] The overload experiment is reported as a single 60-second observation window (600 samples per condition) with no repetitions, standard deviation, or confidence interval, although the lifecycle experiment was repeated 20 times. This is the entire support for the central claim that core-only slicing cannot reliably satisfy uplink SLAs (§VI and Abstract). Several RAN+CN SLA ratios sit close to the 80% TCT (e.g., Security Cameras UL TCP 81.50%, Participants UL TCP 80.67%, UL UDP 81.17%), so a single rerun could move a configuration across the pass/fail boundary. The paper itself notes stable channel conditions (RSRP ≈ −60 dBm, band n48, no external interference), so radio variability is not exercised. Please report repeated runs or a sensitivity analysis over observation windows, and either strengthen the methodology or restate the claim as applying to this testbed configuration.
  2. [§V-B, Eq. (1) and Table II] The SLA success criterion uses the GTD, MAX, and TCT values from the same Service Profiles that METIS uses to configure the Traffic-Shaper and SLA xApp (Subsection IV-C2). The measured 'success' is therefore partly by construction: a correctly enforced rate in [GTD, MAX] is defined as success. This is a limited circularity (the CN-only configuration still fails, so the result is not vacuous), but it weakens the interpretation of 'full SLA satisfaction'. Please add an independent application-level/QoE metric, or perform a sensitivity analysis varying TCT, thresholds, and sampling interval, and discuss how the pass/fail conclusions depend on these parameters.
  3. [§V-B, Table VII and §VI] The takeaway states that 'joint RAN and CN slicing is necessary, not merely beneficial.' The experimental design omits a RAN-only configuration; the columns are No slicing, CN-only, and RAN+CN. The data can support 'CN-only is insufficient in this testbed; RAN+CN works,' but they cannot establish that RAN-side enforcement alone would fail, which is required for the 'joint ... necessary' claim. Add a RAN-only arm, or weaken the conclusion to 'radio-side enforcement is necessary' as in the Abstract, reserving the stronger joint-necessity claim for future work.
minor comments (5)
  1. [§V-B, Table VII] State explicitly how many repetitions were performed for each overload configuration. The text says the test was repeated 'for the other two scenarios,' but it does not say whether the same scenario was rerun multiple times. If it was not, say so directly.
  2. [§V-D, Table VIII] Failure-recovery times are reported as single point values. For reproducibility, report the number of fault-injection runs and provide error bars, or label the values as representative single runs.
  3. [§V-B, Fig. 9] The time-series panels are shown only for RAN+CN. Adding a CN-only or No-slicing uplink panel would make the stated asymmetry visually evident and help readers assess the claim in the takeaway.
  4. [§IV-D] The text says the Slice Operator components were developed from scratch but later states that the Network Operator and NF Operator reuse Base Operator and Manager from Athena. Clarify which components are new and which are reused to avoid inconsistency.
  5. [§V-B, Eq. (1)] Define the measurement point of Traffic(t_n) (UPF TUN interface, RAN, or UE) and clarify whether the number of samples N is identical for all NSIs and traffic conditions. This will make the SLA ratio easier to reproduce.

Circularity Check

1 steps flagged

SLA success in Eq. (1) is defined by the same GTD/MAX values METIS is configured to enforce, so the RAN+CN 'full SLA satisfaction' is partly self-confirming; the CN-only vs RAN+CN differential still supports the asymmetry claim.

specific steps
  1. self definitional [Section V-B, Eq. (1) and Table II; Section IV-C2 (NSI-level QoS Enforcement); Section IV-A (Service Profile derivation)]
    "Under the overload test, a traffic sample at t n 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."

    The success predicate in Eq. (1) uses GTD and MAX taken from the same Service Profiles (Table II) whose QoE content rates the SO-CSMF converts into GBR/MBR and NSI AMBR (Section IV-A), and which are then pushed as the NSI-level QoS to both the CN Traffic-Shaper and the RAN SLA xApp (Section IV-C2). Thus a 'valid' sample is one that stayed inside the exact rate interval METIS was commanded to enforce; the RAN+CN pass is in part guaranteed by construction. The circularity is limited because the CN-only column uses the same CN setpoints and still fails uplink, so the claimed RAN-side necessity rests on the differential, not on the metric alone.

full rationale

The lifecycle, scalability, and failure-recovery evaluations are direct measurements against Kubernetes timestamps, CPU counters, and injected faults; they are self-contained and not circular. The central asymmetry claim is also substantially supported by the differential comparison: with identical CN-side shaping, uplink SLAs fail when RAN enforcement is absent and pass when the SLA xApp is added, which cannot be explained by construction alone. However, the RAN+CN 'full SLA satisfaction' result is partially self-confirming because Eq. (1) defines satisfaction as GTD <= Traffic <= MAX using the same Service-Profile parameters that configure METIS's own Traffic-Shaper and SLA xApp; any well-tuned controller aimed inside that interval will trivially score high. Self-citations to Athena, FlexRIC, and TC-RAN are implementation reuse or background, not load-bearing evidence for the asymmetry claim. The paper's overbroad wording 'cannot reliably satisfy' from a single unrepeated one-minute overload run is an experimental-reliability concern, not a circularity. Overall, one limited self-definitional element; no deep circularity.

Axiom & Free-Parameter Ledger

0 free parameters · 4 axioms · 0 invented entities

The claims rest on standard 3GPP/O-RAN modeling assumptions and on the experimental premise that the testbed's stable channel and chosen SLA thresholds faithfully represent QoE. No numeric parameters are fitted to data; GTD/MAX/TCT values are scenario inputs, not fitted constants. The new software components (Traffic-Shaper, SLA xApp, operators) are implemented artifacts, not unobserved explanatory entities.

axioms (4)
  • domain assumption The traffic-type-to-QoS mapping from 3GPP TS 23.501 Table 5.7.4-1 correctly determines QFI/ARP/PLR/GBR/MBR for arbitrary application traffic types.
    Used in Section IV-A for deriving Slice Profiles from Service Profiles; no validation is provided that the mapping produces correct or 3GPP-compliant QoS profiles beyond being 'inspired by' the standard table.
  • domain assumption O-RAN and 3GPP control interfaces (R1, A1, E2, E42, N4, SBA) behave as specified in the cited standards when used through FlexRIC, Open5GS, and OAI implementations.
    The evaluation in Sections IV-D and V relies on these implementations; no conformance testing is reported.
  • domain assumption Stable channel conditions (RSRP ≈ -60 dBm, band n48, no external interference) allow throughput differences to be attributed to orchestration and QoS enforcement rather than radio variability.
    Stated in Section V-B; the experiments are not tested under varying radio conditions.
  • domain assumption Each MNO operates on dedicated infrastructure, so no infrastructure is shared among MNOs.
    Footnote 1 in Section III; this simplifies the 1:1 NS-to-PLMN mapping and is not evaluated.

pith-pipeline@v1.3.0-daily-deepseek · 22682 in / 13286 out tokens · 131237 ms · 2026-08-03T10:03:18.755363+00:00 · methodology

0 comments
read the original abstract

Network slicing is the cornerstone of application-aware 5G and 6G networks, yet dynamic lifecycle management of network slice instances with coordinated quality-of-service enforcement across the radio access network and core network remains unresolved. 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 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 - radio-side 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.

Figures

Figures reproduced from arXiv: 2607.29282 by Ali Yaghoubian, Arman Divband, Navid Nikaein.

Figure 1
Figure 1. Figure 1: High-level METIS Architecture. 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 slice￾specific configurations often depends on static descriptors or human intervention, r… view at source ↗
Figure 5
Figure 5. Figure 5: Hierarchical relation￾ship among NSI, PDU Ses￾sion, and Flow. IV. SYSTEM DESIGN & IMPLEMENTATION 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 interac￾tions for full lifecycle management of NSIs. It further de￾scribes how Day-0 (Service Modeling and NSI Design), Day￾1 (NSI Instanti… view at source ↗
Figure 3
Figure 3. Figure 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 [PITH_FULL_IMAGE:figures/full_fig_p004_3.png] view at source ↗
Figure 3
Figure 3. Figure 3: the outputs of upper-level components (target states) are [PITH_FULL_IMAGE:figures/full_fig_p006_3.png] view at source ↗
Figure 6
Figure 6. Figure 6: Deployed NSIs for the Campus Event by METIS. [PITH_FULL_IMAGE:figures/full_fig_p008_6.png] view at source ↗
Figure 7
Figure 7. Figure 7: Lifecycle Management Storyline for the Campus Event. [PITH_FULL_IMAGE:figures/full_fig_p010_7.png] view at source ↗
Figure 8
Figure 8. Figure 8: Campus Event NSI lifecycle management results. [PITH_FULL_IMAGE:figures/full_fig_p010_8.png] view at source ↗
Figure 9
Figure 9. Figure 9: Throughput time-series for DL/UL (TCP/UDP) with joint RAN and CN slicing. [PITH_FULL_IMAGE:figures/full_fig_p012_9.png] view at source ↗
Figure 10
Figure 10. Figure 10: Scalability results in terms of CPU Utilization and NSI creation time. [PITH_FULL_IMAGE:figures/full_fig_p013_10.png] view at source ↗

discussion (0)

Sign in with ORCID, Apple, or X to comment. Anyone can read and Pith papers without signing in.

Reference graph

Works this paper leans on

47 extracted references

  1. [1]

    Framework and overall objectives of the future development of IMT for 2030 and beyond,

    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. Recom- mendation ITU-R M.2160-0, 2023

    2030

  2. [2]

    Management and orchestration; concepts, use cases and re- quirements,

    3GPP, “Management and orchestration; concepts, use cases and re- quirements,” 3rd Generation Partnership Project (3GPP), Tech. Rep. TS 28.530, 2024, release 17

    2024

  3. [3]

    Management and orchestration; architecture framework,

    ——, “Management and orchestration; architecture framework,” 3rd Generation Partnership Project (3GPP), Tech. Rep. TS 28.533, 2024, release 17

    2024

  4. [4]

    Network functions virtualisation (NFV) release 5; manage- ment and orchestration; architectural framework specification,

    ETSI, “Network functions virtualisation (NFV) release 5; manage- ment and orchestration; architectural framework specification,” European Telecommunications Standards Institute, Tech. Rep. ETSI GS NFV 006 V5.2.1, 2024

    2024

  5. [5]

    O-RAN slicing architecture,

    O-RAN Alliance, “O-RAN slicing architecture,” O-RAN Alliance, Working Group 1, Tech. Rep. O-RAN.WG1.TS.Slicing-Architecture- R004-v14.01, 2024

    2024

  6. [6]

    O-RAN operations and maintenance architecture,

    ——, “O-RAN operations and maintenance architecture,” O-RAN Alliance, Working Group 10, Tech. Rep. O-RAN.WG10.OAM- Architecture, 2023

    2023

  7. [7]

    Management and orchestration; 5G network resource model (NRM); stage 2 and stage 3,

    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

    2024

  8. [8]

    ONAP service orchestrator architecture,

    ONAP Project, “ONAP service orchestrator architecture,” https://docs. onap.org/projects/onap-so/en/latest/architecture/architecture.html, 2026, accessed: Jun. 3, 2026

    2026

  9. [9]

    ONAP service orchestrator repository,

    ——, “ONAP service orchestrator repository,” https://github.com/onap/ so, 2026, accessed: Jun. 3, 2026

    2026

  10. [10]

    Management and orchestration; provisioning,

    3GPP, “Management and orchestration; provisioning,” 3rd Generation Partnership Project (3GPP), Tech. Rep. TS 28.531, 2023, release 17

    2023

  11. [11]

    Compensating transaction pattern,

    Microsoft Azure Architecture Center, “Compensating transaction pattern,” https://learn.microsoft.com/en-us/azure/architecture/patterns/ compensating-transaction, 2026, accessed: Jun. 3, 2026

    2026

  12. [12]

    Nephio: Cloud native network automation,

    Nephio Project, “Nephio: Cloud native network automation,” https:// nephio.org/, 2026, accessed: Jun. 3, 2026

    2026

  13. [13]

    Athena: An intelligent multi-x cloud native network operator,

    A. Mohammadi and N. Nikaein, “Athena: An intelligent multi-x cloud native network operator,”IEEE Journal on Selected Areas in Commu- nications, vol. 42, no. 2, pp. 460–472, 2024

    2024

  14. [14]

    Open source MANO,

    ETSI OSM, “Open source MANO,” https://osm.etsi.org/, 2026, ac- cessed: Jun. 3, 2026

    2026

  15. [15]

    Tacker: OpenStack NFV orchestration,

    OpenStack, “Tacker: OpenStack NFV orchestration,” https://wiki. openstack.org/wiki/Tacker, 2026, accessed: Jun. 3, 2026. 15

    2026

  16. [16]

    Network functions virtualisation (NFV); management and or- chestration,

    ETSI, “Network functions virtualisation (NFV); management and or- chestration,” European Telecommunications Standards Institute, Tech. Rep. ETSI GS NFV-MAN 001 V1.1.1, 2014

    2014

  17. [17]

    Network functions virtualisation (NFV); management and or- chestration; report on NFV-MANO architectural framework options,

    ——, “Network functions virtualisation (NFV); management and or- chestration; report on NFV-MANO architectural framework options,” European Telecommunications Standards Institute, Tech. Rep. ETSI GS NFV-IFA 036, 2021

    2021

  18. [18]

    Network functions virtualisation (NFV); management and or- chestration; requirements and interfaces specification for containerized VNF management,

    ——, “Network functions virtualisation (NFV); management and or- chestration; requirements and interfaces specification for containerized VNF management,” European Telecommunications Standards Institute, Tech. Rep. ETSI GS NFV-IFA 040, 2021

    2021

  19. [19]

    OSM lifecycle manager,

    ETSI OSM, “OSM lifecycle manager,” https://osm.etsi.org/gitlab/osm/ lcm, 2026, accessed: Jun. 5, 2026

    2026

  20. [20]

    Tacker source code,

    OpenStack, “Tacker source code,” https://github.com/openstack/tacker, 2026, accessed: Jun. 5, 2026

    2026

  21. [21]

    Coordinated management of 5G core slices by MANO and OSS/BSS,

    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

    2021

  22. [22]

    ORANSlice: An open source 5G network slicing platform for O-RAN,

    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,” inProc. 30th Annu. Int. Conf. Mobile Computing and Networking (ACM MobiCom), Washington D.C., USA, 2024, pp. 2297–2302

    2024

  23. [23]

    Cloud native lightweight slice orchestration (CLiSO) framework,

    S. Arora, A. Ksentini, and C. Bonnet, “Cloud native lightweight slice orchestration (CLiSO) framework,”Computer Communications, vol. 213, pp. 1–12, 2024

    2024

  24. [24]

    NASP: Network slice as a service platform for 5G networks,

    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

    2026

  25. [25]

    Nephio source code,

    Nephio Project, “Nephio source code,” https://github.com/ nephio-project/nephio, 2026, accessed: Jun. 5, 2026

    2026

  26. [26]

    Operator pattern,

    Kubernetes Documentation, “Operator pattern,” https://kubernetes.io/ docs/concepts/extend-kubernetes/operator/, 2026, accessed: Apr. 30, 2026

    2026

  27. [27]

    System architecture for the 5G system (5GS),

    3GPP, “System architecture for the 5G system (5GS),” 3rd Generation Partnership Project (3GPP), Tech. Rep. TS 23.501, 2023, release 17

    2023

  28. [28]

    Operator SDK repository,

    Operator Framework, “Operator SDK repository,” https://github.com/ operator-framework/operator-sdk, 2026, accessed: Apr. 30, 2026

    2026

  29. [29]

    OpenAirInterface repository,

    OpenAirInterface Software Alliance, “OpenAirInterface repository,” https://gitlab.eurecom.fr/oai/openairinterface5g, 2026, accessed: Apr. 30, 2026

    2026

  30. [30]

    Open5GS repository,

    Open5GS Project, “Open5GS repository,” https://github.com/open5gs/ open5gs, 2026, accessed: Apr. 30, 2026

    2026

  31. [31]

    FlexRIC: An SDK for next- generation SD-RANs,

    R. Schmidt, M. Irazabal, and N. Nikaein, “FlexRIC: An SDK for next- generation SD-RANs,” inProc. 17th Int. Conf. Emerging Networking EXperiments and Technologies (CoNEXT), 2021, pp. 411–425

    2021

  32. [32]

    tc(8): Show / manipulate traffic control settings,

    Linux man-pages Project, “tc(8): Show / manipulate traffic control settings,” https://man7.org/linux/man-pages/man8/tc.8.html, 2025, ac- cessed: Apr. 30, 2026

    2025

  33. [33]

    Tc-ran: A programmable traffic control service model for 5g/6g sd-ran,

    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

    2024

  34. [34]

    Chaos mesh: A powerful chaos engineering platform for Kubernetes,

    Chaos Mesh Authors, “Chaos mesh: A powerful chaos engineering platform for Kubernetes,” https://chaos-mesh.org/, 2026, accessed: Jun. 18, 2026

    2026

  35. [35]

    Dobies and J

    J. Dobies and J. Wood,Kubernetes Operators: Automating the Container Orchestration Platform. Sebastopol, CA, USA: O’Reilly Media, 2020

    2020

  36. [36]

    Hightower, B

    K. Hightower, B. Burns, and J. Beda,Kubernetes: Up and Running. Sebastopol, CA, USA: O’Reilly Media, 2017

    2017

  37. [37]

    Procedures for the 5G system (5GS),

    3GPP, “Procedures for the 5G system (5GS),” 3rd Generation Partner- ship Project (3GPP), Tech. Rep. TS 23.502, 2024, release 17

    2024

  38. [38]

    Numbering, addressing and identification,

    ——, “Numbering, addressing and identification,” 3rd Generation Part- nership Project (3GPP), Tech. Rep. TS 23.003, 2023, release 17

    2023

  39. [39]

    5G system; network exposure function northbound APIs; stage 3,

    ——, “5G system; network exposure function northbound APIs; stage 3,” 3rd Generation Partnership Project (3GPP), Tech. Rep. TS 29.522, 2025, release 17

    2025

  40. [40]

    Study on O-RAN slicing,

    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

    2022

  41. [41]

    O-RAN A1 interface: General aspects and principles,

    ——, “O-RAN A1 interface: General aspects and principles,” O-RAN Alliance, Working Group 2, Tech. Rep. O-RAN.WG2.A1GAP, 2023

    2023

  42. [42]

    O-RAN E2 application protocol (E2AP),

    ——, “O-RAN E2 application protocol (E2AP),” O-RAN Alliance, Working Group 3, Tech. Rep. O-RAN.WG3.E2AP, 2023

    2023

  43. [43]

    O-RAN R1 interface: General aspects and principles,

    ——, “O-RAN R1 interface: General aspects and principles,” O-RAN Alliance, Working Group 2, Tech. Rep. O-RAN.WG2.R1GAP, 2023

    2023

  44. [44]

    Cloud native manifesto: An operator view,

    NGMN Alliance, “Cloud native manifesto: An operator view,” Next Generation Mobile Networks Alliance, Tech. Rep., 2023, version 1.0, approved 6 September 2023

    2023

  45. [45]

    Controllers,

    Kubernetes Documentation, “Controllers,” https://kubernetes.io/docs/ concepts/architecture/controller/, 2026, accessed: Jun. 3, 2026

    2026

  46. [46]

    Operator lifecycle manager,

    Operator Framework, “Operator lifecycle manager,” https://github.com/ operator-framework/operator-lifecycle-manager, 2024, accessed: Apr. 23, 2026

    2024

  47. [47]

    inotify(7): Monitoring filesystem events,

    Linux man-pages Project, “inotify(7): Monitoring filesystem events,” https://man7.org/linux/man-pages/man7/inotify.7.html, 2025, accessed: Apr. 30, 2026

    2025