48  Cyber-Foraging Offload Contracts

48.1 Start With the Story

Picture an IoT team using the ideas in Cyber-Foraging Offload Contracts 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.

48.2 Learning Objectives

After this page, you should be able to:

• Explain when a nearby cloudlet is a better target than local execution or a distant cloud.
• Compare local and offloaded execution using input size, result size, remote compute, radio energy, and latency.
• Specify cache metadata for freshness, source version, invalidation, and privacy scope.
• Record decision-log evidence for local execution, remote offload, cache hit, stale cache, and fallback paths.

48.3 Why Offload Follows Caching

Edge Cyber-Foraging and Caching introduces cloudlets, opportunistic offload, surrogate discovery, and hierarchical caching. This page turns those ideas into the contract a runtime scheduler needs: when to offload, when to stay local, when to serve from cache, and what evidence proves the choice was valid.

Use it when mobile, wearable, gateway, or field devices must borrow nearby compute without creating hidden battery, privacy, staleness, or availability failures.

48.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.

Cyber-foraging is a measured break-even decision: offload only when transfer energy and latency are lower than the local compute cost for the task.

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.

48.4.1 Overview Knowledge Check

48.5 When Offloading Pays

Offloading helps only when shipping the work out and back beats doing it locally:

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)

Make that rule concrete with measurements rather than labels. Measure local execution time and energy for the task class. Measure uplink and downlink throughput on the current network. Estimate input bytes, output bytes, and any warm-up cost such as loading a model on the cloudlet. Then compare two budgets: local execution versus remote transfer plus remote execution. The offload decision can change minute by minute because Wi-Fi, cellular, battery state, and cloudlet load change.

Worked example: two tasks, two verdicts

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.

The pattern: offload compute-heavy, data-light tasks; keep data-heavy, compute-light tasks local. Caching then removes repeat work by storing the offloaded result or model at the edge so the next identical request is answered quickly.

A robust implementation also needs fallbacks. If discovery finds no trusted surrogate, the task must degrade to local mode, queue for later, or switch to a smaller model. If the surrogate is available but the cache entry is stale, refresh or recompute before serving the result. If the result contains private data, the policy may require local execution even when offloading is faster. The best path is therefore not only shortest latency; it is the path that meets latency, battery, privacy, and freshness constraints together.

48.5.1 Practitioner Knowledge Check

48.6 Energy, Networks, Staleness

The offload break-even equation has three terms on the remote side: energy and delay to send the input, cloudlet execution cost, and energy and delay to receive the result. A local-only path has CPU energy, memory pressure, heat, and user-visible delay. Offloading is beneficial only when the remote side is lower for the active constraint. A task may save battery but miss a latency deadline, or meet latency while violating a privacy rule.

Radio quality is the swing factor. On a strong Wi-Fi link, a few dozen kilobytes may be cheap enough that remote inference saves both time and energy. On a weak cellular link, retries, handshakes, tail energy, and low throughput can make the same offload worse than local execution. That is why cyber-foraging systems should profile the current path, not rely on a design-time assumption that “edge is always better.”

Caching adds another hidden variable: freshness. A cached model, map tile, or inference result is valuable because a cache hit costs almost no compute or network, but stale data can be wrong. Each cache entry needs metadata such as creation time, source version, time-to-live, invalidation rule, and privacy scope. For reusable tasks, the edge cache may be the difference between offloading once and paying the network cost on every request.

Privacy scope is part of the same control loop. A face embedding, location trace, or health feature vector may be cheap to offload, but policy can still require local execution, anonymisation, or a trusted surrogate. The scheduler should treat privacy, cache freshness, and link quality as first-class inputs rather than after-the-fact checks.

Energy break-even

On a battery device, offloading saves energy only if the radio energy to send the input is less than the local compute energy avoided. A weak or slow link can make offloading cost more energy than computing locally.

Why a cloudlet, not the cloud

The distant cloud’s round trip is too slow for interactive offload. A one-hop cloudlet keeps latency low, which is exactly why cyber foraging targets nearby surrogates rather than remote data centres.

Decisions must be adaptive

Network quality and battery level change constantly, so the offload decision should be measured and made per task, not fixed at design time. The right choice this minute may be wrong the next.

Cached data goes stale

Cached results and models save work but can become outdated. Use time-to-live or invalidation so the edge does not serve a stale answer or run a superseded model.

So cyber foraging is a live cost-benefit calculation, not a fixed architecture: offload compute-heavy, data-light work to a nearby cloudlet when the network makes it cheaper in time and energy than computing locally, cache what you can to avoid repeats, and expire the cache so freshness is preserved. The decision log should record why a task ran locally or remotely: input size, result size, link estimate, battery state, cache hit or miss, privacy rule, and fallback path. Measured adaptively, it lets a small device punch far above its weight without pretending that every edge resource is always the right resource.

48.6.1 Under-the-Hood Knowledge Check

48.7 Release Checklist

Before shipping a cyber-foraging offload contract, verify these records:

• Each offloadable task records input size, result size, local execution time, local energy, remote execution time, and network transfer estimate.
• The scheduler measures current link quality and battery state before choosing local execution, cloudlet offload, delayed queue, or smaller-model fallback.
• Cache entries declare source version, creation time, time-to-live, invalidation rule, privacy scope, and whether stale results may be served.
• Trusted-surrogate policy says which cloudlets may run private data and what sandbox, attestation, or encryption boundary applies.
• Decision logs capture local/offload verdict, cache hit or miss, stale-cache handling, privacy override, fallback path, and operator-visible quality flag.

48.8 See Also

• Edge Cyber-Foraging and Caching for the broader offload, surrogate, and cache architecture.
• Edge Reference Model Placement Contracts for tier placement and evidence ownership.
• Edge Stream Window Contracts for bounded state and replay metadata behind edge summaries.
• Edge Patterns Practical Guide for worked placement decisions and calculators.

48.9 Next

Return to Edge Cyber-Foraging and Caching, then continue to Edge Patterns Practical Guide for interactive design tradeoffs.