16 Edge Cyber-Foraging: Cost and Energy Calculations

16.1 Start With the Decision

This section: Start With the Decision — A 4K transcode can move heat and delay from a phone to a nearby server.

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 section: Route Overview — This is part 2 of 2.

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

16.3 Learning Objectives

This section: 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

This section: Chapter Roadmap — Read Figure 16.1 from what to where to when.

• 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

This section: Scavenger System Architecture — The Scavenger system exemplifies cyber-foraging with a distributed architecture enabling mobile devices to discover and utilize nearby computational resources.

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

This section: Network Topology and Device Mix — Real-world cyber-foraging environments include diverse devices with varying capabilities.

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

This section: 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

This section: Edge Caching Strategies — The hierarchy diagram in Figure 16.4 shows why cache placement and freshness must be considered together before choosing a replacement policy.

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:

Inspect Figure 16.4 to ask which of the device, gateway, or cloud caches may safely answer a request with a reused result.

+

In Figure 16.4, a request checks the device cache first because it is nearest to demand. A miss moves to the gateway, and another miss reaches the broader cloud catalogue. The marked hit rates rise from 80% to 95% to 100%, but those percentages describe where an object is found, not whether it is fit to reuse. Read the validation note after each hit. Version, time to live, privacy scope, and invalidation state still have to match the current request. The useful design is therefore the nearest valid result, not simply the first stored copy returned by the hierarchy.

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

This section: Implementation Considerations

16.10 Service Discovery

This section: 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

This section: 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."""
        # CPU rates are cycles/s, bandwidth is B/s, and latency is seconds.
        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 * 1000 < self.deadline_ms

16.13 Illustrative Station AR Wayfinding

This section: Illustrative Station AR Wayfinding — Scenario: An illustrative station AR wayfinding app for visually impaired pedestrians renders 3D audio-visual overlays in real time, requiring GPU resources that exceed typical smartphone capabilities.

Scenario: An illustrative station AR wayfinding app for visually impaired pedestrians 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 for this illustrative station scenario: Station-deployed cloudlets deliver an assumed 30 fps AR navigation at 4 ms latency while reducing modeled battery drain by 75% compared with 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

This section: Cyber-Foraging Offload Contracts — Cyber-foraging only works when the offload decision is measured instead of assumed.

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

This section: 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.

Before applying offload to image and log work, inspect Figure 16.5 to ask when the full radio path uses less energy than local compute.

+

Start with the two energy ledgers in Figure 16.5. Local work costs processor power times compute time; remote work adds transmit, receive, idle, and radio-tail energy for the same task boundary. The branch chooses remote execution only when that total is lower, then checks deadline, privacy, and service availability. The paired 1 MB profiles show why the current link matters. One route costs 130 mJ, while the route with a long radio tail costs 2,050 mJ. Dividing 2,050 mJ by 130 mJ gives about 15.8, so an old offload decision cannot be reused after the network changes.

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

This section: 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

This section: Knowledge Check

16.18 Concept Relationships

This section: Concept Relationships — Key Insight: Cyber-foraging excels when offload environment is predictable (train stations, airports with cloudlets).

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
• In the chapter’s example, three-tier caching (device/surrogate/cloud) serves 70% of traffic from the edge, reducing modeled backhaul volume.

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
• Illustrative station AR navigation scenario: cloudlets deliver an assumed 30 fps at 4 ms latency and modeled 75% battery savings versus 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. In this illustrative station scenario, the What/Where/When framework selects the local cloudlet when latency requirements are strict and surrogate availability is guaranteed.

16.19 What’s Next

This section: What’s Next

16.20 Continue Your Route

This section: Continue Your Route — This is the last part of this chapter.

This is the last part of this chapter. Return to Edge Cyber-Foraging: Placement and Caching Decisions or continue from the analytics-ml module index.