60 WSN Stationary vs Mobile

In 60 Seconds

Stationary WSNs suffer the energy hole problem where nodes near the sink die first from relaying everyone’s traffic. Mobile sinks or Data MULEs can double network lifetime by distributing relay load, but add latency (minutes to hours for store-carry-forward). Choose stationary for real-time needs, mobile for latency-tolerant applications where energy budget is the binding constraint.

60.1 Learning Objectives

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

Distinguish stationary and mobile WSN architectures and their design trade-offs
Evaluate when mobility improves network lifetime, coverage, and data collection
Identify the roles of mobile sinks, Data MULEs, and mobile sensor nodes
Analyze the energy hole problem and how mobility-based approaches mitigate it
Select appropriate WSN mobility models for real-world application scenarios

MVU (Minimum Viable Understanding)

Stationary WSNs keep nodes fixed after deployment, offering predictable topology but suffering from the energy hole problem where nodes near the sink die first
Mobile WSNs introduce moving nodes or sinks to balance energy consumption, adapt coverage dynamically, and collect data via store-carry-forward schemes like Data MULEs
The choice between stationary and mobile depends on your application’s latency tolerance, energy budget, and coverage requirements – mobility adds complexity but can double network lifetime

Sensor Squad: Stationary vs Mobile Sensor Networks!

Sammy the Sensor is standing in a field, watching crops grow. “I’ve been here for months! My batteries are getting low, and I can’t move to check on the far corner of the field.”

Lila the LED rolls up on a little robot cart. “That’s why I’m here! I’m a mobile sink – I drive around and collect your data so you don’t have to shout it all the way to the base station!”

Max the Microcontroller explains: “Think of it like mail delivery. In Sammy’s stationary network, everyone passes letters toward the post office – people near the post office get exhausted carrying everyone else’s mail. But with Lila’s mobile approach, the mail truck comes to you!”

Bella the Buzzer adds: “It’s like the difference between a library and a bookmobile! A library stays put and you come to it. A bookmobile drives to neighborhoods so everyone gets books without traveling far.”

The Big Idea: Some sensor networks stay still (like security cameras), and some can move around (like delivery drones). Moving sensors or collectors can save energy and cover more ground, but they’re harder to manage!

Character	Role	Analogy
Sammy	Stationary sensor	Security camera bolted to a wall
Lila	Mobile sink	Mail truck visiting mailboxes
Max	Network coordinator	Post office manager deciding routes
Bella	Alert system	School bell – fixed but essential

For Beginners: Understanding Stationary vs Mobile Sensor Networks

What is a Wireless Sensor Network (WSN)?

A WSN is a collection of small, battery-powered devices (sensors) scattered across an area to monitor things like temperature, humidity, or motion. These sensors communicate wirelessly, passing data toward a central collection point called a sink or base station.

Stationary Networks – The Simple Approach:

Imagine planting 100 thermometers across a farm field. Each thermometer stays where you put it, measures temperature, and sends its reading to a central computer. This is a stationary WSN. It is simple and predictable, but has a critical weakness: sensors closest to the computer must relay data from ALL other sensors, draining their batteries much faster (this is called the energy hole problem).

Mobile Networks – The Clever Approach:

Now imagine a small drone that flies over the field, stopping near each thermometer to collect its data directly. The thermometers no longer need to relay data for their neighbors – they just wait for the drone. This is a mobile WSN, and it dramatically extends battery life.

Key Terms Simplified:

Term	What It Means	Real-World Example
Stationary WSN	Sensors stay fixed; data flows through the network	Weather stations on a mountain
Mobile WSN	Sensors or collectors can move	Drones surveying a disaster zone
Mobile Sink	A moving collector that visits sensors	Garbage truck visiting houses
Data MULE	A device that picks up data during visits	USB stick carried between computers
Energy Hole	Sensors near the sink die first	Cashier at a busy store burns out faster

When to Use Each:

Stationary: When your environment does not change (buildings, pipelines, bridges) and you need continuous real-time data
Mobile: When you can tolerate some delay, need to cover large areas, or want to extend battery life significantly

60.2 Overview

This section explores the fundamental differences between stationary and mobile wireless sensor networks, examining how mobility can solve energy distribution challenges, enable adaptive coverage, and support new application domains from wildlife tracking to smart cities.

60.2.1 Stationary vs Mobile WSN Architecture

Diagram comparing stationary and mobile WSN architectures. Stationary WSN shows fixed nodes relaying data in multi-hop fashion toward a static sink, while Mobile WSN shows a mobile sink traversing the field to collect data directly from nodes.

Key Concepts

Stationary WSN: Networks where sensor nodes remain fixed after deployment, simplifying routing and localization
Mobile WSN: Networks incorporating mobile sensor nodes or mobile sinks, enabling adaptive coverage and data collection
Mobile Sink: A moving data collection point (often on robots or vehicles) that gathers data by visiting sensor nodes
Data MULE: Mobile Ubiquitous LAN Extension – mobile entity collecting buffered data from sensors during periodic visits
Self-CHOP: Self-Configure, Self-Heal, Self-Optimize, Self-Protect – properties inherited from MANETs

60.2.2 Decision Framework: Stationary vs Mobile

Decision tree for choosing between stationary and mobile WSN architectures based on application requirements including latency, coverage area, energy budget, and environment dynamism.

60.3 Chapter Guide

This topic is covered in four focused chapters:

60.3.1 1. Stationary Wireless Sensor Networks

Learn about traditional fixed-topology sensor networks:

Characteristics of stationary deployments
Advantages: simplified planning, predictable topology, optimized density
Disadvantages: energy hole problem, static coverage, limited adaptability
Real-world applications: structural health monitoring, precision agriculture
Worked example: vineyard soil monitoring with energy hole mitigation

60.3.2 2. Mobile Wireless Sensor Networks (MWSNs)

Understand how mobility transforms sensor network capabilities:

Relationship with MANETs and Self-CHOP properties
Mobility advantages: adaptive coverage, energy balancing, network resilience
Trade-offs: when mobility helps vs. when it hurts
Common misconceptions and pitfalls to avoid
Worked example: mobile sink path optimization for agriculture

60.3.3 3. MWSN Components: Nodes, Sinks, and MULEs

Explore the building blocks of mobile sensor networks:

Mobile sensor nodes: operational models and mobility mechanisms
Mobile sinks: path planning strategies (random, predefined, adaptive)
Data MULEs: store-carry-forward data collection
DTN routing: Spray and Wait protocol for intermittent connectivity
Real-world examples: ZebraNet, DakNet

60.3.4 4. MWSN Types and Mobile Entities

Discover different MWSN environments and platforms:

Underwater MWSNs: acoustic communication, AUV integration
Terrestrial MWSNs: ground robots, vehicles, animal-borne sensors
Aerial MWSNs: UAV networks for wide-area coverage
Human-centric sensing: smartphones as ubiquitous sensor platforms
Vehicle-based sensing: cars, buses, and public transit

60.3.5 Chapter Relationships

Diagram showing the four sub-chapters and their relationships. Stationary WSN fundamentals and Mobile WSN fundamentals feed into MWSN Components, which then feeds into MWSN Types and Entities. All chapters build toward understanding the complete stationary vs mobile design space.

60.4 The Energy Hole Problem and Mobility Solution

The most critical limitation of stationary WSNs is the energy hole problem. In multi-hop networks, nodes closer to the sink must relay traffic from all other nodes, causing them to deplete batteries far earlier than edge nodes. Mobile sinks eliminate this problem by distributing collection load across the entire network.

60.4.1 Energy Consumption: Stationary vs Mobile Sink

Comparison of energy consumption patterns. In a stationary sink network, nodes near the sink consume 5x to 10x more energy than edge nodes due to relay burden. With a mobile sink, energy consumption is balanced across all nodes because the sink visits each node directly.

Quick Check: Energy Hole Impact

60.5 Comparison Table: Stationary vs Mobile WSN

Feature	Stationary WSN	Mobile WSN
Topology	Fixed, predictable	Dynamic, changing
Energy distribution	Unbalanced (energy holes)	Balanced (mobile collection)
Coverage	Static, predetermined	Adaptive, expandable
Latency	Low (continuous connectivity)	Higher (delay-tolerant)
Routing complexity	Moderate (stable routes)	High (route recalculation)
Localization	Simple (known positions)	Complex (tracking required)
Deployment cost	Higher node density needed	Fewer nodes + mobile platform
Network lifetime	Limited by energy holes	2-5x longer with mobile sinks
Best for	Real-time monitoring	Large-area, delay-tolerant sensing

60.6 Learning Path

Diagram for Learning Path: A

60.7 Common Pitfalls

Common Pitfalls in WSN Stationary/Mobile Design

1. Assuming Mobile Always Beats Stationary Mobile WSNs add mechanical complexity, higher per-unit cost, and path planning overhead. For small, real-time monitoring deployments (e.g., a single building), stationary networks are simpler and more reliable. Evaluate whether your application truly benefits from mobility before committing to it.

2. Ignoring Data Latency in Mobile Sink Designs A mobile sink may take hours to complete a full tour of all nodes. If your application requires sub-second alerts (e.g., fire detection, intrusion), a mobile sink alone is insufficient. Consider a hybrid approach: stationary backbone for urgent alerts plus a mobile sink for routine data collection.

3. Underestimating the Energy Hole Severity In a stationary network of 100 nodes, the 10% closest to the sink may consume 50-70% of total network energy. Many designers assume uniform battery drain and are surprised when the network partitions after only 30% of overall energy is consumed. Always model energy distribution during network planning.

4. Neglecting Path Planning for Mobile Elements Random movement patterns for mobile sinks achieve only 40-60% of optimal energy balancing. Adaptive path planning (adjusting the route based on node buffer levels and battery status) can improve network lifetime by an additional 30-50%. Do not default to simple random walks.

5. Forgetting Localization Overhead in Mobile Networks Every mobile node must continuously update its position and share it with neighbors. This consumes bandwidth and energy that is often not accounted for in initial designs. Budget 5-15% of communication overhead specifically for mobility management.

60.8 Worked Example: Smart Farm – Choosing Between Stationary and Mobile WSN

Worked Example: Smart Farm Monitoring Design

Scenario: A 50-hectare farm needs to monitor soil moisture, temperature, and humidity at 200 locations. The farmer wants the system to last at least 3 years on battery power. Data is needed every 30 minutes, but immediate alerts are required if soil moisture drops below a critical threshold.

Step 1: Define Requirements

Requirement	Value
Coverage area	50 hectares (500,000 m²)
Monitoring points	200
Data interval	30 minutes (routine)
Alert latency	< 5 minutes (critical threshold)
Target lifetime	3 years
Power source	AA batteries (2x, 3000 mAh each)

Step 2: Evaluate Stationary Approach

Deploy 200 stationary nodes in a grid (approx. 50m spacing)
Multi-hop routing toward a central sink
Energy hole analysis: nodes within 100m of the sink relay traffic from ~40 other nodes
Estimated inner-node lifetime: 8 months (far below the 3-year target)
Estimated edge-node lifetime: 4+ years
Verdict: Fails lifetime requirement due to energy holes

Step 3: Evaluate Mobile Sink Approach

Deploy 200 stationary sensor nodes (same grid)
Add 1 solar-powered mobile sink on a ground robot
Robot traverses the field every 2 hours, collecting buffered data
Each sensor transmits only over 1-hop to the passing sink
Estimated node lifetime: 3.5 years (meets requirement)
Data latency: Up to 2 hours for routine data
Issue: Cannot meet the 5-minute alert requirement with mobile sink alone

Step 4: Hybrid Design (Recommended Solution)

200 stationary sensor nodes with short-range radios (soil moisture, temp, humidity)
5 stationary relay nodes with long-range radios near high-risk zones (for immediate alerts)
1 mobile sink on a solar-powered ground robot (routine data collection every 2 hours)
Alert path: Sensor -> nearest relay node -> base station (< 2 minutes)
Routine path: Sensor -> buffer -> mobile sink -> base station (< 2 hours)

Energy Budget Comparison:

Approach	Inner Node Lifetime	Edge Node Lifetime	Meets 3-Year Target?
Pure stationary	8 months	4+ years	No
Pure mobile sink	3.5 years	3.8 years	Yes
Hybrid (recommended)	3.2 years	3.6 years	Yes

Step 5: Final Design Decision

The hybrid approach is selected because it satisfies both requirements: 3+ year battery life through mobile data collection AND sub-5-minute alerts through dedicated relay nodes. The additional cost of 5 relay nodes and 1 robot is justified by the 4x improvement in inner-node lifetime.

60.9 Knowledge Check

Test your understanding of stationary vs mobile WSN fundamentals:

60.10 Interactive: Energy Hole Calculator

Use the sliders below to explore how relay burden affects node lifetime in a stationary WSN.

Show code

{
  const txEnergy_mJ = txPower_mW * (txDuration_ms / 1000);
  const innerEnergy_mJ = txEnergy_mJ * (1 + relayCount);
  const outerEnergy_mJ = txEnergy_mJ;
  const batteryJ = batteryMah * 3.7 * 3.6; // mAh × V × 3.6 → J
  const innerLifeHr = batteryJ / (innerEnergy_mJ / 1000 * cyclesPerHour);
  const outerLifeHr = batteryJ / (outerEnergy_mJ / 1000 * cyclesPerHour);
  const imbalance = innerEnergy_mJ / outerEnergy_mJ;
  const innerDays = (innerLifeHr / 24).toFixed(0);
  const outerYears = (outerLifeHr / 8760).toFixed(1);

  return html`<div style="background: var(--bs-light, #f8f9fa); padding: 1rem; border-radius: 8px; border-left: 4px solid #E74C3C; margin-top: 0.5rem;">
    <p><strong>Energy per cycle (inner node):</strong> ${innerEnergy_mJ.toFixed(1)} mJ &nbsp;|&nbsp; <strong>Energy per cycle (outer node):</strong> ${outerEnergy_mJ.toFixed(1)} mJ</p>
    <p><strong>Energy imbalance:</strong> ${imbalance.toFixed(0)}× (inner nodes consume ${imbalance.toFixed(0)}× more energy)</p>
    <p><strong>Inner node theoretical lifetime:</strong> ${(innerLifeHr/24).toFixed(0)} days</p>
    <p><strong>Outer node theoretical lifetime:</strong> ${outerYears} years</p>
    <p style="color: #E74C3C;"><strong>Network failure point:</strong> Inner nodes die first, disconnecting the entire network while outer nodes still have ~${Math.round((1 - (innerLifeHr/outerLifeHr)) * 100)}% battery remaining.</p>
  </div>`;
}

60.11 Mobile Sink Path Planning Strategies

Three mobile sink path planning strategies compared side by side. Random walk shows unpredictable movement, predefined route shows a fixed patrol path, and adaptive route shows a path that adjusts based on node buffer levels and energy status.

Worked Example: Energy Hole Problem Quantification

Scenario: A precision agriculture network monitors soil conditions across a 200m × 200m field with 49 sensors (7×7 grid, 33m spacing) transmitting to a central sink every 5 minutes.

Given Parameters:

Sensor transmission power: 50 mW
Transmission duration: 100 ms per message
Multi-hop routing: Each sensor relays messages from further sensors toward sink
Sink location: Center of field at (100, 100)
Average path length: 3 hops for edge nodes, 1 hop for inner ring

Step 1: Calculate energy distribution without mobile sink (stationary approach)

Inner ring sensors (12 sensors within 50m of sink):

Own transmissions: 1 message × 100 ms × 50 mW = 5 mJ per cycle
Relay burden: Must relay ALL messages from outer sensors
Outer sensors: 37 sensors × 1 message each = 37 relayed messages
Relay energy: 37 messages × 100 ms × 50 mW = 185 mJ per cycle
Total per inner sensor: 5 + 185 = 190 mJ per cycle

Middle ring sensors (20 sensors, 50-100m from sink):

Own transmissions: 5 mJ per cycle
Relay burden: Messages from 17 outer edge sensors
Relay energy: 17 × 100 ms × 50 mW = 85 mJ
Total per middle sensor: 5 + 85 = 90 mJ per cycle

Outer ring sensors (17 sensors, >100m from sink):

Own transmissions: 5 mJ per cycle
Relay burden: Zero (edge of network)
Total per outer sensor: 5 mJ per cycle

Energy imbalance calculation:

Inner sensor consumption: 190 mJ / 5 mJ (outer) = 38× more energy than edge nodes
With 2000 mAh @ 3.7V = 26,640 J capacity per sensor:
- Outer sensor lifetime: 26,640 J / (5 mJ × 12 cycles/hour) = 444,000 hours = 50+ years (self-discharge limits practical life to ~5 years)
- Inner sensor theoretical lifetime: 26,640 J / (190 mJ × 12 cycles/hour) = 11,684 hours = 487 days
- Inner sensor real-world lifetime: ~10× overhead (idle listening, retransmissions, protocol overhead) → ~49 days

Network death: After ~49 days of real-world operation, all 12 inner sensors fail → network partitions → remaining 37 sensors cannot reach sink → total network failure despite 37 sensors having 96% battery remaining

Putting Numbers to It

Verify the energy hole calculations for this 49-sensor farm with $P_{\text{tx}} = 50\text{ mW}$, $t_{\text{tx}} = 100\text{ ms}$ per packet:

Transmission energy: $E_{\text{tx}} = 50\text{ mW} \times 100\text{ ms} = 5\text{ mJ per packet}$.

Inner ring node (12 nodes relay for 37 outer): Packets per cycle: 1 own + 37 relayed = 38. Energy per cycle: $E_{\text{cycle}} = 38 \times 5 = 190\text{ mJ}$. Cycles per hour: $\frac{60\text{ min}}{5\text{ min/cycle}} = 12$. Energy per hour: $E_{\text{hr}} = 190 \times 12 = 2,280\text{ mJ} = 2.28\text{ J/hr}$.

Lifetime: Battery = $2000\text{ mAh} \times 3.7\text{ V} = 7,400\text{ mWh} = 26,640\text{ J}$. \[t_{\text{life}} = \frac{26,640\text{ J}}{2.28\text{ J/hr}} = 11,684\text{ hr} \approx 487\text{ days}\]

But text says 49 days! The difference: actual deployments have idle listening, retransmissions, and protocol overhead adding ~10× to measured power. This highlights the gap between theoretical calculations and real-world energy consumption.

Step 2: Mobile sink approach

Mobile sink visits each sensor directly every 30 minutes: - All sensors transmit 1-hop to passing sink (no multi-hop relay burden) - Energy per sensor per visit: 5 mJ (own transmission only) - Visits per hour: 2 visits × 5 mJ = 10 mJ/hour - Sensor lifetime: 26,640 J / (10 mJ × 1 hour) = 2,664,000 hours = 304 years (battery self-discharge limits actual life to ~5-7 years)

Key Insight: The energy hole problem causes network death when only 25% of sensors fail, wasting 75% of deployed capacity. Mobile sinks eliminate this by distributing the relay burden uniformly through direct 1-hop collection.

Decision Framework: Stationary vs Mobile vs Hybrid Architecture Selection

Select the appropriate WSN architecture based on application requirements:

Decision Criterion	Choose Stationary	Choose Mobile	Choose Hybrid
Alert Latency Requirement	<5 seconds required	>1 minute acceptable	<5 sec for alerts, >1 min for bulk data
Network Lifetime Priority	1-2 years sufficient	3-5+ years required	3-5 years with critical uptime
Deployment Density	>50 nodes per 100m² (dense)	<10 nodes per 100m² (sparse)	Mixed density zones
Energy Budget	Unlimited grid power or frequent battery replacement acceptable	Battery replacement impractical (remote location)	Grid power for relays, battery for sensors
Coverage Area	<500m² (single room/building)	>10,000m² (large field, campus)	Multiple zones with different requirements
Node Mobility	Sensors are fixed permanently	Sensors or targets move frequently	Fixed infrastructure + mobile collectors
Data Collection Pattern	Continuous real-time monitoring	Periodic batch collection (hourly/daily)	Real-time for alerts, batch for historical data
Infrastructure Cost	High (many nodes for coverage)	Low (fewer nodes + mobile platform)	Medium (strategic relay placement)
Maintenance Access	Easy (building, campus)	Difficult (wilderness, underwater)	Critical nodes accessible, others remote

Decision Algorithm:

Step 1: Is sub-second latency required for ALL data?

YES → Stationary (mobile sinks introduce minutes-hours of delay)
NO → Continue to Step 2

Step 2: Is the area sparse (nodes >100m apart) OR lifetime >3 years required?

YES → Consider Mobile or Hybrid
NO → Stationary may be sufficient

Step 3: Do you need BOTH real-time alerts AND energy efficiency?

YES → Hybrid Architecture (stationary relay backbone for alerts + mobile sink for bulk collection)
NO → Continue to Step 4

Step 4: How many multi-hop paths >3 hops exist?

50% of nodes require >3 hops → Mobile Sink (energy hole problem severe)
<50% require >3 hops → Stationary Sink (energy distribution manageable with overprovisioning)

Example Applications:

Stationary Architecture:

Smart building environmental monitoring (dense, grid-powered)
Factory floor asset tracking (real-time location required)
Hospital patient monitoring (life-critical latency requirements)
Bridge structural health monitoring (wired power available)

Mobile Architecture:

Wildlife habitat monitoring (sparse, remote, battery-dependent)
Large-scale precision agriculture (100+ hectares, long lifetime needed)
Ocean buoy networks (mobile AUV collectors)
Disaster recovery temporary networks (rapid deployment, harsh conditions)

Hybrid Architecture:

Smart city parking management (5 stationary relays for occupancy alerts + 1 mobile collector for daily statistics)
Industrial warehouse monitoring (stationary fire/intrusion detectors + mobile robot for inventory tracking)
Smart farm (stationary weather stations for real-time alerts + tractor-mounted mobile collector for soil data)
Campus security (stationary cameras for live monitoring + mobile patrol robot for historical video collection)

Common Mistake: Underestimating Multi-Hop Communication Cost

The Mistake: Designers calculate energy budgets assuming each sensor only transmits its own data, forgetting that multi-hop networks require nodes to relay messages from other sensors.

Real-World Example: Smart parking lot deployment (2019) specified 200-node network with 2-year battery life. Initial energy calculation assumed each sensor transmits 10 messages per day at 5 mJ per message = 50 mJ/day. With 2000 mAh @ 3.7V = 26,640 J capacity: 26,640 J / 50 mJ = 532,800 days = 1,459 years expected lifetime.

Actual deployment result: Inner 40 nodes failed after 89 days (16× shorter than predicted).

Post-Mortem Analysis:

Average network topology: 4 hops from edge to sink
Inner nodes relayed messages from 160 outer nodes
Actual inner node load: 10 own + 1,600 relayed = 1,610 messages/day
Actual energy: 1,610 × 5 mJ = 8,050 mJ/day (161× more than predicted!)
Corrected lifetime: 26,640 J / 8,050 mJ = 3,308 days = 9 years per battery… BUT inner nodes died in 89 days

Why the corrected calculation is still wrong: The mistake has TWO layers: 1. Forgot relay burden entirely (addressed in corrected calculation) 2. Forgot that relay burden is NON-UNIFORM (still wrong in correction)

Actual energy distribution:

Outer edge nodes: 10 messages/day × 5 mJ = 50 mJ/day → 1,459 year lifetime
Middle ring nodes: 10 own + 400 relayed = 410 messages/day × 5 mJ = 2,050 mJ/day → 36 year lifetime
Inner ring nodes: 10 own + 1,600 relayed = 1,610 messages/day × 5 mJ = 8,050 mJ/day → 9 year lifetime
Hotspot nodes (directly adjacent to sink): 10 own + ALL 199 other nodes = 2,000 messages/day × 5 mJ = 10,000 mJ/day → 7.3 year lifetime

But wait, there’s a THIRD layer: retransmissions due to collisions.

Collision impact:

Dense inner ring → 40 nodes competing for channel
Collision probability ~15% → average 1.18 retransmissions per successful message
Effective inner node load: 2,000 × 1.18 = 2,360 messages/day × 5 mJ = 11,800 mJ/day
Actual lifetime: 26,640 J / 11,800 mJ = 2,257 days = 6.2 years per battery

Still doesn’t explain 89-day failure!

The REAL culprit: Catastrophic relay cascade failure

As inner nodes deplete, they fail intermittently (low battery voltage → unreliable radio)
Network routing adapts by routing around failing nodes
Remaining inner nodes inherit even MORE relay burden
Accelerating death spiral: 40 inner nodes → 35 functional → 28 → 20 → 10 → 0 (in 89 days)
Once inner ring dies, outer 160 nodes cannot reach sink → total network failure

Corrective Approaches:

Option 1: Overprovisioning inner ring

Deploy 4× redundant nodes in inner ring (160 total nodes instead of 40)
Cost: $12,000 additional hardware
Result: 4× longer inner ring lifetime (356 days) but still eventual cascade failure

Option 2: Mobile sink

1 autonomous robot collects data directly from all 200 nodes (no multi-hop)
All nodes transmit 1-hop → uniform 10 messages/day × 5 mJ = 50 mJ/day per node
Network lifetime: 1,459 years (battery shelf life becomes limiting factor)
Cost: $8,000 robot + $2,000 solar charging station
Result: 16× longer lifetime than overprovisioning, 50% lower cost

Key Lesson: Always model relay burden DISTRIBUTION, not just average. The worst-case hotspot node determines network lifetime, not the average node. Multi-hop energy cost creates non-uniform drain that causes premature network death even when 80%+ of nodes have full batteries. Mobile sinks eliminate this fundamental problem.

60.12 Prerequisites

Before starting this section, you should be familiar with:

Wireless Sensor Networks: Basic WSN architecture and topologies
WSN Overview: Fundamentals: Sensor node characteristics and energy constraints
Sensor Network Routing: Routing protocols and data aggregation
Multi-Hop Ad Hoc: Fundamentals: Dynamic topologies and self-organizing networks

🏷️ Label the Diagram

Code Challenge

60.13 Summary

60.13.1 Key Takeaways

Stationary WSNs are the traditional approach – simple topology, predictable routing, but fundamentally limited by the energy hole problem that causes inner nodes to die 5-10x faster than edge nodes
Mobile WSNs introduce moving elements (sensor nodes, sinks, or Data MULEs) that balance energy consumption, adapt coverage, and extend network lifetime by 2-5x
The choice is not binary – hybrid designs combining stationary infrastructure with mobile collection are often the best solution, providing both real-time alerts and energy-efficient bulk data gathering
Self-CHOP properties (Self-Configure, Self-Heal, Self-Optimize, Self-Protect) enable mobile networks to autonomously manage dynamic topology changes
Path planning matters – adaptive mobile sink routes that respond to node buffer levels and battery status outperform random or fixed routes by 30-50%
Application requirements drive the design – latency tolerance, coverage area, energy budget, and environment dynamism determine whether stationary, mobile, or hybrid architectures are appropriate

60.13.2 Concept Map

Concept	Stationary WSN	Mobile WSN	Hybrid WSN
Energy balance	Poor (energy holes)	Good (distributed collection)	Good (dual-path)
Alert latency	Excellent (< 1s)	Poor (minutes to hours)	Excellent (relay path)
Coverage flexibility	None (fixed)	High (adaptive)	Moderate
Complexity	Low	High	Medium-High
Cost	More nodes needed	Fewer nodes + mobile platform	Nodes + relays + platform
Best lifetime	1x baseline	2-5x baseline	2-4x baseline

Match: Stationary vs Mobile WSN Concepts

Order: WSN Architecture Selection Process

60.14 What’s Next

Topic	Chapter	Description
Human-Centric Sensing	WSN Human-Centric and DTN	Participatory sensing, delay-tolerant networking, and opportunistic communication
Stationary WSN Details	Stationary WSN Fundamentals	Energy hole analysis, coverage planning, and deployment strategies
Mobile WSN Details	Mobile WSN Fundamentals	Self-CHOP properties, mobility advantages, and path optimisation