7 WSN Energy & Architecture

In 60 Seconds

WSN energy management extends battery-limited node lifetime from days to years through duty cycling, data aggregation, and topology control. The radio dominates energy consumption — a single 250-byte transmission costs as much as executing 3 million CPU instructions.

Prerequisites: WSN Fundamentals and Topologies | Networking Basics

Part of: WSN Overview series

This enables: WSN Applications | WSN Energy Management

7.1 Learning Objectives

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

Analyze Energy Consumption: Quantify power consumption across sensing, processing, and transmission activities
Design Duty Cycling Strategies: Apply sleep scheduling to extend battery life from days to years
Implement Multi-Hop Routing: Design hierarchical architectures with cluster heads and gateways
Differentiate WSN Architecture Tiers: Explain the three-tier architecture from sensor nodes to cloud
Calculate Energy Tradeoffs: Evaluate transmission power vs. hop count for network lifetime optimization

MVU: Minimum Viable Understanding

If you only have 5 minutes, understand these three things:

Transmitting uses 1000x more power than sleeping – this single fact drives every WSN design decision
Duty cycling extends battery life by ~550x – alternating between sleep (99%) and active (1%) transforms 8-day battery life into 12+ years theoretical
Three-tier architecture separates concerns: sensor nodes (sense), gateways (aggregate/translate), cloud (analyze/store)

If you understand why energy is paramount and how duty cycling works, you have the foundation for all WSN design.

Sensor Squad: The Great Battery Challenge!

Bella the Battery Monitor wants to teach you about energy!

Think about your phone. If you leave the screen on ALL day and stream videos, it dies before dinner! But if you put it in your pocket and only check it sometimes, it lasts all day. Sensors work the same way!

Sammy says: “I sleep 99% of the time – like a cat! I only wake up every 10 minutes to check the temperature and tell my friends. That is called duty cycling!”

The Math is Cool:

If Sammy stays awake ALL the time: battery lasts 8 days (like leaving your phone screen on)
If Sammy sleeps 99% and wakes 1%: battery lasts 12+ YEARS! (like only checking your phone a few times a day)

Max adds: “And we work as a team! Instead of everyone shouting to headquarters, we pass messages through neighbors. I tell Lila, Lila tells Bella, Bella tells the gateway. It is like a game of telephone!”

Try This: Time how long your flashlight lasts if you leave it on vs. turning it on for 1 second every minute. The “duty cycled” flashlight lasts WAY longer!

For Beginners: Energy Management Basics

What is this chapter about? This chapter explains why energy is the most critical constraint in WSN design and how to manage it effectively.

Key Terms:

Term	Meaning
Duty Cycling	Alternating between sleep and wake states
Active Power	Energy consumed while sensing/transmitting
Sleep Power	Minimal energy consumed while inactive
Data Aggregation	Combining multiple readings to reduce transmissions

Why Energy Matters:

Sensor nodes often use small batteries (AA, coin cell)
Replacing batteries in remote deployments is expensive
A well-designed WSN can operate 5+ years on batteries
Poor design leads to 5-day battery life instead of 5 years

Simple Analogy: Think of your phone battery. If you keep the screen on and use data constantly, it dies in hours. If you turn off notifications and use airplane mode mostly, it lasts days. WSN sensors do the same - sleep most of the time, wake briefly to sense and transmit.

7.2 The Energy Challenge: Why It Matters

The #1 constraint in WSN design is energy. Consider:

Activity	Power Consumption	Analogy
Sleeping	~10 uA	Scout napping
Sensing	~1 mA	Scout looking around
Processing	~10 mA	Scout thinking/calculating
Transmitting	~30-100 mA	Scout shouting to others

Key insight: Transmitting uses 1000x more power than sleeping!

This is why WSNs use clever tricks: - Duty cycling: Sleep most of the time, wake briefly - Data aggregation: Summarize data locally, send less - Multi-hop: Use nearby nodes instead of shouting far

7.3 Energy Timeline: Duty Cycling in Action

Timeline sequence diagram showing WSN sensor node duty cycling behavior over time. The horizontal axis shows time progressing in 10-minute intervals. The vertical axis shows power consumption in milliamps. The node spends most time in deep sleep mode (flat line near zero, 10 microamps). At each 10-minute interval, the node briefly wakes through three short pulses: sensing spike (1 mA for ~100ms), processing spike (10 mA for ~50ms), and radio transmission spike (30 mA for ~100ms). The ratio of active time to total time is approximately 1 percent, demonstrating how duty cycling conserves energy while still collecting regular measurements. — Figure 7.1: **Timeline View**: This sequence diagram shows how duty cycling solves the energy problem. A sensor node spends 99% of time in deep sleep (10 uA), waking briefly every 10 minutes to sense (1 mA) and process (10 mA). Transmission (30 mA) only occurs when thresholds are exceeded. This pattern transforms 5-day battery life into 2-5 year operation.

7.3.1 Energy Budget Calculation

Let’s calculate battery life for a typical sensor node:

Scenario: Temperature sensor with 2000 mAh battery

State	Current	Duration/Hour	Energy/Hour
Sleep	10 uA	59.83 min	0.010 mAh
Wake	1 mA	0.17 min (6×/hr × 1.7s)	0.003 mAh
Transmit	30 mA	0.01 min (6×/hr × 100ms)	0.005 mAh
Total	-	-	0.018 mAh/hr

Battery Life = 2000 mAh / 0.018 mAh/hr ≈ 111,000 hours = 12.7 years (theoretical)

In practice, battery self-discharge and environmental factors reduce this to 3-5 years, which is still excellent.

Comparison: Always-On Mode | State | Current | Duration/Hour | Energy/Hour | |——-|———|—————|————-| | Active | 10 mA | 60 min | 10 mAh |

Battery Life = 2000 mAh / 10 mAh/hr = 200 hours = 8 days

Duty cycling extends battery life by ~550x!

7.3.2 Interactive: Duty Cycling Battery Life Calculator

Show code

{
  const dc = dcPercent / 100;
  const avgCurrent = dc * dcActive + (1 - dc) * dcSleep;
  const alwaysOnCurrent = dcActive;
  const lifetimeHours = dcBattery / avgCurrent;
  const lifetimeDays = lifetimeHours / 24;
  const lifetimeYears = lifetimeDays / 365;
  const alwaysOnDays = dcBattery / alwaysOnCurrent / 24;
  const improvement = lifetimeDays / alwaysOnDays;

  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>Average Current:</strong> ${avgCurrent.toFixed(3)} mA</p>
    <p><strong>Battery Lifetime (duty cycled):</strong> ${lifetimeDays.toFixed(0)} days (${lifetimeYears.toFixed(1)} years)</p>
    <p><strong>Battery Lifetime (always-on):</strong> ${alwaysOnDays.toFixed(1)} days</p>
    <p><strong>Improvement:</strong> ${improvement.toFixed(0)}× longer with duty cycling</p>
  </div>`;
}

Quick Check: Duty Cycling Impact

A sensor node consumes 20 mA when active and 0.01 mA when sleeping. At a 1% duty cycle, what is the approximate average current?

20 mA
10 mA
0.21 mA
0.01 mA

Answer

c) 0.21 mA. Average current = (0.01 x 20 mA) + (0.99 x 0.01 mA) = 0.2 + 0.0099 = approximately 0.21 mA. Even at just 1% active time, the active current (20 mA) dominates the average, showing why minimizing active time is critical.

7.4 WSN Architecture

Wireless sensor network architecture diagram showing sensor nodes distributed across a monitored area connecting via wireless links to a central sink node, which bridges the sensor network to the Internet and user applications through a gateway, illustrating the three-tier hierarchy from edge sensing to cloud analytics — Figure 7.2: Example of wireless sensor network architecture showing sensor nodes, sink, and base station connectivity

7.4.1 Three-Tier Architecture

Tier 1 - Sensor Nodes:

Collect environmental data through sensors
Perform local processing and filtering
Transmit data to nearby nodes or gateways
Often battery-powered with limited resources

Tier 2 - Gateway/Sink Nodes:

Aggregate data from multiple sensor nodes
Provide protocol translation (e.g., 802.15.4 to Wi-Fi/Ethernet)
Perform edge processing and data fusion
Connect sensor network to external networks

Tier 3 - Backend Systems:

Cloud or on-premise servers
Store and analyze large-scale data
Provide user interfaces and applications
Enable remote management and configuration

7.4.2 Core Characteristics

Distributed Sensing: Multiple sensor nodes deployed across an area provide redundancy, increased coverage, and improved accuracy through collaborative sensing and data fusion.

Wireless Communication: Nodes communicate without physical wiring, enabling deployment in challenging environments and reducing installation costs.

Self-Organization: Networks autonomously configure themselves, adapt to node failures, and optimize routing without centralized coordination.

Resource Constraints: Nodes typically operate under severe constraints in energy, computation, memory, and communication bandwidth.

Application-Specific Design: WSNs are often designed and optimized for specific applications, with hardware and protocols tailored to particular sensing requirements and environmental conditions.

7.5 Multi-Hop Routing Architecture

WSN deployments often require multi-hop communication where sensor nodes relay messages through intermediaries to reach the base station. This diagram illustrates how data flows from edge sensors through cluster heads to the gateway and cloud:

Figure 7.3: WSN multi-hop architecture showing three tiers: (1) Sensor Nodes (green, battery-powered) collect data and relay through neighbors using Zigbee/802.15.4, (2) Cluster Heads (orange, solar-powered) aggregate data from 3-5 sensors, reducing transmissions by 70%, (3) Gateway (orange) translates WSN protocols to Internet (Wi-Fi/4G) and performs edge processing, (4) Cloud Server (navy) provides analytics, storage, and user dashboards. Note multi-hop routing: Sensor 3 reaches gateway via 3 hops (S3-S2-CH1-GW), and remote Sensor 8 relays through Cluster Head 1.

7.5.1 Key Architecture Principles

Hierarchical Organization: Sensor nodes - Cluster heads - Gateway - Cloud
Multi-Hop Communication: Sensors beyond radio range relay through neighbors (e.g., Sensor 3 uses Sensor 2 as relay)
Data Aggregation: Cluster heads combine data from multiple sensors, reducing transmissions from 8 individual messages to 2 aggregated messages (75% reduction)
Energy Heterogeneity: Solar-powered cluster heads handle energy-intensive relay tasks; battery sensors only transmit their own data
Protocol Translation: Gateway bridges low-power WSN protocols (Zigbee, 802.15.4) with Internet protocols (Wi-Fi, 4G, Ethernet)
Battery Monitoring: Remote visibility of sensor battery levels enables predictive maintenance before failures occur

Putting Numbers to It

Multi-Hop vs Direct Transmission Energy Trade-off

Transmission energy scales with distance squared (free-space path loss). Compare direct vs multi-hop for a sensor 200m from gateway:

Radio model: $E_{tx} = E_{elec} + E_{amp} \times d^2$ - $E_{elec}$ = 50 nJ/bit (transceiver electronics) - $E_{amp}$ = 100 pJ/bit/m² (amplifier) - Packet size: 1,000 bits

Option A: Direct transmission (200m): \[E_{direct} = 50 \times 1000 + 100 \times 1000 \times (200)^2\] \[E_{direct} = 50,000 + 4,000,000,000 = 4,000,050,000 \text{ pJ} = 4.0 \text{ mJ}\]

Option B: Two-hop via relay at 100m (2× transmissions of 100m each): \[E_{hop1} = 50 \times 1000 + 100 \times 1000 \times (100)^2 = 1,000,050,000 \text{ pJ}\] \[E_{hop2} = 1,000,050,000 \text{ pJ} \text{ (relay to gateway)}\] \[E_{multihop} = 2 \times 1,000,050,000 = 2,000,100,000 \text{ pJ} = 2.0 \text{ mJ}\]

Energy savings: $\frac{4.0 - 2.0}{4.0} = 50\%$ reduction

Four-hop scenario (4× 50m hops): \[E_{4hop} = 4 \times (50 \times 1000 + 100 \times 1000 \times 50^2) = 4 \times 250,050,000 = 1.0 \text{ mJ}\]

Savings vs direct: $\frac{4.0 - 1.0}{4.0} = 75\%$

Design insight: Multi-hop dominates energy efficiency when $d^2$ dominates, but relay nodes bear forwarding burden. Use solar-powered cluster heads as relays to avoid hotspot battery depletion.

7.5.2 Historical Evolution

Early Development (1980s-1990s): WSNs emerged from military applications, particularly the Distributed Sensor Networks (DSN) program initiated by DARPA. Early systems were expensive, power-hungry, and limited in capability.

Technological Advancement (2000s): Miniaturization of electronics, advances in wireless communication, and improvements in energy efficiency enabled widespread commercial adoption. The Berkeley Mote platform became a landmark development in WSN research.

IoT Integration (2010s-Present): WSNs have become integral to IoT architectures, with standardized protocols (IEEE 802.15.4, Zigbee, LoRaWAN), cloud integration, and edge computing capabilities transforming their role from isolated systems to connected components of larger ecosystems.

7.6 Case Studies

Case Study: Intel Precision Agriculture - Vineyard Monitoring

Industry: Agriculture / Precision Farming

Challenge: A 500-hectare California vineyard needed to optimize irrigation and detect disease early. Manual soil sampling (technician walks fields weekly with probes) provided sparse data (50 locations per week) with 5-7 day delays, missing critical irrigation windows and allowing diseases to spread. Initial cloud-connected IoT sensors (Wi-Fi-based) failed within 2 months due to: (1) Wi-Fi range limited to 100m requiring 200+ access points ($80K installation cost), (2) High power consumption (200mA idle) drained batteries in 3-6 weeks, requiring constant maintenance.

Solution: Intel deployed Zigbee-based WSN with 800 sensor nodes: - Sensor Nodes (Edge): 800 wireless soil moisture/temperature sensors with Zigbee radios (15mA active, 1uA sleep) deployed every 50m across vineyard rows - Network Topology: Cluster-tree with 40 cluster heads (solar-powered Raspberry Pi + Zigbee coordinator) aggregating data from 20 sensors each - Gateway (Fog): 4G LTE gateway receives compressed data from cluster heads, runs local analytics (anomaly detection, irrigation zone recommendations) - Cloud: Receives hourly summaries for long-term trend analysis, ML model training for disease prediction

Results:

3-year battery life: Aggressive duty cycling (1% active, 99% sleep) extended node lifetime from 3-6 weeks (Wi-Fi) to 3+ years (Zigbee with sleep), eliminating weekly battery replacement ($50K/year labor savings)
97% infrastructure cost reduction: Multi-hop Zigbee mesh required only 40 cluster heads + 1 gateway vs. 200 Wi-Fi access points, reducing upfront costs from $80K to $2.4K
30% water savings: Spatial resolution (800 sensors vs. 50 manual samples) identified micro-zones with optimal moisture, enabling targeted irrigation that saved 12 million gallons annually ($18K water cost savings)
Early disease detection: Daily monitoring (vs. weekly manual) caught downy mildew 5 days earlier, preventing spread that would have cost $120K in lost crop yield

Lessons Learned:

Match protocol to power budget - Wi-Fi (200mA idle) is unsuitable for battery-powered sensors; Zigbee (1uA sleep) enables multi-year operation
Multi-hop extends coverage economically - Mesh topology with 100m node spacing covers 500 hectares with minimal infrastructure vs. 200+ Wi-Fi access points
Cluster heads solve hotspot problem - Solar-powered cluster heads eliminate battery drain from relay traffic; regular nodes only transmit their own data
Spatial density reveals patterns - 800 sensors (1.6 per hectare) revealed irrigation inefficiencies invisible to 50 manual samples (0.1 per hectare)
Start with high-ROI metrics - Vineyard prioritized soil moisture (direct irrigation savings) before expanding to disease detection, weather monitoring, and yield prediction

Case Study: City of Copenhagen - Smart Parking & Traffic

Industry: Smart City / Transportation

Challenge: Copenhagen’s 300,000+ vehicles spent 20% of drive time searching for parking, creating congestion (85M EUR annual economic cost), emissions (12,000 tons CO2/year), and frustration. Initial parking sensor pilots using cellular IoT (NB-IoT) faced prohibitive costs: 12,000 parking spots x 8 EUR/month cellular = 1.15M EUR/year recurring fees, plus 150 EUR/sensor for cellular modems vs. 30 EUR for Zigbee sensors.

Solution: Copenhagen deployed LoRaWAN-based WSN for citywide parking and traffic monitoring: - Edge Layer: 12,000 wireless parking sensors (magnetic vehicle detection) + 450 traffic counters (ultrasonic) using LoRa radios transmitting every 15 minutes - Network Architecture: Star topology with 85 LoRaWAN gateways (10-15 km range) covering entire city center (88 km2) - Fog Layer: Gateways aggregate sensor data, perform data validation and filtering, transmit summaries to cloud via Ethernet - Cloud Layer: Real-time parking availability map, historical analytics, predictive occupancy models for event planning

Results:

95% cost reduction: LoRaWAN eliminated cellular fees (0 EUR vs. 1.15M EUR/year) and reduced sensor hardware costs (30 EUR vs. 150 EUR per sensor = 1.44M EUR savings on 12,000 sensors)
10-year battery life: LoRa’s ultra-low-power operation (12uA sleep, 15-minute reporting) enables decade-long deployments vs. 2-3 years for cellular sensors
17% traffic reduction: Real-time parking guidance (mobile app + signage) reduced search time from 20% of trips to 3%, cutting inner-city traffic by 17% during peak hours
35% parking revenue increase: Dynamic pricing based on real-time occupancy increased revenue from 42M EUR to 57M EUR annually while reducing congestion
Emissions reduction: 17% traffic reduction = 2,000+ tons CO2/year avoided, contributing to Copenhagen’s carbon neutrality goals

Lessons Learned:

LPWAN economics enable city-scale deployments - LoRaWAN’s zero-fee connectivity and 30 EUR sensors made 12,000-sensor deployment economically viable; cellular costs would have been prohibitive
Battery lifetime determines TCO - 10-year battery life eliminates maintenance (replacing 12,000 batteries every 2 years = 240K EUR/year labor), making WSN practical for infrastructure
Gateway placement for urban coverage - 85 LoRaWAN gateways (one per km2) provided 99.2% coverage; strategic placement on tall buildings, light poles maximized range
Data aggregation at gateway reduces cloud costs - Gateways filter duplicate readings (same car triggering adjacent sensors), validate data (reject physically impossible transitions), reducing cloud processing by 70%
Start with revenue-generating use case - Parking sensors had immediate ROI (15M EUR annual revenue increase > 2.5M EUR deployment cost), funding expansion to air quality, waste, and flood monitoring
Multi-application infrastructure - LoRaWAN network deployed for parking now supports 35+ applications (waste bins, air quality, traffic, flooding), amortizing infrastructure costs across use cases

Key Concepts

Duty Cycling: Alternating between sleep and active states to conserve energy, enabling multi-year battery operation
Data Aggregation: Combining data from multiple sensors at cluster heads to reduce total network transmissions
Multi-Hop Routing: Relaying data through intermediate nodes to reach destinations beyond direct radio range
Three-Tier Architecture: Sensor nodes (edge), gateway/sink (fog), and cloud backend for complete IoT integration
Energy Heterogeneity: Using solar-powered or mains-powered cluster heads for relay tasks while battery sensors only transmit own data
Protocol Translation: Gateway bridges low-power WSN protocols (Zigbee, 802.15.4) with Internet protocols (Wi-Fi, cellular)

Worked Example: Sizing a Solar-Powered WSN Node

Scenario: You’re deploying 50 environmental monitoring nodes in a desert location where battery replacement is costly. Each node must operate continuously for 10 years. Should you use batteries alone or add solar harvesting?

Node Power Profile (Measured):

Sleep mode: 10 µA (99% of time)
Sensing + Processing: 5 mA for 100 ms every 10 min
Transmission: 30 mA for 50 ms every 10 min
Wake-up overhead: 2 mA for 10 ms per cycle

Energy Calculation Per Hour:

Sleep: 0.01 mA × 59.5 min = 0.595 mAh
Sense: 5 mA × (100 ms × 6) / 60,000 ms = 0.05 mAh
Transmit: 30 mA × (50 ms × 6) / 60,000 ms = 0.15 mAh
Wake overhead: 2 mA × (10 ms × 6) / 60,000 ms = 0.002 mAh
Total: 0.797 mAh per hour = 19.1 mAh per day

Battery-Only Approach:

Required capacity: 19.1 mAh/day × 365 days/year × 10 years = 69,715 mAh
With 50% derating for temperature/aging: 139,430 mAh needed
D-cell lithium primary battery: 19,000 mAh typical
Batteries needed: 8 D-cells per node (cost: $120, weight: 1.2 kg, physically large enclosure)

Solar Harvesting Approach:

Average daily energy: 19.1 mAh × 3.7V = 70.7 mWh
Desert location: 6 hours effective sunlight (accounting for angle, dust)
Required solar panel: 70.7 mWh / 6h = 11.8 mW
Add 3× margin for winter/cloudy: 35 mW panel needed
Typical 55×70mm panel: 110 mW peak, $12
Backup battery: 3 days autonomy = 57.3 mAh → use 200 mAh LiPo: $8
Charge controller + MPPT: $15
Total solar system: $35, 80g weight, compact

Decision: Solar harvesting costs $35 vs. $120 for batteries, weighs 80g vs. 1200g, fits in standard enclosure vs. requiring custom large housing, and operates indefinitely vs. 10-year limit. The desert location with 6+ hours daily sun makes solar the clear winner.

Key Insight: For deployments exceeding 5 years in sunny locations where average power is below 50 mW, solar harvesting almost always beats primary batteries on cost, weight, size, and operational flexibility. The break-even point for temperate climates (3-4 sun hours) is around 3-4 years.

Decision Framework: Choosing Gateway Count and Placement

When designing WSN architecture, gateway quantity and location directly determine network lifetime through the hotspot problem.

Criterion	Single Gateway	Multiple Gateways (3-5)	Dense Gateways (10+)
Max hop count	8-12 hops	3-5 hops	1-2 hops
Hotspot energy burden	Relay 90%+ of traffic	Relay 30-40% of traffic	Relay <10% of traffic
Inner node lifetime	3-6 months	2-3 years	5+ years
Infrastructure cost	$200-500	$600-2,500	$2,000-10,000+
Deployment complexity	Low (single uplink)	Moderate (coordinate 3-5)	High (mesh backhaul)
Network latency	High (long chains)	Moderate (3-5 hops)	Low (direct/1-hop)
Best for	Prototypes, budget-limited	Most production WSNs	Critical, large-scale

Decision Process:

Calculate worst-case relay burden: In a 500-node network with 1 gateway, nodes adjacent to the gateway relay ~400-450 packets. With 5 gateways, worst case is ~80-100 packets.
Estimate hotspot lifetime: If edge nodes transmit 1 packet/hour (0.2 mAh), but hotspot nodes relay 400 packets/hour (80 mAh), hotspot lifetime is 400× shorter. A 2-year edge node becomes a 1.8-day hotspot node!
Calculate gateway ROI: Adding 4 gateways ($800) to extend hotspot lifetime from 2 days to 2+ years eliminates 200+ battery replacement visits at $150/visit = $30,000 savings.
Apply the 5-hop rule: If your network requires average hop counts exceeding 5, add gateways. Beyond 5 hops, cumulative packet loss and latency degrade reliability significantly.

Real-World Example: The Copenhagen parking sensor network (12,000 sensors) uses 85 gateways (1 per 141 sensors) to keep average hop count at 2-3. This design achieved 10-year sensor battery life despite 15-minute reporting intervals. A single-gateway design would have created hotspots dying within weeks.

Common Mistake: Ignoring Gateway Battery Drain

The Mistake: Deploying solar-powered sensor nodes but placing gateways on grid power “because they need more power anyway.”

Why It’s Wrong: Gateways in sunny outdoor locations with consistent uplink connectivity don’t need grid power – they’re actually perfect candidates for solar + battery systems. Requiring grid power severely constrains gateway placement (must be near electrical infrastructure), often forcing gateways into suboptimal locations for RF coverage.

Real-World Failure: A smart agriculture deployment placed 5 gateways near farm buildings (grid power available) rather than optimal RF locations 200m into the fields. This forced sensor nodes to use 6-8 hops instead of 2-3 hops, reducing sensor battery life from 5 years to 8 months. Re-siting gateways to optimal locations with solar power (adding $80 solar kit per gateway = $400 total) extended sensor lifetime to 4+ years, saving $25,000 annually in battery replacement costs.

The Fix: Treat gateways as “super sensors” with higher power budgets (5-10W vs. 50 mW), not as infrastructure requiring grid power. A typical gateway can operate on a 20W solar panel + 20Ah battery for indefinite operation. Total cost: $120. Grid power installation cost: $1,500-$5,000 per drop. The math is obvious.

Rule of Thumb: Only require grid power for gateways with backhaul bandwidth exceeding 1 Mbps (cellular/Wi-Fi hotspots), processing requirements exceeding 500 MHz (edge ML inference), or indoor locations without solar access. For outdoor agricultural, environmental, or infrastructure monitoring, solar-powered gateways are almost always the right choice.

Test Yourself: Match WSN Energy Concepts

Test Yourself: Steps to Design an Energy-Efficient WSN

Common Pitfalls

1. Estimating Battery Life from Average Current Draw

Average current calculation ignores burst transmissions — a node averaging 100 µA may draw 30 mA during transmissions, and if coin cell internal resistance is high, voltage sag during bursts causes premature brownout resets. Always measure peak current and verify voltage stays above minimum at the worst-case load.

2. Optimizing Radio While Ignoring Sensor Power

RF optimization efforts focus on radio (dominant source) but ignore sensor power — a continuous soil moisture sensor drawing 3 mA consumes more than the radio in many duty-cycled designs. Characterize every subsystem’s power consumption before optimizing; the highest consumer is not always the radio.

3. Neglecting Leakage Current in Long-Lifetime Designs

For 5-year battery life targets, quiescent leakage of voltage regulators (1-100 µA) becomes significant — a 100 µA leakage on a 2,500 mAh battery limits life to 2.85 years regardless of how well you optimize the active duty cycle. Select ultra-low-quiescent regulators (<1 µA) for multi-year deployments.

🏷️ Label the Diagram

Code Challenge

7.7 Summary

This chapter covered energy management and architecture design for wireless sensor networks:

Energy is the defining constraint - Transmission uses 1000x more power than sleep, requiring duty cycling strategies
Duty cycling extends battery life dramatically - 1% duty cycle can transform 8-day battery life to 14+ years
Three-tier architecture provides clear separation between sensing (edge), aggregation (gateway), and analytics (cloud)
Multi-hop routing extends network range and enables data aggregation at cluster heads
Real-world deployments demonstrate 3-10 year battery life and 95%+ cost savings over cellular alternatives

Understanding energy management is essential for designing practical WSN deployments that operate reliably for years without maintenance.

7.8 Test Your Understanding

Test Your Understanding

Question 1: A sensor node has a 2000 mAh battery. With duty cycling (1% active at 20 mA, 99% sleep at 0.01 mA), what is the approximate average current consumption?

20 mA
10 mA
0.21 mA
0.01 mA

Answer

c) 0.21 mA. Average current = (0.01 x 20 mA) + (0.99 x 0.01 mA) = 0.2 mA + 0.0099 mA = approximately 0.21 mA. This gives a battery life of 2000 / 0.21 = approximately 9,500 hours or about 396 days. The key insight is that even 1% active time at 20 mA dominates the total consumption.

Question 2: In the three-tier WSN architecture, what is the primary role of the gateway/sink node?

Sensing environmental data with onboard sensors
Aggregating data from sensor nodes and bridging WSN protocols to Internet protocols
Running machine learning models on raw sensor data
Providing long-range radio coverage for all sensor nodes

Answer

b) Aggregating data from sensor nodes and bridging WSN protocols to Internet protocols. The gateway sits at Tier 2, collecting data from multiple sensor nodes (Tier 1), performing protocol translation (e.g., 802.15.4 to Wi-Fi/Ethernet), and forwarding processed data to the cloud backend (Tier 3). While gateways may perform some edge processing, their defining role is aggregation and protocol bridging.

Question 3: Intel’s vineyard WSN case study achieved 3-year battery life by switching from Wi-Fi to Zigbee. What was the primary reason for this improvement?

Zigbee has higher data throughput than Wi-Fi
Zigbee supports true deep sleep at 1 uA vs Wi-Fi’s 200 mA idle listening
Zigbee gateways are less expensive than Wi-Fi access points
Zigbee provides longer communication range than Wi-Fi

Answer

b) Zigbee supports true deep sleep at 1 uA vs Wi-Fi’s 200 mA idle listening. Wi-Fi’s protocol requires continuous association maintenance and beacon responses, consuming 200 mA even when idle. Zigbee allows true deep sleep at 1 uA (200,000x less power). This transformed battery life from 3-6 weeks (Wi-Fi) to 3+ years (Zigbee). The case study also reduced infrastructure costs by 97% using multi-hop Zigbee mesh instead of 200+ Wi-Fi access points.

7.9 Knowledge Check

Quiz: WSN Energy & Architecture

7.10 What’s Next?

Topic	Chapter	Description
WSN Applications	WSN Node ID & Applications	Node identification, collision avoidance, and real-world domains
Energy Management	WSN Energy Management	Advanced energy conservation strategies
Sensor Nodes	WSN Sensor Nodes	Sensor node hardware and capabilities
Deployment Sizing	WSN Deployment Sizing	Plan WSN deployments with sizing calculations