15 Edge Cyber-Foraging: Placement and Caching Decisions
15.1 Start With the Decision
A phone should offload a task only when the nearby server can beat its deadline. Count radio energy and wait time first.
15.2 Route Overview
This is part 1 of 2. Continue with Edge Cyber-Foraging: Cost and Energy Calculations.
15.3 Part Objectives
- Test cyber-foraging check with a concrete scenario and pass criteria.
- Validate mobile figure summary: three-tier caching with a concrete scenario and pass criteria.
15.4 Chapter Roadmap
- A Clear First Route
- Start With the Story
- In 60 Seconds
- Phoebe’s Field Notes: What the 249 mAh Actually Costs, and Why 5 GHz Was the Right Offload Radio
- Cyber-Foraging Check
- Key Concepts
- Cyber-Foraging and Caching Basics
- Prerequisites
- Cyber-Foraging Overview
- What is Cyber-Foraging?
- Cyber-Foraging What Where When
15.5 A Clear First Route
Imagine smart glasses need to map a room but their small battery cannot do all the work at once. The device must decide whether to work alone, use a nearby helper, or wait. Bandwidth means how much data a link can carry in a set time. Latency means the wait from a task’s start to its useful result.
This page starts with one job. Name the task and the deadline that matters. Then note local power, link quality, helper load, data size, and privacy needs. Look for measured time, energy use, link cost, cache age, and a safe local path. Last, choose run here, send the work nearby, use saved data, or stop. Keep the limit in view. Sending work can cost more time and power than it saves. A cached result can also be too old.
15.5.1 Follow One Decision
- What real event starts the case?
- Who needs the result?
- What action may follow?
- Which sign comes from the device?
- How old can that sign be?
- What can make it wrong?
- What must still work after a fault?
- Who owns the next check?
- What change will force a new test?
- What proof should the team keep?
A good record answers each point in plain words. It names the site and the people. It names the device and its state. It says when the event took place. It says when the result arrived. It marks doubt instead of hiding it. It also names the safe fallback. That makes the result useful without making it sound more sure than it is.
15.5.2 Know What This Route Leaves Out
This first route is a guide to the main choice. It does not model every field effect or rare fault. The Practitioner sections add task profiles, helper choice, cache rules, and service search. Under the Hood adds offload maths, virtual machines, agents, weak links, and stale cache risk. Those deeper parts add detail to this route. They do not reverse its main claim.
15.5.3 Read the Result Before You Act
Start with the source, not the final label. Check that the source belongs to this case. Check its time and state. Ask if a second source agrees. If two sources differ, keep that fact in the record. Do not force a clean answer just to fill a screen. A late result may be true about the past and still be unsafe now. A missing result is also useful news when the system shows it at once.
Next, link the result to one owned step. A person may inspect the site. A local rule may hold a safe state. A remote team may ask for more proof. The right step depends on the claim that was tested. It must not depend on a broad product label. Write down the reason for the step. Write down the time. Write down who may close the case.
15.6 Start With the Story
Picture an IoT team using the ideas in Edge Cyber-Foraging and Caching during a live operations review. A device has produced messy evidence, an analytic step is about to change an alert or control decision, and someone has to explain why the result should be trusted.
Read this page as that path from sensor evidence to accountable action. Start with what the system observes, keep the model or data treatment visible, and finish with the check that would convince an operator, maintainer, or auditor to act.
The mathematical gist. At a stated 3.85 V, the chapter’s 249 mAh local run uses 0.959 Wh while the 18.7 mAh offload uses 0.072 Wh, saving 0.887 Wh or 92.5%. The same offload link at 5 GHz has a 6.00 cm wavelength and a 1.50 cm quarter-wave element; that compact, wide-channel radio trades range for the chapter’s 50 MB/s desk-to-laptop transfer.
15.7 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.
15.8 Prerequisites
Before diving into this chapter, you should be familiar with:
- Edge Compute Patterns Overview: Introduction to edge computing concepts
- Edge Processing Patterns: Understanding the four primary edge processing patterns
15.9 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).
15.10 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
15.11 Cyber-Foraging What Where When
Effective cyber-foraging requires answering three fundamental questions:
15.12 Continue to the Next Part
Carry this evidence into Edge Cyber-Foraging: Cost and Energy Calculations, which begins with Putting Numbers to It.