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.
2. 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.
3. 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.
4. 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

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