32 RPL DODAG Example

In 60 Seconds

Complete worked example calculating RANK values for a 10-node smart lighting mesh network using the ETX-based objective function. Walks through parent selection decisions step-by-step when multiple candidate parents exist, showing how link quality (not just hop count) determines the final DODAG topology.

32.1 Learning Objectives

After completing this chapter, you will be able to:

Calculate RANK values step-by-step for a real network topology using the ETX formula
Apply the ETX-based objective function formula to derive cumulative path costs
Evaluate parent selection decisions when multiple candidate parents exist
Interpret the final DODAG structure for upward, downward, and point-to-point routing

For Beginners: RPL DODAG Example

This chapter walks through a complete example of how RPL builds a routing tree from scratch. Following along is like watching a time-lapse of a tree growing – you will see each device discover its neighbors, pick its preferred parent, and join the network structure one step at a time.

Sensor Squad: The Smart Lighting Math!

“Let us work through a real example together,” said Max the Microcontroller. “Imagine 10 smart lights in a building lobby. One is the border router – the boss – and the other nine need to find their way to it.”

“The key formula is RANK = parent’s RANK plus the link cost,” explained Sammy the Sensor. “If my parent has RANK 256 and my link to them has an ETX of 1.5 – meaning I need about 1.5 transmissions per successful delivery – then my RANK is 256 plus 1.5 times 256, which equals 640.”

“But what if you can hear TWO potential parents?” asked Lila the LED. “That is where it gets clever! You calculate your RANK through each parent and pick the one that gives you the lower number. Lower RANK means a better path to the root.”

“In our lighting example, some lights can hear the root directly – they get low RANK values,” added Bella the Battery. “Lights further away have to relay through others, getting higher RANK values. The final tree shape depends entirely on link quality, not just physical distance. A light far from the root might get a lower RANK than one nearby if it has better link quality!”

32.2 Worked Example: DODAG Construction Step-by-Step

10-Node Smart Lighting Network

This worked example walks through the complete DODAG construction process for a realistic smart lighting deployment. We will calculate RANK values using actual RPL parameters and show how parent selection works with varying link qualities.

32.2.1 Problem Context

Scenario: You are deploying a smart lighting mesh network in a commercial building lobby. The network consists of:

1 Border Router (Root): Connected to the building management system
9 Smart Light Controllers: Need to report status and receive dimming commands
Goal: Build an RPL DODAG for reliable many-to-one (sensor data) and one-to-many (commands) communication

32.2.2 Given Parameters

RPL Configuration (RFC 6550 defaults):

Parameter	Value	Description
MinHopRankIncrease	256	Minimum RANK increase per hop
Objective Function	OF0 with ETX	Minimize Expected Transmission Count
ETX Calculation	ETX = 1 / (delivery_ratio)	Higher ETX = worse link
RANK Formula	RANK = Parent_RANK + (MinHopRankIncrease x ETX)	Cumulative path cost

Network Topology and Link Quality:

10-node smart lighting network topology showing border router ROOT at top connected to first-hop nodes A B C, which connect to second-hop nodes D E F, which connect to third-hop leaf nodes G H I. Links labeled with ETX values ranging from 1.0 for good links to 2.0 for poor links, demonstrating varying wireless link quality in building environment — Graph diagram

32.2.3 Solution: Step-by-Step DODAG Construction

32.2.3.1 Step 1: Root Advertisement (t = 0s)

Root Action: Border router initializes DODAG and broadcasts first DIO message.

DIO Message Contents:

DIO {
  DODAG_ID: fd00::1
  RANK: 0
  Version: 1
  MinHopRankIncrease: 256
  Objective Function: OF0 (ETX)
}

Result: Root has RANK = 0. All nodes within radio range receive this DIO.

32.2.3.2 Step 2: First-Hop Nodes Calculate RANK (t = 2-5s)

Nodes A, B, and C receive the root’s DIO and calculate their RANK values:

Node A Calculation: \[\text{RANK}_A = \text{Parent\_RANK} + (\text{MinHopRankIncrease} \times \text{ETX})\] \[\text{RANK}_A = 0 + (256 \times 1.0) = \mathbf{256}\]

Node B Calculation: \[\text{RANK}_B = 0 + (256 \times 1.0) = \mathbf{256}\]

Node C Calculation: \[\text{RANK}_C = 0 + (256 \times 1.5) = \mathbf{384}\]

Parent Selection: All three nodes select ROOT as parent (only option).

Node	Parent	ETX to Parent	Calculated RANK
A	ROOT	1.0	256
B	ROOT	1.0	256
C	ROOT	1.5	384

Actions:

Each node sends DAO to ROOT announcing reachability
Each node broadcasts DIO with its new RANK to neighbors

32.2.3.3 Step 3: Second-Hop Nodes - Parent Selection Decision (t = 5-10s)

This is where RPL’s intelligence shines. Second-hop nodes may hear DIOs from multiple parents and must choose the best one.

Node D: Receives DIO only from Node A \[\text{RANK}_D = 256 + (256 \times 1.0) = \mathbf{512}\] - Parent: A (only option)

Node E: Receives DIOs from both A and B (key decision point!)

Option 1: Via Node A (ETX 1.5) \[\text{RANK}_E^{(A)} = 256 + (256 \times 1.5) = 640\]

Option 2: Via Node B (ETX 1.0) \[\text{RANK}_E^{(B)} = 256 + (256 \times 1.0) = \mathbf{512}\]

Decision: Node E selects B as primary parent (lower RANK = better path) - Node E also stores A as backup parent (RANK 640, valid alternate)

Node F: Receives DIOs from B and C

Option 1: Via Node B (ETX 1.0) \[\text{RANK}_F^{(B)} = 256 + (256 \times 1.0) = \mathbf{512}\]

Option 2: Via Node C (ETX 1.5) \[\text{RANK}_F^{(C)} = 384 + (256 \times 1.5) = 768\]

Decision: Node F selects B as primary parent (RANK 512 < 768)

Node	Candidate Parents	Calculated RANKs	Selected Parent	Final RANK
D	A only	512	A	512
E	A (640), B (512)	640, 512	B	512
F	B (512), C (768)	512, 768	B	512

Key Insight: Link Quality Trumps Hop Count

Notice that Node F could reach ROOT via C in just 2 hops (F->C->ROOT), but the poor link quality (ETX 1.5 + 1.5) makes this path worse than going through B (ETX 1.0 + 1.0), even though both are 2 hops. RANK incorporates link quality, not just hop count.

32.2.3.4 Step 4: Third-Hop Nodes - Final RANK Calculation (t = 10-15s)

Node G: Receives DIOs from D and E

Option 1: Via Node D (ETX 1.0) \[\text{RANK}_G^{(D)} = 512 + (256 \times 1.0) = \mathbf{768}\]

Option 2: Via Node E (ETX 2.0 - poor link!) \[\text{RANK}_G^{(E)} = 512 + (256 \times 2.0) = 1024\]

Decision: Node G selects D as parent (768 < 1024)

Node H: Receives DIOs from E and F

Option 1: Via Node E (ETX 1.0) \[\text{RANK}_H^{(E)} = 512 + (256 \times 1.0) = \mathbf{768}\]

Option 2: Via Node F (ETX 1.5) \[\text{RANK}_H^{(F)} = 512 + (256 \times 1.5) = 896\]

Decision: Node H selects E as parent (768 < 896)

Node I: Receives DIO only from F \[\text{RANK}_I = 512 + (256 \times 1.0) = \mathbf{768}\] - Parent: F (only option)

Node	Candidate Parents	Calculated RANKs	Selected Parent	Final RANK
G	D (768), E (1024)	768, 1024	D	768
H	E (768), F (896)	768, 896	E	768
I	F only	768	F	768

32.2.3.5 Step 5: DAO Propagation - Building Downward Routes (t = 15-25s)

After DODAG formation, DAO messages flow upward to build downward routing tables:

DAO message propagation sequence showing Node G sending DAO to parent D announcing reachability, D aggregating and sending to A, A aggregating and sending to ROOT. Each intermediate node stores routing entries. ROOT confirms with DAO-ACK flowing back down through D and A to G, completing downward route establishment — Mermaid diagram

32.2.3.6 Step 6: Final DODAG Structure (t = 25-30s)

Final DODAG structure for 10-node smart lighting network showing hierarchical tree rooted at border router with Rank 0. First hop has nodes A B C with Ranks 256 256 384. Second hop has D E F all with Rank 512, where B serves as parent for both E and F. Third hop has leaf nodes G H I all with Rank 768. Dotted lines show backup parent relationships from A to E and F to H for fault tolerance — Graph diagram

32.2.4 Final Answer: Complete RANK Summary

Node	Layer	Parent	ETX to Parent	RANK Calculation	Final RANK
ROOT	0	-	-	Root node	0
A	1	ROOT	1.0	0 + 256x1.0	256
B	1	ROOT	1.0	0 + 256x1.0	256
C	1	ROOT	1.5	0 + 256x1.5	384
D	2	A	1.0	256 + 256x1.0	512
E	2	B	1.0	256 + 256x1.0	512
F	2	B	1.0	256 + 256x1.0	512
G	3	D	1.0	512 + 256x1.0	768
H	3	E	1.0	512 + 256x1.0	768
I	3	F	1.0	512 + 256x1.0	768

32.2.5 Interactive: RPL RANK Calculator

Calculate the RANK a node would achieve via any candidate parent using the ETX formula:

Show code

{
  const node_rank = parent_rank + Math.round(min_hop * link_etx);
  const quality = link_etx <= 1.5 ? "Good" : link_etx <= 2.5 ? "Fair" : "Poor";
  const color = link_etx <= 1.5 ? "#16A085" : link_etx <= 2.5 ? "#E67E22" : "#E74C3C";
  return html`<div style="background: var(--bs-light, #f8f9fa); padding: 1rem; border-radius: 8px; border-left: 4px solid #3498DB; font-family: Arial, sans-serif;">
    <p style="margin:0 0 0.4rem;"><strong>Node RANK via this parent:</strong> <span style="color:#2C3E50; font-size:1.2em; font-weight:bold;">${node_rank}</span></p>
    <p style="margin:0 0 0.4rem;"><strong>Rank increase this hop:</strong> <span style="color:#3498DB;">${Math.round(min_hop * link_etx)}</span> (${min_hop} × ${link_etx.toFixed(1)})</p>
    <p style="margin:0; color:${color}; font-size:0.9em;">Link quality: <strong>${quality}</strong> (ETX ${link_etx.toFixed(1)})</p>
  </div>`
}

Putting Numbers to It

Quantifying Energy Savings from ETX-Based Parent Selection

Consider Node E’s parent choice: Node B (ETX 1.0, RANK 512) versus Node A (ETX 1.5, RANK 640).

Energy calculation over one day (CC2650 sensor, 144 reports/day):

Via Node B (chosen): \[\text{TX per hop} = \text{ETX} \times \text{base cost} = 1.0 \times 3.2\text{ ms} = 3.2\text{ ms}\] \[\text{Daily TX} = 144 \times 3.2\text{ ms} = 460.8\text{ ms}\] \[\text{Energy} = 460.8\text{ ms} \times 9.1\text{ mA} = 4.19\text{ mAh/day}\]

Via Node A (rejected): \[\text{TX per hop} = 1.5 \times 3.2\text{ ms} = 4.8\text{ ms}\] \[\text{Daily TX} = 144 \times 4.8\text{ ms} = 691.2\text{ ms}\] \[\text{Energy} = 691.2\text{ ms} \times 9.1\text{ mA} = 6.29\text{ mAh/day}\]

Savings: \(6.29 - 4.19 = 2.1\) mAh/day = 33% less energy

With 6000 mAh batteries: ETX-based routing extends life from 2.6 years to 3.9 years.

Knowledge Check: RANK Calculation

32.3 Interpretation: How RANK Determines Routing

32.3.1 Upward Routing (Sensor Data -> Cloud)

Each node simply forwards to its parent (follows decreasing RANK)
Example: Light #9 (Node I) sends status -> F (512) -> B (256) -> ROOT (0) -> Cloud
Total path cost: 768 (Node I’s RANK represents cumulative ETX)

32.3.2 Downward Routing (Commands -> Lights)

ROOT uses stored routing table from DAO messages
Example: Dim command to Light #7 (Node G): ROOT -> A -> D -> G
Source routing header (Non-Storing) or hop-by-hop lookup (Storing)

32.3.3 Loop Prevention

Data only flows toward lower RANK (upward) or via explicit routes (downward)
Node E (RANK 512) cannot send to Node F (RANK 512) directly
Point-to-point: E -> B (256) -> F (512) via common ancestor

32.3.4 Fault Tolerance

If Node B fails, E has backup parent A (RANK 640 > 512, but functional)
E would recalculate: RANK_E = 256 + 384 = 640, network continues operating
Trickle timer detects failure within 3-4 DIO intervals

Key Takeaways from This Example

RANK is cumulative: Each hop adds MinHopRankIncrease x ETX, not just +1
Link quality matters: Node F chose B over C despite C being available, because B offered better cumulative path quality
Multiple parents: Nodes can maintain backup parents for resilience (A as backup for E)
Unbalanced trees are OK: Node B has 4 descendants (E and F directly; H and I indirectly via E and F), while C has none - this is optimal given link quality
RANK inversion = loop: If Node H somehow got RANK < 512, it would create a loop with E - RPL prevents this
MinHopRankIncrease = 256: This standard value provides fine-grained RANK differentiation per hop. ETX values between 1.0 and 2.0 map to RANK increments of 256–512, giving 256 distinct RANK levels per ETX unit for precise path comparison

32.4 Practice Problems

32.4.1 Problem 1: Calculate New Node RANK

A new node J is added to the network with these link qualities: - J to G: ETX = 1.2 - J to H: ETX = 1.8

Question: What RANK will node J have, and which parent will it select?

Solution

Via G (ETX 1.2): \[\text{RANK}_J^{(G)} = 768 + (256 \times 1.2) = 768 + 307 = 1075\]

Via H (ETX 1.8): \[\text{RANK}_J^{(H)} = 768 + (256 \times 1.8) = 768 + 461 = 1229\]

Answer: Node J selects G as parent with RANK = 1075

32.4.2 Problem 2: Parent Failure Recovery

Node B fails. What happens to nodes E, F, H, and I?

Solution

Node E: Has backup parent A - New RANK: 256 + (256 x 1.5) = 640 - Children (H) must also update

Node F: Must find new parent - Only option: C (ETX 1.5) - New RANK: 384 + (256 x 1.5) = 768 - Children (I) must also update

Node H: Updates due to E’s change - New RANK via E: 640 + (256 x 1.0) = 896

Node I: Updates due to F’s change - New RANK via F: 768 + (256 x 1.0) = 1024

Key insight: Network self-heals but path quality degrades (RANKs increase)

Worked Example: Parent Hysteresis Threshold Calculation

Scenario: In the smart lighting network, Node E currently uses Node B as parent (RANK 512). A new node X joins with RANK 480. Should Node E immediately switch to Node X as parent?

The Hysteresis Mechanism:

RPL uses parent hysteresis to prevent “parent flapping” - rapid switching between parents due to minor RANK fluctuations. A node only switches parents if the new parent offers RANK improvement exceeding a threshold.

Given Values:

Current parent (B): RANK 512
New candidate (X): RANK 480
MinHopRankIncrease: 256
Hysteresis threshold: Default = MinHopRankIncrease × 1.5 = 384

Step 1: Calculate Node E’s RANK via each parent

Via current parent B (ETX to B = 1.0):

RANK_E(B) = 512 + (256 × 1.0) = 768 (current)

Via candidate parent X (ETX to X = 1.1):

RANK_E(X) = 480 + (256 × 1.1) = 480 + 282 = 762 (proposed)

Step 2: Calculate RANK improvement

Improvement = Current RANK - Proposed RANK
            = 768 - 762
            = 6

Step 3: Compare improvement to hysteresis threshold

Improvement (6) < Threshold (384)?
Yes → Do NOT switch parents

Result: Node E keeps Node B as parent despite Node X offering slightly lower RANK (762 vs 768). The improvement of 6 is far below the hysteresis threshold of 384.

Why Hysteresis Matters:

Without hysteresis:

Node E switches to Node X (RANK 762)
30 seconds later, Node X’s link degrades: RANK becomes 495
Node E recalculates: RANK via X = 495 + 282 = 777 (worse than B!)
Node E switches back to B (RANK 768)
30 seconds later, Node X recovers…
Result: Constant parent switching, wasted DAO messages, unstable routes

With hysteresis (threshold = 384):

Node E ignores small fluctuations (±50 RANK)
Only switches when substantial improvement (> 384 RANK)
Stable parent relationship despite minor link quality changes
Reduces DAO updates by ~85% in real deployments

Tuning Hysteresis for Your Network:

Network Type	Threshold	Reasoning
Stable indoor	1.5× MinHopRankIncrease	Balanced (default)
Lossy industrial	2.0× MinHopRankIncrease	Tolerate more fluctuation
Critical latency	1.0× MinHopRankIncrease	Switch quickly for better paths
Battery-constrained	2.5× MinHopRankIncrease	Minimize DAO overhead

RFC 6719 Recommendation: Hysteresis threshold should be at least MinHopRankIncrease to prevent thrashing. Most implementations use 1.5-2.0× as default.

Practical Impact - Manufacturing Network (2020):

150 sensors in metal fabrication shop (high interference)
Without hysteresis: 12 parent switches per node per hour → 1,800 DAO msgs/hour
With 2× threshold: 1 parent switch per node per hour → 150 DAO msgs/hour
Result: 92% reduction in control overhead, battery life increased 18 months → 24 months

32.5 How It Works: Parent Selection with Multiple Candidates

When a node receives DIO messages from multiple potential parents, it must systematically evaluate each option to select the optimal path to the root. Here’s the detailed decision process:

Step 1: Collect Candidate Information Node E hears DIOs from nodes A and B within a single Trickle interval. Each DIO contains: - Sender’s RANK (A: 256, B: 256) - DODAG ID (same for both - they’re in the same DODAG) - DODAG Version (same - network is consistent) - Objective Function parameters (ETX-based OF0)

Step 2: Measure Link Quality Node E measures the Expected Transmission Count (ETX) to each candidate: - Link E→A: ETX = 1.5 (measured via probe packets or historical delivery ratio) - Link E→B: ETX = 1.0 (excellent link quality)

ETX represents how many transmissions are needed on average for successful delivery. Lower ETX = better link.

Step 3: Calculate Candidate RANK Using the RPL formula: RANK = Parent_RANK + (MinHopRankIncrease × ETX)

Via A: RANK_E = 256 + (256 × 1.5) = 640 Via B: RANK_E = 256 + (256 × 1.0) = 512

Step 4: Compare and Select Node E compares the calculated RANK values: - 512 (via B) < 640 (via A) - Decision: Select B as preferred parent

Step 5: Store Backup Parent Node E stores A as a backup parent (RANK 640 is still valid, just not optimal). If B fails later, E can immediately switch to A without waiting for new DIOs.

Why This Matters: This process demonstrates RPL’s core innovation - link quality determines the routing tree, not just physical proximity. Node E might be physically closer to A, but the better radio link to B makes it the superior choice. This ETX-based selection results in more reliable end-to-end paths and fewer retransmissions, saving energy across the entire network.

32.6 Concept Relationships

This worked example connects to several RPL concepts:

Applies Concepts From:

RPL Introduction - Uses RANK, MinHopRankIncrease, and Objective Functions
RPL DODAG Construction - Follows the 5-phase construction algorithm
RPL DODAG Visual Guide - Shows the same network with actual numbers

Demonstrates:

ETX-based routing decisions - Why link quality matters more than hop count
Parent selection algorithm - How nodes evaluate multiple candidates
Backup parent storage - Fault tolerance mechanism

Leads To:

RPL Routing Modes - Understanding how data flows through this DODAG
RPL Production Deployment - Real-world RANK calculations in large networks

Contrasts With:

Hop-count routing (OF0 without ETX) - Would make different parent choices
Static routing - No dynamic adaptation to link quality changes

32.7 See Also

RPL Specifications:

RFC 6550 Section 8.5: “Parent Selection” - Formal parent selection algorithm
RFC 6552: “Objective Function Zero (OF0)” - The objective function used in this example
RFC 6719: “MRHOF (Minimum Rank with Hysteresis)” - Alternative objective function

Related Examples:

RPL DODAG Construction - Step-by-step algorithm
RPL Labs and Quiz - Design your own 10-node network

Implementation Guides:

Contiki-NG RPL Tutorial - Hands-on code walkthrough of parent selection
RIOT OS RPL Module - Implementation-level details

Academic Papers:

Winter et al. “RPL: IPv6 Routing Protocol for Low-Power and Lossy Networks” - Original RFC 6550 paper
Tripathi et al. “Performance Evaluation of RPL” - Empirical analysis of RANK-based routing

Tools:

Wireshark RPL Dissector - Capture real DIO messages and see RANK calculations
Cooja Network Simulator - Simulate this exact 10-node topology

32.8 Try It Yourself

Exercise 1: Add Node J to the Network

A new smart light (Node J) is installed with the following link qualities: - J to G: ETX = 1.2 - J to H: ETX = 1.8

Questions: 1. What RANK will Node J calculate via each candidate parent? 2. Which parent will J select, and why? 3. What is the total path cost (cumulative ETX) from J to ROOT? 4. If link J→G degrades to ETX = 2.5, will J switch parents? (Consider hysteresis threshold = 384)

Exercise 2: Network Failure Scenario

Node B experiences a power failure and goes offline.

Tasks: 1. List all nodes affected by this failure (hint: check parent relationships) 2. Calculate new RANK values for affected nodes using backup parents 3. Estimate convergence time if Trickle Imin = 4 seconds, max 4 doublings before detection 4. Compare battery life impact: 60 seconds with suboptimal routes vs immediate failover

Exercise 3: Optimize for Different Objectives

Recalculate the network using different objective functions:

Hop Count Only (ignore ETX):

RANK = Parent_RANK + 256 (fixed increment)
Which nodes select different parents compared to ETX-based?
What is the maximum hop count to ROOT?

Energy-Aware (battery level):

Node A: 80% battery, Node B: 30% battery
RANK = Parent_RANK + (256 × ETX) + (100 - Battery%)
How does this change Node E’s parent selection?
What is the trade-off in path quality?

Expected Insights:

Hop-count routing creates shorter but less reliable paths
Energy-aware routing extends network lifetime but increases latency
ETX-based routing (our example) balances reliability and path length

Match: DODAG Nodes and Their Properties

Order: DODAG Construction Steps in the Worked Example

Key Concepts

RANK Increment: The value added to a parent’s RANK to calculate the child’s RANK; determined by the Objective Function and link metric.
MinHopRankIncrease: A per-DODAG parameter setting the minimum RANK increment between parent and child, ensuring the DODAG doesn’t become too flat.
Preferred Parent: The selected parent node through which all upward traffic flows by default; chosen based on best path to root by the Objective Function.
Backup Parent: An alternative parent node maintained in the parent set for failover when the preferred parent becomes unreachable.
ETX-based RANK: RANK calculation using MRHOF Objective Function where RANK increment = ETX × MinHopRankIncrease; favors reliable links over simply minimizing hop count.

Common Pitfalls

1. Using Worked Examples With Simplified ETX Values

Worked examples often use integer ETX values (1.0, 1.5, 2.0) for clarity. Real ETX values are measured continuously and fluctuate — actual RANK calculations involve moving averages of ETX that produce non-integer values.

2. Not Tracing Both Upward and Downward Paths in Examples

Worked examples that only trace the upward (MP2P) path miss the downward routing complexity. Practice tracing Storing Mode downward routes through the DAO tables built at each router.

3. Skipping the Convergence Timing Calculation

Worked examples should include not just the final DODAG structure but also the convergence time estimate. DODAG convergence time depends on Trickle parameters and hop depth — calculate it for each example.

🏷️ Label the Diagram

Code Challenge

32.9 Summary

This worked example demonstrated:

RANK Calculation: Using MinHopRankIncrease x ETX formula
Parent Selection: Choosing lowest cumulative path cost
Multi-Option Decisions: Comparing candidates when multiple parents available
Final Structure: Hierarchical tree with RANK-based routing
Routing Implications: Upward via parent pointers, downward via DAO tables
Fault Tolerance: Backup parents enable automatic recovery

32.10 Knowledge Check

Quiz: RPL DODAG Example

32.11 What’s Next

Next	Chapter
Visualize	RPL DODAG Visual Guide
Trace messages	RPL DODAG Message Flow
Energy efficiency	RPL Trickle Algorithm
Overview	RPL DODAG Construction