mobisys-topic-selection

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.

1. 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.

1. 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).

1. 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>