14 WSN Energy: Duty-Cycle Foundations

14.1 Start With the Decision

A sensor node saves energy only when its radio truly sleeps. Duty cycle links awake time, current, latency, and rendezvous work.

14.2 Route Overview

This is part 1 of 2. Continue with WSN Energy: Adaptive Duty-Cycle Evidence.

14.3 Part Objectives

• Calculate average current from active and sleep intervals.
• Choose a duty-cycle schedule from latency and lifetime needs.

14.4 Chapter Roadmap

• Start With the Field Story
• In 60 Seconds
• Quick Check: WSN Energy Duty Cycling
• Duty Cycling as an Active Coverage Claim
• Duty-Cycle Review Route
• What the Schedule Must State
• Synchronous and Asynchronous Scheduling
• MAC Protocol Evidence
• Try It: S-MAC Sleep Windows
• Try It: T-MAC Adaptive Timeout
• Try It: X-MAC Strobed Preambles
• Knowledge Check: Low-Power Listening
• Rendezvous And Topology Role Review

14.5 Start With the Field Story

Schedule Sleep Around the Event

Picture a farm node that sleeps most of the hour to save energy. A leak begins just after it sleeps, and its parent device also sleeps when the warning is sent. A low energy number is useless if the important event waits too long or has no awake path.

A duty cycle is the share of time a device stays active. Latency means the delay from an event to a useful result. Start with the event, its latest safe report time, and the other devices that must be awake. Then write each wake source, active window, listen window, send chance, retry limit, and clock allowance.

Test a normal event at the worst point in the schedule. Drift one clock, miss one wake, change a parent, and send a burst. Record energy, delay, lost reports, route state, and recovery. The schedule should make the failure visible rather than silently save power.

One schedule cannot fit every season, traffic load, or network shape. The deeper sections compare aligned and listening-based methods and show how to trade energy for timely coverage with a reviewable limit.

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.6 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.7 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.8 Quick Check: WSN Energy Duty Cycling

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

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.10 Duty-Cycle Review Route

The Duty-Cycle Review Route claim needs a visual check. In Figure 14.1, WSN Duty-Cycle Review Route sits with MONITORING CLAIM to clarify WSN duty-cycle review route.

WSN Duty-Cycle Review Route begins the visual in Figure 14.1 and exposes energy cost. Next, MONITORING CLAIM names a responsibility; finally, What must stay names a responsibility. From WSN Duty-Cycle Review Route to What must stay, the dependency expresses WSN duty-cycle review route. The Duty-Cycle Review Route review can now test MONITORING CLAIM directly.

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

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.12 Synchronous and Asynchronous Scheduling

Duty-cycling protocols are often introduced by name, but a review should first ask what coordination problem the schedule solves.

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.

Even a fixed listen/sleep percentage can be scheduled two different ways, and the review should name which one is claimed. The simplest rule switches every node’s radio off at the same wall-clock instant: it is easy to reason about, but a node with nothing to send still pays the same idle-listening window as a busy relay, and the whole neighborhood is unreachable at once during the sleep half. A topology-aware rule staggers the off-time by hop position instead, so a wave of wake windows moves outward from the sink and a packet can cross several hops within one cycle rather than waiting for the next synchronized window everywhere. That still is not a free lunch: staggering assumes a traffic estimate that was accurate when the wave was tuned, and a node whose real traffic no longer matches that assumption can end up over-provisioned (awake with nothing to send) or under-provisioned (asleep when a burst arrives) even though the wave schedule looks correct on paper.

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

Use the figure at Figure 14.2 to test the chapter’s mac protocol evidence claim before applying it. The visible relationship between (a) sleep and (b) init radio identifies what must remain true in the real system.

Reading the chart at Figure 14.2 from (a) sleep to (b) init radio shifts the review from a point that exposes the energy consequence to one that adds a distinct review condition. (c) radio crystal startup adds the final condition by adds a distinct review condition. This explains why measured-style current trace in milliamps against time in milliseconds across seven phases: sleep near zero, init-radio jumping to about 14 milliamps, a long radio-crystal-startup plateau near 1 milliamp, a microcontroller-on rise to about 15 milliamps, a receive peak near 22 milliamps, an ADC phase near 15 milliamps, and a return to sleep. It also supplies the bridge from the diagram back to mac protocol evidence.

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.

IEEE 802.15.4-family stacks (Zigbee, Z-Wave, 6LoWPAN) split this timing choice into two families with their own vocabulary. Beacon mode is synchronous: a coordinator’s beacon carries the wake schedule, and Beacon Tracking has a node store that schedule and turn its receiver on slightly before the next expected beacon rather than listening continuously. Non-beacon mode is asynchronous: there is no shared beacon, so a sender instead repeats a short wake-up signal until the receiver’s own independent wake interval catches it, which is the same idle-listening-versus-preamble trade already covered above under the B-MAC and X-MAC row. Neither label replaces the review evidence; the point of naming them is that a beacon-mode design still needs the same clock-drift and guard-time proof as any other synchronous schedule, and a non-beacon design still needs the same preamble-cost proof as B-MAC or X-MAC.

Beacon-mode scheduling also has to answer a question a single-hop diagram hides: what happens when one coordinator’s beacon cannot reach the whole deployment? The IEEE 802.15.4 answer is to let other nodes rebroadcast their own beacons and have the network settle into an association tree, so a node wakes for its parent’s beacon and, if it has children, also broadcasts its own beacon for them to hear. That turns one wake window into two per node on a relay — an incoming window to catch the parent’s beacon and an outgoing window to serve children — which is exactly the kind of role-specific duty-cycle asymmetry this chapter’s Rendezvous And Topology Role Review and Hotspots and Load Balance sections already require evidence for, now with a name for where the second window comes from.

The reason to pause at the diagram in Figure 14.3 is to make mac protocol evidence auditable. In particular, POWER must be reconciled with Active before the result can guide implementation.

The diagram at Figure 14.3 separates three jobs that prose can easily blur: POWER exposes the energy consequence, Active adds a distinct review condition, and Sleep exposes the energy consequence. The distinction matters because duty cycling concept chart showing active and sleep intervals over time, high and low power levels, active time, sleep time, cycle time, and duty cycle formula. With those jobs separated, the chapter’s mac protocol evidence claim remains testable.

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.

The synchronization step itself is not a single broadcast; it is a small contention round the review should be able to name. A node’s SYNC phase is divided into slots, and a neighbor that wants to (re)announce its schedule picks a slot with CSMA and a random backoff rather than transmitting immediately, so two neighbors proposing a schedule at the same moment do not collide. Once a schedule is settled, the RTS/CTS pair that follows does two jobs at once: RTS lets the sender contend for the neighbor’s next listen window, and the neighbor’s CTS both grants the exchange and extends that neighbor’s own wake-up time long enough to receive the data. A route trace that shows repeated SYNC contention without a settled schedule, or a CTS that never extends the active window, points at the rendezvous mechanics failing before any data-delivery evidence is even relevant.

A design can appear sound at Sender and still fail at Long preamble. The illustration in Figure 14.4 frames that exact concern for the chapter’s discussion of mac protocol evidence.

Trace the labelled evidence in Figure 14.4 beginning at Sender, the element that adds a distinct review condition. Pause at Long preamble because it adds a distinct review condition; resolve the path at Actual packet, which adds a distinct review condition. What the visual establishes is that timeline showing a sender transmitting a long preamble followed by the actual packet, while a periodically-waking receiver performs repeated short check-channel samples until one of them catches the preamble, after which it stays awake through the packet. This is the bounded result needed for mac protocol evidence.

14.14 Try It: S-MAC Sleep Windows

14.15 Try It: T-MAC Adaptive Timeout

14.16 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.17 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.18 Continue to the Next Part

Carry this evidence into WSN Energy: Adaptive Duty-Cycle Evidence, which begins with Adaptive Duty-Cycle Inputs.