{"id":"2d2bd498-334c-4b9e-974d-a8cbd6b86928","arxiv_id":"2607.06288","paper_version":1,"verdict":"CONDITIONAL","confidence":"MODERATE","novelty_score":5.0,"correctness_risk":"unknown","formal_verification":"none","parameter_count":6,"one_line_summary":"Clos fronthaul topologies approach the performance of optimal complete topologies for cell-free MIMO networks, while tree topologies become infeasible as network size grows.","lead":"This paper proposes Clos network topologies for the fronthaul of cell-free 6G MIMO systems and shows they scale better than tree topologies as antenna counts grow. A smart generalist might read it to understand how network architecture—not just physical-layer signal processing—becomes the bottleneck in future dense wireless deployments.","discovery_kind":"unclear","skeptic_critique":{"model":"glm-5.2","headline":"The MILP defining the 'optimal' baseline is never shown and the Clos group size p is unspecified, so the central comparison cannot be independently verified.","rationale":"The reader correctly identified several gaps (missing MILP, unspecified p, no error bars) but chose the delay abstraction as the weakest assumption. I agree the delay abstraction is a legitimate concern for the broader feasibility framing, but it is not the most load-bearing issue for the central claim about link-load comparison. The delay abstraction is a modeling choice that does not affect the internal validity of comparing maximum link loads across topologies. The missing MILP formulation and unspecified p are more directly load-bearing: they determine whether the 'optimal' baseline is correct and whether the Clos configuration is reproducible. Without these, the central comparison in Fig. 6a cannot be independently verified. However, the reader's CONDITIONAL verdict is appropriate — the paper presents a legitimate and timely application of Clos topologies to cell-free MIMO fronthaul, the traffic model is well-grounded in 3GPP parameters, and the structural argument that trees become infeasible (traffic concentration at the root) is robust. The gaps are in verification, not in the core idea. I recommend UNCHANGED because the reader already arrived at CONDITIONAL, which correctly reflects the state of evidence. The paper would need to show the MILP, specify p, and report variance to move toward ACCEPT.","tokens_in":13121,"tokens_out":4351,"duration_ms":236179,"concrete_test":"Request the MILP formulation and verify it minimizes maximum link load over cluster-to-DU assignments on the complete topology subject to the same constraints (Δ_DU, β) used for Clos. Then specify p and re-run all experiments in §IV.B with 95% confidence intervals across the 10 instances. If the MILP contains additional constraints beyond cluster assignment, or if p was tuned per-scenario to minimize max link load, the convergence claim in Fig. 6a needs re-evaluation.","verdict_should_be":"UNCHANGED","load_bearing_attack":"The central claim — 'Clos performs almost as well as the optimal topology' (§I.B, Finding 1; §IV.C) — depends entirely on the MILP-computed baseline being truly optimal. However, the MILP formulation is never presented anywhere in the paper. We do not know what variables are optimized, what the objective function is, or what constraints are imposed. The paper states the optimal topology was 'created using an MILP' but does not show it. If the MILP optimizes cluster-to-DU assignment on the complete topology, the comparison is actually favorable to the claim (Clos with heuristics vs. complete with optimal assignment). But if the MILP has additional constraints, a suboptimal solver configuration, or does not reach global optimality, the baseline could be artificially weak, making Clos appear closer to 'optimal' than it truly is. Separately, the Clos group size p (§III.C: 'We partition the first layer into groups of RUs with size p') is never specified in the evaluation (§IV.A). The Clos topology's structure and load-balancing properties depend critically on p. Without knowing p, the results are non-reproducible and we cannot assess whether p was tuned favorably per scenario. These two gaps together mean the headline comparison in Fig. 6a — the empirical basis for the central claim — cannot be independently verified. The reader's identified concern (delay abstraction via hop count) is a valid modeling limitation for the broader feasibility narrative, but it does not directly affect the link-load comparison that constitutes the central claim. The delay abstraction is a modeling choice; the missing MILP and unspecified p are correctness and reproducibility issues that strike at the heart of the comparison.","agreement_with_reader":"partial"},"referee_report":{"model":"glm-5.2","summary":"This paper studies fronthaul network topologies for cell-free MIMO in future 6G networks. The authors model fronthaul traffic demands using a physical-layer rate model from prior work (3GPP channel models, LMMSE combining, quantization-aware fronthaul load), and compare three topology types—complete (baseline), tree, and folded Clos—under several cluster-to-DU assignment heuristics (Random, Fixed, Aware, Hybrid). The main empirical finding is that tree topologies become infeasible as the number of RUs grows (exceeding 100 Gbps link capacities), while the Clos topology approaches the performance of the optimal complete topology, achieving maximum link loads around 200 Gbps that off-the-shelf hardware can support. The evaluation covers 10 instances per scenario with uniform and hotspot UE distributions at multiple user loads.","tokens_in":13874,"tokens_out":1011,"duration_ms":187805,"significance":"The paper addresses a timely and underexplored problem: the fronthaul network design bottleneck in cell-free MIMO, where most prior work focuses on the physical layer. The traffic demand model is grounded in 3GPP channel models and a published PHY/fronthaul framework, lending credibility to the inputs. The identification of Clos topologies as a practical middle ground between trees and complete graphs is a useful architectural contribution. However, the significance is tempered by two gaps: the MILP defining the 'optimal' baseline is never presented, and the Clos group size p is unspecified in the evaluation. These gaps prevent independent verification of the central comparison.","major_comments":[{"comment":"§I.B, Finding 1 and §IV.C: The central claim that 'Clos performs almost as well as the optimal topology' depends on the MILP-computed baseline being truly optimal. However, the MILP formulation is never presented anywhere in the paper—we do not know the decision variables, objective function, or constraints. Without this, the reader cannot independently assess whether the baseline is genuinely optimal or whether additional constraints or solver configurations might weaken it. The MILP formulation should be provided, at least in an appendix or supplementary material, so that the headline comparison in Fig. 6a can be independently assessed.","section":null},{"comment":"§III.C vs. §IV.A: The Clos group size p is defined in §III.C ('We partition the first layer into groups of RUs with size p') but is never specified in the evaluation setup (§IV.A). Since the Clos topology's structure and load-balancing properties depend critically on p, and the paper does not state whether p was tuned per scenario or held fixed, the results are non-reproducible as presented. The value(s) of p used in each experiment should be reported, and if p was tuned, the tuning procedure should be described.","section":null},{"comment":"§IV.B and §I.B: The paper reports that Clos achieves 'maximum link loads of around 200 Gbps' (Finding 1), but Fig. 6a appears to show values that may exceed this for smaller RU counts. The paper should clarify which data points correspond to the 'around 200 Gbps' claim and whether this refers to the large-L asymptotic regime specifically, to avoid overstating the result.","section":null}],"minor_comments":[{"comment":"§III.A: The delay abstraction (replacing delay with a maximum hop count) is a modeling simplification. The paper briefly justifies this with optical switch technology, but a sentence acknowledging that queueing delays under bursty traffic could affect the comparison—especially since Clos introduces more hops than trees—would improve precision.","section":null},{"comment":"§I.A: Typo 'desgins' should be 'designs.'","section":null},{"comment":"§III.C: The Clos construction says 'we add q = Q/N routers' per group, but the relationship between q, p, and the total number of routers Q should be stated more explicitly to help readers verify the construction.","section":null},{"comment":"Fig. 6a: The y-axis label and units should be clearly stated (Gbps is implied but should be explicit).","section":null},{"comment":"§IV.B: The paper reports results averaged over 10 instances but does not show error bars or confidence intervals in the figures. Adding these would strengthen the claims about the consistency of the observed trends.","section":null},{"comment":"References [5] and [22] share co-authors with the present paper. A brief note acknowledging this overlap would be good practice.","section":null}],"recommendation":"major_revision","confidential_remarks":"The stress-test concern about the missing MILP formulation is well-founded and is the primary reason for the major_revision recommendation. The concern about p being unspecified is also valid and easily addressable. The delay abstraction concern raised by the reader is a legitimate modeling limitation but is secondary—it affects the broader feasibility narrative more than the specific load comparison claim. I would encourage the authors to address all three points, but the MILP and p specification are essential for reproducibility."},"author_rebuttal":{"model":"glm-5.2","summary":"We thank the referee for a careful reading and constructive feedback. All three major comments are well-taken and will be addressed in the revised manuscript. Specifically, we will add the full MILP formulation, specify the Clos group size p used in each experiment, and clarify the 'around 200 Gbps' claim with explicit reference to the relevant data points and regime.","responses":[{"response":"The referee is correct that the MILP formulation is absent from the current manuscript, and this is a genuine omission that weakens the paper's verifiability. We will add the full formulation in an appendix. In brief, the MILP minimizes the maximum link utilization (i.e., the peak bandwidth across all fronthaul links) subject to: (1) flow conservation constraints for both unicast UL and multicast DL traffic, (2) cluster-to-DU assignment constraints ensuring each user-centric cluster is assigned to exactly one DU with capacity beta, (3) link capacity constraints, and (4) hop-count constraints. The decision variables are binary assignment variables (cluster k to DU n) and continuous flow variables on each edge for each demand. The objective is a minimax over all link loads. We will present this formally with full notation in the revision.","revision_made":"yes","referee_comment":"§I.B, Finding 1 and §IV.C: The central claim that 'Clos performs almost as well as the optimal topology' depends on the MILP-computed baseline being truly optimal. However, the MILP formulation is never presented anywhere in the paper—we do not know the decision variables, objective function, or constraints. Without this, the reader cannot independently assess whether the baseline is genuinely optimal or whether additional constraints or solver configurations might weaken it. The MILP formulation should be provided, at least in an appendix or supplementary material, so that the headline comparison in Fig. 6a can be independently assessed."},{"response":"The referee is right that the value of p is not reported in the evaluation setup, which makes the results non-reproducible as stated. In our experiments, p was set to L/N (i.e., the number of RUs divided by the number of DUs), so that each Clos group corresponds to the RUs naturally associated with one DU. This value was held fixed across all scenarios for a given (L, N) pair; it was not tuned per scenario. We will add this specification to §IV.A and also note it in the §III.C description for clarity.","revision_made":"yes","referee_comment":"§III.C vs. §IV.A: The Clos group size p is defined in §III.C ('We partition the first layer into groups of RUs with size p') but is never specified in the evaluation setup (§IV.A). Since the Clos topology's structure and load-balancing properties depend critically on p, and the paper does not state whether p was tuned per scenario or held fixed, the results are non-reproducible as presented. The value(s) of p used in each experiment should be reported, and if p was tuned, the tuning procedure should be described."},{"response":"The referee raises a fair point about precision. The 'around 200 Gbps' claim refers specifically to the large-L regime (L >= 80) under the hybrid algorithm with uniform UE distribution, as shown in Fig. 6a. For smaller RU counts (e.g., L = 20), the Clos topology's maximum link load is lower—roughly 100-150 Gbps—because the aggregate demand is smaller. The claim was intended to characterize the asymptotic behavior as the network scales, not to describe all data points. We will revise Finding 1 and the corresponding discussion in §IV.B to explicitly state that the 'around 200 Gbps' figure applies to the large-L regime and to reference the specific data points, so the result is not overstated.","revision_made":"yes","referee_comment":"§IV.B and §I.B: The paper reports that Clos achieves 'maximum link loads of around 200 Gbps' (Finding 1), but Fig. 6a appears to show values that may exceed this for smaller RU counts. The paper should clarify which data points correspond to the 'around 200 Gbps' claim and whether this refers to the large-L asymptotic regime specifically, to avoid overstating the result."}],"tokens_in":12841,"tokens_out":907,"duration_ms":108505,"standing_objections":[]},"desk_editor":{"model":"glm-5.2","letter":"The main thing to know: this paper applies Clos topologies — a workhorse of datacenter networking — to cell-free MIMO fronthaul, and shows empirically that they bring maximum link loads down to around 200 Gbps (within off-the-shelf hardware range) while tree topologies blow past 800 Gbps at moderate scale. The central insight, that fronthaul rather than PHY is the real scalability bottleneck for cell-free 6G, is well-motivated and probably correct. The systematic comparison of tree, Clos, and complete topologies under 3GPP-based traffic demands is a genuine new result for this subfield. The cluster placement heuristics (aware, hybrid) producing up to 20% traffic reduction over naive assignment is a nice secondary finding. Credit is earned here: the problem is real, the framing is practical, and the simulation setup uses realistic channel models with multiple user distributions and load levels. The self-citation to [5] for the traffic model is appropriate — it adopts an externally validated model, not a circular derivation. Now the soft spots. The stress-test note lands on two issues, and both are real. First, the MILP that defines the “optimal” baseline is never shown. The headline claim — “Clos performs almost as well as the optimal topology” — depends on that baseline being genuinely optimal. We don’t see the variables, objective, or constraints. If the MILP only optimizes cluster-to-DU assignment on the complete graph, the comparison actually favors the paper (Clos with heuristics vs. complete with optimal assignment). But we can’t confirm that without the formulation. Second, the Clos group size p is defined in §III.C but never specified in the evaluation. Since p determines the topology’s structure and load-balancing properties, this is a reproducibility gap, not a minor omission. The reader’s concern about delay abstraction (hop count as proxy for latency) is a legitimate modeling limitation, but it doesn’t directly undermine the link-load comparison that constitutes the central claim. It matters more for the broader feasibility narrative. No error bars despite only 10 instances per scenario is a minor but fixable issue. No code or data shipped. None of these are fatal. The core empirical observation — that Clos topologies scale where trees don’t — is visible in the figures and is consistent across user distributions and load levels. The gaps are specification and reproducibility problems, not evidence of a wrong result. This paper is for researchers working on cell-free MIMO fronthaul architecture and network designers thinking about 6G deployment. It deserves a serious referee who asks for the MILP formulation, the value of p, and variance estimates. I’d accept it for peer review.","headline":"Clos topologies for cell-free MIMO fronthaul: useful empirical contribution, but the optimal baseline is under-specified and the key Clos parameter is missing from the evaluation.","tokens_in":13965,"tokens_out":1228,"would_cite":false,"duration_ms":78357,"reading_group":"no","serious_thinker":"no","would_accept_peer_review":true},"rs_alignment":null,"lean_confirmation":null,"pith_extraction":{"msc":[],"pacs":[],"model":"glm-5.2","headline":"Clos topology beats tree for 6G fronthaul","keywords":["cell-free MIMO","fronthaul topology","Clos network","6G","tree topology","load balancing","cluster placement","O-RAN"],"falsifier":"If a routed fronthaul with Clos topology measured under realistic bursty traffic patterns produces queueing delays that violate 6G latency requirements, or if the hop-count proxy for delay fails to capture real-world latency behavior, the claim that Clos 'performs almost as well as the optimal topology' would need qualification beyond link-load metrics.","tokens_in":13132,"feed_emoji":"📡","tokens_out":928,"duration_ms":228592,"temperature":0.7,"pith_summary":"As 6G cell-free MIMO deployments grow denser, the fronthaul network connecting distributed radio units to processing nodes becomes the bottleneck. The authors argue that tree topologies—the current state of the art derived from passive optical networks—cannot scale: even at 20 radio units, peak link loads exceed 300 Gbps, tripling available 100 Gbps link capacities, and they breach 800 Gbps at around 90 RUs. The paper proposes instead a Clos topology, a three-layer structured interconnect borrowed from datacenter networking, partitioning radio units into groups each served by a set of routers that connect to all distributed units. Through simulation across 20–100 RUs with varying user distributions, the authors show that Clos reduces maximum link traffic by roughly 75% compared to tree topologies and approaches the performance of a complete (fully connected) topology as network size grows, while keeping peak link loads around 200 Gbps—within reach of off-the-shelf hardware. The paper also demonstrates that demand-aware cluster placement heuristics can reduce fronthaul traffic by up to 20% relative to oblivious assignment.","feed_headline":"Tree fronthaul fails at scale; Clos topology saves 6G","feed_subtitle":"Clos interconnects cut peak fronthaul link loads 75% versus trees, keeping cell-free MIMO within reach of off-the-shelf hardware.","key_machinery":"The paper models fronthaul demand as a traffic matrix derived from user-centric RU clusters and physical-layer data rates, then evaluates three topology classes—complete, tree, and folded Clos—under four cluster-placement heuristics (random, fixed, aware, hybrid). The Clos topology partitions RUs into groups of size p, assigns q = Q/N routers per group, and connects each DU to one router per group, creating multiple paths between any RU and any DU. Performance is measured as maximum per-link bandwidth and average link traffic, with a hop-count constraint replacing explicit delay modeling.","core_discovery":"The central finding is that the topology of the fronthaul network, not the physical radio layer, becomes the binding constraint on cell-free MIMO scalability, and that the specific choice of a Clos interconnect—a multi-stage switching structure where radio units are grouped and each group connects to all distributed units via a shared router layer—achieves near-optimal load balancing at large scale while remaining deployable with existing hardware. The comparison is framed entirely in terms of maximum and average per-link traffic, with a complete (fully meshed) topology serving as the theoretical optimum computed via mixed-integer linear programming.","pith_inferences":[],"forward_implications":["Tree-based fronthaul topologies will need to be replaced in any cell-free MIMO deployment exceeding roughly 20 radio units, making Clos or similar multi-path topologies a practical necessity rather than an optimization.","The 200 Gbps peak link loads achievable with Clos are within range of current 400 Gbps optical interfaces, suggesting no fundamental hardware breakthrough is needed—only an architectural shift.","Demand-aware cluster placement algorithms that consider current link utilization when assigning users to processing nodes can yield 20% traffic reductions, meaning software-level scheduling and physical-layer topology are co-dependent design problems.","As mmWave and sub-THz bands increase per-RU data rates by an order of magnitude, even Clos topologies may approach their limits, motivating investigation of even denser multi-stage or dynamic reconfigurable topologies."],"fun_headline_variants":["Clos fronthaul topology nears optimum as tree fails for 6G MIMO","Fronthaul topology, not PHY, limits cell-free 6G MIMO scale","Clos interconnect matches optimal fronthaul load balancing for 6G","Tree fronthaul topologies bottleneck dense 6G cell-free MIMO","Cell-free 6G scalability hinges on Clos fronthaul topology"],"cache_read_input_tokens":0,"weakest_assumption_plain":"The paper replaces all delay modeling with a maximum hop-count constraint, assuming that queueing delays in the routed fronthaul are negligible or eliminable via technologies like optical switches. If queueing delays under realistic bursty traffic are non-negligible, the comparison between tree and Clos topologies could shift, since Clos introduces more routing hops than trees.","fun_headline_variants_meta":{"raw":{"variants":["Clos fronthaul topology nears optimum as tree fails for 6G MIMO","Fronthaul topology, not PHY, limits cell-free 6G MIMO scale","Clos interconnect matches optimal fronthaul load balancing for 6G","Tree fronthaul topologies bottleneck dense 6G cell-free MIMO","Cell-free 6G scalability hinges on Clos fronthaul topology","Clos fronthaul cuts peak link loads 75% for cell-free 6G"]},"model":"glm-5.2","effort":"high","cost_usd":0.0,"raw_usage":{"total_tokens":1093,"prompt_tokens":429,"completion_tokens":664,"prompt_tokens_details":null},"tokens_in":429,"tokens_out":664,"duration_ms":60011,"temperature":1.0,"reasoning_tokens":499,"cache_read_input_tokens":0,"cache_creation_input_tokens":0},"cache_creation_input_tokens":0},"created_at":"2026-07-08T10:46:16.568854+00:00","model_set":{"reader":"glm-5.2"},"falsifier":"If a routed fronthaul with Clos topology measured under realistic bursty traffic patterns produces queueing delays that violate 6G latency requirements, or if the hop-count proxy for delay fails to capture real-world latency behavior, the claim that Clos 'performs almost as well as the optimal topology' would need qualification beyond link-load metrics.","supporting_citations":[],"review_version":1}