15 WSN Energy: Adaptive Duty-Cycle Evidence

iot

wireless-sensor-networks

energy

15.1 Start With the Decision

A fixed sleep plan can miss a burst or waste power in quiet hours. Adaptive control needs trusted inputs and measured guardrails.

15.2 Route Overview

This is part 2 of 2. Review WSN Energy: Duty-Cycle Foundations for the preceding evidence.

15.3 Learning Objectives

Select inputs for an adaptive duty-cycle policy.
Verify energy, coverage, latency, and reporting tradeoffs.

15.4 Chapter Roadmap

Adaptive Duty-Cycle Inputs
Energy Evidence and Measurement
Coverage, Latency, and Reporting Path
Hotspots and Load Balance
Duty-Cycle Evidence Record
Phoebe’s Field Notes: Two Different Things Both Called “Duty Cycle”
Worked Review: Greenhouse Monitoring
Worked Review: Perimeter Alarm
Worked Review: Pipeline Valve Wake Rule
Common Duty-Cycle Mistakes
Review Checklist
Knowledge Check: Active Redundancy
Knowledge Check: Reusing a Schedule
Matching: Duty-Cycle Evidence
Ordering: Duty-Cycle Review
Figure Review: Energy per Accepted Delivery
Summary
Key Takeaway
Concept Relationships
What’s Next

15.5 Adaptive Duty-Cycle Inputs

Some WSN schemes change wake and transmit behavior from evidence rather than from a fixed timer. An InTSeM-style rule adjusts a node’s transmission rate or sleep time when the current reading, neighbor context, or expected information gain changes. A social-sensing duty-cycle rule uses an outside signal, such as a public event indicator or local context feed, to increase wake probability around likely rare events and relax it when the event is unlikely.

Information value Name the signal that makes a reading more or less useful: local change, neighbor contrast, uncertainty, missed-event cost, or application priority.

Bounded adaptation Record minimum and maximum wake or transmit rates so an adaptive rule cannot silently become always awake or always asleep.

Rare-event evidence Preserve the trigger source, false-trigger context, event class, and rule that separates a rare event from ordinary background activity.

Network consequence Retest relay availability, queueing, retransmissions, and gateway delivery after the duty-cycle rule changes.

Adaptive duty cycling is accepted only when it preserves the monitoring decision. Saving energy by sleeping through an informative rare event is a failed schedule, even if the average current looks excellent.

15.5.1 Probabilistic Rare-Event Adaptation

An external signal can be useful when the physical event is rare but leaves advance evidence elsewhere. A public-event feed, weather warning, maintenance schedule, crowd report, or local context service can produce an estimate $\hat p_t=P(E_t=1\mid x_t)$ that event $E_t$ will occur during interval $t$ . That estimate must change a bounded probability of being awake, not become an unqualified command from an untrusted feed.

Map the estimate into a legal duty-cycle range:

D_t=D_{\min}+(D_{\max}-D_{\min})a_t, \qquad 0\le a_t\le 1.

Here $a_t$ is the automaton’s current action, while $D_{\min}$ preserves baseline coverage and $D_{\max}$ caps energy and congestion. A node can implement $D_t$ as a longer listen window, more frequent wake windows, or a probability of enabling a sensing cycle. The record must state which interpretation is used.

A weak-estimation learning automaton updates $a_t$ from uncertain reinforcement rather than pretending every external hint is true. One compact linear reward-penalty form is

a_{t+1}=\operatorname{clip}_{[0,1]} \left(a_t+\alpha r_t(1-a_t)-\beta(1-r_t)a_t\right),

where $r_t\in[0,1]$ is confidence that the higher-awake action was useful, $\alpha$ is the reward step, and $\beta$ is the penalty step. A confirmed rare event after an elevated external estimate pushes $a_t$ upward; repeated false hints pull it down. Small steps smooth noisy evidence. A timeout or abrupt contradictory local observation can reset the state faster when safety requires it.

The implementation loop is:

timestamp and authenticate the external evidence where possible;
estimate event probability and expose its source, age, and confidence;
update the bounded automaton state;
convert that state into an explicit wake schedule;
measure local detections, false triggers, missed events, latency, and energy;
feed that outcome into the next update while retaining $D_{\min}$ as the independent coverage floor.

This scheme fails safely only if stale feeds expire, adversarial or duplicated reports cannot force permanent high duty, and absence of social evidence cannot suppress locally detected danger. Compare it against a fixed-duty baseline using missed-event probability, false-wake energy, reporting latency, and battery cost—not only average current.

15.6 Energy Evidence and Measurement

Average power estimates are helpful during design, but a WSN review should not approve a duty cycle from a calculator alone. Hardware draws different current during boot, sensor warm-up, radio listen, transmit, retries, encryption, storage, sleep, and fault recovery. Firmware and field conditions can change the result.

Measure the deployed state: Record sleep current, wake current, radio work, sensor stabilization, retries, logging, and any always-on support circuits.

Measure weak cases: Include poor links, repeated retransmission, cold start, low battery, high event rate, firmware update, and recovery from gateway loss when those cases affect the claim.

Keep the estimate honest: Use lifetime calculations as planning evidence, then replace assumptions with measured current and service observations as soon as pilot data is available.

The point is not to ban calculations. The point is to avoid pretending that a clean spreadsheet proves real battery life. The accepted record should say which current was measured, in what operating state, with what traffic, and under what environmental or installation conditions.

15.6.1 Radio State Energy Budget

Current alone does not decide the cheaper radio burst. The useful comparison must include startup, transmit airtime, acknowledgement listening, delivery probability, and the retry cap, then divide the expected opportunity energy by the probability that useful payload arrives.

Walk through the embedded ledger from Short reliable to Fast short. The TX current rises from 30 mA to 60 mA, yet the bitrate rises from 250 kb/s to 1,000 kb/s and shortens both payload and ACK airtime, so energy per delivered bit falls. Then choose Fast long range: higher TX current and a lower independent delivery probability increase expected failed attempts, reversing the advantage. Read startup, transmit, receive/ACK, and failed-attempt expectation separately before using the total.

Radio energy per useful bit depends on range, bitrate, packet length, and fixed state-transition costs together. Separate the energy paid once per burst from the energy paid while bits are moving:

E_{\text{burst}}=E_{\text{start}}+P_{\text{tx}}(d)\frac{L}{R_b}+P_{\text{rx}}t_{\text{ack}}+E_{\text{retry}},

where $E_{\text{start}}$ includes oscillator, synthesizer, calibration, and state-transition work; $P_{\text{tx}}(d)$ is transmit power at the level needed for reach $d$ ; $L$ is transmitted bits including headers; and $R_b$ is PHY bitrate. Ignoring acknowledgements and retries for a first comparison,

E_b=\frac{E_{\text{burst}}}{L} \approx \frac{E_{\text{start}}}{L}+\frac{P_{\text{tx}}(d)}{R_b}.

The first term explains why short, slow bursts can be expensive: startup energy is divided among too few useful bits. A higher bitrate shortens the on-air interval and can reduce the second term, provided the faster PHY does not require enough extra transmit power, bandwidth, or retransmissions to erase the saving.

Reach is often the stronger lever. A simple radio model writes transmit energy for $L$ bits over distance $d$ as

E_{\text{tx}}(L,d)=L E_{\text{elec}}+L\varepsilon d^n,

with path-loss exponent $n$ near 2 in free space and commonly larger in clutter. Doubling range can therefore multiply the amplifier term by $2^n$ —four times at $n=2$ , eight times at $n=3$ , and sixteen times at $n=4$ . A nominally efficient high-rate direct link can lose to shorter multihop links once required reach and fade margin are included; the relays’ receive and startup energy must then be added to the comparison.

For each candidate radio mode, calculate and then measure: startup duration and energy, active bitrate, complete frame bits, transmit level, achieved range margin, burst duration, receive/ACK cost, retry distribution, and sleep leakage. Report both energy per air bit and energy per accepted application bit. The latter catches header overhead and lossy links that make a fast datasheet number look deceptively efficient.

15.7 Coverage, Latency, and Reporting Path

Energy savings can break a monitoring claim in three main ways: the sensor is asleep when the event happens, the relay path is asleep when the packet must move, or the delay is too long for the required response.

Coverage risk A low-duty sensor may not observe a short event unless the event lasts longer than the sleep interval or a separate wake source is reliable.

Latency risk A reading can be technically collected but arrive too late for alarm, control, safety, or operational response.

Delivery risk Multi-hop networks need awake relays, usable links, gateway availability, and retry behavior that does not drain the weakest nodes.

Slow environmental trends often tolerate longer sleep intervals. Intrusion, leak, fire, machinery protection, and safety-adjacent uses usually need shorter wake paths or separate event triggers. Do not reuse one schedule across these cases without a new review.

15.8 Hotspots and Load Balance

Duty cycling is not only a leaf-node problem. Nodes close to a gateway may relay traffic for many others. Cluster heads, repeaters, and gateway-adjacent nodes can spend more time awake than edge nodes, so their service interval may be shorter even when the nominal duty-cycle rule is the same.

Review relay roles separately: A node that senses only its own environment and a node that forwards traffic for a group should not share an untested battery-life promise.

Check burst behavior: A schedule that works for quiet periodic reporting can fail during storms, alarms, commissioning, diagnostics, or firmware updates.

Record mitigation: Extra relays, mains power, gateway relocation, load-balanced routing, local aggregation, or narrowed claims can be valid if the evidence supports them.

The safest review habit is to ask which node dies first and what claim fails when it does. Average lifetime is less useful when one sleeping relay or one depleted gateway-side node creates a blind spot.

15.9 Duty-Cycle Evidence Record

A list cannot settle Duty-Cycle Evidence Record alone. Inspect Figure 15.1, where WSN Duty-Cycle Evidence Record and MONITORING CLAIM make WSN duty-cycle evidence record concrete.

Wireless sensor network duty-cycle evidence record with nine fields: monitoring claim, duty rule showing a 200 millisecond listen window per 2 second frame giving a 10 percent duty cycle, active set, measured current of about 1.8 milliamps with the radio off and about 20 milliamps while listening or transmitting, latency evidence, delivery path, decision with known limit, service owner, and retest trigger. — Figure 15.1: WSN duty-cycle evidence record

Three labels control the Figure 15.1 visual: WSN Duty-Cycle Evidence Record retains verification evidence; MONITORING CLAIM names a responsibility; What must stay names a responsibility. Retaining both WSN Duty-Cycle Evidence Record and What must stay makes WSN duty-cycle evidence record auditable. For Duty-Cycle Evidence Record, retain MONITORING CLAIM when applying this result.

Phoebe’s Field Notes: Two Different Things Both Called “Duty Cycle”

The mathematical gist. A 10% MAC listen duty with 1.8 mA off and 20 mA active gives $I_{avg}=3.62$ mA, not 2.00 mA, because the receiver still draws current during the other 90%. A typical 1600 mAh usable cell then gives about 442 h or 18.4 days, while the active pulse sags 0.0600 V to 3.54 V. Separately, a 1% regulatory transmit duty allows 36 s/hour; it is not the 10% listen schedule.

15.10 Worked Review: Greenhouse Monitoring

A greenhouse team wants temperature and humidity trends overnight. The readings support crop management, not immediate safety alarms. The team proposes a low-duty schedule to reduce battery visits.

Claim: Overnight temperature and humidity trends are recorded across the growing bay, including weak zones near doors and fans.

Duty rule: Nodes wake on a planned interval, allow sensor stabilization, record the reading, and send through the accepted gateway path.

Evidence needed: Measured current during sampling and radio transfer, successful delivery from weak locations, and comparison against reference readings during a pilot period.

Accepted limit: The schedule supports slow environmental trend monitoring. It does not support fast alarms unless a separate wake rule and latency review are added.

Retest trigger: Reopen the review after fan changes, crop layout changes, gateway relocation, new enclosure, repeated missed readings, or changed reporting interval.

This is a reasonable place for a conservative sleep schedule because the monitored phenomenon changes slowly and the consequence of delayed readings is operational rather than immediate safety response. The same schedule would not automatically pass for fire detection or intrusion alarms.

15.11 Worked Review: Perimeter Alarm

A facility wants a WSN along a fence line to report crossing events. The first proposal reuses the greenhouse sleep schedule because the hardware is similar.

Claim: Fence-line crossings are detected and reported within the accepted response window.

Problem: A long periodic sleep interval may miss short crossing events or report them too late.

Repair path: Add an event wake source, shorten the active interval, add always-awake relay points, narrow the claim, or use a different device class where needed.

Evidence needed: Event replay, missed-event testing, weak-link delivery tests, false-trigger rate, and measured current during alarm bursts.

Decision: Do not approve the reused greenhouse schedule until event and latency evidence support the perimeter claim.

The hardware may be the same, but the monitoring claim is different. Duty-cycle approval belongs to the claim, not to the device model.

15.12 Worked Review: Pipeline Valve Wake Rule

A utility monitors named valves along a long route. Most readings are routine, but selected valves require faster reporting after a pressure anomaly.

Claim: Named valves have routine status reporting, and selected critical valves report anomaly state through the accepted gateway path.

Duty rule: Routine nodes wake on a scheduled interval. Critical valves have a separate event wake rule and a validated relay path.

Evidence needed: Measured current for routine and anomaly states, gateway delivery from weak route segments, and relay behavior during burst traffic.

Known limit: Noncritical route segments are not approved for immediate alarm response unless they join the event wake rule and pass latency tests.

Retest trigger: Reopen after valve additions, gateway movement, terrain change, repeated retransmission, maintenance-route change, or firmware change.

This example shows why hybrid schedules are common. A single duty cycle for every node can either waste energy on routine points or underprotect critical points.

15.12.1 Interactive: Price the Wake Rule, Not Just Sleep Current

The pipeline review needs a whole-cycle comparison because every scheduled wake pays oscillator, restore, sensing, and response-latency costs. Start with the long-sleep preset below, then shorten only the wake interval. Watch when retained standby overtakes cold shutdown even though its sleep current is higher.

Record the selected state together with its wake latency and retained-state assumptions. That makes the greenhouse, perimeter, and valve policies comparable without pretending that one sleep-current number approves all three claims.

15.13 Common Duty-Cycle Mistakes

Counting sleeping sensors as coverage Installed devices should not satisfy the claim unless their wake rule supports the active monitoring state.

Approving a percentage without a latency test A low duty cycle may be fine for trend logging and unacceptable for alarms.

Ignoring relay burden Gateway-side nodes and cluster heads may wake more often than edge nodes because they carry other nodes' traffic.

Using spreadsheet lifetime as field proof Battery estimates need measured current, traffic evidence, and service observations before approval.

Forgetting recovery states Retries, reconnects, firmware updates, calibration, and gateway failures can dominate energy during weak periods.

No retest trigger Duty-cycle assumptions drift after sensor replacement, firmware updates, layout changes, traffic growth, and new alarms.

15.14 Review Checklist

Before accepting a WSN duty-cycle design, check:

Is the monitoring objective written as a testable claim? Which installed nodes actually count in the active state? What wakes the node, and what keeps it awake long enough to do useful work? Does the schedule meet the required latency for the claim? Does the radio path work when relays, gateways, retries, and bursts are considered? Was current measured in the deployed state, including weak cases? Does the service interval match the maintenance team and site access? Are relay, cluster-head, or gateway-adjacent nodes reviewed separately? Does the record state what the schedule does not support? What exact change reopens the duty-cycle review?

Knowledge Check: Active Redundancy

Knowledge Check: Reusing a Schedule

15.15 Matching: Duty-Cycle Evidence

15.16 Ordering: Duty-Cycle Review

The hardware overlay in Figure 15.2 prevents a duty-cycle percentage from hiding which components actually wake.

Transducer, bridge, amplifier and filter, ADC, MCU, and radio stages are placed over a power timeline with RTC-only sleep for one second and a one millisecond active interval. — Figure 15.2: A sensor signal chain is aligned to a one-second sleep interval and one-millisecond active acquisition and communication window.

Read Figure 15.2 from SLEEP · 1.000 s to ACTIVE · 1 ms. The active window is not radio airtime alone: Bias / bridge, Amp + filter, ADC, MCU, and Radio each need a measured duration, and their startup, acknowledgement, and retry costs determine the true duty-cycle energy record.

At night, Packet Pete waits beside a dim sleeping farm sensor whose small timer remains lit, showing low-power sleep rather than power-off. — CW-0003 walkthrough: a low-power node wakes the needed parts, samples, reaches an awake next hop, and sleeps again within its delay limit.

Pete follows arrows through the sensor path, processor, and radio as each required part wakes inside one active window. — CW-0003 walkthrough: a low-power node wakes the needed parts, samples, reaches an awake next hop, and sleeps again within its delay limit.

15.17 Figure Review: Energy per Accepted Delivery

Radio comparisons should normalize the complete burst budget by successfully delivered payload bits at the same reach and packet-error rate.

Illustrative radio energy-per-bit curves across link reach for low, mid, and high data rates, showing a high-rate retry cliff, beside a burst-energy breakdown for startup, electronics, RF power, receive acknowledgements, and retries. — Figure 15.3: Radio energy per delivered bit and burst decomposition.

Figure 15.3 shows high-rate · retry cliff starting below the other curves before rising sharply at long reach; the DECOMPOSE ONE BURST ledger then keeps startup, electronics, RF power, ACK/receive, and the 1/(1−PER) retry multiplier visible.

15.18 Summary

WSN duty cycling is a claim-level design decision. It can reduce service effort and extend operation, but only when the sleep schedule still supports coverage, latency, and delivery. The accepted record should name the active state, wake rule, measured current, weak-case behavior, service model, decision, known limits, owner, and retest trigger.

Do not approve a duty cycle because the percentage looks low or because it worked in a different deployment. Approve it when evidence shows that this schedule supports this monitoring claim in the deployed state.

15.19 Key Takeaway

WSN Energy Duty Cycling should tie sampling, sleep scheduling, duty cycle, communication cost, battery budget, latency, and deployment evidence into one lifetime model.

15.20 Concept Relationships

Duty cycling connects directly to coverage, deployment sizing, routing, gateway placement, and maintenance planning. Coverage tells which active sensors must observe the environment. Deployment sizing decides how many nodes and relays are needed. Routing and gateway design decide whether readings can leave the field. Maintenance planning decides whether the accepted service interval is realistic.

15.21 What’s Next

The next chapter, Duty Cycle Worked Examples, turns the schedule evidence into concrete battery, latency, and relay-role calculations.

15.22 Continue Your Route

This final part closes the route from Adaptive Duty-Cycle Inputs through What’s Next. Return to WSN Energy: Duty-Cycle Foundations or continue from the wsn module index.