5 Node Behaviour: Evidence and Taxonomy

5.1 Start With the Decision

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 is part 1 of 2. Continue with Node Behaviour: Contradictions and Review.

5.3 Part Objectives

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

5.4 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

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. Use the Practitioner layer to map labels to bounded actions and review records. Use the Under the Hood layer to inspect packet totals, selfish conduct, silent faults, and mixed evidence. The deeper routes may change the label, so every choice needs a retest point.

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

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

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

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

5.10 Minimum Viable Understanding

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

• 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

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?.

In the Figure 5.1 visual, Node Behavior Classification Path names a responsibility. The next element, What did the monitor observe?, names a responsibility; What does the evidence support? retains verification evidence. Placing Node Behavior Classification Path before What does the evidence support? reveals the dependency in The node behavior classification path answers what the monitor observed, what the evidence supports, and what action is safe, running five evidence checks into a confidence, a bounded action, and a retest trigger. That makes What did the monitor observe? a checkable part of Classification Frame.

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

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

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.

The visual in Figure 5.2 divides responsibilities clearly: Sensor-Node Behavior Taxonomy Map marks information entry; From observed evidence to a cautious label retains verification evidence; Expected role names a responsibility. Between Sensor-Node Behavior Taxonomy Map and Expected role, responsibilities define Sensor-node behavior taxonomy map linking expected role, observed evidence, related checks, confidence, behavior label, bounded action, and retest trigger. For Behavior Taxonomy, retain From observed evidence to a cautious label when applying this result.

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

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

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

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

“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

5.20 Classification Matrix

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.

Three labels control the Figure 5.3 visual: Node Behavior Classification Matrix names a responsibility; Label names a responsibility; Observed evidence retains verification evidence. The boundary joining Node Behavior Classification Matrix and Observed evidence organises Sensor node classification matrix connecting each behavior label to its observed evidence and bounded review action. The Classification Matrix review can now test Label directly.

• 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

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

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