Observed Data
Readings, events, summaries, and health state usually move from field nodes toward sinks, gateways, and backends.
8 WSN System Architecture
iot
wireless-sensor-networks
architecture
communication
8.1 Start With the Field Story
Imagine sensors watching a greenhouse overnight. One node measures the air, nearby nodes pass the reading along, and an operator receives a warning. A gateway is the device that connects the sensor network to another system. Latency means the delay from the field event to the response.
Start with the warning the operator needs. Trace it from sensor to neighbor, gateway, storage, and screen. At each handoff, ask what can be lost or changed. Then test a dead node, a blocked path, and a missing gateway. The design should state which service continues and which result is no longer safe to claim.
Use a one-reading architecture check. Name the sensor and unit. Name the first node that holds the reading. Mark every relay. Mark the network exit. Name the service that stores it. Name the rule that turns it into an alert. Name the person who acts. Give each arrow a delay and loss limit. Give each box an owner and a health signal.
Now remove one box or arrow. State what still works. State what becomes unknown. Add recovery only where the service needs it. This keeps a pretty network drawing tied to real work.
This one-path story cannot settle every choice about shape, power, coverage, or maintenance. The Practitioner section compares roles and system boundaries. Under the Hood follows capacity, timing, and failure behavior in detail.
A WSN architecture is the path from a field event to a decision owner. Trace one reading from node to neighbor, sink, gateway, backend, and operator, then ask what each handoff proves and what each handoff could lose.
8.2 Architecture Starts With Claims
Wireless sensor network architecture is the connection between a field monitoring claim and a supportable system. The useful question is not “star or mesh?” The useful question is what must be sensed, which node roles are needed, how data reaches a gateway, what the backend does with the data, and who keeps the evidence current after deployment.
A greenhouse trend network, bridge-monitoring network, perimeter alarm, and livestock tracker can all use wireless sensors, but they need different coverage, latency, power, gateway, data-quality, and service evidence. The architecture should make those differences visible before a topology diagram becomes an approval.
Pause the architecture starts with claims discussion at the diagram in Figure 8.1. Comparing Monitoring claim against serve exposes the evidence the next step would otherwise hide.
Notice how Figure 8.1 distinguishes Monitoring claim from serve: the first defines what the design promises, but the second adds a distinct review condition. Add Node roles, which adds a distinct review condition, to recover the whole system view. The figure’s conclusion is that wSN architecture review route from monitoring claim through node roles, gateway path, topology fit, application fit, operations evidence, decision, known limit, and retest trigger. This conclusion belongs in architecture starts with claims.
The beginner mistake is to treat architecture as a drawing of boxes and links. A real WSN architecture is a chain of promises. The sensing promise says the field condition is observed; the network promise says readings move with enough freshness and quality; the gateway promise says data keeps its identity and time; the operations promise says someone can maintain the evidence after handoff.
That chain should stay narrow. If the reviewed claim is slow greenhouse trends, the architecture may be acceptable for trend decisions while still being unapproved for alarms, control, safety response, or a new layout. Good architecture notes prevent that drift by naming the accepted output, the unsupported claim, and the change that forces another review.
If you only need the intuition, this layer is enough: approve WSN architecture from the monitoring claim outward. Name the node roles, topology fit, gateway path, backend decision, operations owner, known limit, and retest trigger.
8.2.1 The Architecture Evidence Boundaries
Monitoring objective
State the physical condition, asset, area, route, boundary, or event the network must observe and the decision that uses the result.
Node roles
Separate leaf sensors, relays, cluster heads, sinks, gateways, mobile nodes, reference nodes, and event-heavy nodes by work and risk.
Path and topology
Choose star, tree, cluster, mesh, or hybrid paths because they fit field evidence, not because the topology label sounds resilient.
Operations boundary
Gateway behavior, backend interpretation, calibration, batteries, firmware, keys, support actions, and retests are architecture requirements.
8.2.2 Beginner Examples
A mesh diagram does not prove resilience until relay load, route repair, link quality, and battery impact are observed. A star topology can be the right answer when direct gateway paths are reliable and gateway failure is handled explicitly. A trend-monitoring architecture should not silently become an alarm architecture without new latency, event, and response evidence. A gateway is not just a pipe. It is a boundary for buffering, identity, clock behavior, diagnostics, backhaul, and ownership.
8.2.3 Overview Knowledge Check
8.3 Architecture Review Record
A practical architecture record should let another engineer repeat the decision. It states the accepted monitoring claim, the node role model, the topology and gateway path, the backend output, the service boundary, and the change that reopens the decision. It should be short enough to use and specific enough to prevent scope drift.
Early design may record assumptions. A release review should replace assumptions with representative evidence from placement, enclosure, calibration, interference, routing, gateway outage behavior, data-quality rules, power state, maintenance access, and support ownership.
Evidence Area
Review Question
Evidence to Record
Failure If Missing
Claim and output
What condition is monitored and what output is accepted?
Phenomenon, location, interval, latency, data-quality need, decision user, known limit, and non-goal.
The system collects readings without proving what operational decision they support.
Node roles
Which devices sense, relay, aggregate, sink, bridge, validate, or move?
Leaf nodes, relays, cluster heads, gateways, reference nodes, mobile nodes, role changes, service load, and ownership.
All nodes are treated as equal while some carry hidden traffic, timing, energy, or maintenance burden.
Topology fit
Why does this path pattern fit the field?
Star, tree, mesh, cluster, or hybrid reason, gateway reach, weak zones, hop count, link quality, repair behavior, and failure cases.
A diagram is approved even though field links, route convergence, relay pressure, and gateway risk remain unproved.
Gateway and backend
How does data become a usable decision?
Buffering, backhaul, clock behavior, identity, duplicate rules, missing-data visibility, validation, alerting, dashboard mapping, and audit.
Data is sensed but not delivered, delivered but not trusted, or trusted with stale or wrong meaning.
Operations
Who keeps the architecture true after handoff?
Battery replacement, calibration, firmware, keys, physical inspection, gateway health, spare stock, support runbook, owner, and retest triggers.
The architecture passes a pilot but cannot be supported or diagnosed after the first field change.
8.3.1 Greenhouse Climate Network
A greenhouse wants temperature and humidity monitoring across growing bays. The review should approve trend monitoring only after checking sensor placement, moisture exposure, calibration, gateway reachability, weak zones near fans or doors, reporting interval, missing-node alerts, and battery replacement ownership.
The safe approval statement is narrow: under the reviewed placement and interval, this network supports zone-level climate trend decisions. It does not prove every crop layout, gateway location, enclosure, battery, or future alarm threshold.
8.3.2 Worked Review: Bridge Monitoring Network
A bridge owner wants selected vibration and strain locations monitored to support inspection planning. The architecture record should name sensor and reference locations, gateway placement, relay roles, power access, backhaul, weather exposure, event-burst behavior, and how missing data remains visible to inspectors.
The approval should not say that low-power wireless generally solves structural monitoring. It should say which sensing features, node positions, network paths, gateway behavior, and operations procedure were observed for inspection evidence.
8.3.3 Example Review Record
wsn_architecture_record:
claim: greenhouse zone temperature and humidity trends
non_goal: immediate fire alarm or safety response
node_roles: leaf sensors in bays, gateway near service area, reference logger for calibration checks
topology: direct gateway paths where possible, limited relay only for verified weak zones
gateway_boundary: buffering, missing-node alert, backhaul recovery, clock behavior, diagnostics
backend_boundary: trend display, stale-data label, calibration note, operator workflow
operations: battery replacement owner, calibration interval, enclosure inspection, spare tags
retest_trigger: bay layout, gateway position, sensor model, reporting interval, or alert use changes
8.3.4 Practitioner Knowledge Check
8.4 Handoffs and Failure Boundaries
Architecture failures often look like one symptom even when the broken boundary is elsewhere. A node may measure correctly while the relay path drains a gateway-adjacent node. A gateway may buffer data while the backend displays stale values without a warning. A topology may carry normal traffic while failing during a burst or after a parent node changes.
The review should preserve the handoff from monitoring objective to node role, topology, gateway, backend, and operations. That separation makes later troubleshooting easier and prevents one pilot condition from expanding into a broad application claim.
Handoff
What It Proves
What It Does Not Prove
Retest Trigger
Claim to node roles
The sensing objective has named devices with appropriate sensing, relay, gateway, reference, or mobile responsibilities.
That those roles have enough energy, route stability, maintenance access, or backend meaning under all conditions.
Objective, interval, sensor, placement, reference method, role assignment, or ownership change.
Roles to topology
The chosen star, tree, cluster, mesh, or hybrid path fits the reviewed field layout and traffic pattern.
That recovery, burst behavior, relay burden, gateway failure, or battery life remains valid after field changes.
Gateway location, obstruction, interference, node density, relay role, traffic load, routing rule, or firmware change.
Topology to gateway
The network can move accepted readings to a sink or gateway with reviewed timing, buffering, duplicates, and loss behavior.
That the backend interprets data correctly, flags stale values, or preserves every operational decision.
Backhaul, buffering policy, clock behavior, duplicate rule, outage duration, gateway hardware, or diagnostics change.
Gateway to operations
The service can store, display, alert, audit, recover, and hand off support for the reviewed monitoring claim.
That future thresholds, support owners, firmware, keys, calibration, battery plans, and application claims remain approved.
Dashboard, alert threshold, role owner, firmware, key, calibration plan, maintenance route, or application scope change.
8.4.1 Diagnosis Pattern
Name the failing boundary. Separate wrong measurement, role overload, broken route, gateway outage, stale dashboard value, missing owner, and changed application claim. Check the closest lower proof. If the dashboard is stale, inspect gateway timestamps and backend mapping before moving nodes. If relay batteries fail, inspect role load before changing sensors. Change one variable at a time. Gateway position, reporting interval, topology rule, relay role, backend threshold, firmware, and maintenance owner can each change the evidence trail. Write the unsupported claim. If the pilot proved trend monitoring for one layout, keep alarm, safety, and new-layout claims out until they are reviewed.
8.4.2 Under-the-Hood Knowledge Check
8.5 WSN Communication Patterns
8.5.1 Start With the Field Story
Imagine soil sensors spread across a field. Each sensor has a small reading, but the farmer needs one clear view. A gateway is a device that gathers local messages and passes them to another network. The first question is who sends what, to whom, and how often.
Begin with one useful reading and trace its path. Decide whether a sensor sends directly, uses a neighbor, or waits for the gateway. Then test a blocked path, a repeated message, and a missing reply. The record should show lost data instead of quietly filling the gap. It should also show who can send a command back into the field.
This short path assumes that radio links and power stay within known limits. A real field may change with rain, plants, traffic, or broken nodes. The Practitioner section compares traffic and relay patterns. Under the Hood follows timing, capacity, and recovery in detail.
Start with the direction of the conversation. Some nodes only report, some answer queries, some relay for neighbors, and some receive control updates. Communication review is the story of whether the traffic pattern, radio path, aggregation choice, and gateway behavior match that promise.
8.5.2 Communication as Evidence Path
WSN communication is the path that lets a field observation become a reviewable claim. It includes uplink readings, downlink commands, neighbor coordination, gateway handoff, buffering, missing-data visibility, duplicate handling, and the rule for reopening the design when field assumptions change.
Use the labelled path in Figure 8.2 to challenge communication as evidence path. If Monitoring claim cannot be connected to support, the surrounding conclusion is premature.
Rather than treating the labels as a list, relate Monitoring claim to support in Figure 8.2. The former defines what the design promises; the latter adds a distinct review condition. Traffic pattern then adds a distinct review condition, completing the visual statement: WSN communication review route from monitoring claim through traffic pattern, link path, gateway path, aggregation fit, control path, evidence, decision, and retest trigger. That completed statement informs communication as evidence path.
For that reason, a communication approval should read like an evidence route. It should explain what moves first, what can wait, what can be lost, what must be acknowledged, what the gateway is allowed to transform, and what operators see when the path is degraded.
8.5.3 Allocate Slots by Urgency Without Starving the Network
A time-slotted WSN needs more than a collision-free schedule when many sources share one sink. Giving every node the same opportunity can delay an emergency behind routine reports, while always serving the most critical source can exhaust weak relays and starve quieter nodes. A priority-aware scheduler can rank each ready transmission from three kinds of evidence: application criticality, the node’s remaining energy or forwarding burden, and time elapsed since its last successful delivery.
Criticality raises urgent traffic; energy state prevents the schedule from silently consuming the nodes that keep the route connected; elapsed waiting time acts as ageing, so a routine source eventually moves forward instead of waiting forever. The scheduler evaluates only eligible, authenticated traffic, assigns the next available slots, and recomputes after acknowledgements, failures, or state changes. A safety class may pre-empt the ordinary ranking, but its admission, retry limit, expiry, and fallback need their own rules.
Imagine several wearable networks reporting through one emergency-vehicle gateway. A new critical event should outrank periodic status packets, yet a patient whose last reports repeatedly failed should gain priority as waiting time grows. A nearly depleted relay may need its forwarding load reduced unless it is the only path for an urgent alert. The trade-offs are explicit: more priority classes and state exchange improve responsiveness but add synchronization, signalling, and manipulation risk. Validate worst-case delay per class, starvation bounds, queue overflow, clock loss, energy impact, and behaviour during simultaneous emergencies—not only average packet delivery in a quiet test.
If you only need the intuition, this layer is enough: approve a WSN communication design from a written flow claim. Name the data path, control path, coordination path, gateway boundary, accepted loss or delay, known limit, owner, and retest trigger.
Control Path
Commands, configuration, time updates, acknowledgements, and service messages move toward nodes and need separate evidence.
Coordination Path
Neighbor discovery, route state, schedules, cluster roles, and repair messages keep the network operating during change.
Evidence Boundary
Missing, delayed, duplicated, stale, aggregated, or buffered data must stay visible enough for the monitoring claim.
8.5.4 Communication Evidence Record
A useful communication record describes what each traffic pattern is allowed to prove. It should be short enough to maintain, but specific enough that a later deployment, support, or audit review can see what was accepted and what must be retested.
Pattern
Evidence to Keep
Common Weak Point
Retest Trigger
Convergecast
Route depth, relay burden, retry behavior, gateway-adjacent load, missing readings, and duplicate handling.
Many-to-one traffic hides a fragile relay, overloaded parent, or gateway bottleneck.
Gateway move, topology change, reporting interval change, new relay role, antenna change, or repeated missing records.
Downlink control
Command timing, acknowledgement, sleeping-node reachability, retry limit, expiry rule, and safe fallback.
Uplink success is reused as proof that commands can reach quiet or weak nodes safely.
Configuration workflow, firmware update, duty cycle, command type, key state, or actuator-adjacent behavior changes.
Aggregation
Input set, function, time window, exception rule, output meaning, and what detail operators can no longer infer.
A summary removes rare events, local extremes, fault evidence, or burst timing needed by the claim.
Application claim, threshold, summary window, dashboard decision, event rule, or forensic requirement changes.
Gateway and backhaul
Buffering, timestamps, identity, restart behavior, replay order, duplicate policy, delayed delivery, and outage visibility.
Backhaul loss is treated as outside scope even though it changes what operators can trust.
Gateway model, location, backhaul path, backend contract, storage limit, time source, or operations owner changes.
The record should also name the accepted limit. A greenhouse trend network can tolerate delayed periodic readings if missing reports remain visible. A safety-adjacent alarm, public warning path, or fast control loop may need a different communication claim, stronger acknowledgement, and a separate review.
Communication evidence record template
Flow claim: what information or command must move, in which direction, for which monitoring decision.
Accepted pattern: convergecast, downlink, local coordination, event burst, aggregation, buffering, or hybrid behavior.
Accepted evidence: link path, relay burden, timing, retries, missing-data visibility, gateway behavior, and operator display.
Known limit: the claim this communication design does not approve, such as immediate safety alarm, fast actuation, or forensic reconstruction.
Owner: who maintains gateway, backhaul, firmware, keys, dashboards, diagnostics, and support procedures.
Retest trigger: the exact traffic, gateway, firmware, sampling, aggregation, topology, application, or service change that reopens review.
8.5.5 Communication Evidence Failures
Most weak communication decisions fail at a boundary between a packet and its meaning. A packet can arrive late, duplicated, stale, aggregated beyond use, buffered without a replay rule, or separated from the health state that explains whether it should be trusted.
Load Boundary
Convergecast concentrates work near sinks, relay parents, and gateways. Those nodes need separate energy, queue, route, and failure evidence.
Meaning Boundary
Aggregation, filtering, compression, and duplicate removal are safe only when the lost detail is not required by the application claim.
Timing Boundary
Sleep cycles, receive windows, event bursts, backoff, buffering, and backhaul outage determine whether data and commands arrive in time to matter.
Control Boundary
Downlink commands require identity, acknowledgement, expiry, retry, and fallback evidence because a missed or repeated command can change field state.
Event bursts are the easiest way to expose the boundary. A quiet periodic network may look healthy until many nodes cross a threshold at once. The review then needs congestion behavior, priority rules, duplicate handling, gateway buffering, and the operator view of missing or late records.
Control traffic exposes the same issue from the opposite direction. A gateway may receive regular uplinks while a sleeping node still misses a configuration command, applies it after the decision window, or repeats it after a retry. Command evidence therefore needs expiry, acknowledgement, identity, and fallback rules of its own.
Gateway and backhaul behavior also belongs inside the communication review. If a gateway restarts, loses time, queues records during outage, or reconnects out of order, the backend must be able to distinguish late evidence from fresh evidence and duplicates from new field events.
The under-the-hood rule is to avoid accepting silent conversion. If data is summarized, delayed, buffered, retried, reordered, acknowledged, or used to issue a command, the communication record should state what changed and what the system can no longer claim.
8.5.6 Summary
WSN communication should be approved from a written flow claim, not from arrows in a diagram. The review separates observed data, downlink control, local coordination, event bursts, gateway behavior, and recovery paths. Convergecast needs relay, gateway-adjacent, queue, retry, duplicate, and missing-data evidence. Aggregation is acceptable only when the summary still preserves the detail required by the claim. Sleeping nodes, backhaul outage, event bursts, firmware changes, and control commands need explicit timing and fallback evidence. A changed gateway, antenna, topology, sampling interval, aggregation rule, firmware, dashboard decision, or application claim should reopen the communication review.
8.5.7 Key Takeaway
Approve WSN communication by evidence path. The accepted record should tie traffic pattern, gateway behavior, aggregation rule, control path, known limit, owner, and retest trigger to the monitoring claim.
8.5.8 See Also
WSN Architecture and Applications
Place communication paths inside node roles, topology choice, gateway placement, backend boundaries, and operations ownership.
Sensor Node Characteristics
Review the node-side sensing, storage, radio, power, diagnostics, and service evidence that communication depends on.
WSN Energy Management
Connect communication load, retry behavior, sleep schedules, receive windows, and service margin to power evidence.
WSN Routing Protocol Classification Review
Compare route classes, relay behavior, path repair, and communication tradeoffs after the flow claim is known.
8.6 Summary
WSN architecture starts with a monitoring claim and accepted output, not with a topology label. Sensor nodes, relays, cluster heads, gateways, reference nodes, mobile nodes, and backends carry different evidence burdens. Topology is a fit decision: star, tree, mesh, cluster, and hybrid paths each trade simplicity, resilience, energy, latency, and operations cost. Gateway and backend behavior are architecture boundaries because buffering, backhaul, time, duplicates, missing data, and dashboards shape the claim. Application fit matters: a network approved for slow trends is not automatically approved for alarm, control, safety, or new inspection workflows. Architecture approval should name known limits, owner, support procedure, and retest triggers.
8.7 Key Takeaway
Approve WSN architecture only when the reviewed behavior ties monitoring claim, node roles, topology, gateway path, backend output, operations owner, and retest boundary together.
8.8 See Also
Sensor Node Characteristics
Review sensing, processing, radio, storage, power, firmware, diagnostics, and service evidence for each node role.
Communication Paradigms
Trace message flow, aggregation, link behavior, loss, retries, gateway paths, and communication retests.
WSN Energy Management
Separate dominant drains, state budgets, routing load, harvesting fit, service margin, and retest evidence.
WSN Deployment Sizing
Turn architecture assumptions into candidate counts, gateway paths, pilot evidence, installation limits, and release checks.