Scaling the Crowd: Leveraging Future Internet Architecture for Mobile Crowdsourcing

Future Internet and Scalability Techniques in Mobile Crowdsourcing

2018-09-19
Peron Rezende de Sousa, Marcos Lage, Antônio Augusto de Aragão Rocha
Summary
Problem
Method
Results
Takeaways
Abstract

This paper proposes a scalable architecture for Mobile Crowdsourcing (MCS) by integrating Future Internet components, specifically the MobilityFirst Global Name Service (Auspice) and Google Firebase. It introduces a multifaceted incentive mechanism combining gamification, reputation services, and network marketing to ensure system longevity and worker motivation.

TL;DR

Mobile Crowdsourcing (MCS) is often hampered by the scalability limits of central servers and the high costs of cloud infrastructure. This paper introduces a hybrid architecture using MobilityFirst’s GNS for discovery and Firebase for delivery, alongside a novel UDP Mirror technique for direct device communication. The result is a system capable of handling 1,500+ concurrent requests—matching the scale of industry giants—while maintaining low operational overhead.

The Scalability Bottleneck in MCS

Most MCS platforms rely on a traditional client-server model. While functional for small groups, this model fails when thousands of users move, update their GPS locations, and request tasks simultaneously. Prior works tried load balancing or "Edge Computing," but these often lead to technical complexity or high financial costs. The authors argue that the "Future Internet" (specifically the MobilityFirst architecture) should handle the heavy lifting of naming and addressing, leaving the application layer to focus on task logic.

Methodology: Decoupling Discovery and Delivery

The proposed architecture splits the MCS lifecycle into five distinct phases:

  1. User Registration & Context: Utilizing the Global Name Service (GNS), or "Auspice," to assign unique GUIDs and track worker context (e.g., location, status).
  2. Contextual Search: Requesters query the GNS for workers within a specific radius and context (e.g., "Find all taxi drivers within 1km").
  3. Decentralized Allocation: The requester's frontend handles task assignment, reducing the central server's load.
  4. Cloud-Agnostic Delivery: While Firebase is used for basic notification (Push), the authors propose a UDP Mirror service. This allows workers to send data directly to requesters, bypassing the cloud to save on data transfer fees.

System Architecture and Data Flow Figure 1: The flow from user selection to direct data collection via the proposed UDP Mirror technique.

A Novel Incentive Engine: Gamification & Network Marketing

To keep the "crowd" active, the paper introduces a Reputation Service (SR) built on:

  • Mean Opinion Score (MOS): Workers are rated 1–5.
  • Staking Mechanism: Workers "bet" reputation points to gain high-value tasks. A high MOS doubles the points; a low MOS wipes them out.
  • Network Marketing (Multi-Level): To solve the "cold start" problem for new users, veterans can invite friends. When a recruit earns points, the recruiter (and those up to 6 levels above) earns a percentage of "reputation dividends," encouraging rapid community growth.

Experimental Results: Java vs. Node.js

The authors stressed-tested their Reputation Service with up to 1,500 simultaneous requesters. A key technical insight was the comparison between Java (Multithreaded) and Node.js (Single-threaded Event Loop):

  • Java: Suffered from "Garbage Collection" (GC) spikes. Under high load, the memory wasn't cleared fast enough, leading to "negative responses" and latency.
  • Node.js: Remained stable and efficient. Most requests were processed in under 1.5 seconds, even at peak load.

Performance Comparison Figure 2: Response times and throughput analysis, showing Node.js outperforming the Java-based socket implementation in high-concurrency scenarios.

Critical Analysis & Conclusion

The core value of this work is its pragmatism. Instead of building a massive backend, the authors "borrow" scalability from the Future Internet (GNS) and current cloud giants (Firebase).

Key Takeaways:

  • Direct D2D is Possible: By using a UDP Mirror, developers can create truly peer-to-peer data transfers to avoid cloud egress costs.
  • Incentives are Social: Applying network marketing principles to reputation (rather than money) effectively scales the workforce without creating "pyramid scheme" financial risks.
  • Architecture Matters: For high-concurrency MCS, event-driven architectures (like Node.js) are strictly superior to traditional multithreaded blocking architectures.

While the GNS isn't yet in full commercial use, this paper provides a robust roadmap for how mobile services will scale when the "Future Internet" finally arrives.

Find Similar Papers

Try Our Examples

  • Search for recent papers that utilize the MobilityFirst Global Name Service (GNS) for context-aware service discovery in mobile ad-hoc networks.
  • Which study first introduced the formal concept of Mobile Crowdsourcing (MCS) and how do decentralized architectures like the one in this paper differ from that original paradigm?
  • Explore how gamification and multi-level marketing (MLM) structures are being applied to improve user retention in blockchain-based decentralized crowdsourcing (DeCrowd) platforms.
Contents
Scaling the Crowd: Leveraging Future Internet Architecture for Mobile Crowdsourcing
1. TL;DR
2. The Scalability Bottleneck in MCS
3. Methodology: Decoupling Discovery and Delivery
4. A Novel Incentive Engine: Gamification & Network Marketing
5. Experimental Results: Java vs. Node.js
6. Critical Analysis & Conclusion