14 WSN Duty Cycling
WSN duty cycling, wireless sensor network energy, sensor node sleep schedule, active state review, WSN battery lifetime, duty-cycle evidence
14.1 Start With the Field Story
Duty cycling is the promise that a node can sleep without missing what matters. Before using a percentage, ask when the node wakes, what latency that creates, who else must be awake, and what evidence shows the coverage or route still works.
14.2 In 60 Seconds
Duty cycling is the WSN practice of turning sensing, processing, and radio work on only when the monitoring claim needs it. The review question is not simply “what percentage is awake?” The review question is whether the sleep and wake rule still supports the required coverage, latency, reporting path, and maintenance promise.
A good duty-cycle design names the active state, wake trigger, expected event timing, radio path, measured current, service interval, known limits, and retest trigger. A low duty cycle can extend service life, but it can also hide missed events, slow alarms, break multi-hop delivery, or make failed nodes look healthy. Accept the schedule only when field evidence supports the claim.
14.3 Learning Objectives
By the end of this chapter, you will be able to:
- Explain duty cycling as an operating-state decision, not only an energy-saving trick.
- Connect wake rules to coverage, latency, and reporting-path evidence.
- Compare synchronous, asynchronous, event-driven, and hybrid scheduling choices.
- Review measured current and service evidence without relying on universal lifetime claims.
- Record accepted limits and retest triggers so duty-cycle assumptions do not drift after deployment.
14.4 Quick Check: WSN Energy Duty Cycling
14.5 Duty Cycling as an Active Coverage Claim
In a WSN review, a sleeping sensor is not automatically part of the active monitoring claim. It may still be useful, but it only counts if the wake rule, event timing, and delivery path support the claim being made.
Installed state The node is physically present and may have power, calibration, and mounting evidence.
Active state The node is awake, calibrated, reachable, and able to sense or relay within the accepted time window.
Claim state The deployment promise states which active nodes, wake rules, and reporting paths are enough for the monitoring objective.
This distinction prevents a common failure: counting every installed sensor as coverage while many sensors are asleep, unreachable, waiting for a long wake interval, or unable to relay through a sleeping neighbor.
14.6 Duty-Cycle Review Route
Use Figure 14.1 to keep the energy decision tied to the monitoring claim.
The route is a loop. A field test may show that the wake interval is acceptable for slow soil moisture logging but not for leak detection. A gateway test may show that one relay schedule works during normal reporting but fails during bursts. The duty cycle should change, or the accepted claim should narrow, before the chapter record says the design is approved.
14.7 What the Schedule Must State
A duty-cycle schedule needs enough detail for another reviewer to reproduce the decision. A statement such as “nodes sleep most of the time” is not reviewable.
Sampling window How often the node samples, how long the sensor needs to stabilize, and whether the reading represents an instant, an average, or an event.
Wake trigger Time schedule, local threshold, interrupt, gateway request, neighbor message, user action, or maintenance test.
Radio path Whether the node must send directly to a gateway, wait for a relay, forward for others, or keep a receiver available for commands.
Latency limit The maximum acceptable time from physical event to recorded reading, alarm, local action, or operator notification.
Failure behavior What happens when a wake is missed, a relay sleeps, a packet is delayed, a battery is weak, or a gateway is offline.
Retest trigger The site, firmware, sensor, traffic, weather, gateway, or maintenance change that reopens the duty-cycle decision.
The same percentage duty cycle can mean very different behavior. A node that wakes for a short local sample and stores data locally has a different risk profile from a relay node that must be available to receive traffic from many neighbors.
14.8 Synchronous and Asynchronous Scheduling
Duty-cycling protocols are often introduced by name, but a review should first ask what coordination problem the schedule solves.
Synchronous schedule Neighboring nodes share planned wake windows. This can make communication more predictable when traffic is regular or multi-hop timing matters, but it needs clock and schedule maintenance.
Asynchronous schedule Nodes wake independently. This can reduce coordination overhead and suit uneven deployments, but sender and receiver timing must still be proven for the accepted latency.
Event-driven wake The node sleeps until a local sensor, interrupt, threshold, or wake source requests work. This can be effective when true events are sparse, but false triggers and missed triggers need evidence.
Hybrid schedule Some periods are scheduled, while urgent events use a separate wake rule. This is common when routine logging and alarms share the same field network.
Protocol names such as S-MAC, T-MAC, B-MAC, X-MAC, and receiver-initiated MACs are useful vocabulary, but they are not a substitute for review evidence. The acceptable choice depends on traffic pattern, latency, clock drift, relay burden, power source, and the consequence of a missed event.
14.9 MAC Protocol Evidence
Wireless MAC design balances more than throughput. A WSN review should name the required latency, throughput, scalability, fairness, bandwidth utilization, and energy efficiency before choosing a contention or scheduled access pattern. Energy waste commonly appears as idle listening by receivers, excessive transmit power or retransmission by senders, and radio start-up latency that is paid every time the node wakes.
Classic TelosB-style current traces make the scale visible: an MCU-on, radio-off state can be around 1.8 mA, while radio-on listening or transmission can sit near 20 mA, so idle listening may cost almost as much as useful transmission.
Contention-based MACs, including Wi-Fi-style carrier-sense access, let stations use random access after sensing the channel. They can be robust and scalable because nodes do not need a central slot assignment for every frame, but collision probability and backoff delay rise as more nodes contend. They also solve the transmit opportunity only; a receiver that must hear possible traffic still needs awake-time evidence.
Contention-free MACs, including TDMA-style schedules, reserve a transmission opportunity before the payload is sent. That can save energy compared with unscheduled listening because nodes know when to be active, but it introduces coordinator, synchronization, utilization, and missed-slot risks. GSM, Bluetooth scheduling, and 802.15.4 beacon/GTS behavior are examples to review by their timing evidence, not by the label alone.
Use Figure 14.2 as a first sanity check. The percentage is meaningful only after the reviewer knows what happens during each awake window and how long the claim can tolerate sleep.
S-MAC makes the idle-listening trade explicit. The node mostly sleeps, then periodically listens long enough to rendezvous with neighbors. If the listen window is 200 ms and the full frame is 2 seconds, the duty cycle is 200 ms / 2 s = 10%; the radio is off for the other 1.8 seconds. That can be low energy, but it is also high latency unless the application tolerates waiting for the next listen window, and it requires parameter choice plus clock synchronization evidence.
In an S-MAC-style review, the active period is not just “radio on.” Neighboring nodes need a common wake schedule, often advertised in a synchronization step before RTS/CTS and data exchange. If separate neighborhoods form different schedules, a bridge node may have to follow both synchronized islands, spending extra energy so packets can cross between them. That is why the evidence should name the schedule source, the neighbors that share it, and any node that must carry more than one schedule.
| Pattern | Energy idea | What the review must prove |
|---|---|---|
| S-MAC | Neighbors share fixed listen and sleep windows | Clock drift, guard time, rendezvous overlap, and per-hop latency remain acceptable |
| T-MAC | A node sleeps early when no activity appears within the timeout | The timeout does not send a relay or receiver to sleep before delayed traffic arrives |
| B-MAC | Receivers sample the channel briefly while senders use a long preamble | Sender preamble cost, overhearing cost, and receiver sample interval still fit the claim |
| X-MAC | Senders use short addressed strobes so the receiver can acknowledge early | Non-target neighbors sleep quickly, the intended receiver catches a strobe, and weak links still meet latency |
14.10 Try It: S-MAC Sleep Windows
14.11 Try It: T-MAC Adaptive Timeout
14.12 Try It: X-MAC Strobed Preambles
Low Power Listening flips the cost from receiver to sender. A long receiver sample interval saves receiver energy but forces a sender to hold the channel longer before the receiver wakes. A short sample interval catches packets faster but makes every receiver wake more often. The right point depends on packet rate, event urgency, neighbor count, and whether the node is a leaf, relay, or gateway-adjacent bottleneck.
14.13 Knowledge Check: Low-Power Listening
14.14 Rendezvous And Topology Role Review
The merged duty-cycle fundamentals and topology material make the rendezvous question explicit: sender and receiver must overlap while awake, and the required overlap changes by node role.
Review:
- cycle window, active window, wake overhead, sensing time, listen time, communication time, and sleep time
- synchronous, asynchronous, adaptive, or hybrid rendezvous method and its drift, retry, or cooldown rule
- acceptable detection latency, communication latency, missed-event behavior, stale-data rule, and retry limit
- whether the node is a leaf, relay, gateway, coordinator, cluster head, cluster member, or mesh participant
- receive windows for children or neighbors, forwarding windows toward the next hop, and buffering rules when a neighbor is unavailable
- retest after schedule, role, route, clock source, traffic pattern, or quality-rule changes
A leaf node can often sleep around its own sensing interval. A relay, cluster head, or gateway-adjacent node may need longer availability because other nodes depend on it. Do not approve a low duty-cycle percentage until the route and role evidence still support the monitoring claim.
14.15 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.
14.16 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.
14.17 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.
14.18 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.
14.19 Duty-Cycle Evidence Record
Use Figure 14.3 to make the accepted schedule easy to audit after deployment changes.
This record is intentionally compact. It should be possible to update it after a firmware change, gateway move, new sensor type, traffic increase, or field failure without rewriting the whole chapter.
Phoebe’s Why
This chapter’s 10% figure is a MAC-layer listen duty cycle – the fraction of time a node’s receiver is awake to catch a rendezvous window. That is a design choice, not a physical limit. A completely different quantity shares the same name in radio regulation: in shared sub-GHz bands, a regulator caps the fraction of each hour a transmitter may actually be on the air, and that cap is a hard legal limit tied to the chosen frequency band, not a firmware setting. Confusing the two is easy and expensive – a schedule can look energy-safe on the MAC-duty-cycle spreadsheet while the underlying radio quietly violates its regulatory airtime budget, or vice versa. And neither number, by itself, tells you how many years the battery survives, because that conversion still needs the same sag-and-derating chain used throughout this book, applied to whatever current this chapter’s own evidence record actually measured.
The Derivation
The mAh-to-Wh chain that turns a measured average current into a lifetime estimate:
\[V_{term} = V_{oc} - I\,R_{int}, \qquad E_{usable}(\mathrm{Wh}) \approx Q_{usable}(\mathrm{Ah})\times V, \qquad Q_{usable}=f_{derate}\times Q_{nominal}\]
Weighted average current from a two-state (off/active) MAC duty cycle:
\[I_{avg} = (1-D_{MAC})\,I_{off} + D_{MAC}\,I_{active}\]
A separate, regulator-imposed transmit airtime budget in a shared sub-GHz band (as established in this book’s frequency-bands chapter):
\[t_{airtime,\ max} = D_{reg}\times3600\ \text{s/hour}\]
Worked Numbers: This Chapter’s Own S-MAC Figures
Using this chapter’s own evidence-record values (\(D_{MAC}=10\%\), \(I_{off}=1.8\) mA, \(I_{active}=20\) mA) and a standard/typical WSN cell (3.6 V, 2000 mAh, \(R_{int}=3\ \Omega\), 80% derated to \(Q_{usable}=1600\) mAh, \(E_{usable}=5.76\) Wh):
- Weighted average current: \(I_{avg} = 0.9\times1.8 + 0.1\times20 = 1.62+2.00 = 3.62\) mA
- Voltage sag during the 20 mA active window: \(\Delta V = 0.020\times3 = 0.0600\) V, terminal voltage falls to \(3.54\) V
- Life: \(1600/3.62 = 442\) h \(= 18.4\) days – cross-check via energy: \(5.76\ \text{Wh}/(3.62\ \text{mA}\times3.6\ \text{V}) = 5.76/0.01303 = 442\) h, same answer
The chapter’s own “measured current” of 1.8 mA at rest – not zero – is what turns a headline 10% duty cycle into an 18-day battery life rather than months, exactly the gap the “Energy Evidence and Measurement” section above warns a clean spreadsheet can hide. That 10% figure is a receiver listen duty cycle and carries no regulatory standing by itself; if this deployment used the EU 868 MHz 1%-duty sub-band, the transmitter’s legal airtime is capped near \(0.01\times3600=36\) s/hour regardless of how the MAC schedules its listen windows, so the two duty-cycle numbers must be checked separately before either is called “safe.”
14.20 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.
14.21 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.
14.22 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.
14.23 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.
14.24 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?
14.25 Knowledge Check: Active Redundancy
14.26 Knowledge Check: Reusing a Schedule
14.27 Matching: Duty-Cycle Evidence
14.28 Ordering: Duty-Cycle Review
14.29 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.
14.30 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.
14.31 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.
14.32 What’s Next
The next chapter, Duty Cycle Worked Examples, turns the schedule evidence into concrete battery, latency, and relay-role calculations.