📱 Chapter 13 — Mobile Cloud Computing (MCC) Cheat Sheet

Core Idea: Mobile devices are resource-constrained (battery, storage, CPU). MCC moves heavy computation and storage into the cloud, accessed over wireless — so your phone is just a smart screen, not the workhorse.

🖥️ Analogy: MCC = a dumb terminal plugged into a mainframe. The phone is the screen and keyboard; the heavy lifting happens in the cloud.

📐 Part 1 — What is MCC?

Mobile Cloud Computing (MCC) = infrastructure where both data storage and data processing happen outside of the mobile device, in the cloud — accessed over a wireless connection via a thin native client.

Why Do We Need MCC?

Mobile devices are fundamentally resource-constrained:

MCC solves this by elastically offloading compute + storage to the cloud on-demand, at low cost.

🏗️ Part 2 — MCC Architecture

Mobile Device
     ↓ (wireless)
Base Station  ←→  Mobile Network (Central Processors + Servers)
     ↓
   Internet
     ↓
Cloud Controllers  →  Cloud Services returned to user

Key Players:

• Mobile users — the end consumers
• Network operators — provide wireless connectivity
• ISPs — backbone internet access
• Data center owners / Cloud Service Providers — host the compute
• Application service providers — deploy apps on the cloud

📏 Performance can be measured via latency (round-trip time from device to cloud and back).

✅ Part 3 — Advantages of MCC

1. 🔋 Extending Battery Life

• Computation offloading = migrating heavy computation from the phone to the cloud
• Remote execution of intensive tasks = significant energy savings
• The phone just handles UI; the cloud handles the crunching

🏗️ Analogy: Like hiring a contractor for heavy construction instead of doing it yourself — your personal energy (battery) is preserved.

2. 💾 Better Storage & Processing Power

• Store and access large data in the cloud
• Mobile apps are not constrained by device storage
• Reduces cost of running computation-intensive apps on device

3. 🛡️ Reliability & Availability

• Data in cloud = no data loss if phone is lost/broken
• Cloud provides: virus scanning, malicious code detection, authentication
• Protects copyrighted digital content
• Services are always available even while moving

4. ⚡ Dynamic Provisioning

• On-demand provisioning on a fine-grained, self-service basis
• No advance reservation required

5. 📈 Scalability

• Apps can scale to meet unpredictable user demand
• Service providers can easily add and expand services

6. 🏢 Multi-tenancy

• Providers share resources and costs across many users and applications

7. 🔗 Ease of Integration

• Multiple services from different providers easily integrated via cloud + internet

📲 Part 4 — MCC Applications

📦 Mobile Commerce (M-Commerce)

• Mobile financial, advertising, shopping
• Challenges: low bandwidth, device complexity, security
• 5G + Cloud combo → increases speed and security

📚 Mobile Learning (M-Learning)

• E-learning + mobility combined
• Old limitations: expensive devices/networks, low transmission rate, limited resources
• Cloud-based M-Learning: enhanced teacher–student communication, remote resources, collaborative learning environment

🏥 Mobile Healthcare (M-Healthcare)

• Solves: small storage, security/privacy issues, medical errors in traditional care
• Cloud provides on-demand hospital services
• Examples:
  • Comprehensive health monitoring (pulse-rate, blood pressure, alcohol level)
  • Intelligent emergency management systems
  • Pervasive access to medical records
  • Lifestyle incentive management (track healthcare expenses)

🎮 Mobile Gaming (M-Gaming)

• High revenue potential
• Completely offload the game engine (e.g. graphic rendering) to cloud server
• Result: saves energy + increases play time
• MAUI = system that allows fine-grained energy-aware offloading of mobile game code
• Rendering adaptation = dynamically adjusts graphics quality based on network conditions and player demands

♿ Assistive Technologies

• Pedestrian crossing guide for visually impaired users
• Mobile currency reader for blind users
• Lecture transcription for hearing-impaired students

🌐 Other Applications

• Photo/video sharing, smart home monitoring, voice/tag/keyword search

⚠️ Part 5 — MCC Issues

📡 Mobile Communication Issues

🧮 Computation Offloading Issues

• Offloading = one of the main features of MCC
• BUT: offloading is not always effective at saving energy
• Critical decisions needed:
  • Whether to offload at all (network might be worse than local)
  • Which portions of the code to offload

Some functions cannot be offloaded (e.g. UI rendering, camera access, GPS) — they must stay on device.

Also: offloading everything sounds good in theory but comes with massive communication overhead — more data to transmit = more energy + more latency.

🔁 Part 6 — Offloading Techniques Overview

Computation Offloading = sending computation-heavy components (functions, methods, tasks) from the mobile device to a cloud server for execution, then receiving the result.

Mobile Device                         Cloud Server
┌──────────────┐    offload          ┌───────────────┐
│ methodA()    │ ──────────────────► │ methodA()     │
│ (heavy)      │ ◄────────────────── │ result        │
│              │    return result    │               │
│ methodB()    │ → stays local       └───────────────┘
│ (light/UI)   │
└──────────────┘

Two main techniques covered in this chapter: CloneCloud and Cloudlet.

🧬 Part 7 — Technique 1: CloneCloud ⚠️ Final Exam Topic!

Professor flagged this as a Final Exam topic because it's complex!

What is CloneCloud?

• Aims to improve battery life and performance by offloading intensive methods/functions to cloud servers
• Implements distributed execution inside an application-layer virtual machine
• Goal: Find the optimal partition of an application — which parts run locally, which run in the cloud

💼 Analogy: Like deciding which tasks to delegate to an assistant — first you analyze what's delegable (static analysis), track how long things take (dynamic profiling), then decide what to hand off (optimizer).

CloneCloud Mechanism

Mobile Device                     Cloud Clone (VM)
[App running]  ──── migrate ────► [Same app state cloned]
               ◄─── result ──────  [Runs intensive methods]

• Clones part of the mobile app state → sends to cloud → cloud runs the intensive portion → returns result back to device

🔬 Part 8 — CloneCloud: Static Analysis

What Static Analysis Does

• Identifies legal partitions of the application (where migration is allowed)
• Migration restricted to method entry and exit points (not in the middle of code)
• Cannot migrate: core system library methods, native method boundaries

Three Properties of Any Legal Partition

Key Concepts

• Program Analysis: control flow and data dependencies analyzed
• Partitioning Points: CPU-intensive methods marked as migration candidates
• Migration Constraints: things that block migration (e.g., needs local library, device sensor access)

Output of Static Analysis

→ A set of migration points embedded in the app where runtime can pause execution and migrate state to the cloud clone

✅ Advantages vs ❌ Limitations

📊 Part 9 — CloneCloud: Dynamic Profiling

What Dynamic Profiling Does

• Monitors the app at runtime to gather performance metrics
• Builds a cost model for local vs. remote execution
• Makes intelligent, real-time offloading decisions

What the Profiler Monitors

Profile Tree Structure

• One node per method invocation in the call tree
• Every non-leaf node has a residual node (cost of running the method body excluding subcall costs)
• Each invocation $i$ has:
  • $C_c(i, l)$ = Computation cost ($l=0$: on mobile, $l=1$: on cloud)
  • $C_s(i)$ = Migration cost (suspend + resume + transfer)

$\boxed{\text{Total Cost} = \text{Execution Time} + \text{Residual Cost} + C_c + C_s + \text{Energy Cost}}$

Execution Flow

1. Run app → collect profiles under different conditions
2. Construct cost models (local vs. remote execution)
3. Optimization engine selects best partitioning strategy in real-time

⏱️ Analogy: Like tracking total work hours (main node), subtracting time on specific tasks (a, b, c), with the remainder (main') being overhead not in any subtask.

Profile Tree → Offloading Decision

Decision Policy:

• Prefer nodes with high computation cost but low data dependency (no UI)
• Avoid nodes with frequent I/O or tight latency constraints
• Consider network conditions (low bandwidth → avoid offloading large state)

✅ Advantages vs ❌ Limitations

🔀 Part 10 — CloneCloud: Combined Hybrid Model

CloneCloud combines both for maximum effectiveness:

Static Partitioning              Dynamic Profiling
(Program Analysis)               (Runtime Monitoring)
       ↓                                ↓
 Migration Points              Cost Models + Network State
       ↓                                ↓
       └──────────► Optimization Engine ◄──────────┘
                            ↓
               Decide: offload or run locally?
                            ↓
                  Mobile Device ←→ Cloud Clone

• Static analysis = defines possible offload points (precomputed)
• Dynamic profiling = decides whether to offload at runtime based on real conditions
• Hybrid model = efficiency + adaptability

☁️ Part 11 — Technique 2: Cloudlet

Why Not Just Use the Regular Cloud?

• One-hop connection to the cloud is not efficient for latency-sensitive tasks
• Humans are sensitive to response delay — cloud WAN latency is typically 100–300 ms
• Security and firewalls worsen latency even when bandwidth improves

What is a Cloudlet?

• A micro-edition of cloud at the edge of the network — sits between mobile devices and the full cloud
• Definition: "A trusted, resource-rich computer or cluster of computers, well-connected to the Internet and available for use by nearby mobile devices"
• Contains only soft states (cache copies of data or code)
• Think: small-scale data center at the network edge

🏪 Analogy: A cloudlet = local convenience store vs. the cloud = large shopping mall. The convenience store is nearby and fast for everyday needs; the mall is for bigger requests.

Cloudlet Code Offloading

• Offload heavy computation to a nearby cloudlet server
• Uses single-hop Wi-Fi instead of long-range broadband → lower latency, lower battery use
• Latency: 10–30 ms (cloudlet via Wi-Fi) vs 100–290 ms (cloud via 3G/internet)

Key Characteristics

🏗️ Part 12 — Three-Tier Architecture for Code Offload

Tier 3: Enterprise Cloud (Central Core)
         ↕ (multi-hop network)
Tier 2: Cloudlets (Offload Elements at network edge)
         ↕ (single-hop Wi-Fi)
Tier 1: Mobile Devices

Cloudlet Host (the server)

Hosts these components:

1. Discovery Service — broadcasts cloudlet IP/port so devices can find it
2. Base VM Image — used as foundation for VM synthesis
3. Cloudlet Server — handles offload via application overlays, performs VM synthesis
4. VM Manager — manages all running guest VM instances

Mobile Client (the device)

Hosts these components:

1. Cloudlet Client App — discovers cloudlets, uploads application overlays
2. Cloudlet-Ready Apps — act as clients to code running on the cloudlet
3. Application Overlays — one per cloudlet-ready app (based on the same Base VM)

🧩 Part 13 — VM Synthesis & Overlays

The Problem with Delivering Full VMs

Sending a complete VM over wireless is too large and too slow → not practical.

Solution: Dynamic VM Synthesis

$\boxed{\text{VM Overlay} = \text{Launch VM Image} - \text{Base VM Image (compressed diff)}}$

$\boxed{\text{Complete VM} = \text{Base VM} + \text{VM Overlay}}$

• Base VM = large, static, widely-used foundation (pre-loaded at cloudlet)
• VM Overlay = small binary delta — only the customized/app-specific bits
• Transient: VM is discarded after use (or optionally cached as a residue)

🩹 Analogy: Like a software patch file — instead of re-downloading the entire OS, you just get the diff that updates what changed.

Application Overlay vs. VM Overlay

🔄 Part 14 — Dynamic VM Synthesis: Step-by-Step

Cloudlet          Mobile Device
   │                    │
   │ (pre-loaded)       │
   ├── Base VM ─────────┤
   │                    │ 1. Discover & negotiate cloudlet
   │ ◄──────────────────┤ 2. Send VM Overlay (small diff file)
   │                    │
   ├── synthesize ──────┤ 3. Base VM + Overlay → Launch VM → VM Instance
   │                    │
   │ ◄──────────────────┤ 4. Device ↔ VM interactions (actual offload work)
   │                    │
   ├── VM Residue ──────┤ 5. Create VM residue (session-specific state)
   │ ──────────────────►│ 6. Return residue to device (for future sessions)
   │                    │
   ├── Discard VM ──────┤ 7. Session ends → destroy VM (optionally cache overlay)

VM residue = session-customized state; can be folded back into the VM overlay for the next session.

⚖️ Part 15 — Cloudlet vs. Cloud

Cloudlet Key Challenges

1. Trusting the infrastructure — need tamper-resistant hardware; portable device as root of trust (e.g., TrustSniffer)
2. Finding the right software — balance between uniformity (deployer value) and specificity (end-user value)

⚡ Part 16 — Dynamo: Dynamic Task Reconfiguration

Problem

How to maintain an optimized component distribution when device power conditions change dynamically (battery draining, network getting worse)?

Solution: Source Parametric Flow Network

• Cast the distribution problem as a flow graph optimization
• Uses current residual energy at the device to make the flow graph "source parametric"

Flow Graph Variables

• $D$ = device node (source), $P$ = proxy node (sink)
• Each task $M_i$ is placed on either device or proxy to minimize total energy cost
• The optimizer re-runs as battery level changes → dynamic reconfiguration

🌐 Part 17 — MCC Ecosystem & 2-Tier Architecture

MCC Ecosystem Key Players

• Public Cloud Providers (AWS, Google Cloud, Azure)
• Wired and Wireless Network Providers
• Local and Private Cloud Providers
• Content and Service Providers
• Devices, Users, and Apps

2-Tier Cloud Architecture

Real RTT Numbers:

• Wi-Fi to local cloudlet: ~80 ms
• 3G to public cloud: ~290 ms

By IBM's prediction: 61% of enterprises would likely be on a tiered cloud model — using both local and public cloud tiers together.

Top Mobile Cloud Use Distribution:

• Mobile Music: 52.5%
• Mobile Video: 25.2%
• Mobile Gaming: 19.3%

🔐 Part 18 — MCC Security Issues

Two Main Categories

1. Security for Mobile Users
2. Securing Data on Clouds

Security for Mobile Users

Problem: Mobile devices exposed to malicious code, GPS privacy issues, resource constraints make running security software harder.

Solution 1 — CloudAV Approach (Oberheide et al.):

• Move threat detection to the cloud (AV = Anti-Vulnerability)
• Host agent runs on device → inspects file activity
• If file not in local cache of analyzed files → sent to in-cloud network service for verification
• Network service performs file verification remotely

📦 Analogy: Like sending suspicious packages to a remote inspection center rather than X-raying them with equipment you carry around.

Solution 2 — Paranoid Android (Portokalidis et al.):

• Attack detection performed on a remote server in the cloud
• Smartphone records only a minimal execution trace → transmits to security server in cloud for analysis
• Keeps device computation minimal while keeping security thorough

Privacy Issues: Location-Based Services (LBS)

Problem: LBS requires users to share their current location → privacy risk if an adversary knows this.

Solution — Location Trusted Server (LTS) (Zhangwei & Mingjun):

Mobile User → LTS → Cloaked Region → LBS Server
                         ↑
                  (hides exact location)

1. LTS collects users' location data
2. Cloaks it into a vague "cloaked region"
3. Sends the cloaked region to LBS → LBS knows only general area, cannot identify the individual

🗺️ Analogy: Like telling a delivery service you're "somewhere in downtown Bangkok" instead of your exact address — they can still serve you, but don't know precisely who or where you are.

🔭 Part 19 — Open Issues in MCC (Future Challenges)

1. Network Access Management

• Need efficient bandwidth usage and link performance
• Cognitive Radio as a solution:
  • Can automatically change transmission/reception parameters
  • Achieves spectrum agility — selects available wireless channels opportunistically
  • Integrated with MCC for better spectrum utilization

2. Quality of Service (QoS)

• Network delay is the biggest QoS challenge
• CloneCloud and Cloudlets both expected to reduce delay:
  • CloneCloud: nearby compute → increases app speed
  • Cloudlet: one-hop Wi-Fi → low latency + high bandwidth
  • Together: can overcome WAN latency limitations

3. Pricing

• MCC involves Mobile Service Provider (MSP) + Cloud Service Provider (CSP) — each with different billing models
• Need a carefully designed business model including pricing and revenue sharing between MSP and CSP

4. Standard Interface

• Interoperability is critical for device–cloud interaction
• Web interfaces are not ideal for mobile:
  • Not designed specifically for mobile
  • More overhead
  • Compatibility issues
• Needs standard protocols, signaling, and interfaces → e.g., HTML5 & CSS3

5. Service Convergence (Sky Computing)

• A single cloud may not be enough for all user demands
• Need a unified scheme to use multiple clouds together:
  • Must auto-discover and compose services for users
• Sky Computing: resources from multiple cloud providers form a large-scale distributed infrastructure
• Mobile Sky Computing: enables cross-cloud communication, allowing users to implement mobile services across providers
• Still largely unexplored — open research area

🧩 Quick Reference Summary