38 RPL Traffic & Network Design
Learning Objectives
By the end of this section, you will be able to:
- Differentiate upward, downward, and point-to-point routing paths in RPL DODAGs
- Design RPL network topologies for specific IoT deployment scenarios
- Calculate memory requirements for Storing vs Non-Storing modes using routing entry sizes
- Evaluate traffic patterns to select appropriate RPL configurations and mode trade-offs
- Apply RPL design principles to real-world smart building network architectures
For Beginners: RPL Traffic and Network Design
This chapter explores how different traffic patterns (sensor data flowing up, commands flowing down, device-to-device messages) affect RPL network design. Think of it like designing a road system – rush hour traffic heading downtown requires different planning than weekend traffic heading to the suburbs.
Sensor Squad: Three Ways to Talk!
“RPL handles three different traffic patterns,” said Sammy the Sensor. “The first one is Many-to-One – that is us sensors sending data upward to the root. It is the easiest because the DODAG tree is designed for exactly this direction!”
“The second is One-to-Many,” explained Max the Microcontroller. “That is when the root needs to send commands DOWN to specific devices – like telling a smart light to dim to 50 percent. This requires downward routes, which means DAO messages need to have registered reachability first.”
“The trickiest is Point-to-Point,” added Lila the LED. “If a motion sensor wants to talk directly to a light switch, the message has to go UP the tree to their common ancestor and then back DOWN. In Non-Storing mode, it goes all the way up to the root first!”
“When designing a network, you need to think about which pattern dominates,” said Bella the Battery. “A sensor-only network is mostly Many-to-One, so Non-Storing mode works great. But a smart home with sensors AND actuators needs lots of downward traffic, so Storing mode might be better despite using more memory.”
38.1 Prerequisites
Before diving into this chapter, you should be familiar with:
- RPL Introduction and Core Concepts: Understanding DODAG topology, RANK mechanism, and why RPL is needed for IoT
- RPL DODAG Construction and Modes: Knowledge of how DODAGs are built and the differences between Storing and Non-Storing modes
Key Concepts
- MP2P (Multipoint-to-Point): RPL’s dominant traffic pattern: many sensors sending data toward the DODAG root (border router); optimized by the default DODAG upward routing structure.
- P2MP (Point-to-Multipoint): Traffic pattern from the root to many leaf nodes; requires Storing Mode downward routing or source routing in Non-Storing Mode.
- P2P (Point-to-Point): Device-to-device traffic within the DODAG; in Non-Storing Mode, all P2P traffic routes through the root; Storing Mode allows more direct paths.
- Traffic Engineering: The process of planning and configuring RPL routing to efficiently handle expected traffic patterns while meeting latency, bandwidth, and energy requirements.
- RPL Memory Budget: Calculation of RAM required for RPL operation: routing table entries × bytes per entry + neighbor table + control message buffers; critical for constrained device deployment.
- Channel Utilization: The fraction of 802.15.4 channel bandwidth consumed by application plus RPL control traffic; must stay below ~30% to avoid excessive collisions.
38.3 RPL Traffic Patterns
RPL optimizes for different traffic directions:
38.3.1 Many-to-One (Upward Routing)
Pattern: Many sensors to single gateway/root
How:
- Each node knows parent (from DODAG construction)
- Default route: Send to parent (toward root)
- No routing table needed (upward)
Example: Temperature sensors reporting to cloud
Sensor 3 -> Node 1 -> Root -> Internet -> Cloud
(Upward along DODAG tree)Optimization:
- Most common traffic in IoT (data collection)
- Minimal state: Just parent pointer
- Efficient: Direct path to root
38.3.2 One-to-Many (Downward Routing)
Pattern: Single controller to many actuators
How:
- Storing mode: Each node has routing table, forwards optimally
- Non-storing mode: Root inserts source route, nodes follow
Example: Controller sends “turn off” to all lights
Root -> [Multicast or unicast to each light]Modes:
- Storing: Root -> Node 1 -> Light 3 (optimal)
- Non-storing: Root inserts route [Node 1, Light 3]
38.3.3 Point-to-Point (P2P)
Pattern: Sensor to Actuator (peer-to-peer)
How:
- Upward then downward (via common ancestor, often root)
- Storing mode: May find shorter path via common ancestor
- Non-storing mode: Always via root
Example: Motion sensor triggers light
Storing: Sensor 3 -> Node 1 -> Light 4 (3 hops, if both under Node 1)
Non-Storing: Sensor 3 -> Node 1 -> Root -> Node 2 -> Light 4 (5 hops)
Putting Numbers to It
In a 3-floor smart building with 120 nodes, analyze the memory overhead difference between Storing and Non-Storing modes.
Storing Mode memory per node: \[ M_{\text{storing}} = (\text{num descendants}) \times (16 \text{ bytes IPv6} + 2 \text{ bytes next-hop}) = N_d \times 18 \text{ bytes} \]
For a typical router with 4 descendants: \[ M_{\text{router}} = 4 \times 18 = 72 \text{ bytes} \]
Total network memory (40 routers, 80 leaves): \[ M_{\text{total}} = (40 \times 72) + (80 \times 0) = 2{,}880 \text{ bytes} \]
Non-Storing Mode memory:
Only the root stores the full routing table for all 119 descendants: \[ M_{\text{root}} = 119 \times 18 = 2{,}142 \text{ bytes} \]
All other nodes: 0 bytes (just parent pointer in RAM, not routing memory).
Savings ratio: \[ \frac{M_{\text{storing}}}{M_{\text{non-storing}}} = \frac{2{,}880}{2{,}142} \approx 1.34\times \]
Non-Storing mode saves 738 bytes (26% reduction) but adds source routing headers (average 8 bytes per hop × 3 hops = 24 bytes per P2P packet). For infrequent P2P traffic, Non-Storing mode wins on total system efficiency. For frequent P2P (>100 packets/hour), the header overhead exceeds memory savings.
38.4 Interactive: RPL Memory Budget Calculator
Use this calculator to estimate routing memory for your network before choosing a mode.
38.5 Hands-On Lab: RPL Network Design
Lab Activity: Designing RPL Network for Smart Building
Objective: Design an RPL network and compare Storing vs Non-Storing modes
Scenario: 3-floor office building
Devices:
- 1 Border Router (roof, internet connection)
- 15 mains-powered sensors (temperature, humidity) - can be routers
- 30 battery-powered sensors (door, motion) - end devices
- 10 actuators (lights, HVAC) - mains powered
Floor Layout:
Floor 3: BR + 5 mains sensors + 10 battery sensors + 3 actuators
Floor 2: 5 mains sensors + 10 battery sensors + 4 actuators
Floor 1: 5 mains sensors + 10 battery sensors + 3 actuators38.5.1 Task 1: DODAG Topology Design
Design the DODAG: 1. Place border router (root) 2. Identify routing nodes (mains-powered devices) 3. Draw DODAG showing parent-child relationships 4. Assign RANK values (assume RANK increase = 100 per hop)
Click to see solution
DODAG Design:
RANK Distribution:
- BR: RANK 0
- Floor 3 mains sensors: RANK 100-200
- Floor 2 mains sensors: RANK 200-400
- Floor 1 mains sensors: RANK 300-500
- Battery/actuators: RANK based on parent + 100
Routing Nodes: 15 mains-powered sensors (can route for battery devices)
Total Nodes: 1 BR + 15 mains + 30 battery + 10 actuators = 56 devices38.5.2 Task 2: Memory Requirements Comparison
Calculate memory requirements for Storing vs Non-Storing:
Assumptions:
- IPv6 address: 16 bytes
- Next-hop pointer: 2 bytes
- Routing entry: 18 bytes total
Calculate:
- Memory per node (Storing mode)
- Memory at root (Non-Storing mode)
- Memory at leaf nodes (both modes)
Click to see solution
Storing Mode:
Routing Table Size per Node:
- Root (BR): All 55 devices reachable
- 55 entries x 18 bytes = 990 bytes
- Mains sensor (typical, 3 children):
- 3 entries x 18 bytes = 54 bytes
- Battery sensor/actuator (leaf):
- 0 entries (just parent pointer: 2 bytes) = 2 bytes
Total network memory (Storing):
- BR: 990 bytes
- 15 mains sensors x 54 bytes avg = 810 bytes
- 40 battery/actuators x 2 bytes = 80 bytes
- Total: ~1,880 bytes distributed across network
Non-Storing Mode:
Routing Table Size:
- Root (BR): All 55 devices
- 55 entries x 18 bytes = 990 bytes
- All other nodes: Just parent pointer
- 55 nodes x 2 bytes = 110 bytes
Total network memory (Non-Storing):
- BR: 990 bytes
- 55 other nodes x 2 bytes = 110 bytes
- Total: ~1,100 bytes (mostly at root)
Comparison:
| Mode | Root Memory | Node Memory (avg) | Total Memory |
|---|---|---|---|
| Storing | 990 bytes | 15-54 bytes | 1,880 bytes |
| Non-Storing | 990 bytes | 2 bytes | 1,100 bytes |
Analysis:
- Non-Storing saves ~780 bytes network-wide
- Mains sensors: Can afford 54 bytes (have 32-128 KB RAM)
- Battery sensors: Both modes use only 2 bytes at leaf nodes
- Trade-off: Memory savings vs routing efficiency
38.5.3 Task 3: Traffic Pattern Analysis
Analyze routing for different traffic patterns:
Scenarios:
- Many-to-One: All battery sensors report temperature every 5 minutes to cloud
- One-to-Many: Cloud sends firmware update to all sensors
- Point-to-Point: Motion sensor (Floor 1) triggers light (Floor 3)
For each scenario, calculate: - Average hop count (Storing vs Non-Storing) - Messages per minute - Network load
Click to see solution
Scenario 1: Many-to-One (Sensor to Cloud)
Route (any battery sensor to BR):
- Storing: Sensor -> Parent (mains) -> Parent -> … -> BR
- Average: 2-3 hops (battery to mains, mains to BR, possibly intermediate)
- Non-Storing: Same (upward routing identical)
- Average: 2-3 hops
Messages:
- 30 battery sensors x 12 msgs/hour = 360 msgs/hour = 6 msgs/min
Conclusion: Identical performance (many-to-one is RPL’s strength)
Scenario 2: One-to-Many (Cloud to All Sensors)
Route (BR to any sensor):
- Storing: BR -> optimal path to sensor
- BR has routing table, knows best path
- Average: 2-3 hops (BR to mains to battery)
- Non-Storing: BR -> mains -> battery (same path, but source routed)
- BR inserts source route
- Average: 2-3 hops
Difference: Minimal - Storing: routing table lookup at each hop - Non-Storing: source route in header (extra ~10 bytes overhead)
Messages: 55 devices x 1 update = 55 messages (infrequent)
Conclusion: Non-Storing adds header overhead but same hop count
Scenario 3: Point-to-Point (Floor 1 Sensor to Floor 3 Light)
Route:
Storing Mode:
Floor 1 Sensor -> Parent (Floor 1 mains) Floor 1 mains checks table: "Floor 3 Light not in my sub-tree" -> Forward to parent (Floor 2 mains) Floor 2 mains checks table: "Floor 3 Light not in my sub-tree" -> Forward to parent (BR) BR checks table: "Floor 3 Light via Sensor 3-2" -> Forward to Sensor 3-2 Sensor 3-2 -> Floor 3 Light Path: F1-Sensor -> F1-mains -> F2-mains -> BR -> F3-mains -> F3-Light Hops: 5Non-Storing Mode:
Floor 1 Sensor -> Parent -> ... -> BR (upward, default route) BR inserts source route: [F3-mains, F3-Light] BR -> F3-mains -> F3-Light Path: F1-Sensor -> F1-mains -> F2-mains -> BR -> F3-mains -> F3-Light Hops: 5 (same)
Conclusion: For this topology, same hop count, but: - Storing: Distributed routing decisions (higher memory) - Non-Storing: Centralized at root (source routing overhead)
Summary:
| Traffic Pattern | Storing Advantage | Non-Storing Advantage |
|---|---|---|
| Many-to-One | None (equal) | None (equal) |
| One-to-Many | None (equal) | Lower node memory |
| Point-to-Point | Can optimize locally | Simpler nodes |
38.6 Quiz: RPL Routing Protocol
Question 1: RANK Purpose
What is the primary purpose of RANK in RPL?
- To measure the distance in meters from the root
- To prevent routing loops by defining hierarchical position
- To prioritize packets based on importance
- To encrypt routing information
Click to see answer
Answer: B) To prevent routing loops by defining hierarchical position
Explanation:
RANK Definition: RANK is a scalar value representing a node’s position in the DODAG hierarchy relative to the root.
Primary Purpose: Loop Prevention
How RANK Prevents Loops:
- Root has minimum RANK (typically 0)
- RANK increases as you move away from root
- Upward routing rule: Packets forwarded to nodes with lower RANK
- Parent selection rule: Node cannot choose parent with higher RANK
Loop Prevention Example:
Attempt to create loop:
Node C (RANK 400) wants to choose Node A (RANK 100) as parent:
- Node A RANK (100) < Node C RANK (400) – moving toward root
- ALLOWED (valid upward direction)
Node A (RANK 100) wants to choose Node C (RANK 400) as parent:
- Node C RANK (400) > Node A RANK (100) – would move away from root
- FORBIDDEN (would create routing loop)
RANK Calculation Factors:
RANK is calculated by objective function, which may consider: - Hop count: Each hop adds fixed amount - ETX: Expected Transmission Count (link quality) - Latency: Time to reach root - Energy: Remaining battery, power consumption - Throughput: Link bandwidth
Example Objective Function (OF0 - Hop Count):
RANK = Parent_RANK + MinHopRankIncrease
MinHopRankIncrease = DEFAULT_MIN_HOP_RANK_INCREASE = 256
Node A (parent: ROOT): RANK = 0 + 256 = 256
Node B (parent: A): RANK = 256 + 256 = 512
Node C (parent: B): RANK = 512 + 256 = 768Example Objective Function (ETX-based):
RANK = Parent_RANK + (ETX x MULTIPLIER)
Good link (ETX = 1.2): RANK increase = 1.2 x 100 = 120
Poor link (ETX = 3.5): RANK increase = 3.5 x 100 = 350
Node might prefer 2 good hops (RANK increase: 240)
over 1 poor hop (RANK increase: 350)
Question 3: RPL Control Messages
Which RPL control message is used by a node to request DODAG information from neighbors?
- DIO (DODAG Information Object)
- DIS (DODAG Information Solicitation)
- DAO (Destination Advertisement Object)
- DAO-ACK (DAO Acknowledgment)
Click to see answer
Answer: B) DIS (DODAG Information Solicitation)
Explanation:
RPL Control Messages (all ICMPv6):
DIS (DODAG Information Solicitation):
Purpose: Request DODAG information from neighbors
When Used:
- New node joins network: Doesn’t know about any DODAG
- Node loses DODAG info: Parent moved, connection lost
- Proactive discovery: Node wants to find better DODAG
Message Flow:
New Node: "Is there a DODAG I can join?"
(sends DIS - multicast)
Neighbors: "Yes, here's my DODAG info"
(respond with DIO - unicast or multicast)
New Node: Receives DIO(s), chooses DODAG and parent38.7 Worked Example: RPL Memory Budget for a 3-Floor Smart Office
Scenario: A smart office occupies 3 floors with 120 Zigbee devices: 80 occupancy sensors (under-desk PIR, battery-powered), 20 smart lights (mains-powered), 10 HVAC zone controllers (mains-powered), and 10 meeting room displays (mains-powered). One border router per floor connects to the building management system. The network must support: occupancy data upward (every 30 seconds), lighting commands downward (on demand, ~50/hour building-wide), and occupancy-to-light point-to-point triggers (motion sensor directly dims nearby light within 200 ms).
Step 1: Map traffic patterns to RPL requirements
| Traffic Pattern | Direction | Frequency | Latency Requirement | RPL Mode Implication |
|---|---|---|---|---|
| Occupancy data | Many-to-one (upward) | 80 sensors x 2/min = 160 msg/min | Seconds OK | Both modes work |
| Lighting commands | One-to-many (downward) | ~50/hour | <500 ms | Storing: direct path. Non-Storing: via root |
| Occupancy-to-light | Point-to-point | ~200/hour (peak) | <200 ms | Storing: common ancestor. Non-Storing: via root |
The 200 ms point-to-point requirement is critical. Let’s calculate latency for each mode.
Step 2: Calculate point-to-point latency
Network topology: 3 floors, average DODAG depth = 3 hops from sensor to root.
Storing mode (route through common ancestor):
A desk sensor and the nearest light are typically 1-2 hops apart with a common ancestor 1 hop up:
| Hop | Direction | Latency (802.15.4 at 250 kbps) |
|---|---|---|
| Sensor to common ancestor | Up 1 hop | ~8 ms (48-byte packet at 250 kbps + processing) |
| Common ancestor to light | Down 1 hop | ~8 ms |
| Total | 2 hops | ~16 ms |
Well within the 200 ms requirement.
Non-Storing mode (route through root/border router):
| Hop | Direction | Latency |
|---|---|---|
| Sensor to root | Up 3 hops | ~24 ms |
| Root source-route lookup | Processing | ~2 ms |
| Root to light | Down 2 hops (source-routed) | ~20 ms (16 ms + 4 ms source header processing) |
| Total | 5 hops | ~46 ms |
Still within 200 ms, but 2.9x slower. More importantly, all P2P traffic now flows through the root, creating a bottleneck.
Step 3: Calculate root bottleneck in Non-Storing mode
In Non-Storing mode, the border router must process ALL downward and P2P traffic:
| Traffic Type | Messages/min | Bytes/msg (incl. source routing header) | Root processing load |
|---|---|---|---|
| Lighting commands (downward) | 0.83 | 48 + 56 (src-route, 3 hops) = 104 bytes | 86 bytes/min |
| P2P occupancy-to-light | 3.33 (peak) | 48 + 72 (src-route, 4 hops) = 120 bytes | 400 bytes/min |
| Upward sensor data (just forwarding) | 53.3 (per-floor root) | 48 bytes | 2,560 bytes/min |
| Total root load | 57.5 msg/min | 3,046 bytes/min |
This is manageable for a single root. But at peak occupancy (morning rush, 8:30-9:00 AM), P2P triggers spike:
| Peak scenario | Messages/min at root | Processing time |
|---|---|---|
| 60 people arriving in 30 min | 120 occupancy-to-light triggers/min | 120 x 2 ms = 240 ms/min |
| Plus normal upward traffic | 53 sensor readings/min | 53 x 1 ms = 53 ms/min |
| Total | 173 msg/min | 293 ms/min |
The root can handle this (~0.5% CPU utilization). Non-Storing mode is feasible but adds unnecessary latency.
Step 4: Memory budget comparison
Storing mode:
| Device Type | Count | Role | Routing Table Entries | RAM for Routing |
|---|---|---|---|---|
| Border routers | 3 | Root (all 40 devices on floor) | 40 x 28 bytes = 1,120 bytes | 1.1 KB |
| Smart lights | 20 | Router (~4 descendants each) | 4 x 28 = 112 bytes | 112 bytes |
| HVAC controllers | 10 | Router (~8 descendants each) | 8 x 28 = 224 bytes | 224 bytes |
| Meeting room displays | 10 | Router (~2 descendants each) | 2 x 28 = 56 bytes | 56 bytes |
| Occupancy sensors | 80 | Leaf (0 descendants) | 0 bytes | 0 bytes |
| Total routing memory | 5.2 KB |
Typical Zigbee module (CC2530): 8 KB RAM. Routing table for a light (112 bytes) is 1.4% of available RAM.
Non-Storing mode:
| Device | Count | RAM for Routing |
|---|---|---|
| Border routers | 3 | 40 x 28 = 1,120 bytes each (3.4 KB total) |
| All other devices | 117 | 0 bytes (no routing table) |
| Total routing memory | 3.4 KB |
Decision: Storing mode. The memory savings from Non-Storing (1.8 KB less across the network) do not justify the 2.9x latency increase for P2P occupancy-to-light triggers. The mains-powered lights and controllers have sufficient RAM (8 KB) to store 4-8 routing entries (112-224 bytes). The battery-powered occupancy sensors are leaves with zero routing memory in both modes.
Key insight: In this smart office, 78% of traffic is upward (occupancy data) where both modes perform identically. But the remaining 22% (lighting commands and P2P triggers) determines the mode choice. The 200 ms occupancy-to-light requirement is easily met by both modes, but Storing mode’s 16 ms P2P latency leaves headroom for future requirements (e.g., adding Bluetooth presence for sub-100 ms lighting response). Non-Storing mode would be the right choice only if the occupancy sensors had extremely constrained RAM (<1 KB) – which is not the case for modern Zigbee modules.
Common Pitfalls
1. Designing Traffic Patterns Without Measuring Actual Payloads
Traffic design exercises often use round-number payload sizes. Real IoT sensors have protocol overhead (CoAP header, 6LoWPAN fragmentation, RPL source routing) that can double or triple the effective per-packet size. Measure full packet sizes including all headers.
2. Not Analyzing Traffic Bursts
Average traffic calculations hide burst behavior — a smart building with 200 sensors that all report simultaneously after a power restoration creates a DIO + application message storm. Design for peak burst, not average load.
38.8 What’s Next
| If you want to… | Read this |
|---|---|
| Study RPL routing modes for traffic handling | RPL Routing Modes |
| Review production deployment framework | RPL Production Framework |
| Practice network design in labs | RPL Lab: Network Design |
| Analyze real deployment scenarios | RPL Production Scenarios |