Measure RPL sink reboot and delivery recovery

Measure a root reboot delivery gap using numbered upward packets and actual RPL control traffic.

A packet you cannot trace is a claim you cannot defend: name the address, the route, and the hop that dropped it., your practice guide

A packet you cannot trace is a claim you cannot defend: name the address, the route, and the hop that dropped it.
Predict the reading, then compare it with the measurement.

Contiki-NG Cooja

Third party Tool

Measure a root reboot delivery gap using numbered upward packets and actual RPL control traffic.

Tier 2 · Free simulator · install required · No account

Version tested: Contiki-NG release/v4.9 c20b12cd, Cooja 4.8 (2022071901), Temurin 17.0.20.1, image sha256:b14d5afb0a2a852d9e72bbed607ead03f6ccc5f4d4dee44f0799110be2f4b609. Date: 2026-10-09.

Download the complete lab packet and follow README.md to run it in the free simulator.

Download the setup and run guide

Get the lab files

Download the complete packet for the simulation and its firmware, or download individual files for inspection. README.md gives the setup and run commands.

Steps

Screens captured against Contiki-NG Cooja Contiki-NG release/v4.9 c20b12cd, Cooja 4.8 (2022071901), Temurin 17.0.20.1, image sha256:b14d5afb0a2a852d9e72bbed607ead03f6ccc5f4d4dee44f0799110be2f4b609 on 2026-10-09; the tool may have moved on — the text steps are the contract.

  1. Step 1

    Do
    Open the CSC in Cooja Network and identify the three-link route from sender 4 through relays 3 and 2 to sink 1.
    You will see
    Run: seed 1; adjacent motes 40 m apart; UDGM range 50 m. Serial: `70975000 ID:4 SEQ_SEND node=4 seq=3` Serial: `71035792 ID:1 [INFO: App ] Received request 'SEQ:3' from fd00::204:4:4:4` Radio messages: 112 cumulative frames at 75 s.
    Why it matters
    Meaning: Before the reboot, the sink receives sender 4's numbered traffic over the chain. Boundary: Early receipt does not establish failover performance.

  2. Step 2

    Do
    Click Start/Pause and inspect Network and the Simulation script editor log for the sink removal marker; compare Mote output for the next sender sequence.
    You will see
    Script: `SINK_REBOOT phase=down node=1 removed_instance=true at_us=95549000` Serial: `91030792 ID:1 [INFO: App ] Received request 'SEQ:7' from fd00::204:4:4:4` Serial: `95980000 ID:4 SEQ_SEND node=4 seq=8` Network at 100 s: mote 1 is absent.
    Why it matters
    Meaning: Only the sink disappears while sender 4 continues its synthetic sequence. Boundary: A send log is not a sink receipt.

  3. Step 3

    Do
    Click Start/Pause and inspect Network, Radio messages, and Mote output while the sink remains absent.
    You will see
    Serial: `120984000 ID:4 SEQ_SEND node=4 seq=13` Root 1: no receipt for sequences 8–13 during its 30-second absence. Radio messages: 254 cumulative frames by 120 s; relay DIS/DIO/DAO activity remains visible.
    Why it matters
    Meaning: The application sequence advances through the outage and control traffic continues. Boundary: Cumulative radio frames do not measure application delivery.

  4. Step 4

    Do
    Click Start/Pause and inspect the returned sink in Network and the DIO/DIS messages in Mote output.
    You will see
    Script: `SINK_REBOOT phase=up node=1 fresh_instance=true at_us=125549000` Serial: `195984000 ID:4 SEQ_SEND node=4 seq=28` At 200 s, the root is present but no post-restart application receipt has appeared. Radio messages: 284 cumulative frames.
    Why it matters
    Meaning: A fresh sink instance and control traffic are visible before delivery repairs. Boundary: Seeing DIO/DIS alone is not packet acceptance.

  5. Step 5

    Do
    Click Start/Pause and locate the first recovered sink receipt in Mote output, then read the ScriptRunner first-recovery marker.
    You will see
    Serial: `465985000 ID:4 SEQ_SEND node=4 seq=82` Serial: `466071824 ID:1 [INFO: App ] Received request 'SEQ:82' from fd00::204:4:4:4` Script: `FIRST_RECOVERED seq=82 at_us=466071824` Radio messages: 398 cumulative frames at 470 s.
    Why it matters
    Meaning: Delivery resumed 370.522824 s after removal and 340.522824 s after restart. Boundary: This seed's slow recovery is not a general RPL timer.

  6. Step 6

    Do
    Click Start/Pause and reconcile the sequence gap and later sink receipts in Mote output with the raw headless summary.
    You will see
    Root: last pre-reboot receipt was sequence 7; first recovered was 82; missing sequence numbers 8–81 count 74. At 490 s, root has received later sequences 83–86. Headless: `REBOOT_SUMMARY last_before=7 first_after=82 missing_seq=74 reboot_us=95549000 restart_us=125549000 first_delivery_us=466071824 recovery_from_reboot_ms=370522.824 recovery_after_restart_ms=340522.824 control_after=310 sent=89 delivered=15` Headless: `TEST OK`
    Why it matters
    Meaning: The packet sequence makes the operational delivery gap explicit. Boundary: This upward packet test does not validate root-to-node commands or field failover.

Chapter checks

These questions refer to the chapter’s examples. Use the return links to review their answers.

  1. A framework record accepts an RPL design using only a diagram and default settings. What should the review do?

    Return to the chapter’s knowledge check

  2. A review record shows compatible DIO messages, a selected preferred parent, and successful node-to-root telemetry packets. The same record also claims that the root can command every node. What is missing before the downward-command claim should be accepted?

    Return to the chapter’s knowledge check

Return to RPL Production Framework · Browse Labs