51  Edge Cyber-Foraging & Caching

In 60 Seconds

Cyber-foraging enables resource-constrained mobile devices to opportunistically discover and offload computation to nearby devices called surrogates. The What/Where/When framework guides offloading decisions: What task to offload (CPU-heavy, delay-tolerant tasks are best candidates), Where to offload (nearby devices with matching capabilities), and When to offload (based on battery state, network conditions, and urgency). Edge caching across three tiers (device, surrogate, cloud) further reduces latency and bandwidth.

51.1 Learning Objectives

By the end of this chapter, you will be able to:

  • Explain Cyber-Foraging Concepts: Describe how mobile devices opportunistically discover and leverage nearby computational resources
  • Apply the What/Where/When Framework: Evaluate offloading decisions based on task characteristics, surrogate capabilities, and timing constraints
  • Compare Virtualization vs Mobile Agents: Distinguish between cloudlet-based and agent-based approaches for different session durations and isolation requirements
  • Design Edge Caching Strategies: Implement multi-tier caching hierarchies for optimal latency and bandwidth

Key Concepts

  • Cyber-foraging: A mobile edge computing strategy where resource-constrained devices dynamically offload compute tasks to nearby, more powerful nodes (cloudlets, edge servers) discovered opportunistically on the local network.
  • Cloudlet: A trusted, resource-rich compute node located close to mobile or IoT devices, providing low-latency offloading without the round-trip delay of a public cloud data centre.
  • Task migration: The process of moving an in-progress computation from one node to another, requiring serialisation of the computation state and transfer of associated data.
  • Offload decision algorithm: The logic determining whether to execute a task locally or offload it to a nearby node, typically based on task size, local battery level, network round-trip time, and available remote resources.
  • Opportunistic networking: A communication paradigm where connections are established whenever nodes come within range of each other, without requiring persistent infrastructure, used to distribute processing in dense IoT environments.

Imagine your phone needs to do a really hard math problem but it is too slow. Instead of sending the problem all the way to a faraway server (the cloud), your phone looks around for a nearby laptop or tablet that can help. This “looking for nearby help” is called cyber-foraging. It is faster because the helper is close, and it saves your phone’s battery because it does not have to do all the hard work itself. Caching is like keeping a copy of answers you already got, so you do not have to ask again.

51.2 Prerequisites

Before diving into this chapter, you should be familiar with:

51.3 Cyber-Foraging Overview

Cyber-foraging extends edge computing concepts by enabling resource-constrained mobile devices to opportunistically discover and offload computation to nearby devices (surrogates).

51.3.1 What is Cyber-Foraging?

Definition: Cyber-foraging is the practice of augmenting the computing capabilities of wireless mobile computers by dynamically discovering and leveraging nearby computational resources.

Core Concept: Instead of relying on fixed infrastructure (cloudlets, fog nodes), mobile devices scavenge for computational resources in their environment – nearby smartphones, laptops, vehicles, or IoT gateways.

Key Characteristics:

  • Opportunistic: Uses whatever resources are available nearby
  • Dynamic: Adapts to changing network topology and device availability
  • Heterogeneous: Works across diverse device types with varying capabilities
  • Autonomous: Devices make independent decisions about offloading

51.4 Cyber-Foraging Framework: What/Where/When

Effective cyber-foraging requires answering three fundamental questions:

Consider a 4K video transcoding task (H.265 to H.264):

Local execution (smartphone): \[\text{Processing time} = \frac{3{,}840\text{ MB}}{12\text{ MB/s}} = 320\text{ s}\] \[\text{Battery drain} = 2{,}800\text{ mA} \times 320\text{ s} = 896{,}000\text{ mAs} = 249\text{ mAh}\]

Offload to nearby laptop (5 GHz Wi-Fi): \[\text{Upload time} = \frac{3{,}840\text{ MB}}{50\text{ MB/s}} = 76.8\text{ s}\] \[\text{Remote transcode} = \frac{3{,}840\text{ MB}}{180\text{ MB/s}} = 21.3\text{ s}\] \[\text{Download time} = \frac{2{,}560\text{ MB}}{50\text{ MB/s}} = 51.2\text{ s}\] \[\text{Total offload time} = 76.8 + 21.3 + 51.2 = 149.3\text{ s}\] \[\text{Battery drain} = 450\text{ mA} \times 149.3\text{ s} = 67{,}185\text{ mAs} = 18.7\text{ mAh}\]

Result: Offloading saves 53% time (320 s to 149 s) and 92% battery (249 mAh to 18.7 mAh). This justifies the What/Where/When framework: offload CPU-heavy tasks to capable nearby devices when the network is fast.

Three-column decision framework diagram with WHAT showing task characteristics like CPU intensity and data sensitivity, WHERE showing surrogate selection criteria like latency and trust, and WHEN showing timing triggers like battery state and network conditions.
Figure 51.1: Edge caching framework diagram showing three decision dimensions: WHAT (what data or computation to cache or offload), WHERE (which edge nodes to use), and WHEN (timing and triggers).

Decision Framework:

Question Considerations Example
WHAT? Task characteristics (CPU/memory/network), data sensitivity, QoS requirements Video transcoding is CPU-heavy but delay-tolerant – good candidate for offloading
WHERE? Surrogate capabilities, network latency, reliability, trust Nearby laptop has GPU – offload AR rendering; stranger’s device – avoid for private data
WHEN? Task urgency, network conditions, battery state, surrogate availability Battery <10% + Wi-Fi available + non-urgent task – offload immediately

51.5 Scavenger System Architecture

The Scavenger system exemplifies cyber-foraging with a distributed architecture enabling mobile devices to discover and utilize nearby computational resources:

Layered architecture diagram with client side showing application layer, scavenger library, and RPC interface on the left, connected via network to surrogate side showing frontend, IPC layer, and sandboxed execution environment on the right.
Figure 51.2: Cyber-foraging scavenger system architecture showing heterogeneous network topology with mobile client discovering nearby surrogates via service discovery protocol.

Client-Side Components:

  1. Application Layer: User application (e.g., photo processing, video transcoding)
  2. Scavenger Library: Profiles tasks (CPU, memory, network requirements), discovers surrogates, selects optimal target
  3. RPC Interface: Serializes tasks, transmits to surrogate, receives results

Surrogate-Side Components:

  1. Frontend: Accepts incoming RPC requests from clients
  2. IPC Layer: Manages communication between frontend and execution environment
  3. Execution Environment: Sandboxed environment for running client tasks with resource limits

51.6 Network Topology and Device Heterogeneity

Real-world cyber-foraging environments include diverse devices with varying capabilities:

Network topology diagram showing a central mobile client connected to multiple device types including laptop, smartphone, desktop PC, and IoT gateway, with connection quality indicators and device capability labels.
Figure 51.3: Heterogeneous device network topology showing mobile client surrounded by diverse surrogates with capability-aware task assignment.

Device Capability Spectrum:

Device Type CPU RAM GPU Battery Network Best For
Netbook (Client) 1.6 GHz dual 2 GB Integrated Limited Wi-Fi Lightweight tasks only
Laptop 2.8 GHz quad 16 GB Integrated Hours Wi-Fi/LTE CPU-bound tasks (compilation, compression)
Smartphone 3.2 GHz hexa 6 GB 5-core GPU Moderate 5G/Wi-Fi ML inference, image processing
IoT Gateway 600 MHz ARM 256 MB None Limited 3G/Wi-Fi Simple data processing
Desktop PC 3.5 GHz 8-core 32 GB RTX 3080 Unlimited Gigabit Video encoding, 3D rendering, ML training

51.7 Virtualization vs. Mobile Agents Comparison

Two primary approaches exist for implementing cyber-foraging, each with distinct trade-offs:

Approach Pros Cons Representative Systems
Virtualization Strong isolation (sandboxing), no special software on client, standardized VM interfaces, security through hypervisor VM spin-up delays (30–60 s), resource overhead (hypervisor), fixed VM sizes not adaptable to task Cloudlets, MAUI, CloneCloud, ThinkAir
Mobile Agents Dynamic deployment (code mobility), autonomous execution (detached operation), fine-grained adaptation to resources Agent management complexity, security risks (code injection), heterogeneous runtime environments, debugging difficulty Scavenger, Aglets, IBM Mobile Agents

When to Use Each:

Virtualization (Cloudlets):

  • Best for: Computation-intensive applications with graphical interfaces (AR, gaming, video editing)
  • Scenario: Predictable workloads where VM startup time is amortized over long sessions (>5 minutes)
  • Example: Mobile AR navigation app running on cloudlet VM for entire campus tour (30 minutes)

Mobile Agents (Scavenger):

  • Best for: Short-lived tasks (<1 minute) on opportunistic, heterogeneous devices
  • Scenario: Rapidly changing network topology (moving vehicles, crowded spaces)
  • Example: Tourist photo processing – offload photo stitching to nearby laptop in coffee shop for 20 seconds, then move on

Hybrid Approach:

  • Many modern systems use both: Cloudlets for persistent sessions + Mobile agents for quick offloads
  • Example: Smartphone uses cloudlet for continuous AR, but offloads burst photo processing to nearby laptop via Scavenger

51.8 Edge Caching Strategies

Cyber-foraging and edge computing benefit from intelligent caching to minimize latency and bandwidth:

Cache Placement Hierarchy:

Three-tier pyramid diagram with device cache at bottom showing 30 percent hit rate, surrogate or AP cache in middle showing 40 percent hit rate, and cloud CDN at top showing 30 percent hit rate, with latency values labeled at each tier.
Figure 51.4: Three-tier edge caching hierarchy showing hit rates at each level demonstrating effectiveness of hierarchical caching.

Caching Policy Trade-offs:

Policy What to Cache When to Update Use Case
LRU (Least Recently Used) Most recently accessed items On access General-purpose caching
LFU (Least Frequently Used) Most frequently accessed items Periodic count reset Static content (maps, models)
TTL (Time-To-Live) All items with expiration After TTL expires Dynamic data (sensor readings, weather)
Context-Aware Items based on location/time/activity On context change Predictive prefetch (navigation routes)

Real-World Example: Mobile Video Streaming

Scenario: User watches YouTube videos on phone while commuting

Tier 1 (Device):
- Recently watched videos cached locally (2 GB)
- Hit rate: 30% (rewatching favorite clips)

Tier 2 (Nearby Wi-Fi AP Cache):
- Popular videos in neighborhood cached on Wi-Fi router (500 GB)
- Hit rate: 40% (trending content)

Tier 3 (CDN/Cloud):
- All videos available from global CDN
- Hit rate: 30% (long-tail content)

Result: 70% of video traffic served from edge (Tier 1+2),
       reducing cellular bandwidth by 5 GB/month

Quantify the bandwidth savings of three-tier caching for 10,000 apartment residents:

Without edge caching (all requests to cloud): \[\text{Monthly traffic} = 10{,}000\text{ users} \times 15\text{ GB/user} = 150{,}000\text{ GB} = 150\text{ TB}\] \[\text{ISP backhaul cost} = 150\text{ TB} \times \text{\$8/TB} = \text{\$1,200/month}\]

With three-tier caching (30% device, 40% AP cache, 30% cloud): \[\text{Device hits} = 150\text{ TB} \times 0.30 = 45\text{ TB (no network)}\] \[\text{AP cache hits} = 150\text{ TB} \times 0.40 = 60\text{ TB (local Wi-Fi only)}\] \[\text{Cloud requests} = 150\text{ TB} \times 0.30 = 45\text{ TB (backhaul)}\] \[\text{ISP backhaul cost} = 45\text{ TB} \times \text{\$8/TB} = \text{\$360/month}\]

Savings: $1,200 - $360 = $840/month (70% reduction). Edge caching hardware (Wi-Fi AP with 2 TB SSD) costs $600 one-time – payback in 3 weeks.

51.9 Implementation Considerations

51.9.1 Service Discovery

Cyber-foraging requires efficient discovery of nearby surrogates:

# Example: mDNS-based surrogate discovery
import zeroconf

class SurrogateDiscovery:
    def __init__(self):
        self.zeroconf = zeroconf.Zeroconf()
        self.surrogates = {}

    def on_service_state_change(self, name, state):
        if state == "added":
            info = self.zeroconf.get_service_info(
                "_cyberforage._tcp.local.", name
            )
            self.surrogates[name] = {
                "address": info.parsed_addresses()[0],
                "port": info.port,
                "capabilities": info.properties,
            }

    def get_best_surrogate(self, task_requirements):
        """Select surrogate matching task needs."""
        for name, surrogate in self.surrogates.items():
            if self.matches_requirements(surrogate, task_requirements):
                return surrogate
        return None

51.9.2 Task Profiling

Effective offloading requires understanding task characteristics:

# Example: Task profiler for offloading decisions
class TaskProfile:
    def __init__(self, task):
        self.cpu_intensity = self.estimate_cpu(task)       # in cycles
        self.memory_requirement = self.estimate_memory(task)  # in bytes
        self.input_size = len(task.input_data)               # in bytes
        self.expected_output_size = self.estimate_output(task)
        self.deadline_ms = task.deadline

    def should_offload(self, local_cpu, surrogate_cpu,
                       network_bandwidth, network_latency):
        """Decide whether offloading benefits this task."""
        local_time = self.cpu_intensity / local_cpu
        transfer_time = (
            (self.input_size + self.expected_output_size)
            / network_bandwidth
        )
        remote_time = (
            self.cpu_intensity / surrogate_cpu
            + transfer_time
            + network_latency * 2  # round-trip overhead
        )
        return remote_time < local_time and remote_time < self.deadline_ms
See Also

51.9.3 Worked Example: Singapore Smart Nation AR Navigation Offloading

Scenario: Singapore’s Land Transport Authority (LTA) piloted an AR wayfinding application for visually impaired pedestrians navigating Orchard Road MRT station. The app renders 3D audio-visual overlays in real-time, requiring GPU resources that exceed typical smartphone capabilities.

Given:

  • Smartphone GPU: Qualcomm Adreno 660, 35 GFLOPS sustained
  • AR rendering demand: 60 GFLOPS at 30 fps for obstacle mesh + audio spatialization
  • Station cloudlet: NVIDIA Jetson AGX Orin, 275 TOPS AI + 200 GFLOPS GPU
  • Wi-Fi 6 latency to cloudlet: 4 ms round-trip
  • 5G latency to cloud GPU instance: 22 ms round-trip
  • Session duration: 8 minutes average (station entry to platform)
  • Daily users: 1,200 visually impaired commuters across 40 stations

Step 1: Evaluate offloading options

Option Compute Latency Cost/Session Battery Drain
Local only 35 GFLOPS (insufficient, ~18 fps) 0 ms SGD 0 340 mAh (8 min full GPU)
Station cloudlet 200 GFLOPS (3.3x headroom) 4 ms SGD 0.02 (amortized HW) 85 mAh (Wi-Fi only)
Cloud GPU (5G) Unlimited 22 ms SGD 0.18 (GPU-as-a-service) 190 mAh (5G radio)

Step 2: Apply What/Where/When framework

Decision Analysis Choice
What to offload AR mesh rendering (GPU-bound, 60 GFLOPS) + obstacle LIDAR processing Full render pipeline
Where to offload Cloudlet: 4 ms latency meets 33 ms frame budget; cloud: 22 ms too close to budget Station cloudlet
When to offload Battery <50% OR GPU thermal throttling OR >2 concurrent AR layers Immediate (always, for this app)

Step 3: Calculate system-wide economics

\[\text{Cloud compute cost} = 1{,}200\text{ users} \times 30\text{ days} \times \text{SGD 0.18/session} = \text{SGD 6,480/month}\] \[\text{Cloudlet compute cost} = 1{,}200 \times 30 \times \text{SGD 0.02} = \text{SGD 720/month (amortized HW)}\] \[\text{Compute savings} = 6{,}480 - 720 = \text{SGD 5,760/month}\]

For 40 stations at SGD 1,200 per cloudlet unit: \[\text{Total hardware cost} = 40 \times \text{SGD 1,200} = \text{SGD 48,000}\] \[\text{Payback period} = \frac{\text{SGD 48,000}}{\text{SGD 5,760/month}} \approx 8.3\text{ months}\]

Result: Station-deployed cloudlets deliver 30 fps AR navigation at 4 ms latency while reducing battery drain by 75% compared to on-device rendering. The SGD 48,000 cloudlet investment pays for itself in about 8 months through eliminated cloud GPU costs, plus additional savings from reduced 5G data usage.

Key Insight: Cyber-foraging excels when the offloading environment is predictable. Train stations, airports, and hospitals have fixed infrastructure where cloudlets can be pre-positioned. The What/Where/When framework collapses to “always offload to the local cloudlet” when latency requirements are strict and surrogate availability is guaranteed.

51.10 Summary

  • Cyber-foraging enables mobile devices to opportunistically discover and offload computation to nearby surrogates
  • The What/Where/When framework guides offloading decisions based on task characteristics, surrogate capabilities, and timing
  • Scavenger architecture demonstrates client-server design with discovery, profiling, and execution components
  • Virtualization vs mobile agents trade strong isolation (VMs) against deployment flexibility (agents)
  • Three-tier caching places data at device, surrogate, and cloud levels for optimal access latency
  • Caching policies (LRU, LFU, TTL, context-aware) match data characteristics to update strategies
  • Service discovery (mDNS/Zeroconf) and task profiling enable intelligent offloading decisions
Key Takeaway

Cyber-foraging extends edge computing by allowing devices to scavenge nearby computational resources opportunistically. Use virtualization (cloudlets) for long sessions requiring strong isolation, and mobile agents for short-lived tasks on heterogeneous devices. Three-tier caching (device, surrogate, cloud) can serve 70% of traffic from the edge, dramatically reducing bandwidth and latency.

Sammy asks for help from nearby friends!

Sammy the Sensor had a problem. He had taken a hundred photos of the garden to check on the plants, but his tiny brain was too small to figure out which plants were healthy and which were sick.

“I know!” said Sammy. “I will send all the photos to the cloud for analysis!” But Bella the Battery shook her head: “That will use up all my energy sending photos over the internet!”

Max the Microcontroller had a clever idea: “What about cyber-foraging? That means asking for help from nearby friends instead of calling the faraway cloud!”

Max looked around the garden and found Lila the LED’s powerful tablet sitting on the porch. “Lila’s tablet has a fast processor and is connected to our Wi-Fi. We can send the photos to her tablet instead – it is right here, so it is super fast and uses almost no energy!”

Lila’s tablet analyzed all the photos in seconds and sent back the results: “Three tomato plants need water, and one rose bush has bugs!”

“That was 10 times faster than using the cloud!” cheered Sammy.

“And I barely used any energy!” added Bella happily.

The lesson: Cyber-foraging means looking for helpful computers NEARBY instead of always sending your work to the faraway cloud. It is faster, cheaper, and saves energy!

51.11 Knowledge Check

Test Your Understanding

Question 1: A mobile AR navigation app needs continuous rendering for a 30-minute campus tour. The user’s phone has limited GPU capability. Which cyber-foraging approach is MOST appropriate?

  1. Mobile agents offloaded to nearby smartphones
  2. Virtualization using a campus cloudlet with a dedicated VM
  3. Direct cloud processing via 5G connection
  4. No offloading – run everything locally on the phone

Answer: b) Virtualization via cloudlets is best for long sessions (30 minutes) with computation-intensive graphical workloads. The VM startup cost (30–60 seconds) is amortized over the long session, and cloudlets provide strong isolation and dedicated resources for consistent AR rendering.

Question 2: In a three-tier edge caching hierarchy (device, nearby AP cache, cloud CDN), what is the typical percentage of traffic served from the edge (Tier 1 + Tier 2 combined)?

  1. About 20%
  2. About 50%
  3. About 70%
  4. About 95%

Answer: c) Approximately 70% of traffic is typically served from edge tiers – about 30% from the device cache (recently accessed content) and 40% from the nearby access point cache (locally popular content). Only 30% of requests need to reach the cloud CDN for long-tail content.

51.12 Concept Relationships

Cyber-foraging extends edge computing by enabling opportunistic offloading to nearby devices:

Core Framework (This chapter):

  • What/Where/When decision framework guides task offloading (CPU-heavy tasks to capable surrogates when battery low)
  • Virtualization (cloudlets) vs mobile agents: strong isolation vs deployment flexibility trade-off
  • Three-tier caching (device/surrogate/cloud) serves 70% of traffic from edge, reducing bandwidth and latency

Edge Pattern Context:

Architectural Foundation:

  • IoT Reference Model – Cyber-foraging operates at Level 3 (edge compute) leveraging nearby Level 4 (fog) resources
  • Edge Fog Computing – Cloudlets are pre-positioned fog nodes; cyber-foraging discovers opportunistic fog resources

Practical Application:

  • Edge Patterns Practical Guide – Latency calculator helps decide when offloading saves time vs network overhead
  • Singapore AR navigation case study: cloudlets deliver 30 fps at 4 ms latency, 75% battery savings vs on-device rendering

Data Acquisition Impact:

Key Insight: Cyber-foraging excels when offload environment is predictable (train stations, airports with cloudlets). Random opportunistic offloading (to stranger’s laptop) rarely works due to trust, discovery overhead, and availability uncertainty. The What/Where/When framework collapses to “always offload to local cloudlet” when latency requirements are strict and surrogate availability guaranteed.

51.13 What’s Next

Next Topic Description
Edge Patterns Practical Guide Interactive tools, worked examples, and common pitfalls
Edge Data Acquisition Data collection strategies at the edge

Edge Pattern Series:

Architecture:

Data Acquisition: