| name | sensys-topic-selection |
| description | Use when deciding whether a project belongs at SenSys after the 2026 merger absorbed IPSN and IoTDI — testing whether the contribution is a built, measured sensing/embedded/IoT/on-device-AI system rather than a pure algorithm, a mobile-networking mechanism, or an offline ML result, and routing misfits to MobiCom, MobiSys, or an ML/DSP venue. |
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.
- 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.
- 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.
- 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.
- 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
