24  RPL: Smart Lighting Example

In 60 Seconds

Step-by-step worked example of DODAG construction for a 10-node smart lighting network, calculating RANK values using actual RPL parameters and ETX-based objective functions. Demonstrates parent selection when multiple candidate parents exist and shows how link quality determines the final routing topology.

24.1 Worked Example: DODAG Construction Step-by-Step

Learning Objectives

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

• Calculate RANK values using MinHopRankIncrease and ETX parameters for any network topology
• Evaluate parent selection with multiple candidate parents based on cumulative path cost
• Apply objective function formulas (OF0 with ETX) to real network scenarios
• Interpret final DODAG structure for upward, downward, and fault-tolerant routing

For Beginners: RPL Smart Lighting Example

This chapter shows RPL in action with a real-world scenario: smart street lighting. You will see how streetlight sensors form a network, choose routing paths, and deliver data to a central controller – making the abstract concepts of RPL concrete through a practical everyday example.

Sensor Squad: Streetlights Finding Their Way!

“Picture nine streetlights in a parking lot, all trying to report their status to a central controller,” said Sammy the Sensor. “That controller is the root of our DODAG tree.”

“Each streetlight measures how reliable its connection is to its neighbors using ETX – Expected Transmission Count,” explained Max the Microcontroller. “If a link has ETX of 1.0, that means every packet gets through on the first try. An ETX of 2.0 means you need two tries on average. Lower ETX is better!”

“Watch what happens when Streetlight 7 can hear two parents,” added Lila the LED. “Through Parent A, its total RANK would be 768. Through Parent B, its total RANK would be 640. So it picks Parent B – even though Parent B might be physically further away! That is the beauty of ETX-based routing.”

“By the end of this example, every streetlight has a clear path to the controller,” concluded Bella the Battery. “And the path is not the shortest in distance – it is the most reliable in terms of packet delivery. That is what makes RPL so smart for IoT networks!”

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.

24.2 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

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

Graph diagram

Figure 24.1: 9-node DODAG showing RANK hierarchy and parent selection

24.4 Solution: Step-by-Step DODAG Construction

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

---

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

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

---

24.4.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 to C to 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.

---

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

---

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

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

Mermaid diagram

Figure 24.2: DAO upward propagation and aggregation sequence

---

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

Graph diagram

Figure 24.3: Final DODAG structure with RANK values and backup parents

Putting Numbers to It

Quantifying DAO Propagation Delay in Layered DODAG

For our 10-node smart lighting network, calculate the complete cold-start convergence time from power-on to full routing:

DIO propagation (3 layers, Imin = 10ms): \(t_{\text{layer}} = t_{\text{DIO}} + t_{\text{process}} = 10\text{ ms} + 5\text{ ms} = 15\text{ ms}\) \(t_{\text{DIO total}} = 3 \times 15\text{ ms} = 45\text{ ms}\)

DAO upward propagation (Storing mode, 50ms/hop): \(t_{\text{layer 3}} = 3\text{ hops} \times 50\text{ ms} = 150\text{ ms}\) (G→D→A→ROOT) \(t_{\text{layer 2}} = 2\text{ hops} \times 50\text{ ms} = 100\text{ ms}\) (D→A→ROOT) \(t_{\text{layer 1}} = 1\text{ hop} \times 50\text{ ms} = 50\text{ ms}\) (A→ROOT)

Trickle stabilization (reaching Imax = 2^6 × Imin): \(t_{\text{stable}} = \sum_{i=0}^{6} 2^i \times 10\text{ ms} = 1270\text{ ms} \approx 1.3\text{ s}\)

Total cold-start convergence: \(t_{\text{total}} = 45 + 150 + 1300 = 1495\text{ ms} \approx \mathbf{1.5\text{ seconds}}\)

With retransmissions and safety margins for lossy links (ETX 1.5 on some hops), expect 2-3 seconds for complete network initialization.

24.5 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

24.5.1 Interactive: Verify the RANK Calculations

Use this calculator to reproduce any RANK value from the table above. Enter a parent’s RANK and the link ETX to see the child’s RANK:

viewof calcParentRank = Inputs.range([0, 1024], {value: 256, step: 256, label: "Parent RANK"})

viewof calcEtx = Inputs.range([1.0, 3.0], {value: 1.0, step: 0.1, label: "Link ETX to parent"})

calcChildRank = calcParentRank + Math.round(256 * calcEtx)

html`<div style="background: var(--bs-light, #f8f9fa); padding: 1rem; border-radius: 8px; border-left: 4px solid #3498DB;">
<p><strong>Formula:</strong> RANK = ${calcParentRank} + (256 &times; ${calcEtx.toFixed(1)}) = <strong style="color: #16A085; font-size: 1.1em;">${calcChildRank}</strong></p>
<p style="color: #7F8C8D; font-size: 0.9em;">
  Try: Parent=0, ETX=1.0 &rarr; Node A/B (RANK 256) &nbsp;|&nbsp;
  Parent=256, ETX=1.5 &rarr; Node C (RANK 384) &nbsp;|&nbsp;
  Parent=512, ETX=2.0 &rarr; Node G via E (RANK 1024)
</p>
</div>`

24.6 Interpretation: How RANK Determines Routing

Upward Routing (Sensor Data to Cloud):

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

Downward Routing (Commands to Lights):

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

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 to B (256) to F (512) via common ancestor

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

1. RANK is cumulative: Each hop adds MinHopRankIncrease x ETX, not just +1
2. Link quality matters: Node F chose B over C despite C being available, because B offered better cumulative path quality
3. Multiple parents: Nodes can maintain backup parents for resilience (A as backup for E)
4. Unbalanced trees are OK: Node B has 4 descendants (E, F, H, I indirectly), while C has none - this is optimal given link quality
5. RANK inversion = loop: If Node H somehow got RANK < 512, it would create a loop with E - RPL prevents this
6. MinHopRankIncrease = 256: This standard value allows for 16 sub-levels (256/16=16) of rank differentiation per hop for fine-grained path selection

24.7 Detailed Construction Steps

Step 1: Root Initiates DODAG

Root node (border router/gateway): 1. Creates DODAG: Assigns unique DODAG ID 2. Sets RANK = 0: Root has minimum RANK 3. Broadcasts DIO: Sends DODAG Information Object (multicast)

DIO Contents:

• DODAG ID (IPv6 address)
• RANK (0 for root)
• Objective function (routing metric)
• DODAG configuration (timers, etc.)

See Solution Step 1 above for the complete DIO message example from the smart lighting network.

## Step 2: Nodes Receive DIO and Join {#net-rpl-fund-step2}

Node receives DIO:

1. Decision: Join this DODAG or wait for others?
   • Compare DODAG rank, objective function
   • May receive DIOs from multiple DODAGs
2. Calculate RANK: RANK = parent_RANK + increase
3. Select parent: Choose sender of DIO (if acceptable)
4. Update state: Store DODAG ID, parent, RANK

Multiple DIO Sources:

• Node may hear DIOs from multiple neighbors
• Chooses best parent (lowest RANK, best link quality)
• May maintain backup parents (loop-free)

Quiz 1: Step 2: Nodes Receive DIO and Join

24.8 Step 3: Nodes Propagate DIO

After joining DODAG:

1. Node becomes part of DODAG
2. Sends own DIO: Advertises DODAG to neighbors
3. DIO contents: Own RANK, DODAG ID, etc.
4. Trickle timer: Controls DIO frequency (adaptive)

Trickle Algorithm:

• Stable network: Send DIOs infrequently (minutes)
• Network changes: Send DIOs frequently (seconds)
• Reduces overhead while maintaining responsiveness

Step 4: Build Upward Routes

Upward routes (towards root) established automatically: - Each node knows its parent (from DIO selection) - Default route: Send to parent (towards root) - No routing table needed for upward routes (just parent pointer)

Example:

Node 3 -> Node 1 -> Root
(N3 knows parent is N1, N1 knows parent is Root)

Step 5: Build Downward Routes (Storing Mode)

Downward routes (from root to nodes) require DAO messages:

1. Node sends DAO to parent:
   • “I am reachable via you”
   • Includes node’s address and prefixes
2. Parent updates routing table:
   • “Node X is reachable via this child”
3. Parent propagates DAO towards root:
   • Aggregates reachability information
4. Root knows all nodes:
   • Complete routing table for downward routes

DAO-ACK (optional): - Parent confirms DAO receipt - Reliability for critical networks

Quiz 2: Step 5: Build Downward Routes (Storing Mode)

24.9 Contiki-NG: RPL Configuration in Code

The DODAG construction we calculated above happens automatically in Contiki-NG’s RPL implementation. Here is how you configure the key parameters:

/* project-conf.h -- RPL configuration matching our worked example */
#include "contiki-default-conf.h"

/* Objective Function: OF0 with ETX metric (matching our example) */
#define RPL_CONF_OF_OC            rpl_of0
#define RPL_CONF_WITH_MC          1

/* MinHopRankIncrease = 256 (RFC 6550 default, matches our calculation) */
#define RPL_CONF_MIN_HOPRANKINCREASE  256

/* Storing mode: each node maintains routing table for downward routes */
#define RPL_CONF_WITH_STORING     1

/* Maximum number of parents in parent set (for backup parents) */
/* Node E stored both B (primary) and A (backup) in our example */
#define RPL_CONF_MAX_PARENTS      4

/* Trickle timer: controls DIO interval (adaptive) */
#define RPL_CONF_DIO_INTERVAL_MIN     12   /* 2^12 ms = 4.096 sec min */
#define RPL_CONF_DIO_INTERVAL_DOUBLINGS 8  /* Max: 4.096s x 2^8 = 17.5 min */

/* DAO configuration for downward route establishment (Step 5) */
#define RPL_CONF_DAO_ACK          1  /* Request DAO acknowledgements */

/* smart-light.c -- Node application */
#include "contiki.h"
#include "net/routing/routing.h"
#include "net/ipv6/simple-udp.h"

#define UDP_PORT 5678

PROCESS(smart_light_process, "Smart Light");
AUTOSTART_PROCESSES(&smart_light_process);

/* Callback: prints current RANK and parent address */
static void check_rpl_status(void) {
  if (NETSTACK_ROUTING.node_is_reachable()) {
    rpl_dag_t *dag = rpl_get_any_dag();
    if (dag != NULL) {
      /* This prints the RANK values we calculated:
         Node A: 256, Node D: 512, Node G: 768, etc. */
      printf("RANK: %u, Parent: ", dag->rank);
      uip_debug_ipaddr_print(
        rpl_parent_get_ipaddr(dag->preferred_parent));
      printf("\n");
    }
  }
}

/* What to observe:
 * - RANK values match our manual calculations (256, 512, 768)
 * - Parent selection follows lowest-RANK path (same as Step 3)
 * - If you disconnect Node B, Node E switches to backup parent A
 *   and its RANK increases from 512 to 640 (same as our fault
 *   tolerance analysis)
 */

Why Contiki-NG Matches Our Calculation

The hand-calculated RANK values in this chapter are exactly what Contiki-NG computes internally. When Node E evaluates two DIO senders:

1. Via B: parent_rank(256) + MinHopRankIncrease(256) x ETX(1.0) = 512
2. Via A: parent_rank(256) + MinHopRankIncrease(256) x ETX(1.5) = 640

It selects B (RANK 512 < 640) and stores A as backup – the same decision we made in Step 3. Understanding the math lets you predict and debug RPL behavior in real deployments.

Knowledge Check: RANK and Routing

24.10 Energy Impact of RANK Decisions

Parent selection affects not just reliability but also energy consumption. Let’s calculate the difference:

Scenario: Node G sends 100-byte sensor reading to ROOT every 5 minutes.
Radio: CC2650 (TX: 9.1 mA, RX: 6.1 mA, sleep: 0.001 mA)
TX time per hop: 3.2 ms at 250 kbps (802.15.4)

Path via D (selected, RANK 768):
  G -> D: ETX 1.0 -> avg 1 transmission  -> 3.2 ms TX
  D -> A: ETX 1.0 -> avg 1 transmission  -> 3.2 ms TX
  A -> ROOT: ETX 1.0 -> avg 1 transmission -> 3.2 ms TX
  Total TX time: 3 x 3.2 ms = 9.6 ms
  Energy per message: 9.6 ms x 9.1 mA = 87.4 uAs

Path via E (rejected, RANK 1024):
  G -> E: ETX 2.0 -> avg 2 transmissions -> 6.4 ms TX
  E -> B: ETX 1.0 -> avg 1 transmission  -> 3.2 ms TX
  B -> ROOT: ETX 1.0 -> avg 1 transmission -> 3.2 ms TX
  Total TX time: 6.4 + 3.2 + 3.2 = 12.8 ms
  Energy per message: 12.8 ms x 9.1 mA = 116.5 uAs

Savings from RPL's optimal parent selection:
  Per message: 116.5 - 87.4 = 29.1 uAs saved (25% less energy)
  Per day (288 messages): 8.4 mAs saved
  Per year: 3.06 Ah saved

With 2x AA batteries (3000 mAh each):
  Optimal path: battery lasts ~6.5 years
  Suboptimal path: battery lasts ~4.9 years

RPL's RANK-based parent selection extends battery life by 1.6 years.

Match: Smart Lighting Network RANK Values

Order: Parent Selection Decision Process for Node E

Key Concepts

• RANK Calculation Walk-Through: A step-by-step trace of how each node in a DODAG computes its RANK from the root’s initial RANK using the configured Objective Function.
• Parent Set Construction: The process of identifying candidate parent nodes with lower RANK that meet link quality thresholds and building the preferred/backup parent set.
• DODAG Convergence Trace: A time-sequence analysis showing how RANK values propagate through the network from root to leaf as DIO messages are exchanged.
• ETX Link Cost: The expected transmission count for a specific link, derived from packet reception ratio measurements; lower ETX means higher quality link.
• RANK Comparison Rule: A node must only choose parents with strictly lower RANK (not equal) to prevent routing loops in the upward direction.

Common Pitfalls

1. Worked Example ETX Values Don’t Match Real Measurements

Worked examples use simplified integer ETX values (1, 2, 3). Real ETX measurements are continuously updated sliding averages that fluctuate based on RF conditions. The worked example logic is correct, but expect non-integer ETX in real systems.

2. Not Checking Feasibility Condition in Parent Selection

RPL’s MRHOF uses a feasibility condition to prevent loops even during topology transitions. A potential parent with a RANK that would cause the node’s RANK to not decrease is rejected even if its RANK is lower. Many simplified examples skip this detail.

3. Applying Worked Example Network Sizes to Production Design

A 5-node worked example demonstrates the algorithm but doesn’t reveal scaling behaviors. Run worked examples at 20+ nodes to understand how RANK values scale and where bottlenecks form.

🏷️ Label the Diagram

Code Challenge

24.11 Summary

This worked example demonstrated:

• RANK Calculation: Using MinHopRankIncrease x ETX formula to compute cumulative path cost
• Parent Selection: Comparing multiple candidate parents and choosing the one offering lowest RANK
• Link Quality Impact: How poor links (high ETX) cause nodes to prefer longer paths with better quality
• Backup Parents: Maintaining alternate routes for fault tolerance
• Routing Interpretation: How RANK determines upward, downward, and point-to-point routing paths

24.12 Concept Relationships

This worked example synthesizes multiple RPL concepts:

Applies:

• RANK calculation from RPL Introduction
• DODAG construction from RPL DODAG Construction
• Parent selection algorithm from RFC 6550 Section 8.5

Demonstrates:

• ETX-based objective function (OF0 with ETX metric)
• Multi-candidate parent evaluation
• Backup parent storage for fault tolerance
• Link quality vs hop count trade-off

Prerequisites:

• RPL DODAG Visual Guide - Understanding formation phases
• MinHopRankIncrease concept (256 default)
• Expected Transmission Count (ETX) metric

Leads To:

• RPL Trickle and Modes - How this DODAG is maintained
• RPL Labs - Design your own networks with calculations
• Implementation on Contiki-NG - Code example section shows real deployment

Related Calculations:

• Energy impact analysis - Battery life estimation
• Parent hysteresis - Preventing parent flapping
• Contiki-NG code mapping - Theory to practice

24.13 See Also

Core Specifications:

• RFC 6550 Section 8.5: “Parent Selection” - Official algorithm
• RFC 6552: “Objective Function Zero (OF0)” - RANK calculation formula
• RFC 6719: “MRHOF” - Alternative objective function with hysteresis

Related Examples:

• RPL DODAG Construction - General algorithm
• RPL DODAG Visual Guide - Step-by-step diagrams
• RPL Labs and Quiz - Practice problems

ETX Metric Resources:

• De Couto et al. “A High-Throughput Path Metric for Multi-Hop Wireless Routing” - Original ETX paper
• RFC 6551: “Routing Metrics for RPL” - ETX and other metrics
• Contiki-NG ETX Calculation - Implementation details

Implementation Guides:

• Contiki-NG RPL Tutorial - Hands-on code walkthrough
• RIOT OS RPL Example - Alternative implementation
• Zephyr RPL Sample - Embedded Linux RPL

Debugging Tools:

• Wireshark RPL Dissector - Capture DIO messages, see RANK values
• Cooja Network Simulator - Simulate this 10-node topology
• RPL Debug Console - Monitor parent selection in real-time

Academic Papers:

• Tripathi et al. “Performance Evaluation of RPL” - Empirical RANK analysis
• Korte et al. “RPL: Routing for the Internet of Things” - Comprehensive overview
• Clausen et al. “A Critical Evaluation of RPL” - Protocol analysis

Comparison Topics:

• Hop Count vs ETX - Why link quality matters
• OF0 vs MRHOF - When to use hysteresis
• Static vs Dynamic Routing - Adaptation benefits

24.14 What’s Next

Next	Chapter
Trickle and modes	RPL Trickle and Routing Modes
Visual guide	RPL DODAG Visual Guide
Practice	RPL Labs and Quiz
Series overview	RPL Fundamentals and Construction