Percom Topic Selection

---
name: percom-topic-selection
description: Use when deciding whether a pervasive-computing project belongs at IEEE PerCom or should be routed to ACM UbiComp/IMWUT, MobiCom, MobiSys, SenSys, or IPSN, and when distinguishing PerCom's human-centric ubicomp focus from networked-sensor-systems venues by contribution shape, the human-centricity test, and the IEEE-conference vs. IMWUT-journal model.
---

# PerCom Topic Selection

Decide the venue before drafting. PerCom — the IEEE International Conference on Pervasive Computing
and Communications — is IEEE's flagship for **human-centric ubiquitous computing**: activity
recognition, context-awareness, wearable and mobile sensing, and smart environments. Its papers are
IEEE Xplore proceedings read for a **pervasive-computing contribution grounded in real human use**.
A technically strong paper whose real lesson is about network protocols, low-power hardware, or a
pure ML model is respected and then rejected as out of scope.

## The routing question that matters most

PerCom overlaps most with **ACM UbiComp/IMWUT** in *topic* — both cover HAR, wearables, and smart
spaces — so the decisive question is rarely "is this ubicomp?" but **"which model and calendar fits
this paper now?"** UbiComp presents papers published in the **IMWUT journal** on **rolling
quarterly deadlines** with a revise cycle; PerCom is an **IEEE conference** with a **single annual
deadline**, a **bounded rebuttal**, and an in-person-presentation requirement. A strong ubicomp
paper is publishable at either — choose by the publication model you want and the nearer honest
deadline.

## Neighbor-venue routing table

| Signal in your project | Better home | Why |
|---|---|---|
| Human-centric ubicomp (HAR, context, wearables, smart space), ready now, PerCom deadline nearer | **IEEE PerCom** | IEEE conference flagship; annual deadline + rebuttal |
| Same topic, but you want a journal publication and a rolling deadline | **ACM UbiComp / IMWUT** | Journal model, quarterly submissions, revise cycle |
| Core is wireless/cellular networking or the mobile *network* itself | **MobiCom / MobiSys** | Mobile-networking and mobile-systems centers |
| Core is a low-power networked-sensor *system* or sensor-platform design | **SenSys** | Networked sensor systems, not human-centric ubicomp |
| Core is information processing in sensor networks / signal-level sensing | **IPSN** | Sensor-network information processing |
| Study is a deep dataset/measurement better as an archival journal article | **IMWUT / IEEE journals** | Journal length and revise cycle |

## Contribution shapes PerCom rewards

- **Human activity / context recognition** — a recognizer or model for human activity, context, or
  behavior from mobile/wearable/ambient sensors, evaluated **cross-subject** on real people (the
  EMGSense lineage).
- **Pervasive system / infrastructure** — a deployable system for sensing, localization, or smart
  environments whose insight outlives the specific hardware (the LANDMARC lineage).
- **Sensing tooling / datasets** — a generator, framework, or dataset that unblocks how the
  community evaluates (the SmartSPEC lineage).
- **Sensing consequence / privacy** — surfacing what ubiquitous sensing makes possible on real
  devices, for good or ill (the DeepMag side-channel lineage).
- **Context modeling / device-to-device** — treating context as a first-class systems concern with
  real deployment tradeoffs (the CHITCHAT lineage).

## The human-centricity and model-swap tests

Two quick tests sharpen a borderline verdict:

- **Human-centricity test:** is a *person* — their activity, context, behavior, or environment —
  the center of the contribution? If the paper is really about the network stack or the sensor
  hardware with no human at the center, route to MobiCom/MobiSys or SenSys/IPSN.
- **Model-swap test:** if the paper leans on a deep model, ask whether the pervasive-computing
  lesson survives swapping the model for another. If not, the model is the contribution and an ML
  venue fits better; PerCom rewards the ubicomp insight, not the architecture.

## Evidence maturity, without the ladder cliché

Fit is necessary but not sufficient: the same idea sits at different doors depending on evidence
maturity. A recognizer evaluated only **within-subject** or **in-lab** needs cross-subject,
free-living data before the research track; a system shown only on your own testbed needs a
realistic deployment; a study too deep and long for 9 pages may belong in IMWUT first. Submitting a
step early earns a polite "promising, but the evaluation is within-subject" and costs a full cycle,
because PerCom runs on an annual rhythm.

## Cheap reconnaissance before committing

```text
[Scope]   scan the last two PerCom programs (dblp, percom.org) for your subarea
          -> 3+ recent papers = a reviewer pool exists; 0 = opening or mismatch
[Citations] is your bibliography majority ubicomp/mobile/sensing venues (PerCom/UbiComp/IMWUT/
          MobiCom/SenSys)? -> majority non-ubicomp => reviewers read you as a visitor; naturalize first
[Calendar] compare the next PerCom deadline (annual, ~Sep) with IMWUT's rolling quarterly cutoffs
          and MobiCom/SenSys dates -> route to the nearest honest fit, not a year's wait
```

## Decision procedure

```text
[Audience] who acts differently if the claim holds? -> ubicomp researchers/practitioners/users?
[Claim type] recognition / system / tooling-dataset / sensing-consequence / context-modeling
[Human-centricity] is a person at the center? -> yes: PerCom-family; no: MobiCom/SenSys/IPSN
[PerCom vs IMWUT] both fit? -> conference+rebuttal+annual (PerCom) vs journal+rolling (IMWUT)
[Verdict] PerCom research track / neighbor venue / journal-first, with a one-line reason
```

Run this before the writing skills; a wrong venue decision wastes every later step. When the
verdict is PerCom, continue with `percom-workflow` for the calendar and `percom-writing-style` for
the paper shape.