AMSNP: Orchestrating Adaptive Social Content Sharing in Mobile P2P Networks

TL;DR

Mobile Social Networks in Proximity (MSNP) allow users to share content directly via Bluetooth or Wi-Fi. However, mobile devices are resource-constrained and peer environments are volatile. This paper presents AMSNP, a workflow-based mediation framework that uses an Adaptive CPI (Cost-Performance Index) model to decide in real-time whether to process social tasks locally or offload them to the Cloud, ensuring optimal performance without draining device batteries.

The Challenge: Flexibility in a Moving Target

In a crowded event like a music festival or a tech conference, everyone wants to share photos and info. Relying on a central server is often impossible due to congestion, while pure P2P is too heavy for a phone's CPU when hundreds of peers connect.

The fundamental problem is Static Workflow Execution. Most apps are hardcoded: they either always use the Cloud or always stay local. In a dynamic P2P environment, this binary choice leads to either high latency (local overload) or high cost (unnecessary cloud data usage).

Methodology: The "Brain" of the Mediation Framework

The AMSNP host acts as a miniaturized Enterprise Service Bus (ESB). It treats every function—from discovery to matchmaking—as a service.

1. The Architecture

The system is composed of four layers: Proximal P2P Network, General Internet, Private Cloud, and the AMSNP Host. The Host uses a WS-BPEL engine to manage workflows.

2. The CPI Adaptation Scheme

The core innovation is the decision-making logic. For any task (T), the system evaluates different "Approaches" (A).

• Performance (p): Measured as the inverse of timespan (latency).
• Cost (E): Includes CPU usage, bandwidth, and battery impact.
• Fuzzy Logic: Since "performance" is relative, the system uses fuzzy sets to normalize these values, allowing for a "weighted" decision where users can prioritize battery life over speed.

Content Advertising: A Practical Example

Imagine PeerX wants to share a recommendation. The workflow splits into:

1. Discovery (T1): Finding peers.
2. Matchmaking: Checking if those peers are actually interested.
3. Advertising (T2): Pushing the content.

The framework can choose a Mobile-based Approach (doing matchmaking on the phone) or a Cloud-based Approach (sending metadata to many peers via a Cloud Utility service).

Experimental Insights

The researchers tested the prototype on an iPod Touch against a simulated network of up to 250 peers.

• The Threshold Effect: When peers are few (<50), the overhead of Cloud communication makes local processing faster.
• The Scale Shift: As peers cross the 150-mark, the local CPU spikes, and the CPI model automatically triggers a shift to Cloud-based matchmaking.
• User Priority: If a user increases the "weight" of Cloud Cost (e.g., they are low on data), the system stays in P2P mode longer, even if it means slower discovery.

Deep Insight & Conclusion

This work highlights a critical shift from "Mobile-First" to "Context-First" architecture. By using a SOA/ESB model on a handheld device, the authors demonstrate that mobile applications shouldn't be rigid apps, but rather dynamic choreographers of local and remote resources.

Limitations: The current prototype relies on Dropbox and CloudUtil (GAE), which introduces some centralization. Future work could explore true decentralized "Fog" computing where proximal peers share the computation load of the workflow itself.

The Takeaway: For developer and architects building for the "Edge," AMSNP provides a mathematical framework for balancing the triangle of Latency, Cost, and Battery Life.