Ieee experiments

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	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	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 with its role and shared constraint.
3. Simulation setup: channel/system model, swept parameters, Monte-Carlo realizations.
4. Validation plan: which expressions get a simulation overlay; asymptotic-slope check.
5. Convergence/complexity: iteration behaviour + complexity order vs benchmarks.
6. Gaps: curves or numbers the user still needs to produce.