47 In-Network Data Aggregation

47.1 Start With the Field Story

Picture ten field sensors that report soil moisture to one pump. Sending every reading keeps detail but uses more radio time. Sending one local average saves messages but may hide a dry corner.

Name the pump decision first. Decide which readings may be joined, how old they may be, and which missing sensor must stay visible. Give alarms their own path so a summary cannot smooth them away.

Then test a bad set. One dead sensor, one extreme value, or one late reading can change an average. A smaller message saves energy, but the saved bytes are not useful if the result no longer supports the action.

This ten-sensor story cannot choose the best summary for every network. It does not set freshness, group size, error, or relay placement. Those limits need field data and a clear recovery rule.

Use the Practitioner sections to build the set and summary record. Use Under the Hood for tree and cluster placement, missing members, and function behavior. The deeper work qualifies the simple average; it does not weaken the decision-first rule.

Build one set by hand. List all ten nodes. Mark the report time. Mark each unit. Mark the group rule. Remove one node. Keep its name visible. Add one dry value. Do not smooth it away. Add one late value. Apply the age rule. Compute the mean. Compute the lowest value. Compare both pump choices. Send an alarm alone. Save the raw set. Save the summary. Save the function name. Save the relay name. Break the relay. Use the backup path. Check energy before and after. Check the final soil state. Change the rule only with cause.

Aggregation helps only when the summary still answers the monitoring question. Start by asking what can be combined, what must stay separate, how freshness is protected, and how missing members or outliers remain visible.

47.2 In 60 Seconds

WSN data aggregation combines, filters, suppresses, or summarizes readings before they reach the sink. It can reduce radio traffic, but it can also hide the evidence that an application needs. The reviewer must ask what decision the aggregate supports, which function is used, where aggregation happens, which nodes or readings are missing, how fresh the result is, and how outliers or alarms escape summary loss.

Use this chapter after the routing introduction and challenge review. A good aggregation answer does not say “aggregate everything.” It records the aggregation purpose, function choice, completeness rule, freshness rule, relay or cluster role, exception path, accuracy check, owner, fallback action, and retest trigger.

47.3 Learning Objectives

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

• explain what in-network data aggregation changes in a WSN route
• select aggregation functions based on the application decision and failure risk
• review completeness, freshness, missing-member visibility, and outlier handling
• identify where aggregation should happen in a tree, cluster, or data-centric route
• build an aggregation evidence record with acceptance limits and retest triggers

47.4 WSN Data Aggregation Review

47.5 Prerequisites

This chapter builds on WSN Routing Introduction Review, WSN Routing Challenge Review, and WSN Routing Protocol Classification Review. If the learner cannot describe source nodes, relay nodes, sinks, route state, and aggregation risk, review those chapters first.

47.6 What Data Aggregation Means

Aggregation changes the data that travels through the route. A node may combine nearby readings, suppress duplicates, forward only extremes, count events, compress a distribution, or report a summary instead of raw samples.

47.7 Aggregation Is a Claim About a Set

An aggregate is not just a smaller packet. It is a claim that a named set of readings, sources, time windows, and exceptions can be represented by a smaller value. The review starts with the set behind the summary: which sensors were expected, which contributed, which were late or missing, which readings were filtered, and which alarms were forced around the summary path.

Use Figure 47.1 to compare the radio work created by the same six sources. The readings do not disappear in the aggregated case; an intermediate node assumes responsibility for representing them.

In Figure 47.1, the left side has S1-S6 each forwarding a separate message through the relay, leaving the upstream route and sink to handle six transmissions. On the right, two intermediate aggregators combine their local groups and the main aggregator sends one summary towards the sink. That reduction can save forwarding energy, but the advertised 6-to-1 message count is not proof that the summary is adequate. The sink still needs the function, contributing-member count, freshness, and exception status to know what the one message represents.

A useful aggregate carries four labels. The function label says whether the value is a mean, maximum, count, threshold list, histogram, or another summary. The membership label names expected and contributing sources. The time label names the sampling window, aggregation time, and stale-data rule. The exception label names alarms, outliers, bad quality, duplicates, or missing members that must remain visible.

Use one test before accepting a compact summary: if two different source sets could produce the same aggregate value but require different operational actions, the aggregate needs more evidence or a different function.

47.8 Aggregation Function Fit

Figure 47.2 begins with the same four readings and deliberately fans out to different summaries. Follow those branches to see why aggregation is chosen from the downstream decision rather than from packet size alone.

In Figure 47.2, an average or median at the relay, cluster, branch, or sink boundary preserves a slow trend but can hide a dangerous peak. A maximum or threshold list keeps alarm evidence; a count answers a membership question; and a histogram or top-k result preserves more of the spread and outliers. Whichever branch is selected, the summary must also carry count, freshness, quality, and exceptions. The separate exception path is what stops an alarm or missing-member warning from being averaged into an ordinary-looking result.

The same raw readings can support different decisions. Average may be useful for a slow trend, maximum or threshold may be necessary for an alarm, count may be enough for occupancy, and a histogram may preserve distribution shape. When the wrong function is selected, the route can deliver a clean-looking packet that has lost the important evidence.

47.9 Function Review Guide

Function choice is an evidence decision. It should name the value being preserved and the value being sacrificed.

47.10 Fair Aggregation Is More Than Majority Rule

When nodes contribute decisions rather than interchangeable measurements, aggregation also needs a fairness contract. A majority vote can repeatedly ignore a small region, a weakly connected cluster, or the patient whose evidence arrives last. “Fair” therefore has to become testable: identify who is eligible, prevent the topology leader from receiving automatic extra authority, apply the same rule to equivalent contributors, make a contributor’s stronger support unable to harm its chosen outcome, and record how missing or conflicting votes are handled.

A practical design can form temporary groups around the decision context instead of treating a cluster head as the opinion owner. Each group submits an authenticated decision plus freshness and quality state; the aggregation rule combines eligible inputs, and an exception path preserves high-consequence minority reports. No rule satisfies every fairness goal in every case, so the application must state the trade-off. Equal votes resist leader bias but may ignore sensor reliability; reliability weights use evidence quality but can entrench a historically favoured node; unanimity protects minorities but can block action; simple majority progresses quickly but can suppress rare hazards.

Consider body-area sensors serving patients during an evacuation. A mobile collection point may receive several local “stable” decisions and one fresh high-criticality alert. Ordinary majority voting could erase the case that needs attention most. A defensible rule keeps the urgent alert on an exception path, uses the collective decision only for the routine group, records eligible and missing contributors, and explains any weighting. Fairness here does not mean every packet has identical influence; it means that influence follows a declared, auditable rule tied to the care decision rather than network position.

47.11 Completeness, Freshness, Members

Aggregation is only trustworthy when the sink knows what the summary represents.

Without these fields, aggregation can turn a sensor failure into an apparently normal average. The route may look efficient while the monitoring claim becomes weaker.

47.12 Aggregation Evidence Record

Treat the diagram in Figure 47.3 as the review trail for one aggregation rule. It begins with the application decision and its risk, because that claim determines which losses of detail are acceptable.

The diagram in Figure 47.3 uses its first review row to record the chosen function and aggregation boundary, then makes completeness, freshness, and the exception path explicit. Validation compares summaries with raw samples and checks whether the application decision changes. The acceptance row assigns an owner and links the deployed summary to its evidence file; it also records relay health, fallback behaviour, limits, and a retest trigger. A topology, load, or rule change can therefore reopen the decision instead of letting an old acceptance silently outlive its evidence.

47.13 Epoch and Membership Ledger

Aggregation usually runs in repeated collection epochs. During each epoch, children sample, relay results upward, and the aggregation boundary emits one summary for that window. The review should ask whether the epoch is long enough to include expected children, short enough to satisfy the application, and explicit enough to mark late arrivals instead of silently excluding them.

Tree, cluster-head, data-centric, and mobile-collector designs all need this ledger. Every boundary that combines readings needs a compact record explaining what it combined and why the result is still acceptable. Useful states include complete, partial-accepted, partial-warning, stale, exception-forwarded, rejected, and needs-raw-validation.

47.14 Where Aggregation Happens

Aggregation placement changes the route. The same function can be safe at the sink and unsafe at a relay if it hides missing members before the route can detect them.

The review should explain why the selected boundary is the right compromise for the decision, route health, and operations evidence.

The diagram in Figure 47.4 keeps LEACH control traffic, scheduled member traffic, aggregation, and the long sink uplink in one energy story.

Walk through Figure 47.4 from Candidate heads to Strongest signal and Separate resources. In the Members sleep until slot stage, N1–N4 avoid idle listening; CH-A and CH-B then pay the receive, aggregation, and sink-uplink cost that the round ledger must preserve.

47.15 LEACH Cluster Formation and Aggregation

LEACH (Low-Energy Adaptive Clustering Hierarchy) makes the cluster-head boundary concrete. It assumes a dense deployment in which every node can reach the sink directly, but uses local clusters so ordinary nodes usually transmit over a shorter distance and only cluster heads perform the expensive aggregation and sink uplink. A common design target is that about $p=0.05$ of eligible nodes become cluster heads in a round. Five percent is a teaching value, not a universal constant: the right fraction depends on field size, radio model, density, aggregation ratio, and sink placement.

A round has two phases. During setup, the network constructs temporary clusters:

1. Eligible nodes elect themselves as cluster-head candidates for this round.
2. Each candidate broadcasts an advertisement. Ordinary nodes compare received advertisements and normally request membership in the cluster whose advertisement arrived with the strongest signal.
3. A cluster head accepts members, selects a cluster-specific spreading code when the implementation uses CDMA separation, and publishes a TDMA schedule assigning each member an intra-cluster transmit slot.
4. Members turn off their receivers outside the time needed for their slot and schedule control, reducing idle listening and cross-member collisions.

During steady state, each member samples and transmits in its slot. The cluster head must remain awake for the member schedule, receive the reports, apply the declared aggregation function, and forward the compact result to the sink. The classic description uses CSMA for cluster-head access toward the sink; that means the uplink still needs carrier sensing, random backoff, collision and retry evidence even though member access is scheduled.

47.15.1 LEACH Round Lifecycle

Rotation prevents the same nodes paying the head cost forever. A common threshold rule gives node $n$ a chance to become a head only if it has not been one during the previous epoch of about $1/p$ rounds:

$$T(n)= \begin{cases} \dfrac{p}{1-p\left(r \bmod \frac{1}{p}\right)}, & n\in G(r),\\[6pt] 0, & n\notin G(r), \end{cases}$$

where $r$ is the round number and $G(r)$ is the set of nodes not yet selected in the current epoch. An eligible node draws $u\sim U(0,1)$ and becomes a candidate when $u<T(n)$. With $p=0.05$, the epoch spans about 20 rounds. The threshold rises for the nodes that remain eligible, so the role is distributed over the epoch rather than permanently assigned.

Follow one complete lifecycle:

1. Election: eligible nodes evaluate the threshold and advertise if selected.
2. Re-clustering: ordinary nodes choose among this round’s advertisements; membership from the previous round is not silently assumed.
3. Scheduling: each new head assigns its cluster code and TDMA slots.
4. Collection: members send readings in their slots; the head records received and missing members.
5. Aggregation and uplink: the head produces the stated aggregate and competes to send it to the sink.
6. Round close: nodes close the epoch ledger, age the current schedule, and return to setup for the next round.

Rotation distributes expected burden, but random election alone does not prove fairness. Residual energy, cluster size, head-to-sink distance, isolated nodes, clock drift, control overhead, and a failed head can dominate the result. A deployment should log head identity, cluster membership, setup duration, member delivery, head energy, aggregate completeness, sink delivery, and the recovery action for every round. Without that ledger, the protocol can rotate titles while leaving the real relay burden concentrated.

The aligned lifecycle in Figure 47.5 shows why re-election distributes the cluster-head burden rather than making it disappear.

In Figure 47.5, CH=A · cluster joins begins round r, and A aggregates + uplinks aligns with the steep drop on Node A. At CH=B · new clusters, the extra decline moves to Node B, demonstrating that rotation spreads the expensive role across rounds while each round still incurs it.

47.16 Duplicate Sensitivity and Route Shape

Different aggregate functions tolerate loss and duplication differently. On a single-path aggregation tree, one dropped child packet can remove the contribution of an entire subtree. On a redundant multipath design, the same reading may arrive more than once. Both cases can be acceptable or dangerous depending on the function class.

This is why a design that is efficient for maximum temperature may be unsafe for average load or event count. A count or sum cannot assume that duplicate forwarding is harmless. If a sensor report can arrive through two parents, the design needs duplicate suppression, single-path ownership, or another duplicate-safe method before the aggregate can be trusted.

The opposite risk appears when the route is too narrow. A single tree can save traffic, but a relay failure removes all child evidence behind that relay. The aggregate should therefore name repair behavior: reopen raw samples, switch parent, reissue the query, lower aggregation depth, send a partial-warning label, or reject the result until coverage returns.

47.17 LEACH Threshold Application

47.18 Accuracy and Validation

Aggregation accuracy is not only a math property. It depends on missing data, link behavior, sensor quality, time alignment, location meaning, and the function being used.

An aggregate is acceptable when it preserves the evidence required by the decision and exposes enough uncertainty for operations to act safely.

47.19 Greenhouse Trend Monitoring

Scenario: A greenhouse uses many temperature and humidity sensors to watch slow environmental trends. The operator needs zone-level conditions and missing-zone visibility.

47.20 Worked Review: Equipment Heat Alarm

Scenario: A WSN watches equipment enclosures for overheating. One hot reading can matter even if nearby sensors are normal.

47.21 Common Mistakes

47.22 Review Checklist

Before accepting WSN data aggregation, verify that the record includes:

application decision and aggregation purpose. selected function and rejected alternatives. aggregation boundary, owner node or role, and route impact. expected members, contributing members, missing members, and partial-data rule. freshness, timeout, stale-data, and time-alignment rule. outlier, alarm, duplicate, and quality-flag exception path. validation method using raw samples or independent checks. accepted limits, owner, fallback action, and retest trigger.

47.23 Knowledge Check: Function Choice

47.24 Knowledge Check: Missing Members

47.25 Match Aggregation Functions to Evidence

47.26 Order the Aggregation Review

47.27 Summary

WSN data aggregation can make routing more efficient only when it preserves the evidence the application needs. Reviewers should choose the function from the decision, record the aggregation boundary, expose completeness and freshness, preserve alarms and outliers, monitor relay or cluster roles, validate with raw samples, and define retest triggers. Good aggregation is not just fewer packets; it is a trustworthy summary with visible uncertainty.

47.28 Key Takeaway

WSN Routing Data Aggregation Review should balance path reliability, link quality, energy cost, latency, aggregation, topology change, control overhead, and deployment evidence.

47.29 Concept Relationships

47.30 What’s Next

Continue with WSN Routing Directed Diffusion to review interest-driven routing, then use WSN Routing Link Quality to test whether links and parent choices support the aggregation boundary. For the broader route family map, return to WSN Routing Protocol Classification Review.