30  WSN Review: Scenario Analysis

In 60 Seconds

Duty cycling provides 75x battery improvement: always-on radio lasts 5.5 days versus 416 days duty-cycled on the same battery. The hotspot problem is a traffic pattern issue (not hardware) – three sinks instead of one multiplies network lifetime by 3x. Full mesh routing destroys battery life (14 hours) versus clustered star (36 days), and aggregation’s real benefit is collision avoidance, not just bandwidth reduction.

30.1 Learning Objectives

By the end of this chapter, you will be able to:

• Calculate Energy Trade-offs: Compute battery life under different deployment strategies and duty cycling configurations
• Evaluate Architectural Choices: Compare mesh vs. star topologies with quantified energy and cost outcomes
• Apply Scenario-Based Reasoning: Use case study insights to justify deployment decisions
• Select Aggregation Functions: Choose appropriate aggregation methods (MIN, MAX, AVG) for specific applications

Key Concepts

• Core Concept: Fundamental principle underlying WSN Review: Scenario Analysis — understanding this enables all downstream design decisions
• Key Metric: Primary quantitative measure for evaluating WSN Review: Scenario Analysis performance in real deployments
• Trade-off: Central tension in WSN Review: Scenario Analysis design — optimizing one parameter typically degrades another
• Protocol/Algorithm: Standard approach or algorithm most commonly used in WSN Review: Scenario Analysis implementations
• Deployment Consideration: Practical factor that must be addressed when deploying WSN Review: Scenario Analysis in production
• Common Pattern: Recurring design pattern in WSN Review: Scenario Analysis that solves the most frequent implementation challenges
• Performance Benchmark: Reference values for WSN Review: Scenario Analysis performance metrics that indicate healthy vs. problematic operation

30.2 MVU: Minimum Viable Understanding

If you only have 5 minutes, remember these scenario-based insights:

1. Duty cycling gives 75x battery improvement – always-on radio (5.5 days) vs duty-cycled (416 days) using the same battery
2. The hotspot problem is a traffic pattern issue, not a hardware issue – three sinks instead of one multiplies network lifetime by 3x
3. Full mesh routing destroys battery life (14 hours!) vs clustered star (36 days) – always ask “can I add more gateways?”
4. Aggregation’s real benefit is collision avoidance – reducing 100 competing transmitters to 5 eliminates collision waste, not just bandwidth

Each scenario below provides exact calculations. Use them as templates for your own deployment planning.

Sensor Squad: Real-World Story Time!

The Sensor Squad loves stories about real sensor networks!

Sammy says: “Each scenario below is like a detective story – we figure out WHY things work or fail!”

Bella shares her favorite: “The farm story is amazing! When sensors used always-on radio, batteries died in 5.5 days. With duty cycling, the SAME batteries lasted 416 days. That is like your phone lasting over a YEAR on one charge!”

Max adds: “And the mesh vs star story? Mesh routing made batteries last only 14 hours – that is less than a school day! But adding 10 gateways made them last 36 days. Sometimes the simple answer is the best answer!”

Lila reminds everyone: “Pay attention to the numbers in each story. Real engineers use these exact calculations to plan their sensor networks!”

For Beginners: How to Use These Scenarios

What are scenario analyses? These are detailed worked examples that walk through WSN design decisions with real-world numbers. Each scenario compares two or more approaches and explains WHY one works better.

How to Study These:

1. Read the scenario description first
2. Try to predict which option is better BEFORE reading the analysis
3. Follow the math calculations step by step
4. Focus on the “Key Insight” at the end of each scenario
5. The “Real-world wisdom” quotes come from actual engineers

Key Scenarios Covered:

• Energy management (duty cycling vs always-on)
• Hotspot problem (single vs multiple sinks)
• Topology comparison (mesh vs clustered star)
• Aggregation economics (flat vs hierarchical)
• Latency vs energy trade-offs

30.3 Prerequisites

Required Chapters:

• WSN Review: Architecture and Design - Architecture concepts
• WSN Review: Knowledge Checks - Core understanding validation

Estimated Time: 20 minutes

Related Chapters

WSN Review Series:

• WSN Overview Review (Index) - Series overview
• WSN Review: Architecture and Design - Architecture concepts
• WSN Review: Knowledge Checks - Quick assessment questions
• WSN Review: Comprehensive Assessment - Advanced topics and summary

Energy Management:

• Context Aware Energy Management - Energy optimization
• Duty Cycling and Topology - Sleep scheduling

30.4 Scenario Analysis: WSN Design Decisions

The following scenarios provide detailed quantified analysis of WSN design decisions. Each scenario presents competing approaches with real-world numbers to guide your understanding.

Understanding Check: WSN Energy Management Trade-offs

Scenario: An agricultural WSN monitors soil moisture with 100 sensor nodes. Each node has a 2000 mAh battery, radio consuming 15 mA (idle listening) and 20 mA (transmitting). Nodes transmit 1% of the time.

Your agricultural co-op debates two deployment strategies:

Option A (Always-On Radio):

• Radio always listening: 15 mA continuous
• Transmit 1% time: additional 5 mA average
• Total: ~15 mA average
• Cost: $50/node battery replacement visit
• Battery life: 2000 mAh / 15 mA = 133 hours = 5.5 days

Option B (Duty-Cycled with S-MAC):

• Sleep 99% time: 1 µA average
• Wake & transmit 1% time: 20 mA for brief periods
• Total: ~0.2 mA average
• Cost: Same hardware, firmware upgrade
• Battery life: 2000 mAh / 0.2 mA = 416 days

Think about:

1. Operational cost: Option A requires 75 battery swaps/year x $50 = $375K vs. Option B’s 1 swap/year x $50 = $5K
2. Reliability: Which fails first during peak season when access is difficult?
3. The hidden cost: Why does idle listening (15 mA) almost match active transmission (20 mA)?

Key Insight: Idle listening is the silent killer of WSN deployments. Many developers focus on reducing transmission time (already 1%!) while ignoring the radio consuming 15 mA continuously just waiting to receive. The 75x lifetime difference comes from sleep mode optimization, not transmission optimization.

Real-world wisdom: “Always-on radios turn month-long deployments into week-long failures. Sleep scheduling isn’t optional—it’s the difference between viable and impossible.”

Putting Numbers to It

Duty cycling provides a 75× battery lifetime improvement by eliminating idle listening power consumption.

\[ \text{Battery Life (days)} = \frac{\text{Battery Capacity (mAh)}}{\text{Average Current (mA)}} \]

Worked example: Agricultural sensor with 2000 mAh battery. Always-on radio draws 15 mA continuous listening + 5 mA average transmit = 20 mA total. Battery life: 2000 / 20 = 100 hours = 4.2 days. With S-MAC duty cycling at 1% active time: sleep consumes 0.001 mA × 0.99 = 0.001 mA, active consumes 20 mA × 0.01 = 0.2 mA, total = 0.201 mA. Battery life: 2000 / 0.201 = 9,950 hours = 415 days. The 75× improvement comes from replacing 15 mA idle listening (99% of always-on power) with 1 µA deep sleep.

Understanding Check: The WSN Hotspot Problem

Scenario: A forest fire detection system deploys 100 sensor nodes across 10 km² of wilderness. All sensor data must reach a single gateway with satellite uplink. After 3 months, the system fails when nodes within 200m of the gateway die from battery exhaustion, creating a “coverage hole” that isolates the outer 70 sensors.

Architecture A (Single Sink):

• 30 nodes near sink relay for all 70 outer nodes
• Reporting rate: 1 report per 1.5 min per node (about 1,000 reports/day per outer node)
• Each hotspot node forwards: 70 × 1,000 / 30 = ~2,333 packets/day
• Energy: 2,333 transmissions × 0.1s × 20 mA / 3600 = 1.3 Ah/day
• Battery life: 2000 mAh / 1,300 mAh = 1.5 months
• Edge nodes (no relay burden): 12+ months battery life
• Network failure at ~3 months when hotspot zone creates isolation

Architecture B (Three Distributed Sinks):

• Each sink services ~33 nodes
• Hotspot nodes relay for ~23 outer nodes each
• Relay burden: 23 × 1,000 / 10 relays per sink = ~767 packets/day per node
• Energy: 767 × 0.1s × 20 mA / 3600 = 0.43 Ah/day
• Battery life: 2000 mAh / 430 mAh = 4.7 months
• Network lifetime: 2+ years with biannual battery replacement

Think about:

1. Cost analysis: Single sink requires 3-month battery replacement vs. three sinks with 5-month cycles. Labor cost: $200/visit x 100 nodes x 4 visits/year = $80K vs. $48K
2. Coverage reliability: What happens when a single hotspot node fails in Architecture A vs. B?
3. Why unequal load? The physics of multi-hop networking means inner nodes relay everyone’s traffic, not just their own

Key Insight: The hotspot problem is a fundamental consequence of many-to-one traffic patterns in multi-hop networks. You cannot solve it with better batteries or protocols—you must distribute the traffic load architecturally. Three sinks reduce each hotspot’s relay burden by 66%, directly multiplying lifetime.

Real-world wisdom: “The hotspot problem killed more WSN deployments than all other issues combined. If you have one sink and multi-hop routing, you have a ticking time bomb.”

Understanding Check: WSN Topology Energy Trade-offs

Scenario: A smart vineyard needs 200 sensor nodes across 1 km² to monitor microclimates for precision irrigation. The engineering team debates two topologies:

Topology A (Full Mesh with AODV Routing):

• Every node discovers routes to all 199 neighbors
• Routing table: 199 entries x 16 bytes = 3,184 bytes RAM per node
• Route discovery: Broadcast RREQ floods network (200 nodes x 64 bytes = 12.8 KB airtime)
• Route maintenance: Each link failure triggers new discovery
• Relay burden: Node must forward packets for ~10 neighbors on average
• Energy per day: Routing overhead (50 mA x 10s) + relay traffic (20 mA x 120s) + sensing (20 mA x 10s) = 3.3 Ah/day
• Battery life: 2000 mAh / 3.3 Ah = 0.6 days (14 hours!)
• Node cost: $45 (needs 4KB RAM for routing)

Topology B (Clustered Star with 10 Gateways):

• 20 sensors per cluster communicate directly to gateway (no multi-hop)
• Routing table: 1 entry (gateway address)
• No route discovery needed
• No relay burden (direct to gateway)
• Energy per day: Sensing + transmit to gateway (20 mA x 10s) = 0.055 Ah/day
• Battery life: 2000 mAh / 0.055 Ah = 36 days
• Node cost: $25 (128 bytes RAM sufficient)
• Gateway cost: 10 x $200 = $2,000 (mains powered, Wi-Fi backhaul)

Think about:

1. 60x battery life difference: Topology B lasts 36 days vs. Topology A’s 14 hours
2. Total system cost: Topology A: 200 x $45 = $9,000. Topology B: (200 x $25) + $2,000 = $7,000
3. Operational cost: Mesh requires daily battery service ($500/day labor). Clustered star: monthly service ($100/month)
4. When is mesh worth it? Only when sensor spacing exceeds gateway range (>100m) AND you cannot add more gateways

Key Insight: Full mesh is a solution in search of a problem. The routing overhead and relay burden destroy battery life for negligible benefit in most deployments. Always ask: “Can I add more gateways instead?” The answer is usually yes, and it’s cheaper than the mesh energy penalty.

Real-world wisdom: “We spent 6 months perfecting mesh routing, then realized 3 strategically placed gateways eliminated all multi-hop traffic. Threw away the mesh code and deployed.”

Understanding Check: In-Network Aggregation Economics

Scenario: An industrial facility monitors equipment temperature with 100 wireless sensors reporting every 60 seconds. Network engineer proposes hierarchical aggregation to reduce congestion at the central gateway.

Architecture A (Flat - No Aggregation):

• Each sensor transmits raw reading to sink: 10 bytes payload + 20 bytes header = 30 bytes
• Total traffic at sink: 100 nodes x 30 bytes/min = 3,000 bytes/min = 50 bytes/sec
• Airtime per transmission: 30 bytes x 8 bits x (1/250,000 bps) = 0.96 ms
• Total airtime: 100 x 0.96 ms = 96 ms/min (network 16% busy)
• Collision probability: 16% → ~8% packet loss requiring retransmissions
• Energy per node: 30 bytes x 20 mA x 0.96 ms = 0.58 mAh/day

Architecture B (Hierarchical - 5 Cluster Heads):

• 20 sensors per cluster send to cluster head (20 x 30 bytes = 600 bytes/cluster)
• Cluster head aggregates: min/max/avg/stddev/count = 40 bytes summary
• Traffic to sink: 5 clusters x 40 bytes = 200 bytes/min = 3.3 bytes/sec
• Traffic reduction: 3,000 → 200 bytes = 93% (better than 80% because header overhead eliminated)
• Airtime: Only 5 transmissions/min = 4.8 ms/min (network 0.8% busy)
• Collision probability: < 1% → negligible packet loss
• Energy per sensor node: Local transmission (0.58 mAh) vs. cluster head (receive 20 packets + aggregate + transmit = 1.8 mAh)

Think about:

1. Bandwidth savings: 93% reduction means network can scale from 100 to 1,400 sensors with same congestion
2. Battery symmetry: Cluster heads consume 3x more energy. How do you handle this? (Rotation, mains power, larger batteries?)
3. Information loss: What if you need individual sensor values for diagnostics? (Send raw data on exception, aggregates normally)
4. Latency trade-off: Aggregation adds 5-10 second delay waiting for all cluster members

Key Insight: Aggregation’s primary benefit isn’t bandwidth—it’s collision avoidance. Going from 100 competing transmitters to 5 eliminates the exponential backoff and retransmission waste that destroys WSN efficiency. The 93% reduction is the side effect; the real win is deterministic delivery.

Real-world wisdom: “We added aggregation to reduce bandwidth. Unexpectedly, packet delivery jumped from 83% to 99.7%. Turned out the network was drowning in collisions, not data volume.”

Understanding Check: Latency vs Energy in Duty-Cycled WSNs

Scenario: A chemical plant deploys gas leak detection sensors. Engineers must balance response time against battery life in the duty cycling configuration.

Configuration A (S-MAC: 1-second wake interval, 10% duty cycle):

• Nodes wake simultaneously every 1 second for 100 ms
• Event detected at worst case: right after sleep cycle starts
• Maximum latency: 1 second (wait for next wake cycle)
• Average latency: 500 ms
• Energy: Sleep 900 ms (1 µA) + wake 100 ms (15 mA) = 1.5 mAh/day
• Battery life: 2000 mAh / 1.5 mAh = 1,333 days (3.7 years)

Configuration B (High Duty Cycle: 100 ms wake interval, 10% duty cycle):

• Nodes wake every 100 ms for 10 ms
• Maximum latency: 100 ms
• Average latency: 50 ms
• Energy: Sleep 90 ms (1 µA) + wake 10 ms (15 mA) = 1.5 mAh/day (same!)
• Battery life: 3.7 years (energy determined by duty cycle %, not interval)

Configuration C (Wake-Up Radio: Always-on monitoring):

• Low-power wake-up radio monitors continuously: 10 µA
• Main radio sleeps: 1 µA
• Gas detected → wake-up radio triggers main radio interrupt
• Latency: <10 ms (near-instantaneous)
• Energy: Wake-up radio (10 µA) + main radio sleep (1 µA) + occasional wake (amortized 0.1 mA) = 0.26 mAh/day
• Battery life: 2000 mAh / 0.26 mAh = 7,692 days (21 years!)
• Hardware cost: +$8/node for wake-up radio

Think about:

1. Safety requirements: For gas leak (life-threatening), is 1-second latency acceptable? 100 ms? Or must you detect <10 ms?
2. Energy misconception: Why does Configuration B have same battery life as A despite 10x faster wake-ups? (Duty cycle % matters, not interval)
3. Cost-benefit: Wake-up radio costs $800 for 100 nodes, but eliminates 20 years of battery replacements ($50 x 10 visits x 100 nodes = $50,000)

Key Insight: Latency in duty-cycled networks is bounded by wake interval, not duty cycle percentage. You can achieve both fast response AND long battery life by using short wake intervals with proportionally short wake durations. Better yet, wake-up radios eliminate the trade-off entirely.

Real-world wisdom: “We debugged S-MAC for weeks trying to improve latency while maintaining battery life. Finally realized we were optimizing the wrong variable—threw in $5 wake-up radios and got 10x better latency with 5x better battery life.”

Quick Check: Duty Cycling Impact

A 2000 mAh battery powers a sensor with always-on radio drawing 15 mA. What is the approximate battery lifetime?

30.5 Duty Cycling Latency vs. Energy Calculator

Explore how wake interval and duty cycle interact. Notice that energy stays constant when duty cycle % is fixed, but latency changes with the interval.

viewof wake_interval_ms = Inputs.range([50, 5000], {value: 1000, step: 50, label: "Wake interval (ms)"})

viewof duty_cycle_pct_s = Inputs.range([1, 50], {value: 10, step: 1, label: "Duty cycle (%)"})

viewof battery_cap_s = Inputs.range([500, 5000], {value: 2000, step: 100, label: "Battery capacity (mAh)"})

{
  const dc = duty_cycle_pct_s / 100;
  const wake_ms = wake_interval_ms * dc;   // active duration per cycle
  const sleep_ms = wake_interval_ms * (1 - dc);

  // Average current (mA)
  const active_ma = 15;   // radio active
  const sleep_ua  = 1;    // deep sleep µA
  const avg_ma = active_ma * dc + (sleep_ua / 1000) * (1 - dc);

  const lifetime_days = battery_cap_s / (avg_ma * 24);
  const max_latency_ms = wake_interval_ms;   // worst case
  const avg_latency_ms = wake_interval_ms / 2;

  return html`<div style="background: var(--bs-light, #f8f9fa); padding: 1rem; border-radius: 8px; border-left: 4px solid #16A085; margin-top: 0.5rem;">
    <p><strong>Duty Cycling Configuration</strong></p>
    <p>Wake duration per cycle: <strong>${wake_ms.toFixed(0)} ms</strong> active out of every <strong>${wake_interval_ms} ms</strong></p>
    <p>Average radio current: <strong>${avg_ma.toFixed(3)} mA</strong></p>
    <p>Battery lifetime: <strong style="color:${lifetime_days > 365 ? '#16A085' : '#E74C3C'}">${lifetime_days.toFixed(0)} days (${(lifetime_days/365).toFixed(1)} years)</strong></p>
    <p>Max event latency: <strong>${max_latency_ms} ms</strong> | Avg latency: <strong>${avg_latency_ms} ms</strong></p>
    <p style="color:#7F8C8D; font-size:0.9em;">Key insight: change wake interval while keeping duty cycle % constant — energy stays the same but latency changes!</p>
  </div>`
}

Understanding Check: Choosing the Right Aggregation Function

Scenario: A 50-hectare vineyard uses 100 soil moisture sensors for precision irrigation. The irrigation controller receives aggregated data from 5 cluster heads (20 sensors each) to make watering decisions.

Aggregation Option A (SUM):

• Cluster reports: Total moisture = 12,450 units (sum of 20 sensors)
• Controller receives: Zone 1 = 12,450, Zone 2 = 11,200, Zone 3 = 13,100, Zone 4 = 12,800, Zone 5 = 10,900
• Decision making difficulty: What does “12,450 total units” mean? Is it good? Bad? Needs irrigation?
• Cannot identify which specific sensors are dry
• Useless for spatial irrigation planning

Aggregation Option B (MIN/MAX/MEAN):

• Cluster reports: MIN = 18%, MAX = 72%, MEAN = 45%
• Controller receives: Zone 1 (min=18%, mean=45%, max=72%)
• Actionable decisions:
  • MIN = 18% → Critical dry spot, activate irrigation immediately in Zone 1
  • MAX = 72% → Some sensors oversaturated, check for drainage issues
  • MEAN = 45% → Overall zone is moderately dry
• Water savings: Irrigate only Zone 1 (MIN=18%) and Zone 5 (MIN=15%), skip Zones 2-4 (all MIN>30%)
• Result: 60% water reduction vs. uniform irrigation

Aggregation Option C (Spatial Distribution with STDDEV):

• Cluster reports: MIN=18%, MAX=72%, MEAN=45%, STDDEV=22%
• Advanced insights:
  • High STDDEV (22%) indicates uneven moisture distribution
  • Suggests irrigation system malfunction (clogged emitters, broken lines)
  • Triggers maintenance alert instead of just adding more water

Think about:

1. Information value: SUM tells you nothing about spatial distribution. MIN/MAX reveal extremes needing action
2. Water economics: Precision irrigation using MIN/MAX saves $15,000/year in water costs for this 50-hectare vineyard
3. Data compression: Sending MIN/MAX/MEAN/STDDEV = 16 bytes vs. raw 20 readings = 40 bytes (60% reduction with better insights)

Key Insight: The best aggregation function depends on the decision being made, not the data being collected. SUM is mathematically valid but operationally useless for irrigation—you can’t water “the sum.” MIN/MAX answer the real question: “Where is it too dry or too wet?”

Real-world wisdom: “We aggregated soil moisture with MEAN for two seasons, wasted 40% of our water. Switched to MIN/MAX spatial aggregation—water bill dropped $18K annually and yields improved 12% from better moisture management.”

Understanding Check: High-Fidelity vs Low-Power WSN Trade-offs

Scenario: City engineers deploy a structural health monitoring system on a 2 km suspension bridge to detect dangerous resonance frequencies before failure occurs.

Application A (Low-Power WSN Approach):

• Deploy 200 battery-powered nodes sampling vibration at 1 Hz
• Standard WSN: Temperature/humidity sensors repurposed for accelerometers
• Time synchronization: NTP over wireless (~100 ms accuracy)
• Data rate: 1 sample/sec x 2 bytes x 200 nodes = 400 bytes/sec
• Battery life: 2 years
• Problem: Missed critical frequency analysis!
  • Bridge resonance occurs at 0.5-50 Hz
  • 1 Hz sampling can only detect up to 0.5 Hz per the Nyquist theorem (sampling rate ≥ 2× signal frequency)
  • Cannot distinguish torsional vs. vertical modes without time-correlated data
  • 100 ms time sync error destroys phase relationship between sensor pairs

Application B (High-Fidelity Structural Monitoring):

• Deploy 64 mains-powered accelerometer nodes sampling at 1000 Hz
• Professional-grade: 16-bit ADC, GPS time sync (±10 µs accuracy)
• Data rate: 1000 samples/sec x 2 bytes x 64 nodes = 128 KB/sec (320x higher!)
• Power: Mains required (PoE or AC, ~5W per node)
• Cost: $800/node vs. $45/node for low-power WSN
• Capabilities unlocked:
  • Detect resonance frequencies: 0.5-50 Hz covered
  • Modal analysis: Correlate vibrations across spans to identify bending/torsion modes
  • Early warning: Detect frequency shifts indicating structural degradation
  • Earthquake response: Capture high-frequency seismic events

Application C (Hybrid - Smart Energy Harvesting):

• 64 nodes with vibration energy harvesters + supercapacitors
• Adaptive sampling: 10 Hz baseline, 1000 Hz during detected events
• Edge processing: FFT on-node, transmit only frequency spectrum (100x compression)
• Data rate (baseline): 10 Hz x 2 bytes x 64 = 1.28 KB/sec
• Data rate (events): 1000 Hz x 2 bytes x 64 = 128 KB/sec for 10-second bursts
• Power: Energy neutral (vibration harvesting generates ~50 mW, consumes ~30 mW avg)
• Cost: $400/node (harvester + supercap)

Think about:

1. Application mismatch: Why can’t low-power WSN approaches work for structural monitoring? (Sampling rate, timing, data fidelity)
2. Energy vs. fidelity: 1000 Hz sampling requires 1000x more processing/transmission than 1 Hz—battery operation becomes impossible
3. Cost justification: Bridge failure costs $100M+. Is $50K for proper monitoring expensive or cheap?

Key Insight: Not all sensing applications fit the low-power WSN paradigm. Structural health monitoring needs high sampling rates, tight time synchronization, and continuous operation—optimizing for battery life destroys the application’s core value. Sometimes the right answer is “use mains power.”

Real-world wisdom: “We tried to save money with battery-powered 1 Hz accelerometers. Missed a critical resonance development that nearly caused bridge closure. Ripped it out, deployed proper 1000 Hz GPS-synced system. Yes, it costs 10x more. Bridge failure costs 1000x more.”

30.6 Test Your Understanding

Test Your Understanding

Question 1: An agricultural WSN with 100 nodes uses always-on radio consuming 15 mA with a 2000 mAh battery. What is the battery lifetime, and how much would duty cycling (0.2 mA average) improve it?

1. 5.5 days without duty cycling; 75x improvement to 416 days with duty cycling
2. 13 days without duty cycling; 10x improvement to 130 days
3. 55 days without duty cycling; 5x improvement to 275 days
4. 8 hours without duty cycling; 1000x improvement to 8000 hours

Answer

a) 5.5 days without duty cycling; 75x improvement to 416 days with duty cycling. Without duty cycling: 2000 mAh / 15 mA = 133 hours = 5.5 days. With duty cycling: 2000 mAh / 0.2 mA = 10,000 hours = 416 days. The 75x improvement comes entirely from eliminating idle listening – the radio was consuming 15 mA just waiting to receive, nearly as much as the 20 mA transmission power.

Question 2: In the aggregation economics scenario, hierarchical aggregation with 5 cluster heads reduced network traffic by 93%. What was the MOST important benefit?

1. Reduced bandwidth at the gateway
2. Lower data storage costs in the cloud
3. Collision avoidance by reducing competing transmitters from 100 to 5
4. Improved data quality through statistical summaries

Answer

c) Collision avoidance by reducing competing transmitters from 100 to 5. While bandwidth reduction is the obvious benefit, the real win was eliminating collisions. With 100 nodes transmitting independently, the network was 16% busy with 8% packet loss. Reducing to 5 cluster head transmissions made the network only 0.8% busy with negligible collisions. Packet delivery jumped from 83% to 99.7%.

Question 3: A chemical plant needs gas leak detection with the fastest possible response time AND multi-year battery life. Which duty cycling approach is best?

1. S-MAC with 1-second wake interval (1 second max latency, 3.7 year battery life)
2. S-MAC with 100ms wake interval (100ms max latency, 3.7 year battery life)
3. Wake-up radio with always-on monitoring (<10ms latency, 21+ year battery life)
4. No duty cycling (0ms latency, 8 day battery life)

Answer

c) Wake-up radio with always-on monitoring (<10ms latency, 21+ year battery life). Wake-up radios use an ultra-low-power secondary radio (10 uA) that monitors continuously while the main radio sleeps. This provides near-instantaneous response (<10ms) with excellent battery life (21+ years). The $8/node hardware cost is easily justified by eliminating the latency-energy trade-off entirely. For life-safety applications like gas detection, this is the optimal choice.

Worked Example: Optimal Cluster Size Calculation for 500-Node Deployment

Scenario: Agricultural IoT with 500 soil sensors across 250 hectares. Determine optimal cluster size to maximize network lifetime.

Variables:

• Total nodes: N = 500
• Number of clusters: k (to be optimized)
• Cluster size: n = N/k
• Data per node: 50 bytes/transmission
• Transmission energy: \(E_{tx} = 50 \mu J\)/byte × distance²
• Cluster head to sink: d = 500m average
• Member to CH: d = 50m average

Energy Model:

Cluster Member Energy (per transmission): \[E_{member} = 50 \text{ bytes} \times 50 \mu J \times (50m)^2 = 6.25 \text{ mJ}\]

Cluster Head Energy (per round): \[E_{CH} = E_{receive} + E_{aggregate} + E_{transmit}\] \[E_{CH} = n \times 50 \times 30 \mu J + 10 mJ + 50 \times 50 \times (500)^2 \mu J\] \[E_{CH} = 1.5n + 10 + 625 = 635 + 1.5n \text{ mJ}\]

Average Energy per Node (assuming fair CH rotation): \[E_{avg} = \frac{1}{n}E_{CH} + \frac{n-1}{n}E_{member}\] \[E_{avg} = \frac{635 + 1.5n}{n} + \frac{n-1}{n} \times 6.25\] \[E_{avg} = \frac{635}{n} + 1.5 + 6.25 - \frac{6.25}{n}\] \[E_{avg} = \frac{628.75}{n} + 7.75 \text{ mJ}\]

Optimization: Minimize \(E_{avg}\) by choosing n: \[\frac{dE_{avg}}{dn} = -\frac{628.75}{n^2} = 0 \text{ (has no minimum, decreases monotonically)}\]

This shows larger clusters are ALWAYS more energy-efficient… but this ignores the multi-hop problem within clusters!

Corrected Model (accounting for intra-cluster hops): For cluster radius > 75m (single-hop range), members need multi-hop to reach CH: - Cluster radius r scales as \(\sqrt{n}\) for fixed density - Average hops \(\approx \sqrt{n}/75\)

Corrected member energy: \[E_{member,corrected} = 6.25 \times \text{hops} = 6.25 \times \frac{\sqrt{n}}{75} \text{ mJ}\]

Re-optimizing: \[E_{avg} = \frac{635 + 1.5n}{n} + 6.25 \times \frac{\sqrt{n}}{75}\] \[\frac{dE_{avg}}{dn} = -\frac{635}{n^2} - \frac{1.5}{n} + \frac{3.125}{75\sqrt{n}} = 0\]

Numerical solution: n ≈ 20-25 nodes per cluster

Verification for n=20:

• Clusters: k = 500/20 = 25
• Cluster radius: ~50m (single-hop capable)
• Avg energy: 635/20 + 7.75 + 6.25×1 = 31.75 + 7.75 + 6.25 = 45.75 mJ/transmission
• vs. direct to sink: 50 × 50 × (500)² = 625,000 µJ = 625 mJ → 13.7× energy savings

Key Insight: Optimal cluster size balances CH overhead against multi-hop costs. Too small (n=5) wastes energy on CH rotation. Too large (n=100) forces multi-hop within clusters, negating aggregation benefits. Sweet spot: 15-25 nodes for typical agricultural deployments.

Decision Framework: Aggregation Function Selection by Application

Application	Raw Data Pattern	Best Aggregation	Worst Aggregation	Reasoning
Precision irrigation	Soil moisture 10-80%	MIN, MAX, STDDEV	AVG, SUM	Need to identify dry spots (MIN) and variability (STDDEV); average hides critical extremes
Structural monitoring	Vibration 0-100 Hz	MAX, FFT peaks	AVG, MEDIAN	Anomalies (cracks) show as MAX spikes; averaging smooths away the signal you need
Environmental temp	Temperature 15-35°C	AVG, MIN, MAX	COUNT, SUM	Ambient monitoring benefits from statistics; SUM is meaningless for temperature
Occupancy detection	Motion binary 0/1	COUNT, ANY	AVG, MEDIAN	Need total occupancy (COUNT) or any movement (ANY); averaging booleans is nonsense
Wildfire detection	Temperature 10-60°C	MAX, RATE-OF-CHANGE	AVG, MEDIAN	Fire shows as MAX spike + rapid increase; averaging dilutes the alert signal
Air quality	PM2.5 0-500 µg/m³	MAX, 95th percentile	MIN, MEDIAN	Health risk from peak exposure, not average; MIN/MEDIAN miss dangerous spikes

Selection Process:

1. Identify decision trigger: What value causes action? (irrigation when MIN < 20%, alarm when MAX > 50°C)
2. Match aggregation to trigger: Use aggregation function that preserves the decision signal
3. Test with adversarial data: Will your aggregation hide the critical event? (averaging 19 normal + 1 fire = 23°C average, no alarm!)
4. Transmit decision-relevant data only: Send MIN+MAX (8 bytes) instead of 20 raw readings (40 bytes) = 80% bandwidth savings with better information

Common Mistake: Latency Confusion in Multi-Hop Networks

The Mistake: Calculating network latency as (hop count) × (transmission time per hop), assuming transmissions occur instantly at each hop.

Why It’s Wrong: Ignores queueing delay and MAC contention. A 5-hop path with 10 ms TX time per hop does NOT have 50 ms latency. Actual latency includes: - Queueing: Waiting for radio to become available (10-100 ms if network is busy) - MAC backoff: CSMA/CA exponential backoff after collisions (0-300 ms) - Duty cycle wake: Waiting for next-hop node to wake (0-5000 ms in asynchronous networks)

Real Measurement Example: 5-hop agricultural WSN with S-MAC (100 ms wake interval): - Theoretical: 5 hops × 1.6 ms TX = 8 ms - Measured average: 480 ms (60× higher!) - Breakdown: 5 × (50 ms avg wake wait + 10 ms queueing + 1.6 ms TX + 5 ms processing) = 333 ms + 147 ms variance

The Fix: For latency budgets, use empirical formula: \[\text{Latency} = \text{hops} \times (\frac{\text{wake interval}}{2} + 15ms) + \text{contention overhead}\]

For S-MAC with 100 ms wake: Latency ≈ hops × 65 ms

Rule of Thumb: If application requires <500 ms latency, limit hop count to 5 with S-MAC, or use always-on MAC (costly in energy) or wake-up radio (costly in hardware).

Common Pitfalls

1. Prioritizing Theory Over Measurement in WSN Review: Scenario Analysis

Relying on theoretical models without profiling actual behavior leads to designs that miss performance targets by 2-10×. Always measure the dominant bottleneck in your specific deployment environment — hardware variability, interference, and load patterns routinely differ from textbook assumptions.

2. Ignoring System-Level Trade-offs

Optimizing one parameter in isolation (latency, throughput, energy) without considering impact on others creates systems that excel on benchmarks but fail in production. Document the top three trade-offs before finalizing any design decision and verify with realistic workloads.

3. Skipping Failure Mode Analysis

Most field failures come from edge cases that work in the lab: intermittent connectivity, partial node failure, clock drift, and buffer overflow under peak load. Explicitly design and test failure handling before deployment — retrofitting error recovery after deployment costs 5-10× more than building it in.

🏷️ Label the Diagram

Code Challenge

30.7 Summary

This chapter covered detailed scenario analysis for WSN design decisions:

• Energy Management Trade-offs: 75x lifetime improvement through duty cycling vs. always-on radio
• Hotspot Problem: Architectural solutions using multiple sinks to distribute relay burden
• Topology Trade-offs: 60x battery life difference between mesh and clustered star
• Aggregation Economics: 93% traffic reduction through hierarchical clustering
• Latency vs Energy: Wake interval bounds latency, duty cycle determines energy
• Aggregation Function Selection: MIN/MAX for actionable decisions vs. SUM/MEAN for statistics
• Application-Appropriate Design: When low-power WSN paradigm doesn’t fit the use case

30.8 Knowledge Check

Quiz: WSN Review: Scenario Analysis

Match Deployment Problems to Solutions

Order the Energy Optimization Steps

30.9 What’s Next

Topic	Chapter	Description
Comprehensive Assessment	WSN Review: Comprehensive Assessment	Advanced topics, protocol selection, and design guidance
Energy Management	Context Aware Energy Management	Energy optimization strategies
Duty Cycling	Duty Cycling and Topology	Sleep scheduling and topology design
Coverage	WSN Coverage Fundamentals	Area and target coverage algorithms