MobiCom Experiments
MobiCom's evidence culture is physical: a mobile/wireless mechanism is believed when it is
measured over the air, on real hardware, under conditions that resemble deployment. A
simulation-only or single-run evaluation reads as under-done here. Design the evaluation as
a set of questions about the mechanism, then build the smallest measurement campaign that
answers them on real radios.
Questions before measurements
Write the evaluation's subsection titles as questions first — Does the mechanism hold under
mobility? What does it cost in energy at rest? When does the channel defeat it? — then
design one experiment per question. The inverted approach (run everything, narrate the
survivors) produces the benchmark tour that MobiCom reviews call unfocused.
A minimal matrix for a wireless-mechanism paper:
| Question |
Experiment |
Metrics that answer it |
| Does it work in the motivating condition? |
over-the-air run under the target channel/mobility |
delivery rate, goodput, SNR/BER distribution |
| What does it cost when idle? |
baseline with no stress |
energy-per-bit, power draw, CPU/airtime overhead |
| Why does it work? |
component breakdown / ablation |
per-mechanism contribution |
| Does it scale? |
node / distance / density sweeps |
knee location, per-node or per-meter curve |
| When does it break? |
interference, deep fades, high mobility |
the regime where baselines win |
| Does it hold over time? |
multi-hour or multi-day runs |
drift, stability, tail behavior |
Measurement methodology reviewers check
- State the RF setup completely: radio/SDR model and firmware, carrier frequency,
bandwidth, transmit power, antenna and gain, and receiver chain. A number without its
radio context is not interpretable.
- Name the channel condition: distance, line-of-sight vs multipath, ambient
interference, and how you characterized it (RSSI/CSI traces, coherence time). Do not let
"in our lab" stand in for a channel description.
- Make mobility explicit: walker paths, speeds, and schedules for mobility experiments,
and a stationary control. "Under mobility" without the traces is unverifiable.
- Report ground-truth honestly: how position, gesture, or decode-correctness truth was
obtained, and its own error, since a sensing result is only as good as its reference.
Energy is a first-class metric
Battery and harvested-energy claims are common at MobiCom and are held to instrument-level
scrutiny:
Energy report checklist:
instrument: power monitor / shunt + DAQ, sampling rate
quantity: energy-per-bit or per-operation, not just average power
boundary: what is inside the measured envelope (radio only? whole tag?)
budget: for harvested/batteryless designs, the source and the duty cycle
An energy claim that cannot be re-derived from a described measurement setup should not
survive your own audit.
Baselines on tuned hardware
- Compare against the incumbent people actually run, configured the way its own
documentation prescribes — an untuned baseline is the most common credibility wound in
systems and wireless reviewing.
- Include the do-less baseline: the trivial fix (more power, a fixed high rate, another
antenna). If the mechanism cannot beat it at equal cost, that is the finding.
- When a competitor cannot be run (proprietary radio, unavailable hardware), reimplement and
label it a reimplementation, or compare on published numbers with the configuration deltas
stated.
Distributions, not superlatives
- Report percentiles and confidence intervals for delivery, latency, and throughput
claims; a single "up to N×" without the distribution behind it is a review risk
(
mobicom-writing-style).
- Show CDFs for headline results and repeat runs across enough channel realizations,
days, or walker paths to expose run-to-run spread; state what varies between repeats.
- Wireless results are time- and place-dependent — a result from one room at one hour is
not a claim about the mechanism until the spread is characterized.
Audit checklist
Output format
[Evidence form] over-the-air testbed / deployment / trace / simulation (claimed vs actual)
[Question map] question -> experiment -> metric (gaps flagged)
[RF+channel] setup and conditions specified? y/n per headline experiment
[Energy] measured, with instrument and boundary? y/n
[Baseline audit] incumbent tuned? do-less present?
[Break condition] regime where the mechanism loses: <named or MISSING>
[Priority additions] ordered by review-risk reduction per testbed-week
Source: brycewang-stanford/Awesome-Journal-Skills → MobiCom-Skills/skills/mobicom-experiments/SKILL.md
1---2name: mobicom-experiments3description: Use when designing or auditing the evaluation of a MobiCom submission — building real-device testbeds, choosing RF and channel measurement methodology, injecting realistic mobility and interference, profiling energy on hardware, picking tuned baselines, and reporting distributions so wireless reviewers see where the mechanism wins and breaks.4---567# MobiCom Experiments89MobiCom's evidence culture is physical: a mobile/wireless mechanism is believed when it is10**measured over the air, on real hardware, under conditions that resemble deployment**. A11simulation-only or single-run evaluation reads as under-done here. Design the evaluation as12a set of questions about the mechanism, then build the smallest measurement campaign that13answers them on real radios.1415## Questions before measurements1617Write the evaluation's subsection titles as questions first — *Does the mechanism hold under18mobility? What does it cost in energy at rest? When does the channel defeat it?* — then19design one experiment per question. The inverted approach (run everything, narrate the20survivors) produces the benchmark tour that MobiCom reviews call unfocused.2122A minimal matrix for a wireless-mechanism paper:2324| Question | Experiment | Metrics that answer it |25|---|---|---|26| Does it work in the motivating condition? | over-the-air run under the target channel/mobility | delivery rate, goodput, SNR/BER distribution |27| What does it cost when idle? | baseline with no stress | energy-per-bit, power draw, CPU/airtime overhead |28| Why does it work? | component breakdown / ablation | per-mechanism contribution |29| Does it scale? | node / distance / density sweeps | knee location, per-node or per-meter curve |30| When does it break? | interference, deep fades, high mobility | the regime where baselines win |31| Does it hold over time? | multi-hour or multi-day runs | drift, stability, tail behavior |3233## Measurement methodology reviewers check3435- **State the RF setup completely:** radio/SDR model and firmware, carrier frequency,36 bandwidth, transmit power, antenna and gain, and receiver chain. A number without its37 radio context is not interpretable.38- **Name the channel condition:** distance, line-of-sight vs multipath, ambient39 interference, and how you characterized it (RSSI/CSI traces, coherence time). Do not let40 "in our lab" stand in for a channel description.41- **Make mobility explicit:** walker paths, speeds, and schedules for mobility experiments,42 and a stationary control. "Under mobility" without the traces is unverifiable.43- **Report ground-truth honestly:** how position, gesture, or decode-correctness truth was44 obtained, and its own error, since a sensing result is only as good as its reference.4546## Energy is a first-class metric4748Battery and harvested-energy claims are common at MobiCom and are held to instrument-level49scrutiny:5051```text52Energy report checklist:53 instrument: power monitor / shunt + DAQ, sampling rate54 quantity: energy-per-bit or per-operation, not just average power55 boundary: what is inside the measured envelope (radio only? whole tag?)56 budget: for harvested/batteryless designs, the source and the duty cycle57```5859An energy claim that cannot be re-derived from a described measurement setup should not60survive your own audit.6162## Baselines on tuned hardware6364- Compare against the **incumbent people actually run**, configured the way its own65 documentation prescribes — an untuned baseline is the most common credibility wound in66 systems and wireless reviewing.67- Include the **do-less** baseline: the trivial fix (more power, a fixed high rate, another68 antenna). If the mechanism cannot beat it at equal cost, that is the finding.69- When a competitor cannot be run (proprietary radio, unavailable hardware), reimplement and70 label it a reimplementation, or compare on published numbers with the configuration deltas71 stated.7273## Distributions, not superlatives7475- Report **percentiles and confidence intervals** for delivery, latency, and throughput76 claims; a single "up to N×" without the distribution behind it is a review risk77 (`mobicom-writing-style`).78- Show **CDFs** for headline results and repeat runs across enough channel realizations,79 days, or walker paths to expose run-to-run spread; state what varies between repeats.80- Wireless results are **time- and place-dependent** — a result from one room at one hour is81 not a claim about the mechanism until the spread is characterized.8283## Audit checklist8485- [ ] Every evaluation subsection answers a named question.86- [ ] RF setup, channel condition, and mobility fully specified per experiment.87- [ ] Energy measured with a described instrument and boundary, not estimated.88- [ ] Incumbent-grade baseline present and tuned; do-less baseline present.89- [ ] Percentiles + distributions for headline metrics; multi-run spread reported.90- [ ] At least one condition the mechanism does not win, discussed rather than buried.91- [ ] Numbers in abstract/intro regenerate from the recorded runs.92- [ ] A hardware-optional or downscaled variant exists for artifact evaluators93 (`mobicom-artifact-evaluation`).9495## Output format9697```text98[Evidence form] over-the-air testbed / deployment / trace / simulation (claimed vs actual)99[Question map] question -> experiment -> metric (gaps flagged)100[RF+channel] setup and conditions specified? y/n per headline experiment101[Energy] measured, with instrument and boundary? y/n102[Baseline audit] incumbent tuned? do-less present?103[Break condition] regime where the mechanism loses: <named or MISSING>104[Priority additions] ordered by review-risk reduction per testbed-week105```106107---108109**Source:** [`brycewang-stanford/Awesome-Journal-Skills`](https://github.com/brycewang-stanford/Awesome-Journal-Skills) → `MobiCom-Skills/skills/mobicom-experiments/SKILL.md`