sensys-topic-selection

SenSys Topic Selection

SenSys accepts a system you built and measured under embedded constraints. The 2026 merger

of SenSys, IPSN, and IoTDI widened the mandate — low-power networked sensing, embedded systems,

IoT, and on-device AI now share one venue — but it did not soften the systems bar: a strong

SenSys paper still has a buildable mechanism whose value is shown in **energy, latency,

memory, and deployment behavior on real hardware**, not in a proof or a leaderboard delta.

The fit test

Ask these in order; a "no" is a routing signal, not a verdict on the work's quality.

1. Is there a system? Can you point to the artifact — firmware, a node, a protocol, a

deployment — that embodies the contribution? A pure algorithm with no embedded realization

is a signal-processing or ML contribution.

1. Do embedded constraints bind? Does energy, memory, compute, bandwidth, or intermittent

power actually shape the design? If the method would run unchanged on a workstation, the

constraint is not doing work and SenSys is a weak fit.

1. Is the evidence physical? Are the headline numbers measured on hardware — current

draw, duty cycle, on-device latency, deployment uptime — or are they simulation/offline

accuracy? SenSys reviewers discount simulation-only and single-run results.

1. Is sensing or embedded computation central? SenSys is about turning **physical signals

into information under resource limits**, or computing on constrained nodes — not about the

wireless link itself (that is MobiCom) or the mobile application platform (that is MobiSys).

Routing table

| If the core contribution is... | The likely home is... | Because |

|---|---|---|

| A built sensing system measured on real hardware for energy/latency/accuracy | SenSys | The merged venue's center of mass |

| Low-power networked sensing / mote-class protocols (formerly IPSN) | SenSys (post-merger) | IPSN's community joined SenSys in 2026 |

| IoT design/implementation, edge deployments (formerly IoTDI) | SenSys (post-merger) | IoTDI's community joined SenSys in 2026 |

| An on-device / TinyML model with measured footprint on an MCU | SenSys | Embedded-AI systems are in-scope after the merger |

| A wireless link, PHY/MAC, or over-the-air networking mechanism | MobiCom | The mechanism is the radio, not the sensing system |

| A mobile-platform / smartphone systems contribution | MobiSys | The platform, not embedded sensing under energy limits |

| A new estimator/algorithm with no embedded realization | an ML or DSP venue | The contribution is the math, not a built system |

| A datacenter/OS/networking systems result | NSDI / OSDI / SIGCOMM | Not sensing/embedded and not energy-bound |

Post-merger boundary calls

The merger creates new adjacencies to reason about explicitly:

• On-device AI vs. an ML paper. If the novelty is model architecture or accuracy, it is an

ML venue. If the novelty is running inference within a real MCU's RAM/flash/energy budget

— quantization-for-hardware, intermittent-power inference, on-sensor compute — it is SenSys.

• IoT deployment vs. an applications paper. A deployment is SenSys when the **system design

or measurement methodology** is the contribution, not merely that a known stack was installed.

• Sensing vs. signal processing. A new algorithm belongs at a DSP venue unless it is

embodied and measured on the constrained node where it must actually run.

Fit self-check (answer before choosing SenSys):
[ ] There is a concrete built system/artifact, not only a method.
[ ] An embedded constraint (energy/memory/compute/power) shapes the design.
[ ] Headline numbers are measured on real hardware, not simulation-only.
[ ] Sensing or on-node computation — not the radio or the app platform — is central.
[ ] If on-device AI: the claim is measured footprint/latency, not offline accuracy.

When two venues both fit

Some work genuinely spans SenSys and MobiCom (e.g. a sensing system that also innovates on its

link). Route by where the reviewable novelty lives: if a reviewer would spend most of their

judgment on the sensing/embedded system and its energy behavior, submit to SenSys and treat the

link as engineering; if the defensible novelty is the wireless mechanism, submit to MobiCom.

Pick one — a paper straddling both usually reads as under-contributing to each.

Output format

[Verdict]  SenSys fit: strong / plausible / weak
[System]   the concrete artifact that embodies the contribution
[Constraint] which embedded limit binds the design (energy/memory/compute/power)
[Evidence] hardware-measured? or simulation/offline (a re-route risk)
[Reroute]  if weak — target venue + the one sentence that would move it
[Open]     any post-merger boundary ambiguity to resolve before committing