Chapters

2 WSN Introduction and History

iot
wireless-sensor-networks
foundations

2.1 Start With the Field Story

Inspect Figure before reducing a deployment to network-node circles. The weatherproof station exposes the enclosure, mast, cable, power, orientation, and siting decisions that determine whether a logical WSN design can survive in the field.

Outdoor environmental sensor station (weatherproof enclosure) in a real physical setting
A weatherproof sensor station shows the enclosure, mast, cable, power, and siting decisions hidden by a network-node circle. Read the visible connections, enclosure, mounting, and surroundings as deployment evidence alongside the model on this page. Photo: Jim Barton; CC BY-SA 2.0

In Figure, trace the sensing head down through its mast and cable into the enclosure, then ask where power, radio clearance, sealing, and maintenance access enter the design. That physical chain challenges any assumption that the logical block alone captures the complete field system.

Begin With One Useful Field Fact

Imagine a park worker who needs to know when a young tree is too dry. A small unit measures the soil. It may pass the result through other units before the message reaches a local bridge. The useful outcome is not “a packet arrived.” It is “this tree needs water now.”

A wireless sensor network, or WSN, is a group of small measuring units that share facts over radio links. The designer should start with the field decision. Name what is measured, how often it matters, how far the message travels, and who acts when it is missing.

Then test the installed network. Remove one unit, weaken a battery, block a path, and compare the reading with a trusted check. Make gaps visible instead of filling them with guesses.

This simple story leaves out how units share time and choose routes. Practitioner plans the field system. Under the Hood explains radio behavior, energy limits, and routing rules.

Begin with one simple claim: small devices in the field need to notice something and report it often enough to matter. The rest of a WSN review checks whether node roles, radio paths, gateways, energy budgets, and maintenance plans can keep that claim true after the first demonstration.

The mathematical gist. A typical 2000 mAh, 3.6 V primary cell stores 7.20 Wh only at the constant-voltage nameplate approximation. A 30 mA pulse through 3 Ω internal resistance sags 0.0900 V to 3.51 V. After an 80% derating, 1600 mAh or 5.76 Wh remains; at 50 µA average current that bounded ledger gives 32,000 h, or 3.65 years.

Math Bridge · guided foundationsWhy is 2000 mAh not yet a lifetime answer?Let Packet Pete connect charge, energy, pulse sag, usable capacity, and runtime.

2.2 What a WSN Claim Means

What must survive the move from Sensing Purpose to Condition measured,? The visual at Figure 2.1 poses that question for the current what a wsn claim means decision.

WSN overview evidence map connecting sensing purpose, node roles, site evidence, energy state, network path, acceptance limits, owner response, and retest trigger.
Figure 2.1: WSN overview evidence map connecting sensing purpose, node roles, site evidence, energy state, network path, acceptance limits, owner response, and retest trigger.

Begin with the Condition measured, label in Figure 2.1, noting that it states how the claim is checked. Look backward to Sensing Purpose, which defines what the design promises, and forward to place, interval,, which sets the timing constraint. This reveals why wSN overview evidence map connecting sensing purpose, node roles, site evidence, energy state, network path, acceptance limits, owner response, and retest trigger. The visual therefore advances what a wsn claim means, rather than interrupting it.

WSN history matters because it explains the recurring pressures: constrained energy, lossy links, placement-sensitive measurements, topology changes, gateway boundaries, and maintenance ownership. Early research proved that many constrained nodes can create useful system evidence. Field deployments proved that lab connectivity is only one part of the review.

That order prevents a common beginner mistake: treating the network diagram as the whole system. A WSN can look connected while the sensing point is misplaced, the relay carries too much traffic, the gateway loses meaning during recovery, or the support owner has no retest rule. The introduction should therefore approve only the part of the system that has matching field evidence.

If you only need the intuition, this layer is enough: approve a WSN from the sensing claim, node roles, topology, power evidence, data path, operations owner, and retest trigger. A successful packet in a lab does not prove field sensing quality.

2.2.1 The Five Evidence Boundaries

Sensing purpose

The review starts with what condition is measured, where it is measured, at what interval, and which decision uses the data.

Node behavior

Sensor, processor, radio, storage, sleep state, retry behavior, calibration, enclosure, mounting, and battery assumptions define each node claim.

Network behavior

Star, cluster, mesh, relay, sink, gateway, routing, aggregation, loss, recovery, and stale-data behavior define the communication claim.

Operations behavior

Battery replacement, calibration, firmware, keys, gateway health, alert ownership, data quality, and retest triggers decide whether the deployment remains trustworthy.

2.2.2 Beginner Examples

A gateway ping proves only a narrow communication fact. It does not prove sensing placement, power life, route recovery, or missing-data detection. A mesh diagram is not proof of route resilience. Relay load, parent choice, loss, recovery, and battery impact need field evidence. A sensor reading is not useful unless it is placed, calibrated, timestamped, delivered, and interpreted for a decision. A WSN can be the wrong tool when wired sensing, manual sampling, a powered gateway, or fewer high-quality instruments provide better evidence.

2.2.3 Overview Knowledge Check

2.3 WSN Review Record

A practical WSN review record should let another engineer repeat the decision. It states the sensing objective, node role model, topology, power budget, data path, gateway boundary, failure behavior, owner, and change that reopens the decision.

Early design may record assumptions. A release review should replace assumptions with representative evidence from field placement, enclosure, calibration, interference, traffic, route behavior, battery profile, gateway outage behavior, missing-data handling, and support procedures.

Evidence Area
Review Question
Evidence to Record
Failure If Missing
Sensing claim
What physical condition supports which decision?
Phenomenon, location, interval, accuracy need, latency, calibration rule, placement, and acceptance limit.
The network carries data that is connected but not useful for the decision.
Node roles
Which devices sense, relay, aggregate, sink, or bridge?
Leaf nodes, relays, cluster heads, sinks, gateways, role changes, local storage, retry behavior, and ownership.
Relay or gateway devices silently carry more traffic, energy, and maintenance burden than the review expects.
Topology and routing
How does data reach the service?
Star, cluster, mesh, hybrid, route selection, link quality, hop count, aggregation, recovery after node or gateway loss, and stale-data rule.
The design assumes connectivity from a diagram while field links, route repair, and data-loss behavior remain unproved.
Energy and duty cycle
What work consumes power?
Sensing, processing, transmit, receive, listening windows, retries, joins, downlinks, maintenance traffic, firmware updates, and sleep current.
Battery life is estimated from one transmit event while hidden receive, retry, and maintenance work drains the node.
Data quality and gateway
How are readings trusted after leaving the node?
Timestamp, buffering, duplicate rule, missing-data alert, gateway recovery, backend mapping, dashboard threshold, and audit trail.
Missing, stale, noisy, duplicated, or delayed data becomes a trusted operational signal.
Operations
Who keeps the evidence current?
Owner, battery replacement, calibration, firmware, key rotation, gateway health, physical inspection, support runbook, and retest triggers.
Support cannot tell whether a field change invalidates the original WSN approval.

2.3.1 Worked Review: Greenhouse Monitoring

A greenhouse team wants temperature and humidity readings from several growing zones. The review should start with the control decision and acceptable latency, then record sensor placement, enclosure behavior near wet areas, calibration, gateway reachability, reporting interval, missing-node alerts, and battery replacement ownership.

The safe approval statement is narrow: under the reviewed placement and reporting interval, this sensor field supports these zone-level decisions. It does not prove every crop layout, gateway location, enclosure, battery, or future alert threshold.

2.3.2 Bridge Vibration Monitoring

A bridge monitoring deployment needs vibration evidence at selected structural points. The review should separate measurement quality from radio connectivity: mounting validation, feature preservation, sample or summary behavior, buffering, relay load, gateway outage behavior, weather exposure, and retest triggers after maintenance or firmware changes.

The approval should not say that low-power wireless generally solves structural monitoring. It should say which sensing features, node positions, network route, and operations procedure were observed.

2.3.3 Practitioner Knowledge Check

2.4 Layer Handoffs and Failures

WSN failures are often misdiagnosed because several layers appear as one missing reading. A measurement can be wrong before it is transmitted. A good measurement can be buffered and delayed. A packet can reach a relay but not a gateway. A gateway can store data while the dashboard interprets it with stale thresholds. A working route can still be operationally unsafe if nobody owns batteries, calibration, or keys.

The review should preserve the handoff from physical observation to node behavior, network delivery, gateway and backend interpretation, and operations. That separation keeps a narrow lab result from becoming a broad deployment claim.

Handoff
What It Proves
What It Does Not Prove
Retest Trigger
Phenomenon to node
The physical condition can be observed by the selected sensor at the reviewed location and mounting.
Radio delivery, gateway interpretation, battery life, or usefulness for every decision.
Sensor, calibration, mounting, enclosure, placement, threshold, environment, or decision-latency change.
Node to network
The node can timestamp, process, buffer, sleep, wake, transmit, receive, and retry under the tested workload.
Route resilience, gateway recovery, backend mapping, or long-term maintenance readiness.
Reporting interval, payload, firmware, sleep mode, battery, local storage, radio settings, or retry rule change.
Network to gateway
The topology and route can move data toward a sink or gateway under the reviewed link and traffic conditions.
Measurement accuracy, backend semantics, alert correctness, or support ownership.
Node density, gateway location, obstruction, interference, route rule, relay role, aggregation, or failure scenario change.
Gateway to operations
The service can store, display, alert, audit, and recover around the reviewed data path.
That every future field condition, threshold, owner, key, firmware, or maintenance procedure preserves the same evidence.
Backend mapping, alert threshold, dashboard, owner, firmware, credential, key, maintenance, or support-runbook change.

2.4.1 Diagnosis Pattern

Name the failing boundary. Separate bad measurement, missing packet, stale reading, duplicate reading, gateway outage, alert error, and maintenance failure. Check the closest lower proof. If the dashboard is wrong, inspect gateway and backend mapping before moving nodes. If the reading is noisy, inspect placement and calibration before changing routing. Change one variable at a time. Sensor placement, reporting interval, retry policy, route behavior, gateway location, and alert threshold can each change the evidence trail. Write the unsupported claim. If the pilot covered one room, one topology, one season, or one battery profile, keep the approval limited to that boundary.

2.4.2 Under-the-Hood Knowledge Check

2.5 Summary

WSN approval starts with a bounded sensing claim, not with a wireless label or a lab packet. Node roles, topology, routing, power, gateway behavior, data quality, and operations ownership need separate evidence. Sensing quality depends on placement, calibration, enclosure, interval, and the decision that uses the data. Energy review must include sensing, processing, transmit, receive, retries, listening windows, joins, downlinks, and maintenance traffic. Network review must cover topology, role burden, link quality, route repair, gateway recovery, and stale-data behavior. Operations evidence names owners for batteries, calibration, firmware, keys, gateway health, alert thresholds, and retest triggers.

Key Takeaway

Approve a WSN only when the reviewed behavior is tied to sensing purpose, node roles, topology, routing, energy evidence, gateway behavior, owner, and retest boundary.

2.6 See Also

WSN Architecture and Applications

Review node, sink, gateway, backend, topology, application-fit, and operations boundaries.

WSN Sensor Nodes and Hardware

Connect sensing, processing, radio, storage, enclosure, mounting, and power evidence to node behavior.

WSN Communication Patterns

Review message flow, aggregation, link behavior, loss, retry, and gateway handoffs in WSN communication.

WSN Energy Management

Separate duty cycle, sleep, receive windows, retries, maintenance traffic, and replacement evidence.