Pith. sign in

REVIEW 3 major objections 4 minor 89 references

SLICES, a scientific instrument for the networking community

T0 review · 3 major / 4 minor · reviewed 2026-08-07 · deepseek-v4-flash

Pith's one-line read Computer networking research should be conducted on a shared, calibrated scientific instrument, and SLICES is that instrument.

desk verdict A clear, honest position paper for SLICES, but it raises its own feasibility objections and never answers them. read the letter →

arxiv 2502.09783 v1 pith:FUC6QRTA submitted 2025-02-13 cs.NI

classification cs.NI
keywords experimentally-drivennetworkingresearchscientificinstrumenttestbedfederationreproducibilityFAIRdata5G/6GnetworksSDN/NFVlifecycle
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 computer networking research has matured to the point where it needs a formal scientific instrument, not just scattered in-house testbeds, and that the European SLICES initiative is that instrument. It claims that a shared, large-scale, programmable research facility, built from current virtualization and radio-access technologies and managed under the ESFRI lifecycle, would make experimental results in networking reproducible, credible, and reusable. The authors draw on lessons from earlier testbeds and from the open-source 5G ecosystem to sketch the architecture and the full research-lifecycle support, including data management, FAIR principles, and integration with European open-science services, that such an instrument requires. A sympathetic reader would take the paper as a call to treat experimental networking as a science carried out on calibrated shared equipment, with the same seriousness as other experimental disciplines.

What carries the argument

The central object is SLICES itself, a distributed research infrastructure organized as a central hub plus national nodes, each node built from four subsystems: inter-facility and intra-facility switching, real-time and non-real-time computing, radio infrastructure, and end-user devices. It is a layered architecture comprising Resource, Virtualization, Orchestration, Northbound-Interface, Application, and UI layers, in which a central SLICES-Core application acts as a multi-domain orchestrator that glues NFV, MEC, and cloud-native orchestrators under one authority. The other load-bearing mechanism is the full research-lifecycle methodology, including FAIR data management, metadata, data governance, and reproducibility, which the authors say an instrument must provide rather than just raw testbed capacity.

What would settle it

See whether the fraction of networking papers whose experiments can be independently reproduced on SLICES rises above today's baseline within five years of the facility opening; if it does not, the paper's central claim is not borne out.

Watch

Extended reading notes

Core claim

The paper's central claim is that experimentally-driven networking research can and should be built on a scientific instrument: a distributed, programmable, pan-European facility called SLICES that supports the whole research lifecycle from experiment design through data collection to publication. The authors argue that previous generations of testbeds, from PlanetLab and ORBIT to GENI and FIRE, demonstrated both the value and the limits of federated platforms, and that the current availability of SDN/NFV, network slicing, disaggregation, and open-source 5G software makes a next-generation instrument feasible. They propose that SLICES should be governed under ESFRI, adopt FAIR data principles, and interoperate with EOSC, so that networking results become reproducible and credible in the same way as results in established sciences.

Load-bearing premise

The argument collapses if a large, centrally governed facility planned on a decade-long cycle cannot stay relevant in a field where technology changes quickly and researchers remain fragmented.

Editorial extensions

If this is right

  • If SLICES is right, networking journals and venues could come to expect artifacts that run on a shared facility rather than on unverifiable private testbeds.
  • Beyond-5G and 6G innovations could be tested end-to-end on a reference infrastructure before deployment, the way other fields test on calibrated instruments.
  • Small research groups and SMEs would gain access to large-scale 5G and edge facilities they cannot build themselves.
  • Data from experiments would be preserved under FAIR principles, making it possible to re-analyze and combine past experiments rather than repeat them from scratch.

Reading between the lines

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

  • The same reproducibility crisis exists in other computer-science fields; if SLICES works, its lifecycle and governance model could plausibly be copied by distributed-systems or AI/ML communities that also depend on experimental evidence.
  • The authors' emphasis on the research lifecycle suggests that the value of a testbed may shift from raw hardware to data stewardship; funders could start evaluating facilities by reproducibility metrics rather than capacity.
  • Whether the facility stays relevant depends on the open-source 5G ecosystem remaining consolidated; a divergence among projects like OAI, srsRAN, and O-RAN implementations would break the architecture's assumption that commodity software can stand in for proprietary network equipment.
Share X Bluesky LinkedIn Reddit HN

Editorial analysis

A structured set of objections, weighed in public.

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

Referee Report

3 major / 4 minor

Summary. The paper argues that computer-networking research needs a structured, experimentally driven methodology supported by a dedicated scientific instrument, and it presents the SLICES initiative as the European answer to that need. After introducing the ESFRI framework, the paper reviews enabling technologies (SDN/NFV, network slicing, disaggregation, CUPS, MEC), illustrates them with a 5G/O-RAN example, proposes a layered architecture for SLICES, and describes the research-lifecycle, FAIR-data, and EOSC-interoperability components of the design. The paper is a position/design document: it contains no experimental evaluation, and its contribution is a community-level proposal rather than a falsifiable technical result.

Significance. If realized as described, SLICES would be a substantial community resource: it would provide a pan-European, federated, programmable instrument for networking research, with explicit commitments to FAIR data, reproducible experiments, and EOSC interoperability. The paper's strengths are its broad and mostly accurate synthesis of current open-source RAN/core/MANO components, its concrete layered architecture (Section V), and its clear embedding of the proposal in the ESFRI lifecycle and Open Science agenda. The main weakness is that the feasibility claim rests on programmatic assertions: the paper acknowledges the standard objections to such an instrument but does not resolve them, and the sizing estimates and "lessons learned" framing are not supported by evidence.

major comments (3)
  1. [Section I and Sections V-VII] The paper opens by listing three objections to a networking scientific instrument: (i) unpredictable future questions, (ii) rapid technology evolution, and (iii) community fragmentation. The remainder of the paper describes the proposed architecture and technology choices but never returns to these objections. The architecture in Section V and the technology survey in Section IV are anchored to 5G NR, O-RAN, NFV-MANO, and Kubernetes; no mechanism is specified for refreshing or retiring components as the technology wave moves on. Because the value of a decade-scale ESFRI facility depends on continued relevance and community adoption, the central feasibility claim requires an explicit treatment of technology-refresh governance, incentives for a fragmented community to converge on one instrument, and evidence from predecessor facilities (GENI, FIRE, PAWR) about how large testbeds fared through technology transitions.
  2. [Section VI] The sentence "Our preliminary estimations for SLICES include up to 5,000 users ... 0.25PB-1PB of data storage ... and 5PB for the cloud-based datacenter" presents the sizing figures as facts, but no derivation, source, or sensitivity analysis is provided. These numbers are load-bearing for the ESFRI-scale feasibility argument: an instrument that is either grossly oversized or undersized would undermine the proposal. The authors should either derive the estimates from usage data of predecessor platforms (OneLab, PlanetLab Europe, GENI, PAWR) or explicitly label them as illustrative planning assumptions with stated caveats.
  3. [Abstract and Sections III-VII] The abstract claims that the paper "reports lessons learned from the design and operation of test platforms," but the body is largely a survey of enabling technologies and a proposed architecture. There is no systematic discussion of what succeeded or failed in PlanetLab, ORBIT, GENI, or FIRE, no metrics of adoption, reproducibility, or sustainability, and no analysis of why SLICES would avoid the fragmentation that the paper attributes to current practice. If the "lessons learned" claim is retained, the relevant evidence and analysis need to be included; otherwise the claim should be softened to "experience and design considerations."
minor comments (4)
  1. [Table I] The URLs in the srsLTE and SD-RAN rows appear to be swapped: the srsLTE row points to openairinterface.org and the SD-RAN row points to github.com/srsran/srsRAN.
  2. [Section IV.A] The phrase "the FlexRIC platform (also called as FlexRAN)" conflates two related but distinct pieces of software; the relationship between FlexRIC and FlexRAN should be clarified.
  3. [Section VIII and Section IX] There are several typographical issues: "lets consider" in Section VIII, "life-cyle" in Section IX, and "computer networks needs" in the abstract.
  4. [References [61] and [62]] References [61] and [62] are bare URLs without titles or authors; they should be completed so that readers can verify the sources.

Circularity Check

0 steps flagged · score 0.0 of 10

No circularity: the paper is a position/architecture paper with no derived predictions, fitted parameters, or construction-level equivalences.

full rationale

This paper is a community position and architecture description for the SLICES research infrastructure. It makes no quantitative predictions, fits no model parameters, and derives no formal result from an input. Its claims are programmatic: that networking research needs better experimental instruments, that ESFRI provides a suitable governance framework, and that a layered architecture built from existing open-source components (OAI, FlexRIC, OSM, Kubernetes, etc.) is a plausible design. The authors cite their own prior and ongoing work (e.g., OneLab, FlexRIC, SLICES design studies) and their own initiative documents (SLICES-Design Study Deliverable D4.2), but these citations are not load-bearing in the sense of a derivation: they are historical background, implementation choices, or pointers to ongoing design work. Section I candidly lists objections ('it is hard to predict the future landscape and challenging scientific questions, ii) the technology is evolving too quickly, and iii) the community is fragmented'), and the paper does not provide a quantitative argument resolving those objections, but an unsupported feasibility claim is a correctness/evidence gap, not circular reasoning. The sizing figures in Section VI (5,000 users, 50 GB/user on nodes, 1 TB/user on cloud, 0.25-1 PB and 5 PB storage) are presented as 'preliminary estimations' without derivation; again, unjustified assumptions are not circularity. No step in the paper reduces by construction to its own input, no fitted value is renamed as a prediction, and no uniqueness result is imported from the authors' prior work. The appropriate finding is therefore no significant circularity.

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

The paper makes no numerical derivations, so there are no fitted free parameters. Its central proposal rests on several domain assumptions about scientific methodology, the transferability of the ESFRI model, and the appropriateness of FAIR/EOSC. It introduces the SLICES infrastructure and its interoperability framework as new entities; both have external existence or planned status, but the framework lacks an independent implementation.

assumptions (4)
  • domain assumption Experimentally-driven research is a cornerstone of sound scientific methodology in networking
    Stated in Section I without empirical justification; the paper uses this premise to argue for the need for SLICES.
  • domain assumption The ESFRI lifecycle and governance model, designed for large physics and biology facilities, is applicable to a distributed digital-infrastructure testbed
    Section II assumes this transferability; if the ESFRI model is wrong for quickly evolving digital facilities, the central argument weakens.
  • domain assumption FAIR data principles and EOSC integration are sufficient and appropriate to solve reproducibility in networking research
    Sections VI-VII endorse these as the solution; no evidence from networking experiments is provided.
  • domain assumption Scale estimates of 5,000 users, 50GB/user, and 0.25-1PB storage are realistic planning figures
    Section VI presents these estimates without derivation; the architecture's data-management requirements depend on them.
invented entities (2)
  • SLICES-RI (proposed European research infrastructure) independent evidence
    purpose: To serve as a shared scientific instrument for experimentally-driven networking research across Europe
    The project has public funding (H2020 grant 101008468) and a public website, providing an externally checkable existence, although its scientific utility is not yet demonstrated.
  • SLICES-IF (SLICES Interoperability Framework)
    purpose: To define interoperability between SLICES and EOSC and other research infrastructures
    Described in Section VII as a planned interface; details are deferred to the authors' design-study deliverable D4.2, and no implementation is public yet.

how reviews work

0 comments
Cite this review

Pith. "Pith review of SLICES, a scientific instrument for the networking community." pith.science (2026). https://pith.science/paper/FUC6QRTA

@misc{pith2026250209783,
  author       = {Pith},
  title        = {Pith review of: SLICES, a scientific instrument for the networking community},
  year         = {2026},
  howpublished = {\url{https://pith.science/paper/FUC6QRTA}},
  note         = {Machine review of arXiv:2502.09783}
}
read the original abstract

A science is defined by a set of encyclopedic knowledge related to facts or phenomena following rules or evidenced by experimentally-driven observations. Computer Science and in particular computer networks is a relatively new scientific domain maturing over years and adopting the best practices inherited from more fundamental disciplines. The design of past, present and future networking components and architectures have been assisted, among other methods, by experimentally-driven research and in particular by the deployment of test platforms, usually named as testbeds. However, often experimentally-driven networking research used scattered methodologies, based on ad-hoc, small-sized testbeds, producing hardly repeatable results. We believe that computer networks needs to adopt a more structured methodology, supported by appropriate instruments, to produce credible experimental results supporting radical and incremental innovations. This paper reports lessons learned from the design and operation of test platforms for the scientific community dealing with digital infrastructures. We introduce the SLICES initiative as the outcome of several years of evolution of the concept of a networking test platform transformed into a scientific instrument. We address the challenges, requirements and opportunities that our community is facing to manage the full research-life cycle necessary to support a scientific methodology.

Figures

Figures reproduced from arXiv: 2502.09783 by the authors.

Figure 1
Figure 1. Open-RAN deployment and programmable interfaces [PITH_FULL_IMAGE:figures/full_fig_p006_1.png] view at source ↗
Figure 2
Figure 2. Cloud-native instantiation of the 5G Core Network [PITH_FULL_IMAGE:figures/full_fig_p008_2.png] view at source ↗
Figure 3
Figure 3. Key ONF SDN platforms [PITH_FULL_IMAGE:figures/full_fig_p008_3.png] view at source ↗
Figures from the paper (8 more)
Figure 4
Figure 4. Figure 4: ETSI NFV-MANO architecture and does the lifecycle management of VNFs. VNF lifecycle management involves establishing/configuring, preserving, and terminating VNFs; 3) NFV Orchestrator (NFVO) implements resource and service orchestration in the network. NFVO is split up…
Figure 5
Figure 5. Figure 5: A high-level view of a SLICES node from an equipment standpoint [PITH_FULL_IMAGE:figures/full_fig_p011_5.png]
Figure 6
Figure 6. Figure 6: SLICES Infrastructure conceptual architecture [PITH_FULL_IMAGE:figures/full_fig_p011_6.png]
Figure 7
Figure 7. Figure 7: Layered architecture for SLICES MySlice V2 [76], and will be further enhanced at later stages; 6) UI Layer: This Layer defines the User Interface for the experimenters. It should abstract the experiments enough to make them more user friendly as possible. The operation…
Figure 8
Figure 8. Figure 8: SLICES interconnection with European e-Infrastructures and digital infrastructures [PITH_FULL_IMAGE:figures/full_fig_p015_8.png]
Figure 9
Figure 9. Figure 9: OpenAIRE Explore [PITH_FULL_IMAGE:figures/full_fig_p016_9.png]
Figure 10
Figure 10. Figure 10: EGI Notebook current trends in resource management (resource programma￾bility, network virtualization, resource disaggregation) have resulted in the wide adoption of several Management and Orchestration (MANO) frameworks for deploying experiments and applications over…
Figure 11
Figure 11. Figure 11: Jupyter notebook [3] P. Antoniadis et al., “Federation of virtualized infrastructures: Sharing the value of diversity,” in Proceedings of the 6th International COnference, ser. Co-NEXT ’10. New York, NY, USA: Association for Computing Machinery, 2010. [Online]. Availa…

Discussion (0). Continue with ORCID to comment.

Reference graph

Works this paper leans on

89 extracted references · 78 canonical work pages

  1. [1]

    OneLab: An open federated facility for experimen- tally driven future internet research,

    P. Antoniadis et al., “OneLab: An open federated facility for experimen- tally driven future internet research,” in Proceedings of Conext 2010 . Springer, 2010, pp. 1–12

  2. [2]

    Federation of internet experimentation facilities: architecture and implementation,

    T. Wauters et al. , “Federation of internet experimentation facilities: architecture and implementation,” in European Conference on Networks and Communications (EuCNC 2014) , 2014. Fig. 11: Jupyter notebook

  3. [3]

    Federation of virtualized infrastructures: Sharing the value of diversity,

    P. Antoniadis et al. , “Federation of virtualized infrastructures: Sharing the value of diversity,” in Proceedings of the 6th International COnference, ser. Co-NEXT ’10. New York, NY , USA: Association for Computing Machinery, 2010. [Online]. Available: https://doi.org/10. 1145/1921168.1921184

  4. [4]

    Overview of the ORBIT radio grid testbed for evaluation of next-generation wireless network protocols,

    D. Raychaudhuri et al. , “Overview of the ORBIT radio grid testbed for evaluation of next-generation wireless network protocols,” in IEEE Wireless Communications and Networking Conference, 2005 , vol. 3. IEEE, 2005, pp. 1664–1669

  5. [5]

    GENI-global environment for network innovations

    C. Elliott, “GENI-global environment for network innovations.” in LCN, 2008, p. 8

  6. [6]

    The European FIRE Future Internet Research and Experi- mentation Initiative,

    M. Lemke, “The European FIRE Future Internet Research and Experi- mentation Initiative,” in 2009 5th International Conference on Testbeds and Research Infrastructures for the Development of Networks Commu- nities and Workshops, 2009, pp. 2–3

  7. [7]

    Tools to foster a global federation of testbeds,

    J. Auge et al., “Tools to foster a global federation of testbeds,”Computer Networks, vol. 63, pp. 205–220, 2014

  8. [8]

    Platforms for Advanced Wireless Research: Helping Define a New Edge Computing Paradigm,

    A. Gosain, “Platforms for Advanced Wireless Research: Helping Define a New Edge Computing Paradigm,” in Proceedings of the 2018 on Technologies for the Wireless Edge Workshop , 2018, pp. 33–33

Show all 89 references
  1. [9]

    5G EVE a European platform for 5G Application deployment,

    F. Moggio et al. , “5G EVE a European platform for 5G Application deployment,” in Proceedings of the 14th International Workshop on Wireless Network Testbeds, Experimental Evaluation & Characteriza- tion, 2020, pp. 124–125

  2. [10]

    5GENESIS: The Genesis of a flexible 5G Fa- cility,

    H. Koumaras et al. , “5GENESIS: The Genesis of a flexible 5G Fa- cility,” in 2018 IEEE 23rd International Workshop on Computer Aided Modeling and Design of Communication Links and Networks (CAMAD). IEEE, 2018, pp. 1–6

  3. [11]

    The potential of 5G experimentation-as-a-service paradigm for operators and vertical industries: The case of 5G-VINNI facility,

    C. Kalogiros et al. , “The potential of 5G experimentation-as-a-service paradigm for operators and vertical industries: The case of 5G-VINNI facility,” in 2019 IEEE 2nd 5G World Forum (5GWF) . IEEE, 2019, pp. 347–352

  4. [12]

    Linux Foundation, ONAP – Open Network Automation Platform,

    “Linux Foundation, ONAP – Open Network Automation Platform,” [Online], http://onap.org/

  5. [13]

    From Cloud RAN to Open RAN,

    L. Gavrilovska, V . Rakovic, and D. Denkovski, “From Cloud RAN to Open RAN,” Wireless Personal Communications, pp. 1–17, 2020

  6. [14]

    OpenAirInterface: A flexible platform for 5G research,

    N. Nikaein et al. , “OpenAirInterface: A flexible platform for 5G research,” ACM SIGCOMM Computer Communication Review , vol. 44, no. 5, pp. 33–38, 2014

  7. [15]

    European Strategy Forum on Research Infrastructures (ESFRI),

    “European Strategy Forum on Research Infrastructures (ESFRI),” [On- line], https://www.esfri.eu/

  8. [16]

    Integrated NFV/SDN architectures: A systematic literature review,

    M. S. Bonfim, K. L. Dias, and S. F. Fernandes, “Integrated NFV/SDN architectures: A systematic literature review,” ACM Computing Surveys (CSUR), vol. 51, no. 6, pp. 1–39, 2019

  9. [17]

    Network slicing and softwarization: A survey on principles, enabling technologies, and solutions,

    I. Afolabi et al. , “Network slicing and softwarization: A survey on principles, enabling technologies, and solutions,” IEEE Communications Surveys Tutorials, vol. 20, no. 3, pp. 2429–2453, 2018

  10. [18]

    Network function virtualization in dynamic networks: A stochastic perspective,

    X. Cheng et al., “Network function virtualization in dynamic networks: A stochastic perspective,” IEEE Journal on Selected Areas in Commu- nications, vol. 36, no. 10, pp. 2218–2232, 2018

  11. [19]

    Ai-native network slicing for 6g networks,

    W. Wu et al., “Ai-native network slicing for 6g networks,”IEEE Wireless Communications, vol. 29, no. 1, pp. 96–103, 2022

  12. [20]

    Data offloading techniques in cellular networks: A survey,

    F. Rebecchi et al., “Data offloading techniques in cellular networks: A survey,” IEEE Communications Surveys Tutorials , vol. 17, no. 2, pp. 580–603, 2015

  13. [21]

    V-edge: Virtual edge computing as an enabler for novel microservices and cooperative computing,

    F. Dressler et al. , “V-edge: Virtual edge computing as an enabler for novel microservices and cooperative computing,” IEEE Network, 2022

  14. [22]

    Application-driven end-to-end slicing: When wireless network virtualization orchestrates with nfv-based mobile edge comput- ing,

    K. Han et al. , “Application-driven end-to-end slicing: When wireless network virtualization orchestrates with nfv-based mobile edge comput- ing,” IEEE Access, vol. 6, pp. 26 567–26 577, 2018

  15. [23]

    Toward zero-touch management and orchestration of massive deployment of network slices in 6g,

    H. Chergui et al., “Toward zero-touch management and orchestration of massive deployment of network slices in 6g,” IEEE Wireless Communi- cations, vol. 29, no. 1, pp. 86–93, 2022

  16. [24]

    Open, programmable, and virtualized 5g networks: State-of-the-art and the road ahead,

    L. Bonati et al. , “Open, programmable, and virtualized 5g networks: State-of-the-art and the road ahead,” Computer Networks , vol. 182, p. 107516, 2020

  17. [25]

    Understanding O-RAN: Architecture, Interfaces, Algorithms, Security, and Research Challenges,

    M. Polese et al. , “Understanding O-RAN: Architecture, Interfaces, Algorithms, Security, and Research Challenges,” arXiv preprint arXiv:2202.01032, 2022

  18. [26]

    A survey of the functional splits proposed for 5G mobile crosshaul networks,

    L. M. Larsen, A. Checko, and H. L. Christiansen, “A survey of the functional splits proposed for 5G mobile crosshaul networks,” IEEE Communications Surveys & Tutorials, vol. 21, no. 1, pp. 146–172, 2018

  19. [27]

    Open ran—radio ac- cess network evolution, benefits and market trends,

    D. Wypi ´or, M. Klinkowski, and I. Michalski, “Open ran—radio ac- cess network evolution, benefits and market trends,” Applied Sciences , vol. 12, no. 1, p. 408, 2022

  20. [28]

    3GPP SA2 architecture and functions for 5G mobile communication system,

    J. Kim, D. Kim, and S. Choi, “3GPP SA2 architecture and functions for 5G mobile communication system,” ICT Express, vol. 3, no. 1, pp. 1–8, 2017

  21. [29]

    5G evolution: A view on 5G cellular technology beyond 3GPP release 15,

    A. Ghosh et al. , “5G evolution: A view on 5G cellular technology beyond 3GPP release 15,” IEEE access , vol. 7, pp. 127 639–127 651, 2019

  22. [30]

    Rommer et al., 5G Core Networks: Powering Digitalization

    S. Rommer et al., 5G Core Networks: Powering Digitalization . Aca- demic Press, 2019

  23. [31]

    3GPP TS 38.470 V17.0.0 (2022-04), 3rd Generation Partnership Project; Technical Specification Group Radio Access Network; NG- RAN; F1 general aspects and principles (Release 17),

    3GPP, “3GPP TS 38.470 V17.0.0 (2022-04), 3rd Generation Partnership Project; Technical Specification Group Radio Access Network; NG- RAN; F1 general aspects and principles (Release 17),” 2022

  24. [32]

    srsRAN: a 4G/5G software radio suite,

    “srsRAN: a 4G/5G software radio suite,” [Online], https://github.com/ srsran/srsRAN

  25. [33]

    3GPP, “3GPP TS 28.541 V17.6.0 (2022-03), 3rd Generation Partnership Project; Technical Specification Group Services and System Aspects; Management and orchestration; 5G Network Resource Model (NRM); Stage 2 and stage 3 (Release 17),” 2022

  26. [34]

    Intelligence and learning in O-RAN for data-driven NextG cellular networks,

    L. Bonati et al. , “Intelligence and learning in O-RAN for data-driven NextG cellular networks,” IEEE Communications Magazine , vol. 59, no. 10, pp. 21–27, 2021

  27. [35]

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

    R. Schmidt, M. Irazabal, and N. Nikaein, “FlexRIC: an SDK for next-generation SD-RANs,” in Proceedings of the 17th International Conference on emerging Networking EXperiments and Technologies , 2021, pp. 411–425

  28. [36]

    FlexRAN: A flexible and programmable platform for software-defined radio access networks,

    X. Foukas et al. , “FlexRAN: A flexible and programmable platform for software-defined radio access networks,” in Proceedings of the 12th International on Conference on emerging Networking EXperiments and Technologies, 2016, pp. 427–441

  29. [37]

    ONF Software Defined RAN (SD-RAN),

    ONF, “ONF Software Defined RAN (SD-RAN),” 2022, [Online], https: //opennetworking.org/sd-ran/

  30. [38]

    ONF AETHER - 5G Connected Edge platform,

    ——, “ONF AETHER - 5G Connected Edge platform,” 2022, [Online], https://opennetworking.org/aether/

  31. [39]

    ONOS: towards an open, distributed SDN OS,

    P. Berde et al. , “ONOS: towards an open, distributed SDN OS,” in Proceedings of the third workshop on Hot topics in software defined networking, 2014, pp. 1–6

  32. [40]

    Central office re-architected as a data center,

    L. Peterson et al., “Central office re-architected as a data center,” IEEE Communications Magazine, vol. 54, no. 10, pp. 96–101, 2016

  33. [41]

    ONF OMEC - Open Mobile Evolved Core,

    ONF, “ONF OMEC - Open Mobile Evolved Core,” 2022, [Online], https: //opennetworking.org/omec/

  34. [42]

    3rd Generation Partnership Project; Technical Specification Group Services and System Aspects; System architecture for the 5G System (5GS); Stage 2 (Release 17),

    3GPP, “3rd Generation Partnership Project; Technical Specification Group Services and System Aspects; System architecture for the 5G System (5GS); Stage 2 (Release 17),” 2022

  35. [43]

    5G Cloud-Native: Network Management & Automation,

    O. Arouk and N. Nikaein, “5G Cloud-Native: Network Management & Automation,” in NOMS 2020-2020 IEEE/IFIP Network Operations and Management Symposium. IEEE, 2020, pp. 1–2

  36. [44]

    An overview of OpenStack architecture,

    T. Rosado and J. Bernardino, “An overview of OpenStack architecture,” in Proceedings of the 18th International Database Engineering & Applications Symposium, 2014, pp. 366–367

  37. [45]

    Management and orchestration challenges in network functions virtualization,

    R. Mijumbi et al., “Management and orchestration challenges in network functions virtualization,” IEEE Communications Magazine , vol. 54, no. 1, pp. 98–105, 2016

  38. [46]

    Containers and Cloud: From LXC to docker to Kuber- netes,

    D. Bernstein, “Containers and Cloud: From LXC to docker to Kuber- netes,” IEEE Cloud Computing , vol. 1, no. 3, pp. 81–84, 2014

  39. [47]

    Open Source project of 5GC and EPC (Release 16),

    Open5GS, “Open Source project of 5GC and EPC (Release 16),” [Online], https://open5gs.org/

  40. [48]

    OpenAirInterface Core Network,

    OAI, “OpenAirInterface Core Network,” [Online], https://gitlab. eurecom.fr/oai/cn5g

  41. [49]

    NextEPC: Open Source EPC,

    NextEPC, “NextEPC: Open Source EPC,” [Online], https://nextepc.org/

  42. [50]

    Open Source implementation of 5G Core Network (3GPP Release 15 and beyond),

    Free5GC, “Open Source implementation of 5G Core Network (3GPP Release 15 and beyond),” [Online], https://www.free5gc.org/

  43. [51]

    Magma: Communications Service Providers leverage Magma’s open network core solution to connect people using LTE, 5G, Wi-Fi, and beyond

    Meta, “Magma: Communications Service Providers leverage Magma’s open network core solution to connect people using LTE, 5G, Wi-Fi, and beyond.” [Online], https://www.facebook.com/connectivity/ solutions/magma

  44. [52]

    ETSI NFV management and orchestration-An overview,

    M. Ersue, “ETSI NFV management and orchestration-An overview,” in Proc. of 88th IETF meeting , 2013

  45. [53]

    Open Source MANO,

    ETSI, “Open Source MANO,” OSM home page - https://osm.etsi.org/ , 2016

  46. [54]

    Multi-tenant 5G Network Slicing Architecture with Dynamic Deployment of Virtualized Tenant Management and Orches- tration (MANO) Instances,

    A. Mayoral et al., “Multi-tenant 5G Network Slicing Architecture with Dynamic Deployment of Virtualized Tenant Management and Orches- tration (MANO) Instances,” in ECOC 2016; 42nd European Conference on Optical Communication , Sep. 2016, pp. 1–3

  47. [55]

    Open baton: a framework for virtual network function management and orchestration for emerging software- based 5G networks,

    G. A. Carella and T. Magedanz, “Open baton: a framework for virtual network function management and orchestration for emerging software- based 5G networks,” Newsletter, vol. 2016, p. 190, 2015

  48. [56]

    Docker [software engineering],

    C. Anderson, “Docker [software engineering],” Ieee Software, vol. 32, no. 3, pp. 102–c3, 2015

  49. [57]

    Picozzi, M

    S. Picozzi, M. Hepburn, and N. O’Connor, DevOps with Openshift: Cloud deployments made easy . ” O’Reilly Media, Inc.”, 2017

  50. [58]

    Apache mesos,

    M. Frampton, “Apache mesos,” in Complete Guide to Open Source Big Data Stack. Springer, 2018, pp. 97–137

  51. [59]

    A p4-based 5g user plane function,

    R. MacDavid et al. , “A p4-based 5g user plane function,” in SOSR ’21: Proceedings of the ACM SIGCOMM Symposium on SDN Research (SOSR), 2021, pp. 162—-168

  52. [60]

    Performance evaluation of offloading ldpc decoding to an fpga in 5g baseband processing,

    F. Kaltenberger, H. Wang, and S. Velumani, “Performance evaluation of offloading ldpc decoding to an fpga in 5g baseband processing,” in 25th International ITG Workshop on Smart Antennas , 2021, pp. 1–4

  53. [61]

    Available: https://www.xilinx.com/about/events/2022/ mwc-2022.html

    [Online]. Available: https://www.xilinx.com/about/events/2022/ mwc-2022.html

  54. [62]

    Available: https://developer.nvidia.com/aerial-sdk

    [Online]. Available: https://developer.nvidia.com/aerial-sdk

  55. [63]

    OPEN NFV Edge project ,

    “OPEN NFV Edge project ,” [Online], https://wiki.opnfv.org/display/EC/ Edge+cloud

  56. [64]

    ONAP Project: Edge Automation through ONAP,

    “ONAP Project: Edge Automation through ONAP,” [Online], https:// wiki.onap.org/display/DW/Edge+Automation+through+ONAP

  57. [65]

    OpenStack Project: Edge Computing,

    “OpenStack Project: Edge Computing,” [Online], https: //www.openstack.org/edge-computing/

  58. [66]

    LF EDGE Project: Building an Open Source Framework for the Edge,

    “LF EDGE Project: Building an Open Source Framework for the Edge,” [Online], https://www.lfedge.org/

  59. [67]

    5G City Project,

    “5G City Project,” [Online], https://www.5gcity.eu/

  60. [68]

    Openness Project,

    “Openness Project,” [Online], https://www.openness.org/

  61. [69]

    SYMEC Project,

    “SYMEC Project,” [Online], https://www.symec.com.pl/

  62. [70]

    Linux Foundation Projects: OPNFV/Anuket,

    “Linux Foundation Projects: OPNFV/Anuket,” online], [https://www. opnfv.org/

  63. [71]

    Cloud Native Computing Foundation (CNCF),

    “Cloud Native Computing Foundation (CNCF),” online], [https://www. cncf.io/

  64. [72]

    Open Compute Project Foundation (OCP),

    “Open Compute Project Foundation (OCP),” online], [https://www. opencompute.org/

  65. [73]

    Multi-domain orchestration of 5G vertical services and network slices,

    G. Bernini et al. , “Multi-domain orchestration of 5G vertical services and network slices,” in 2020 IEEE International Conference on Com- munications Workshops (ICC Workshops). IEEE, 2020, pp. 1–6

  66. [74]

    OMF: a control and management framework for networking testbeds,

    T. Rakotoarivelo et al., “OMF: a control and management framework for networking testbeds,” ACM SIGOPS Operating Systems Review, vol. 43, no. 4, pp. 54–59, 2010

  67. [75]

    013: Network functions virtualisation (nfv); management and orchestration; os-ma-nfvo reference point–interface and information model specification

    G. ETSI, “013: Network functions virtualisation (nfv); management and orchestration; os-ma-nfvo reference point–interface and information model specification.”

  68. [76]

    Next generation portal for federated testbeds MySlice v2: from prototype to production,

    L. Baron et al. , “Next generation portal for federated testbeds MySlice v2: from prototype to production,” Fed4FIRE Engineering Conference - FEC2, Oct. 2017, poster. [Online]. Available: https: //hal.archives-ouvertes.fr/hal-01804013

  69. [77]

    EU’s open science policy,

    “EU’s open science policy,” [Online], https://ec.europa.eu/info/ research-and-innovation/strategy/strategy-2020-2024/our-digital-future/ open-science en

  70. [78]

    EU support for open access,

    “EU support for open access,” [Online], https://ec.europa.eu/info/ research-and-innovation/strategy/strategy-2020-2024/our-digital-future/ open-science/open-access

  71. [79]

    Open Research Data Pilot of the European Commission ,

    “Open Research Data Pilot of the European Commission ,” 2017, [Online], https://www.openaire.eu/what-is-the-open-research-data-pilot

  72. [80]

    Cloudy, increasingly FAIR; revisiting the FAIR Data guiding principles for the European Open Science Cloud,

    B. Mons et al. , “Cloudy, increasingly FAIR; revisiting the FAIR Data guiding principles for the European Open Science Cloud,” Information Services & Use , vol. 37, no. 1, pp. 49–56, 2017

  73. [81]

    EOSC FAIRsFAIR project,

    “EOSC FAIRsFAIR project,” [Online], https://www.fairsfair.eu/

  74. [82]

    EOSC GO FAIR initiative,

    “EOSC GO FAIR initiative,” [Online], https://www.go-fair.org/

  75. [83]

    FAIR Data Maturity Model: specifi- cation and guidelines,

    R. F. D. M. M. W. Group et al., “FAIR Data Maturity Model: specifi- cation and guidelines,” Research Data Alliance. DOI , vol. 10, 2020

  76. [84]

    The FAIR Guiding Principles for scientific data management and stewardship,

    M. D. Wilkinson et al. , “The FAIR Guiding Principles for scientific data management and stewardship,” Scientific data , vol. 3, no. 1, pp. 1–9, 2016

  77. [85]

    Realising the European open science cloud,

    P. Ayris et al., “Realising the European open science cloud,” 2016

  78. [86]

    Corcho et al

    O. Corcho et al. , EOSC interoperability framework: Report from the EOSC Executive Board Working Groups FAIR and Architecture . Eu- ropean Commission, 2021

  79. [87]

    Interoperability governance: a definition and insights from case studies in Europe,

    M. A. Wimmer, R. Boneva, and D. Di Giacomo, “Interoperability governance: a definition and insights from case studies in Europe,” in Proceedings of the 19th Annual International Conference on Digital Government Research: Governance in the Data Age , 2018, pp. 1–11

  80. [88]

    SLICES Design Study D4.2: SLICES infrastructure and services integration with EOSC and Open Science (initial pro- posal),

    K. Joshi et al. , “SLICES Design Study D4.2: SLICES infrastructure and services integration with EOSC and Open Science (initial pro- posal),” 2021, [Online], http://slices-ds.eu/wp-content/uploads/2021/12/ SLICES-DS D4.2.pdf

  81. [89]

    ACM Artifact Review and Badging,

    “ACM Artifact Review and Badging,” [Online], https://www.acm.org/ publications/policies/artifact-review-badging

Pith tools

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