sensys-related-work

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

1. 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