{"id":"211526e3-51d3-44f9-a047-298a79669570","arxiv_id":"2411.15505","paper_version":1,"verdict":"CONDITIONAL","confidence":"MODERATE","novelty_score":4.0,"correctness_risk":"medium","formal_verification":"none","parameter_count":3,"one_line_summary":"A 5G neutral host architecture using network slicing and roaming authenticates and isolates operator and non-operator clients, though the reported throughput and packet-loss gains are confounded by simulator process distribution.","lead":"This paper designs and tests a 5G neutral host network that lets several operators and non-operators share one infrastructure, using network slices for isolation and roaming for authentication. The functional tests pass, but the reported performance gains look like an artifact of simulator software running more processes, not of the architecture itself.","discovery_kind":"extension","skeptic_critique":{"model":"deepseek-v4-flash","headline":"Headline performance gains are not architecture-controlled: the single-client baseline uses one SMF/UPF process on one core, versus one process per slice in the four-client test, and the PLR load (23.1 Mbps) sits just above baseline saturation; the claimed advantage may be an artifact of process…","rationale":"The reader's verdict is CONDITIONAL and I agree. The functional part of the paper—authentication for operator/non-operator clients and interface-level traffic isolation—is described with enough implementation detail to be credible, and the acknowledged Open5GS/UERANSIM limitations are stated transparently. The decisive issue is the performance evaluation. The paper's own Section 4.2 observation that one slice yields a single process capped at 99% of one core while four slices yield four processes across cores is exactly the confounding variable: the comparison varies both the number of tenants and the number of processes/cores, so the 61.8% throughput gain cannot be attributed to the architecture. The PLR test then fixes offered load at 23.1 Mbps, just above the one-slice configuration's measured ~22.1 Mbps saturation point, so the 96.8% loss reduction is also not a robust metric. The proposed control experiment—four slices for one tenant, plus a load sweep—would separate multi-tenancy benefits from process-level parallelism and load selection. If it shows the gains persist only when multiple slices/processes are used, the authors should soften the abstract to claim 'additional slices/processes improve throughput' rather than 'the proposed neutral-host architecture improves performance.' I do not see grounds for rejection; the architecture and functional validation remain useful. The verdict stays CONDITIONAL pending the control experiment and revised claims.","tokens_in":11857,"tokens_out":5494,"duration_ms":49428,"concrete_test":"Run a control experiment using the same 8-user/four-VM topology but with all four slices assigned to a single logical client (same PLMN), so the number of SMF/UPF processes and CPU cores used matches the four-client test. If total throughput approaches the 286.7 Mbps and PLR the 0.036% values from Tables 2 and 4, the claimed advantage is due to process-per-slice parallelism, not multi-tenant isolation. In the same control, sweep UDP offered load from 5 to 35 Mbps for both the one-slice and four-slice configurations; if PLR is near-zero below 22 Mbps in both, the 96.8% PLR claim is an artifact of selecting 23.1 Mbps.","verdict_should_be":"UNCHANGED","load_bearing_attack":"Section 4.2's throughput comparison is not an architecture-independent test of the neutral-host design. The authors' own CPU monitoring shows the four-slice configuration creates one Open5GS process per slice and spreads work across the VM's cores, whereas the one-client baseline runs a single slice with one process capped at ~99% of one core (Section 4.2, Tables 2-3). A traditional operator could equally deploy multiple slices or multiple SMF/UPF instances to use more cores, so the measured 61.8% gain does not establish an advantage of the proposed multi-tenant architecture. The PLR result in Section 4.3 is additionally load-selection dependent: both configurations are tested at 23.1 Mbps, but Table 2 shows the one-slice baseline saturates around 22.1 Mbps, so its 1.11% PLR is largely expected; at lower offered loads the loss would approach zero in both cases. Functional authentication and isolation tests are plausible, but the central performance claim in the Abstract is unsupported as stated.","agreement_with_reader":"agree"},"referee_report":{"model":"deepseek-v4-flash","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.","tokens_in":12064,"tokens_out":4844,"duration_ms":45366,"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":[{"comment":"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.","section":"§4.2, Tables 2–3"},{"comment":"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.","section":"§4.3, Table 4"},{"comment":"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.","section":"§3.2.2, Figures 4–6"}],"minor_comments":[{"comment":"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.","section":"Abstract"},{"comment":"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.","section":"Tables 2–4"},{"comment":"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.","section":"§4.2"},{"comment":"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.","section":"§3.2.1"}],"recommendation":"major_revision","confidential_remarks":"The paper is closer to an experience/design report than a controlled performance study. The functional demonstration of authentication and slice-isolation is valuable, but the abstract's quantitative performance claims should be revised or removed unless the baseline is made architecture-independent. The journal may also wish to consider whether an implementation-oriented framing, rather than a claim of performance superiority, better matches the manuscript's actual contribution."},"author_rebuttal":null,"desk_editor":{"model":"deepseek-v4-flash","letter":"The paper's real contribution is the combination of network slicing and LBO roaming in a neutral host core that serves both MNO and non-MNO tenants, implemented concretely with Open5GS and UERANSIM. That combination is not in the cited prior work, and the functional tests for authentication and traffic isolation are plausible and well described. The authors also do a decent job documenting the software limitations that forced deviations from the conceptual architecture. That part is worth a careful read by anyone building a multi-tenant 5G testbed.\n\nThe soft spot is the performance evaluation, and it is load-bearing. The 61.8% throughput gain and 96.8% lower PLR in the abstract come from comparing a one-slice baseline against a four-slice configuration. The paper's own CPU monitoring shows the gain is explained by Open5GS spawning one process per slice and spreading across cores, while the one-slice baseline is capped by a single process on a single core. A traditional operator could equally deploy multiple slices or multiple SMF/UPF instances to use more cores, so the comparison does not establish an architectural advantage. The PLR result is also suspect: both configurations run at 23.1 Mbps, but the one-slice baseline saturates around 22.1 Mbps, so its loss is largely saturation loss. At lower load the difference would shrink toward zero. The stress-test note on this point is correct.\n\nThe functional claims stand, and the architecture is a sensible incremental design. But the abstract overstates the performance results, and the paper would need a proper baseline (e.g., multiple SMF/UPF processes or multiple slices allocated to the single tenant) before the quantitative claims are credible. Releasing configuration files would also help reproducibility.\n\nMy take: this is an honest engineering paper with a useful implemented architecture, but the headline numbers are not supported as stated. It deserves a serious referee who will push on the baseline, not a desk reject. If the authors fix the comparison and soften the abstract, I would be happy to see it published in a systems or experimentation venue.","headline":"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.","tokens_in":12615,"tokens_out":1473,"would_cite":false,"duration_ms":15048,"reading_group":"maybe","serious_thinker":"yes","would_accept_peer_review":true},"rs_alignment":null,"lean_confirmation":null,"pith_extraction":{"msc":[],"pacs":[],"model":"deepseek-v4-flash","headline":"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.","keywords":["5G","network sharing","neutral host","network slicing","roaming","traffic isolation","throughput","packet loss"],"falsifier":"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.","tokens_in":11634,"feed_emoji":"📶","tokens_out":8613,"duration_ms":68902,"temperature":0.7,"pith_summary":"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.","feed_headline":"In shared 5G test, four slices beat one by 61.8%","feed_subtitle":"A neutral-host core with per-client slices serves operators and non-operators while cutting packet loss by 96.8%.","key_machinery":"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.","core_discovery":"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.","pith_inferences":["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."],"forward_implications":["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."],"supporting_citations":[{"why":"Positions NFV and network slicing as the enabling techniques for shared 5G neutral-host infrastructure.","marker":"[4]"},{"why":"Supplies the neutral-host concept, its use cases, and its management challenges that the architecture addresses.","marker":"[7]"},{"why":"Defines the end-to-end network slicing model and S-NSSAI identification that the per-client slices rely on.","marker":"[8]"},{"why":"Describes the local-breakout and home-routed roaming architectures and the SEPP function used for operator-client authentication.","marker":"[9]"},{"why":"Classifies passive and active infrastructure sharing including MOCN, MORAN, and roaming, framing where the proposal sits.","marker":"[11]"},{"why":"Presents a prior neutral-host design that uses roaming for authentication but lacks traffic isolation, which this paper extends.","marker":"[14]"},{"why":"Compares open-source 5G core implementations and supports the selection of the core that provides slicing and roaming.","marker":"[23]"},{"why":"Provides the traffic generator used to measure the throughput and packet-loss values behind the performance comparison.","marker":"[24]"}],"fun_headline_variants":["Sliced neutral-host 5G: +61.8% throughput, -96.8% packet loss","Four slices, one RAN: 61.8% faster, 96.8% less loss","Shared 5G with per-client slices boosts throughput 61.8%, cuts loss 96.8%","Neutral-host 5G slices: 61.8% more throughput, 96.8% less loss","Multi-client 5G slices: 61.8% throughput gain, 96.8% loss drop"],"cache_read_input_tokens":3200,"weakest_assumption_plain":"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.","fun_headline_variants_meta":{"raw":{"variants":["Sliced neutral-host 5G: +61.8% throughput, -96.8% packet loss","Four slices, one RAN: 61.8% faster, 96.8% less loss","Shared 5G with per-client slices boosts throughput 61.8%, cuts loss 96.8%","Neutral-host 5G slices: 61.8% more throughput, 96.8% less loss","Multi-client 5G slices: 61.8% throughput gain, 96.8% loss drop"]},"model":"deepseek-v4-flash","effort":"low","cost_usd":0.000405,"raw_usage":{"total_tokens":2114,"prompt_tokens":962,"completion_tokens":1152,"prompt_tokens_details":{"cached_tokens":384},"prompt_cache_hit_tokens":384,"prompt_cache_miss_tokens":578,"completion_tokens_details":{"reasoning_tokens":1015}},"tokens_in":578,"tokens_out":1152,"duration_ms":9066,"temperature":1.0,"reasoning_tokens":1015,"cache_read_input_tokens":384,"cache_creation_input_tokens":0},"cache_creation_input_tokens":0},"created_at":"2026-08-12T14:12:48.555045+00:00","model_set":{"reader":"deepseek-v4-flash"},"falsifier":"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.","supporting_citations":[{"cited_title":"Edge Computing Enhancements in an NFV-Based Ecosystem for 5G Neutral Hosts","cited_arxiv_id":null,"evidence_quote":"Positions NFV and network slicing as the enabling techniques for shared 5G neutral-host infrastructure."},{"cited_title":"Roaming in the 5G system: The 5GS roaming architecture","cited_arxiv_id":null,"evidence_quote":"Describes the local-breakout and home-routed roaming architectures and the SEPP function used for operator-client authentication."},{"cited_title":"Infrastructure Sharing","cited_arxiv_id":null,"evidence_quote":"Classifies passive and active infrastructure sharing including MOCN, MORAN, and roaming, framing where the proposal sits."},{"cited_title":"Making Neutral Host a Reality with OnGo; Mobile Experts White Paper; Mobile Experts, Inc.: Campbell, CA, USA, 2018","cited_arxiv_id":null,"evidence_quote":"Presents a prior neutral-host design that uses roaming for authentication but lacks traffic isolation, which this paper extends."},{"cited_title":"Open Source 5G Core Network Implementations: A Qualitative and Quantitative Analysis","cited_arxiv_id":null,"evidence_quote":"Compares open-source 5G core implementations and supports the selection of the core that provides slicing and roaming."},{"cited_title":"Available online: https://iperf.fr/ (accessed on 16 October 2023)","cited_arxiv_id":null,"evidence_quote":"Provides the traffic generator used to measure the throughput and packet-loss values behind the performance comparison."}],"review_version":1}