72  Mobile Sink Planning

In 60 Seconds

Mobile sinks (ground robots or UAVs) eliminate the hotspot problem by physically traveling to collect data from sensor clusters, but path planning is critical since 70-80% of energy goes to movement. Optimized TSP tours reduce travel distance 30-40% over random walks, while multi-MULE strategies (partitioned zones, opportunistic, auction-based) scale collection to large networks. UAV data mules get only 15-22 minutes of actual mission time per charge, making energy-efficient path planning the dominant design constraint.

Minimum Viable Understanding

• Mobile sink path planning ranges from simple (random walk, fixed routes) to optimized (TSP tours reduce travel distance 30-40%), with adaptive planning handling runtime events like buffer overflows and high-priority alerts via greedy insertion heuristics.
• Multi-MULE coordination uses four strategies: partitioned zones (simple, predictable), opportunistic (zero-cost existing mobility), auction-based (dynamic, load-balanced), and leader-follower (globally optimal but single point of failure).
• Mobile collectors spend 70-80% of energy on movement, making path efficiency the dominant factor in mission success – UAVs get only 15-22 minutes of actual mission time from a full battery.

Sensor Squad: Planning the Perfect Route

Max the Microcontroller was planning the route for a mobile data collector – a little robot that drives around collecting data from sensors.

“It’s like planning the best trick-or-treat route on Halloween!” explained Max. “You want to visit every house, but you don’t want to walk back and forth wasting time.”

Sammy the Sensor asked: “What if you plan a route but then someone tells you there’s full-size candy bars two streets over? Do you stick to the plan?”

“Great question! That’s called adaptive planning,” said Max. “If a sensor says ‘My memory is almost full – I’ll lose data in 2 hours!’ we change the route to visit that sensor NEXT, then go back to the original plan. It’s like getting a text from your friend saying ‘Come NOW, I have extra candy!’”

Lila the LED added: “And what if we have THREE robots collecting data? They need to split up so they don’t all visit the same sensors!”

“Exactly! We can divide the area into zones – one robot per zone, like splitting a neighborhood between trick-or-treaters. Or we can use an auction where sensors say ‘I need help!’ and the closest robot responds,” explained Max.

Bella the Battery reminded everyone: “But remember – 70-80% of the robot’s energy goes to just DRIVING around. So making the route shorter saves way more energy than anything else!”

For Beginners: Understanding Mobile Sink Path Planning

A mobile sink is a data collector that physically moves through a sensor field to pick up data. Think of it as a mail carrier visiting mailboxes along a route.

Key concepts:

Strategy	How It Works	Best For
Random Walk	Wander randomly, collect from nearby sensors	Simple/unplanned environments
Fixed Route	Follow same path every time (like a bus)	Regular, predictable monitoring
TSP Tour	Compute shortest path visiting all sensors	Time-critical data collection
Adaptive	Adjust route based on real-time urgency	Dynamic priorities, emergencies

Why path planning matters: A TSP-optimized tour typically travels 30-40% less distance than random movement, directly saving energy and time. For a UAV with only 22 minutes of flight time, that difference determines whether the mission succeeds or fails.

Multiple collectors: When you have several mobile collectors, they need to coordinate to avoid visiting the same sensors while covering the entire network. Think of it as multiple delivery drivers splitting up a city’s addresses.

72.1 Learning Objectives

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

• Design Mobile Sink Systems: Build path planning and optimization for data collection
• Apply TSP-Based Tour Planning: Implement optimal visiting sequences for sensor networks
• Configure Adaptive Path Planning: Handle runtime events like buffer overflows and priority data
• Coordinate Data MULEs: Schedule multiple mobile data collectors for efficient coverage
• Implement Multi-MULE Strategies: Deploy partitioned, opportunistic, and auction-based coordination

72.2 Prerequisites

Required Chapters:

• WSN Production Deployment - Production framework basics
• WSN Stationary Mobile Fundamentals - Core mobility concepts

Technical Background:

• Mobile sink architectures
• Energy consumption in mobile systems
• Data collection strategies

Estimated Time: 18 minutes

72.3 Mobile Sink Path Planning Strategies

Mobile sinks must balance latency, energy consumption, and data collection completeness.

72.3.1 Path Planning Objectives

Strategy	Latency	Energy (Sink)	Energy (Sensors)	Complexity	Best For
Random Walk	High (hours)	High (inefficient)	Low (opportunistic)	Low	Unstructured environments
Fixed Route	Medium (predictable)	Low (optimized)	Low (scheduled wake)	Low	Regular monitoring
TSP Tour	Low (optimized)	Medium (good path)	Low (single visit)	High	Time-critical data
Adaptive	Variable	Medium	Medium	Very High	Dynamic priorities
Multi-Sink	Very Low (parallel)	High (multiple vehicles)	Low (load balanced)	High	Large-scale systems

72.3.2 Traveling Salesman Problem (TSP) Tours

For data collection from stationary sensors, mobile sink computes optimal visiting order.

Problem Formulation:

• Given: N sensor locations {s1, s2, …, sn}
• Find: Tour minimizing total distance while visiting all sensors
• Constraint: Return to base station

Optimization Variants:

1. Minimum Latency Tour: Visit high-priority sensors first
   • Weight edges by data urgency: dij x (1 + priorityj)
   • Result: Critical sensors serviced quickly
2. Energy-Constrained Tour: Limit tour length to sink battery budget
   • Partial tours if cannot visit all nodes
   • Return to base for recharge, then continue
3. Deadline-Aware Tour: Ensure data collected before expiry
   • Some sensors have time-sensitive data (e.g., event detection)
   • Schedule visits to meet deadlines

Example - Wildlife Camera Network:

• 50 cameras monitoring migration route
• Mobile ATV collects images weekly
• TSP tour: 42 km vs random walk: 68 km (38% reduction)
• Tour time: 3.5 hours vs 5.5 hours
• Battery: 60% remaining vs 15% (safety margin)

Putting Numbers to It

Calculate energy savings from TSP-optimized tour for the ATV data collector @ 12 km/h with 25W movement + 8W collection power:

Random walk: Distance = 68 km, time = \(\frac{68}{12} = 5.67\text{ hr}\). Movement energy: \(E_{\text{move}} = 25\text{ W} \times 5.67\text{ hr} = 141.75\text{ Wh}\). Collection (50 cameras × 30 s): \(E_{\text{collect}} = 8\text{ W} \times \frac{50 \times 30}{3600} = 3.33\text{ Wh}\). Total = 145.08 Wh

TSP tour: Distance = 42 km, time = 3.5 hr. \(E_{\text{move}} = 25 \times 3.5 = 87.5\text{ Wh}\), \(E_{\text{collect}} = 3.33\text{ Wh}\). Total = 90.83 Wh

Savings: \(\frac{145.08 - 90.83}{145.08} = 37.4\%\) reduction enables twice-weekly collections on same battery charge!

Try It: TSP Tour Energy Savings Calculator

Explore how tour distance reduction and vehicle parameters affect energy savings.

viewof random_dist_km = Inputs.range([20, 200], {value: 68, step: 1, label: "Random walk distance (km)"})
viewof tsp_reduction_pct = Inputs.range([10, 50], {value: 38, step: 1, label: "TSP distance reduction (%)"})
viewof vehicle_speed_kmh = Inputs.range([1, 50], {value: 12, step: 1, label: "Vehicle speed (km/h)"})
viewof move_power_w = Inputs.range([5, 500], {value: 25, step: 5, label: "Movement power (W)"})
viewof num_sensors = Inputs.range([5, 500], {value: 50, step: 5, label: "Number of sensors"})
viewof collect_time_s = Inputs.range([10, 120], {value: 30, step: 5, label: "Collection time per sensor (s)"})
viewof collect_power_w = Inputs.range([1, 50], {value: 8, step: 1, label: "Data collection power (W)"})

tsp_results = {
  const tsp_dist = random_dist_km * (1 - tsp_reduction_pct / 100);
  const collect_hr = (num_sensors * collect_time_s) / 3600;

  const random_move_wh = move_power_w * (random_dist_km / vehicle_speed_kmh);
  const random_collect_wh = collect_power_w * collect_hr;
  const random_total = random_move_wh + random_collect_wh;

  const tsp_move_wh = move_power_w * (tsp_dist / vehicle_speed_kmh);
  const tsp_collect_wh = collect_power_w * collect_hr;
  const tsp_total = tsp_move_wh + tsp_collect_wh;

  const savings_pct = ((random_total - tsp_total) / random_total * 100);
  const tsp_time_hr = (tsp_dist / vehicle_speed_kmh) + collect_hr;
  const random_time_hr = (random_dist_km / vehicle_speed_kmh) + collect_hr;

  return { tsp_dist, random_total, tsp_total, savings_pct, tsp_time_hr, random_time_hr };
}

html`<div style="background: var(--bs-light, #f8f9fa); padding: 1rem; border-radius: 8px; border-left: 4px solid #16A085; margin-top: 0.5rem;">
<p><strong>TSP Tour Distance:</strong> ${tsp_results.tsp_dist.toFixed(1)} km (vs ${random_dist_km} km random walk)</p>
<p><strong>Random Walk Energy:</strong> ${tsp_results.random_total.toFixed(1)} Wh &nbsp;|&nbsp; <strong>TSP Tour Energy:</strong> ${tsp_results.tsp_total.toFixed(1)} Wh</p>
<p><strong>Energy Savings:</strong> ${tsp_results.savings_pct.toFixed(1)}% &nbsp;|&nbsp; <strong>Time Savings:</strong> ${(tsp_results.random_time_hr - tsp_results.tsp_time_hr).toFixed(2)} hr</p>
<p style="color: ${tsp_results.savings_pct > 30 ? '#16A085' : '#E67E22'}; font-weight: bold;">${tsp_results.savings_pct > 30 ? 'High-impact optimization — TSP planning strongly recommended.' : 'Moderate savings — consider whether TSP complexity is justified.'}</p>
</div>`

72.3.3 Adaptive Path Planning

Dynamic environments require runtime path adjustments.

Adaptive path planning feedback loop

Figure 72.1: Adaptive planning adjusts mobile sink routes in response to network events and changing priorities.

Trigger Conditions for Replanning:

1. High-Priority Event: Sensor detects fire, intrusion, equipment failure
   • Immediate deviation to event location
   • Collect detailed data, verify alert
   • Return to planned tour
2. Buffer Overflow Warning: Sensor reports buffer >80% full
   • Risk of data loss if not serviced soon
   • Insert into tour before overflow
3. Energy Depletion Alert: Node battery critically low
   • Last chance to collect accumulated data
   • High priority visit
4. Obstacle Detection: Planned path blocked (road closed, terrain impassable)
   • Recompute feasible path
   • May skip unreachable sensors

Algorithm - Greedy Insertion Heuristic:

Current tour: [Base -> A -> B -> C -> D -> Base]
New high-priority node: E

For each edge in tour (A-B, B-C, C-D, D-Base):
    cost_insert = distance(prev, E) + distance(E, next) - distance(prev, next)
    Select minimum cost insertion point

Result: [Base -> A -> E -> B -> C -> D -> Base]

Real-World Example - Disaster Response:

• Hurricane aftermath monitoring (Florida, 2023)
• 100 sensors in evacuation zone
• Planned tour: 8-hour systematic sweep
• Hour 3: Sensor #47 detects gas leak (high priority)
• Replanning: Insert #47 next (15 min detour), complete original tour
• Result: Gas leak confirmed in 20 minutes vs 5 hours (planned visit)

Quick Check: Adaptive Path Planning

72.4 Data MULE Coordination

Multiple mobile collectors require coordination to avoid redundant visits and coverage gaps.

72.4.1 Multi-MULE Strategies

Multi-MULE coordination strategies

Figure 72.2: MULE coordination strategies: partitioned zones assign fixed regions to each MULE, while auction-based coordination allows sensors to select the best MULE dynamically based on distance and availability.

Strategy	Coordination	Coverage	Energy	Latency	Best For
Partitioned	Static zones	Guaranteed	Balanced	Predictable	Structured deployments
Opportunistic	None (independent)	Redundant	Unbalanced	Variable	Sparse networks
Auction-Based	Bidding protocol	Optimized	Near-optimal	Low	Dynamic environments
Leader-Follower	Central control	Complete	Leader-dependent	Low	Small MULE teams

72.4.2 Partitioned Zones Strategy

Divide network into regions, assign one MULE per region.

Implementation:

• Geographic partitioning (Voronoi cells)
• Each MULE responsible for all sensors in its zone
• No inter-MULE communication required

Example: 400-node farm, 4 MULEs, 100 nodes each

Pros:

• Simple, no coordination overhead
• Predictable coverage and latency
• Easy troubleshooting (clear responsibility)

Cons:

• Load imbalance if zones have different node densities
• Single point of failure per zone
• Cannot adapt to MULE failures

72.4.3 Auction-Based Coordination

Sensors “advertise” data urgency, MULEs “bid” based on capability.

Protocol Flow:

1. Sensors broadcast data urgency (buffer level, priority)
2. MULEs receive advertisements within communication range
3. Each MULE calculates bid: distance, battery, current schedule
4. Sensor selects MULE with best bid (lowest cost, fastest service)
5. Selected MULE adds sensor to tour

Example Protocol:

Sensor S broadcasts: "100 KB data, priority=HIGH, buffer=85%"
MULE M1: "Distance=500m, ETA=10min, battery=60%"
MULE M2: "Distance=1200m, ETA=25min, battery=90%"
Sensor S selects: M1 (faster service despite lower battery)
M1 adds S to tour, navigates to location, collects data

Advantages:

• Dynamic adaptation to changing conditions
• Load balancing across MULEs
• Graceful degradation when MULEs fail

Challenges:

• Communication overhead for bidding
• May require repeated auctions
• Convergence time in dense networks

72.4.4 Opportunistic Collection

MULEs operate independently, collecting data when encountering sensors.

Best For:

• Human-carried devices (smartphones)
• Vehicles with unpredictable routes (taxis, delivery trucks)
• Sparse networks where coordination impractical

Trade-offs:

• High latency variability
• Potential redundant collection (multiple MULEs visit same sensor)
• No guaranteed coverage

Example - Urban Bus Network:

• 50 buses with data collection hardware
• 500 sensors along bus routes
• Each sensor opportunistically uploads when bus passes
• Average latency: 4-6 hours (bus route frequency)
• Cost: Zero dedicated mobility (existing infrastructure)

72.4.5 Leader-Follower Coordination

Central controller (leader) assigns tasks to MULEs (followers).

Architecture:

     Central Controller
     /      |      \
   MULE1  MULE2  MULE3
     |      |      |
  [Sensors in assigned area]

Protocol:

1. Controller receives sensor status updates
2. Controller computes optimal MULE assignments
3. Controller sends route instructions to MULEs
4. MULEs execute assigned routes
5. MULEs report completion, controller reassigns

Advantages:

• Global optimization (controller sees entire network)
• Can handle MULE failures (reassign to remaining MULEs)
• Prioritization based on network-wide view

Challenges:

• Single point of failure (controller)
• Communication overhead to/from controller
• Latency for centralized decision-making

72.5 Practical Considerations

72.5.1 MULE Selection Criteria

When choosing mobile data collectors, consider:

Factor	Ground Robot	UAV/Drone	Vehicle (Bus/Tractor)	Human Carrier
Speed	0.5-2 m/s	10-30 m/s	5-20 m/s	1-2 m/s
Range	2-5 km	10-30 km	Unlimited	1-3 km
Payload	1-10 kg	0.5-2 kg	50+ kg	1-5 kg
Terrain	Limited	Excellent	Road-only	Moderate
Cost	$2K-20K	$1K-10K	Existing	$0 (labor)
Control	Autonomous	Autonomous/Pilot	Driver	Volunteer
Best Use	Warehouses, factories	Agriculture, disaster	Urban sensing	Participatory

72.5.2 Energy Budget Allocation

Mobile collectors must budget energy between:

1. Movement (typically 70-80%):
   • Ground robots: 5-20W locomotion
   • UAVs: 100-500W flight
   • Vehicles: N/A (fuel-powered)
2. Communication (10-20%):
   • Collecting data from sensors
   • Uploading to base station
   • Coordination with other MULEs
3. Computation (5-10%):
   • Path planning
   • Data aggregation
   • Navigation/localization

Example - UAV Data Collection:

• Total battery: 5000 mAh @ 22.2V = 111 Wh
• Flight power: 300W (22 min flight time)
• Communication: 5W during hover
• Computation: 10W continuous
• Practical mission: 15 min flight + 5 min data collection + reserve

Putting Numbers to It

Calculate actual usable mission time for UAV accounting for all power consumers:

Battery: \(E_{\text{total}} = 5000\text{ mAh} \times 22.2\text{ V} = 111\text{ Wh}\). Reserve (20%): \(E_{\text{reserve}} = 22.2\text{ Wh}\). Usable = 88.8 Wh.

Power budget: Flight: \(P_{\text{flight}} = 300\text{ W}\). Hover/collect: \(P_{\text{hover}} = 300\text{ W (motors)} + 5\text{ W (radio)} + 10\text{ W (compute)} = 315\text{ W}\).

Mission (15 min flight + 5 min collect): \[E_{\text{mission}} = (300 \times 0.25) + (315 \times 0.083) = 75 + 26.25 = 101.25\text{ Wh}\]

Feasibility: \(101.25\text{ Wh} > 88.8\text{ Wh}\) → infeasible! Must reduce flight time to ~12 min. This illustrates why UAV missions are so energy-constrained.

Interactive: Target Handoff Between Sensors Animation

Worked Example: TSP Tour Planning for Mobile Sink

Scenario: A 100-hectare vineyard needs wireless sensor monitoring for soil moisture. The farm has 40 sensor clusters distributed across the field. A mobile data collector (autonomous ground vehicle) must visit all clusters daily to download buffered data.

Given Parameters:

• 40 sensor clusters at known GPS coordinates
• Mobile collector max speed: 2 m/s (walking pace)
• Data collection time per cluster: 30 seconds
• Available collection window: 4 hours per day
• Collector battery: 150 Wh capacity
• Movement power: 25W, Data collection power: 8W

Step 1: Calculate naive random-walk baseline

• Random walk average distance between 40 points in 100 hectares (1000m × 1000m): approximately 42 km
• Travel time: 42,000 m / 2 m/s = 21,000 seconds = 5.8 hours
• Collection time: 40 clusters × 30 sec = 1,200 seconds = 0.33 hours
• Total time: 6.13 hours (exceeds 4-hour budget)
• Energy: (21,000 sec × 25W) + (1,200 sec × 8W) = 525,000 + 9,600 = 534,600 J = 148.5 Wh

Step 2: Apply TSP-based tour optimization

• Use nearest-neighbor heuristic to construct tour
• Optimized tour distance: 26 km (38% reduction from random walk)
• Travel time: 26,000 m / 2 m/s = 13,000 seconds = 3.6 hours
• Collection time: 0.33 hours (unchanged)
• Total time: 3.93 hours (fits within 4-hour budget)
• Energy: (13,000 × 25W) + (1,200 × 8W) = 325,000 + 9,600 = 334,600 J = 92.9 Wh

Step 3: Add adaptive replanning for high-priority clusters

• 5 clusters report buffer >80% full (2-hour overflow risk)
• Insert these clusters early in tour using greedy insertion
• Detour cost: +1.2 km (5% additional distance)
• Adjusted tour: 27.2 km, 3.78 hours travel + 0.33 hours collection = 4.11 hours total
• Energy: (13,600 × 25W) + (1,200 × 8W) = 340,000 + 9,600 = 349,600 J = 97.1 Wh

Key Results:

• TSP tour reduces travel distance by 38% vs random walk
• Fits within time budget (4.11 hours vs 6.13 hours for random)
• Consumes 97.1 Wh vs 148.5 Wh (35% energy savings)
• Battery capacity utilization: 65% (leaves 35% safety margin)
• Adaptive replanning prevents data loss at 5 critical clusters with only 4.6% additional travel cost

Real-World Impact: California vineyard deployment (2022) achieved similar results: 40% travel reduction, 3-year mobile collector lifetime on solar charging, zero data loss from buffer overflows.

Decision Framework: Mobile Sink Path Planning Strategy Selection

When designing a mobile sink system, choose the appropriate path planning strategy based on your application requirements:

Criterion	Random Walk	Fixed Route	TSP Tour	Adaptive Planning
Deployment Complexity	Trivial (no planning)	Low (pre-compute once)	Medium (compute tour)	High (runtime replanning)
Data Latency	High (hours, unpredictable)	Medium (predictable cycle)	Low (optimized tour)	Very Low (priority-driven)
Energy Efficiency	Poor (40% wasted travel)	Good (if route optimized)	Excellent (minimal travel)	Excellent (plus reactive)
Adaptability	None (blind wandering)	None (fixed path)	None (static tour)	High (runtime adjustment)
Computational Cost	Zero	Zero (offline)	Medium (one-time TSP)	High (continuous updates)
Buffer Overflow Risk	High (unpredictable visits)	Medium (fixed intervals)	Low (optimized timing)	Very Low (priority-aware)
Best For	Exploratory deployments, unknown terrain	Regular monitoring, stable conditions	Time-critical collection, known layout	Dynamic priorities, mission-critical data

Decision Rules:

Use Random Walk when:

• Deployment area is unknown or changing
• No time constraints on data collection
• Simplicity is paramount (proof-of-concept, research)
• Sink has unlimited energy (e.g., fuel-powered vehicle)

Use Fixed Route when:

• Sensor locations are static and known
• Data generation rates are uniform and predictable
• Environmental conditions are stable (no obstacles, no failures)
• Route can be pre-planned once and reused indefinitely

Use TSP Tour when:

• Time budget is constrained (must visit all sensors within deadline)
• Travel distance directly impacts cost or energy
• Sensor locations are known and static
• No runtime replanning capability available

Use Adaptive Planning when:

• Some sensors have higher priority than others
• Buffer overflow risk is unacceptable
• Sensor failures or obstacles require route changes
• Real-time events (alerts, emergencies) need immediate response
• System can afford computational overhead for replanning

Hybrid Approach (Recommended for Production):

• Baseline: Pre-computed TSP tour (covers all sensors optimally)
• Overlay: Adaptive replanning for high-priority events (buffer >80%, alerts)
• Fallback: Fixed route if replanning fails or times out
• Result: 95% of tours follow optimal TSP path, 5% deviate for urgent needs

Common Mistake: Ignoring Movement Energy in Mobile Sink Design

The Mistake: Designers focus on optimizing sensor energy (duty cycling, compression, aggregation) while treating the mobile sink’s movement energy as “free” because it’s a separate platform (vehicle, UAV, robot).

Real-World Example: Wildlife tracking project (2020) deployed 200 stationary sensors and 1 mobile UAV collector. Design focused on sensor battery life (achieved 3-year lifetime through aggressive duty cycling). UAV battery lasted only 22 minutes per charge.

Calculation Breakdown:

• UAV battery: 5000 mAh @ 22.2V = 111 Wh
• Flight power consumption: 300W
• Flight time: 111 Wh / 300W = 0.37 hours = 22 minutes
• Mission requirement: Visit 200 sensors @ 30 seconds each = 100 minutes of flight + collection time
• Result: UAV could only visit 40 sensors per flight (20% coverage)

The Hidden Cost:

• 5 flights needed per full collection cycle
• UAV required 6 recharge cycles per day (25 minutes flight + 45 minutes recharge = 70 minutes per cycle)
• Human operator cost: $40/hour × 8 hours/day × 365 days = $116,800/year just to manage charging
• Failed to meet “autonomous” design goal

Why This Happens:

1. Separate budgets: Sensor and collector budgets managed by different teams
2. Perception: “The robot has a battery, sensors have tiny batteries” → sensors seem more constrained
3. Reality inversion: Mobile collectors often consume 100-1000× more power than sensors (25W ground robot vs 0.05W sensor, 300W UAV vs 0.05W sensor)
4. Movement cost dominance: 70-80% of mobile sink energy goes to locomotion, not communication

Corrective Approach for Wildlife Tracking Redesign (2021):

• Reduced sensor coverage to 80 nodes (40% reduction) using Voronoi clustering
• Optimized UAV tour using TSP → 35 km flight path vs 52 km random walk (33% reduction)
• Solar charging stations at 3 waypoints → 8-minute charging boost during mission
• Result: Single UAV flight covers all 80 sensors in 68 minutes (within battery budget)
• Annual cost: $12,000 infrastructure vs $116,800 labor (90% savings)

Key Lesson: Mobile sink movement energy is often the DOMINANT cost in the system. Path planning optimization (TSP, adaptive routes) that reduces travel distance by 30-40% can mean the difference between mission success and failure. Always calculate the complete energy budget including locomotion BEFORE deployment.

Common Pitfalls

1. Prioritizing Theory Over Measurement in Mobile Sink Planning

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

72.6 Summary

This chapter covered mobile sink path planning and multi-MULE coordination:

Key Takeaways:

1. Path Planning Strategies: TSP tours reduce travel distance 30-40% vs random walks, while adaptive planning handles runtime events like buffer overflows and priority alerts.

2. Greedy Insertion: When high-priority events occur, insert the urgent node into the current tour at the minimum-cost position to minimize detour.

3. Multi-MULE Coordination: Choose partitioned zones for simplicity, auction-based for dynamic environments, or opportunistic for existing infrastructure (buses, vehicles).

4. Energy Budgeting: Mobile collectors spend 70-80% of energy on movement, making path efficiency critical for mission success.

72.7 Knowledge Check

Test Your Understanding

Question 1: A mobile sink is following a TSP tour visiting 50 sensors. At sensor #10, it receives an alert that sensor #35 is at 90% buffer capacity and will overflow in 2 hours. The original tour would visit #35 in 4 hours. What should the sink do?

1. Complete the original tour and accept the data loss at sensor #35
2. Abandon the original tour and go directly to sensor #35
3. Use greedy insertion to add sensor #35 as the next stop, then resume the original tour
4. Broadcast to all sensors asking them to reduce data generation rate

Answer

c) Use greedy insertion to add sensor #35 as the next stop, then resume the original tour. Greedy insertion finds the minimum-cost point to insert the urgent sensor into the current tour. The sink deviates briefly to service sensor #35 (preventing data loss within the 2-hour deadline), then continues the original tour. This adds only ~5% to total tour length while preventing critical data loss. Abandoning the tour wastes the planned route, and reducing data generation loses quality for all sensors.

Question 2: A farm needs 4 mobile collectors (MULEs) to cover 400 sensor nodes. Which coordination strategy requires the least communication overhead?

1. Auction-based coordination where sensors bid for MULE service
2. Leader-follower with a central controller assigning routes
3. Partitioned zones with each MULE assigned to 100 fixed sensors
4. Opportunistic collection where all MULEs roam independently

Answer

c) Partitioned zones with each MULE assigned to 100 fixed sensors. Geographic partitioning (e.g., Voronoi cells) assigns each MULE a fixed region with no inter-MULE communication needed. Each MULE independently covers its zone. Auction-based requires continuous bidding messages; leader-follower requires constant controller communication; opportunistic has zero coordination but may result in redundant visits and coverage gaps. Partitioned zones sacrifice adaptability for simplicity and zero coordination overhead.

Question 3: A UAV data collector has a 5000 mAh battery at 22.2V (111 Wh total). Flight consumes 300W. How much actual mission time (flight + data collection) is available?

1. About 5 minutes
2. About 22 minutes
3. About 1 hour
4. About 3 hours

Answer

b) About 22 minutes. With 111 Wh of energy and 300W flight power consumption: 111 Wh / 300 W = 0.37 hours = 22 minutes of total flight time. In practice, 15 minutes of flight + 5 minutes of hover/data collection + safety reserve. This extreme constraint is why path efficiency is critical for UAV-based data collection – a 30% shorter TSP tour means the difference between covering all sensors or running out of battery mid-mission.

Quiz: Mobile Sink Planning

Match: Mobile Sink Planning Concepts

Order: Mobile Sink Data Collection Mission

72.8 What’s Next?

Topic	Chapter	Description
Best Practices	WSN Best Practices	Decision frameworks, pre-deployment checklists, and monitoring KPIs
Production Review	WSN Stationary/Mobile Review	Comprehensive review with TCO analysis and deployment strategies
Production Deployment	WSN Production Deployment	Architecture comparison and real-world deployment examples