711 RPL Traffic Patterns and Network Design

Learning Objectives

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

Understand upward, downward, and point-to-point routing in RPL
Design RPL networks for different IoT applications
Calculate memory requirements for Storing vs Non-Storing modes
Analyze traffic patterns and select appropriate RPL configurations
Apply RPL concepts to real-world smart building scenarios

711.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

Related Chapters

This Series: - RPL Introduction - Core concepts and fundamentals - RPL DODAG Construction and Modes - Building DODAGs and routing modes - RPL Traffic Patterns and Design - This chapter - RPL Production and Summary - Production framework and key takeaways

Hands-On: - RPL Production and Review - Storing vs Non-Storing mode deployment - Simulations Hub - Test RPL DODAG formation in simulators

711.2 RPL Traffic Patterns

RPL optimizes for different traffic directions:

%%{init: {'theme': 'base', 'themeVariables': { 'primaryColor': '#2C3E50', 'primaryTextColor': '#fff', 'primaryBorderColor': '#16A085', 'lineColor': '#16A085', 'secondaryColor': '#E67E22', 'tertiaryColor': '#7F8C8D'}}}%%
graph TB
    subgraph ManyToOne["Many-to-One<br/>(Upward)"]
        S1["Sensor 1"] --> GW1["Gateway"]
        S2["Sensor 2"] --> GW1
        S3["Sensor 3"] --> GW1
        S4["Sensor 4"] --> GW1
    end

    subgraph OneToMany["One-to-Many<br/>(Downward)"]
        GW2["Gateway"] --> A1["Actuator 1"]
        GW2 --> A2["Actuator 2"]
        GW2 --> A3["Actuator 3"]
    end

    subgraph P2P["Point-to-Point"]
        SEN["Sensor"] --> ACT["Actuator"]
    end

    style ManyToOne fill:#16A085,stroke:#2C3E50,color:#fff
    style OneToMany fill:#E67E22,stroke:#2C3E50,color:#fff
    style P2P fill:#7F8C8D,stroke:#2C3E50,color:#fff
    style GW1 fill:#2C3E50,stroke:#16A085,color:#fff
    style GW2 fill:#2C3E50,stroke:#16A085,color:#fff
    style S1 fill:#F8F9FA,stroke:#16A085,color:#2C3E50
    style S2 fill:#F8F9FA,stroke:#16A085,color:#2C3E50
    style S3 fill:#F8F9FA,stroke:#16A085,color:#2C3E50
    style S4 fill:#F8F9FA,stroke:#16A085,color:#2C3E50
    style A1 fill:#F8F9FA,stroke:#E67E22,color:#2C3E50
    style A2 fill:#F8F9FA,stroke:#E67E22,color:#2C3E50
    style A3 fill:#F8F9FA,stroke:#E67E22,color:#2C3E50
    style SEN fill:#F8F9FA,stroke:#7F8C8D,color:#2C3E50
    style ACT fill:#F8F9FA,stroke:#7F8C8D,color:#2C3E50

Figure 711.1: RPL traffic patterns: Many-to-One (upward), One-to-Many (downward), and Point-to-Point routing

{fig-alt=“RPL traffic patterns: Many-to-One shows multiple sensors sending to gateway (upward routing), One-to-Many shows gateway sending to multiple actuators (downward), Point-to-Point shows direct sensor to actuator communication”}

711.2.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

711.2.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]

711.2.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 - 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 (4 hops)

711.3 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 actuators

711.3.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:

Smart building DODAG topology with three floors showing BR root node (Navy), mains-powered sensors (Teal), battery-powered sensors (Orange), and actuators (Gray). RANK values increase from 0 at root to 500 at leaf nodes, with a long-range link connecting Floor 3 BR to Floor 2 Sensor 2-1.

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 devices

711.3.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: 1. Memory per node (Storing mode) 2. Memory at root (Non-Storing mode) 3. 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: Benefit from 2 bytes vs 0 (minimal difference) - Trade-off: Memory savings vs routing efficiency

711.3.3 Task 3: Traffic Pattern Analysis

Analyze routing for different traffic patterns:

Scenarios: 1. Many-to-One: All battery sensors report temperature every 5 minutes to cloud 2. One-to-Many: Cloud sends firmware update to all sensors 3. 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: 5 ```

Non-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)

If topology were flatter (e.g., many sensors directly under BR): - Storing: F1-Sensor -> BR -> F3-Light (2 hops) - Non-Storing: F1-Sensor -> BR -> F3-Light (2 hops) - Same performance

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

Recommendation: Non-Storing for this scenario - Battery-powered sensors dominate (low memory) - Many-to-one traffic primary (sensors reporting) - Point-to-point rare (motion to light scenarios uncommon)

Quiz 6: Lab Activity: Designing RPL Network for Smart Building

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 12: 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.

711.4 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:

RANK-based loop prevention mechanism showing valid parent selection (Node C can choose Node A, RANK 100 < 400) versus forbidden loop creation (Node A cannot choose Node C, RANK 400 > 100)

Attempt to create loop:

Node C wants to choose Node A as parent: - Current RANK: 400 - Node A RANK: 100 - ALLOWED (100 < 400, moving toward root)

Node A wants to choose Node C as parent: - Current RANK: 100 - Node C RANK: 400 - FORBIDDEN (400 > 100, moving away from root = 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 = 768

Example 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)

Conclusion: RANK’s primary purpose is loop prevention by establishing a strict hierarchy where packets can only flow “upward” (toward lower RANK), preventing cycles in the DODAG.

Question 2: Storing vs Non-Storing Mode

In a network of 100 battery-powered sensors sending data to a single gateway (many-to-one traffic), which RPL mode is more appropriate?

Storing mode (better routing efficiency)
Non-Storing mode (lower memory requirements)
Both modes have identical performance for this scenario
RPL doesn’t support many-to-one traffic well

Click to see answer

Answer: C) Both modes have identical performance for this scenario

Explanation:

Many-to-One Traffic is RPL’s primary use case and is handled identically in both modes.

How Many-to-One Works in RPL:

Upward Routing (toward root): - Every node knows its parent (from DODAG construction) - Default route: Send to parent - No routing table needed for upward routes

Both Modes:

Sensor 50 (RANK 500)
  -> Parent Node 20 (RANK 300)
    -> Parent Node 10 (RANK 150)
      -> ROOT (RANK 0)

Process:
1. Sensor 50 has data for gateway
2. Looks up default route: "Send to parent (Node 20)"
3. Node 20 receives, looks up default route: "Send to parent (Node 10)"
4. Node 10 receives, looks up default route: "Send to parent (ROOT)"
5. ROOT receives - destination reached!

Performance Comparison:

Aspect	Storing Mode	Non-Storing Mode
Hop Count	Same (upward to root)	Same (upward to root)
Latency	Same	Same
Forwarding Complexity	Same (parent lookup)	Same (parent lookup)
Memory Used	Parent pointer + routing table	Parent pointer only
Bandwidth	Same	Same

Key Insight: Routing tables are for downward/P2P routes!

For many-to-one traffic, both RPL modes have identical routing performance (same path, same hop count, same latency). The choice between modes should be based on memory constraints and other traffic patterns (downward, P2P), not many-to-one routing efficiency.

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):

%%{init: {'theme': 'base', 'themeVariables': { 'primaryColor': '#2C3E50', 'primaryTextColor': '#fff', 'primaryBorderColor': '#16A085', 'lineColor': '#16A085', 'secondaryColor': '#E67E22', 'tertiaryColor': '#7F8C8D'}}}%%
graph TB
    subgraph Messages["RPL Control Messages"]
        DIO["DIO<br/>DODAG Information Object<br/>Sent by: ROOT, Routers<br/>Purpose: Advertise DODAG"]
        DIS["DIS<br/>DODAG Information Solicitation<br/>Sent by: New nodes<br/>Purpose: Request DODAG info"]
        DAO["DAO<br/>Destination Advertisement<br/>Sent by: All nodes<br/>Purpose: Build downward routes"]
        DAOACK["DAO-ACK<br/>DAO Acknowledgment<br/>Sent by: Parents<br/>Purpose: Confirm DAO receipt"]
    end

    style Messages fill:#F8F9FA,stroke:#2C3E50,color:#2C3E50
    style DIO fill:#2C3E50,stroke:#16A085,color:#fff
    style DIS fill:#16A085,stroke:#2C3E50,color:#fff
    style DAO fill:#E67E22,stroke:#2C3E50,color:#fff
    style DAOACK fill:#7F8C8D,stroke:#2C3E50,color:#fff

Figure 711.4: RPL control message types: DIO for DODAG advertisement, DIS for solicitation, DAO for route building

{fig-alt=“RPL Control Messages showing DIO (advertise DODAG from ROOT/routers), DIS (request info from new nodes), DAO (build downward routes from all nodes), DAO-ACK (confirm receipt from parents)”}

DIS (DODAG Information Solicitation):

Purpose: Request DODAG information from neighbors

When Used: 1. New node joins network: Doesn’t know about any DODAG 2. Node loses DODAG info: Parent moved, connection lost 3. 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 parent

Conclusion: DIS (DODAG Information Solicitation) is the RPL control message used to request DODAG information from neighbors, enabling active network discovery and faster DODAG joining compared to waiting for periodic DIOs.

Question 4: Traditional vs RPL Routing

Why is OSPF (Open Shortest Path First) not suitable for IoT Low-Power and Lossy Networks?

OSPF doesn’t support IPv6
OSPF requires too much processing power and memory
OSPF can’t handle mesh topologies
OSPF is proprietary and requires licensing

Click to see answer

Answer: B) OSPF requires too much processing power and memory

Explanation:

OSPF is a link-state routing protocol designed for traditional IP networks (enterprise, ISP). It’s fundamentally incompatible with resource-constrained IoT devices.

Resource Requirements Comparison:

Resource	OSPF	RPL
CPU	GHz, multi-core	MHz, single-core
RAM	MB-GB	KB (10-128 KB)
Flash	MB-GB	KB (32-512 KB)
Power	Watts (mains)	Milliwatts (battery)
Algorithm	Dijkstra’s SPF	Distance-vector
Database	Link-state DB (entire network)	Parent pointer / routing table

Why OSPF Doesn’t Work for IoT:

1. Memory Requirements:

OSPF: - Link-State Database (LSDB): Stores topology of entire network - Every router knows everything: All links, all routers - Example: 100-node network - Average 3 links per node = 300 links - Link-state data: ~50 bytes per link - LSDB size: 300 x 50 = 15 KB (minimum, just topology) - Add routing table, neighbor table, etc.: 50-100 KB total

IoT Device (e.g., nRF52840): - Total RAM: 256 KB - OSPF would use: 50-100 KB (~40% of RAM!) - Application left with: 150 KB (including OS, app, buffers)

RPL: - Storing mode: Routing table for sub-DODAG only (KBs) - Non-Storing mode: Just parent pointer (2 bytes) - Typical: 1-5 KB for routing state

2. Processing Requirements:

OSPF Algorithm:

1. Receive Link-State Advertisements (LSAs)
2. Update Link-State Database
3. Run Dijkstra's Shortest Path First (SPF) algorithm
   - For 100-node network: O(N^2) = 10,000 operations
   - Recalculate entire routing table
4. Update forwarding table

RPL Algorithm:

1. Receive DIO from parent
2. Update RANK = parent_RANK + increase
3. (Storing mode) Update routing table for children
4. Done

CPU Time: < 1ms (simple calculation) vs 500ms-2s for OSPF on IoT hardware

3. Protocol Overhead:

OSPF: - Hello packets: Every 10 seconds (keep neighbors alive) - LSA flooding: Every topology change - LSA refresh: Every 30 minutes (even if no change) - Packets: Large (detailed link-state info)

RPL: - DIO: Trickle timer (adaptive, minutes when stable) - DAO: Only when topology changes - Packets: Smaller (compressed headers with 6LoWPAN)

Conclusion: OSPF is unsuitable for IoT LLNs primarily because its link-state database and SPF algorithm require far more memory and processing power than battery-powered IoT devices can afford, while RPL is specifically designed for these constraints.

711.5 What’s Next

Now that you understand RPL traffic patterns and have practiced network design, the next chapter covers production frameworks and provides a comprehensive summary of key concepts.

Continue to: RPL Production and Summary

Production RPL framework architecture
Key concepts summary
Visual reference gallery
Comprehensive review quiz
Standards references (RFC 6550, 6552, 6719)