/ieee-experiments

name: ieee-experiments
description: >-
  Design and audit IEEE communications simulation and numerical-results sections for JSAC, TWC,
  TCOM, WCL, and CL. Covers benchmark schemes, Monte-Carlo protocol, BER/SER/outage/rate/EE
  metrics, SNR/antenna/user sweeps, analysis-vs-simulation validation, convergence and
  complexity, learning-based evaluation, ISAC rate-CRB/detection tradeoffs, robustness, and
  empirical/ray-tracing/testbed evidence. Use for planning or checking results: benchmark
  selection, simulation setup, Monte-Carlo validation, neural-network evaluation, CRB/ISAC
  tradeoffs, fairness boundaries, or reviewer-risk audits.

IEEE Communications — Simulation and Numerical Results

Use this skill to make the evidence earn the claims in a PHY/network communications paper. Every contribution in the Introduction must have a result that could falsify it; for analytical papers, every derived expression must be validated by Monte-Carlo simulation; every figure answers one question.

Core stance

• **Results test claims, not showcase wins.** Map each contribution to the curve/table that

supports it before running anything.

• **Validate analysis with simulation.** If the paper derives a closed-form expression (outage,

BER, rate, coverage), Monte-Carlo markers must sit on the analytical curve — that agreement *is* the proof the derivation is correct. Note asymptotic slope (diversity order) where claimed.

• **Fairness is declared, not assumed.** State the comparison's boundary: same power budget, same

CSI assumption, same bandwidth/antennas, same channel realizations across schemes.

• **No fabrication.** Do not invent curves, gains, benchmark numbers, or "matching" between theory

and simulation. Use `[PLACEHOLDER]` for results not yet run and list what the user must produce.

When to open extra files

| File | Open when | |---|---| | [references/experiment-design.md](references/experiment-design.md) | Choosing the system/channel setup, benchmark schemes, communications metrics, Monte-Carlo protocol, convergence/complexity, learning-based evaluation (NMSE/generalization/inference cost), ISAC dual metrics (CRB/detection + rate–CRB tradeoff), and robustness (imperfect CSI/hardware) tests | | [references/tables-and-claims.md](references/tables-and-claims.md) | Structuring result tables, mapping each table/figure to a claim, table/prose division of labour, and IEEE table conventions |

The evidence ladder (design in this order)

1. Validation            do Monte-Carlo markers match the analysis (curves), and is the
                         asymptotic slope (diversity order / DoF) as claimed?  [analytical papers]
2. Performance           does the scheme beat conventional and prior-art schemes on the key
                         metric (sum rate, BER, outage, EE, ...)?
3. Operating regimes     behaviour swept across SNR, #antennas, #users, power, blocklength, K-factor
4. Design analysis       is each design choice necessary (compare reduced "w/o" variants)?
5. Convergence & cost    does the iterative algorithm converge; complexity order vs benchmarks
6. Robustness            graceful degradation under imperfect CSI, hardware impairments, mismatch

Not every paper needs all six. An optimization paper centres on rungs 2–5; an analytical paper must clear rung 1 first. A method paper that stops at rung 2 is usually under-evaluated; a letter (WCL/CL) may show only rungs 1–3 for space — see the `ieee-letter` skill.

Workflow

1. **List the contributions** (from the Introduction). For each, write the single result that would convince a skeptic and the one that could falsify it. 2. **Choose benchmark schemes** across categories (see experiment-design.md): proposed, conventional/heuristic, prior-art (same setting), an upper bound (relaxed/genie/perfect-CSI), and a lower bound (random/equal-power/no-optimization). Label each category. For a learning-based paper, always include the **model-based method it replaces** (LS/MMSE/WMMSE) and, for deep unfolding, the parent iterative algorithm at full and at matched `L` iterations. 3. **Choose metrics** that match the claim — not just the headline. Add a tail/distributional metric (outage, CDF, worst-user rate) for stability claims, and a cost metric (complexity order, runtime, energy efficiency) for efficiency claims. 4. **Plan parameter sweeps:** which quantity on the x-axis (usually SNR/transmit power), what is swept as curve families (#antennas, #users, K-factor), and the regime that exposes the claim. 5. **Set the Monte-Carlo protocol:** number of independent channel realizations, what is averaged, confidence/smoothness, and **the same channel seeds across all schemes** for paired comparison. 6. **Plan analysis-vs-simulation validation** (analytical papers): which expressions get a simulation overlay, and the asymptotic check. 7. **Plan convergence/complexity** for any iterative algorithm (SCA/ADMM/AO/fractional programming): objective-vs-iteration curve plus per-iteration complexity order. 8. **Declare the fairness boundary** in words (see below). 9. **Map every planned figure/table to one claim;** drop anything that answers no question. 10. **Return** the design as a claim→result→metric→figure matrix, plus a gap list.

Declare the fairness boundary

When no standard public benchmark exactly matches the setting:

> Since no existing scheme fully matches the considered setup, representative implementable schemes > are adopted under the same power budget, CSI assumption, and bandwidth.

Then classify each scheme (proposed / conventional / prior-art / upper bound / lower bound) and state the shared resource constraint. This single move pre-empts the most common reviewer objection ("the comparison is unfair").

Output format

1. `Claim–result matrix:` `Contribution → Result (curve/table) → Metric(s) → Fig/Table → Status`. 2. `Benchmark schemes:` grouped by category, each labelled