725 RPL Production Scenarios and Knowledge Checks
725.1 Learning Objectives
By the end of this chapter, you will be able to:
- Apply Mode Selection: Choose between Storing and Non-Storing modes for specific deployments
- Calculate Routing Overhead: Determine source routing header overhead percentages
- Compare Objective Functions: Evaluate OF0 vs MRHOF for different network conditions
- Configure Trickle Timers: Understand adaptive DIO transmission mechanisms
725.2 Prerequisites
Required Chapters:
- RPL Production Framework - Framework architecture
- RPL Fundamentals - Core RPL concepts
- RPL Operation - DODAG mechanics
Estimated Time: 30 minutes
What is this chapter? This chapter provides hands-on knowledge checks and real-world deployment scenarios to test and apply your RPL understanding.
Difficulty: Advanced
How to use these scenarios:
- Read the deployment context carefully
- Try to answer each question before revealing the solution
- Study the detailed explanations to deepen understanding
- Apply these patterns to your own deployment planning
Topics Covered:
| Scenario | Focus Area |
|---|---|
| Smart City Streetlights | Mode Selection |
| Industrial Sensor Network | Objective Functions |
| Smart Building | Trickle Timer Dynamics |
725.3 Knowledge Check
Test your understanding of production RPL deployment through real-world scenarios.
Question: In large deployments, what is typically the primary scalability bottleneck of RPL Storing Mode on constrained routers?
Explanation: B. Storing Mode distributes downward routing state across intermediate nodes; sub-tree route tables can exceed available RAM as the network grows.
Question: In RPL Non-Storing Mode, at steady state, how many routing table entries does a typical sensor node maintain for downward routes?
Explanation: C. Non-Storing Mode centralizes downward routing state at the root; nodes forward downward packets using the source routing header.
Question: A downward command uses IPv6 RH3 source routing with 8 bytes per hop. For a 5-hop path and a 200-byte payload, what is the source-routing overhead percentage?
Explanation: D. Header = 5 x 8 = 40 bytes; total = 200+40 = 240; overhead = 40/240 = 16.7%.
Question: Which RPL objective function commonly uses ETX (Expected Transmission Count) to choose more reliable paths (with hysteresis to reduce churn)?
Explanation: A. MRHOF minimizes a path cost (often ETX-based) and includes hysteresis to avoid frequent parent switches.
725.4 Scenario 1: Smart City Streetlight Network - Mode Selection
Deployment Context:
A smart city deploys 800 streetlight sensors across 20 city blocks for monitoring:
- Traffic pattern: Light level, traffic count, environmental data every 30 seconds to gateway (upward dominant)
- Sensor constraints: 64KB RAM, battery backup (solar primary)
- Network depth: 5-7 hops typical for multi-block urban deployment
- Downward traffic: Occasional firmware updates (once per month to 10-50 sensors)
- Gateway resources: x86 Linux gateway with 1GB+ RAM
Question 1: What is the PRIMARY scalability bottleneck for Storing Mode in this 800-node deployment?
Consider the memory requirements at different DODAG levels. A router 3 hops from the root might have 100-200 descendant nodes in its sub-tree.
Click to reveal answer
Answer: Intermediate router memory capacity (64KB insufficient for sub-tree routing tables)
Memory Analysis:
- Mid-level router (3 hops from root) with 100-200 descendants requires:
- 100 routes x 100 bytes per route = 10-20 KB routing table
- Additional memory for: Application code, 6LoWPAN fragmentation buffers, OS, parent selection state
- Total memory pressure: 30-40 KB minimum, leaving only 24-34 KB for everything else
- Typical Storing Mode capacity: 100-300 nodes depending on topology depth
- This deployment: 800 nodes exceeds practical Storing Mode limits with 64KB sensors
Question 2: Non-Storing Mode is selected. Calculate the source routing overhead for downward firmware updates.
- Typical path: 5 hops from root to sensor
- IPv6 Routing Header Type 3 (RH3): 8 bytes per hop
- Firmware update command: 200 bytes
- What percentage is overhead?
Click to reveal answer
Calculation:
- Source routing header: 5 hops x 8 bytes/hop = 40 bytes
- Total packet: 200 bytes (payload) + 40 bytes (RH3 header) = 240 bytes
- Overhead percentage: 40 / 240 = 16.7%
Trade-off Assessment:
- Acceptable for infrequent downward traffic: Firmware updates once per month = <1% of total traffic
- Upward traffic (99% of traffic): NO source routing overhead - standard IPv6 headers only
- Memory savings: 64KB sensors use <10KB for RPL (no routing tables), leaving 50KB+ for application
- Root capacity: Gateway stores 800-node routing table (~80KB) easily within 1GB RAM
Question 3: At steady state, how many routing table entries does each sensor maintain in Non-Storing Mode?
Click to reveal answer
Answer: Zero (0) routing table entries per sensor
Non-Storing Mode Routing:
- Upward routing: Each sensor stores only its preferred parent and backup parent set (2-4 parent pointers, not routing tables). To send upward, sensor forwards packet to preferred parent. No route lookup needed.
- Downward routing: Root constructs source routing header (IPv6 RH3) specifying complete path. Intermediate sensors simply forward based on header, no routing decision.
- Memory at sensor: ~5-10 KB for RPL protocol state (parent selection, RANK calculation, control messages)
- Memory at root: 800 routes x 100 bytes = 80 KB (centralized)
Comparison:
- Storing Mode: Each sensor stores routes for its sub-tree (10-20 KB for 100-200 descendants)
- Non-Storing Mode: Each sensor stores 0 routes (parent pointers only)
- Network-wide memory savings: ~40% reduction with Non-Storing Mode
725.5 Scenario 2: Industrial Sensor Network - Objective Function Selection
Deployment Context:
An industrial monitoring network tracks machine health in a factory with high RF interference:
- Network conditions: 20% average packet loss, varies by zone (15-30%)
- Node discovery: Node C identifies two potential parents during DODAG construction
- Parent 1: RANK 3 (3 hops to root), ETX 1.5, RSSI -75 dBm
- Parent 2: RANK 4 (4 hops to root), ETX 1.2, RSSI -68 dBm
- Requirements: Reliable data delivery critical, latency less critical (5-second reports acceptable)
- Objective Function: MRHOF (Minimum Rank with Hysteresis) configured with ETX metric
Question 1: Which parent should Node C select using MRHOF with ETX metric, and why?
Consider that MRHOF optimizes for minimum path cost based on the configured metric (ETX), not simply minimum hop count.
Click to reveal answer
Answer: Parent 2 (RANK 4, ETX 1.2) should be selected
ETX Analysis:
- ETX (Expected Transmission Count) measures link reliability: ETX = 1 / (1 - packet_loss_rate)
- Parent 1 ETX 1.5 corresponds to ~33% packet loss (1.5 = 1 / (1 - 0.33))
- Parent 2 ETX 1.2 corresponds to ~17% packet loss (1.2 = 1 / (1 - 0.17))
- Parent 2 has 50% better link quality despite being 1 hop farther
Path Cost Calculation:
- MRHOF calculates cumulative path cost = parent’s path cost + link cost
- Parent 1 might offer lower latency (3 hops vs 4 hops), but higher cumulative retransmissions
- Parent 2’s superior link quality (ETX 1.2 vs 1.5) compensates for extra hop
- Reliability prioritized over latency in MRHOF with ETX metric
Question 2: Compare OF0 vs MRHOF for this industrial scenario. What would OF0 select, and what’s the consequence?
OF0 (Objective Function Zero) uses simple hop count minimization. How would Node C’s parent selection differ?
Click to reveal answer
OF0 Selection: Parent 1 (RANK 3) - minimum hop count (3 hops vs 4 hops)
Consequences of OF0 Selection:
Reliability Impact:
- Parent 1 (ETX 1.5): Requires 1.5 transmissions on average per packet
- Over 100 packets: 50 packets require retransmission
- Lost data: Higher probability of exceeding retry limits, losing critical machine health alerts
Energy Impact:
- Retransmissions: 1.5x transmissions vs 1.2x (25% more radio-on time)
- Battery-powered sensors: 25% faster battery drain with Parent 1
Latency Paradox:
- Expected latency: OF0 assumes 3 hops < 4 hops
- Actual latency with retransmissions: 3 hops x 1.5 retries = 4.5 effective hops
- Parent 2 actual latency: 4 hops x 1.2 retries = 4.8 effective hops
- Minimal difference, but Parent 1 has higher latency variance (unpredictable due to retries)
When OF0 is Appropriate:
- Low packet loss environments (<5% loss): Link quality differences negligible
- Latency-critical applications: Minimize hops when links are reliable
- Homogeneous networks: All links have similar quality
When MRHOF is Appropriate (this scenario):
- Lossy environments (10-40% loss typical in wireless sensor networks)
- Reliability-critical: Machine health, safety monitoring
- Heterogeneous links: Varying RF conditions (interference, distance, obstacles)
Question 3: MRHOF uses hysteresis to prevent rapid parent switching. What problem does this solve?
Imagine Node C’s link quality to both parents fluctuates due to intermittent RF interference. Without hysteresis, what happens?
Click to reveal answer
Problem: Route flapping (rapid, repeated parent switches)
Without Hysteresis:
- Time T0: Parent 2 has ETX 1.2, selected as preferred parent
- Time T1 (30 seconds later): Brief interference increases Parent 2 ETX to 1.25, Parent 1 now better (ETX 1.24)
- Node C switches to Parent 1, sends new DAO messages, updates routing
- Time T2 (1 minute later): Interference clears, Parent 2 ETX returns to 1.2
- Node C switches back to Parent 2, sends new DAO messages again
- Repeat every few minutes: Continuous switching, control message overhead, routing instability
With Hysteresis:
- Threshold configured: New parent must be X% better (e.g., 10% improvement threshold)
- Time T1: Parent 1 ETX improves to 1.24, but 1.24/1.25 = 99.2% (only 0.8% better)
- Below threshold: Node C stays with Parent 2 despite slight metric improvement
- Prevents switch unless sustained, significant improvement detected
Hysteresis Configuration:
- Typical values: 5-15% improvement required to trigger parent switch
- Higher hysteresis (15%): More stable, slower to adapt to topology changes
- Lower hysteresis (5%): More responsive, risk of flapping in noisy environments
Benefits:
- Reduced control overhead: Fewer DAO messages (downward route updates)
- Stable paths: Applications see consistent latency, fewer reorderings
- Lower energy: Parent switching requires radio-on for control messages
- Network-wide stability: Prevents cascading route changes from small metric fluctuations
725.6 Scenario 3: Smart Building Deployment - Trickle Timer and Network Dynamics
Deployment Context:
A smart building automation system with 200 sensors (HVAC, lighting, occupancy) deployed across 10 floors:
- Stable operation: Network operational for 3 months, minimal topology changes
- Trickle Timer configuration: Imin = 10 ms, Imax = 1 hour (3,600,000 ms)
- Current state: DIOs transmitted every 45-60 minutes during steady state
- Event: 15 new sensors added to Floor 7 during office renovation
- Observation: DIO transmission frequency temporarily increases across Floor 7, then gradually returns to hourly
Question 1: Why does the Trickle Timer increase DIO frequency when new sensors join, and how does it return to steady state?
Consider the exponential backoff mechanism: Imin to 2xImin to 4xImin to … to Imax
Click to reveal answer
Answer: Trickle Timer detects inconsistency (new node joining), resets to Imin, then exponentially backs off to Imax
Steady State Operation (before new sensors):
- Trickle interval: Started at Imin = 10 ms, doubled each interval: 10 ms to 20 ms to 40 ms to 80 ms to … to Imax = 1 hour
- After ~20 doublings: 10 ms x 2^20 = 10,485 seconds = 3 hours (reaches Imax at 1 hour)
- Network consistent: All nodes receiving expected DIOs, no better RANK discovered
- DIO frequency: Every 45-60 minutes (minimal control overhead)
New Sensor Joins Floor 7:
- New sensor powers on, sends DIS (DODAG Information Solicitation) to ff02::1A (all-RPL-nodes multicast)
- Floor 7 routers receive DIS, recognize inconsistency (new node needs DODAG info)
- Routers reset Trickle Timer to Imin = 10 ms
- DIOs sent rapidly: 10 ms, 20 ms, 40 ms, 80 ms… (exponential backoff)
- New sensor receives DIO, calculates RANK, selects parent, joins DODAG
- Network stabilizes: After 30-60 seconds, Floor 7 routers detect consistency (all expected neighbors responding)
- Exponential backoff continues: 160 ms to 320 ms to 640 ms to … to 1 hour
- Return to steady state: After ~10-15 minutes, DIO frequency returns to hourly
Why Localized to Floor 7:
- Inconsistency detection is local: Only routers on Floor 7 detect DIS from new sensors
- Other floors unaffected: Floor 5, 8, 10 routers continue hourly DIOs
- Gradual propagation: If Floor 7’s RANK changes affect Floor 6 neighbors, they might reset timers too
- Spatial containment: Trickle Timer adapts locally to topology changes
Question 2: Calculate the control message overhead during steady state vs during the 15-sensor join event.
Assume 200 existing nodes + 15 new nodes. Each DIO is 80 bytes. Compare hourly overhead vs join period overhead.
Click to reveal answer
Steady State Overhead (before join):
- DIO frequency: 1 DIO per hour per node
- Network size: 200 nodes
- DIOs per hour: 200 DIOs x 80 bytes/DIO = 16,000 bytes/hour = 16 KB/hour
- Bandwidth: Assuming IEEE 802.15.4 at 250 kbps
- Overhead percentage: (16 KB / 3600 seconds) / (250 kbps / 8) = 0.036 bytes/sec / 31.25 KB/sec = 0.0001% overhead
Join Period Overhead (15 new sensors, 60-second join window):
- Affected routers: ~20 routers on Floor 7 (near new sensors)
- Trickle reset: These 20 routers send DIOs at Imin intervals for 60 seconds
- DIO intervals during join: 10 ms, 20 ms, 40 ms, 80 ms, 160 ms, 320 ms, 640 ms, 1280 ms, 2560 ms…
- Total DIOs per router in 60 seconds:
- 0-10 ms: 1 DIO
- 10-30 ms: 1 DIO
- 30-70 ms: 1 DIO
- 70-150 ms: 1 DIO
- 150-310 ms: 1 DIO
- 310-630 ms: 1 DIO
- 630-1270 ms: 1 DIO
- 1270-2550 ms: 1 DIO
- 2550-5110 ms: 1 DIO
- 5110-10230 ms: 1 DIO
- 10230-20470 ms: 1 DIO
- 20470-40950 ms: 1 DIO
- 40950-60000 ms: Partial (1 DIO)
- Total: ~13 DIOs per router in 60 seconds
- Total DIOs: 20 routers x 13 DIOs = 260 DIOs x 80 bytes = 20,800 bytes in 60 seconds = 20.8 KB
- Overhead percentage during join: (20.8 KB / 60 seconds) / 31.25 KB/sec = 0.347 KB/sec / 31.25 KB/sec = 1.1% overhead
New Sensors (DIS + initial DIOs):
- 15 new sensors each send 1 DIS (80 bytes) = 1,200 bytes
- 15 new sensors receive ~13 DIOs during join = 15 x 13 x 80 bytes = 15,600 bytes
- New sensor contribution: 1,200 + 15,600 = 16,800 bytes
Total Join Overhead:
- Existing routers: 20,800 bytes
- New sensors: 16,800 bytes
- Total: 37,600 bytes in 60 seconds = 37.6 KB
- Overhead: 1.1% of bandwidth for 60 seconds
Comparison:
- Steady state: 0.0001% overhead (negligible)
- Join period: 1.1% overhead for 60 seconds (acceptable temporary spike)
- Network scales well: Even with 15 simultaneous joins, overhead is <2% for 1 minute
- After join: Exponential backoff returns network to 0.0001% within 15 minutes
Question 3: What happens if the Trickle Timer’s Imax is set too low (e.g., 1 minute instead of 1 hour)?
Consider both control overhead and responsiveness to topology changes.
Click to reveal answer
Answer: Unnecessary control overhead without significant benefit for responsiveness
Configuration Comparison:
Imax = 1 Hour (Standard):
- Steady state DIOs: 1 per node per hour
- 200-node network: 200 DIOs/hour = 16 KB/hour = 0.0001% overhead
- Battery impact: Negligible (1 DIO transmission = ~10-20 uJ, once per hour)
- Responsiveness: New nodes join in 30-60 seconds (determined by Imin and exponential backoff during join, not Imax)
Imax = 1 Minute (Too Low):
- Steady state DIOs: 1 per node per minute (60x more frequent)
- 200-node network: 200 DIOs/minute x 60 minutes = 12,000 DIOs/hour = 960 KB/hour = 0.006% overhead
- Battery impact: 60x more DIO transmissions = 60x faster battery drain for control messages
- 200-node network over 1 year: (10 uJ/DIO x 12,000 DIOs/hour x 8760 hours/year) / 1000 = 1,051,200 mJ = 1,051 Joules per node
- With 2x AA batteries (3000 mAh x 3V = 32,400 J total), control messages consume 3.2% of battery capacity
- Responsiveness improvement: None - new nodes still join in 30-60 seconds (determined by Imin reset during inconsistency, not Imax)
Why No Responsiveness Benefit:
- Trickle Timer resets on inconsistency: When new node sends DIS or better RANK detected, timer resets to Imin (10 ms)
- Join speed determined by Imin: Exponential backoff from Imin (10 ms to 20 ms to 40 ms…) governs how quickly new nodes receive DIOs
- Imax only affects steady state: Once network is stable and no inconsistencies, Imax determines maintenance DIO frequency
- Stable networks need infrequent DIOs: Established parent relationships don’t change unless link fails or better path discovered
When Lower Imax Might Help:
- Highly dynamic topologies: Mobile nodes frequently changing parents (vehicular networks, UAVs)
- Frequent link quality changes: RF environment with rapid interference patterns (not typical in building/industrial)
- Very small networks: 10-20 nodes where DIO overhead is negligible regardless of frequency
Recommended Imax Configuration:
- Static buildings, industrial: Imax = 1 hour (standard)
- Outdoor sensor networks: Imax = 30 minutes (environmental changes)
- Mobile/vehicular: Imax = 5-10 minutes (frequent topology changes)
- Emergency/disaster: Imax = 1-2 minutes (rapid reconfiguration needed)
725.7 Summary
This chapter provided hands-on practice with production RPL deployment scenarios:
- Mode Selection: How to choose Storing vs Non-Storing based on network size and traffic patterns
- Overhead Calculations: Quantifying source routing header overhead and control message costs
- Objective Functions: When to use OF0 (hop count) vs MRHOF (ETX-based) and the impact on reliability
- Trickle Timer Dynamics: Understanding adaptive DIO transmission and Imax configuration
725.8 What’s Next
Continue to RPL Production Summary for comprehensive concepts, key takeaways, and a detailed industrial case study, or return to RPL Production Framework to review architecture concepts.