20 Fog Energy-Latency Tradeoffs
Measure the Tradeoff Before Moving Work
20.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.
20.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.
20.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.
20.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.
20.5 The Stable Tradeoff Model
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.
20.5.1 Interactive: Compare Edge, Fog, and Cloud Latency
20.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.
20.5.3 Fog
Best when local coordination, filtering, buffering, priority, or short-site-path communication changes the measured budget.
20.5.4 Cloud
Best when the workload tolerates remote response, needs durable fleet context, or benefits from compute that local tiers cannot provide.
20.6 Build the Budget
A fog energy-latency review starts with two budgets and one set of measurements.
20.6.1 Response budget
Define the maximum elapsed time from event or sample arrival to the action, warning, data product, or acknowledgement that matters.
20.6.2 Energy budget
Define the allowed energy per event, per sample window, per hour, or per day, depending on what limits the deployment.
20.6.3 Load condition
Record device count, report rate, competing workloads, queue depth, radio condition, and expected bursts.
20.6.4 Fallback condition
Record what happens when the preferred tier is unavailable, overloaded, asleep, thermally limited, or disconnected.
20.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.
20.7 Measurements That Matter
20.7.1 Active compute
Measure the energy and time to run the local algorithm, including sensor readout, preprocessing, inference, encryption, compression, and logging.
20.7.2 Radio path
Measure transmit, receive, connection setup, acknowledgements, retransmissions, and the difference between local, site, and WAN paths.
20.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.
20.7.4 Wake penalty
Measure how long it takes a device, gateway, container, radio, or model to become ready after a low-power state.
20.7.5 Queueing and contention
Measure fog response under realistic concurrent workloads, not only in an empty lab.
20.7.6 Recovery overhead
Measure how much energy and latency are added by reconnecting, replaying buffers, resyncing state, or retrying failed work.
20.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.
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.
20.9 Placement Patterns
20.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.
20.9.2 Strong edge signal
The action must continue without any gateway, broker, WAN, or remote service.
20.9.3 Strong edge signal
The local algorithm consumes less energy than waking the radio, negotiating a connection, and sending the payload.
20.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.
20.9.5 Strong fog signal
Local aggregation turns many readings into a smaller site data product that still satisfies reporting and audit requirements.
20.9.6 Strong fog signal
The fog node can prioritize safety, alarm, or control work ahead of batch reporting during contention.
20.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.
20.9.8 Strong cloud signal
The work is analytical, historical, or model-lifecycle oriented rather than an immediate local action.
20.9.9 Strong cloud signal
Local processing would add operational risk without improving the measured response or energy budget.
20.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.
20.10.1 Useful question
“What is the longest quiet period we can allow before the next measurement or response?”
20.10.2 Useful question
“What event can wake the system early, and what is the measured wake-to-action time?”
20.10.3 Weak claim
“Deep sleep is always better because active power is high.”
20.10.4 Weak claim
“The gateway can sleep for a fixed interval because the average response target looks acceptable.”
20.10.5 Duty-Cycle Record
20.10.6 Record this before accepting a sleep policy
20.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.
20.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.
20.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.
20.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.
20.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.
Phoebe’s Why
Power is the rate energy is spent, so energy is just power held constant over a stretch of time – multiply the two and the millijoule ledger above is already physics, not bookkeeping. What turns that ledger into a battery-life claim is the cell itself: its printed mAh times its terminal voltage sets an energy budget, but self-discharge quietly leaks some of that budget away even while idle, and a derating margin has to be reserved so the gateway shuts down cleanly instead of browning out mid-task. None of that changes the millijoule-per-window comparison – it only sets how many such windows the battery can actually pay for before the next service visit.
The Derivation
Energy from a near-constant power draw held for a duration:
\[E = P \times t\]
Charge and delivered energy, related through terminal voltage:
\[E_{cell}\,\mathrm{(Wh)} = C\,\mathrm{(Ah)} \times V\]
Usable energy after self-discharge over time \(t\) and a derating margin \(\delta\):
\[E_{usable} = E_{cell}\,(1-k)^{t}\,(1-\delta)\]
Field runtime between service visits, from a fixed daily energy draw \(E_{day}\):
\[\mathrm{runtime} = \frac{E_{usable}}{E_{day}}\]
Worked Numbers: The Gateway’s Battery Between Visits
Recomputing the chapter’s own figures precisely: \(E_{local} = 40\times150/1000 = 6.00\) mJ; \(E_{radio} = (120\times20 + 60\times5)/1000 = 2.70\) mJ – both match the chapter’s “about 6 mJ” and “about 2.7 mJ” exactly.
The chapter does not fix a repeat rate or a cell, so take standard assumptions: one analysis window per second, and an 18650 Li-ion cell (\(V=3.7\) V, \(C_0=3000\) mAh).
- Daily draw if always local: \(6.00\ \mathrm{mJ}\times86{,}400 = 518{,}400\) mJ \(= 0.144\) Wh/day. Always offloaded: \(2.70\times86{,}400 = 233{,}280\) mJ \(= 0.0648\) Wh/day.
- Usable cell energy: \(E_{cell}=3000\times3.7/1000=11.1\) Wh; after a standard 2%/month Li-ion self-discharge over a 6-month service interval and a 10% derating margin, \(E_{usable} = 11.1\times(0.98)^6\times0.90 = 8.85\) Wh.
- Runtime always-local: \(8.85/0.144 = 61.5\) days. Runtime always-offload: \(8.85/0.0648 = 137\) days – a 2.22x longer service interval, matching the \(6.00/2.70=2.22\) energy ratio exactly, as it must.
- Voltage sag at the cell: an 18650’s low internal resistance (\(R_{int}\approx0.05\ \Omega\)) against the radio’s \(120\ \mathrm{mW}/3.3\ \mathrm{V} = 36.4\) mA draw sags the terminal by only \(36.4\times0.05 = 1.82\) mV – negligible, unlike a small high-ESR coin cell under the same current.
So the break-even test in the ledger above is not just a latency-budget check: on this battery, choosing offload over local processing roughly doubles the number of days between truck rolls.
20.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.
20.12.1 Edge responsibility
Sensors timestamp readings, reject impossible values, and preserve a last-known-safe reporting mode.
20.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.
20.12.3 Cloud responsibility
The cloud stores long-term trends, adjusts seasonal policy, compares greenhouse zones, and supports model updates.
20.12.4 Operations responsibility
Operators test the local decision path, review battery reports, rotate credentials, and validate replay after outages.
20.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.
20.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.
20.14 Code Challenge: Choose a Feasible Tier
20.15 Common Mistakes
20.15.1 Claiming universal savings
Do not reuse a percentage from another radio, workload, or site as if it applies everywhere.
20.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.
20.15.3 Treating sleep as free
Sleep saves energy only if wake time, wake energy, and missed-event behavior fit the response budget.
20.15.4 Optimizing the device only
A design can save sensor energy while making the gateway, network, or operations burden unacceptable.
20.15.5 Hiding retry behavior
Poor wireless links, reconnect storms, and replay after outage can dominate both latency and energy.
20.15.6 Forgetting review triggers
Measurements must be revisited when firmware, batteries, site count, traffic mix, or policy changes.
20.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.
20.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.
20.18 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.
20.19 Concept Relationships
20.19.1 Duty cycling
Controls average energy by changing awake time, but must be checked against wake penalty and missed-event risk.
20.19.2 Resource allocation
Turns a single workload measurement into a shared-node question: queues, priority, fairness, and overload.
20.19.3 Data gravity
Supports fog when moving raw data costs more than moving compact local data products.
20.19.4 Network selection
Changes radio energy, connection setup, retry behavior, and round-trip latency.
20.19.5 Fallback design
Defines what continues, degrades, queues, or escalates when the preferred operating point fails.
20.19.6 Operations
Owns firmware changes, battery replacement, telemetry, alarms, tests, and decision review.
20.20 What’s Next
20.20.1 Fog Optimization and Privacy
Apply the energy-latency record to production-style fog use cases, privacy boundaries, and local data products.
20.20.2 Fog Production Framework
Turn measured placement decisions into operational controls, rollout checks, and production governance.
20.20.3 Context-Aware Energy
Connect the duty-cycle record to broader IoT power-management and adaptive sampling patterns.
20.21 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.