%% fig-alt: "Comparison of traditional routing (address-centric, peer-to-peer, performance-focused) vs WSN routing (data-centric, many-to-one, energy-focused)"
%%{init: {'theme': 'base', 'themeVariables': {'primaryColor': '#2C3E50', 'primaryTextColor': '#fff', 'primaryBorderColor': '#16A085', 'lineColor': '#16A085', 'secondaryColor': '#E67E22', 'tertiaryColor': '#ECF0F1', 'fontSize': '16px'}}}%%
graph LR
subgraph "Traditional vs WSN Routing Comparison"
TRAD_ADDR["Address-Centric:<br/>Route to IP address"]
TRAD_P2P["Peer-to-Peer:<br/>Any-to-any communication"]
TRAD_PERF["Performance Goal:<br/>Minimize latency,<br/>maximize throughput"]
TRAD_SCALE["Scale:<br/>100s-1000s nodes"]
WSN_DATA["Data-Centric:<br/>Route by content<br/>(temp > 30°C)"]
WSN_M2O["Many-to-One:<br/>Sensors → Sink"]
WSN_ENERGY["Energy Goal:<br/>Minimize consumption,<br/>extend lifetime"]
WSN_SCALE["Scale:<br/>1000s-1,000,000s nodes"]
end
TRAD_ADDR -.->|"vs"| WSN_DATA
TRAD_P2P -.->|"vs"| WSN_M2O
TRAD_PERF -.->|"vs"| WSN_ENERGY
TRAD_SCALE -.->|"vs"| WSN_SCALE
style TRAD_ADDR fill:#95A5A6,stroke:#2C3E50,stroke-width:2px,color:#fff
style TRAD_P2P fill:#95A5A6,stroke:#2C3E50,stroke-width:2px,color:#fff
style TRAD_PERF fill:#95A5A6,stroke:#2C3E50,stroke-width:2px,color:#fff
style TRAD_SCALE fill:#95A5A6,stroke:#2C3E50,stroke-width:2px,color:#fff
style WSN_DATA fill:#16A085,stroke:#2C3E50,stroke-width:3px,color:#fff
style WSN_M2O fill:#16A085,stroke:#2C3E50,stroke-width:3px,color:#fff
style WSN_ENERGY fill:#E67E22,stroke:#2C3E50,stroke-width:3px,color:#fff
style WSN_SCALE fill:#3498DB,stroke:#2C3E50,stroke-width:3px,color:#fff
436 WSN Routing: Challenges and Requirements
436.1 Learning Objectives
By the end of this chapter, you will be able to:
- Identify WSN Routing Challenges: Explain why traditional routing protocols fail in sensor networks
- Compare Routing Paradigms: Distinguish address-centric from data-centric routing approaches
- Analyze Routing Requirements: Evaluate energy efficiency, scalability, and robustness requirements for WSN routing
436.2 Prerequisites
Before diving into this chapter, you should be familiar with:
- WSN Routing Introduction: Understanding the fundamental differences between WSN and traditional routing
- Wireless Sensor Networks: WSN architecture and multi-hop communication patterns
NoteKey Concepts
- Address-Centric Routing: Traditional routing based on destination IP addresses
- Data-Centric Routing: Routing based on data content and attributes
- Energy Hotspots: Nodes that deplete faster due to forwarding traffic from many sources
- Many-to-One Traffic: Communication pattern where all sensors report to a central sink
- In-Network Processing: Processing data within the network to reduce transmissions
436.3 Why Traditional Routing Fails in WSNs
Traditional network routing protocols like OSPF, BGP, and RIP were designed for wired networks with fundamentally different characteristics. When applied to WSNs, they fail for several critical reasons.
436.3.1 1. Address-Centric vs Data-Centric
Traditional: Route packets to specific IP addresses. The network cares about where data goes, not what it contains.
WSN: Route data based on content (“temperature > 30°C”). Node addresses may not be globally unique or even available. The network cares about what data contains, not necessarily who sent it.
436.3.2 2. Communication Pattern
Traditional: Peer-to-peer communication. Any node can communicate with any other node.
WSN: Many-to-one (sensors to sink), one-to-many (sink to sensors). Rarely sensor-to-sensor communication. This asymmetric pattern creates unique challenges.
436.3.3 3. Energy Constraints
Traditional: Minimize latency, maximize throughput. Routers are mains-powered with abundant resources.
WSN: Minimize energy consumption to extend lifetime. Sensors run on batteries for years. The shortest path may not be energy-optimal if it creates energy hotspots.
436.3.4 4. Scale and Density
Traditional: Hundreds to thousands of nodes with relatively sparse connectivity.
WSN: Potentially thousands to millions of nodes with high density. This density enables in-network processing but creates routing table overhead challenges.
436.3.5 5. Node Failures
Traditional: Relatively rare failures trigger rerouting procedures.
WSN: Common failures due to energy depletion. Nodes can’t always be replaced. Routing must be robust to frequent topology changes.
436.4 Routing Requirements in WSNs
Given these challenges, WSN routing protocols must meet specific requirements:
436.4.1 Energy Efficiency
- Minimize transmission energy: Radio transmission dominates energy consumption
- Balance load across nodes: Avoid creating energy hotspots near the sink
- Consider residual energy: Route through nodes with higher remaining battery
436.4.2 Scalability
- Handle large numbers of nodes: Protocols must scale to thousands of nodes
- Localized algorithms preferred: Avoid global state that requires flooding
- Avoid flooding where possible: Use directed or hierarchical approaches
436.4.3 Data Aggregation
- Combine data from multiple sensors: Reduce redundant transmissions
- In-network processing: Aggregate before forwarding to reduce traffic
- Maintain data accuracy: Balance compression with information preservation
436.4.4 Robustness
- Adapt to node failures: Continue operation when nodes die
- Handle dynamic topology changes: Accommodate node mobility and failures
- Graceful degradation: Maintain partial functionality under stress
436.4.5 Quality of Service
- Latency bounds for time-critical applications: Fire alarms, industrial safety
- Reliability for critical data: Guaranteed delivery for important events
- Bandwidth allocation: Fair resource distribution
436.5 Illustrative Examples
436.6 Knowledge Check
Test your understanding of WSN routing challenges.
436.7 Common Pitfalls
CautionPitfall: Running Data Aggregation Without Time Synchronization
The Mistake: A cluster head aggregates readings from 10 nodes and computes the spatial average. But node clocks differ by 2-8 seconds, so some readings are from the current minute while others are stale. The “aggregated” result mixes temporally inconsistent data, producing meaningless averages.
Why It Happens: Developers focus on spatial aggregation (combining data from nearby nodes) but ignore temporal alignment. Without network-wide time synchronization, each node’s timestamp reflects its local clock. When phenomena change rapidly (temperature rising 2°C/minute during fire), a 5-second timing error introduces 0.17°C measurement error - compounding across aggregated nodes.
The Fix: Implement time synchronization before enabling data aggregation:
- Synchronization protocol: Deploy FTSP (Flooding Time Synchronization Protocol) or TPSN achieving <1 ms accuracy across multi-hop networks
- Sync frequency: Resynchronize every 30-60 seconds for µs-level accuracy, every 5-10 minutes for ms-level (sufficient for most environmental monitoring)
- Aggregation windows: Define explicit time windows for aggregation (e.g., “aggregate all readings with timestamp 10:00:00-10:00:05”). Discard readings outside the window rather than mixing temporal epochs
- Staleness threshold: Set maximum data age for aggregation (e.g., 10 seconds). If node reading is older than threshold, request fresh data or exclude from aggregation
- Timestamp format: Use network-synchronized epoch time, not local elapsed time. Include timestamp in every packet:
{node_id: 5, value: 21.3, timestamp: 1704067200123}
CautionPitfall: Using Hop Count Instead of Link Quality for Route Selection
The Mistake: The routing protocol selects a 2-hop path over a 3-hop path because fewer hops means less energy. But the 2-hop path has 60% packet delivery ratio per link, requiring 2.8 retransmissions per hop on average. The “efficient” route wastes 3x more energy than the longer but reliable path.
Why It Happens: Traditional routing metrics (hop count) assume all links are equal. In WSNs, link quality varies dramatically: a link might work 95% of the time at 10 meters but only 30% at 25 meters. The infamous “gray zone” (intermediate distances) has highly variable, often poor link quality that hop-count metrics ignore.
The Fix: Use Expected Transmission Count (ETX) or link-quality metrics instead of hop count:
- ETX calculation:
ETX = 1 / (forward_delivery × reverse_delivery). For a link with 80% forward and 90% reverse delivery: ETX = 1/(0.8×0.9) = 1.39 expected transmissions - Path comparison:
- Path A (2 hops, poor links): ETX = 1/(0.6×0.6) + 1/(0.6×0.6) = 2.78 + 2.78 = 5.56 total
- Path B (3 hops, good links): ETX = 1/(0.95×0.95) + 1/(0.95×0.95) + 1/(0.95×0.95) = 1.11 × 3 = 3.33 total
- Path B saves 40% energy despite being longer!
- Link quality estimation: Sample at least 20-50 packets over 5+ minutes before calculating stable ETX. Use WMEWMA smoothing:
ETX_new = 0.9 × ETX_sample + 0.1 × ETX_old - Gray zone avoidance: If measured PRR is between 10-90%, consider the link unreliable. Prefer links with PRR > 90% or < 10% (clearly good or clearly avoid)
436.8 Summary
This chapter explored why traditional routing protocols are unsuitable for WSNs and what requirements WSN-specific protocols must meet:
Key Takeaways:
- Traditional Routing Fails: Address-centric, peer-to-peer protocols ignore energy constraints and data semantics
- Five Key Differences: Addressing (data vs address), pattern (many-to-one vs peer-to-peer), goal (energy vs throughput), scale (millions vs thousands), failures (common vs rare)
- Essential Requirements: Energy efficiency, scalability, data aggregation support, robustness, and QoS guarantees
- Common Pitfalls: Time synchronization for aggregation, link quality over hop count
436.9 What’s Next?
The next chapter explores the classification of WSN routing protocols into data-centric, hierarchical, location-based, and QoS-aware categories, with interactive demonstrations.
Continue to WSN Routing Classification →
NoteRelated Chapters
- WSN Routing Introduction - Fundamental concepts and overview
- WSN Routing Classification - Protocol categories and tradeoffs
- WSN Routing: Directed Diffusion - Data-centric routing example
- WSN Routing: Link Quality - RSSI, WMEWMA, and MIN-T metrics