45 WSN Routing Protocol Classification

45.1 Start With the Field Story

This section: Start With the Field Story — Use one short route review.

Use one short route review. Draw the source nodes. Draw the collection point. Add any moving parts. Show the usual data direction. Mark the weak links. Mark the busy nodes.

Then ask basic questions. Who creates a path? Who repairs it? How long may repair take? Which nodes do extra work? Does the method need location? Does it need a fixed tree? Can it follow a named event?

Choose the family last. Test its key assumption first. Break one link. Move one node. Add more reports. Watch energy and delivery. Keep the result bounded to that field setup. Recheck when movement, load, or node roles change.

Imagine a farm with many small sensor nodes. One node reports soil moisture. Another passes that report onward. A third moves with a vehicle. All three need a path to the collection point. They do not need the same kind of path.

Start with what moves. The node may stay fixed. The source may move. The collection point may move. Next, ask where reports need to travel. Some go from many sources to one place. Some go from one place to many nodes. Others follow a named event or area.

A route is the chosen path between these nodes. Classification means grouping route methods by the assumptions they make. One family may build a tree. Another may ask for data by interest. A third may use location. A fourth may change paths when nodes move. The label is useful only when those assumptions match the field.

Now check the cost. Count how often nodes must listen. Notice how often paths change. Record missing and late reports. Mark any node that carries too much work. A route that reaches the goal can still drain one area early.

This first view treats each family as a clear pattern. Real networks can mix patterns and react over time. Do not choose from the family name alone. The Practitioner layer builds the comparison record and field test. Under the Hood explains control messages, path scores, repair rules, and the cases where neat categories overlap.

Protocol classification is not a label-matching game. Name the traffic direction, node roles, mobility, link evidence, aggregation need, and reliability target first, then choose the routing family whose assumptions match those facts.

45.2 In 60 Seconds

This section: In 60 Seconds — WSN routing classification is a decision aid, not a menu of universal answers.

WSN routing classification is a decision aid, not a menu of universal answers. Data-centric, hierarchical, geographic, reactive, proactive, tree-based, and quality-aware approaches each make different assumptions about traffic, node roles, location knowledge, route state, link quality, aggregation, mobility, reliability, and operations.

Use this chapter after the routing-challenge review. A classification answer should first name the workload and evidence, then choose the family that makes the fewest unsafe assumptions. The accepted record should also name why close alternatives were rejected and what would trigger a retest.

45.3 Learning Objectives

This section: Learning Objectives

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

• classify WSN routing approaches by the evidence each family requires
• distinguish data-centric, hierarchical, geographic, reactive, proactive, tree-based, and quality-aware routing fit
• compare protocol-family tradeoffs without relying on brittle lifetime, cost, range, or performance claims
• explain why protocol names such as Directed Diffusion, LEACH, GPSR, AODV, SPEED, and RPL are examples, not automatic answers
• build a classification record with accepted assumptions, rejected alternatives, owner, and retest triggers

45.4 WSN Routing Classification Review

This section: WSN Routing Classification Review

45.5 Prerequisites

This section: Prerequisites — This chapter builds on WSN Routing Challenge Review, WSN Routing Introduction, and WSN Routing and Monitoring Review.

This chapter builds on WSN Routing Challenge Review, WSN Routing Introduction, and WSN Routing and Monitoring Review. If the learner cannot identify relay pressure, link-quality evidence, or aggregation risk, review routing challenges before classifying protocol families.

45.6 Classification Review Scope

This section: Classification Review Scope — Classification is useful only when it is tied to the application evidence.

Classification is useful only when it is tied to the application evidence. Start with the traffic and route-health claims, then map them to a family.

45.7 Classification as an Assumption Contract

This section: Classification as an Assumption Contract — Treat a routing-family label as an assumption contract, not as a finished design.

Treat a routing-family label as an assumption contract, not as a finished design. The label should bind a monitoring claim to a traffic pattern, route state, link evidence, repair behavior, and an operations record. If any one of those pieces is missing, the label is still a hypothesis rather than an accepted classification.

Use Figure 45.1 as the worked route for the assumption contract. The upper panel follows one soil-moisture report from a source through a relay to the collection point and marks the link evidence that must be measured on each hop. The lower panel shows the six pieces that a routing-family label must bind before the classification is accepted.

+

Read Figure 45.1 from top to bottom. First trace the source-to-relay-to-collection path and record link quality, retry counts, and measurement age for both hops. Then check the assumption contract: monitoring claim, traffic pattern, link evidence, route state, repair behavior, and operations record. Test those pieces before choosing the routing family; if one is missing, the classification remains a hypothesis. Retest when deployment assumptions such as topology, gateway placement, firmware, or mobility change.

A useful review separates three statements that are often blurred together. The design statement names the family the team intends to use. The evidence statement lists the observations that would make that family true for this workload. The operations statement says who watches the evidence and what happens when it drifts. A protocol name may appear in the design statement, but it cannot replace the other two.

The fastest way to catch a weak classification is to ask what evidence would disprove it. If a proactive tree cannot show stale-parent age, it is not yet an accepted tree. If a data-centric design cannot show how old an interest is, it is not yet an accepted interest route. If a quality-aware label cannot name the reliability or freshness target, it is only a preference for better service, not a classification.

45.8 Protocol Families as Evidence Patterns

This section: Protocol Families as Evidence Patterns — Use Figure 45.2 to compare the assumption each routing family uses to choose or maintain a path.

Use Figure 45.2 to compare the assumption each routing family uses to choose or maintain a path.

+

Start with data-centric routing. It uses a query or data name to guide packets, so each node need not have a world-wide address. The next group uses cluster roles to join data and cut traffic, but the leaders do more work. Place-based rules use a node’s position to move a packet, so sound points and a plan for dead ends are vital. Service-aware rules add delay, trust, or power limits to the choice. The map sorts families; it does not rank them. The app claim tells you which key idea to test at the site.

The family map is not a ranking. A data-centric approach can be excellent for query-driven events and weak for simple periodic collection. A hierarchical approach can save traffic when summaries preserve meaning and fail when cluster heads hide missing members. A geographic approach can be elegant when position evidence is trustworthy and brittle when location, void handling, or movement assumptions are weak.

45.9 Family Review Guide

This section: Family Review Guide — Do not force a chapter example into a deployment.

Do not force a chapter example into a deployment. The correct family may be hybrid: periodic readings may use a stable tree, alarms may need a higher-priority route, and firmware distribution may use a separate controlled dissemination pattern.

45.10 LEACH-Like Round Review

This section: LEACH-Like Round Review — LEACH is useful as a teaching example because it makes the hierarchical assumptions visible.

LEACH is useful as a teaching example because it makes the hierarchical assumptions visible. A typical round has a setup phase and a steady-state phase. In setup, candidate cluster heads advertise, nearby members choose a cluster, and the cluster head publishes the schedule that members will use. In steady state, members transmit in assigned windows, the cluster head aggregates the readings, and the cluster head forwards the summary toward the sink. Later rounds rotate the cluster-head burden so the same nodes do not always pay the relay and aggregation cost.

A LEACH-like label is not enough by itself. The review should prove that the dense-node assumption, cluster-head reach, schedule behavior, aggregation meaning, and role-rotation evidence all fit the monitoring claim.

45.11 Hybrid Family Ledger

This section: Hybrid Family Ledger — Real deployments often classify more than one traffic class.

Real deployments often classify more than one traffic class. A quiet environmental network might use a tree for periodic readings, a reactive repair path for temporary outages, and a quality-aware exception route for urgent alarms. Record each traffic class separately instead of forcing the whole deployment into one family.

The ledger also prevents hidden downgrades. A cluster head may make energy sense for a room summary, but it can hide which member failed unless the aggregate carries member evidence. A reactive route may save background traffic, but it can be unacceptable for an alarm if discovery delay is not bounded. Each accepted family needs its own limit, monitor, owner, and retest trigger.

For mixed workloads, record the interaction between rows. A backup path for alarms may consume the same relay energy that the periodic tree depends on. A cluster summary may reduce upstream traffic but delay a query that needs raw member values. A geographic shortcut may bypass the normal monitor path and make fault evidence harder to collect.

45.12 Classification Decision Route

This section: Classification Decision Route — Watch how one network workload becomes a route choice.

Watch how one network workload becomes a route choice. The strip moves from a drawn path, to a comparison grid, to a record that can accept or reject a candidate.

The first panel states the workload and decision. The comparison grid tests route families against link, relay, repair, and monitoring evidence. The last panel records rejected alternatives, an owner, and a retest trigger. Next, Figure 45.3 compares proactive tree with AODV-like reactive routing for a building telemetry workload.

+

In Figure 45.3, compare the ready parent state, link history, relay pressure, and missing-node monitoring required for the proactive tree with the discovery delay, repair cost, and quiet-versus-dead checks for reactive routing. For this regular-reading workload, begin with a tree family only if route health and missing-node monitoring are in place; record rejected alternatives, owner, limits, and retest trigger.

45.13 Tradeoff 1: Flat, Tree, or Hierarchical

This section: Tradeoff 1: Flat, Tree, or Hierarchical — Flat routing treats nodes as peers.

Flat routing treats nodes as peers. Tree routing organizes traffic toward a root or sink. Hierarchical routing adds roles such as cluster heads or aggregation leaders.

The key question is not “which family saves the most energy in theory?” The key question is “which family can prove the monitoring claim with visible route health and acceptable side effects?”

45.14 Tradeoff 2: Proactive or Reactive

This section: Tradeoff 2: Proactive or Reactive — Proactive designs maintain route state before data arrives.

Proactive designs maintain route state before data arrives. Reactive designs discover or repair routes when traffic needs them. Both can be appropriate.

Avoid accepting a reactive design for urgent alarms unless the route-discovery delay and failure behavior have been tested. Avoid accepting a proactive design for quiet networks unless control overhead and stale-state behavior are visible.

45.15 Single, Multipath, Quality Routes

This section: Single, Multipath, Quality Routes — Single-path routing is simple but can drop data during failure.

Single-path routing is simple but can drop data during failure. Multipath and quality-aware routing add resilience but cost route state, energy, duplicate handling, and monitoring complexity.

Classification should describe the service behavior, not just the implementation label. “Quality-aware” is not credible unless the quality target, measurement method, owner, and fallback action are named.

45.16 Building Telemetry Classification

This section: Building Telemetry Classification — Scenario: Battery nodes report room conditions to a nearby gateway.

Scenario: Battery nodes report room conditions to a nearby gateway. The building has dense walls and occasional gateway maintenance. Readings are useful for trend monitoring, not emergency control.

45.17 Field Event Query Classification

This section: Field Event Query Classification — Scenario: A field deployment mostly sleeps, but the gateway occasionally asks whether a region is above a threshold.

Scenario: A field deployment mostly sleeps, but the gateway occasionally asks whether a region is above a threshold. The answer is useful only if freshness and duplicate behavior are visible.

45.18 Common Mistakes

This section: Common Mistakes

45.19 Expiry and Retest Rules

This section: Expiry and Retest Rules — A classification should expire when the evidence that made it true no longer describes the network.

A classification should expire when the evidence that made it true no longer describes the network. In practice, the expiry rule is more important than the protocol name, because the same family can move from safe to unsafe after a gateway move, firmware change, enclosure change, sampling-rate change, node-density change, or new reliability requirement.

One practical implementation is to put an evidence TTL beside every accepted family row. The TTL is not a packet timer; it is the maximum age of the review evidence. A quiet greenhouse network might allow a weekly route-family review for trend telemetry, while an alarm path might require proof after every firmware update or gateway move.

Use a simple contradiction test: if the newest observation would have caused the team to reject the family during design, the family label has expired. A sudden rise in parent changes contradicts a stable-tree assumption. Missing member IDs contradict a cluster summary that claims per-room coverage. Position drift contradicts a geographic route. Reclassification is a normal maintenance action, not a failure of the original design.

45.20 Review Checklist

This section: Review Checklist — workload, traffic direction, and decision use.

Before accepting a WSN routing classification, verify that it records:

workload, traffic direction, and decision use. candidate family and required assumptions. link-quality, relay-load, route-state, repair, and monitoring evidence. aggregation or redundancy side effects when the family uses them. rejected alternatives and why they were rejected. accepted limits, owner, fallback action, and retest trigger.

45.21 Knowledge Check: Assumption Contract

This section: Knowledge Check: Assumption Contract

45.22 Knowledge Check: Family Fit

This section: Knowledge Check: Family Fit

45.23 Knowledge Check: Rejecting a Family

This section: Knowledge Check: Rejecting a Family

45.24 Match Routing Families to Evidence

This section: Match Routing Families to Evidence

45.25 Order the Classification Review

This section: Order the Classification Review

45.26 Summary

This section: Summary — WSN routing protocol classification works best as an evidence-backed review step.

WSN routing protocol classification works best as an evidence-backed review step. The family label should follow the workload, topology, link quality, node roles, aggregation needs, route-state behavior, repair cost, reliability requirements, and operations evidence.

Do not treat a protocol name as a design answer. The accepted classification should name the selected family, the evidence that supports it, the alternatives rejected, the accepted limits, the owner, and the retest trigger.

45.27 Key Takeaway

This section: Key Takeaway — WSN Routing Protocol Classification Review should balance path reliability, link quality, energy cost, latency, aggregation, topology change, control overhead, and deployment evidence.

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

45.28 Concept Relationships

This section: Concept Relationships

45.29 What’s Next?

This section: What’s Next?

Continue with these routing chapters: