| name | sensys-related-work |
| description | Use when positioning a SenSys paper against the sensing, embedded, IoT, and on-device-AI literature — sweeping the right venue lanes after the SenSys/IPSN/IoTDI merger, proving each citation's venue via dblp/ACM DL against the MobiCom/NSDI/IPSN traps, distinguishing your mechanism from the nearest prior system, and self-citing blind-safely. |
SenSys Related Work
A SenSys related-work section has one job: show that you know the closest prior systems and
can name, precisely, what your mechanism does that theirs does not. Vague "prior work is limited"
draws blood at a systems venue where reviewers built that prior work. The 2026 merger widened the
lanes you must sweep — IPSN and IoTDI literature is now sibling canon, not a separate world.
Sweep the right lanes
After the merger, a thorough sweep covers more ground than a pre-2026 SenSys paper did:
| Lane | Where it lives | What to look for |
|---|
| Low-power networked sensing | SenSys, IPSN (pre-2026) | The primitive/service your mechanism competes with |
| IoT design & deployment | SenSys, IoTDI (pre-2026) | Deployment methodology and system architecture priors |
| On-device / embedded AI | SenSys, TinyML venues, embedded-ML tracks | Footprint/latency baselines on real MCUs |
| Mobile & wireless systems | MobiCom, MobiSys | Adjacent mechanisms you must distinguish from, not claim |
| Sensing algorithms / DSP | Signal-processing venues | The math you build on but do not re-derive |
Prove the venue before you cite it
The sensing canon is the most-misfiled literature in systems. Directed diffusion is MobiCom,
not SenSys; Glossy is IPSN; TinyDB's core is OSDI/SIGMOD. Getting a venue wrong in related
work signals you do not know the field. Verify every load-bearing citation:
For each key citation:
1. Look it up on dblp (dblp.org) — read the venue key: conf/sensys? conf/ipsn? conf/mobicom?
2. Cross-check the ACM DL / proceedings for year and edition.
3. Record venue + year; if a rendering is unavailable, mark 待核实 — do NOT guess.
Post-merger nuance: a paper's community may now be part of SenSys, but its historical venue is
unchanged. A 2011 IPSN paper is still cited as IPSN 2011, even though IPSN merged into SenSys in
2026. Do not retroactively relabel.
Distinguish from the closest system, concretely
The paragraph that matters most contrasts you with the single nearest prior system. Make it
mechanism-level and, where possible, measurable:
Weak: "Unlike prior work, our system is more efficient."
Strong: "CTP-style collection assumes a persistent radio; our node duty-cycles the radio to a
1% budget and recovers routing state from non-volatile memory after each sleep, trading
a stated latency increase for a measured order-of-magnitude energy reduction (§4.2)."
The strong version names the prior mechanism, the specific difference, and the trade-off with a
pointer — exactly what a systems reviewer checks (sensys-writing-style).
Self-cite without breaking blind
Double-blind still applies to related work:
- Cite your own prior papers in the third person ("Prior work [12] showed...", never "our
earlier work [12]").
- Do not drop a relevant citation to preserve anonymity — omission is itself a signal and hurts
the positioning.
- Keep any comparison to your own unpublished/concurrent work blind and factual.
Position, do not inflate
A SenSys reviewer distrusts a related-work section that makes every prior system sound broken.
Credit what prior systems got right, then carve the specific gap you fill. A paper that respects
its lineage and names one crisp delta is more credible than one that claims to obsolete the field.
Output format
[Lanes] which venue lanes swept (SenSys/IPSN/IoTDI/MobiCom/DSP) — gaps
[Venues] citations with unverified venues — listed for dblp/ACM DL check
[Nearest] the closest prior system + the concrete, measurable delta stated
[Blind] self-citations in third person? pass/gap
[Open] the one prior system a reviewer will expect and whether it is addressed
