484  Sensor Behaviors: Knowledge Checks and Quiz

484.1 Learning Objectives

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

  • Test Node Classification Skills: Accurately identify failed, badly failed, dumb, selfish, and malicious nodes from described behaviors
  • Apply Diagnostic Reasoning: Use systematic decision trees to classify observed sensor node anomalies
  • Evaluate Trade-offs: Understand the energy-latency-reliability trade-offs in WSN design decisions
  • Analyze Reputation Systems: Identify vulnerabilities and countermeasures in trust management systems
  • Compare Protocol Layers: Distinguish MAC layer vs routing layer responsibilities for energy management
  • Assess Social Sensing Applicability: Determine when social media integration benefits WSN duty cycle management
WarningPrerequisites

Before attempting these knowledge checks, you should have studied:

What is this chapter? A collection of self-assessment questions to test and reinforce your understanding of sensor node behaviors and WSN design principles.

How to approach the questions: 1. Read each scenario carefully before looking at answer choices 2. Think through your reasoning before checking the answer 3. Review explanations even for questions you answered correctly 4. Note any concepts that surprised you for further study

Types of questions: - Understanding Checks: Open-ended scenarios requiring analysis - Auto-Gradable MCQs: Multiple choice with immediate feedback - Interactive Quiz: Detailed questions with comprehensive explanations

Recommended approach: 1. Complete all Understanding Checks first 2. Take the Auto-Gradable Quick Check 3. Work through Interactive Quiz questions 4. Review any topics where you struggled

484.2 Knowledge Check: Understanding Checks

Test your understanding of sensor node behaviors and WSN design principles with these scenario-based questions.

Scenario: You’re managing an industrial warehouse monitoring system with 100 WSN nodes deployed 6 months ago. During routine diagnostics, you observe:

  • 15 nodes show battery levels below 10% (threshold: 15%)
  • 8 nodes consistently drop packets they should forward (confirmed via neighbor monitoring)
  • 3 nodes send temperature readings that differ by 15 degrees C from redundant nearby sensors

Think about: 1. How should you classify each group of misbehaving nodes (failed, badly failed, dumb, selfish, or malicious)? 2. What mitigation strategy is appropriate for each classification? 3. Why does correct classification matter for network maintenance?

Key Insight: Classification determines remediation: 15 battery-critical nodes (near failure - schedule battery replacement/recharge), 8 selfish nodes (functional hardware but refusing cooperation to save energy - needs incentive mechanisms or reputation systems), 3 badly failed nodes (sensor fault/calibration drift - recalibrate or replace sensing element; escalate to security only if you see corroborating evidence like coordinated patterns). Misclassification wastes resources: treating selfish nodes as failed means unnecessary hardware replacement costs; treating sensor faults as attacks triggers needless incident response; treating attacks as sensor faults delays security response.

Scenario: You’re deploying a forest fire detection WSN across 500 hectares. Design requirements:

  • Normal operation: 1% duty cycle (99% sleep to achieve 5-year battery life)
  • Fire detection: Must alert rangers within 2 seconds of smoke detection
  • Multi-hop network: Average 6 hops from detection point to base station

Think about: 1. What is the fundamental conflict between 99% sleep duty cycle and 2-second alert latency? 2. How can sleeping nodes relay urgent fire alerts if they’re asleep when packets arrive? 3. What architectural solutions enable both low power and fast emergency response?

Key Insight: The sleep-latency paradox: 1% duty cycle means nodes sleep approximately 59.4 minutes per hour, saving energy but creating routing gaps. Solution: Cascading wake-up architecture - detecting node broadcasts wake-up beacon before transmitting alert (200ms), woken neighbors relay beacon while forwarding alert, creating a progressive wave of awakened nodes. Commercial systems achieve less than 3 second end-to-end latency with very low duty cycles by using: staged wake-up protocols, redundant routing paths (increases awake-node probability), wake-up radios (ultra-low-power receivers for urgent interrupts), and energy harvesting for emergency bursts. Real deployment (FireWatch California): 2.1s average alert latency, 5.2-year median battery life, 0.3% false positive rate.

Scenario: Your agricultural IoT deployment shows premature battery drain in certain nodes. Energy analysis reveals:

  • Nodes near gateway (3-4 hops) deplete batteries in 8 months (expected: 24 months)
  • Network-wide: 65% energy consumed during idle listening, 25% in transmission, 10% sensing
  • Packet collision rate: 18% during peak irrigation control periods

Think about: 1. Which protocol layer (MAC or Routing) is responsible for each energy waste source? 2. How do MAC protocol decisions affect idle listening energy consumption? 3. How do routing protocol decisions affect energy distribution across nodes?

Key Insight: MAC (Layer 2) controls idle listening waste (65% of energy): Duty-cycle MACs (S-MAC, B-MAC) put radios to sleep between transmissions, reducing idle listening from continuous to less than 5%. TDMA MACs (Z-MAC) eliminate collisions via time slots, saving 18% collision waste. Routing (Layer 3) controls energy distribution: Poor routing creates hotspots (gateway-adjacent nodes forward all traffic, dying first), while energy-aware routing (RPL with ETX metric) distributes forwarding load. For your scenario: Implement duty-cycle MAC (reduce 65% to less than 5% idle = 60% savings) + multipath routing (distribute hotspot load across alternate parents = extends hotspot node life 3-5x). Combined: Expected battery life increases from 8 months to 24+ months for critical nodes.

484.3 Auto-Gradable Quick Check

Test your knowledge with these multiple-choice questions that provide immediate feedback.

Question 1: A WSN node reliably sends its own sensor readings but drops a large fraction of packets it is supposed to forward for neighbors. What behavior best fits?

Explanation: B. Selfish nodes are functional but strategically uncooperative, often to conserve energy. The key indicator is that the node successfully sends its OWN data (proving the radio works) but drops OTHERS’ packets (indicating intentional non-cooperation rather than hardware failure).

Question 2: A node communicates normally but its temperature readings are consistently approximately 15 degrees C away from redundant nearby sensors. With no other evidence of an attack, the most likely classification is:

Explanation: C. A sensing fault or calibration drift can corrupt measurements while the radio stack still works. “Badly failed” describes nodes that transmit corrupted data. Failed nodes cannot communicate at all, dumb nodes have communication problems (not sensing problems), and the readings clearly indicate abnormal operation.

Question 3: In the “MAC vs Routing energy impact” scenario, which layer most directly controls idle listening energy consumption?

Explanation: B. Duty cycling, channel access, and listen/sleep schedules are MAC layer responsibilities. The MAC layer determines when the radio is on vs sleeping, directly controlling idle listening energy. Routing determines which path packets take but not when nodes listen for packets.

Question 4: Which change most directly reduces collisions during peak control periods in a contention-heavy WSN?

Explanation: A. Scheduling reduces simultaneous contention, cutting collisions and retransmissions (especially during synchronized bursts). TDMA assigns time slots to each node, preventing overlapping transmissions. Increasing sampling rate would increase traffic and collisions. Larger payloads don’t reduce collision probability. Disabling ACKs reduces reliability without addressing the collision root cause.

484.4 Interactive Quiz

Time: ~15 min | Difficulty: Intermediate | Code: P05.C19.U02

Work through these detailed questions to deepen your understanding of sensor node behaviors and WSN design decisions.

A sensor node in an agricultural IoT deployment can sense soil moisture accurately, but due to heavy rainfall, its radio communication range has dropped from 100m to only 5m, making it unable to reach any neighbors. What type of node behavior is this?

A) Failed node B) Badly failed node C) Dumb node D) Malicious node

Answer

C) Dumb node

Explanation:

Dumb Node Characteristics: - Functional sensing: Yes (soil moisture sensor works correctly) - Communication failure: Yes (radio range reduced due to environmental factors) - Temporary condition: Yes (will recover when rain stops) - Environmental cause: Yes (heavy rainfall) - Hardware intact: Yes (no permanent damage)

Why not other options:

A) Failed node: Incorrect because sensor is functioning. Failed nodes cannot sense or communicate. This node can sense, just can’t transmit.

B) Badly failed node: Incorrect because node is not sending corrupted/erroneous data. It’s simply unable to communicate at all. Badly failed nodes transmit false information that can contaminate network data.

D) Malicious node: Incorrect because there’s no intentional attack. The node is a victim of environmental conditions, not an adversary deliberately disrupting the network.

Key Distinguishing Factor:

The temporary, environment-induced nature of the communication failure specifically defines “dumb behavior.” Once the rain clears, radio performance will return to normal, and the node will resume normal operation - confirming this is dumb behavior, not permanent failure.

Real-World Parallel: Like a person who can hear but temporarily can’t speak due to laryngitis (temporary vocal cord inflammation). They’re not broken, just temporarily unable to communicate, and will recover when the condition resolves.

How can you distinguish between a selfish node and a malicious node in a WSN, given that both may drop packets?

A) Selfish nodes drop all packets; malicious nodes drop selectively B) Selfish nodes drop packets inconsistently based on personal cost; malicious nodes actively attack with pattern C) There’s no way to distinguish them D) Selfish nodes never forward; malicious nodes always forward

Answer

B) Selfish nodes drop packets inconsistently based on personal cost; malicious nodes actively attack with pattern

Explanation:

Selfish Node Behavior Pattern:

Forwarding Decision Tree for Selfish Node:
IF (my battery < 20%) THEN drop packet (save energy)
IF (relay costs > benefit) THEN drop packet
IF (packet is my own) THEN always send
IF (network monitoring active) THEN forward (avoid detection)
ELSE drop with some probability

Characteristics: - Motivation: Self-interest (energy conservation, resource preservation) - Behavior: Opportunistic dropping based on personal cost/benefit - Pattern: Inconsistent - forwards when forced (reputation threat), drops when safe - Example: Forwards packets when neighbors are watching (reputation), drops when no one monitoring

Malicious Node Behavior Pattern:

Attack Strategy for Malicious Node:
GOAL: Maximize network disruption
IF (route critical) THEN drop (black hole attack)
IF (packet important) THEN drop/modify
IF (detection risk high) THEN behave normally temporarily
ELSE execute attack

Characteristics: - Motivation: Network disruption, sabotage - Behavior: Strategic, goal-oriented attacks - Pattern: Consistent attack strategy, may have phases (normal to attack to normal) - Example: Drops all packets from specific source (targeted attack), or drops packets to specific destination (selective black hole)

Key Differences:

Aspect Selfish Node Malicious Node
Motivation Self-interest Network attack
Packet dropping Based on personal cost Strategic disruption
Own packets Always sends May send (to blend in)
Consistency Inconsistent (opportunistic) Consistent (strategy)
Detection Responds to reputation May evade strategically
Cooperation Cooperates when forced Never truly cooperative
Battery impact Extends own lifetime Indifferent to own lifetime

Detection Strategy:

  1. Monitor forwarding rate over time
    • Selfish: Variable (depends on battery, monitoring)
    • Malicious: Consistent with attack pattern
  2. Test with incentives
    • Selfish: Responds to rewards (credits, reputation)
    • Malicious: Ignores incentives
  3. Observe own packet handling
    • Selfish: Always forwards own packets
    • Malicious: Consistent with attack goal

Why other options wrong:

A) Incorrect - Both can drop selectively. Selfish nodes don’t necessarily drop all packets (just when costly). Malicious nodes may drop selectively (selective black hole).

C) Incorrect - They CAN be distinguished through behavioral analysis over time.

D) Incorrect - Neither “never” nor “always” apply. Both exhibit conditional forwarding behavior.

In an InTSeM-managed WSN monitoring room temperature, which scenario would result in the most transmission reduction?

A) Highly variable temperature (frequent changes) B) Stable temperature (rarely changes) C) Periodic temperature oscillation (predictable pattern) D) InTSeM provides equal reduction in all scenarios

Answer

B) Stable temperature (rarely changes)

Explanation:

Recall InTSeM transmits only when information content is high:

Information(x) = -log2(P(x))

High probability reading leads to low information leads to skipped transmission.

Scenario Analysis:

Scenario A: Highly Variable Temperature

Time Temp Probability Information Transmit?
0 25C 0.08 3.64 bits YES
1 28C 0.07 3.84 bits YES
2 22C 0.09 3.47 bits YES
3 30C 0.05 4.32 bits YES
4 24C 0.08 3.64 bits YES

Transmission Rate: approximately 100% (all readings are surprising/high-information)

Why: Every reading is unexpected, so all have high information content. InTSeM transmits nearly everything.

Scenario B: Stable Temperature

Time Temp Probability Information Transmit?
0 25.0C 0.10 3.32 bits YES (initial)
1 25.1C 0.85 0.23 bits NO (predictable)
2 25.0C 0.90 0.15 bits NO (very predictable)
3 25.0C 0.95 0.07 bits NO (extremely predictable)
4 25.1C 0.90 0.15 bits NO (still predictable)

Transmission Rate: approximately 10% (only initial readings + rare anomalies)

Why: After initial learning, temperature stays constant. Most readings have very high probability (P approximately 0.9), resulting in very low information content (I approximately 0.1 bits). InTSeM skips approximately 90% of transmissions.

Scenario C: Periodic Oscillation

Time Temp Pattern Probability Information Transmit?
0 20C Morning 0.80 0.32 bits NO
1 25C Noon 0.85 0.23 bits NO
2 20C Evening 0.80 0.32 bits NO
3 25C Noon next 0.85 0.23 bits NO

Transmission Rate: approximately 30% (periodic pattern becomes predictable)

Why: Oscillation is periodic and thus predictable. InTSeM learns the pattern (20C morning, 25C noon). Still transmits occasionally to confirm pattern continues, but skips most redundant readings.

Quantitative Comparison:

Scenario Transmissions Reduction
Variable 87/100 13.0%
Stable 12/120 90.0%
Periodic 35/120 70.8%

Key Insight:

InTSeM is most effective when data is predictable (high probability). Stable scenarios have highest predictability, thus highest transmission reduction.

Real-World Application: - Indoor temperature monitoring: approximately 80-90% reduction (stable) - Outdoor weather station: approximately 20-30% reduction (variable) - HVAC cycle monitoring: approximately 60-70% reduction (periodic)

Social sensing for duty cycle management works best for which type of events?

A) Continuous processes (temperature gradients) B) Rare events with social media discussion (protests, concerts) C) Microscopic phenomena (chemical reactions) D) Random unpredictable events

Answer

B) Rare events with social media discussion (protests, concerts)

Explanation:

Social sensing leverages social media activity to predict physical events. This requires: 1. Event must generate social media discussion 2. Social media activity precedes or correlates with physical event 3. Cost of continuous monitoring is high (benefits from duty cycle reduction)

Option B - Rare Events with Social Media Discussion (BEST):

Examples: - Protests/demonstrations: Widely discussed on Twitter, Facebook before occurring - Concerts/sports events: Announced in advance, attendees post - Traffic incidents: Real-time reports on Waze, Twitter - Natural disasters: Weather warnings, crowd observations

Why Social Sensing Works:

The system monitors social media for relevant keywords (hashtag protest hashtag downtown hashtag saturday), detects events through natural language processing, increases sensor duty cycle in relevant geographic zones before events occur, then returns to baseline after events conclude.

Advantages: - Early warning: Social media precedes physical event (hours to days) - Contextual awareness: Learn event type, location, expected size - Energy efficiency: Normal baseline duty cycle 99% of time - Scalability: Leverage millions of social media users

Option A - Continuous Processes (NOT SUITABLE):

Example: Temperature gradient in building

Why Social Sensing FAILS: - Temperature changes don’t generate social media posts - Continuous phenomena (not rare events) - No temporal correlation between social media and physical process - Can’t predict temperature from Twitter

Option C - Microscopic Phenomena (NOT SUITABLE):

Example: Chemical reactions in lab

Why Social Sensing FAILS: - Microscopic events invisible to humans - No public awareness leads to no social media discussion - Even if scientists tweet about experiments, timing doesn’t correlate with actual reactions - Lab processes not public events

Option D - Random Unpredictable Events (NOT SUITABLE):

Example: Lightning strikes

Why Social Sensing FAILS: - Unpredictable by definition - No advance social media warning - May generate posts after event, but that’s too late for duty cycle adjustment - Social media doesn’t predict random events

Quantitative Comparison:

Event Type Social Media Correlation Energy Savings Applicability
Protests (B) High (hours advance) 90-99% Excellent
Temperature (A) None 0% Not applicable
Chemical (C) None 0% Not applicable
Lightning (D) None (after-the-fact) 0% Not applicable

Real-World Success Story:

Project: Urban protest monitoring in major city - Baseline duty cycle: 1% (sensors sleep 99% of time) - Social media integration: Twitter API monitoring for protest keywords - Results: - 98% energy savings during normal times - 95% event detection rate (caught 95% of actual protests) - 6-hour advance warning on average - 0.1% false positive rate

Key Insight:

Social sensing is a niche technique for specific scenarios: - Rare events: Yes - Human-observable events: Yes - Events generating social media discussion: Yes - Events with lead time (hours to days): Yes - Continuous processes: No - Microscopic phenomena: No - Truly random events: No - Events without public awareness: No

A reputation-based system is deployed to detect selfish nodes. A clever selfish node learns the system’s threshold (reputation < 0.5 triggers exclusion) and always forwards just enough packets to maintain reputation = 0.6. What’s the best countermeasure?

A) Increase threshold to 0.8 B) Use adaptive threshold that’s unpredictable C) Combine reputation with energy consumption auditing D) Give up on reputation systems

Answer

C) Combine reputation with energy consumption auditing

Explanation:

The clever selfish node is gaming the system by maintaining just enough reputation to avoid exclusion while still dropping 40% of packets.

Why Each Option:

A) Increase Threshold to 0.8 (INEFFECTIVE):

Old threshold: 0.5, clever node maintains: 0.6 (safe)

New threshold: 0.8, clever node adjusts: maintains 0.9 (still gaming!)

Problem: Selfish node simply adjusts strategy: - Forward 90% instead of 60% - Still saves 10% energy vs fully cooperative (100%) - Arms race: Every threshold increase leads to selfish node adapts

Fundamental flaw: Threshold-based systems are gameable if threshold is known or discoverable.

B) Adaptive/Unpredictable Threshold (PARTIALLY EFFECTIVE):

The threshold changes randomly between 0.5 and 0.9. However, a smart selfish node can adopt a conservative strategy, assuming the threshold might be 0.9 and maintaining reputation at 0.95.

Partial effectiveness: - Prevents trivial gaming (fixed target) - But selfish node can adopt conservative strategy (maintain high reputation) - Still achieves energy savings vs fully cooperative

Better than A, but not optimal.

C) Combine Reputation + Energy Auditing (BEST):

Multi-Dimensional Detection:

Monitor three independent metrics: reputation (forwarding rate), energy consumption (power usage), and neighbor cross-validation (observed packet drops). Cross-validate to identify inconsistencies.

Why This Works:

Selfish node cannot fake both metrics simultaneously: - If it forwards packets to maintain reputation, energy consumption increases - If it drops packets to save energy, energy consumption reveals truth

Cross-validation catches gaming:

Forwarding Rate (Claimed) Energy Consumption Verdict
90% 55 mAh/hr Normal (consistent)
90% 35 mAh/hr Selfish (inconsistent)
50% 35 mAh/hr Honest but uncooperative

Key Insight:

Selfish node cannot fake both metrics simultaneously: - High forwarding + High energy = Honest cooperative node - High forwarding + Low energy = Selfish node gaming system (DETECTED) - Low forwarding + Low energy = Honest uncooperative node (apply incentives)

D) Give Up on Reputation (DEFEATIST):

Obviously wrong - reputation systems are valuable when properly designed. Don’t abandon effective tools; improve them!

Advanced Multi-Metric Approach:

Real-world deployments should monitor: 1. Forwarding rate (reputation) 2. Energy consumption (auditing) 3. End-to-end delivery rate (network performance) 4. Neighbor cross-validation (corroboration) 5. Temporal consistency (behavior over time)

Combining multiple metrics makes gaming exponentially harder.

Real-World Analogy:

Tax fraud detection: - Single metric: Income declared (easily faked) - Multi-metric: Income vs lifestyle vs spending vs assets - inconsistencies reveal fraud

Same principle applies to selfish node detection.

484.5 Summary

This chapter tested your understanding of sensor node behaviors through various question formats:

  • Node Classification Skills: Distinguishing between failed, badly failed, dumb, selfish, and malicious behaviors requires systematic analysis of sensing capability, communication status, data accuracy, and cooperation patterns.

  • Environmental vs Intentional Failures: Dumb nodes (environmental communication failure) differ fundamentally from failed nodes (hardware death) and selfish nodes (intentional non-cooperation) - correct diagnosis prevents costly misremediations.

  • Protocol Layer Responsibilities: MAC layer controls idle listening and collision management (65% of typical WSN energy), while routing layer controls traffic distribution and hotspot formation.

  • Information-Theoretic Efficiency: InTSeM achieves maximum transmission reduction (80-90%) in stable environments where readings are highly predictable, moderate reduction (60-70%) for periodic patterns, and minimal reduction for highly variable conditions.

  • Social Sensing Applicability: Social media integration benefits duty cycle management only for rare, human-observable, publicly-discussed events with advance notice - not continuous processes or random events.

  • Multi-Dimensional Trust Management: Single-metric reputation systems are gameable; combining forwarding reputation with energy consumption auditing creates cross-validation that catches clever selfish nodes.

484.6 What’s Next

Continue to the implementation chapter to see a complete Python reputation-based trust management system in action.

Continue to Sensor Behaviors: Trust Implementation ->

Application Context: - Mine Safety Monitoring - WSN application case study - Node Behavior Taxonomy - Detailed behavior definitions

Implementation: - Trust Implementation - Python reputation system code - Production and Review - Deployment strategies

Protocol Details: - MAC Protocols - Duty cycling and collision management - Routing Protocols - Energy-aware routing