18 Fog Energy-Latency Tradeoffs
18.1 Start Simple
Imagine a battery-powered gateway deciding whether to compute locally, use a nearby fog node, or send work to the cloud. The core idea is that the best tier depends on measured response time, radio cost, compute cost, idle cost, contention, and fallback behavior. Everyday IoT optimization starts with one workload budget rather than a universal rule about fog. Build one energy-latency record, then retest it when load, battery, temperature, or network conditions change.
18.2 Learning Objectives
By the end of this chapter, you will be able to:
- Build an energy-latency budget for a fog workload using measured components.
- Compare edge, fog, and cloud placement without relying on fixed universal latency or energy numbers.
- Explain when duty cycling, batching, compression, filtering, and local aggregation help or hurt.
- Identify queueing, wake-up, retry, thermal, and contention effects that make a design miss its response budget.
- Write a concise energy-latency placement record with evidence, fallback behavior, and review triggers.
- Use simple code logic to choose a feasible tier from measured candidate values.
Do not optimize “energy” and “latency” separately. A fog design is defensible only when one measured operating point satisfies both budgets under realistic load and has a documented fallback when the measurements change.
18.3 Prerequisites
- Fog Resource Allocation: Review queueing, priority, fairness, and overload behavior on shared fog nodes.
- Fog Fundamentals Tradeoffs: Review how placement decisions should be recorded and pressure-tested.
- Energy-Aware Design: Review battery capacity, power states, duty cycle, and measurement habits.
18.4 Why This Chapter Exists
Energy-latency examples are easy to overstate. A single wireless-energy comparison, round-trip latency number, or battery-life calculation can look precise while hiding the site conditions that make it true. The reliable habit is different: describe the workload, measure the candidate tiers, and record the constraints that would make the decision invalid.
Use this chapter when a fog design needs to answer questions like these:
“Should this device process locally or offload?” Compare the energy of local compute against radio transmission, queueing, wake-up, and retry cost.
“Can the gateway sleep?” Compare the wake-up penalty against the maximum acceptable response time and the cost of staying ready.
“Is the fog node overloaded?” Include queueing delay, thermal throttling, shared workload priority, and fallback behavior in the latency budget.
“Can we send only local data products upstream?” Measure whether filtering, aggregation, or event extraction reduces enough traffic to justify local processing.
18.5 The Stable Tradeoff Model
-
Set the response and energy limits before choosing a place.
-
Measure edge, nearby, and remote options on the same task.
-
Keep a point only if both limits pass, then record its fallback.
Every candidate placement has an operating point. Some points are clearly bad: they use more energy and miss the latency budget. Some points are feasible but fragile. The useful set is the frontier of options that meet the required response time while using an acceptable amount of energy and operational effort.
Inspect Figure 18.1 before continuing. A placement is acceptable only if the same measured operating point satisfies both response and energy limits. Figure 18.1 makes that joint test visible before the chapter compares candidate tiers.
In the diagram Figure 18.1, the horizontal Latency per useful result axis meets the vertical Energy per result axis at the Response budget and Energy budget boundaries. The Measured frontier positions Edge, Fog, Cloud, Duty cycle, and Overloaded candidates relative to both limits. Points beyond either boundary are rejected; points inside still need fallback, operations burden, and review triggers recorded. The plot therefore prevents a low-energy but late option, or a fast but power-hungry one, from being described as optimal.
18.5.1 Interactive: Compare Edge, Fog, and Cloud Latency
18.5.2 Edge
Best when the action must remain local, the computation is small enough, or sending data would cost more energy than processing it.
18.5.3 Fog
Best when local coordination, filtering, buffering, priority, or short-site-path communication changes the measured budget.
18.5.4 Cloud
Best when the workload tolerates remote response, needs durable fleet context, or benefits from compute that local tiers cannot provide.
18.6 Build the Budget
A fog energy-latency review starts with two budgets and one set of measurements.
18.6.1 Response budget
Define the maximum elapsed time from event or sample arrival to the action, warning, data product, or acknowledgement that matters.
18.6.2 Energy budget
Define the allowed energy per event, per sample window, per hour, or per day, depending on what limits the deployment.
18.6.3 Load condition
Record device count, report rate, competing workloads, queue depth, radio condition, and expected bursts.
18.6.4 Fallback condition
Record what happens when the preferred tier is unavailable, overloaded, asleep, thermally limited, or disconnected.
18.6.5 A Simple Budget Equation
Use a simple equation before discussing tools. Replace every term with a measurement from the actual platform or a clearly labeled experiment.
latency_total = sense_time + transmit_time + queue_time + process_time + return_time + wake_time + actuation_or_ack_time
energy_total = active_compute + radio_send + radio_receive + idle_wait + sleep_leakage + wake_cost + retry_cost + management_overhead
The point is not to make the equation perfect. The point is to stop hidden costs from disappearing. A design that ignores sleep leakage, wake time, retransmissions, or queueing can pass a small demo and fail in the field.
18.7 Measurements That Matter
18.7.1 Active compute
Measure the energy and time to run the local algorithm, including sensor readout, preprocessing, inference, encryption, compression, and logging.
18.7.2 Radio path
Measure transmit, receive, connection setup, acknowledgements, retransmissions, and the difference between local, site, and WAN paths.
18.7.3 Idle and sleep
Measure the energy spent while waiting. Low average energy usually comes from sleep behavior, not only from faster active computation.
18.7.4 Wake penalty
Measure how long it takes a device, gateway, container, radio, or model to become ready after a low-power state.
18.7.5 Queueing and contention
Measure fog response under realistic concurrent workloads, not only in an empty lab.
18.7.6 Recovery overhead
Measure how much energy and latency are added by reconnecting, replaying buffers, resyncing state, or retrying failed work.
18.8 The Energy-Latency Review Loop
Run the review as a loop because measurements age. Workloads grow, batteries age, firmware changes, fog nodes acquire new tasks, and wireless conditions move.
Inspect Figure 18.2 before continuing. Energy and latency evidence ages as firmware, batteries, traffic, and radio conditions change. Figure 18.2 turns the initial tier comparison into a recurring operational review.
In the diagram Figure 18.2, State the budgets fixes the deadline, energy limit, and acceptable degradation; Measure the tiers tests Edge, Fog, and Cloud under representative load and link conditions. Choose the tier rejects any option that misses response, energy, data-boundary, or fallback needs, then Verify degraded exercises overload, network loss, sleep wake-up, queue replay, and updates. Record sampling cadence, useful-result definition, p50 and p95 response, joules per result, battery or supply condition, radio retries, queue age, processing load, fallback outcome, measurement owner, and the firmware, topology, traffic, or battery change that triggers a retest. Preserve the measurement date and test load with that record. The worked vibration check places Edge at 5 mJ and 40 ms, Fog at 3 mJ and 120 ms, and Cloud at 12 mJ and 500 ms against the stated 8 mJ and 200 ms budgets, showing exactly why review triggers must reopen the decision.
1. State the response and energy budgets. Write the required action, deadline, energy limit, and acceptable degradation.
2. Measure candidate tiers. Measure edge, fog, and cloud paths under representative load and link conditions.
3. Choose a feasible operating point. Reject any tier that misses the response budget, energy budget, data boundary, or fallback requirement.
4. Verify degraded behavior. Test overload, network loss, sleep wake-up, queue replay, and management updates.
5. Set review triggers. Reopen the decision when load, firmware, battery, radio, site count, or policy changes.
18.9 Placement Patterns
18.9.1 When Edge Wins
Choose edge processing when immediate action is mandatory, the computation fits the device, the payload is small, or the radio cost would exceed the compute cost.
18.9.2 Strong edge signal
The action must continue without any gateway, broker, WAN, or remote service.
18.9.3 Strong edge signal
The local algorithm consumes less energy than waking the radio, negotiating a connection, and sending the payload.
18.9.4 When Fog Wins
Choose fog processing when local coordination changes the result: several devices need a shared view, raw data can be reduced before leaving the site, the cloud path is not reliable enough for the local obligation, or the fog node can enforce priority and fallback behavior.
18.9.5 Strong fog signal
Local aggregation turns many readings into a smaller site data product that still satisfies reporting and audit requirements.
18.9.6 Strong fog signal
The fog node can prioritize safety, alarm, or control work ahead of batch reporting during contention.
18.9.7 When Cloud Wins
Choose cloud processing when the workload tolerates remote response, needs cross-site context, uses durable fleet history, or needs compute and storage that local tiers cannot reasonably operate.
18.9.8 Strong cloud signal
The work is analytical, historical, or model-lifecycle oriented rather than an immediate local action.
18.9.9 Strong cloud signal
Local processing would add operational risk without improving the measured response or energy budget.
18.10 Duty Cycling Without Magic Numbers
Duty cycling can produce large energy savings, but only when the application can tolerate the sleep interval and wake penalty. Treat every duty-cycle claim as conditional.
18.10.1 Useful question
“What is the longest quiet period we can allow before the next measurement or response?”
18.10.2 Useful question
“What event can wake the system early, and what is the measured wake-to-action time?”
18.10.3 Weak claim
“Deep sleep is always better because active power is high.”
18.10.4 Weak claim
“The gateway can sleep for a fixed interval because the average response target looks acceptable.”
18.10.5 Duty-Cycle Record
18.10.6 Record this before accepting a sleep policy
18.11 Compute, Transmit, and DVFS Break-Even
The simplest offload test compares the energy spent computing locally with the energy spent moving the input and receiving the result. That comparison is only the first gate. A lower-energy offload still fails if queueing, round-trip time, protocol overhead, or fallback behavior misses the response budget.
E_local ~= P_cpu * T_compute E_offload ~= P_tx * T_tx + P_rx * T_rx T_tx ~= data_size / bandwidth
The ratio matters. Heavy compute on a compact input can favor fog because a small radio transfer replaces a costly local calculation. Light compute on a large payload usually favors local processing or pre-filtering because transmission time and radio energy rise with data size and weak links.
18.11.1 Local break-even signal
Choose local processing when the payload is large, the link is weak, the result must survive gateway loss, or the task can finish within budget using the device’s available energy.
18.11.2 Offload break-even signal
Choose fog offload when compact features replace heavy local compute, the fog queue is bounded, and the added round trip still leaves response-budget margin.
18.11.3 DVFS option
When a local task has deadline slack, dynamic voltage and frequency scaling can reduce energy by running slower at lower voltage.
18.11.4 DVFS limit
Leakage current and the task deadline set the floor; slowing a task indefinitely does not make energy approach zero.
Use a concrete ledger before accepting the placement. If a local classifier draws 40 mW for 150 ms, local energy is about 6 mJ. If sending compact features draws 120 mW for 20 ms and receiving the result draws 60 mW for 5 ms, the radio side is about 2.7 mJ before queueing and protocol overhead. Offload is attractive only if the measured round trip, fog queue, and fallback policy meet the response budget. If the payload grows tenfold, transmission can erase the saving. If deadline slack exists, DVFS may reduce the 6 mJ local path without using the radio at all.
18.11.5 Real Systems That Prove the Break-Even Model
The break-even test above is not only a classroom exercise. Two published mobile-systems examples run the same comparison in the field, and neither one settles for a universal answer.
18.11.6 MAUI: profile before you offload
MAUI is a mobile-device framework that profiles each code component’s energy cost, then decides at runtime whether to run it locally or offload it, accounting for the energy and latency cost of moving the code and data rather than only the cost of running it. The decision is made per component and per network condition, not as one always-local or always-cloud setting for the whole app.
18.11.7 LEO: the scheduler must pay for itself
LEO is a low-power scheduler for continuous audio-sensing apps such as emotion recognition, speaker identification and counting, gender estimation, and ambient sound detection. It runs low-overhead heuristics on a dedicated low-power unit to route each job to whichever local resource, CPU, DSP, or GPU, fits its deadline and energy profile, falling back to the cloud only when local options cannot keep up. On a 10-app workload, LEO’s own scheduling overhead measured under 0.5% of device energy and took about 100 ms; scheduling the same workload in the cloud, LEO’s own “next best alternative” baseline, cost about 3.5%.
18.11.8 Read the ratio, not the number
The same study also benchmarked an optimized on-device GPU pipeline for a keyword-spotting workload: it ran more than 6x faster than sending the job to the cloud, more than 21x faster than a naive sequential CPU pass, and beat the cloud on energy once batching was applied. Those multiples describe one workload on one mobile GPU against one cloud baseline. Re-measure on the actual hardware, workload, and radio before repeating them.
18.11.9 MAUI and LEO do not replace the ledger
Both systems still start from the same two numbers this chapter builds: local compute energy against transfer energy. What they add is a runtime that keeps re-measuring and re-deciding instead of hard-coding the answer once.
The mathematical gist. At one window/s, 6.00 mJ local processing costs 0.144 Wh/day, while 2.70 mJ radio offload costs 0.0648 Wh/day. A 3 Ah, 3.7 V cell retains about 8.85 Wh after six months at 2% monthly self-discharge and 10% derating. The ideal runtimes are therefore 61.5 and 137 days: the same 2.22× ratio as .
18.12 Worked Example: Greenhouse Irrigation Gateway
A greenhouse uses soil sensors, valve controllers, and a local gateway. The cloud dashboard helps with seasonal planning, but the irrigation decision must continue during a WAN outage. The target is not sub-second control; the farm needs a reliable local decision within the agronomy response window while preserving battery life.
18.12.1 Edge responsibility
Sensors timestamp readings, reject impossible values, and preserve a last-known-safe reporting mode.
18.12.2 Fog responsibility
The gateway correlates soil moisture, valve state, pump status, weather cache, and recent readings; it decides when local irrigation should start or defer.
18.12.3 Cloud responsibility
The cloud stores long-term trends, adjusts seasonal policy, compares greenhouse zones, and supports model updates.
18.12.4 Operations responsibility
Operators test the local decision path, review battery reports, rotate credentials, and validate replay after outages.
18.12.5 Example placement record
The important result is not a universal saving percentage. The important result is a placement that names the local obligation, measures the energy and latency path, and gives operators a test they can repeat.
18.13 Label the Optimization Record
Use the diagram to identify the core parts of an energy-latency decision: budgets, measurements, tier selection, fallback policy, and verification record.
18.14 Code Challenge: Choose a Feasible Tier
18.15 Common Mistakes
18.15.1 Claiming universal savings
Do not reuse a percentage from another radio, workload, or site as if it applies everywhere.
18.15.2 Ignoring queueing
A fog node that is fast when empty can miss deadlines when it shares CPU, GPU, disk, or network with other workloads.
18.15.3 Treating sleep as free
Sleep saves energy only if wake time, wake energy, and missed-event behavior fit the response budget.
18.15.4 Optimizing the device only
A design can save sensor energy while making the gateway, network, or operations burden unacceptable.
18.15.5 Hiding retry behavior
Poor wireless links, reconnect storms, and replay after outage can dominate both latency and energy.
18.15.6 Forgetting review triggers
Measurements must be revisited when firmware, batteries, site count, traffic mix, or policy changes.
18.16 Review Checklist
Before accepting a fog energy-latency design, confirm that the record includes:
- The response budget and the consequence of missing it.
- The energy budget and the unit of accounting: per event, per hour, per day, or per battery life target.
- Measured edge, fog, and cloud candidate paths under representative load.
- Active, radio, idle, sleep, wake, retry, queueing, and recovery components.
- Data-boundary and privacy constraints that affect placement.
- Fallback behavior when the preferred tier is overloaded, asleep, disconnected, or unhealthy.
- Verification screenshots, logs, traces, or power profiles that a reviewer can inspect.
- Review triggers that reopen the decision before the measurements become stale.
18.17 Reference Notes
- Use device power profilers, gateway telemetry, packet captures, and application traces when possible. Datasheet values are useful for estimates, but acceptance should come from measured deployment-like behavior.
- Treat radio energy as stateful. Connection setup, listening windows, retries, acknowledgements, and roaming can matter as much as payload bytes.
- Treat latency as a path. Transmission time alone does not include queueing, wake-up, processing, result return, actuation, or acknowledgement.
- Use cloud, fog, and edge together when their responsibilities differ. The goal is not to crown one tier, but to assign the work each tier can prove.
18.18 Debate: Edge vs. Cloud Processing Placement
This scenario is drawn from a manufacturing predictive-maintenance deployment and is meant to be worked through as a design-decision exercise.
18.18.1 Edge vs Cloud Processing
Keep One Urgent Decision Local
Picture a cold-room alarm that reaches the cloud after the safe response time has passed. Its audit history may travel later, but the urgent action cannot wait for an uncertain path.
Bandwidth means how much data a path can carry in a given time. Latency means the delay from an event to the response that depends on it.
Run the same event locally and through the cloud, then slow and disconnect the link. Keep event and action times, bandwidth use, latency, decision, missed deadline, buffered history, and recovery order.
This comparison covers one workload and failure set, not a universal placement rule. The prompt below asks which responsibilities belong near the device and which can move upstream.
Scenario: A manufacturing plant monitors 1,000 machines with vibration sensors (1kHz sampling). Goal: Predict failures before they happen.
Question: Where should the ML inference run?
Position A: Edge processing
- Lower latency for real-time alerts
- Bandwidth savings
- Works during network outages
Position B: Cloud processing
- More powerful models
- Centralized model updates
- Cross-plant pattern detection
Your Task: Each person picks a position and must defend it for 3 minutes. Then switch sides.
18.19 Summary
Fog energy and latency optimization is a measurement practice. Start with the response and energy budgets, measure each candidate tier, reject operating points that miss constraints, and record fallback behavior. The strongest fog designs are not the ones with the boldest savings claim; they are the ones that keep working when load, link quality, battery state, and local obligations change.
18.20 Concept Relationships
18.20.1 Duty cycling
Controls average energy by changing awake time, but must be checked against wake penalty and missed-event risk.
18.20.2 Resource allocation
Turns a single workload measurement into a shared-node question: queues, priority, fairness, and overload.
18.20.3 Data gravity
Supports fog when moving raw data costs more than moving compact local data products.
18.20.4 Network selection
Changes radio energy, connection setup, retry behavior, and round-trip latency.
18.20.5 Fallback design
Defines what continues, degrades, queues, or escalates when the preferred operating point fails.
18.20.6 Operations
Owns firmware changes, battery replacement, telemetry, alarms, tests, and decision review.
18.21 What’s Next
18.21.1 Fog Optimization and Privacy
Apply the energy-latency record to production-style fog use cases, privacy boundaries, and local data products.
18.21.2 Fog Production Framework
Turn measured placement decisions into operational controls, rollout checks, and production governance.
18.21.3 Context-Aware Energy
Connect the duty-cycle record to broader IoT power-management and adaptive sampling patterns.
18.22 Key Takeaway
Energy and latency must be optimized together. Moving work to fog can reduce device energy and response time, but extra communication, gateway load, and always-on infrastructure can erase the benefit.