IPSN Topic Selection

Decide two things before drafting: which track and which venue. IPSN — the ACM/IEEE
International Conference on Information Processing in Sensor Networks — split its research papers into
the Information Processing (IP) track and the **Sensor Platforms, Tools and Design Methods
(SPOTS) track, and it lived inside CPS-IoT Week**. As of 2026-07-09 IPSN no longer runs
standalone — it merged into SenSys (Embedded AI and Sensing Systems) — but the IP-vs-SPOTS
instinct still decides how your paper is read and where its evidence bar sits, so keep it.

First decision: IP track or SPOTS track

This is the choice with no sibling analogue. Get it wrong and your platform paper is judged by
theory reviewers, or your estimator is judged by hardware reviewers.

Rule of thumb from IPSN's own wording: **analysis and processing of collected data → IP;
hardware/software platforms and tools used to collect it → SPOTS.** A paper with both a new
estimator and a new board picks the track matching its primary claim and treats the other as
support.

Second decision: is this the IPSN lineage at all?

IPSN rewards work where information processing meets physical sensing. A pure ML result with a
sensing dataset, or a pure networking result, is respected and then rerouted.

The merger reality (do not skip)

IPSN's last standalone edition was IPSN 2024 (23rd, Hong Kong). From 2025 it merged with SenSys
and IoTDI; the live venue is SenSys — Embedded AI and Sensing Systems, still at CPS-IoT Week.
Practical consequences:

• "Submit to IPSN" now means submit to SenSys with an IP-track or SPOTS-track style of

contribution. Confirm on the current SenSys call whether it keeps an explicit track split or folds
it into one technical track with categories (待核实).

• Do not send authors to an archived ipsn.acm.org/2026 — no such standalone conference exists.

The model-swap and platform-swap tests

• Model-swap test (IP track): if your paper leans on a specific learner/model, ask whether the

sensing lesson survives swapping it. If not, the model is the contribution and an ML venue fits
better; if yes, it is an IP-track sensing result.

• Platform-swap test (SPOTS track): would your platform/tool contribution still matter on a

different application? If it only helps your one demo, it is an application paper, not a SPOTS
contribution.

Evidence maturity, without the ladder cliché

Fit is necessary but not sufficient. An estimator with a bound but no real-sensor evaluation is a
theory note; a board with a datasheet but no measured power/robustness story is an engineering
report; a deployment with no ground truth is an anecdote. IPSN wants the information-processing claim
and the physical measurement that makes it real.

Cheap reconnaissance before committing

[Scope]   scan recent IPSN (dblp, ACM DL/IEEE Xplore) and the latest SenSys program for your subarea
          -> 3+ recent papers = a reviewer pool exists; 0 = mismatch or reroute
[Track]   is your novelty in the method (IP) or the platform/tools/deployment (SPOTS)?
[Citations] is your bibliography majority sensing venues (IPSN/SenSys/MobiCom/INFOCOM + SP)?
          -> majority pure-ML or pure-networking => reviewers read you as a visitor; reframe first
[Calendar] the live target is the next SenSys edition at CPS-IoT Week -> confirm its deadline

Decision procedure

[Who acts] who changes behavior if the claim holds? sensor-system builders / deployers / SP researchers?
[Claim type] estimator/inference (IP) / platform/tool/deployment (SPOTS)
[Track] IP vs SPOTS, chosen by where the primary novelty lives
[Venue] IPSN-lineage (SenSys) / RTAS / HSCC-ICCPS / MobiSys-MobiCom / INFOCOM / SP journal
[Verdict] track + venue, with a one-line reason and the live successor deadline to confirm

Run this before the writing skills; a wrong track or venue wastes every later step. When the verdict
is the IPSN lineage, continue with ipsn-workflow for the CPS-IoT Week calendar and
ipsn-writing-style for the paper shape.