Pith. sign in

REVIEW 3 major objections 4 minor 25 references

A Flexible Infrastructure-Sharing 5G Network Architecture Based on Network Slicing and Roaming

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

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

Pith's one-line read A shared 5G core with one slice per client serves operators and non-operators, and four-slice sharing tests outperform a single-operator baseline by 61.8% in throughput and 96.8% in packet loss.

desk verdict A useful neutral-host architecture combining slicing and roaming, honestly implemented, but the headline throughput and PLR gains are artifacts of the chosen baseline and should not be taken at face value. read the letter →

arxiv 2411.15505 v1 pith:SGZPXOSM submitted 2024-11-23 cs.NI

Joao P. Ferreira , Vinicius C. Ferreira , Sergio L. Nogueira , Joao M. Faria , Jose A. Afonso This is my paper · ORCID
classification cs.NI
keywords 5Gnetworksharingneutralhostslicingroamingtrafficisolationthroughputpacketloss
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 tries to show that a neutral host—one 5G radio and core network owned by an infrastructure provider—can serve any number of clients, mobile operators or not, by giving each client its own network slice and using roaming only for operator subscribers' authentication. The authors implement this design with open-source RAN and core simulators and validate two things: both client types can authenticate, and each slice's traffic stays isolated from the others. They then report a performance result: four clients sharing the infrastructure, with eight users total, achieve 61.8% higher aggregate throughput and 96.8% lower packet loss than a single client using all the same resources. If the architecture works as described, a shared neutral host could lower 5G deployment costs while giving each tenant control over its own slice.

What carries the argument

The load-bearing object is the per-client network slice in the shared 5G core, realized as a dedicated pair of session management and user plane functions per client under a shared access and mobility management function. Network slicing gives each tenant its own control and user plane for sessions and QoS, which is what provides traffic isolation and policy separation. The paper couples slicing with local-breakout roaming for operator clients: their home core authenticates the user, while the neutral host routes the user's data locally. The specific mechanism behind the reported performance gain is process-level parallelism—the core implementation runs each slice as a separate process, so four slices use multiple CPU cores, whereas the one-slice baseline is limited to a single process on a single core.

What would settle it

Run the same eight-user test with one operator client whose users are distributed across four SMF-UPF pairs, matching the process count of the four-slice neutral-host setup; if total throughput stays near 286 Mbps rather than dropping to 177 Mbps, then the claimed advantage comes from the baseline's single-process limit, not from sharing.

Watch

Extended reading notes

Core claim

The central claim is that a neutral-host 5G architecture built on network slicing plus local-breakout roaming can deliver isolated, policy-controlled 5G service to heterogeneous clients without a separate physical network per client. In the implemented design, a shared RAN and a shared access and mobility management function handle all users, while each client gets a dedicated slice containing its own session management function and user plane function; operator clients additionally authenticate their users through their home core using local-breakout roaming, whereas non-operator clients are authenticated directly in the neutral-host core. The paper's measured outcome is that this arrangement not only authenticates both user types and keeps their traffic on separate interfaces, but also improves resource efficiency: with four slices and eight users, total throughput rises 61.8% and mean packet loss falls 96.8% compared with the one-slice baseline, because each slice runs as a separate process and spreads the CPU load across cores.

Load-bearing premise

The performance comparison assumes that the right baseline for a traditional operator is a single slice with all its users on one core process; if an operator could also split users across several slices or processes, the reported 61.8% throughput and 96.8% packet-loss advantages would no longer be a property of the neutral-host architecture.

Editorial extensions

If this is right

  • A neutral host can onboard MNO and non-MNO clients through the same infrastructure, authenticating operator users via local-breakout roaming and non-operator users directly.
  • Per-client slices give each tenant a dedicated SMF-UPF pair, so user traffic and QoS policies of one client do not cross into another client's slice.
  • Sharing the infrastructure among four clients and eight users produced 61.8% higher total throughput than one client using all resources.
  • The same test showed a 96.8% lower packet loss ratio in the four-slice configuration at equal offered load.
  • Because each slice runs as a separate core process, adding slices distributes the CPU load across cores, which is the observed source of the performance gain.

Reading between the lines

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

  • This suggests the performance advantage is tied to the test core's process-per-slice implementation; a production core that already parallelizes a single operator's sessions would not necessarily show the same gap against the neutral-host design.
  • The same per-slice SMF-UPF separation could be pushed into radio-resource isolation, where each slice gets guaranteed scheduling shares; the paper's isolation test only checks core-side interfaces, not spectrum contention.
  • A testable extension would scale the number of slices beyond four and measure whether throughput gains saturate with the number of CPU cores, which would help operators decide slice granularity.
  • The architecture's use of the operator's own PLMN ID for neutral-host coverage implies a simpler device handover between home and host networks, which could be measured as reduced registration delay or dropped sessions.
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 manuscript proposes a neutral-host 5G architecture that combines network slicing with LBO roaming to serve both MNO and non-MNO tenants from a shared core. It presents a conceptual design with per-client slices (SMF/PCF/UPF) and operator authentication via roaming, then describes an implementation based on Open5GS and UERANSIM running in VMs. Functional tests cover UE authentication time and per-slice traffic isolation. Performance tests compare a four-client/four-slice configuration with a one-client/one-slice baseline for TCP throughput and UDP packet loss ratio; the paper reports 61.8% higher throughput and 96.8% lower PLR and attributes these gains to per-slice processes distributing CPU load across cores.

Significance. If the performance claims were supported, the paper would provide useful experimental evidence for neutral-host slicing; the functional validation of two authentication paths and per-slice interface isolation is a concrete contribution. The authors also give an explicit, honest account of Open5GS and UERANSIM limitations, which helps readers judge the scope of the evaluation. However, the headline performance comparison is not architecture-controlled, and the manuscript supplies no code or measurement artifacts, so the quantitative conclusion needs substantial rework before it can be accepted as stated.

major comments (3)
  1. [§4.2, Tables 2–3] The throughput comparison does not control for CPU-parallelism effects. The authors observe that the one-slice baseline creates a single Open5GS process bounded by ~99% of one core, whereas the four-slice configuration creates one process per slice and distributes work over multiple cores. A traditional single-operator deployment could equally run multiple slices or multiple SMF/UPF instances and use more cores. Hence the reported 61.8%/61.7% gains in Tables 2 and 3 do not establish an advantage of the proposed neutral-host architecture over a conventional operator core; they largely measure process-level parallelism. Please repeat the experiment with a baseline that uses the same number of processes/cores (e.g., one client whose users are split over four slices, or one client served by multiple SMF/UPF instances), or normalize throughput by allocated CPU.
  2. [§4.3, Table 4] The PLR comparison is load-selection dependent. Both configurations are offered 23.1 Mbps per user, yet Table 2 indicates that the one-slice baseline's maximum TCP throughput is around 22.1 Mbps per user; at an offered load above saturation, a PLR near 1.1% is expected rather than evidence of an architectural deficiency. The four-slice configuration's 0.036% PLR likely reflects that the per-user load sits below the multi-core aggregate capacity. Reporting a single load point cannot support the abstract's 96.8% lower PLR claim; the paper should sweep offered load from below to above the saturation point of each configuration, or at least choose a load below the baseline saturation.
  3. [§3.2.2, Figures 4–6] The implemented system validates a simplified version of the conceptual architecture, as the text itself acknowledges: UERANSIM cannot emulate a shared RAN with multiple PLMNs, so each client runs a separate UERANSIM VM; Open5GS slicing is limited to SMF/UPF, with PCF not part of the implemented slices; and slice creation is manual and requires a service restart. Consequently, the qualitative isolation test demonstrates separation between Open5GS tunnel interfaces but not isolation through a shared RAN scheduler or dynamic slice management. The paper should state clearly that the 'flexible' and 'dynamic' properties are design-level claims and that the evaluation exercises only static, manually configured slices.
minor comments (4)
  1. [Abstract] The phrase 'capable of providing services to any type of client' overstates the scope: Section 3.2.2 excludes QoS, billing, resource distribution, and dynamic reconfiguration, so the claim should be qualified to the implemented authentication and isolation scenarios.
  2. [Tables 2–4] The column layout does not label individual users; for example, Table 2 places eight throughput values under four VM headers. Add per-user columns or a legend, and state explicitly that the values are averages of 10 runs.
  3. [§4.2] The host machine's CPU/RAM and hypervisor details are not reported, which makes it hard to assess the core-count effect described in the CPU-usage discussion; please provide the physical host specification.
  4. [§3.2.1] The claims that 'Open5GS has recently included support for roaming' and that free5GC failed to handle multiple PLMN IDs would benefit from specific software versions and, ideally, linked configuration snippets or logs to support reproducibility.

Circularity Check

0 steps flagged · score 0.0 of 10

No circular derivation: the architecture is tested against an empirical baseline, and no predicted quantity is defined in terms of fitted parameters or self-citations.

full rationale

The paper is an experimental systems paper, not a derivation. The claimed 61.8% throughput and 96.8% PLR advantages are measurement comparisons between a four-slice configuration and a one-slice baseline (Tables 2 and 4), and the paper openly attributes the difference to Open5GS creating one process per slice and spreading CPU load across cores (Section 4.2). No equation is fitted, no quantity is defined in terms of another predicted quantity, and no load-bearing uniqueness theorem or ansatz is imported from the authors' prior work; the reference list contains no self-citations by the authors. The weakest point is the baseline: a traditional operator could in principle also deploy multiple slices or SMF/UPF instances, so the performance gain is not architecture-independent. That is a baseline and soundness concern, not circularity: the comparison is not forced by definition, and the functional authentication and isolation tests are independent evidence. Accordingly, the circularity score is 0.

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

The ledger shows the empirical validation rests on software-behavior assumptions rather than on new theoretical axioms. The most fragile item is the single-slice baseline assumption, which invalidates the performance claim as stated.

free parameters (3)
  • UDP test load for PLR comparison = 23.1 Mbps per user
    Chosen as the maximum feasible load that kept all eight users connected (Section 4.3). The 96.8% lower PLR figure is measured at this load and may not hold at other loads.
  • Number of clients/slices in performance test = 4
    Limited by test hardware (Section 4.2). The paper only compares one slice with four slices and does not test scaling beyond four.
  • iperf TCP window size = 416 kB
    Fixed test parameter for throughput measurements (Section 4.2); throughput numbers depend on it.
assumptions (4)
  • domain assumption Per-client UERANSIM VM instances with distinct PLMN IDs emulate a multi-PLMN shared RAN.
    UERANSIM cannot run multiple PLMNs in one instance, so the architecture uses one VM per client (Section 3.2.2); the multi-client validation depends on this equivalence.
  • domain assumption Open5GS per-slice tunnel interfaces and processes represent production 3GPP network slicing isolation.
    Traffic isolation is verified by tcpdump per interface (Section 4.1), but the behavior is that of the simulator, not a certified production core.
  • ad hoc to paper The single-slice baseline with one SMF/UPF process is an appropriate reference for a traditional single-operator deployment.
    This premise underlies the performance comparison in Section 4.2 and is not justified; a traditional operator could also parallelize with multiple slices or processes.
  • domain assumption Open5GS's roaming implementation follows 3GPP LBO roaming semantics.
    Section 3.2.1 selects Open5GS because it added roaming support; the operator-client authentication test depends on this implementation being representative.

how reviews work

0 comments
Cite this review

Pith. "Pith review of A Flexible Infrastructure-Sharing 5G Network Architecture Based on Network Slicing and Roaming." pith.science (2026). https://pith.science/paper/SGZPXOSM

@misc{pith2026241115505,
  author       = {Pith},
  title        = {Pith review of: A Flexible Infrastructure-Sharing 5G Network Architecture Based on Network Slicing and Roaming},
  year         = {2026},
  howpublished = {\url{https://pith.science/paper/SGZPXOSM}},
  note         = {Machine review of arXiv:2411.15505}
}
read the original abstract

The sharing of mobile network infrastructure has become a key topic with the introduction of 5G due to the high costs of deploying such infrastructures, with neutral host models coupled with features such as network function virtualization (NFV) and network slicing emerging as viable solutions for the challenges in this area. With this in mind, this work presents the design, implementation, and test of a flexible infrastructure-sharing 5G network architecture capable of providing services to any type of client, whether an operator or not. The proposed architecture leverages 5G's network slicing for traffic isolation and compliance with the policies of different clients, with roaming employed for the authentication of users of operator clients. The proposed architecture was implemented and tested in a simulation environment using the UERANSIM and Open5GS open-source tools. Qualitative tests successfully validated the authentication and the traffic isolation features provided by the slices for the two types of clients. Results also demonstrate that the proposed architecture has a positive impact on the performance of the neutral host network infrastructure, achieving 61.8% higher throughput and 96.8% lower packet loss ratio (PLR) in a scenario sharing the infrastructure among four clients and eight users when compared to a single client with all the network resources.

Figures

Figures reproduced from arXiv: 2411.15505 by the authors.

Figure 1
Figure 1. illustrates different models for sharing 5G network infrastructures, catego￾rizing them into two groups: passive sharing and active sharing, where A and B represent two different MNOs [11]. Passive sharing involves the sharing of non-electronic infra￾structure components, such as sites and towers, power supplies, and the physical elements of transport in backhaul, e.g., optical fibers. Site sharing is a common and s… view at source ↗
Figure 2
Figure 2. Conceptual neutral host architecture of the proposed solution [PITH_FULL_IMAGE:figures/full_fig_p006_2.png] view at source ↗
Figure 3
Figure 3. Flowchart of a new client configuration in the neutral host [PITH_FULL_IMAGE:figures/full_fig_p008_3.png] view at source ↗
Figures from the paper (3 more)
Figure 4
Figure 4. Figure 4: Flowchart of the authentication procedure. 3.2. Architecture Implementation 3.2.1. Software Tools In this work, several open-source software tools were considered for implementation and testing of the proposed architecture. For the RAN simulation, notable options inclu…
Figure 5
Figure 5. Figure 5: Architecture of the implemented system [PITH_FULL_IMAGE:figures/full_fig_p011_5.png]
Figure 6
Figure 6. Figure 6: presents a more detailed illustration of the implemented architecture, em￾phasizing the used VMs and their interactions. This scenario, which was used on the tests presented in Section 4, includes up to four clients: one operator client and up to three non￾operator cli…

Discussion (0). Continue with ORCID to comment.

Reference graph

Works this paper leans on

25 extracted references · 20 canonical work pages

  1. [1]

    The 5G Revolution: Expectations Versus Reality

    Jabagi, N.; Park, A.; Kietzmann, J. The 5G Revolution: Expectations Versus Reality. IT Prof . 2020, 22, 8–15. https://doi.org/10.1109/MITP.2020.2972139

    arXiv 2020

  2. [2]

    View on 5G Architecture ; Version 4.0; 5G PPP Architecture Working Group: Pisa, Italy, 2021

    5G PPP Architecture Working Group. View on 5G Architecture ; Version 4.0; 5G PPP Architecture Working Group: Pisa, Italy, 2021

    work page 2021

  3. [3]

    Pricing Models for 5G Multi-Tenancy Using Game Theory Framework

    Kumar, S.K.A.; Crawford, D.; Stewart, R. Pricing Models for 5G Multi-Tenancy Using Game Theory Framework. IEEE Commun. Mag. 2023, 1–7. https://doi.org/10.1109/MCOM.001.2200742

    work page doi:10.1109/mcom.001.2200742 2023

  4. [4]

    Edge Computing Enhancements in an NFV-Based Ecosystem for 5G Neutral Hosts

    Baldoni, G.; Cruschelli, P.; Paolino, M.; Meixner, C.C.; Albanese, A.; Papageorgiou, A.; Khalili, H.; Siddiqui, S.; Simeonidou, D. Edge Computing Enhancements in an NFV-Based Ecosystem for 5G Neutral Hosts. In Proceedings of the 2018 IEEE Conference on Network Function Virtualization and Software Defined Networks (NFV-SDN), Verona, Italy, 27–29 November 2...

    work page 2018

  5. [5]

    3GPP Technical Report 21.915; Version 15.0.0 Release 15; ETSI: Sophia Antipolis, France 2019

    3rd Generation Partnership Project. 3GPP Technical Report 21.915; Version 15.0.0 Release 15; ETSI: Sophia Antipolis, France 2019

    work page 2019

  6. [6]

    AI-Assisted Slicing-Based Resource Management for Two-Tier Radio Access Networks

    Zhou, C.; Gao, J.; Li, M.; Shen, X.; Zhuang, W.; Li, X.; Shi, W. AI-Assisted Slicing-Based Resource Management for Two-Tier Radio Access Networks. IEEE Trans. Cogn. Commun. Netw. 2023, 9, 1691–1706. https://doi.org/10.1109/TCCN.2023.3307929

    arXiv 2023

  7. [7]

    Neutral Host Technology: The Future of Mobile Network Operators

    Bajracharya, R.; Shrestha, R.; Jung, H.; Shin, H. Neutral Host Technology: The Future of Mobile Network Operators. IEEE Access 2022, 10, 99221–99234. https://doi.org/10.1109/ACCESS.2022.3207823

    arXiv 2022

  8. [8]

    A Comprehensive Survey on the E2E 5G Network Slicing Model

    Chahbar, M.; Diaz, G.; Dandoush, A.; Cérin, C.; Ghoumid, K. A Comprehensive Survey on the E2E 5G Network Slicing Model. IEEE Trans. Netw. Serv. Manag. 2021, 18, 49–62. https://doi.org/10.1109/TNSM.2020.3044626

    arXiv 2021

Show all 25 references
  1. [9]

    Roaming in the 5G system: The 5GS roaming architecture

    Keller, R.; Castellanos, D.; Sander, A.; Robison, A.; Abtin, A. Roaming in the 5G system: The 5GS roaming architecture. Ericsson Technol. Rev. 2021, 2021, 2–11

    2021

  2. [10]

    Validating a 5G-Enabled Neutral Host Framework in City-Wide Deployments

    Fernández-Fernández, A.; Colman-Meixner, C.; Ochoa-Aday, L.; Betzler, A.; Khalili, H.; Siddiqui, M.S.; Carrozzo, G.; Figuerola, S.; Nejabati, R.; Simeonidou, D. Validating a 5G-Enabled Neutral Host Framework in City-Wide Deployments. Sensors 2021, 21,

    2021

  3. [11]

    Infrastructure Sharing

    GSMA. Infrastructure Sharing. Available online: https://www.gsma.com/futurenetworks/wiki/infrastructure-sharing-an-over- view/ (accessed on 23 February 2024)

    2024

  4. [12]

    Toward Resilient Network Slicing for Satellite–Terrestrial Edge Computing IoT

    Esmat, H.H.; Lorenzo, B.; Shi, W. Toward Resilient Network Slicing for Satellite–Terrestrial Edge Computing IoT. IEEE Internet Things J. 2023, 10, 14621–14645. https://doi.org/10.1109/JIOT.2023.3277466

    2023

  5. [13]

    Flexible Multi-Operator RAN Sharing: Experimentation and Validation Using Open Source 4G/5G Prototype

    Kassis, M.; Costanzo, S.; Yassin, M. Flexible Multi-Operator RAN Sharing: Experimentation and Validation Using Open Source 4G/5G Prototype. In Proceedings of the 2021 Joint European Conference on Networks and Communications & 6G Summit (EuCNC/6G Summit), Porto, Portugal, 8–11 ...

    2021

  6. [14]

    Making Neutral Host a Reality with OnGo; Mobile Experts White Paper; Mobile Experts, Inc.: Campbell, CA, USA, 2018

    Mun, K. Making Neutral Host a Reality with OnGo; Mobile Experts White Paper; Mobile Experts, Inc.: Campbell, CA, USA, 2018

    2018

  7. [15]

    System Architecture and Deployment Scenarios for SESAME: Small cEllS coodinAtion for Multi-Tenancy and Edge Services

    Giannoulakis, I.; Xylouris, G.; Kafetzakis, E.; Kourtis, A.; Fajardo, J.O.; Khodashenas, P.S.; Albanese, A.; Mouratidis, H.; Vass- ilakis, V. System Architecture and Deployment Scenarios for SESAME: Small cEllS coodinAtion for Multi-Tenancy and Edge Services. In Proceedings of...

    2016

  8. [16]

    Management of Mission Critical Public Safety Applications: The 5G ESSENCE Project

    Spada, M.R.; Pérez-Romero, J.; Sanchoyerto, A.; Solozabal, R.; Kourtis, M.A.; Riccobene, V. Management of Mission Critical Public Safety Applications: The 5G ESSENCE Project. In Proceedings of the 2019 European Conference on Networks and Com- munications (EuCNC), Valencia, Spa...

    2019

  9. [17]

    UERANSIM

    Güngör, A. UERANSIM. Available online: https://github.com/aligungr/UERANSIM (accessed on 16 October 2023)

    2023

  10. [18]

    OAI 5G RAN Project Group

    OpenAirInterface. OAI 5G RAN Project Group. Available online: https://openairinterface.org/oai-5g-ran-project/ (accessed on 16 October 2023)

    2023

  11. [19]

    my5G-RANTester

    my5G. my5G-RANTester. Available online: https://github.com/my5G/my5G-RANTester (accessed on 16 October 2023)

    2023

  12. [20]

    Available online: https://open5gs.org/ (accessed on 16 October 2023)

    Open5GS. Available online: https://open5gs.org/ (accessed on 16 October 2023)

    2023

  13. [21]

    Available online: https://free5gc.org/ (accessed on 16 October 2023)

    free5GC. Available online: https://free5gc.org/ (accessed on 16 October 2023)

    2023

  14. [22]

    5G Core Network

    OpenAirInterface. 5G Core Network. Available online: https://openairinterface.org/oai-5g-core-network-project/ (accessed on 16 October 2023)

    2023

  15. [23]

    Open Source 5G Core Network Implementations: A Qualitative and Quantitative Analysis

    Reddy, R.; Lipps, C.; Schotten, H.D.; Gundall, M.; Schotten, H.D. Open Source 5G Core Network Implementations: A Qualitative and Quantitative Analysis. In Proceedings of the 2023 IEEE International Black Sea Conference on Communications and Net- working (BlackSeaCom), Istanbul...

    2023

  16. [24]

    Available online: https://iperf.fr/ (accessed on 16 October 2023)

    iPerf—The Ultimate Speed Test Tool for TCP, UDP and SCTP. Available online: https://iperf.fr/ (accessed on 16 October 2023)

    2023

  17. [8103]

    https://doi.org/10.3390/s21238103

    doi

Pith tools

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