Physical Evidence
Placement, calibration, warm-up, drift, saturation, environmental exposure, and reference checks show whether the node can observe the condition it claims to observe.
6 Node Behaviour: Contradictions and Review
iot
wireless-sensor-networks
sensor-nodes
6.1 Start With the Decision
A node can send valid-looking values that clash with its neighbours. Review must test presence, plausibility, and consistency apart.
6.2 Route Overview
This is part 2 of 2. Review Node Behaviour: Evidence and Taxonomy for the preceding evidence.
6.3 Learning Objectives
- Distinguish missing evidence from contradictory evidence.
- Write a review record that links each label to an action.
6.4 Chapter Roadmap
- Plausible but Contradictory
- Worked Review: Mixed Missing Evidence
- Review Record
- Common Mistakes
- Knowledge Check
- Matching Quiz
- Ordering Quiz
- Sensor Node Characteristics
- Summary
- Key Takeaway
- Concept Relationships
- What’s Next
6.5 Plausible but Contradictory
Scenario: a storage area has several related condition readings. One node reports a value that is possible by itself, but it repeatedly contradicts nearby observations and the expected process state.
Observation
The node still sends complete messages. The value is not impossible, but it does not match related evidence.
Evidence check
Message presence passes. Plausibility passes. Consistency fails repeatedly.
Classification
Misleading for the affected decision.
Action
Reject that reading for the current decision, preserve it as evidence with a suspect validity state, and request a reference check or replacement review.
Residual concern
The failed consistency check does not prove the physical cause. The classification should stay evidence-bound and avoid claiming a root cause until a separate inspection supports it.
6.6 Worked Review: Mixed Missing Evidence
Scenario: a gateway notices that one node’s current reading is missing. The node’s previous reading was accepted, but the expected message did not arrive during the current review window.
Concrete example: a storage-room humidity node reported normally during the last review window, but the dashboard refresh has no new message while nearby temperature and door-state nodes are still reporting.
First pass
The node is not immediately failed, selfish, or malicious. The strongest first label is silent because the expected message is absent.
Context check
The reviewer checks schedule, topology role, related nodes, and whether the node recently changed duty-cycle behavior. If nearby nodes are also missing, the label may stay silent or move into limited-capability recovery review. If only shared relay traffic is missing while the node’s own readings continue, selfish behavior may become a hypothesis.
Action
The current decision should not reuse the stale value as current. The review record marks the source unavailable for that decision, preserves the last accepted observation, and records what new message, related-node observation, or recovered data would reopen the label.
6.7 Review Record
The purpose of the figure at Figure 6.1 is to test a specific review record boundary: Node / source ID must remain consistent with Expected role.
The route through the map at Figure 6.1 is Node / source ID to Expected role to Latest accepted observation. Respectively, they establishes the starting condition, adds a distinct review condition, and identifies the field observation. The route matters because node behavior review record listing nine fields: source identifier, expected role, latest accepted observation, failed and passed checks, behavior label, confidence, decision action, residual concern, and retest trigger. It leaves the review record claim with an explicit test boundary.
Record:
- node or source identifier;
- expected role;
- latest accepted observation;
- failed and passed checks;
- behavior label;
- confidence;
- decision action;
- residual concern;
- retest trigger.
The retest trigger matters because node behavior can change. Repeat the classification after a configuration change, relocation, reference check, repeated missing state, or new contradiction.
6.8 Common Mistakes
Treating silence and misleading data as the same failure. Assuming a root cause from one symptom. Accepting plausible values without consistency evidence. Removing a node from every decision when only one decision path is affected. Hiding missing readings by reusing old values without a stale state. Classifying a node without recording confidence and action. Forgetting to retest after configuration or placement changes.
6.9 Knowledge Check
6.10 Matching Quiz
6.11 Ordering Quiz
The round-aligned view in Figure 6.2 is a useful safeguard against labelling a healthy cluster head as an energy-anomalous node.
In Figure 6.2, Node A declines sharply during A aggregates + uplinks, while Node B declines after CH=B · new clusters. A classifier must therefore join energy evidence to round and role metadata: the same slope can be expected cluster-head behavior in one window and suspicious depletion in another.
6.12 Sensor Node Characteristics
6.12.1 Begin With One Node in One Place
Firmware is the code that runs on a device. Picture a soil sensor placed at the edge of a field. Calling it a sensor node says very little. The useful first choice is its field role: what it senses, what it stores, when it speaks, what it may relay, and how long it must work alone.
Write a one-line role claim. Name the sensor, sample time, local work, radio path, store, power source, case, and service visit. Then test one full cycle from wake to accepted record. Try a wet probe, weak cell, full store, lost link, reset, and stale clock. Record what data stays sound and what state the next system can see.
A small node can save cost and power, but it may hide faults or lose useful proof. Extra logs can aid repair, but they use store, energy, and air time. A board list does not prove the node will stay fit in the field. Use the Practitioner layer to write the role and evidence record. Use the Under the Hood layer to inspect sensing, timing, storage, radio, power, case, and reopen triggers. Those routes turn a part list into a service claim that can be tested again.
6.12.2 Start With the Field Story
Start with a single sensor node as a field worker with a job, limits, and proof obligations. It must sense, process, store, communicate, sleep, wake, diagnose itself, and survive service conditions well enough for the monitoring claim it supports.
Phoebe’s Field Notes: What a Directional Gateway Antenna Buys a Leaf Node
The mathematical gist. Raising gateway antenna gain from 2.15 to 9.15 dBi adds 7.00 dB. Spend it on ideal free-space range and the multiplier is 2.24×; spend it on lower transmit power and 10.0 dBm becomes 3.00 dBm. In the chapter’s typical 1% transmit ledger, PA current falls from 8.66 to 1.73 mA and bounded battery life rises from 455 days to 5.13 years, a 4.11× extension.
6.12.3 Sensor Node as Field Role
A WSN sensor node is the field system that turns a physical condition into usable evidence. It includes the sensor element, processing, radio, storage, power source, enclosure, firmware, identity, diagnostics, calibration path, and service plan. A part list is only a starting point.
The same rule applies to very small motes such as Michigan Micro Mote-style boards: miniaturization is interesting only after the review ties sensing, radio, storage, power, firmware, and service behavior to a field role.
The next sensor node as field role claim rests on a relationship, not an isolated value. Inspect Role Claim and Sensing Path in Figure 6.3 before accepting it.
First isolate Role Claim on the figure at Figure 6.3; it defines what the design promises. Next pair Sensing Path (adds a distinct review condition) with calibration (adds a distinct review condition). Their pairing demonstrates that wSN sensor node review route connecting role claim, sensing path, processing, radio path, power storage, diagnostics, evidence, decision, retest trigger, and service loop. This is what the chapter needs before continuing sensor node as field role.
If you only need the intuition, this layer is enough: approve a sensor node for one written role claim. Name what it senses, how it reports, what power and service limits apply, what failure becomes visible, and what change forces a retest.
Network Evidence
Radio reach, retries, receive windows, routing burden, queue behavior, time labels, and gateway handoff show whether readings can leave the node with their meaning intact.
Service Evidence
Battery threshold, enclosure access, firmware version, update behavior, diagnostics, identity, and maintenance ownership show whether the node can remain trustworthy after installation.
6.12.4 Sensor-Node Evidence Record
A useful record separates node subsystems from the claim they support. The goal is not to document every component detail. The goal is to preserve enough evidence that another reviewer can see why the node is acceptable, what it cannot prove, and who owns the next action when evidence weakens.
Subsystem
Evidence to Keep
Common Weak Point
Retest Trigger
Sensing path
Placement, calibration, sample timing, warm-up, drift, saturation, and quality flags.
The sensor part is trusted even though mounting or environment changed the measurement.
Sensor model, placement, calibration method, sampling interval, enclosure, or reference condition changes.
Processing and storage
Filtering, thresholds, timestamps, queues, logs, replay order, duplicate handling, and visible loss state.
Firmware hides missing, stale, filtered, or replayed data as if it were fresh evidence.
Firmware update, configuration change, outage behavior, queue pressure, storage wear, or new event threshold appears.
Radio and role load
Link behavior, retries, receive windows, routing burden, forwarded traffic, security state, and diagnostics.
A leaf-node test is reused after the node becomes a relay, cluster head, mobile node, or gateway-adjacent node.
Topology, gateway, antenna, route policy, channel condition, traffic mix, or node role changes.
Power and service
Sleep states, active current, brownout behavior, update window, service threshold, enclosure, identity, and owner.
The node can work in theory but cannot be reached, diagnosed, recalibrated, powered, or replaced safely in the field.
Battery chemistry, harvest source, duty cycle, enclosure, installation access, maintenance interval, or ownership changes.
Role changes deserve explicit review. A relay node receives and forwards other nodes’ traffic. A cluster head schedules or aggregates. A gateway-adjacent node may carry concentrated traffic and command exposure. A mobile node changes contact, location meaning, and custody. None of those burdens is proven by a leaf-node sensing test.
Sensor-node record template
Role claim: what this node must sense, forward, store, decide, or protect.
Accepted evidence: sensing path, processing path, radio path, storage path, power path, enclosure, identity, and diagnostics.
Known limit: the claim that is not approved, such as safety alarm, fast control, public warning, or new relay burden.
Owner: who maintains calibration, firmware, keys, battery, enclosure, and replacement state.
Retest trigger: the exact sensor, firmware, antenna, gateway, traffic, enclosure, power, service, or application change that reopens review.
6.12.5 Why Node Evidence Fails
Most weak sensor-node decisions fail at a boundary. The value may be measured correctly but timestamped badly. The packet may be sent but not acknowledged. The buffer may preserve data but replay it out of order. The firmware may recover but lose calibration state. The enclosure may protect the electronics but detune the antenna. The node may look healthy because diagnostics are missing.
Measurement Boundary
Sensor output becomes evidence only after placement, calibration, timing, range, noise, drift, and quality flags are reviewed against the monitoring claim.
Custody Boundary
Once data enters firmware, queues, radio, routing, and gateway handoff, the record needs freshness, duplicate, missing-data, replay, and ownership evidence.
Control Boundary
Remote commands, firmware updates, threshold changes, and actuator-adjacent decisions need stronger identity, authorization, rollback, and failure-state evidence.
Brownout is a useful example because it crosses several boundaries. A weak battery can corrupt timekeeping, reset firmware, shorten radio range, drop queue writes, or make diagnostics disappear. A resilient node review states how brownout is detected, how the node labels recovery, what data is discarded or preserved, and when service must act.
Diagnostics are the bridge between hidden device behavior and an operator decision. A good node exposes enough status to distinguish no event from no sample, no route from no power, no queue space from no gateway, and old calibration from a fresh observation. Without those labels, the backend may display a clean value while the node is actually outside its approved boundary.
That is why the evidence record should include negative states as well as successful measurements. Missing packets, low battery, stale timestamps, saturation, replacement, firmware rollback, and failed update attempts are not side notes. They are part of the proof that the node can tell the rest of the WSN when its own claim is no longer reliable.
The under-the-hood rule is to avoid accepting silent assumptions. If a node decision depends on calibration, time, state, route, queue, key, battery, enclosure, or owner, that dependency should appear in the evidence record with a known limit and retest trigger.
6.12.6 Summary
A WSN sensor node is a field role with sensing, processing, radio, storage, power, enclosure, firmware, identity, diagnostics, calibration, and service behavior. Node approval should start with a written role claim: leaf, relay, cluster head, mobile node, reference node, actuator-adjacent node, or gateway-adjacent node. Sensing evidence covers placement, calibration, sample timing, warm-up, drift, saturation, and visible quality flags. Processing, storage, and radio evidence must preserve freshness, ordering, replay, duplicate, loss, route, security, and diagnostic state. Power, enclosure, and service evidence determine whether the node can remain trustworthy after deployment. A changed sensor, firmware, antenna, gateway, topology, traffic load, enclosure, power source, service plan, or application claim should reopen the node review.
6.12.7 Key Takeaway
Approve sensor nodes by role and evidence boundary, not by board label. The reviewed claim must tie measurement, firmware, radio, storage, power, diagnostics, service owner, known limit, and retest trigger together.
6.12.8 See Also
WSN Architecture and Applications
Place node roles inside the wider topology, gateway path, backend boundary, operations owner, and retest record.
Communication Paradigms
Trace message flow, retries, aggregation, route behavior, gateway handoff, and communication evidence.
Sensor Node Behavior Classification
Classify silent, suspect, misleading, limited, or healthy node behavior from observable evidence.
WSN Energy Management
Review power states, duty cycle, dominant drains, service margin, and battery or harvesting retest triggers.
6.13 Summary
Sensor node behavior classification is an evidence review, not a guess about what broke. Healthy, silent, suspect, misleading, and unknown labels help teams separate missing data from active but untrustworthy data. The classification is strongest when it records message presence, plausibility, consistency, role behavior, recovery state, confidence, action, and retest trigger.
6.14 Key Takeaway
Node-behavior classification helps separate normal, degraded, selfish, malicious, and recovering nodes so the architecture can respond appropriately.
6.15 Concept Relationships
Behavior Taxonomy defines the broader behavior categories used before this classification step. Selfish & Malicious Nodes extends classification to nodes that intentionally withhold, distort, or abuse network roles. Limited-Capability And Recovery Cases focuses on response patterns when a node cannot provide rich diagnostic evidence. Duty-Cycling and Topology Management explains why expected schedules and topology roles affect behavior evidence.
6.16 What’s Next
Next, move from fault-style behavior labels to intent and incentive questions in Selfish & Malicious Nodes. Keep the same evidence discipline: label the behavior from observations, state confidence, and avoid claiming motives that the evidence does not support.
6.17 Continue Your Route
This final part closes the route from Plausible but Contradictory through What’s Next. Return to Node Behaviour: Evidence and Taxonomy or continue from the wsn module index.