4 Routing in Low-Power IoT Networks

4.2 Overview: IoT Routing Starts With Constraints

IoT routing is not ordinary Internet forwarding placed on smaller devices. Wireless links may lose messages. Devices may sleep, store only a few routes, and have little power. Most devices may send toward one gateway. A route can look correct in a diagram yet fail when a relay sleeps, the system chooses a weak parent, or nobody tests the return path.

A directed acyclic graph is a set of one-way links that never forms a loop. RPL builds a destination-oriented form of this graph, called a DODAG. The graph points toward a border router at its root. Each device chooses a preferred parent. An Objective Function is the rule used for that choice, such as preferring a stronger or cheaper link.

Begin the review with the way the network is used. A meter that reports once an hour needs different proof from an irrigation controller that must receive a command within a time limit. A moving asset needs another kind of proof because it may change parents during the day.

Use Figure 4.1 to see which link-quality evidence causes a node to leave its old parent and whether the replacement restores forwarding without a loop.

+

Read Figure 4.1 from the old parent and its degraded link to the new parent selected by node N. The next relay changes first, and the Rank update records the node’s new position relative to the root. Those control changes are necessary but do not by themselves prove recovery. Capture the candidate metrics, switch event, advertised Rank, and loop check, then send the required application traffic through the repaired path. Delivery and recovery time complete the evidence that the graph was maintained rather than merely redrawn.

4.3 Practitioner: Write the RPL Fit Record

A practical routing record should let another engineer decide whether RPL is appropriate and whether the chosen parent, repair behavior, and return path were proven. Keep the record small, but make every claim testable.

Before deciding whether RPL fits, make the required routing evidence concrete. Figure 4.2 shows a worked preferred-parent tree and a storing-mode DIO/DAO sequence. Use it to identify what belongs in the fit record: the root, parent policy, Rank, traffic direction, routing mode, and the route state that must be tested. The example explains RPL operation; it does not by itself establish that RPL is the best choice for a deployment.

+

Read Figure 4.2 from C toward A and R to follow upward forwarding, then trace the advertisements in the right panel. The example fixes OF0 with MinHopRankIncrease 256 and equal unit steps, so Rank rises from 256 to 512 to 768 away from the root; other metrics or Objective Functions need not produce these values. In the storing-mode example, C’s DAO lets A install a route to C, and A advertises C’s target onward in a new DAO. Check the resulting downward route at each router and send a command from R to C. In non-storing mode, the DAO’s logical destination is the root, although the packet still travels through intermediate routers. Carry these distinctions into the record below and test repair and application delivery separately.

Use the record to choose the simplest routing approach that satisfies the claim. A fixed gateway subnet may need only a default route and return-path proof. A constrained mesh with lossy parent options may need RPL with an Objective Function that accounts for link quality and relay role. A mains-powered backhaul can use ordinary infrastructure routing outside the constrained domain.

4.4 Under the Hood: Parent Choice and Repair Are the Boundary

RPL parent selection is local but not arbitrary. A node hears DIO information, filters incompatible candidates, applies the Objective Function, computes Rank, and chooses one or more candidate parents. Upward forwarding should move toward lower Rank, while downward reachability depends on the selected routing mode and DAO behavior when that traffic is required.

Rank is not just hop count. A design can prefer a slightly longer path if it has better link evidence, a more suitable relay role, or a lower expected transmission cost. Hysteresis matters because frequent parent changes can waste control traffic and hide instability until queues, retries, or missed commands expose it.

Repair is the other half of the boundary. A node that finds a better parent, loses a parent, or hears a new DODAG version changes both forwarding behavior and review evidence. Capture the control-plane trigger, the chosen replacement, the packets sent during the change window, and whether downward state was refreshed when commands depend on it.

Keep the failure window explicit. If telemetry succeeds during repair but commands fail afterward, the evidence points to a different route-state question than a total loss of upward forwarding.

Two named variants show why protocol labels need their mechanism recorded. Cognitive RPL (CORPL) keeps the DODAG concept but routes through a forwarding set rather than relying only on parent forwarding state; DIO messages update neighbours as that set forms. Channel-Aware Routing Protocol (CARP) addresses underwater communication instead: a root broadcasts HELLO packets during network initialization, then data travels hop by hop from nodes toward the root. These are distinct routing mechanisms for distinct environments, not interchangeable transport protocols.

Check Figure 4.3 while working through Under the Hood: Parent Choice and Repair Are the Boundary. The asset depicts how upward telemetry and downward commands are different claims. A formed DODAG is not proof that both directions work, which identifies the concrete observation that the surrounding prose is about to use.

+

Follow C’s two directions in Figure 4.3 using the worked storing-mode example. A reading travels C → A → R through preferred parents. For a command back to C, check that R’s next hop is A and A’s next hop is C, then test R → A → C. After C changes parent, refresh the downward entries and repeat the command; the earlier successful reading cannot prove the repaired return path.

Use Figure 4.4 to choose post-repair packet checks from the different locations where storing and non-storing modes keep downward state.

+

Figure 4.4 contrasts storing mode, where intermediate routers retain tables for local hop-by-hop downward forwarding, with non-storing mode, where the root owns the path and supplies source-route information. The placement of state determines the repair test. After a parent change in storing mode, inspect affected router entries; after a root or topology change in non-storing mode, inspect the root’s path view and packet header. In both cases, send the downward command after control state settles. Restored upward telemetry proves neither route location nor return-path delivery.