Pith. sign in

REVIEW 4 major objections 5 minor 1 cited by

A Study on 5G Network Slice Isolation Based on Native Cloud and Edge Computing Tools

T0 review · 4 major / 5 minor · reviewed 2026-08-09 · deepseek-v4-flash

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

Pith's one-line read The paper argues that combining CPU limits with scheduler priority keeps a priority 5G slice within about 5 percent of its uncontended throughput.

desk verdict Useful empirical matrix on Kubernetes-based slice isolation for Open5GS, but the unsupported memory claim, missing significance tests, and unverified CPU-contention mechanism mean it needs major revision before publication. read the letter →

arxiv 2502.02842 v2 pith:EBAYBUJT submitted 2025-02-05 cs.NI cs.DC

Maiko Andrade , Juliano Araujo Wickboldt This is my paper · ORCID
classification cs.NIcs.DC
keywords 5GnetworkslicingsliceisolationedgecomputingKubernetesCPUresourcelimitsbandwidthlimitationfunctionvirtualization
verification ladder T0 review T1 audit T2 compute T3 formal

The pith

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

The reading

The paper argues that slice isolation in private 5G networks can be improved using resource-control knobs that already exist in container-orchestrated edge clouds, without adding 5G-specific isolation hardware or protocols. In a hospital telemedicine scenario, the authors run one high-priority video slice against four background slices whose user-plane functions share a single edge node, and they vary CPU limits, Linux scheduler priorities, and egress bandwidth caps individually and in combination. Their central finding is that capping the CPU of the non-priority user-plane functions while giving the priority function a higher scheduler priority keeps priority-slice throughput within roughly 5 percent of the single-slice ideal, at the cost of the background slices. Memory limits show no measurable effect, CPU priority alone is ineffective, and severe bandwidth caps protect the priority slice but can push background latency into seconds. A sympathetic reader would take away a practical, reproducible recipe for protecting a priority slice in a low-cost private 5G deployment.

What carries the argument

The load-bearing object is the user-plane function (UPF), the packet-forwarding network function where all slices' data traffic converges; in the testbed all five UPFs run on one resource-constrained edge node, so the CPU scheduler is the shared resource through which slices interfere. Three native control mechanisms are applied to the UPFs: CPU limits and requests expressed in millicpu and enforced by cgroups through the container orchestrator; the Linux nice value, which changes the scheduler's time-slice fraction according to the formula $\mathrm{fraction}(i) = \frac{\mathrm{timeslice}(i)}{\sum_j \mathrm{timeslice}(j)}$; and egress bandwidth shaping using Earliest Departure Time (EDT) in the eBPF-based network plugin chosen for its lower latency overhead. The key comparison metric is the priority slice's average throughput during the last five minutes of each 20-minute run, measured against Experiment 1 (154.04 Mbps, single slice) as the ideal-isolation reference and Experiment 5 (119.12 Mbps, five slices without controls) as the worst case.

What would settle it

Rerun the five-slice workload with all UPFs on separate edge nodes or with a link faster than 1 Gbps; if the priority slice still loses roughly 20 percent of its throughput as slices are added, CPU contention is not the cause. Alternatively, log host CPU utilization at the UPF node during the runs: if the node is not CPU-saturated at the moments priority throughput drops, the mechanism the paper attributes the gain to is not the one doing the work.

Watch

Extended reading notes

Core claim

The authors claim that interference between network slices sharing an edge node is primarily CPU contention among the user-plane functions (UPFs), and that native mechanisms—container-orchestrator CPU quotas backed by cgroups, the Linux nice value, and egress bandwidth shaping—can enforce isolation under that contention. In their best configuration (Experiment 25, which limits non-priority UPFs to 500 millicpu, sets their nice value to 5, assigns the priority UPF a nice value of -5, and activates bandwidth control without a hard cap), the priority slice sustains an average of 145.83 Mbps, a 5.33% reduction from the 154.04 Mbps single-slice best case, while the background slices collectively lose only 6.58% relative to the five-slice worst case. They also report that lowering non-priority CPU limits from none to 500m to 250m progressively restores priority throughput in the isolated CPU experiments, that memory limits have negligible effect because UPF memory usage is flat, and that combining CPU limits with nice outperforms either mechanism alone. The paper frames this as a methodology and a dataset rather than a new protocol: the same scripts and measurements are released for reproduction and for machine-learning studies.

Load-bearing premise

The load-bearing premise is that the interference the experiments measure comes from CPU contention among the UPFs on the shared edge node, rather than from the 1 Gbps switch link or from artifacts of the UE/RAN simulator used to generate traffic.

Editorial extensions

If this is right

  • Operators of private 5G networks can protect a priority slice by capping the CPU of non-priority UPFs, with no changes to the 5G core protocol stack.
  • Combining a CPU cap with a scheduler priority boost is more effective than either alone, since CPU priority alone shows no benefit in these tests.
  • Memory limits can be left out of isolation configurations for this class of workload, because UPF memory usage stays flat.
  • A 150 Mbps egress cap protects the priority slice but can make low-priority slices nearly unusable and drive their latency to seconds, so bandwidth caps should be applied cautiously.
  • The public experimental data and scripts turn the result into a baseline for reproducing the scenario and for training data-driven slice controllers.

Reading between the lines

Editorial extensions of the paper, not claims the author makes directly.

  • If the CPU-contention mechanism is general, the same native knobs should isolate any pair of containerized data-plane functions sharing a node, not just 5G UPFs, which would extend the recipe to other virtualized network functions.
  • The observation that bandwidth adjustments do not require application restarts suggests a control loop could tune egress caps dynamically; the released dataset is a plausible training set for such a controller, though the paper does not build one.
  • The 5 percent figure is tied to the testbed's 1 Gbps link and single-CPU edge nodes; on multi-core nodes with hardware multi-queue NICs, EDT-based shaping may interact differently, so the quantitative result should be revalidated before transfer to larger deployments.
  • The paper's explanation that nice alone fails because the bottleneck is the network link is testable: repeating the nice-only experiments with a faster link should make scheduler priority visible again if the explanation is right.
Share X Bluesky LinkedIn Reddit HN

Signed reviews

No signed human review yet.

Editorial analysis

A structured set of objections, weighed in public.

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

Referee Report

4 major / 5 minor

Summary. The paper reports an experimental study of network-slice isolation in a private 5G network built from Open5GS, Kubernetes, Cilium, and the my5G-RANTester emulator. The authors place five UPFs on a single edge node, generate medical-video-like traffic with iPerf, and run 26 experiments (10 runs each) that apply CPU limits, Linux nice values, and bandwidth limits to non-priority slices, individually and in combination. The headline findings are that CPU limits on non-priority UPFs improve priority-slice throughput, memory limits have no observable effect, and a combination of CPU limiting with prioritization keeps the priority slice within about 5% of its single-slice reference throughput, with Experiment 25 identified as the best configuration. The paper contributes a reproducible testbed, public scripts, and a dataset.

Significance. If the causal mechanism behind the reported results were established, the paper would provide practical, low-cost guidance for private 5G operators using open-source cores on Kubernetes, and the public scripts and data would be a useful community resource. The experimental design is systematic, and the authors deserve credit for making the artifacts available and for reporting per-experiment statistics. However, the significance is conditional: the central claim requires evidence that the observed interference is caused by CPU contention among co-located UPFs, and that evidence is not present in the paper as written.

major comments (4)
  1. [§5.1, §5.3, §5.4] The central causal claim—that CPU limits on the non-priority UPFs protect priority-slice throughput—is not supported by mechanism evidence. The testbed's offered load is set to 1080 Mbps (§5.1), but in baseline Experiment 5 the aggregate received throughput is only about 234 Mbps (119.12 + 114.59 Mbps in Figure 9), far below the 1 Gbps link; this indicates that the bottleneck is in the software UPF or in the my5G-RANTester emulator, not the physical link. §5.4 itself attributes the null effect of nice to the fact that 'the bottleneck lies in the network, which limits the availability of packets for processing by the network function.' Under that reading, CPU limits on a UPF could simply throttle the traffic that the emulator is able to inject, without establishing a CPU-scheduling isolation mechanism that would transfer to a real RAN or to multi-node edge deployments. No CPU-utilization, cgroup-throttling, or packet-drop measurements are reported (the CPU metrics mentioned in §5.1 are never analyzed), so the experiment cannot distinguish CPU contention among the five co-located UPFs from emulator-side saturation. This is load-bearing for the paper's operational recommendation, and it needs to be addressed with either additional measurements or a substantially qualified claim.
  2. [§5.1, Abstract] The abstract's claim that 'memory restrictions have minimal impact' is not supported by the experiments as reported. §5.1 states that memory limits were tried during initial configuration, found to have 'no significant impact,' and then 'excluded from subsequent experiments,' but no controlled experiment, table, or quantitative result for memory limitation is presented anywhere in Section 5. Either the memory experiments need to be reported with the same detail as the CPU and bandwidth experiments, or the claim should be removed from the abstract and conclusions.
  3. [§5.3, §5.9, Figure 21] The ranking of configurations, in particular the statement that 'Experiment 25 is superior to the other experiments' (§5.9), is based on differences that appear to be within the noise of the measurements. In Figure 21, the priority-slice means for Experiments 23-26 are 137.50, 140.40, 145.83, and 142.14 Mbps with standard deviations between 17 and 20 Mbps; in §5.3, the CPU-limit progression 138→142→151 Mbps is reported with comparable dispersion. No confidence intervals, hypothesis tests, or effect sizes are given, and the 10 runs per experiment are not analyzed as repeated measurements. The 'approximately 5% variation' headline in the conclusion therefore needs statistical support before it can be treated as a substantive finding.
  4. [§5.9, Conclusion] The conclusion states that 'the combined use of CPU limitation and prioritization provides better performance,' but the data in Figures 17 and 23 show that CPU limitation alone (Experiment 8: 147.09 Mbps) and CPU limitation with bandwidth-control activation (Experiment 19: 149.08 Mbps) achieve priority-slice throughput at least as high as the combined CPU+nice experiments (Experiment 15: 146.52, Experiment 16: 145.74). The incremental contribution of nice over CPU limits is therefore not demonstrated; the paper should compare the combined configurations against their CPU-only counterparts explicitly and quantify any improvement.
minor comments (5)
  1. [Figures 8-24, Tables 1-6] Several figures contain corrupted labels (e.g., '/uni00000014 ...') and tables contain typos such as 'T able' and 'milicpu'; these should be cleaned before publication.
  2. [§5.4, §4.4] The statement in §5.4 that 'the bottleneck lies in the network' conflicts with the §4.4 premise that resource contention among the co-located UPFs is the dominant effect; the text should be made internally consistent.
  3. [§7, Abstract, §4.4] The Data Availability section says the data are 'accessible upon request,' while the abstract and §4.4 state that the scripts and data are publicly available on GitHub; these statements should be reconciled.
  4. [Figures 10, 12, 24] Several latency tables have missing IQR cells (e.g., Experiments 2-4 in Figure 10, Experiment 7 in Figure 12), and Figure 24's table appears to copy throughput values into a latency table (Experiment 1 shows 154.04 in a latency-only figure); these need correction.
  5. [References] Several references are incomplete or inconsistently formatted (e.g., [1] and [13] lack publication years, and some venue fields are missing); the reference list should be checked against the journal style.

Circularity Check

0 steps flagged · score 1.0 of 10

Empirical measurement study; no derived quantity reduces to its inputs by construction, and the only self-citation is background motivation, not load-bearing.

full rationale

The paper's claims are observational: throughput and latency are measured by iPerf, Telegraf, and Prometheus under configured CPU, nice, and bandwidth controls, not derived from fitted parameters or from equations whose target equals an input. Experiment 1 provides a measured reference level (154.04 Mbps for the priority slice alone), and later experiments compare measured values; no prediction is produced from a fit, and no quantity is defined in terms of the reported outcome. The only notable self-citation is Ref. [6], which includes a coauthor of the present paper and is used in Sections 2.6.2 and 2.7 to motivate the choice of Open5GS and my5G-RANTester and to describe tool maturity; this is background and does not support the central empirical conclusion, so it is not load-bearing. The skeptical concern that the bottleneck may be the 1 Gbps link or the emulator rather than CPU contention is a validity or correctness threat, not circularity: even if the mechanism were misidentified, the reported measurements would still be measurements. Accordingly, no circular step is identified.

Assumptions & free parameters 3 free parameters · 4 assumptions · 0 invented entities

The central claims rest on experimental assumptions rather than derived constants. The CPU limit levels, nice values, and bandwidth caps are chosen experimental settings, not fitted parameters. No new entities are introduced. The key domain assumptions are that cgroups enforce Kubernetes limits faithfully, that my5G-RANTester and iPerf stand in for real UEs and video traffic, that concentrating UPFs on one node produces representative contention, and that the bottleneck is processing rather than the network link.

free parameters (3)
  • Secondary UPF CPU limits = 500m and 250m (millicpu)
    Chosen by the authors for the isolation experiments; the beneficial effect is demonstrated only at these levels.
  • nice values for UPFs = -5 (priority) and 5 (others)
    Arbitrary prioritization levels; no optimization was performed.
  • Bandwidth limits for secondary slices = 150 Mbps and 75 Mbps
    Chosen to test moderate and severe caps; the 75 Mbps case was later excluded from combined experiments as atypical.
assumptions (4)
  • domain assumption Kubernetes CPU and memory limits are enforced by cgroups on the edge nodes exactly as specified.
    Section 4.3.1 states the kubelet enforces limits via cgroups; the interpretation of Experiments 6 to 8 depends on this enforcement being reliable on the testbed.
  • domain assumption my5G-RANTester plus iPerf isochronous traffic adequately represents 5G UEs and high-definition video for slice-interference purposes.
    Section 5.1 describes pods that run my5G-RANTester, iPerf at 45 Mbps and 60 fps, and Telegraf; the findings are only meaningful if this stand-in is faithful.
  • domain assumption All UPFs sharing one edge node creates the same contention patterns as a real edge deployment.
    Section 4.4 deliberately concentrates UPFs on one node; the external validity of the results rests on this being representative.
  • domain assumption The network bottleneck is the 1 Gbps link, so observed interference is due to processing, not other network elements.
    Section 5.4 states the bottleneck lies in the network, and the whole CPU-limitation story depends on CPU being the scarce resource for UPFs.

how reviews work

0 comments
Cite this review

Pith. "Pith review of A Study on 5G Network Slice Isolation Based on Native Cloud and Edge Computing Tools." pith.science (2026). https://pith.science/paper/EBAYBUJT

@misc{pith2026250202842,
  author       = {Pith},
  title        = {Pith review of: A Study on 5G Network Slice Isolation Based on Native Cloud and Edge Computing Tools},
  year         = {2026},
  howpublished = {\url{https://pith.science/paper/EBAYBUJT}},
  note         = {Machine review of arXiv:2502.02842}
}
read the original abstract

5G networks support various advanced applications through network slicing, network function virtualization (NFV), and edge computing, ensuring low latency and service isolation. However, private 5G networks relying on open-source tools still face challenges in maturity and integration with edge/cloud platforms, compromising proper slice isolation. This study investigates resource allocation mechanisms to address this issue, conducting experiments in a hospital scenario with medical video conferencing. The results show that CPU limitations improve the performance of prioritized slices, while memory restrictions have minimal impact. The generated data and scripts have been made publicly available for future research and machine learning applications.

Discussion (0). Continue with ORCID to comment.

Forward citations

Cited by 1 Pith paper

Reviewed papers in the Pith corpus that reference this work. Sorted by Pith novelty score. Full citation record

  1. WiLLM: an Open Framework for LLM Services over Wireless Systems

    cs.NI 2025-06 conditional novelty 6.0 of 10

    WiLLM is a new open-source platform plus dataset for running and measuring LLM services over live wireless networks, with evidence that LLM traffic is bidirectional, bursty, and coupled to network slicing.

Reference graph

Works this paper leans on

37 extracted references · 26 canonical work pages · cited by 1 Pith paper

  1. [1]

    Hassan, N., Yau, K.-L., Wu, C.: Edge computing in 5g: A review PP, 1–1 https: //doi.org/10.1109/access.2019.2938534

    arXiv 2019

  2. [2]

    In: 2022 3rd International Conference on Innovations in Computer Science AND Software Engineering (ICONICS), pp

    Islam Farooqui, M.N., Mubashir Khan, M., Farooq, F., Arshad, J.: A comparative analysis of 5g network slicing simulators. In: 2022 3rd International Conference on Innovations in Computer Science AND Software Engineering (ICONICS), pp. 1–8 (2022). https://doi.org/10.1109/ICONICS56716.2022.10100574

    work page arXiv 2022

  3. [3]

    In: 2020 European Conference on Networks and Communications (EuCNC), pp

    Gonzalez, A.J., Ordonez-Lucena, J., Helvik, B.E., Nencioni, G., Xie, M., Lopez, D.R., Grønsund, P.: The isolation concept in the 5g network slicing. In: 2020 European Conference on Networks and Communications (EuCNC), pp. 12–16 (2020). https://doi.org/10.1109/EuCNC48522.2020.9200939

    arXiv 2020

  4. [4]

    In: 2018 IEEE 5G World Forum (5GWF), pp

    Luong, D.-H., THIEU, H.-T., OUTTAGARTS, A., GHAMRI-DOUDANE, Y.: Predictive autoscaling orchestration for cloud-native telecom microservices. In: 2018 IEEE 5G World Forum (5GWF), pp. 153–158. https://doi.org/10.1109/ 5gwf.2018.8516950

    work page arXiv 2018

  5. [5]

    Silveira, L.B.D., de Resende, H.C., Both, C.B., Marquez-Barja, J.M., Silvestre, B., Cardoso, K.V.: Tutorial on communication between access networks and the 5g core 216(109301), 109301–109301 https://doi.org/10.1016/j.comnet.2022.109301

    work page arXiv

  6. [7]

    In: 2019 International Conference on Advances in Computing, Communication and Control (ICAC3), pp

    Gupta, R.K., Misra, R.: Machine learning-based slice allocation algorithms in 5g networks. In: 2019 International Conference on Advances in Computing, Communication and Control (ICAC3), pp. 1–4 (2019). https://doi.org/10.1109/ ICAC347590.2019.9036741

    work page arXiv 2019

  7. [8]

    In: 2021 International Conference on Information Science and Communications Technologies (ICISCT), pp

    Souza Neto, F.J., Amatucci, E., Nassif, N.A., Marques Farias, P.A.: Analysis for comparison of framework for 5g cor implementation. In: 2021 International Conference on Information Science and Communications Technologies (ICISCT), pp. 1–5. https://doi.org/10.1109/icisct52966.2021.9670414

    work page arXiv 2021

  8. [9]

    In: 2019 IEEE Conference of Russian Young Researchers in Electrical and Electronic Engineering (EIConRus)

    Shorov, A.: 5g testbed development for network slicing evaluation. In: 2019 IEEE Conference of Russian Young Researchers in Electrical and Electronic Engineering (EIConRus). IEEE. https://doi.org/10.1109/eiconrus.2019.8656861

    work page arXiv 2019

Show all 37 references
  1. [10]

    Scotece, D., Noor, A., Foschini, L., Corradi, A.: 5g-kube: Complex telco core infrastructure deployment made low-cost 61(7), 26–30 https://doi.org/10.1109/ mcom.006.2200693

  2. [11]

    In: 2021 24th Conference on Innovation in Clouds, Internet and Networks and Workshops (ICIN), pp

    Khaturia, M., Manjeshwar, A.N., Jha, P., Karandikar, A.: 5g-serv: Decoupling user control and network control in the 3gpp 5g network. In: 2021 24th Conference on Innovation in Clouds, Internet and Networks and Workshops (ICIN), pp. 75–

    2021

  3. [12]

    Arabian Journal for Science and Engineering 48(2), 2313–2330 (2023) https://doi.org/10.1007/ s13369-022-07183-9

    Ghaffar, A., Aziz, A., Mahmoud, A., Sheltami, T., Abu-Amara, M.: A survey on software-defined networking-based 5g mobile core architectures. Arabian Journal for Science and Engineering 48(2), 2313–2330 (2023) https://doi.org/10.1007/ s13369-022-07183-9

    2023

  4. [13]

    Academic Press

    Rommer, S., Hedman, P., Olsson, M., Frid, L., Sultana, S., Mulligan, C.: 5G Core Networks. Academic Press

  5. [14]

    IEEE Transactions on Mobile Computing 22(12), 6921–6937 (2023) https://doi.org/10.1109/TMC.2022.3201512

    Singh, S.K., Rothenberg, C.E., Langlet, J., Kassler, A., V¨ or¨ os, P., Laki, S., Pongr´ acz, G.: Hybrid p4 programmable pipelines for 5g gnodeb and user plane functions. IEEE Transactions on Mobile Computing 22(12), 6921–6937 (2023) https://doi.org/10.1109/TMC.2022.3201512

    2023

  6. [15]

    IEEE Access PP, 1–1 https://doi.org/10.1109/access.2024.3367120

    H ˚ akeg ˚ ard, J., Lundqvist, H., Rauniyar, A., Morris, P.: Performance evaluation of an open source implementation of a 5g standalone platform. IEEE Access PP, 1–1 https://doi.org/10.1109/access.2024.3367120

    2024

  7. [16]

    Accessed: 12 de Agostos de 2024

    OpenAirInterface: OpenAirInterface - 5G software alliance for democratising wireless innovation. Accessed: 12 de Agostos de 2024. https://openairinterface. org/ 42

    2024

  8. [17]

    Accessed: 12 de Agostos de 2024

    srsRAN, P.: srsRAN Project Documentation. Accessed: 12 de Agostos de 2024. https://docs.srsran.com/projects/project/en/latest/index.html

    2024

  9. [18]

    In: NOMS 2024-2024 IEEE Network Operations and Management Symposium, pp

    Rouili, M., Saha, N., Golkarifard, M., Zangooei, M., Boutaba, R., Onur, E., Saleh, A.: Evaluating open-source 5g sa testbeds: Unveiling performance dis- parities in ran scenarios. In: NOMS 2024-2024 IEEE Network Operations and Management Symposium, pp. 1–6 (2024). https://doi....

    2024

  10. [19]

    https://github.com/aligungr/UERANSIM

    G ¨UNG ¨OR, A.: UERANSIM. https://github.com/aligungr/UERANSIM. Accessed: 12 de Agostos de 2024 (2024)

    2024

  11. [20]

    https://open5gs.org

    Lee, S.: Open5GS. https://open5gs.org. Accessed: 12 de Agostos de 2024

    2024

  12. [21]

    Wireless Communications and Mobile Computing 2021, 6655216 (2021) https://doi.org/10.1155/2021/6655216

    Esmaeily, A., Kralevska, K.: Small-scale 5g testbeds for network slicing deploy- ment: A systematic review. Wireless Communications and Mobile Computing 2021, 6655216 (2021) https://doi.org/10.1155/2021/6655216

    2021 doi

  13. [22]

    IEEE Wireless Communica- tions 25(5), 30–37 (2018) https://doi.org/10.1109/MWC.2018.1800050

    Garcia-Aviles, G., Gramaglia, M., Serrano, P., Banchs, A.: Posens: A practical open source solution for end-to-end network slicing. IEEE Wireless Communica- tions 25(5), 30–37 (2018) https://doi.org/10.1109/MWC.2018.1800050

    2018

  14. [23]

    Computer Communications 150, 1–12 (2020) https://doi.org/10.1016/j.comcom.2019.11.003

    Garcia-Aviles, G., Gramaglia, M., Serrano, P., Gringoli, F., Fuente-Pascual, S., Labrador Pavon, I.: Experimenting with open source tools to deploy a multi- service and multi-slice mobile network. Computer Communications 150, 1–12 (2020) https://doi.org/10.1016/j.comcom.2019.11.003

    2020 doi

  15. [24]

    In: 2018 IEEE Symposium on Computer Applications & Industrial Electronics (ISCAIE), pp

    Dzogovic, B., Do, V.T., Feng, B., Do, T.: Building virtualized 5g networks using open source software. In: 2018 IEEE Symposium on Computer Applications & Industrial Electronics (ISCAIE), pp. 360–366 (2018). https://doi.org/10.1109/ ISCAIE.2018.8405499

    2018

  16. [26]

    IEEE Transactions on Network and Service Management 21(5), 5291–5303 (2024) https://doi.org/10

    De Simone, L., Di Mauro, M., Natella, R., Postiglione, F.: Performance and avail- ability challenges in designing resilient 5g architectures. IEEE Transactions on Network and Service Management 21(5), 5291–5303 (2024) https://doi.org/10. 1109/TNSM.2024.3404560

    2024

  17. [27]

    In: NOMS 2023-2023 IEEE/IFIP Network Operations and Management Symposium, pp

    Minardi, M., Drif, Y., Vu, T.X., Maity, I., Politis, C., Chatzinotas, S.: Sdn-based testbed for emerging use cases in beyond 5g ntn-terrestrial networks. In: NOMS 2023-2023 IEEE/IFIP Network Operations and Management Symposium, pp. 1–6 (2023). https://doi.org/10.1109/NOMS56928...

    2023

  18. [28]

    IEEE Transactions on Network and Service Management20(3), 3135–3147 (2023) https: //doi.org/10.1109/TNSM.2023.3235710

    Adeppady, M., Giaccone, P., Karl, H., Chiasserini, C.F.: Reducing microservices interference and deployment time in resource-constrained cloud systems. IEEE Transactions on Network and Service Management20(3), 3135–3147 (2023) https: //doi.org/10.1109/TNSM.2023.3235710

    2023

  19. [29]

    IEEE Transactions on Network and Service Management 20(1), 415–425 (2023) https://doi.org/10

    Muro, F., Baena, E., Fortes, S., Nielsen, L., Barco, R.: Noisy neighbour impact assessment and prevention in virtualized mobile networks. IEEE Transactions on Network and Service Management 20(1), 415–425 (2023) https://doi.org/10. 1109/TNSM.2022.3194137

    2023

  20. [30]

    In: 2024 IEEE 10th International Conference on Network Softwarization (NetSoft), pp

    Ait Aba, M., Kassis, M., Elkael, M., Araldo, A., Khansa, A.A., Castel-Taleb, H., Jouaber, B.: Efficient network slicing orchestrator for 5g networks using a genetic algorithm-based scheduler with kubernetes: Experimental insights. In: 2024 IEEE 10th International Conference on...

    2024

  21. [31]

    Manning Publications Co., Shelter Island, NY

    Luksa, M.: Terraform - up and Running, 2nd edn. Manning Publications Co., Shelter Island, NY

  22. [32]

    Nigel Poulton

    Poulton, N., Joglekar, P.: The Kubernetes Book. Nigel Poulton

  23. [33]

    Dakic, V., Redˇ zepagi´ c, J., Baˇ si´ c, M.,ˇZgrabli´ c, L.: Performance and latency effi- ciency evaluation of kubernetes container network interfaces for built-in and cus- tom tuned profiles 13(19), 1–100 https://doi.org/10.3390/electronics13193972

    doi

  24. [34]

    In: 2023 International Conference on Information Networking (ICOIN), pp

    Duong, V.-B., Kim, Y.: A design of service mesh based 5gcore network using cilium. In: 2023 International Conference on Information Networking (ICOIN), pp. 25–28. https://doi.org/10.1109/icoin56518.2023.10049044

    2023

  25. [35]

    Sukhija, N., Bautista, E.: Towards a framework for monitoring and analyzing high performance computing environments using kubernetes and prometheus. In: 2019 IEEE SmartWorld, Ubiquitous Intelligence & Computing, Advanced & Trusted Computing, Scalable Computing & Communications...

    2019

  26. [36]

    O’Reilly Media, Sebastopol, CA (2022)

    Brikman, Y.: Terraform - up and Running, 3rd edn. O’Reilly Media, Sebastopol, CA (2022)

    2022

  27. [37]

    https://isovalent.com/blog/post/ addressing-bandwidth-exhaustion-with-cilium-bandwidth-manager/

    Vibert, N.: Addressing Bandwidth Exhaustion with Cilium Band- width Manager - Isovalent. https://isovalent.com/blog/post/ addressing-bandwidth-exhaustion-with-cilium-bandwidth-manager/. [Accessed 16-01-2025] (2023)

    2023

  28. [38]

    John Wiley and Sons, Hoboken, NJ (2013) 44

    Silberschatz, A., Galvin, P.B., Gagne, P.: Operating System Concepts, 7th edition edn. John Wiley and Sons, Hoboken, NJ (2013) 44

    2013

  29. [79]

    https://doi.org/10.1109/icin51074.2021.9385552

    2021

Pith tools

Reviewed August 9, 2026 · model on record in the stance chip above.