CROWDio: A Practical Mobile Crowd Computing Framework with Developer-Oriented Design, Adaptive Scheduling, and Fault Resilience arXiv:2604.19363v1 [cs.DC] 21 Apr 2026
Lakshani Manamperi∗
Disumi Pathirana∗ Nipun Premarathna∗ Thiwanka Pathirana∗ Kutila Gunasekara† ∗ Undergraduate Student
† Supervisor
Department of Computer Science & Engineering University of Moratuwa, Sri Lanka [email protected]
Abstract Mobile Crowd Computing (MCdC) leverages the idle computational capacity of consumer smartphones to enable distributed task processing at scale; however, widespread real-world adoption remains constrained by the absence of developer-oriented frameworks capable of transparently managing device heterogeneity, fault tolerance, and connectivity volatility. This paper introduces CROWDio, a centralized MCdC platform comprising three tightly integrated subsystems: (i) a declarative SDK that abstracts distributed execution to a single function annotation, eliminating the need for explicit parallelism management; (ii) a tiered checkpointing mechanism that enables fault-tolerant task resumption under the memory and execution constraints inherent to mobile runtimes; and (iii) a pluggable multi-criteria scheduling framework driven by continuous live device telemetry, supporting interchangeable decision strategies without modification to the dispatch core. Empirical evaluation across six heterogeneous Android devices spanning CPU-bound, AI/NLP inference, and data-parallel workloads demonstrates that capability-aware adaptive scheduling reduces total execution time by up to 56.9% relative to naı̈ve round-robin dispatch, while the checkpointing subsystem incurs a bounded overhead of only 2–3 s per task regardless of checkpoint frequency. A systemwide Jain’s Fairness Index of 0.889 confirms equitable and stable workload distribution across heterogeneous worker devices.
Keywords: Mobile Crowd Computing, Distributed Systems, Task Scheduling, Fault Tolerance, Checkpointing, Mobile Devices, MCDM, Developer Frameworks
1
1
Introduction
Contemporary smartphones routinely operate well below their peak computational capacity, presenting an opportunity for Mobile Crowd Computing (MCdC) to aggregate idle resources into a collective execution platform [1]. Unlike cloud-centric paradigms, MCdC reduces latency and centralised infrastructure dependency [2]. Early systems Hyrax [3], Misco [4], Honeybee [5] proved the feasibility of smartphone-based distributed computation, but remained research prototypes without production-grade developer tooling [6]. The primary barrier to adoption is a software engineering problem: the absence of frameworks that abstract scheduling, fault tolerance, and device heterogeneity from the developer. CROWDio addresses this gap with a production-quality SDK and empirically validated scheduling and checkpointing subsystems. Contributions: (1) A tiered checkpointing scheme enabling fault-tolerant task resumption within constrained mobile runtimes, with bounded and predictable overhead. (2) A pluggable multi-criteria decision-making (MCDM) scheduling architecture driven by live device telemetry, integrating FIFO, WRR, EDAS, ARAS, and MABAC strategies. (3) A modular software architecture following separation-of-concerns and pluggable strategy patterns that hides coordination complexity from the developer. (4) Empirical evaluation on a six-device heterogeneous cluster demonstrating up to 56.9% scheduling improvement and bounded checkpointing overhead.
2
Related Work
Hyrax and Misco demonstrated MapReduce on smartphone clusters; Honeybee introduced work-stealing for dynamic load balancing. All remained research prototypes without developer SDKs [1, 6]. The broader landscape of mobile cloud computing including computation offloading, resource constraints, and P2P ad hoc cloud architectures is surveyed comprehensively by Fernando et al. [7], who identify the absence of developer-facing abstractions as a persistent gap. Similarly, Ray et al. [8] survey crowdsensing and crowdsourcing strategies for smart mobile devices, distinguishing task-offloading paradigms from crowd-computing approaches that aggregate peer device capacity. Volunteer computing systems such as BOINC [9] address device heterogeneity, unreliability, and churn at scale, primarily targeting desktop platforms; their scheduling policies (resource scheduling, work fetch, job selection) informed the design of CROWDio’s pluggable dispatch architecture. A recent P2P volunteer computing framework [10] proposes global scheduling based on observed per-device performance, highlighting the importance of capability-aware dispatch a concern CROWDio addresses via live telemetry-driven MCDM. MCDM-based worker selection for heterogeneous MCdC clusters was introduced by Pramanik et al. [11], with Shannon entropy weighting [12] assigned to device capability criteria. The challenge of scheduling across heterogeneous edge and mobile resources has also been studied in broader distributed computing contexts: Stan et al. [13] systematically 2
evaluate scheduling algorithms in hybrid edge–cloud environments comprising smartphone and Raspberry Pi nodes, finding that conventional policies suffer significant performance degradation on low-capacity edge resources motivating the MCDM approach taken by CROWDio. Cloud-oriented distributed frameworks apply clean developer abstractions [14, 15] but are unsuited to mobile runtime constraints and volatile connectivity. CROWDio applies their design philosophy to MCdC: Table 1 positions it against prior work. Table 1: Comparison of CROWDio with related systems. System Target Scheduling Checkpointing SDK Hyrax/Misco Phones MapReduce None Honeybee Mobile Work-steal None BOINC Desktop Static App-level Cloud Frameworks Cloud DAG/Graph Lineage CROWDio Mobile MCDM Tiered
3
System Architecture
3.1
Overview
No No Partial Yes Yes
CROWDio follows a Coordinator–Worker master-worker pattern across three layers: (1) the Developer SDK, (2) the central Coordinator (control plane), and (3) distributed mobile Workers (execution plane). All layers communicate via persistent, low-latency event-driven connections [16]. Figure 1 shows the high-level architecture. Design principles. Each Coordinator component carries a single responsibility (modularity); the scheduling subsystem uses a Strategy pattern (extensibility); all coordination complexity is hidden from the developer (abstraction); workers are stateless execution agents with durable state owned solely by the Coordinator (fault isolation).
3.2
Developer SDK
The SDK enables distributed execution through a minimal interface, requiring only a single function annotation to transform sequential code into a distributed workload. Parallel operations such as data-parallel map are dispatched and aggregated transparently. Fault tolerance checkpointing and automatic retries, is declared alongside the annotation rather than implemented by hand, reducing the cognitive overhead of distributed programming to that of a standard cloud function service.
3.3
Scheduling
Worker devices are not interchangeable: a high-end device at low load is categorically more capable than a low-end device near saturation. Naı̈ve dispatch ignores this, causing systematic 3
Figure 1: CROWDio high-level architecture. The Coordinator manages job decomposition, scheduling, and result aggregation. Workers execute tasks on mobile devices; all durable state is persisted centrally. head-of-line blocking. CROWDio instead employs a pluggable scheduling architecture driven by live device telemetry (CPU utilisation, available memory, battery level, network latency, and thermal state). MCDM strategies construct a decision matrix over all connected workers and observable criteria. Shannon entropy weighting [12] assigns criterion weights that reflect inter-device variability rather than subjective preferences: 1 − Ej , k (1 − Ek )
wj = P
Ej = −
1 X pij ln pij ln m i
(1)
P where pij = xij / i xij and m is the number of workers. Each pluggable strategy (EDAS, ARAS, MABAC, WRR) ranks workers according to its own decision logic; the highest-ranked available worker receives the next task. New strategies can be registered without modifying the core dispatch loop.
4
3.4
Fault Tolerance and Checkpointing
Tiered checkpoint model. CROWDio uses three checkpoint tiers to balance recovery fidelity against overhead. Base checkpoints are complete state snapshots. Delta checkpoints persist only variables that changed since the last snapshot, minimising transfer and storage cost. Compacted checkpoints periodically consolidate the delta chain (default threshold k = 50), bounding recovery replay complexity to O(k). Code instrumentation. Because standard runtime tracing facilities are unavailable in constrained mobile execution environments, CROWDio instruments user-supplied task functions at the source-code representation level before deployment. Instrumentation: (i) injects checkpoint variable recovery at function entry; (ii) adjusts loop ranges to skip already-completed iterations on resumption; (iii) inserts state-persistence calls after each mutation; and (iv) wraps execution in a thread-safe checkpoint state manager. The transformation is fully transparent to the developer. Graceful reconnection. On worker failure, in-progress tasks are transparently resumed on an alternative worker from the last validated checkpoint. If the original worker reconnects, it is re-registered immediately; task ownership is managed atomically by the Coordinator to prevent duplicate execution. Figure 2 illustrates the lifecycle.
4
Empirical Evaluation
4.1
Experimental Setup
Six Android devices (Table 2) were used as workers, intentionally selected for heterogeneity in clock speed and memory. Each configuration was repeated ten times; results are reported as mean ± SD.
Device
Table 2: Android worker devices. Cores Frequency
Samsung Galaxy A34 Samsung Galaxy A32 Samsung Galaxy A51 Motorola E40 Samsung Galaxy S6 Lite Samsung Galaxy A9+
8 8 8 8 8 8
2.00 GHz 1.80 GHz 1.74 GHz 1.82 GHz 2.00 GHz 1.80 GHz
RAM 7.3 GB 5.5 GB 7.4 GB 3.4 GB 3.6 GB 3.3 GB
Three workloads were evaluated: (1) Monte Carlo estimation of Euler’s number e at 1M–100M iterations (CPU-intensive scalability benchmark); (2) Sentiment Analysis on a help-desk ticket corpus [17] across five workers (AI/NLP inference); (3) Tile-based Image Processing on 6,862 images [18] (data-parallel, coordination-overhead sensitivity).
5
Figure 2: Worker disconnection and graceful reconnection lifecycle. Tasks resume on alternative workers from the last checkpoint; reconnecting workers re-register with no developer intervention.
4.2
CROWDio vs. Single-Device Execution
Table 3 shows that CROWDio’s advantage grows with workload size, achieving 5.1× speedup over the best single device at 100 M trials. Framework coordination overhead is approximately 0.3–0.5 s per job negligible at scale. Figure 3 visualises the widening performance gap.
4.3
Scheduling Algorithm Comparison
Table 4 compares WRR against FIFO for Monte Carlo. At 100 M trials, WRR achieves a 56.9% reduction (48.9 s vs. 113.4 s) as FIFO suffers severe head-of-line blocking on weaker devices. Low standard deviations (σ/µ < 2%) confirm reproducibility across runs.
4.4
Checkpointing Overhead
Table 5 shows a consistent 2–3 s overhead regardless of checkpoint interval frequency, attributable to state serialisation, delta computation, compression, and network transmission. The 5-second interval provides the best balance between recovery granularity and performance 6
Table 3: Single-device vs. CROWDio WRR execution time for Monte Carlo (mean ± SD, n=10, checkpointing disabled). Trials
Best (s)
Worst (s)
CROWDio (s)
1M 10M 100M
2.06 ± 0.04 3.12 ± 0.05 1.20 ± 0.05 19.2 ± 0.28 29.7 ± 0.43 6.13 ± 0.09 192 ± 2.82 297 ± 4.36 37.9 ± 0.52
Speedup ×1.7 ×3.1 ×5.1
Figure 3: Execution time: best device, worst device, and CROWDio WRR across six workers. The advantage grows with scale (5.1× at 100 M trials). Checkpointing disabled. cost. Coordination-overhead caveat. Distributed image processing on five workers took substantially longer than single-device execution due to small per-task batch sizes. When per-task computation time is comparable to coordination overhead, distribution yields no benefit analogous to Amdahl’s Law. The ratio of per-task computation to coordination cost must exceed approximately an order of magnitude for distribution to be advantageous.
4.5
Fairness
Jain’s Fairness Index J = 0.889 (σ < 0.01) was consistently observed across all configurations, confirming stable and reproducible load distribution despite significant device heterogeneity.
7
Table 4: FIFO vs. WRR execution time (mean ± SD, n=10). Trials
Single (s)
FIFO (s)
WRR (s)
Improvement
1M 10M 100M
2.06 ± 0.04 2.0 ± 0.06 1.2 ± 0.05 40.0% 6.13 ± 0.09 6.2 ± 0.11 5.5 ± 0.10 11.3% 37.9 ± 0.52 113 ± 2.10 48.9 ± 0.89 56.9%
Table 5: Checkpoint frequency vs. execution time (1 M trials, mean ± SD, n=10).
5
Mode
Time (s)
Overhead
Disabled Enabled (5 s) Enabled (2 s) Enabled (0.5 s)
2.06 ± 0.04 — 4.14 ± 0.08 +2.08 s 4.90 ± 0.09 +2.84 s 4.94 ± 0.10 +2.88 s
Discussion and Limitations
CROWDio demonstrates that applying established software engineering principles to MCdC yields a platform that is simultaneously more developer-accessible and more maintainable than prior research prototypes. The single-annotation interface reduces the cognitive overhead of mobile distributed computing to a level comparable to a cloud function service. The 56.9% scheduling improvement confirms that capability-aware dispatch is essential for heterogeneous mobile clusters: naı̈ve assignment leads to systematic bottlenecking at scale. The consistent 2–3 s checkpoint overhead is well justified in mobile environments where disconnection and battery depletion are routine events. Limitations. The six-device cluster may not capture emergent dynamics at 20–100 devices. The controlled laboratory setting does not replicate mobility, user interruption, or voluntary participation patterns. Comparative evaluation of EDAS, ARAS, and MABAC versus WRR at scale remains future work, as does energy consumption measurement.
6
Conclusion
CROWDio bridges the gap between theoretical MCdC research and practical deployment by combining a declarative developer SDK, pluggable MCDM scheduling, and tiered checkpointing in a single mobile-native platform. Empirical evaluation demonstrates linear scalability, 56.9% scheduling improvement over naı̈ve dispatch, bounded 2–3 s checkpointing overhead, and consistent task distribution fairness all critical for production MCdC deployment. Future work will focus on enabling efficient multi-stage deep neural network inference via pipeline scheduling in mobile crowd computing environments, extending CROWDio beyond general-purpose computation toward collaborative, scalable AI inference across mobile devices.
8
References [1] P.K.D. Pramanik, S. Pal, and P. Choudhury. Mobile crowd computing: potential, architecture, requirements, challenges, and applications. Journal of Supercomputing, 80(2), 2024. https://doi.org/10.1007/s11227-023-05545-0 [2] P.K.D. Pramanik. Sustainable computing with mobile crowd computing. Technical Report, NIT Durgapur, 2023. [3] E.E. Marinelli. Hyrax: Cloud computing on mobile devices using MapReduce. Technical Report CMU-CS-09-164, Carnegie Mellon University, 2009. [4] A. Dou et al. Misco: A MapReduce framework for mobile systems. In Proceedings of PETRA 2010. ACM, 2010. [5] N. Fernando, S.W. Loke, and W. Rahayu. Honeybee: A programming framework for mobile crowd computing. In MobiQuitous 2012, Lecture Notes of the Institute for Computer Sciences, Social Informatics and Telecommunications Engineering, vol. 120. Springer, 2013. [6] T.B. Kiridana et al. Mobile crowd computing with mobile agents and work stealing. In Proceedings of MERCon 2024. IEEE, 2024. [7] N. Fernando, S.W. Loke, and W. Rahayu. Mobile cloud computing: A survey. Future Generation Computer Systems, 29(1):84–106, 2013. https://doi.org/10.1016/j. future.2012.05.023 [8] A. Ray, C. Chowdhury, S. Bhattacharya, and S. Roy. A survey of mobile crowdsensing and crowdsourcing strategies for smart mobile device users. CCF Transactions on Pervasive Computing and Interaction, 5:98–123, 2023. https://doi.org/10.1007/ s42486-022-00110-9 [9] D.P. Anderson. BOINC: A platform for volunteer computing. Journal of Grid Computing, 18(1):99–122, 2020. https://doi.org/10.1007/s10723-019-09497-9 [10] E. Saleh and C. Shastry. A new approach for global task scheduling in volunteer computing systems. International Journal of Information Technology, 2022. https: //doi.org/10.1007/s41870-022-01090-w [11] P.K.D. Pramanik et al. A comparative analysis of MCDM methods for resource selection in MCC. Symmetry, 13(9):1713, 2021. [12] C.E. Shannon. A mathematical theory of communication. Bell System Technical Journal, 27(3):379–423, 1948. [13] R. Stan, C. Copil, D. Moldovan, and H.-L. Truong. Evaluation of task scheduling algorithms in heterogeneous computing environments. Sensors, 21(18):6035, 2021. https: //doi.org/10.3390/s21186035
9
[14] P. Moritz et al. Ray: A distributed framework for emerging AI applications. In Proceedings of USENIX OSDI, pages 561–577, 2018. [15] M. Zaharia et al. Apache Spark: A unified engine for big data processing. Communications of the ACM, 59(11):56–65, 2016. [16] I. Fette and A. Melnikov. The WebSocket protocol (RFC 6455). IETF, 2011. https: //doi.org/10.17487/RFC6455 [17] M. Abdellatif. Help desk tickets. Mendeley Data V2, 2025. https://doi.org/10.17632/ btm76zndnt.2 [18] J. Bhathena. Weather image recognition dataset. Kaggle, n.d. [19] M. Keshavarz Ghorabaee et al. Multi-criteria inventory classification using EDAS. Informatica, 26(3):435–451, 2017. [20] E.K. Zavadskas and Z. Turskis. A new ARAS method in multicriteria decision-making. Technological and Economic Development of Economy, 16(2):159–172, 2010. [21] D. Pamucar and G. Cirovic. The selection of transport resources using MABAC. Expert Systems with Applications, 42(6):3016–3028, 2015.
10