721  RPL Knowledge Check

721.1 Learning Objectives

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

  • Apply RPL Mode Selection: Choose between Storing and Non-Storing modes based on real-world deployment scenarios
  • Analyze Traffic Patterns: Evaluate how different traffic types affect RPL performance
  • Understand Trickle Timer: Explain how adaptive DIO transmission balances responsiveness with energy efficiency
  • Diagnose Routing Issues: Identify common RPL problems and their solutions

721.2 Prerequisites

Required Chapters:

Estimated Time: 30 minutes

What is this chapter? Scenario-based quizzes that test your RPL understanding through realistic deployment situations.

How to approach: 1. Read each scenario carefully 2. Consider all factors before choosing 3. Expand the explanation to learn from the detailed analysis 4. Relate the scenario to your own projects

721.3 Knowledge Check

Test your understanding of RPL concepts through real-world scenarios.

Scenario: You’re deploying a patient monitoring system across a 300-bed hospital with 1,200 wireless sensors (vital signs, room environment, equipment tracking).

Network Requirements: - 1,000 sensors send readings to cloud every 2 minutes (many-to-one: sensors to gateway to cloud) - 200 infusion pumps occasionally receive dosage updates from nurse stations (one-to-many: cloud to gateway to specific pump) - Nurse call buttons need point-to-point: Room 302 button to Nursing station display (10-20 events/day per floor)

RPL Mode Comparison:

Mode Memory/Node Many-to-One One-to-Many Point-to-Point
Storing 50-100 bytes Excellent Excellent Excellent
Non-Storing 2 bytes Excellent Good (adds header) Poor (via root)

Analysis: 1. Many-to-one (sensors to cloud): Both modes identical. Uses parent pointers only. 2. One-to-many (cloud to pumps): 200 pumps/day get updates - Storing: Direct path, 2-hop average - Non-Storing: Source routing through root, 2-hop average + 10-byte routing header - Impact: 200 x 10 bytes/day = 2 KB/day extra. Negligible. 3. Point-to-point (nurse call buttons): 20 events/day across 6 floors - Storing: Room 302 to Floor router to Nursing station (2 hops, optimal) - Non-Storing: Room 302 to … to Root to … to Nursing station (4+ hops through root, suboptimal) - Impact: 2x latency for urgent nurse calls!

The Decision: Use Storing mode because: - Point-to-point nurse calls need low latency (medical emergency response) - Memory overhead (50-100 bytes) is trivial on mains-powered sensors - Avoids root bottleneck for 120 daily P2P events

Real-World Gotcha: Engineer initially chose Non-Storing (“saves memory!”) but discovered nurse call latency increased from 200ms to 800ms because packets routed through root on different floor. After complaints from nursing staff, switched to Storing mode.

Key Lesson: Non-Storing is not universally better despite lower memory. Choose based on traffic pattern: - 95%+ many-to-one: Non-Storing works great - Significant P2P traffic: Storing pays off - Mixed traffic with latency requirements: Storing is safer

Question 1: A smart building has 100 temperature sensors reporting to a central gateway every 5 minutes, and occasionally the gateway sends configuration updates to individual sensors. Which RPL mode is most appropriate?

Explanation: Non-Storing mode is ideal for primarily many-to-one traffic (sensors to gateway). While configuration updates are downward, they’re infrequent and can tolerate the slightly higher latency of source routing through the root. Non-Storing mode saves ~40% memory network-wide and scales better (limited by root capacity, not individual node memory). Storing mode would be overkill unless downward/P2P traffic was frequent and latency-critical.

Question 2: A smart building uses RPL with 80 nodes in Storing mode. The network has been stable for 2 hours. Suddenly, 15 new nodes join simultaneously. What happens to the DIO transmission pattern?

Explanation: RPL’s trickle timer algorithm adaptively balances network stability with responsiveness:

Normal operation (stable network): - Trickle interval exponentially increases: 1s to 2s to 4s to 8s to … to maximum (e.g., 1 hour) - Nodes rarely transmit DIOs, saving energy

When new nodes join: 1. New nodes send DIS (DODAG Information Solicitation) to request DODAG info 2. Nodes receiving DIS reset their trickle timer to minimum interval 3. These nodes send DIO messages more frequently 4. New nodes receive DIOs, join DODAG, and select parents 5. As network stabilizes, trickle intervals increase again

This is localized - only nearby nodes reset timers, not the entire network. The trickle algorithm detects “inconsistency” (new nodes, topology changes) and automatically increases DIO frequency. Once consistent, it backs off exponentially. Result: Fast joining for new devices without constant overhead in stable networks.

Question 3: What is the primary purpose of RANK in RPL?

Explanation: B. RANK represents a node’s position in the DODAG. Upward forwarding chooses parents with lower RANK, and parent selection rules prevent “moving away” from the root, which helps avoid loops.

Question 4: When a new RPL node joins a network and needs DODAG information, which control message does it typically send to solicit nearby routers to respond?

Explanation: C. New nodes send DIS to request DODAG configuration. Neighbors respond with DIO, which helps the joining node select parents and join the topology.

721.4 Scenario Analysis: Industrial Deployment

Scenario: Manufacturing plant with 500 sensors monitoring equipment vibration, temperature, and energy consumption.

Requirements: - Sensors report every 10 seconds (6 readings/minute each) - 95% of traffic is sensor-to-cloud (many-to-one) - 5% is cloud-to-sensor commands (predictive maintenance alerts) - Latency for alerts: < 500ms required

Question: Should you use Storing or Non-Storing mode?

Analysis Factors:

Factor Storing Non-Storing
Memory per sensor 50-100 bytes 2 bytes
Many-to-one latency ~50ms ~50ms
Cloud-to-sensor latency ~50ms ~100ms (via root)
Network overhead Higher (distributed tables) Lower

Decision Process: 1. Traffic pattern: 95% many-to-one - favors Non-Storing 2. Alert latency: 100ms via root still meets < 500ms requirement 3. Sensor constraints: Industrial sensors often have 256KB+ RAM 4. Scale: 500 nodes - Non-Storing centralizes state efficiently

Recommendation: Non-Storing mode because: - Dominant many-to-one traffic performs identically - 100ms alert latency meets 500ms SLA with margin - Simplified sensor firmware (no routing tables) - Easier network management (all routes visible at root)

When to reconsider: - If sensors need to communicate directly (P2P vibration correlation) - If alert latency SLA tightens to < 100ms - If network partitions require local routing autonomy

721.5 Summary

These scenario-based quizzes reinforced critical RPL design decisions:

  • Mode Selection: Traffic pattern analysis drives the Storing vs Non-Storing choice, not just memory constraints
  • Trickle Timer: RPL’s adaptive algorithm balances fast convergence with energy efficiency through localized resets
  • RANK Purpose: Loop prevention through hierarchy, not physical distance or encryption
  • Control Messages: DIS solicits DODAG info, DIO advertises it, DAO builds downward routes

721.5.1 Decision Framework

Use this quick reference when designing RPL networks:

If your network has… Prefer… Because…
95%+ many-to-one Non-Storing Identical performance, lower memory
Frequent P2P traffic Storing Avoids root bottleneck
Latency-critical downward Storing Direct routing paths
Memory-constrained sensors Non-Storing 2 bytes vs 50-100 bytes
100+ nodes Non-Storing Centralized state scales better

721.6 What’s Next

Continue to RPL Quiz Questions for detailed concept review with comprehensive explanations, or return to RPL Labs and Quiz Overview to explore other RPL learning resources.