By the end of this section, you will be able to:
Routing is how data finds its way from one device to another across a network, like a GPS navigation system finding the best route between two cities. In IoT networks, routing is especially challenging because devices often have limited power, the network can change frequently, and some paths may be unreliable.
“Routing in IoT is trickier than in regular networks,” said Max the Microcontroller. “We have three big challenges: limited battery power, unreliable wireless links, and networks that change shape when devices move or go to sleep.”
“In a regular office network, routers are always on and links are stable,” explained Sammy the Sensor. “But in my sensor network, some of us go to sleep to save battery. When I wake up, my neighbor might be asleep! The routing path I used an hour ago might not work anymore.”
Lila the LED brought up link quality. “Wireless links are not like Ethernet cables. Signal strength varies with weather, obstacles, and interference. A path that works perfectly at noon might be terrible at night when temperature changes affect radio propagation.”
“That is why IoT needs special routing protocols like RPL,” said Bella the Battery. “Regular routing protocols like OSPF assume stable links and always-on devices. RPL was designed for our world – it builds routes that adapt to changing conditions, considers battery life when choosing paths, and repairs routes quickly when links fail. IoT routing is a whole different game!”
IoT networks face unique routing challenges that traditional enterprise protocols weren’t designed for:
| Challenge | Traditional Network | IoT Network |
|---|---|---|
| Power | Mains-powered | Battery-powered |
| Links | 99.99% reliable | 70-95% reliable (wireless) |
| Topology | Stable | Dynamic (mobile sensors) |
| Resources | Gigabytes of RAM | Kilobytes of RAM |
| Convergence | Seconds | Minutes (acceptable) |
| Traffic Pattern | Any-to-any | Many-to-one (sensors to gateway) |
Understanding failure modes helps you design resilient systems.
Setup:
Sensor -> Gateway -> Router A -> Router B -> Cloud
|
[FAILS!]Timeline:
T=0s: Router A crashes (power failure)
T=0-10s: Gateway keeps sending packets to Router A
T=10s: Gateway's ARP requests for Router A go unanswered
T=15s: Routing protocol detects Router A is down
T=20s: Protocol floods "Router A unreachable" to all routers
T=25s: Network converges: NO alternate path found
T=30s: Gateway marks route as unreachablePacket Behavior:
Impact:
Prevention: Redundant routers + VRRP (Virtual Router Redundancy Protocol)
Setup:
Sensor -> Gateway -> Router A (FAILS) -> Cloud
\ /
-> Router B --------+OSPF Timeline:
T=0s: Router A crashes
T=10s: Gateway misses hello from Router A
T=40s: OSPF dead interval expires (4x hello = 40s)
T=41s: OSPF floods LSA: "Router A down"
T=43s: All routers recalculate SPF
T=44s: Gateway updates routing table: use Router B
T=44s+: New packets route through Router BImpact:
RPL Convergence (Slower but OK for IoT):
T=0s: Router A fails
T=60s: Neighbors send DIO, no response from A
T=120s: Neighbors detect inconsistency
T=150s: New parent (Router B) selected
T=180s: Traffic flows via Router B
Total outage: 2-3 minutes (acceptable for sensor data)Setup:
Router A says: "To reach Cloud, send to Router B"
Router B says: "To reach Cloud, send to Router C"
Router C says: "To reach Cloud, send to Router A" <- LOOP!What Happens:
Packet Journey:
Sensor sends packet (TTL=64, destination=Cloud)
Hop 1: Gateway -> Router A (TTL=63)
Hop 2: Router A -> Router B (TTL=62)
Hop 3: Router B -> Router C (TTL=61)
Hop 4: Router C -> Router A (TTL=60) <- LOOP!
Hop 5: Router A -> Router B (TTL=59)
...
Hop 64: TTL=0, packet DROPPEDImpact:
Without TTL:
Detection:
$ traceroute cloud.example.com
1 192.168.1.1 (Gateway) 1 ms
2 10.0.0.1 (Router A) 5 ms
3 10.0.0.2 (Router B) 6 ms
4 10.0.0.3 (Router C) 7 ms
5 10.0.0.1 (Router A) 8 ms <- LOOP!Setup:
10 Sensors -> Gateway -> Cloud
|
[POWER FAILURE]What Happens:
Sensor Perspective:
T=0s: Gateway loses power
T=60s: Sensor 1 wakes, sends reading to gateway
T=60s: No ACK from gateway (timeout after 5s)
T=65s: Sensor 1 retries (CoAP exponential backoff)
T=100s: Sensor 1 gives up, stores reading in flash memoryRecovery When Power Returns:
T=3600s: Gateway powers back on
T=3620s: Sensors receive gateway's "I'm alive" message
T=3660s: Sensor uploads 60 minutes of buffered data
T=3720s: All sensors caught upData Loss Analysis:
Downtime: 60 minutes
Sensor interval: 60 seconds
Missed transmissions: 600 total
BUT:
- Sensors buffered data in flash
- Readings uploaded when gateway returned
- ZERO data loss (just delayed)Design Lesson:
The Mistake:
# Router configured with only specific routes
ip route 192.168.1.0/24 via 10.0.0.2
ip route 10.50.0.0/16 via 10.0.0.3
# No default route configured!What Happens:
Sensor tries to reach cloud server at 8.8.8.8:
1. Router checks routing table for 8.8.8.8
2. No match found
3. Packet DROPPED!Real Impact:
The Fix:
# Always add a default route
ip route 0.0.0.0/0 via 192.168.1.1 # IPv4
ip -6 route add ::/0 via 2001:db8::1 # IPv6Best Practice: Always configure default route on edge routers before deploying sensors.
The Mistake:
# Network with 50 routers, all using static routes
# Router 1:
ip route 10.1.0.0/16 via 10.0.0.2
ip route 10.2.0.0/16 via 10.0.0.3
# ... 100+ static routes per routerWhat Goes Wrong:
Configuration Explosion:
50 routers x 100 routes = 5,000 static route entries
Manual configuration time: 16+ hours
Error rate: ~5% (typos, wrong next hops)Topology Change Disaster:
Static routing failover:
1. Router 15 fails at 10:00 AM
2. Admin gets alert at 10:05 AM
3. Admin manually updates 20 routers
4. Total downtime: 90+ minutes
Dynamic routing (OSPF) failover:
1. Router 15 fails
2. OSPF dead interval expires (40 seconds)
3. LSA flood + SPF recalculation (~4 seconds)
4. Total downtime: ~44 secondsThe Fix:
The Mistake:
# Developer assumes default TTL=64 is enough
def send_data(payload):
packet = create_packet(payload)
send_packet(packet) # TTL=64 by defaultThe Problem:
Deep Mesh Scenario:
Sensor -> 10 mesh hops -> Gateway -> 5 internet hops -> Cloud
Total hops: 15 (seems fine with TTL=64)
During convergence (routing loop):
Packet loops for 50 hops before path stabilizes
TTL: 64 - 50 = 14 remaining
Then 15 hops to cloud: 14 - 15 = DROPPED!The Fix:
# Increase TTL for mesh networks
import socket
sock = socket.socket(socket.AF_INET6, socket.SOCK_DGRAM)
sock.setsockopt(socket.IPPROTO_IPV6, socket.IPV6_UNICAST_HOPS, 128)Best Practice:
The Mistake:
Network deployed without route monitoring.
Routing protocol configured correctly.
BUT: No monitoring for route changes.What Happens Silently:
Unstable Link Scenario:
Router A <-> Router B link quality varies:
- 08:00: Link up
- 08:15: Link down (interference)
- 08:20: Link up
- 08:35: Link down
(Flaps 50 times per day)Hidden Costs:
Every link flap triggers:
1. OSPF detects change (40s)
2. LSA flood to all routers
3. SPF recalculation on all routers
4. Routing table update
50 flaps/day x 48s = 40 minutes of daily instability!The Fix:
# Monitor route changes
router ospf 1
log-adjacency-changes detail
# Alert on excessive changes
rate(ospf_route_changes[5m]) > 10 # Alert if >10 changes/5minRoot Causes:
The Mistake:
Developer assumes:
"If packets go Sensor -> Router A -> Cloud,
then responses go Cloud -> Router A -> Sensor"
WRONG!Reality:
Asymmetric Routing Example:
Forward path (Sensor -> Cloud):
Sensor -> Router A (10ms) -> ISP1 -> Cloud
Total: 3 hops, 25ms
Return path (Cloud -> Sensor):
Cloud -> ISP2 -> Router B -> Router A -> Sensor
Total: 4 hops, 45ms (different path!)When This Breaks:
Stateful Firewall Issue:
Firewall on Router A expects symmetric routing:
Forward: Sensor -> Router A (firewall) -> Cloud
- Firewall creates state entry
Return: Cloud -> Router B (bypasses firewall!) -> Sensor
- Firewall never sees return packet
- Future packets blocked!The Fix:
The Mistake:
Single IoT gateway handles:
- 1,000 sensors sending data
- Routing for entire mesh network
- Data aggregation
- Protocol translation (LoRaWAN -> MQTT)
- TLS encryptionWhat Happens:
Resource Exhaustion:
Gateway specs:
- CPU: 1.2 GHz quad-core ARM
- RAM: 1 GB
Load:
- Routing table lookups: 10,000/sec
- Data aggregation: 15% CPU
- TLS encryption: 30% CPU
- Total: 70% CPU at baseline
During peak (all sensors wake simultaneously):
- CPU: 100% saturated
- Packet drops: 40%
- Latency: 500ms -> 5000msThe Fix:
Hierarchical Routing:
Before: 1 Gateway handles 1,000 sensors (3,000 routes)
After: 10 Sub-gateways, each handles 100 sensors (300 routes each)
Main gateway handles 10 sub-gateways (10 routes)
Route lookups reduced by 99.7%!Best Practice:
The Mistake:
Network uses RIP routing protocol
Topology changes frequently
RIP update interval: 30 secondsThe Problem:
RIP Convergence:
T=0s: Link fails
T=30s: Router misses expected RIP update
T=60s: Router misses 2nd update
T=90s: Router misses 3rd update
T=180s: Router declares route invalid (invalid timer = 6x update interval)
T=180s: Router enters holddown (180s)
T=360s: Router removes route (flush timer)
Total convergence: up to 6 minutes!Impact on IoT:
During 6-minute convergence:
- Sensor sends every 60s
- 6 packets routed to DEAD link
- 100% packet loss for 6 minutes
- Sensor battery wasted on retriesThe Fix:
Protocol Summary:
| Protocol | Best For | Convergence | Energy | Complexity |
|---|---|---|---|---|
| Static | Small, stable networks (<10 nodes) | Instant | Zero | Low |
| RPL | Battery-powered IoT mesh (Zigbee, Thread) | Minutes | Minimal | Medium |
| OSPF | Enterprise IoT with latency needs | Seconds (with BFD/fast timers) to ~44s (default) | High | High |
| AODV | Mobile ad-hoc networks | Variable | Medium | Medium |
Scenario: A vineyard deploys 200 soil moisture sensors across 50 hectares (500m x 1000m). Sensors are battery-powered (AA lithium, 3,000 mAh) with 802.15.4 radios (250 kbps, 100m range in open field). Terrain includes gentle hills blocking some line-of-sight paths. Each sensor transmits a 20-byte reading every 15 minutes to a solar-powered gateway at the vineyard office. The network must operate for 3 growing seasons (18 months) without battery replacement. Choose the routing protocol and configuration.
Step 1: Evaluate Candidate Protocols
| Protocol | Control Overhead | Memory per Node | Convergence | Link-Loss Handling |
|---|---|---|---|---|
| Static routing | 0 bytes/day | 50 bytes (1 route) | N/A – no adaptation | None – path failure = data loss |
| RIP (distance-vector) | ~14,400 bytes/day (30s updates) | 200 bytes (routing table) | 3-5 minutes | Slow – count to infinity risk |
| OSPF (link-state) | ~2,400 bytes/day (hello packets) | 8-50 KB (topology database) | 1-44 seconds (timer-dependent) | Fast – but floods on every change |
| RPL (LLN-optimized) | ~200-800 bytes/day (Trickle-controlled) | 200-500 bytes | 10-60 seconds | Adaptive – Trickle ramps up on change |
Why not static routing? With 200 sensors over hilly terrain, some sensors are 5-8 hops from the gateway. If any intermediate node fails (dead battery, wildlife damage), all downstream sensors lose connectivity. Over 18 months, expect 5-10 node failures – static routing would require manual reconfiguration each time.
Why not OSPF? OSPF’s topology database requires 8-50 KB of RAM per node. The 802.15.4 MCUs in this deployment have 10 KB total RAM. OSPF also floods link-state advertisements on every topology change – with 200 nodes and seasonal interference variations, this flooding would drain batteries within weeks.
Step 2: RPL Configuration for the Vineyard
| Parameter | Value | Rationale |
|---|---|---|
| Objective Function | MRHOF (Minimum Rank with Hysteresis) using ETX | Accounts for link quality variations from weather and foliage |
| DIO minimum interval | 4 seconds | Fast initial convergence when network first powers on |
| DIO maximum interval | ~17 minutes (2^10 x 1s) | Trickle timer stabilizes; minimal overhead when topology is stable |
| Mode | Non-Storing | Sensors have limited RAM; let the gateway maintain all routes |
| Maximum RANK | 8 hops | 500m x 1000m field with 100m range = max 10 hops; set limit at 8 to prevent inefficient paths |
Step 3: Battery Life Estimation with RPL
Daily data transmissions:
Readings: 96/day x 20 bytes = 1,920 bytes
Multi-hop relay: Average node relays for ~3 neighbors = 5,760 bytes
Total data: 7,680 bytes/day
Daily RPL control overhead (stable network):
DIO messages: ~4/day x 40 bytes = 160 bytes (Trickle-suppressed)
DAO messages: ~2/day x 30 bytes = 60 bytes
Total control: ~220 bytes/day
Radio energy per day:
TX: (7,900 bytes x 8 bits) / 250,000 bps = 253 ms at 17.4 mA = 1.22 uAh
RX (listen windows): ~500 ms/day at 19.7 mA = 2.74 uAh
Sleep: 86,399 s at 1 uA = 24.0 uAh
Total: 27.96 uAh/day
Battery life: 3,000,000 uAh / 27.96 uAh = 107,296 days = 294 years (theoretical)Even accounting for battery self-discharge (1% per year for lithium), real-world battery life exceeds 10 years – comfortably surpassing the 18-month target.
Step 4: Failure Recovery Test
What happens when node 47 (a relay for 12 downstream sensors) fails after 6 months?
| Phase | RPL Behavior | Time |
|---|---|---|
| Detection | Children of node 47 stop receiving DIO; Trickle timer resets to minimum (4s) | 0-17 minutes |
| Parent switch | Affected nodes select new parents with next-best ETX | 4-30 seconds after detection |
| Route repair | DAO messages propagate new paths to gateway | 2-10 seconds |
| Data resumes | Buffered readings transmitted via new route | Immediate |
| Total outage | Worst case: 17 minutes (Trickle max) + 40 seconds (repair) | ~18 minutes |
Key Insight: RPL’s Trickle timer creates a trade-off between energy efficiency and failure detection speed. In stable periods, Trickle suppresses most control messages (saving battery). When a failure occurs, the maximum detection delay equals the Trickle maximum interval. For this vineyard, 17 minutes of data loss per failure event over 18 months is acceptable – the soil moisture changes slowly enough that a brief gap is invisible in trend analysis.
How much energy does RPL’s ETX-aware routing save compared to hop-count routing in a vineyard sensor network? Consider a subset of the vineyard: 200 sensors total, but 10 are behind trellis wires with poor link quality. Each uses an AA battery (2,700 mAh x 1.5 V = 14.6 kJ) with a 10-year target lifespan.
Hop-count routing (shortest path, ignores link quality) – per sensor: - Sensor behind weak trellis wire link (ETX = 4.0) - 100 packets/day x 4.0 average transmissions per packet = 400 transmissions/day - TX energy: 50 mW x 20 ms = 1 mJ per transmission - Daily TX energy: \(400 \times 1 = 400\text{ mJ} = 0.4\text{ J/day per sensor}\)
ETX-aware routing (RPL with MRHOF) – per sensor: - Routes around weak link via 1-hop detour through good links (ETX = 1.2) - 100 packets/day x 2 hops x 1.2 retries = 240 transmissions/day - Daily TX energy: \(240 \times 1 = 240\text{ mJ} = 0.24\text{ J/day per sensor}\)
Savings per sensor: \(0.4 - 0.24 = 0.16\text{ J/day}\)
10-year battery impact (per sensor): - Hop-count: \(0.4 \times 365 \times 10 = 1{,}460\text{ J}\) TX energy over 10 years = 10% of battery capacity (14.6 kJ) - ETX-aware: \(0.24 \times 365 \times 10 = 876\text{ J}\) TX energy = 6% of capacity - Savings: 584 J per sensor (4% of battery) over 10 years – a meaningful margin in deployments where sleep current and other overhead consume additional energy
Economic perspective (10 affected sensors): Total savings of 5,840 J across the group reduces the risk of early battery replacement. At $50 per sensor (battery + labor), avoiding even a few replacements saves the vineyard hundreds of dollars over the deployment lifetime.
OSPF, BGP, and RIP are designed for always-on, high-bandwidth routers with large memory. Running these on constrained IoT devices exceeds RAM, CPU, and battery budgets. Use RPL or similar LLN-specific protocols.
IoT radio links are often asymmetric — a packet sent from A to B may succeed while B-to-A fails due to power differences or obstructions. RPL accounts for this; simpler protocols may not.
RPL’s Storing Mode (Mode 2) optimizes P2P and MP2P patterns; Non-Storing Mode (Mode 1) routes everything through the root. Mismatching mode to traffic pattern wastes energy and bandwidth.
| Previous: Packet Switching | Next: End-to-End Connectivity |
| If you want to… | Read this |
|---|---|
| Learn RPL in depth | RPL Overview |
| Understand DODAG construction | RPL DODAG Construction |
| Explore 6LoWPAN integration with RPL | 6LoWPAN and RPL |
| Practice with routing simulations | Routing Lab: Advanced |
Continue to End-to-End Connectivity to understand the complete picture of IoT connectivity requirements and see worked examples of configuring routes.