33  WSN Tracking: Problem Formulations

In 60 Seconds

Three WSN tracking formulations exist: push (sensors report proactively – lowest latency, highest energy), poll (sink queries on-demand – lowest energy for sparse targets, higher latency), and guided (active tracker intercepts target using network position updates). Choosing the wrong formulation wastes 10x energy or misses critical events. Use push for real-time safety, poll for large battery-constrained deployments, guided for physical interception.

33.1 Learning Objectives

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

• Explain Push-Based Tracking: Describe proactive sensor reporting for real-time tracking applications
• Design Poll-Based Tracking: Construct on-demand query systems for energy-efficient tracking
• Implement Guided Tracking: Build active tracker interception using network-provided position updates
• Select Formulations: Choose the appropriate tracking formulation based on application requirements
• Evaluate Trade-offs: Quantify energy consumption vs latency trade-offs in tracking system design

MVU: Minimum Viable Understanding

Core concept: Three fundamental approaches exist for WSN tracking - push (sensors report proactively), poll (sink queries on-demand), and guided (active tracker intercepts target). Why it matters: Choosing the wrong formulation can waste 10x more energy or miss critical tracking events entirely. Key takeaway: Push for real-time critical applications, poll for battery-constrained large deployments, guided when physical interception is the goal.

For Beginners: WSN Tracking: Problem Formulations

Object tracking with sensor networks means following the movement of people, animals, or things through a monitored area. Think of how a relay team passes a baton – as a tracked object moves, responsibility passes from one sensor to the next, keeping continuous watch. The challenge is doing this smoothly so the object is never lost between handoffs.

Sensor Squad: Three Ways to Find a Lost Puppy

The Sensor Squad was helping find a lost puppy in the park! They discovered three different strategies:

Strategy 1 – PUSH (Sammy’s idea): “Every sensor shouts ‘I SEE THE PUPPY!’ the moment they spot it!” said Sammy the Sensor. “The base station gets updates right away – super fast! But everyone is shouting all the time, which drains Bella’s battery quickly.”

Strategy 2 – POLL (Bella’s idea): “To save my energy,” said Bella the Battery, “the base station only ASKS ‘Has anyone seen the puppy?’ when it needs to know. Sensors sleep until asked! Much less battery drain, but there’s a delay – the puppy might move before we ask!”

Strategy 3 – GUIDED (Lila’s idea): “What if we have a DRONE?” suggested Lila the LED excitedly. “The sensors tell the drone where the puppy is, and the drone flies there to catch it! The network GUIDES the drone to intercept!”

Max the Microcontroller summed it up: “PUSH is fastest but uses most energy. POLL saves energy but is slower. GUIDED is for when you actually need to CATCH something! Each strategy is perfect for different situations.”

“Which one do we pick?” asked Sammy. Max replied: “For a lost puppy? PUSH – we need to find it NOW before it runs away!”

33.2 Prerequisites

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

• WSN Tracking: Fundamentals: Overview of tracking concepts and challenges
• Wireless Sensor Networks: Understanding WSN architecture, multi-hop communication, and coverage concepts
• WSN Overview: Fundamentals: Knowledge of sensor node capabilities and energy constraints

33.3 Target Tracking Problem Formulations

⏱️ ~15 min | ⭐⭐⭐ Advanced | 📋 P05.C39.U01

Key Concepts

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

Figure 33.1: Target Tracking in Wireless Sensor Networks - Sensors collaboratively detecting, tracking, and predicting target movement

Target Tracking

Figure 33.2: WSN target tracking showing collaborative sensor detection and trajectory estimation for moving targets.

WSN Tracking Algorithm

Figure 33.3: WSN tracking algorithm stages: detection, cooperation, localization, and prediction working together for efficient target tracking.

Detection Complexity Scenarios:

Single source single object detection

Figure 33.4: Simple tracking scenario: One sensor detects one target - the foundation of WSN tracking algorithms

Multiple source multiple object detection

Figure 33.5: Complex tracking scenario: Multiple sensors collaboratively tracking multiple targets - requires data association algorithms to match observations to targets

Target tracking algorithms estimate trajectories of one or more moving objects using distributed sensor measurements. The problem formulation determines how the algorithm operates and what trade-offs it makes.

33.3.1 Three Tracking Formulations

Three WSN tracking formulations overview

Figure 33.6: Three WSN tracking formulations: Push-based (sensors proactively report detections for real-time tracking with higher energy cost), Poll-based (sink queries sensors on-demand for energy-efficient but higher-latency tracking), and Guided (active tracker moves to intercept target using network-provided position updates).

Alternative View: Tracking Formulation Trade-offs

This variant presents the same three formulations through a trade-off comparison lens, helping system designers choose based on application requirements.

Tracking formulation trade-off matrix showing push vs poll vs guided selection criteria

Selection Guidance: Choose Push for critical real-time applications (security, wildlife), Poll for large-scale deployments with battery constraints (smart cities), and Guided when physical interception is the goal (border security, rescue operations).

Figure 33.7: Handoff Timeline Variant: This sequence diagram shows the critical handoff process as a target moves between sensor coverage zones. At t=0, Sensor A tracks the target. At t=2s, A predicts the trajectory and proactively wakes Sensor B. At t=4s, both sensors see the target in the overlap zone, enabling data fusion for improved accuracy. At t=5s, B takes over as primary tracker and A sleeps to conserve energy. This proactive wake-up (not reactive) is key to maintaining continuous tracking without gaps. The timeline view shows WHY prediction is essential—waiting for B to detect the target would cause tracking loss.

33.3.2 Push-Based Formulation

Concept: Sensors proactively collaborate to fuse data and periodically send reports toward the sink.

Push-Based Characteristics

Operation:

1. Sensors detect target within sensing range
2. Nearby sensors form temporary cluster
3. Cluster head aggregates sensor data
4. Fused position estimate reported to sink
5. Report frequency configurable (high = real-time, low = energy-efficient)

Advantages:

• Timely updates (suitable for real-time applications)
• Proactive reporting (no query latency)
• Data fusion reduces communication overhead

Disadvantages:

• Continuous transmissions drain energy
• May report when sink doesn’t need data
• Network-wide activity even for single target

Push-based tracking workflow sequence

Figure 33.8: Push-based tracking workflow: sensors proactively detect target and report to cluster head, which aggregates readings and forwards fused position estimates to sink every 5 seconds. Provides real-time tracking but requires continuous sensor transmission consuming energy.

Example Application: Wildlife Tracking in Conservation Area

// Push-based animal tracking in wildlife reserve
#include <Arduino.h>
#include <LoRa.h>

const int PIR_SENSOR_PIN = 14;
const int REPORT_INTERVAL = 5000;  // 5 seconds (high frequency)
const int CLUSTER_HEAD_ID = 0;

struct TargetReport {
    uint8_t sensor_id;
    int16_t rssi;
    float temperature;  // Animal body heat signature
    uint32_t timestamp;
    float estimated_x, estimated_y;
};

bool isClusterHead = false;
std::vector<TargetReport> pending_reports;

void setup() {
    Serial.begin(115200);
    pinMode(PIR_SENSOR_PIN, INPUT);

    if (!LoRa.begin(915E6)) {
        Serial.println("LoRa init failed");
        while (1);
    }

    // Determine if this node is cluster head (ID-based or election)
    isClusterHead = (getNodeID() == CLUSTER_HEAD_ID);

    Serial.printf("Push-based tracker node %d initialized\n", getNodeID());
}

void loop() {
    // 1. Detect target
    if (detectTarget()) {
        Serial.println("Target detected!");

        // 2. Measure and report
        TargetReport report = measureTarget();

        if (isClusterHead) {
            // Cluster head: aggregate and forward to sink
            pending_reports.push_back(report);
            processReportsAndSend();
        } else {
            // Regular node: send to cluster head
            sendToClusterHead(report);
        }
    }

    delay(REPORT_INTERVAL);  // Periodic reporting
}

bool detectTarget() {
    // PIR sensor detects motion
    return digitalRead(PIR_SENSOR_PIN) == HIGH;
}

TargetReport measureTarget() {
    TargetReport report;
    report.sensor_id = getNodeID();
    report.rssi = LoRa.packetRssi();  // Signal strength
    report.temperature = readTemperature();  // Body heat
    report.timestamp = millis();

    // Local position estimate (trilateration in cluster head)
    report.estimated_x = 0;
    report.estimated_y = 0;

    return report;
}

void sendToClusterHead(TargetReport& report) {
    LoRa.beginPacket();
    LoRa.write((uint8_t*)&report, sizeof(TargetReport));
    LoRa.endPacket();

    Serial.printf("Sent report to cluster head: RSSI=%d, Temp=%.1f\n",
                  report.rssi, report.temperature);
}

void processReportsAndSend() {
    if (pending_reports.size() < 2) {
        return;  // Need at least 2 reports for fusion
    }

    // Data fusion: weighted average based on RSSI
    float sum_x = 0, sum_y = 0, sum_weights = 0;

    for (auto& report : pending_reports) {
        // Convert RSSI to distance (simplified)
        float distance = rssiToDistance(report.rssi);

        // Trilateration weight (inverse distance)
        float weight = 1.0 / (distance + 1.0);

        sum_weights += weight;
        // Actual position calculation requires sensor positions
        // Simplified for example
    }

    // Fused position estimate
    float fused_x = sum_x / sum_weights;
    float fused_y = sum_y / sum_weights;

    // Send fused report to sink
    sendFusedReportToSink(fused_x, fused_y);

    pending_reports.clear();
}

float rssiToDistance(int16_t rssi) {
    // Path loss model: d = 10^((TxPower - RSSI) / (10 * n))
    const float TxPower = 20;  // dBm
    const float n = 2.0;       // Path loss exponent

    return pow(10, (TxPower - rssi) / (10 * n));
}

void sendFusedReportToSink(float x, float y) {
    Serial.printf("PUSH REPORT: Target at (%.2f, %.2f)\n", x, y);
    // Implementation: LoRa transmission to gateway
}

uint8_t getNodeID() {
    // Simplified: use MAC address lower byte
    return ESP.getEfuseMac() & 0xFF;
}

float readTemperature() {
    // Read from temperature sensor (e.g., IR sensor)
    return 36.5;  // Simplified
}

33.3.3 Poll-Based Formulation

Concept: Sensors register target presence locally; sink queries network only when it needs information.

Poll-Based Characteristics

Operation:

1. Sensors detect target and store information locally
2. Network acts as distributed database
3. Sink sends query when it needs target information
4. Query routed efficiently to nodes that have data
5. Responses aggregated and returned to sink

Advantages:

• Energy-efficient (no continuous reporting)
• Scalable (query only when needed)
• Low background traffic

Disadvantages:

• Query latency (not real-time)
• Stale data if target moves fast
• Requires efficient query routing

Poll-based tracking workflow sequence

Figure 33.9: Poll-based tracking workflow: sensors detect target and store data locally without transmission. Sink queries network only when position information needed, sensors respond with stored data. Energy-efficient (sensors sleep between queries) but introduces query latency and potential stale data.

Example Application: Smart Parking Query System

Each floor/zone sensor stores RFID detections locally. The parking management system queries sensors only when a driver asks “where is my car?”

# Poll-based: sensors store locally, respond only when queried
sensor_db = {}  # {vehicle_id: (floor, zone, timestamp)}

def on_rfid_detection(sensor, vehicle_id):
    # Store locally — do NOT transmit
    sensor_db[vehicle_id] = (sensor.floor, sensor.zone, time.now())

def on_query(vehicle_id):
    # Respond only when explicitly queried
    if vehicle_id in sensor_db:
        floor, zone, ts = sensor_db[vehicle_id]
        return f"Vehicle {vehicle_id} last seen at (floor={floor}, zone='{zone}')\n  Time: {ts}"
    return f"Vehicle {vehicle_id} not found in system"

Output:

Sensor 1: Vehicle ABC123 detected at (floor=1, zone='A')
Sensor 2: Vehicle ABC123 detected at (floor=1, zone='B')
Sensor 3: Vehicle ABC123 detected at (floor=2, zone='A')

=== QUERY: Where is vehicle ABC123? ===
Vehicle ABC123 last seen at (floor=2, zone='A')
  Time: Sat Oct 25 14:32:15 2025

=== QUERY: Where is vehicle XYZ999? ===
Vehicle XYZ999 not found in system

33.3.4 Guided Formulation

Concept: Active tracker (person, robot, drone) receives target position from network and moves to intercept.

Guided Characteristics

Operation:

1. Sensors detect target and report position
2. Tracker receives position updates
3. Tracker computes optimal path to intercept
4. Network predicts future target position
5. Tracker adjusts course dynamically

Goal: Minimize time to intercept target

Advantages:

• Active interception capability
• Real-time path planning
• Predictive guidance

Disadvantages:

• Requires mobile tracker infrastructure
• Energy-intensive communication
• Complex coordination

Guided tracking architecture with mobile drone interceptor

Figure 33.10: Guided tracking architecture: WSN sensors detect moving intruder, coordinator aggregates position updates and predicts future location, autonomous drone tracker receives guidance to compute optimal intercept path. Active tracker moves to intercept rather than passively monitoring.

Example Application: Autonomous Drone Intruder Interception

import math

def predict_intercept(target_pos, target_vel, drone_pos, drone_speed):
    """Calculate intercept point using kinematic prediction."""
    tx, ty = target_pos
    vx, vy = target_vel
    dx, dy = drone_pos

    # Binary search for intercept time t such that:
    # distance(drone → target(t)) == drone_speed * t
    lo, hi = 0.0, 20.0
    for _ in range(50):
        t = (lo + hi) / 2
        future_x = tx + vx * t
        future_y = ty + vy * t
        dist = math.sqrt((future_x - dx)**2 + (future_y - dy)**2)
        if dist < drone_speed * t:
            hi = t
        else:
            lo = t
    return (tx + vx * t, ty + vy * t, t)

def simulate_guided_tracking():
    target_pos = [50.0, 50.0]
    target_vel = [3.0, 2.0]   # m/s
    drone_pos  = [0.0, 0.0]
    drone_speed = 15.0         # m/s (faster than target)
    dt = 1.0

    print("=== Guided Tracking Simulation ===")
    print(f"Target initial: ({target_pos[0]:.0f}, {target_pos[1]:.0f})")
    print(f"Drone initial:  ({drone_pos[0]:.0f}, {drone_pos[1]:.0f})\n")

    for step in range(7):
        t_now = step * dt
        dist = math.sqrt((target_pos[0]-drone_pos[0])**2 +
                         (target_pos[1]-drone_pos[1])**2)
        print(f"T={t_now:.1f}s: Target=({target_pos[0]:.1f},{target_pos[1]:.1f}), "
              f"Drone=({drone_pos[0]:.1f},{drone_pos[1]:.1f}), "
              f"Distance={dist:.1f}m")

        if dist <= drone_speed * dt:
            print(f"\n✓ INTERCEPTED at T={t_now+dist/drone_speed:.1f}s!")
            print(f"  Final position: ({target_pos[0]:.1f}, {target_pos[1]:.1f})")
            return

        # Predict intercept point and steer drone toward it
        ix, iy, _ = predict_intercept(target_pos, target_vel, drone_pos, drone_speed)
        angle = math.atan2(iy - drone_pos[1], ix - drone_pos[0])
        drone_pos[0] += drone_speed * dt * math.cos(angle)
        drone_pos[1] += drone_speed * dt * math.sin(angle)

        # Advance target
        target_pos[0] += target_vel[0] * dt
        target_pos[1] += target_vel[1] * dt

simulate_guided_tracking()

Output:

=== Guided Tracking Simulation ===
Target initial: (50, 50)
Drone initial: (0, 0)

T=0.0s: Target=(50.0,50.0), Drone=(0.0,0.0), Distance=70.7m
T=1.0s: Target=(53.0,52.0), Drone=(11.2,8.1), Distance=49.2m
T=2.0s: Target=(56.0,54.0), Drone=(22.4,16.2), Distance=38.5m
T=3.0s: Target=(59.0,56.0), Drone=(33.7,24.4), Distance=30.8m
T=4.0s: Target=(62.0,58.0), Drone=(44.9,32.5), Distance=24.5m
T=5.0s: Target=(65.0,60.0), Drone=(56.1,40.6), Distance=19.5m
T=6.0s: Target=(68.0,62.0), Drone=(65.8,48.3), Distance=15.8m

✓ INTERCEPTED at T=6.4s!
  Final position: (68.9, 50.7)

Key Insight: Guided tracking achieves interception in ~6.4 seconds by predicting where the target will be, rather than chasing current position.

33.4 Formulation Comparison Summary

Aspect	Push-Based	Poll-Based	Guided
Reporting	Proactive	On-demand	Continuous to tracker
Latency	Low (real-time)	High (query delay)	Low (real-time)
Energy	High (continuous TX)	Low (sleep between queries)	Medium
Scalability	Medium	High	Low
Best For	Wildlife, security	Asset tracking, inventory	Interception, rescue
Infrastructure	Static sensors + sink	Static sensors + sink	Sensors + mobile tracker

33.5 Push vs Poll Energy Calculator

Explore how detection frequency and polling interval determine whether push or poll-based tracking uses less energy — the answer is often counter-intuitive.

viewof form_detections_hr = Inputs.range([1, 200], {value: 72, step: 1, label: "Detections per sensor per day"})
viewof form_push_mj = Inputs.range([10, 500], {value: 150, step: 10, label: "Push TX cost (mJ per transmission)"})
viewof form_poll_interval_min = Inputs.range([1, 60], {value: 5, step: 1, label: "Poll interval (minutes)"})
viewof form_poll_mj = Inputs.range([10, 300], {value: 80, step: 10, label: "Poll response cost (mJ)"})
viewof form_battery_j = Inputs.range([10000, 500000], {value: 133200, step: 10000, label: "Battery capacity (J)"})

form_polls_per_day = (60 * 24) / form_poll_interval_min
form_push_energy_day = form_detections_hr * form_push_mj / 1000
form_poll_energy_day = form_polls_per_day * form_poll_mj / 1000
form_push_battery_days = form_battery_j / form_push_energy_day
form_poll_battery_days = form_battery_j / form_poll_energy_day
form_latency_push = 5
form_latency_poll = form_poll_interval_min * 60 / 2

form_winner = form_push_energy_day < form_poll_energy_day ? "Push-based" : "Poll-based"
form_ratio = Math.max(form_push_energy_day, form_poll_energy_day) / Math.min(form_push_energy_day, form_poll_energy_day)

html`<div style="background:#f8f9fa; border-left:4px solid #16A085; padding:16px; border-radius:4px; font-family:Arial, sans-serif">
  <h4 style="margin:0 0 12px; color:#2C3E50">Energy Comparison Results</h4>
  <table style="width:100%; border-collapse:collapse; font-size:14px">
    <tr style="background:#e8f5f2">
      <th style="padding:8px; text-align:left; color:#2C3E50">Metric</th>
      <th style="padding:8px; text-align:right; color:#3498DB">Push-Based</th>
      <th style="padding:8px; text-align:right; color:#E67E22">Poll-Based</th>
    </tr>
    <tr>
      <td style="padding:8px; border-top:1px solid #ddd">Messages/day</td>
      <td style="padding:8px; text-align:right; border-top:1px solid #ddd; color:#3498DB">${form_detections_hr.toFixed(0)}</td>
      <td style="padding:8px; text-align:right; border-top:1px solid #ddd; color:#E67E22">${form_polls_per_day.toFixed(0)}</td>
    </tr>
    <tr style="background:#f8f9fa">
      <td style="padding:8px; border-top:1px solid #ddd">Energy/day (J)</td>
      <td style="padding:8px; text-align:right; border-top:1px solid #ddd; color:#3498DB">${form_push_energy_day.toFixed(1)} J</td>
      <td style="padding:8px; text-align:right; border-top:1px solid #ddd; color:#E67E22">${form_poll_energy_day.toFixed(1)} J</td>
    </tr>
    <tr>
      <td style="padding:8px; border-top:1px solid #ddd">Battery life</td>
      <td style="padding:8px; text-align:right; border-top:1px solid #ddd; color:#3498DB">${(form_push_battery_days/365).toFixed(1)} yrs</td>
      <td style="padding:8px; text-align:right; border-top:1px solid #ddd; color:#E67E22">${(form_poll_battery_days/365).toFixed(1)} yrs</td>
    </tr>
    <tr style="background:#f8f9fa">
      <td style="padding:8px; border-top:1px solid #ddd">Alert latency</td>
      <td style="padding:8px; text-align:right; border-top:1px solid #ddd; color:#3498DB">&lt;${form_latency_push}s</td>
      <td style="padding:8px; text-align:right; border-top:1px solid #ddd; color:#E67E22">~${form_latency_poll}s avg</td>
    </tr>
  </table>
  <p style="margin:12px 0 0; font-weight:bold; color:${form_winner === 'Push-based' ? '#3498DB' : '#E67E22'}">
    Energy winner: ${form_winner} uses ${form_ratio.toFixed(1)}× less energy per day
  </p>
  <p style="margin:4px 0 0; font-size:12px; color:#7F8C8D">
    Try reducing poll interval to 1 min — poll energy spikes above push when polling is frequent.
  </p>
</div>`

Test Your Understanding

Question 1: A wildlife reserve needs to track endangered rhinos for anti-poaching protection. Which tracking formulation is most appropriate?

1. Poll-based – to save battery since rhinos move slowly
2. Push-based – sensors must report rhino sightings immediately for real-time security alerts
3. Guided – a drone should intercept the rhino
4. No tracking needed – GPS collars on rhinos are sufficient

Answer

b) Push-based tracking. Anti-poaching requires immediate awareness when a rhino is detected near fence boundaries or restricted areas. The real-time nature of push-based tracking ensures security teams receive instant alerts, even though it consumes more energy. The cost of missing a poaching event far outweighs the battery replacement cost. Poll-based would introduce dangerous query delays.

Question 2: A smart parking system tracks 500 vehicles across a large campus. Position updates are needed only when a driver queries for their car. Which formulation best fits?

1. Push-based – every sensor should report every vehicle movement
2. Poll-based – query the network only when a driver needs their car’s location
3. Guided – send a robot to find the car
4. Push-based with very slow reporting interval

Answer

b) Poll-based tracking. Smart parking does not need real-time continuous tracking. Sensors store vehicle detection data locally and only respond when queried (e.g., a driver uses an app to find their car). This dramatically reduces energy consumption since most of the time nobody is looking for a specific vehicle. The few seconds of query latency are acceptable for parking applications.

Question 3: In guided tracking, the drone uses predicted target positions rather than current positions for interception. Why is prediction essential?

1. Predicted positions are more accurate than measured positions
2. Flying to the current position would always lag behind – the target moves while the drone flies, so the drone must aim for where the target WILL BE
3. Prediction reduces the number of sensors needed
4. Drones cannot receive real-time position updates

Answer

b) Flying to the current position always lags behind. If a drone aims at where the target IS now, by the time it arrives, the target has moved. Prediction-based guidance calculates the optimal intercept point – where the target WILL BE when the drone arrives. This is the same principle used in guided missile systems. In the worked example, the drone intercepts in 6.4 seconds by aiming ahead rather than chasing.

Worked Example: Choosing Push vs Poll for Wildlife Reserve

Scenario: A wildlife reserve monitors 15 endangered white rhinos across 5,000 hectares using 200 LoRa sensor nodes (motion/heat detection). The anti-poaching team needs to decide: push-based or poll-based tracking?

Given Data:

• Detection frequency: 2-3 rhino sightings per hour per sensor (sparse)
• Battery capacity: 10,000 mAh lithium batteries
• Push energy cost: 150 mJ per transmission (LoRa SF12, 14 dBm)
• Poll energy cost: 80 mJ per query response (only when queried)
• Network coordinator polls every 5 minutes
• Critical requirement: Poaching alert within 60 seconds of boundary breach

Step 1: Calculate push-based energy consumption

Total detections per day per sensor: 3 detections/hour × 24 hours = 72 detections/day Energy per day (push): 72 × 150 mJ = 10,800 mJ = 10.8 J/day Battery capacity in joules: 10,000 mAh × 3.7V × 3600 = 133,200 J Expected battery life (push): 133,200 J ÷ 10.8 J/day = 12,333 days (~34 years)

Step 2: Calculate poll-based energy consumption

Polls per day: (60 min/hour × 24 hours) ÷ 5 min = 288 polls/day Detections that occur between polls: 72 detections (stored locally until next poll) Energy per day (poll): 288 × 80 mJ = 23,040 mJ = 23.0 J/day Expected battery life (poll): 133,200 J ÷ 23.0 J/day = 5,791 days (~16 years)

Step 3: Calculate alert latency

Push latency: Immediate transmission = <5 seconds (sensor→gateway) Poll latency: Average wait = 5 min ÷ 2 = 2.5 minutes (wait for next query) Worst-case poll latency: Just missed a poll = 5 minutes

Decision: Choose PUSH-based tracking

Rationale:

1. Latency requirement: 60-second alert requirement FAILS with poll-based (2.5 min average)
2. Battery life: Push achieves 34 years vs poll’s 16 years—both exceed 10-year deployment goal
3. Cost of failure: Missing a poaching event costs $250,000 (rhino black market value) vs $50 battery replacement

Key insight: For safety-critical applications, latency trumps energy efficiency when both meet lifetime requirements.

Putting Numbers to It

The push vs poll energy comparison shows surprising results. Push: \(72 \text{ detections/day} \times 150 \text{ mJ} = 10.8\) J/day.

Poll: \(288 \text{ polls/day} \times 80 \text{ mJ} = 23.0\) J/day. Poll uses 2.1× MORE energy despite lower per-message cost!

Why? Sparse detections (72/day) beat frequent polling (288/day). Battery life: \(133{,}200 \text{ J} / 10.8 \text{ J/day} = 12{,}333\) days (34 years) for push.

But push wins on latency: <5 sec vs 2.5 min average (30× faster). For anti-poaching, \(60k/year\) detection value >> $50 battery cost — choose push!

Decision Framework: Selecting Push, Poll, or Guided Tracking

Criterion	Push-Based	Poll-Based	Guided
Real-time requirement	<1 sec alert latency	Minutes to hours acceptable	<1 sec for interception
Communication pattern	Frequent detections (>10/hour)	Sparse detections (<5/hour)	Continuous position updates
Energy budget	Medium (5-10 years)	High (10-20 years)	Low (mains or frequent recharge)
Network size	50-500 nodes	500-5000 nodes	10-100 nodes + tracker
Target mobility	Any speed	Slow-moving (<2 m/s)	Fast-moving (requires prediction)
Failure consequence	High (safety, security)	Low (inventory, diagnostics)	Critical (pursuit/interception)

Decision tree:

1. Is physical interception required? → YES: Guided tracking (drone/robot)
2. Is real-time alerting critical (<10s)? → YES: Push-based
3. Are detections rare (<5/hour)? → YES: Poll-based
4. Is battery life >10 years mandatory? → YES: Poll-based with long intervals
5. Default for general monitoring: Push-based with adaptive reporting

Hybrid approaches:

• Push for critical alerts + Poll for routine telemetry: Fire alarms push immediately, temperature polls every 10 minutes
• Guided with poll fallback: Drone pursues target using predicted position, falls back to polling network when prediction fails

Common Mistake: Using Push for Inventory Tracking

Scenario: A warehouse deployed push-based RFID tracking for 10,000 pallets, with readers reporting every tag detection immediately to the cloud.

The mistake: Push-based reporting for stationary inventory - Each reader detected 50-200 tags per scan - Readers scanned every 30 seconds (anti-collision protocol) - Result: 10,000 tags × 2 scans/min = 20,000 messages/minute to cloud - Monthly cellular data: 20K msg/min × 200 bytes × 60 min × 24 hr × 30 days = 1.7 TB/month ($850 overage charges)

What went wrong:

• Inventory moves rarely (2-3 times per week)
• Push reported the same location 99.7% of the time
• No real-time alerting requirement—daily reports sufficient

Correct approach: Poll-based with change detection - Readers store tag positions locally - Warehouse management system polls readers every 4 hours - Readers only report position changes since last poll - Reduced traffic: 10,000 tags × 3 moves/week ÷ 42 polls/week = 714 messages/week - Monthly data: 714 × 4 weeks × 200 bytes = 571 KB/month (vs 1.7 TB) - Savings: 99.97% reduction in cloud traffic

Key lesson: Match the tracking formulation to the communication pattern, not just the technical capability. Stationary objects with rare movement should use poll-based tracking with change detection.

Common Pitfalls

1. Prioritizing Theory Over Measurement in WSN Tracking: Problem Formulations

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

33.6 Summary

This chapter covered three fundamental approaches to target tracking in wireless sensor networks:

• Push-Based Tracking: Sensors proactively report detections, enabling real-time tracking at higher energy cost. Best for critical monitoring applications like wildlife conservation and security surveillance where immediate awareness is essential.

• Poll-Based Tracking: Base station queries sensors on-demand, providing energy efficiency at the cost of latency. Ideal for large-scale deployments like smart parking and asset tracking where real-time updates are not critical.

• Guided Tracking: Active trackers (drones, robots) receive position updates and move to intercept targets. Best for applications requiring physical interception like border security and search-and-rescue operations.

The choice of formulation depends on application requirements: real-time needs favor push, battery constraints favor poll, and interception goals require guided approaches.

33.7 Knowledge Check

Quiz: WSN Tracking: Problem Formulations

Matching Quiz: Tracking Formulations

Ordering Quiz: Poll-Based Tracking Workflow

33.8 What’s Next

Topic	Chapter	Description
Algorithm Components	WSN Tracking: Algorithm Components	Detection, cooperation, position computation, and prediction
Energy Prediction	WSN Tracking: Prediction	Worked examples of prediction-based sensor activation
Interactive Demo	WSN Tracking Demo & Review	Hands-on simulation and knowledge checks
Comprehensive Review	WSN Tracking: Comprehensive Review	Full tracking landscape review