mobisys-topic-selection

name	mobisys-topic-selection
description	Use when deciding whether a project belongs at MobiSys — testing whether the core contribution is a mobile or embedded system, application, or service whose on-device behavior is the result, and routing wireless, sensor-network, distributed-systems, ubicomp, or early-idea misfits to MobiCom, SenSys, NSDI/OSDI, IMWUT, or HotMobile.

MobiSys Topic Selection

MobiSys is the ACM SIGMOBILE venue for mobile systems, applications, and services — the system that runs on the device, not the radio underneath it. The fastest way to waste a year-long cycle is to submit a paper whose real contribution belongs one venue over. This skill is a fit and routing tool, not a substitute for the current CFP scope list.

The fit test

A MobiSys-shaped paper answers all four:

1. Is the contribution a mobile or embedded system? A runtime, an OS/platform mechanism, an on-device inference engine, a sensing pipeline, an offload scheduler, a mobile application or service — something built and run on the device, not an algorithm evaluated in the abstract.
2. Does the device constraint shape the result? If compute, energy, latency, memory, or thermal budget could be idealized away with no loss, the contribution is probably not MobiSys's.
3. Is there on-device evidence, or a credible plan for it? MobiSys expects real phones, wearables, or embedded boards; a simulation-only story is a fit risk (mobisys-experiments).
4. Would MobiSys's systems-and-services reviewers be the right audience? Say why in one sentence using the venue's vocabulary, not "it is a top conference."

Routing map

Route by contribution type, not prestige. The nearest siblings and what pulls a paper to each:

Signal in the contribution	Better-fit venue
Wireless/PHY-MAC mechanism, protocol, or RF sensing as the core	ACM MobiCom
Sensor-network / embedded-sensing infrastructure at large	ACM SenSys
Data-center, cloud, or distributed-systems design and implementation	USENIX NSDI / OSDI
Operating-system generality beyond mobile	USENIX OSDI / ACM SOSP
Ubiquitous-computing / on-body inference as the finding	ACM IMWUT (UbiComp)
Security or privacy of mobile as the central claim	a security venue
Early idea without a full on-device evaluation	HotMobile or a workshop

The MobiSys↔MobiCom line is the one authors get wrong most: a wireless mechanism is MobiCom; an end-to-end mobile system whose device behavior is the point is MobiSys. The MobiSys↔SenSys line is the second: a sensing infrastructure is SenSys; a mobile platform, app, or service built on sensing is MobiSys. When two are present, decide which is the contribution and which is the vehicle.

Contribution-type honesty

Name the contribution before choosing the venue:

[Contribution type] mobile runtime / OS-platform mechanism / on-device ML system /
                    sensing service / offload scheduler / mobile app-service / other
[Device dependence] does the result change if compute/energy/latency is idealized? y/n
[Evidence form] real-device measurement / deployment / user study / trace / simulation-only
[Primary audience] the MobiSys sub-community that should review it

If the type is "on-device ML system," MobiSys rewards a resource-management or runtime contribution (scheduling, approximation, placement, thermal control), not a better model — a new architecture with mobile motivation routes to a machine-learning venue. If it is "sensing service," the mobile system and its on-device budget must be the contribution, not just the sensor.

Common misfit patterns

• The better-model paper. A more accurate network that happens to run on a phone; the system is incidental → a machine-learning venue, unless the runtime is the contribution.
• The wireless paper wearing a systems hat. A link/PHY result with a phone demo → MobiCom.
• The sensor-network paper. A multi-node embedded-sensing infrastructure → SenSys.
• The simulation-only system. A scheduler or runtime evaluated only in a simulator; strong ones still need on-device measurement to clear the bar.
• The distributed-systems paper with a mobile example. A cloud/back-end contribution with a mobile motivating scenario → NSDI/OSDI.

Re-routing decision

If the paper misses MobiSys's bar, do not force it into the December deadline — re-route by type and record why. A wireless mechanism goes to MobiCom, a sensing infrastructure to SenSys, a distributed-systems design to NSDI/OSDI, a ubicomp finding to IMWUT, an early idea to HotMobile. Because MobiSys runs one deadline a year, a misfit costs a full cycle, and the two-round review often surfaces it as an early reject after round 1 rather than a rescue — re-routing early is by far the cheaper move.

Output format

[Fit] High / Medium / Low (one-line reason in MobiSys's vocabulary)
[Contribution type] <named>
[Device dependence] result depends on compute/energy/latency/memory? y/n
[Evidence form] real-device / deployment / user study / trace / simulation-only
[Main gap] the single most important missing system mechanism or measurement
[Re-route] <sibling venue if not a fit, with the signal that sends it there>