MSCC: Harnessing Social Trust and CAN for Resilient Mobile Clouds

TL;DR

This research tackles the instability of using mobile devices as cloud servers. By leveraging the implicit trust within Social Networking Services (SNS) and the structural efficiency of Content Addressable Networks (CAN), the authors propose a scheduling framework that filters malicious actors, ensures Quality of Service (QoS) through a "Resourceability" metric, and maintains fault tolerance via smart replication.

The Core Problem: The Volatility of the Mobile Edge

Traditional cloud computing relies on stable, wired data centers. However, Mobile Social Cloud Computing (MSCC) aims to turn our smartphones and laptops into active resource providers. This creates two massive hurdles:

1. Hardware/Network Faults: Phones move, lose signal, or run out of battery mid-task.
2. User Behavior: "Free-riders" might consume services without ever contributing their own resources (Malicious behavior).

Methodology: The Four Pillars of MSCC Scheduling

The authors argue that a robust MSCC needs more than just a connection; it needs a structured logical layer. They adopt CAN (Content Addressable Network) to map mobile devices into a virtual coordinate space, making resource lookup efficient and decentralized.

1. The Reputation Matrix (Malicious Filtering)

To join the network, a device must solve a "Test Application" (matrix multiplication). If the result is incorrect or missing, the device is flagged. Reputation is not static; it is updated periodically using a weighted moving average: $reputatio{n}_{i+1}=reputatio{n}_i\ast \alpha +reputatio{n}_{i-1}\ast (1-\alpha )$

2. Social-Aware Delivery

Instead of fetching data from a distant server, the system prioritizes the closest SNS friend. This leverages real-world trust to bypass heavy authentication overhead and reduce latency.

3. "Resourceability" and QoS

Standard QoS (Time/Cost) isn't enough for mobile. The authors introduce Resourceability, a regression-based metric: $resourceability={\beta }_0+{\beta }_1(battery)+{\beta }_2(network)+{\beta }_3(performance)+ϵ$ This ensures that a phone with 5% battery isn't assigned a heavy task, even if it is geographically close.

Figure 1: The MSCC architecture showing the interaction between Cloud Servers, APs, and Social Network Groups.

Experimental Validation

Using CloudSim and BRITE for topology generation, the authors compared 12 different scenarios.

Key Findings:

• Execution Time: Filtering malicious users and using SNS group-based sharing drastically lowered execution times (Case 12).
• Reliability: Replication (maintaining a backup provider) ensured that even if a primary provider moved out of range, the service continued.
• The CAN Advantage: While CAN provides the logical "map" for routing, the scheduling logic itself (SNS + QoS) provides the performance gains.

Figure 2: Comparison of execution times across different cases. Case 12 (Full Feature) shows the most significant reduction.

Critical Insight & Conclusion

The true value of this work lies in the fusion of social trust and physical constraints. By treating "Social Relationship" as a routing optimization and "Battery Level" as a scheduling constraint, the authors move closer to a viable decentralized cloud.

Limitations: The "Test Application" for reputation consumes energy itself—a paradox for mobile devices already struggling with battery life. Future work should look into low-energy proofs of trust or blockchain-based light clients to handle reputation more efficiently.