63  MWSN Nodes, Sinks & MULEs

In 60 Seconds

MWSN Nodes, Sinks & MULEs covers the core principles and practical techniques essential for IoT practitioners. Understanding these concepts enables informed design decisions that balance performance, energy efficiency, and scalability in real-world deployments.

Minimum Viable Understanding

• Mobile WSNs have three key mobile components: mobile sensor nodes (sensors that move), mobile sinks (base stations that move to collect data), and Data MULEs (entities that ferry data using existing mobility patterns).
• Data MULEs exploit existing mobility (buses, animals, vehicles) for zero-cost store-carry-forward data collection, accepting higher latency for dramatically lower infrastructure costs.
• Delay-Tolerant Networking (DTN) protocols like Spray and Wait handle intermittent connectivity by limiting message replication to control overhead while maintaining good delivery probability.

Sensor Squad: The Three Mobile Helpers

Sammy the Sensor was stuck in one place and couldn’t reach the base station. Three helpers offered to solve his problem in different ways:

Helper 1 – Mobile Sammy: “What if I could move around? If I had wheels like a little robot, I could sense AND drive closer to deliver my data!” That’s a mobile sensor node – the sensor itself moves around collecting data.

Helper 2 – Max the Microcontroller on a Bus: “I’ll come to YOU! I’ll ride around on a bus and collect data from all the sensors along the way.” That’s a mobile sink – the base station moves to visit sensors.

Helper 3 – Bella the Battery on a Zebra: “Wait, I’m already walking past Sammy every day on my way to the watering hole! I can just pick up his data when I pass by and drop it off later.” That’s a Data MULE – like a mail carrier who collects letters from mailboxes along a route they were already walking!

Lila the LED asked: “Which helper is best?” Sammy smiled: “It depends! If I need data fast, Helper 2 (mobile sink) is great. If I just need data eventually and want to save energy, Helper 3 (Data MULE) is perfect – because the zebra was going that way anyway, so it costs zero extra energy!”

63.1 Learning Objectives

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

• Design Mobile Sensor Nodes: Differentiate operational models for self-propelled and attached sensors
• Plan Mobile Sink Paths: Select appropriate path planning strategies (random, predefined, adaptive)
• Implement Data MULEs: Construct store-carry-forward data collection systems
• Compare Collection Strategies: Evaluate trade-offs between mobile sinks and data MULEs
• Apply DTN Routing: Analyse Spray and Wait and other delay-tolerant protocols

Key Concepts

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

63.2 Prerequisites

Before diving into this chapter, you should be familiar with:

• Mobile WSN Fundamentals: Understanding MWSN architecture and mobility benefits
• Stationary WSN Fundamentals: Knowledge of the energy hole problem that mobile components solve
• Sensor Network Routing: Basic routing concepts for data aggregation

For Beginners: Three Ways to Add Mobility

Mobile WSNs have three main mobile components:

1. Mobile Sensor Nodes - The sensors themselves move

• Animal collars tracking wildlife
• Smartphones carried by people
• Sensors on autonomous robots

2. Mobile Sinks - The base station moves

• Tractor with receiver driving through farm
• Bus collecting data from roadside sensors
• Drone flying over remote sensors

3. Data MULEs - Dedicated data ferries

• Like a mail carrier picking up letters from mailboxes
• Zebras passing near sensors and carrying data to watering holes
• City buses collecting parking sensor data along routes

Key Difference: Mobile sinks are designed specifically to collect data. Data MULEs use existing mobility (they were going that way anyway!).

63.3 Overview of MWSN Components

Figure 63.1: Components of Mobile WSNs - Overview of mobile sensor nodes, mobile sinks, and data MULEs in MWSN architecture

63.4 Mobile Sensor Nodes

Figure 63.2: Mobile Sensor Nodes - Self-propelled sensors with mobility capability for dynamic network topology

Mobile sensor nodes are the fundamental sensing units equipped with mobility mechanisms.

Mobility Mechanisms:

• Wheels (ground robots)
• Propellers (aerial drones)
• Thrusters (underwater vehicles)
• Animal attachment (wildlife tracking)
• Human-carried (smartphones)

63.4.1 Operational Model

1. Sensing Phase: Nodes sense environmental parameters while moving
2. Data Buffering: Store sensed data locally with timestamps and location
3. Proximity Detection: Identify when sink is within communication range
4. Data Transfer: Opportunistically transmit buffered data to sink
5. Continuation: Resume sensing and movement

viewof flash_kb = Inputs.range([8, 256], {value: 32, step: 8, label: "Flash buffer size (KB)"})

viewof bytes_per_reading = Inputs.range([6, 64], {value: 12, step: 2, label: "Bytes per reading"})

viewof sample_interval_s = Inputs.range([10, 3600], {value: 60, step: 10, label: "Sample interval (seconds)"})

{
  const max_readings = Math.floor((flash_kb * 1000) / bytes_per_reading);
  const total_seconds = max_readings * sample_interval_s;
  const days = total_seconds / 86400;
  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>Maximum readings stored:</strong> ${max_readings.toLocaleString()}</p>
    <p><strong>Buffer lifetime before overflow:</strong> <span style="color:#16A085; font-size:1.1em;">${days.toFixed(1)} days</span></p>
    <p style="font-size:0.85em; color:#7F8C8D;">MULE must visit within ${days.toFixed(1)} days or data is lost. Reduce sample rate or increase flash to extend buffer lifetime.</p>
  </div>`;
}

Putting Numbers to It

Mobile sensor buffer capacity calculation: A wildlife tracking collar (mobile sensor node) senses GPS location every 60 seconds. Each reading: 12 bytes (4 bytes lat, 4 bytes lon, 4 bytes timestamp). The collar has 32 KB flash memory for buffering.

Buffer capacity: \[\text{Max readings} = \frac{32{,}000 \text{ bytes}}{12 \text{ bytes/reading}} = 2{,}666 \text{ readings}\]

Time until buffer full: \[\text{Days} = \frac{2{,}666 \text{ readings}}{1 \text{ reading/min} \times 1{,}440 \text{ min/day}} = 1.85 \text{ days}\]

If the animal encounters a mobile sink (e.g., ranger vehicle) only once per week, the buffer overflows after 1.85 days, losing 5.15 days of data. Solutions: (1) Reduce sampling rate to 5 min intervals → 9.25 days buffer. (2) Increase flash to 128 KB → 7.4 days at 1 min intervals. (3) Compress readings (delta encoding) → 6 bytes per reading → 3.7 days. Trade-off: Lower sampling rate misses short-duration events. Storage expansion adds cost ($2-5). Compression adds processing overhead (5-10 mA for 50 ms per reading = 2.5 mJ).

Figure 63.3: Mobile sensor node state machine showing sensing, buffering, and opportunistic data transfer

Quick Check: Mobile Sensor Nodes

63.5 Mobile Sink (Mobile Base Station)

Original

AI Modern Style

Mobile Sink Path

AI Geometric Style

Mobile Sink Routing

Figure 63.4: Mobile Sink architecture - Base station moves through network to balance energy consumption and extend lifetime

A mobile sink actively moves through the sensor field to collect data from stationary or mobile sensor nodes. This approach addresses the hotspot problem in stationary sink deployments.

Benefits:

• Distributes energy consumption evenly
• Increases network lifetime significantly (up to 5-10x)
• Reduces multi-hop communication overhead
• Balances traffic load

63.5.1 Path Planning Strategies

Figure 63.5: Mobile sink path planning strategies with trade-offs

Strategy Comparison:

Strategy	Latency	Energy Balance	Complexity	Best For
Random Walk	Variable	Good (long-term)	Low	Simple deployments
Predefined	Predictable	Moderate	Low	Regular routes (buses)
Adaptive	Optimized	Excellent	High	Critical data collection

Putting Numbers to It

Comparing mobile sink strategies for a 400-node agricultural WSN across 1 km²: Mobile sink is a tractor that collects data while moving through the field.

Predefined Path (Fixed Route): Tractor follows plowing rows, visiting all 400 sensors sequentially. Path length = 1.2 km, tractor speed = 2 m/s. Time per tour: \(\frac{1{,}200 \text{ m}}{2 \text{ m/s}} = 600 \text{ s} = 10 \text{ min}\).

Random Walk: Tractor moves randomly. Expected time to visit all nodes (coupon collector problem): \[E[\text{visits}] = n \times \sum_{i=1}^{n} \frac{1}{i} = 400 \times H_{400} \approx 400 \times 6 = 2{,}400 \text{ visits}\]

With 5 sensors visited per minute: \(2{,}400 / 5 = 480\) minutes = 8 hours to reach all sensors (48× slower than predefined path).

Adaptive (TSP-based): Tractor optimizes path based on sensor buffer fullness (prioritize sensors with 90%+ buffers). Optimal tour via Traveling Salesman Problem heuristic: 1.05 km (12.5% shorter than predefined rows). Tour time = \(\frac{1{,}050}{2} = 525 \text{ s} = 8.75 \text{ min}\) (12.5% faster than predefined).

Result: Adaptive path saves 1.25 minutes per tour. With 6 tours/hour during workday: \(1.25 \times 6 \times 8 = 60\) minutes saved per day – allowing the tractor to serve a second field or complete tours 15% faster, reducing data latency.

63.6 Data MULEs (Mobile Ubiquitous LAN Extensions)

Figure 63.6: Data MULEs concept - Mobile entities collecting data from stationary sensors by physically moving through network

Data MULEs are mobile entities that physically transport data from sensors to the sink. Unlike mobile sinks that follow planned paths, MULEs often move based on existing mobility patterns (e.g., buses, animals, humans).

63.6.1 Operational Model

1. Mobile entity (bus, animal, robot) moves through the sensor field
2. Sensors detect MULE proximity and transmit buffered data
3. MULE buffers collected data from multiple sensors
4. MULE delivers aggregated data to sink when in range
5. Process repeats with each MULE pass

Figure 63.7: Data MULE store-carry-forward sequence showing opportunistic data collection

63.6.2 Real-World MULE Examples

ZebraNet (Kenya, 2004):

• 7 zebras with peer-to-peer GPS collar nodes deployed across ~2.4 km² near Mpala Research Center
• Each collar node senses location and buffers GPS readings
• When two collars come within range, they exchange data
• At least one collar carried data to the base station via store-carry-forward
• Key insight: Animal movement is zero-cost – the zebras were already moving through the field
• Note: Later similar deployments scaled this concept to larger savanna areas with static sensors

DakNet (India, 2003):

• Rural villages without internet connectivity
• Buses carry Wi-Fi access points as data MULEs
• Villagers upload/download data when bus passes
• Store-carry-forward email and web content
• Result: Internet access for remote communities at minimal cost

63.7 DTN Routing: Spray and Wait

For networks with intermittent connectivity, Delay-Tolerant Networking (DTN) protocols handle message delivery when end-to-end paths rarely exist.

Spray and Wait limits message replication to control overhead while maintaining good delivery probability.

63.7.1 Operation with L=6 Copies

Spray Phase:

• Source has L=6 message copies
• When encountering other nodes, transfer copies
• Binary spray: Split remaining copies (keep 3, give 3)
• Continue until all L copies distributed to different relay nodes

Wait Phase:

• Nodes with copies only forward to destination (direct delivery)
• No forwarding to other relay nodes
• Each holder “waits” to encounter destination directly

Performance Comparison:

Protocol	Copies	Delivery Rate	Overhead
Epidemic	Unlimited	~98%	150x
Spray and Wait (L=6)	6	~85%	6x
Direct Delivery	1	~40%	1x

63.8 Knowledge Check

Quiz: MWSN Components

63.9 Choosing a Data Collection Strategy: Cost and Performance Comparison

Selecting the right mobile data collection approach depends on deployment constraints, latency requirements, and budget. The following decision framework uses real-world numbers from published deployments.

Worked Example: Environmental Monitoring in a 10 km² Nature Reserve

Scenario: 200 sensor nodes monitoring wildlife activity, soil moisture, and microclimate. No cellular coverage. Nearest base station is 8 km away. Budget: $50,000 for 3-year operation.

Option A – Mobile Sink (Autonomous Drone):

• Hardware: DJI Matrice 300 ($6,500) + edge gateway payload ($800)
• Flight time: 55 minutes per charge, covers ~4 km² per sortie
• Daily sorties: 3 (with battery swaps), covering full reserve in 1 day
• Annual operating cost: $2,400 (batteries, maintenance, pilot license)
• Data latency: 4-8 hours (worst case: node surveyed once per day)
• 3-year cost: $6,500 + $800 + $7,200 = $14,500

Option B – Data MULEs (Park Ranger Vehicles):

• Hardware: 4 Raspberry Pi gateways with LoRa ($120 each) mounted on ranger trucks
• Coverage: Rangers patrol ~60% of reserve daily on existing routes
• Data latency: 12-48 hours (depends on patrol schedule, 40% of nodes may wait 2 days)
• Annual operating cost: $200 (hardware replacement, SD cards)
• 3-year cost: $480 + $600 = $1,080

Option C – Multi-hop Relay to Fixed Sink:

• Hardware: 40 relay nodes ($85 each) forming a mesh backbone to base station
• Coverage: All 200 nodes within 3 hops of a relay
• Data latency: 5-30 seconds (real-time)
• Annual operating cost: $1,200 (battery replacement for relay nodes, 6-month battery life)
• 3-year cost: $3,400 + $3,600 = $7,000

Criterion	Mobile Sink (Drone)	Data MULE (Rangers)	Multi-hop Relay
3-Year Cost	$14,500	$1,080	$7,000
Latency	4-8 hours	12-48 hours	5-30 seconds
Coverage	100% (planned path)	60% daily	100% (if mesh designed)
Node Energy	Low (short TX burst)	Low (short TX burst)	High (relay duty)
Weather Dependence	High (no-fly in rain)	Low (trucks operate)	None
Scalability	Add flight time	Limited by patrol routes	Add relay nodes
Maintenance	Moderate (drone upkeep)	Very low	Moderate (batteries)

Decision: For this reserve, Option C (multi-hop relay) provides the best balance – real-time data for wildlife alerts at moderate cost. Option B is the fallback for budget-constrained deployments where 24-48 hour latency is acceptable. Option A is justified only if aerial imagery is also needed (dual-purpose drone).

Deployment Need	Best Strategy	Why
Real-time alerts (security, fire)	Multi-hop relay	Sub-second latency required
Daily environmental logs	Data MULE	Lowest cost, latency acceptable
Inaccessible terrain (mountains, ocean)	Mobile sink (UAV/AUV)	No roads for MULEs, no relay infrastructure
Urban air quality with existing transit	Data MULE (buses)	Zero marginal cost, predictable routes
Precision agriculture (irrigation control)	Multi-hop relay	Actuator commands need real-time delivery
Disaster area (post-earthquake)	Mobile sink (drone)	No infrastructure, terrain altered

Common Pitfalls

1. Prioritizing Theory Over Measurement in MWSN Nodes, Sinks & MULEs

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

63.10 Summary

This chapter covered the three key components of mobile wireless sensor networks:

• Mobile Sensor Nodes: Self-propelled or attached sensors using wheels, propellers, thrusters, or animal/human carriers, operating through sense-buffer-transfer cycles
• Mobile Sinks: Moving base stations that actively collect data using random walk, predefined, or adaptive path planning strategies
• Data MULEs: Mobile entities that leverage existing mobility (buses, animals, vehicles) for zero-cost store-carry-forward data collection
• DTN Routing: Spray and Wait and other protocols for intermittent connectivity, trading delivery guarantees for bounded overhead

Match: MWSN Components and Characteristics

Order: Data MULE Collection Sequence

63.11 What’s Next

Topic	Chapter	Description
MWSN Types	MWSN Types and Mobile Entities	Underwater, terrestrial, and aerial mobile sensor networks
Human-Centric Sensing	WSN Human-Centric Networks and DTN	Participatory sensing with smartphones and DTN protocols
Production Deployment	WSN Production Deployment	Real-world deployment frameworks and cost analysis