5 Node Behaviour: Evidence and Taxonomy

5.1 Start With the Decision

This section: Start With the Decision — A quiet node may be asleep, out of power, cut off, or selfish.

A quiet node may be asleep, out of power, cut off, or selfish. One missing packet cannot pick the right label.

5.2 Route Overview

This section: Route Overview — This is part 1 of 2.

This is part 1 of 2. Continue with Node Behaviour: Contradictions and Review.

5.3 Part Objectives

This section: Part Objectives

• Classify node behaviour from link, power, clock, and route evidence.
• Use denominators when judging drops and forwarding.

5.4 Chapter Roadmap

This section: Chapter Roadmap

• Begin With One Node That Went Quiet
• Start With the Field Story
• In 60 Seconds
• Sensor Node Behavior Review
• Minimum Viable Understanding
• Prerequisites
• Classification Frame
• Behavior Labels
• Behavior Taxonomy
• Label-To-Action Guide
• Evidence Checks
• Node Behavior Patterns
• Dropped Packets Need Denominators
• Selfish Forwarding Evidence
• Classification Matrix
• Worked Review: Silent Temperature Node

5.5 Begin With One Node That Went Quiet

This section: Begin With One Node That Went Quiet — Picture a field sensor that misses three expected reports.

Picture a field sensor that misses three expected reports. It may be asleep, out of power, cut off by a weak link, full of old data, or acting against the route rule. The first choice is not a blame label. It is the evidence set needed to tell these cases apart.

Write the expected send plan and the last sound report. Check nearby nodes, link events, cell state, stored records, clock, and repair history. Count sent and received work with a clear total. Then state a temporary label and the action it allows. Try to disprove it with a direct visit, a new route, a wake event, or a later data return.

A quick label can help an operator act, but it can also hide a shared network fault. Waiting for perfect proof can avoid blame, but it may leave a service at risk. This first pass does not prove intent or root cause. For a node-behavior label, map labels to bounded actions and review records; check packet totals, selfish conduct, silent faults, and mixed evidence before accepting the result.

Use plain labels that lead to a safe check. “Silent” means no expected report was seen. “Faulty” needs bad sensing proof. “Selfish” needs sound proof that the node keeps its own work while refusing agreed relay work. “Harmful” needs still stronger evidence. Do not skip these steps.

Place each fact in a row. Add source, time, and total. Mark facts that clash. A low cell and a missed forward can both be true. So can a bad clock and a sound sensor. Mixed facts may need a mixed or open label.

Choose the smallest safe act. Ask again. Use another route. Hold one data stream. Visit the node. Do not block a whole group from one weak clue. Set a time to read the case again. A label is useful only while its evidence stays fresh.

5.6 Start With the Field Story

This section: Start With the Field Story — Imagine one node that still sends packets, but the packets no longer make sense.

Imagine one node that still sends packets, but the packets no longer make sense. Classification starts by separating silence, selfish forwarding, faulty readings, malicious behavior, and recovery state so the team knows whether to repair hardware, change routing, quarantine data, or investigate an attack.

5.7 In 60 Seconds

This section: In 60 Seconds — Sensor node behavior classification turns scattered symptoms into a reviewable decision.

Sensor node behavior classification turns scattered symptoms into a reviewable decision. A node can be healthy, silent, suspect, or actively misleading. The classification should be based on evidence that the system can observe: recent messages, plausible values, consistency with related nodes, role behavior, recovery state, and the effect on downstream decisions.

The most important distinction is between a node that is unavailable and a node that continues to send untrustworthy data. Silence is usually easier to detect. Misleading readings require validation checks, comparison evidence, and a clear action record.

5.8 Learning Objectives

This section: Learning Objectives

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

• Separate healthy, silent, suspect, and misleading node behavior.
• Classify a node from observable symptoms rather than assumptions.
• Choose evidence checks for message presence, value plausibility, consistency, and role behavior.
• Write a review record that states confidence, action, residual concern, and retest trigger.
• Avoid overreacting to a single weak signal when the evidence is incomplete.

5.9 Sensor Node Behavior Review

This section: Sensor Node Behavior Review

5.10 Minimum Viable Understanding

This section: Minimum Viable Understanding — Classification begins with observations, not guesses about root cause.

Classification begins with observations, not guesses about root cause. A silent node is unavailable; a misleading node is more dangerous because it can still affect decisions. Plausibility checks catch impossible readings, but consistency checks catch readings that are possible yet wrong for the current context. A classification is not complete until it names the evidence, confidence, action, and retest trigger.

5.11 Prerequisites

This section: Prerequisites

• Wireless Sensor Networks: network roles and sensor-node context.
• Duty-Cycling and Topology Management: how node schedules and topology roles affect what the monitor expects to see.
• WSN Sensor Nodes: sensor-node structure, power, and maintenance evidence.

5.12 Classification Frame

This section: Classification Frame — The next Classification Frame step depends on the sequence behind Classification Frame.

A node behavior label should answer three questions:

1. What did the monitor observe?
2. What does that evidence support?
3. What action is safe while uncertainty remains?

The next Classification Frame step depends on the sequence behind Classification Frame. Read Figure 5.1 first, focusing on Node Behavior Classification Path and What did the monitor observe?.

+

Figure Figure 5.1 traces a behavior label back to observations. Its soil-moisture example has six readings at 99%, while nearby probes sit near 45%. Message presence says the node is available, but the consistency check finds a conflict. Plausibility, assigned role, and recovery state still need checking before the team infers a cause. The figure therefore lowers confidence and suggests a suspect or misleading label for this decision. Down-weighting the reading protects the current result while a reference check or repeated sample tests it. The label can change when new evidence resolves the contradiction.

Use the label as a decision aid, not as a permanent identity. A node can move from suspect to healthy after a reference check, or from healthy to misleading after repeated contradictions appear.

Follow the evidence before choosing the label. A good classification says what was observed, what remains unknown, what action is safe, and what would make the team revisit the decision. That turns a messy trail — a missing message, a stale reading, a value that disagrees with nearby nodes, a relay that behaves differently from its role — into a bounded decision rather than a guess about intent.

5.13 Behavior Labels

This section: Behavior Labels — Use a small label set so the review stays consistent.

Use a small label set so the review stays consistent.

Healthy

The node sends expected messages, the readings are plausible for the context, related evidence agrees, and the node performs its assigned role.

Silent

The monitor no longer receives expected messages. The classification should record the last accepted message, expected schedule, affected data path, and action to cover the missing evidence.

Suspect

The node has weak or conflicting evidence. It may be late, noisy, inconsistent, or missing metadata. Suspect means “do not rely on this reading without more evidence,” not “remove the node from every decision.”

Misleading

The node continues to send data, but the data should not be trusted for the current decision. Evidence may include impossible values, repeated contradictions with nearby or related observations, invalid metadata, or role behavior that conflicts with the protocol record.

Unknown

The monitor cannot classify the node from available evidence. Unknown is a useful label when the review must request another observation, a reference check, or a configuration audit.

5.14 Behavior Taxonomy

This section: Behavior Taxonomy — The broader taxonomy treats every label as a current evidence state rather than a permanent identity.

The broader taxonomy treats every label as a current evidence state rather than a permanent identity.

Selfish

The node appears to preserve its own traffic while avoiding shared work such as forwarding, route participation, or cooperative sensing. This label needs evidence of asymmetry, not just one missing relay.

Malicious

The node appears to introduce active harm such as false claims, identity conflict, route manipulation, selective distortion, or data tampering that is not explained by ordinary limits. This label needs corroboration and careful confidence language.

Dumb or limited-capability

The node has limited diagnostic evidence. It may be simple, temporarily silent, or unable to explain its local state. The safe response is recovery review, stale-data protection, and a clear retest trigger.

Evidence for Behavior Taxonomy starts in Figure 5.2. Look at Sensor-Node Behavior Taxonomy Map beside From observed evidence to a cautious label before accepting the structure behind Behavior Taxonomy.

+

Figure Figure 5.2 shows how to move from a node’s expected role to a cautious label. First record what it should send, forward, or verify, then compare readings, messages, route claims, and status with that expectation. Checks from neighbors, gateways, schedules, and peers may strengthen or weaken the observation. Confidence decides whether a behavior label is supported or the case stays suspect. The vocabulary includes silent, selfish, malicious, and unknown, but the next step is a bounded action that protects the affected decision. A retest trigger states what new observation could change the label.

Use a small evidence window before assigning intent. Suppose a gateway expects one health packet every 60 seconds from node N17. In a five-minute window N17 should produce five packets, but the monitor receives zero while two neighbouring nodes continue to report and the parent still forwards other traffic. The immediate label is silent or suspect, not malicious: the evidence proves absence from this decision path, but it does not yet prove deliberate harm. The safe action is to mark N17’s value stale, route decisions through related nodes, and clear the label only after current packets with valid metadata return.

A different window supports a different label. If N17 sends all five of its own readings but a watchdog overhears it forward 0 of 20 packets for children while nearby relays forward most observed packets, the pattern is self-serving rather than merely absent. If the same node also advertises false routing state or rewrites readings, the record can move toward malicious. Keep the label scoped to the observed role: a selfish relay label does not automatically invalidate a still-plausible local temperature report.

5.15 Label-To-Action Guide

This section: Label-To-Action Guide — The action should match the evidence.

The action should match the evidence.

Healthy: use the node for the current decision while keeping normal monitoring and retest rules. Silent: mark the current source unavailable or stale for affected decisions; check schedule, role, related nodes, and recovery evidence before assigning a cause. Suspect: reduce confidence, request corroboration, or route the decision through additional evidence. Selfish: avoid relying on the node for shared work while collecting relay or cooperation evidence; do not treat it as malicious unless the record supports active harm. Malicious: protect the affected route, identity, or data path with narrow quarantine, corroboration, or exclusion bounded to the evidence record. Dumb or limited-capability: preserve last-good evidence, handle buffered data carefully, and name the condition that would reopen or clear the recovery review. Unknown: hold a conservative state, collect missing evidence, and avoid irreversible labels.

5.16 Evidence Checks

This section: Evidence Checks — Classification improves when each check has a narrow purpose.

Classification improves when each check has a narrow purpose.

Message presence

Ask whether the node has sent an expected message recently enough for the current decision. Record whether the missing state is temporary, repeated, or unexplained.

Value plausibility

Ask whether the value is possible under the known context. Plausibility checks catch impossible readings, unit mistakes, stuck values, and readings outside the accepted band.

Consistency

Ask whether the reading agrees with related evidence. Related evidence may come from a nearby node, a repeated sample, a reference observation, or a process signal that should change together.

Role behavior

Ask whether the node is behaving consistently with its assigned role. A relay, sampler, actuator-adjacent node, or observer may have different expectations.

Recovery state

Ask whether the node recently restarted, rejoined, changed configuration, or lost required metadata. Recovery evidence can explain a temporary suspect state, but it should not automatically restore trust.

5.17 Node Behavior Patterns

This section: Node Behavior Patterns — Behavior monitoring gives evidence; classification interprets it.

Behavior monitoring gives evidence; classification interprets it. A watchdog can overhear whether a neighbour actually forwards packets it was given, while a reputation record can aggregate observations over time. The same missing forward can mean very different things depending on whether the node is also missing its own reports, preserving only its own traffic, or actively corrupting route or data state.

Keep separate counters for own reports, relay opportunities, overheard forwards, failed plausibility checks, and contradictory peer evidence. A soil-moisture node that reports 44%, 45%, and 44% while adjacent nodes report 43% and 46% is probably cooperative for that decision. A node that reports 99% for six samples while adjacent probes remain near 45% is available but suspect or misleading. A relay that sees 18 child packets and forwards only one, yet sends its own five packets on time, is a selfish hypothesis until more evidence proves a fault or active attack.

The response should be as narrow as the evidence. Mark a stale sensor unavailable for the affected dashboard rather than removing it from every network function. Down-weight a contradictory reading until a reference check or repeated sample resolves the conflict. Quarantine a routing participant only when the record shows harmful route or identity behaviour. A simple two-window rule often helps: warn on the first weak window, act only when the second window repeats the same pattern.

5.18 Dropped Packets Need Denominators

This section: Dropped Packets Need Denominators — “Dropped a packet” is weak evidence unless the record states how many chances the node had, what the monitor could overhear, and whether the same radio link carried the node’s own traffic.

“Dropped a packet” is weak evidence unless the record states how many chances the node had, what the monitor could overhear, and whether the same radio link carried the node’s own traffic. A watchdog that observes 20 relay opportunities, hears only 2 forwards, and also sees the node send 10 of 10 own reports has a different case from a monitor that missed one forward during a noisy interval.

Reputation systems usually smooth these observations across windows, age old evidence down, and separate role-specific scores so a poor relay score does not automatically condemn a temperature reading that still passes plausibility and peer checks.

5.19 Selfish Forwarding Evidence

This section: Selfish Forwarding Evidence

5.20 Classification Matrix

This section: Classification Matrix — Before applying Classification Matrix, view Figure 5.3 and compare Node Behavior Classification Matrix with Label.

Before applying Classification Matrix, view Figure 5.3 and compare Node Behavior Classification Matrix with Label. Their relationship makes the structure behind Classification Matrix reviewable.

+

Figure Figure 5.3 ties each label to an observation and a review action. A healthy node has expected, plausible data that agrees with other evidence, so the team can accept it while keeping freshness data. A silent node needs a missing-data response before the decision proceeds. Weak or conflicting evidence calls for isolation or lower weight; data that is present but untrustworthy goes to review. An unknown case needs another observation. The matrix treats labels as aids to the present decision: a reference check can move a node from suspect to healthy, and later evidence can change that judgment again.

• Healthy evidence can be accepted, but the record should still keep freshness and validity metadata.
• Silent evidence requires a missing-data action before the decision continues.
• Suspect evidence should be isolated or down-weighted until an additional check resolves it.
• Misleading evidence should be rejected for the affected decision and routed to review.
• Unknown evidence should trigger a request for the missing observation rather than a confident label.

5.21 Worked Review: Silent Temperature Node

This section: Worked Review: Silent Temperature Node — Scenario: a room condition dashboard expects periodic temperature readings from a node.

Scenario: a room condition dashboard expects periodic temperature readings from a node. The node has stopped sending messages.

Concrete example: a classroom comfort dashboard expects a temperature and humidity packet from each room node every review interval. If one room stops reporting while nearby rooms continue, the current room value should be marked missing instead of being copied forward as a fresh reading.

Observation

The last accepted message is old enough that the dashboard can no longer treat the value as current.

Evidence check

Message presence fails. There is no current reading, and the data record should not silently reuse the last value.

Classification

Silent.

Action

Mark the current reading unavailable, show the affected room state as missing, and request a node health review. Do not infer a temperature trend from stale data.

Residual concern

The silence may hide a local issue that the application still needs to handle, so the decision record should state how missing evidence changes the downstream rule.

5.22 Continue to the Next Part

This section: Continue to the Next Part — Carry this evidence into Node Behaviour: Contradictions and Review, which begins with Plausible but Contradictory.

Carry this evidence into Node Behaviour: Contradictions and Review, which begins with Plausible but Contradictory.