720  RPL Lab: Network Design

720.1 Learning Objectives

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

  • Design DODAG Topologies: Plan RPL network structures with appropriate node placement and parent relationships
  • Assign RANK Values: Calculate and configure RANK for nodes based on hop count and objective functions
  • Compare Operating Modes: Evaluate Storing vs Non-Storing modes for different building and deployment scenarios
  • Identify Routing Nodes: Determine which devices should serve as RPL routers versus leaf nodes
  • Optimize for Power: Design RPL networks that balance routing overhead with battery life requirements

720.2 Prerequisites

Required Chapters:

Technical Background:

  • IPv6 addressing basics
  • Tree-based routing concepts
  • Directed Acyclic Graphs (DAGs)

Lab Requirements:

  • Contiki-NG or RIOT OS environment
  • 6LoWPAN capable hardware (or simulator like Cooja)
  • Wireshark with RPL dissector for packet analysis

Estimated Time: 45 minutes

What is this lab? A practical design exercise for RPL (Routing Protocol for Low-Power and Lossy Networks) network planning.

When to use: - After studying RPL fundamentals and DODAG construction - When you want hands-on routing design experience - Before implementing RPL in real networks

Key Concepts to Practice:

Concept Exercise Focus
DODAG Formation Build routing trees
Rank Calculation Understand path costs
Mode Selection Storing vs Non-Storing
Memory Planning Resource requirements

720.3 Hands-On Lab: RPL Network Design

Time: ~45 min | Level: Advanced | Code: P07.C23.U01

NoteLab 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

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

%%{init: {'theme': 'base', 'themeVariables': { 'primaryColor': '#2C3E50', 'primaryTextColor': '#fff', 'primaryBorderColor': '#16A085', 'lineColor': '#16A085', 'secondaryColor': '#E67E22', 'tertiaryColor': '#7F8C8D'}}}%%
graph TD
    BR["Border Router<br/>RANK 0<br/>(Floor 3, Roof)"]

    MS1["Mains Sensor 1<br/>RANK 100"]
    MS2["Mains Sensor 2<br/>RANK 100"]
    MS3["Mains Sensor 3<br/>RANK 200"]
    MS4["Mains Sensor 4<br/>RANK 200"]

    BS1["Battery Sensor<br/>RANK 200"]
    BS2["Battery Sensor<br/>RANK 300"]
    BS3["Battery Sensor<br/>RANK 300"]

    AC1["Actuator<br/>RANK 200"]
    AC2["Actuator<br/>RANK 300"]

    BR --> MS1
    BR --> MS2
    MS1 --> MS3
    MS2 --> MS4
    MS1 --> BS1
    MS3 --> BS2
    MS4 --> BS3
    MS2 --> AC1
    MS4 --> AC2

    style BR fill:#2C3E50,stroke:#16A085,color:#fff
    style MS1 fill:#16A085,stroke:#16A085,color:#fff
    style MS2 fill:#16A085,stroke:#16A085,color:#fff
    style MS3 fill:#16A085,stroke:#16A085,color:#fff
    style MS4 fill:#16A085,stroke:#16A085,color:#fff
    style BS1 fill:#E67E22,stroke:#16A085,color:#fff
    style BS2 fill:#E67E22,stroke:#16A085,color:#fff
    style BS3 fill:#E67E22,stroke:#16A085,color:#fff
    style AC1 fill:#7F8C8D,stroke:#16A085,color:#fff
    style AC2 fill:#7F8C8D,stroke:#16A085,color:#fff

Figure 720.1: DODAG topology for 3-floor smart building with border router and hierarchical node placement

DODAG hierarchy for 3-floor smart building with border router (Navy), mains-powered sensors (Teal), battery sensors (Orange), and actuators (Gray)

Figure 720.2

This variant shows the same DODAG topology from a physical building perspective - emphasizing how RANK correlates with distance from the roof-mounted border router across floors.

%% fig-alt: "Smart building floor layout showing DODAG structure with Border Router on roof (RANK 0), Floor 3 devices at RANK 100-200 nearest to BR, Floor 2 devices at RANK 200-400 in middle, and Floor 1 devices at RANK 300-500 furthest from root. Radio waves show wireless parent-child connections between floors, demonstrating how physical distance maps to RPL RANK values."
%%{init: {'theme': 'base', 'themeVariables': { 'primaryColor': '#2C3E50', 'primaryTextColor': '#fff', 'primaryBorderColor': '#16A085', 'lineColor': '#E67E22', 'secondaryColor': '#16A085', 'tertiaryColor': '#7F8C8D', 'fontSize': '11px'}}}%%
flowchart TB
    subgraph ROOF["ROOF - Internet Connection"]
        BR["Border Router<br/>RANK 0"]
    end

    subgraph F3["FLOOR 3 - RANK 100-200"]
        direction LR
        F3M1["Mains<br/>R:100"]
        F3M2["Mains<br/>R:100"]
        F3B1["Battery<br/>R:200"]
        F3A1["Actuator<br/>R:200"]
    end

    subgraph F2["FLOOR 2 - RANK 200-400"]
        direction LR
        F2M1["Mains<br/>R:200"]
        F2M2["Mains<br/>R:300"]
        F2B1["Battery<br/>R:300"]
        F2A1["Actuator<br/>R:400"]
    end

    subgraph F1["FLOOR 1 - RANK 300-500"]
        direction LR
        F1M1["Mains<br/>R:300"]
        F1M2["Mains<br/>R:400"]
        F1B1["Battery<br/>R:400"]
        F1A1["Actuator<br/>R:500"]
    end

    BR --> F3M1
    BR --> F3M2
    F3M1 --> F3B1
    F3M2 --> F3A1
    F3M1 --> F2M1
    F3M2 --> F2M2
    F2M1 --> F2B1
    F2M2 --> F2A1
    F2M1 --> F1M1
    F2M2 --> F1M2
    F1M1 --> F1B1
    F1M2 --> F1A1

    style BR fill:#2C3E50,stroke:#16A085,stroke-width:3px,color:#fff
    style F3M1 fill:#16A085,stroke:#2C3E50,color:#fff
    style F3M2 fill:#16A085,stroke:#2C3E50,color:#fff
    style F3B1 fill:#E67E22,stroke:#2C3E50,color:#fff
    style F3A1 fill:#7F8C8D,stroke:#2C3E50,color:#fff
    style F2M1 fill:#16A085,stroke:#2C3E50,color:#fff
    style F2M2 fill:#16A085,stroke:#2C3E50,color:#fff
    style F2B1 fill:#E67E22,stroke:#2C3E50,color:#fff
    style F2A1 fill:#7F8C8D,stroke:#2C3E50,color:#fff
    style F1M1 fill:#16A085,stroke:#2C3E50,color:#fff
    style F1M2 fill:#16A085,stroke:#2C3E50,color:#fff
    style F1B1 fill:#E67E22,stroke:#2C3E50,color:#fff
    style F1A1 fill:#7F8C8D,stroke:#2C3E50,color:#fff

Figure 720.3: Physical floor layout showing RANK distribution across building floors

Key Insight: RANK increases as you move further from the roof-mounted border router. This physical-to-logical mapping helps design efficient multi-hop routes where mains-powered devices on each floor act as routing nodes for battery-powered sensors.

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

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

720.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 to Parent (mains) to Parent to … to 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 to optimal path to sensor - BR has routing table, knows best path - Average: 2-3 hops (BR to mains to battery) - Non-Storing: BR to mains to 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:

%%{init: {'theme': 'base', 'themeVariables': { 'primaryColor': '#2C3E50', 'primaryTextColor': '#fff', 'primaryBorderColor': '#16A085', 'lineColor': '#16A085', 'secondaryColor': '#E67E22'}}}%%
sequenceDiagram
    participant F1 as Floor 1 Sensor
    participant M1 as Mains Router 1
    participant BR as Border Router
    participant M2 as Mains Router 2
    participant F3 as Floor 3 Light

    F1->>M1: Data packet
    Note over M1: Routing table lookup:<br/>Dest F3 via BR
    M1->>BR: Forward to BR
    Note over BR: Routing table lookup:<br/>Dest F3 via M2
    BR->>M2: Forward to M2
    Note over M2: Routing table lookup:<br/>Dest F3 direct
    M2->>F3: Deliver packet

    Note over F1,F3: Total: 4 hops with distributed routing

Figure 720.4: Point-to-point routing in Storing Mode with distributed routing table lookups

Point-to-point routing in Storing Mode with distributed routing table lookups at each hop

Figure 720.5

Non-Storing Mode:

%%{init: {'theme': 'base', 'themeVariables': { 'primaryColor': '#2C3E50', 'primaryTextColor': '#fff', 'primaryBorderColor': '#16A085', 'lineColor': '#16A085', 'secondaryColor': '#E67E22'}}}%%
sequenceDiagram
    participant F1 as Floor 1 Sensor
    participant M1 as Mains Router 1
    participant BR as Border Router
    participant M2 as Mains Router 2
    participant F3 as Floor 3 Light

    F1->>M1: Data packet (to BR)
    M1->>BR: Forward upward (parent)
    Note over BR: Source routing:<br/>Build path F1 M1 BR M2 F3<br/>Insert in packet header
    BR->>M2: Packet with source route
    M2->>F3: Deliver using source route

    Note over F1,F3: Total: 4 hops with centralized routing at BR

Figure 720.6: Point-to-point routing in Non-Storing Mode with source routing through border router

Point-to-point routing in Non-Storing Mode with source routing from border router

Figure 720.7

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 to BR to F3-Light (2 hops) - Non-Storing: F1-Sensor to BR to 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)

720.4 Summary

This hands-on lab demonstrated practical RPL network design skills:

  • DODAG Topology Design: Strategic placement of border router and routing nodes based on network hierarchy and power availability is crucial for efficient RPL networks
  • Memory Trade-offs: Storing mode distributes routing tables (~54 bytes per router) while Non-Storing mode centralizes at root (~990 bytes), impacting scalability differently
  • Traffic Pattern Analysis: Many-to-one traffic shows identical performance in both modes, while point-to-point routing may benefit from Storing mode’s distributed tables

720.4.1 Key Design Principles

  1. Use mains-powered devices as routers - They have sufficient RAM and continuous power
  2. Configure battery sensors as leaf nodes - Minimize routing overhead
  3. Choose Non-Storing for sensor-heavy networks - Lower memory requirements
  4. Consider Storing for P2P-heavy networks - Better routing efficiency

720.5 What’s Next

Continue to RPL Knowledge Check to test your understanding with scenario-based quizzes, or explore RPL Quiz Questions for detailed concept review with explanations.