16 Edge Cyber-Foraging: Cost and Energy Calculations

16.1 Start With the Decision

A 4K transcode can move heat and delay from a phone to a nearby server. Compare the local cost with the offload cost.

16.2 Route Overview

This is part 2 of 2. Review Edge Cyber-Foraging: Placement and Caching Decisions for the preceding evidence.

16.3 Learning Objectives

• Test putting numbers to it with a concrete scenario and pass criteria.
• Validate test your understanding with a concrete scenario and pass criteria.

16.4 Chapter Roadmap

• Putting Numbers to It
• Mobile Figure Summary: What/Where/When
• Scavenger System Architecture
• Mobile Figure Summary: Scavenger Flow
• Network Topology and Device Mix
• Mobile Figure Summary: Device Capability Ladder
• Virtualization vs Mobile Agents
• Edge Caching Strategies
• Mobile Figure Summary: Three-Tier Caching
• Putting Numbers to It
• Implementation Considerations
• Service Discovery
• Task Profiling
• See Also
• AR Navigation Offloading
• Interactive Quiz: Match Concepts
• Interactive Quiz: Sequence the Steps
• Label the Diagram
• Code Challenge
• Cyber-Foraging Offload Contracts
• Cyber-Foraging Offload Contracts
• Summary
• Key Takeaway
• Knowledge Check
• Test Your Understanding
• Quiz: Cyber-Foraging and Caching
• Concept Relationships
• What’s Next
• See Also

An available surrogate is not automatically a safe offload target. The framework diagram in Figure 16.1 separates the three decisions that must be recorded before computation or data leaves the device.

Use the three columns in the diagram Figure 16.1 as distinct gates. What identifies the Data/computation and its sensitivity or compute burden; Where selects a Device/gateway with acceptable capability, latency, and trust; When applies the Trigger policy and How Long / TTL strategy. This order prevents a nearby node from winning merely because it is present. It also advances the cyber-foraging contract: record the task boundary, chosen surrogate, trigger, expiry, and failure fallback for every offloaded or cached result.

Read Figure 16.1 from what to where to when. First bound the task by compute cost, data sensitivity, and deadline; next choose only a surrogate whose capability, latency, and trust meet that boundary; finally trigger offload when battery, network, and urgency make the transfer worthwhile. The order matters because an available device is not automatically an acceptable destination. This connects cyber-foraging to the chapter’s running placement narrative: opportunistic compute remains a governed decision with explicit data and failure limits.

Decision Framework:

16.5 Scavenger System Architecture

The Scavenger system exemplifies cyber-foraging with a distributed architecture enabling mobile devices to discover and utilize nearby computational resources. Use Figure 16.2 to trace the request across the trust and execution boundary before reading the component lists.

Follow Figure 16.2 from the application into the client library and RPC interface, across the network, and then through the surrogate frontend and IPC layer into sandboxed execution. The return path carries a result, but the boundary must also carry identity, task limits, errors, and provenance. Notice that discovery and selection happen before execution. That ordering advances the running narrative from abstract offload criteria to a concrete system in which capability checks, transport, isolation, and fallback must all support the same task claim.

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

16.6 Network Topology and Device Mix

Real-world cyber-foraging environments include diverse devices with varying capabilities. The topology diagram in Figure 16.3 makes that heterogeneity visible before a task is matched to a surrogate.

Read Figure 16.3 from the mobile client outward. Each candidate differs in compute, memory, acceleration, energy source, link quality, and trust; proximity alone does not make the phone, laptop, desktop, or gateway interchangeable. Compare the connection indicators with the capability labels, then identify which task constraint rules each candidate in or out. This continues the chapter’s running argument: cyber-foraging selection is a per-task evidence decision, and the chosen node must remain observable enough to detect departure or failure.

Device Capability Spectrum:

16.7 Virtualization vs Mobile Agents

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

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

16.8 Edge Caching Strategies

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

The hierarchy diagram in Figure 16.4 shows why cache placement and freshness must be considered together before choosing a replacement policy.

Cache Placement Hierarchy:

Caching changes both response distance and the evidence needed to decide whether a reused result is still valid. The hierarchy diagram in Figure 16.4 shows how requests can be absorbed at three progressively broader tiers.

In the hierarchy diagram Figure 16.4, L1 Device is the nearest cache and the diagram marks 80% hit rate before a request climbs to L2 Gateway at 95% hit rate. L3 Cloud completes the hierarchy with 100% hit rate, representing the broad backing catalogue rather than a claim of equal latency. Each upward step trades locality for wider availability. The chapter’s caching strategy must therefore couple tier selection with version, TTL, privacy, and invalidation evidence; a hit is useful only when the object remains correct for the decision.

Trace Figure 16.4 from the device cache through the surrogate or access-point cache to the cloud or CDN. The nearest tier offers the lowest latency but the smallest, most local working set; the middle tier can share neighbourhood results; the cloud tier holds the broadest catalogue at the highest path cost. The hit-rate labels partition served requests rather than guaranteeing freshness. This connects caching to the running cyber-foraging narrative: place reusable work near demand, but carry version, TTL, privacy, and invalidation evidence with every cached result.

Caching Policy Trade-offs:

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

16.9 Implementation Considerations

16.10 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

16.11 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

16.13 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

Step 2: Apply What/Where/When framework

Step 3: Calculate system-wide economics

• Cloud compute cost = 1,200 users x 30 days x SGD 0.18/session = SGD 6,480/month
• Cloudlet compute cost = 1,200 x 30 x SGD 0.02 = SGD 720/month (amortized HW)
• Compute savings = SGD 6,480 - SGD 720 = SGD 5,760/month

For 40 stations at SGD 1,200 per cloudlet unit:

• Total hardware cost = 40 x SGD 1,200 = SGD 48,000
• Payback period = SGD 48,000 / SGD 5,760 per month ~= 8.3 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.

16.14 Cyber-Foraging Offload Contracts

Cyber-foraging only works when the offload decision is measured instead of assumed. Continue to Cyber-Foraging Offload Contracts for cloudlet break-even checks, cache freshness, privacy constraints, adaptive fallback, and decision-log evidence.

16.15 Cyber-Foraging Offload Contracts

16.15.4 Overview: Borrowing Compute From Nearby

Cyber foraging is the idea that a resource-poor device can borrow computing power from a nearby machine to do work it could not do alone. Rather than always computing locally (too slow, drains the battery) or always reaching the distant cloud (too far, too laggy), the device opportunistically offloads heavy tasks to a well-connected surrogate one hop away: a cloudlet.

The cloudlet gives cloud-like power with local-network latency, and caching results and models nearby avoids recomputing or refetching. But offloading is not always a win: whether to offload is a genuine calculation involving how much data must be shipped, how heavy the computation is, how much battery remains, and whether the answer is still useful after the network round trip.

Intuition: offloading is like handing a hard sum to a friend next to you instead of mailing it to an expert overseas. It helps only when the sum is hard enough to be worth handing over, and the friend is close enough to answer quickly.

Borrowed compute saves energy only when the radio path costs less than local execution. The decision diagram in Figure 16.5 makes that comparison explicit before the chapter applies it to image and log workloads.

The diagram’s decision diamond in Figure 16.5 compares E_local = P_cpu x t_compute with E_remote = E_tx + E_rx + E_idle + E_tail. The Wi-Fi Offloading example pairs 16 Mbps and 250 mW with a 130 mJ total, while LTE / Cellular Offloading adds the labelled RRC tail and reaches 2050 mJ total for the same 1 MB example. Thus an Offload to Cloud branch is conditional on both task size and current link state; the runtime contract must measure network type, battery state, input bytes, result bytes, and deadline before choosing local or remote execution.

In practice, the device compares a local plan with a remote plan. The local plan spends CPU, memory, and battery on the device. The remote plan spends radio energy to send the input, remote compute time at the cloudlet, and radio energy to receive the answer. If the input is a 60 kB image and the result is a short label, offloading may be attractive. If the input is a 600 MB log and the local calculation is a simple average, offloading is usually wasteful. Caching improves the odds when the same model, map tile, inference result, or feature vector is likely to be reused soon.

Offload if:  (send input) + (remote compute) + (receive result)
             <  (local compute)
Great candidates: heavy compute + small input/output
Poor candidates:  light compute + large input (shipping costs more
                  than just doing it locally)

Task A: run face recognition on one small image.
  input  = a small image (a few KB)
  output = a name (tiny)
  compute = heavy for a tiny device
  -> OFFLOAD: small data both ways, heavy compute saved. Win.

Task B: compute a simple average of a huge local log.
  input  = a large file (many MB)
  output = one number
  compute = trivial
  -> DO IT LOCALLY: uploading the file costs far more time and
     energy than the trivial computation would locally.

16.16 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

16.17 Knowledge Check

16.18 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:

• Edge Compute Patterns — Cyber-foraging is an advanced offloading pattern beyond basic filter/aggregate/infer
• Edge Processing Patterns — Infer pattern often offloads ML inference via cyber-foraging

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:

• Edge Data Acquisition — Cyber-foraging offloads processing but still requires edge data collection
• Edge Data Acquisition: Power and Gateways — Offloading reduces battery drain (85 mAh for Wi-Fi offload vs 340 mAh local GPU)

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.

16.19 What’s Next

16.20 Continue Your Route

This final part closes the route from Putting Numbers to It through See Also. Return to Edge Cyber-Foraging: Placement and Caching Decisions or continue from the analytics-ml module index.