PaperlayerView exact revision on arXiv

Source-linked AI summary

A Survey of Limitations and Enhancements of the IPv6 Routing Protocol for Low-power and Lossy Networks: A Focus on Core Operations

Baraq Ghaleb, Ahmed Al-Dubai, Elias Ekonomou, Ayoub Alsarhan, Youssef Nasser, Lewis Mackenzie, Azzedine Boukerche

arXiv:1902.01888v1cs.NI

TL;DR

RPL extensions have been proposed to address reported weaknesses in the protocol’s core operations, but the survey finds that many limitations remain unresolved. It reviews the proposed solutions and their pitfalls, identifying a need for further research.

  • Problem

    RPL has reported limitations in its core operations, and the survey asks whether proposed extensions have overcome them.

    Source: §IV · p. 11, §VI · p. 25

  • Method

    The paper surveys and comparatively analyzes RPL extensions addressing objective functions, routing maintenance, and downward routing, including their challenges and pitfalls.

    Source: §VII · pp. 26–27

  • Results

    RPL extensions have only partially addressed its limitations, with efficient downward-route construction, load-balancing, and metric composition among the issues not successfully resolved.

    Source: A. Contribution of the Survey · p. 2, §VI · p. 25

  • Takeaways & Limitations

    Further research is needed to address RPL limitations that proposed extensions have not fully overcome.

    Source: A. Contribution of the Survey · p. 2, §VI · p. 25

    The survey focuses on reported RPL limitations related to objective functions, downward routing, and routing maintenance.

    Source: §IV · p. 11

Abstract

from arXiv · show

Driven by the special requirements of the Lowpower and Lossy Networks (LLNs), the IPv6 Routing Protocol for LLNs (RPL) was standardized by the IETF some six years ago to tackle the routing issue in such networks. Since its introduction, however, numerous studies have pointed out that, in its current form, RPL suffers from issues that limit its efficiency and domain of applicability. Thus, several solutions have been proposed in the literature in an attempt to overcome these identified limitations. In this survey, we aim mainly to provide a comprehensive review of these research proposals assessing whether such proposals have succeeded in overcoming the standard reported limitations related to its core operations. Although some of RPL weaknesses have been addressed successfully, the study found that the proposed solutions remain deficient in overcoming several others. Hence, the study investigates where such proposals still fall short, the challenges and pitfalls to avoid, thus would help researchers formulate a clear foundation for the development of further successful extensions in future allowing the protocol to be applied more widely.

I. INTRODUCTION1

LLNs make efficient routing difficult because devices and links are constrained, while deployments may scale to thousands of nodes. This survey reviews RPL’s core limitations and assesses whether proposed extensions overcome them.

I. INTRODUCTION1

  • LLNs combine constrained node resources and unreliable, low-capacity links, making efficient routing difficult at potentially large scale.Deployments may comprise thousands of nodes or more.Source: §I · p. 1

C. Organization of the Survey

A. Contribution of the Survey

  • The survey reviews proposed remedies for RPL’s reported limitations and finds that extensions have addressed them only partially.Efficient downward-route construction, load-balancing, and metric composition remain unresolved issues.Source: A. Contribution of the Survey · pp. 1–2

B. Overview of Related Survey Articles

  • Unlike earlier surveys that mainly examine RPL itself, this work assesses whether research proposals have overcome limitations in its core operations.Its focus includes objective functions, downward routing, and routing maintenance.Source: B. Overview of Related Survey Articles · pp. 2–3

II. LOW-POWER AND LOSSY NETWORKS

  • The paper introduces LLNs and their routing challenges and requirements in the IoT context.Source: §II · p. 3

A. LLN Characteristics

LLNs encompass resource-constrained devices and variable, lossy communication technologies, so routing must accommodate diverse applications and network conditions. The section reviews the standards and radio technologies used in these networks and the resulting design challenges.

A. LLN Characteristics

  • LLNs connect constrained devices to the external world through a border router, while host capabilities vary from severely constrained Class 0 devices to less constrained Class 2 devices.Class 0 devices have no more than 10 KiB of memory and need gateway assistance for communications.Source: A. LLN Characteristics · p. 3

B. LLN Standards and Radio Technologies

  • IEEE 802.15.4 provides a low-rate wireless foundation with a 127-byte MTU, and its MAC uses CSMA/CA.Only up to 116 bytes are available for an upper-layer protocol.Source: 1) IEEE 802.15.4 (Layers 1 and 2) · p. 4

2) 6LoWPAN (Layer 2.5)

  • 6LoWPAN inserts an adaptation layer between IEEE 802.15.4 and IPv6 to compress headers and fragment and reassemble packets.This bridges the 127-byte IEEE 802.15.4 MTU and IPv6’s minimum 1280-byte datagram size.Source: 2) 6LoWPAN (Layer 2.5) · p. 4

3) IEEE 802.15.4e TSCH and IETF 6TiSCH (Layer 2)

  • TSCH combines TDMA scheduling and channel hopping, while 6TiSCH integrates TSCH with IPv6 and defines cell-management and distributed-scheduling mechanisms.TDMA reduces contention; channel hopping is intended to improve reliability and mitigate channel fading.Source: 3) IEEE 802.15.4e TSCH and IETF 6TiSCH… · p. 4

4) Other Communication Technologies

  • BLE and Wi-Fi HaLow offer wireless alternatives, while PLC reuses electrical wiring and can provide the longest range among the technologies described.Wi-Fi HaLow is described as reaching around a kilometer; PLC range is limited by the length of the electrical cables.Source: 4) Other Communication Technologies · pp. 4–5

C. Unique Routing Challenges in LLNs

  • Routing must serve diverse applications with conflicting requirements, communication patterns, reporting models, and deployment densities.LLNs include MP2P, P2MP, and P2P traffic; reporting may be query-, event-, or time-based, and density may range from a few to hundreds of neighbors per node.Source: C. Unique Routing Challenges in LLNs · p. 5
  • Routing must also conserve scarce energy while operating over links whose loss rates can be unpredictable or change over time, and sometimes account for mobile nodes.Update frequency should be sufficient to keep routes fresh while meeting the application energy budget.Source: C. Unique Routing Challenges in LLNs · p. 5

D. LLNs Routing Requirements

LLN routing requirements differ across home, building, industrial, and urban applications. Their traffic patterns, scale, mobility, energy sources, and latency needs vary substantially.

Home Automation

  • Home networks are typically small and shallow, but may include mobile devices and varied traffic; battery-powered nodes and fast convergence are important requirements.The section describes a typical diameter of five hops and convergence within half a second for stationary devices, relaxed to four seconds with mobility.Source: D. LLNs Routing Requirements · p. 6

Building Automation

  • Building networks mix P2P traffic with MP2P and P2MP traffic, may be divided into subnetworks of no more than 255 nodes, and include delay-sensitive critical applications.About 30% of traffic is expected to be P2P, with the remainder attributed to MP2P and P2MP.Source: D. LLNs Routing Requirements · pp. 6–7

Industrial LLNs

  • Industrial LLNs typically favor MP2P traffic, often comprise tens of devices, and may include battery-operated nodes requiring at least five years of lifetime.Mobile devices may reach 35 kph; convergence may take a few minutes for a new node, while established routes require latency of no more than ten seconds.Source: D. LLNs Routing Requirements · p. 7

Urban LLNs

  • Urban LLNs are expected to scale from hundreds to potentially tens of thousands or millions of nodes, with varied density, multi-hop paths, and battery lifetimes of 10–15 years.Alert traffic generally cannot tolerate waits of more than a few seconds, while latency requirements vary by reporting model.Source: D. LLNs Routing Requirements · p. 7

III. THE IPV6 ROUTING PROTOCOL FOR LLNS (RPL)

RPL is a proactive IPv6 distance-vector protocol for LLNs, optimized for data gathering and also supporting downward traffic. It builds a destination-oriented DAG and uses control messages to establish routes.

A. RPL Topology and Operations

  • RPL organizes the network as a destination-oriented DAG rooted at a destination, with upward routes carrying traffic to the root and downward routes carrying traffic from it.Each node selects a preferred parent for upward routing; nodes participating in downward routing announce themselves to a parent.Source: A. RPL Topology and Operations · pp. 7–8, §III · p. 7
  • RPL uses DIOs to advertise topology information, DAOs to propagate destination information for downward routes, DIS messages to solicit DIOs, and DAO-ACKs to acknowledge DAOs.Source: A. RPL Topology and Operations · p. 8

1) RPL Upward Routes (Building the DODAG Topology)

  • The root initiates DODAG construction by multicasting a DIO; each receiving node records the sender as a candidate parent, computes rank, selects a preferred parent, and propagates its updated DIO.The process continues until nodes have established upward routes toward the root.Source: 1) RPL Upward Routes (Building the… · p. 8

2) RPL Downward Routes

RPL builds downward routes by propagating DAOs and supports storing and non-storing modes. Its route-selection objectives and Trickle maintenance govern how paths are chosen and signaling is adjusted.

2) RPL Downward Routes

  • In storing mode, parents record each child’s destination and next hop, then forward its DAO toward the root; non-storing mode stores relationships only at the root for source routing.In non-storing mode, intermediate parents forward DAOs without maintaining routing state; the root adds a source route to packets sent downward.Source: 2) RPL Downward Routes · p. 8
  • For peer-to-peer traffic, packets travel upward to an ancestor with a known route to the destination, then downward through intermediate routers.Figure 3 depicts route construction and the resulting bidirectional DODAG.Source: 2) RPL Downward Routes · p. 8, Figure 3 · p. 9

B. Objective Functions (OFs)

  • The Objective Function separates application-specific route selection and optimization from core protocol operations, deriving rank from metrics and using rank to select a preferred parent.The passage names OF0 and MRHOF as the two standardized objective functions.Source: B. Objective Functions (OFs) · p. 9

1) The Objective Function Zero (OF0)

C. Routing Maintenance (Trickle Timer)

  • Trickle increases signaling when routing information changes, then exponentially reduces transmissions as the network approaches steady state and suppresses redundant control packets.The suppression mechanism prevents a node from transmitting when enough neighbors have already sent the same information.Source: C. Routing Maintenance (Trickle Timer) · p. 10

D. RPL’s Self-healing Mechanisms

RPL uses rank and data-path checks to avoid and detect loops, and local or global repair to respond to failures. Its security modes and implementations vary in supported features.

1) Loop Avoidance and Detection

  • Rank-based routing helps avoid loops, while data-path validation detects possible loops by checking packet direction against sender and receiver ranks.A downward packet received from a higher-ranked node indicates an inconsistency because packets from higher-ranked nodes should progress upward.Source: 1) Loop Avoidance and Detection · p. 10

D. RPL’s Self-healing Mechanisms

  • Local repair detaches and rejoins a non-root node after an inconsistency, whereas root-triggered global repair constructs a fresh DODAG by incrementing its version number.Local repair poisons routes using INFINITE RANK; global repair is triggered by the DODAG root.Source: 2) DODAG Repair · p. 10

E. RPL’s Security Features

F. RPL’s Implementations

2) RPL Vendor Implementations

The section reviews RPL vendor implementations and reported limitations in objective functions and downward routing. It identifies single-path forwarding, metric-composition ambiguity, hop-count effects, and incompatibility between downward-routing modes.

2) RPL Vendor Implementations

  • Cisco’s implementation supports OF0 and two OF1 variants, but omits RPL secure mode and non-storing mode.The two OF1 variants use latency and ETX, respectively.Source: 2) RPL Vendor Implementations · p. 11

IV. RPL LIMITATIONS AND DRAWBACKS

  • Studies report RPL limitations in objective functions, downward routing, and routing maintenance, summarized by the paper in Table 2.The survey presents these as weaknesses reported in the literature.Source: §IV · p. 11, Table 2 · p. 12

A. Objective Function Limitations

  • The objective-function issues reviewed include single-path routing, under-specified metric composition, and implicit hop-count impact.These categories frame the subsequent discussion of routing-selection limitations.Source: A. Objective Function Limitations · p. 11

1) Single-path Routing

  • RPL sends traffic through the preferred parent while it remains reachable, without load balancing, potentially draining overloaded parents and contributing to disconnections.The passage links this behavior to overloaded nodes dying earlier and network unreliability.Source: 1) Single-path Routing · p. 11

2) Under-specification of Metrics Composition

  • RPL gives no guidelines for combining metrics, and optimizing one application requirement with a single metric may violate another.ETX can select a reliable path yet contribute to early partitioning when load balancing is absent and vulnerable nodes exhaust their batteries.Source: 2) Under-specification of Metrics… · p. 11

3) Implicit Hop-count Impact

  • Summing link costs makes longer paths appear more costly, even when their links are better quality, potentially favoring shorter paths with very low-quality links.The passage describes this as a possible distortion in routing decisions.Source: 3) Implicit Hop-count Impact · p. 12

B. RPL Downward Routes

  • RPL prioritizes expected MP2P traffic, reducing overhead and routing state for upward routes at the cost of inefficient downward-route construction in overhead, state, and path stretch.The standard expects P2MP and P2P traffic to be less common.Source: B. RPL Downward Routes · p. 12

1) Incompatible Modes for Downward Routing

  • Mixing storing and non-storing modes can leave an incompatible node as a leaf, partitioning downstream communication; allowing it to route may still cause downward forwarding failure.A storing-mode router cannot understand a source header from a non-storing peer.Source: 1) Incompatible Modes for Downward… · p. 12

2) Memory Limitations in the Storing Mode

This section reviews RPL extensions for objective functions, downward routing, and routing maintenance, including the goals of objective-function enhancements and the weaknesses and pitfalls identified in the survey.

2) Memory Limitations in the Storing Mode

  • Storing-mode nodes must keep routing state for their sub-DODAG, so dense networks can overflow constrained storage and make destinations unreachable from the root.The root then drops packets destined for those unreachable nodes.Source: 2) Memory Limitations in the Storing… · p. 12

3) Long Source Headers in the Non-storing Mode

  • With a 127-byte MTU, non-storing source routes allow four uncompressed hops or, under IPv6 compression and auto-configuration constraints, at most eight hops.The passage estimates 71 bytes for the L3 datagram payload and notes that compression techniques alone could allow up to 70 hops, but auto-configuration limits the path to eight.Source: 3) Long Source Headers in the… · p. 13

4) Under Specification of DAO Emission

  • Unspecified DAO timing can increase control overhead or let routes expire before updates arrive, leaving the root unable to calculate source routes and forcing it to drop affected packets.One study sent DAOs every 5 seconds, increasing overhead relative to ContikiRPL’s use of DIO Trickle timers; conservative timing can harm data-plane reliability.Source: 4) Under Specification of DAO Emission · p. 13

1) Listen-only Period

  • Trickle’s listen-only period delays new information by at least I/2 per hop and can create uneven transmission loads that block vital updates or leave efficient routes undiscovered.Without the listen-only period, early transmissions could weaken suppression and cause redundant transmissions, limiting scalability.Source: 1) Listen-only Period · p. 13

2) Suppression Mechanism Inefficiency

  • Trickle’s suppression constant k is difficult to configure across scenarios; incorrect settings can produce suboptimal routes in heterogeneous topologies because routing updates from different sources are not interchangeable.Trickle suppresses further control-message propagation after the number of consistent messages in a window exceeds k.Source: 2) Suppression Mechanism Inefficiency · p. 13

1) OF Enhancements Based on Metric Composition

  • Objective-function extensions use lexical, additive, hybrid, or fuzzy metric composition; reports improved misbehavior detection and reliable paths, while energy-plus-hop-count improves load distribution.SCAOF combines remaining energy, ETX, availability, hardware robustness, and workload; simulations and testbed experiments report reduced churn, longer network lifetime, and better application QoS versus RPL-ETX, whose exact OF is unclear.Source: a) Hybrid Composition Enhancements · p. 14
  • Up to 12% higher network lifetime is reported for a weighted energy-oriented metric combining residual energy and ETX, while L2AM outperforms ETX RPL by up to 56% in network lifetime.L2AM combines link transmission power and residual energy into a primary metric, then multiplies it by ETX.Source: b) Additive Based Composition… · p. 15
  • SI-RPL and SI-ETX-RPL reduce control-plane overhead CDF by up to 90% and average transmissions by up to 50%, but incur slightly longer latency than HC-RPL.SI estimates stability from weighted DIO, DIS, and DAO counts over a hearing window; packet-delivery gains depend on window size, and higher DAO frequency can reflect more children rather than instability.Source: b) Additive Based Composition… · p. 17, f) Fuzzy-Based Composition Enhancements · p. 19
  • EAOF combines ETX with residual energy to improve network lifetime and balance energy use, with negligible reliability impact but slight PRR degradation.MAX-ETX limits the candidate subset, while MIN_ENER adds hysteresis to energy-based parent switching; experiments used 25 nodes, limiting generalizability.Source: c) Lexical-Based Composition… · p. 18, f) Fuzzy-Based Composition Enhancements · p. 19
  • RPL-SCSP prioritizes queue load before ETX and reduces end-to-end delay while enhancing network lifetime; PER-HOP-ETX improves PDR in dense networks while reducing power and latency.PER-HOP-ETX divides cumulative path ETX by hop count, but its combined metric does not satisfy monotonicity, creating a loop risk.Source: d) Cross-Layer Based Composition… · p. 18, e) Average-Based Composition… · p. 18, f) Fuzzy-Based Composition Enhancements · p. 19
  • OF-FL combines hop count, node energy, link quality, and delay, improving load distribution and edge-node delay but producing more churn than MRHOF with ETX.It reduces average hop count in dense networks, outperforms OF0 in packet delivery ratio, and has nearly MRHOF-with-ETX packet delivery ratio; transmitting more than four parameters in the DIO metric container raises fragmentation risk.Source: f) Fuzzy-Based Composition Enhancements · pp. 18–19
  • The two-stage fuzzy approach lowers packet loss by up to 20%, slightly improves delay, and averages 6.63 parent changes per hour versus ETX-RPL’s 43.52.It combines delay and ETX into QoS, then combines QoS with energy; the review notes that the claimed stability and delay improvements lack justification.Source: f) Fuzzy-Based Composition Enhancements · pp. 18–19
  • Opt-FLQERM reports the lowest packet loss, end-to-end delay, and churn among compared metrics, using control and data traffic for link estimates.The review says the method does not clarify how DIOs enter link estimation and may favor short paths containing low-quality single-hop links.Source: f) Fuzzy-Based Composition Enhancements · p. 19
  • The review finds early energy-composition studies leave reliability unclear, with using only six nodes; EAOF adds reliability evaluation and parent-switch hysteresis.EAOF’s simulation used only 25 nodes, so its findings may not generalize to larger networks.Source: f) Fuzzy-Based Composition Enhancements · p. 19
  • Other reported limitations include unsupported reliability claims and atypical Trickle configuration, DIO fragmentation risk, and fuzzy-method complexity and insufficiently explained results.The review also questions the reliability of SI’s control-message-based stability measure and notes that fuzzy approaches may enlarge DIOs and increase overhead.Source: f) Fuzzy-Based Composition Enhancements · p. 19

2) OF Enhancements Based on Multi-path Routing

The surveyed multipath and composite-objective-function proposals target congestion, reliability, energy balance, and QoS, using multiple parents or metrics to address limitations of standard RPL. Their reported gains come with implementation and evaluation caveats, including fragmentation risks, assumptions about deployment, and limited test-network scale.

Multipath forwarding

  • LB-RPL distributes traffic among its top k parents by rank and load, with delayed DIO broadcasts signaling a heavily loaded parent; simulations report better PDR, delay, and workload distribution than RPL.A lost DIO can be misread as a delay, falsely indicating higher workload, while long Trickle DIO periods may slow recovery and parent-set changes may cause herding.Source: 2) OF Enhancements Based on Multi-path… · pp. 20–21
  • Multipath ELT [106] balances traffic across parents using bottleneck-node lifetime estimates, achieving nearly ETX-level reliability while selecting paths with maximum residual energy and improving routing stability over standard RPL.ELT estimates remaining lifetime from residual energy and calculated energy consumption; network lifetime is defined as time until the first node dies.Source: 2) OF Enhancements Based on Multi-path… · p. 20
  • M-RPL splits forwarding when PDR falls below a threshold, improving throughput and per-bit energy use; its delay is initially higher but later beats RPL after stabilization.A congested parent notifies children through DIO messages, which then split traffic between that parent and another listed parent.Source: 2) OF Enhancements Based on Multi-path… · p. 20
  • CA-RPL combines wakeup-aware DELAY ROOT, received-packet count, and ETX, improving root packet reception by up to 50%, throughput by up to 34%, packet loss by up to 25%, and average delay by 30% versus RPL.It is designed to respond quickly to sudden traffic events and relieve congestion.Source: 2) OF Enhancements Based on Multi-path… · p. 20
  • LQA-RPL uses link quality across neighbors and residual-energy parent selection; it outperforms hop-count RPL in PDR and balances energy use to prolong network lifetime.The survey notes that the comparison would be more logical against ETX, and that the reported metric could violate rank monotonicity and create a loop-prone DODAG.Source: 2) OF Enhancements Based on Multi-path… · pp. 20–22

Energy-based objective functions

  • The energy-based OF improves network lifetime by up to 40% versus OF0 and MRHOF, but is outperformed by MRHOF in packet loss; its evaluation uses only seven nodes.The survey also questions the unexplained higher churn attributed to OF0.Source: 2) OF Enhancements Based on Multi-path… · pp. 21–22

Composite objective functions

  • OMC-RPL assigns class-specific ranks using SDN and a weighted objective function; it improves delay for minimum-delay traffic, PDR for reliability traffic, and lifetime by up to 41% versus RPL.With the SDN controller, it reduces control packets by approximately 62% versus OMC-RPL and standard RPL, and energy consumption by more than 50% versus standard RPL; the survey questions the one-hop controller assumption and leaves reporting interval unspecified.Source: 2) OF Enhancements Based on Multi-path… · pp. 21–22

Energy-based objective functions

  • RERBDI improves lifetime over hop-count, ETX, and RER, but is slightly worse in PDR because it omits link quality; its BDI cost may have little influence, and weights restricted to [0, 1] limit adjustment.The survey further notes that the proposed multi-parameter DIOs increase fragmentation risk, especially with multipath, and that ELT’s non-monotonicity requires an added ETX-based DODAG construction step.Source: 2) OF Enhancements Based on Multi-path… · pp. 21–22

3) Common Challenges and Pitfalls of OFs Enhancements

Composite objective functions and multipath enhancements can introduce costs and design pitfalls that constrain their usefulness in LLNs. The survey emphasizes fragmentation, unrealistic assumptions, limited evaluation scale, and multipath state and interference overhead.

Composite-metric design

  • Combining metrics can enlarge DIOs and increase layer-2 fragmentation, packet errors, and loss; choosing weights is difficult, metrics may be hard to estimate, and non-monotone composites can create loops.Fragmentation risk is greater for fuzzy approaches and especially consequential with multipath, where fragments of one packet may follow different paths.Source: 3) Common Challenges and Pitfalls of… · p. 22

Evaluation assumptions

  • Unrealistic assumptions—such as one-hop communication, optional standard features, or non-duty-cycle and synchronous MACs—can produce misleading conclusions and routing decisions.Control-message frequency, for example, does not necessarily indicate node or topology instability.Source: 3) Common Challenges and Pitfalls of… · p. 22

Evaluation scale

  • Many surveyed enhancements were tested on fewer than 10 nodes despite RPL targeting thousands, so their results cannot be generalized to large-scale deployments.One cited evaluation used only six nodes.Source: 3) Common Challenges and Pitfalls of… · p. 22

Multipath costs

  • Multipath requires extra route state and packet allocation, while maintaining node-disjoint paths adds overhead; route coupling can also cause interference and collisions that undermine congestion reduction or load balancing.State for all destinations in a sub-DODAG may be infeasible for memory-constrained devices, and location-aware mitigation carries substantial computational and communication complexity.Source: 3) Common Challenges and Pitfalls of… · p. 23

B. Routing Maintenance Enhancements

The section introduces extensions addressing the listen-only period and suppression-mechanism inefficiency in RPL’s routing maintenance primitive.

Routing maintenance

1) Suppression Oriented Enhancements

The surveyed suppression-oriented enhancements address Trickle’s potential to suppress useful DIO information and its configuration of the redundancy constant. They propose fairer suppression and node-specific constants, with reported improvements in route quality, overhead, and transmission distribution.

Trickle-F

  • Trickle suppression can construct sub-optimal paths, increasingly so as more DIOs are suppressed, because RPL DIOs may carry source-dependent information rather than identical content.Source: 1) Suppression Oriented Enhancements · p. 23
  • Trickle-F prioritizes nodes according to suppression history, reducing nodes with sub-optimal routes while retaining the original Trickle energy-consumption profile.Nodes that suppress more DIOs gain a higher chance of transmitting in the next interval frame.Source: 1) Suppression Oriented Enhancements · p. 23

Adaptive redundancy constant

  • Adaptive-k sets each node’s redundancy constant from its degree, inferred from received Trickle messages, and improves RPL performance by lowering control overhead while enabling more optimal routes.The cited standards and draft recommend differing k values, and the best setting depends on application and topology.Source: 1) Suppression Oriented Enhancements · p. 23

Degree-based redundancy constant

  • A degree-based Trickle enhancement sets k to one below an offset threshold and otherwise derives it from the offset and step, balancing transmission distribution against standard Trickle in simulations.Source: 1) Suppression Oriented Enhancements · p. 23

2) Listen Interval Oriented Enhancements

Listen-interval enhancements target Trickle’s convergence delay, but the surveyed proposals retain practical limitations. The survey flags unrealistic operating assumptions, uncertain density estimates, and un demonstrated effects on routes or energy use.

2) Listen Interval Oriented Enhancements

  • Opt-Trickle removes the fixed listen-only period in the first interval by letting nodes that receive inconsistent transmissions reset immediately and choose a random time in [0, Imin].The authors attribute this to implicit synchronization; subsequent intervals still retain a listen-only period.Source: 2) Listen Interval Oriented Enhancements · pp. 23–24
  • Trickle-F partly addresses sub-optimal route construction, but its listen-only period still slows convergence.Opt-Trickle is also limited by its 100% duty-cycle assumption, and its later-interval listen-only periods can add latency in lossy networks.Source: 2) Listen Interval Oriented Enhancements · pp. 23–24
  • The survey questions density estimates based on received-message counts in non-synchronized networks and notes that another enhancement reports no route-quality or power impact.Different transmission frequencies across nodes at minimum and maximum intervals can distort estimated node degree; adding step and offset parameters also increases complexity.Source: 2) Listen Interval Oriented Enhancements · p. 24

3) Routing Discovery and Maintenance Key Challenges

Routing maintenance must balance rapid dissemination against communication overhead in LLNs. The survey also identifies an unresolved gap: Trickle extensions do not clearly specify what makes routing transmissions consistent or inconsistent.

3) Routing Discovery and Maintenance Key Challenges

  • Proactive maintenance establishes routes in advance with more overhead but minimal forwarding delay, whereas reactive discovery occurs on demand with higher delay.Reactive schemes are preferred for networks with many mobile nodes, while proactive schemes are preferred in stationary networks such as LLNs.Source: 3) Routing Discovery and Maintenance… · p. 24
  • LLNs’ resource constraints and some network dynamicity make proactive maintenance challenging, while short update intervals trade lower propagation delay for higher communication overhead.Long intervals reduce overhead but disseminate routing information slowly.Source: 3) Routing Discovery and Maintenance… · p. 24
  • Trickle adapts interval size to propagate quickly during inconsistency and reduce transmissions in steady conditions, but does not define routing-specific consistent and inconsistent states or their detection.The survey argues that efficient routing maintenance needs explicit state definitions and detection mechanisms.Source: 3) Routing Discovery and Maintenance… · p. 24

C. RPL Downward Routes Enhancements

The surveyed downward-routing proposals combine RPL modes or use multicast to address storage and interoperability constraints. Their benefits are qualified by scalability limits, evaluation gaps, and possible costs to ordinary traffic.

1) Hybrid Based Enhancements

  • DualMOP-RPL enables storing and non-storing nodes to cooperate by adding source-routing headers in storing mode and hop-by-hop destination-prefix advertisements in non-storing mode.In a 25-node mixed-mode network, simulations and testbed experiments report better packet reception ratio than RPL, whose mixed modes can cause partitioning and non-optimal paths.Source: 1) Hybrid Based Enhancements · p. 24
  • MERPL delegates a child as a store when a node reaches routing-entry threshold N, then advertises that child’s destinations to the root in a separate DAO.It uses a hybrid of storing and non-storing operation for downward forwarding.Source: 1) Hybrid Based Enhancements · p. 24
  • With N set to 10, MERPL reduces the average number of items in a source route by 61.5% versus RPL; its average path length is shorter than non-storing RPL but slightly longer than storing RPL.The simulation used network sizes of 576 and 1204 nodes; storage reductions were especially evident near the root.Source: 1) Hybrid Based Enhancements · p. 25

2) Multicast Based Enhancements

  • D-RPL registers destinations that cannot be announced because of routing-table limits with a multicast group, allowing the root to reach them through multicast.Cooja/Contiki simulations report a 6-fold PDR improvement over ContikiRPL; above 60 nodes, average duty cycle is higher, and average end-to-end delay also increases.Source: 2) Multicast Based Enhancements · p. 25
  • DualMOP-RPL’s evaluation on 25 nodes does not establish large-scale performance, and interoperability does not remove non-storing header length or storing-mode memory limits.For MERPL, the survey notes that simulation parameters beyond node count and the choice of N are unspecified.Source: 2) Multicast Based Enhancements · p. 25
  • D-RPL’s multicast cost may affect traffic beyond packets otherwise undelivered when nodes overflow at different times and multicast packets flood the network.The survey says this can harm data flows from nodes not experiencing overflow.Source: 2) Multicast Based Enhancements · p. 25

3) Downward Routes Enhancements Common Challenges

The survey concludes that RPL extensions have mostly not resolved core limitations, particularly for large-scale bidirectional deployments. It identifies remaining downward-routing, load-balancing, metric-composition, configuration, and evaluation issues, alongside uncertainty about the role of multi-hop RPL as long-range technologies emerge.

3) Downward Routes Enhancements Common Challenges

  • Downward routing is constrained by node memory for routing entries and technology-limited packet size for source-route hops; single-path RPL also cannot exploit multiple parents’ combined capabilities.Hybrid and multicast proposals remain subject to these constraints, and multicast may harm ordinary traffic when nodes have not overflowed.Source: 3) Downward Routes Enhancements Common… · p. 25

VI. RESEARCH DIRECTIONS AND OPEN ISSUES

  • The survey finds that RPL extensions have mostly fallen short, leaving limitations that require further research.It identifies efficient downward-route construction, load-balancing, and metric composition among issues not successfully addressed.Source: §VI · p. 25

A. Downward Traffic Patterns

  • Interoperability between RPL’s modes was addressed, but storing-mode memory limits, long non-storing source headers, and DAO/DAO-ACK under-specification remain concerns for scalable bidirectional deployments.The timing of DAO and DAO-ACK messages remains an open question.Source: A. Downward Traffic Patterns · p. 25

B. Load-Balancing

  • Most proposed load-balancing mechanisms risk instability from frequent preferred-parent switching, which may undermine their benefits; a stable load-balancing solution remains undeveloped.The survey says evaluated extensions do not efficiently address this concern.Source: B. Load-Balancing · p. 26

C. Metric Composition

  • Metric composition should keep the number of metrics minimal; the survey favors lexical over additive composition and notes cross-layer combinations can serve load-balancing and energy-efficiency goals.More combined metrics enlarge DIOs, increasing fragmentation and routing-error risk; additive composition also makes weight assignment harder.Source: C. Metric Composition · p. 26

D. Single-instance vs Multi-instance Optimization

  • RPL supports multiple instances for concurrent applications with conflicting routing requirements, but their operation is unspecified and adds implementation and configuration complexity.The survey says removal is premature to judge without comparative evaluations and a standard specification of multi-instance operation.Source: D. Single-instance vs Multi-instance… · p. 26

E. Real Testbeds Evaluation

  • Only about 10% of reviewed articles used real testbeds, and none tested more than 30 nodes, a scale the survey says applies only to home automation.The authors argue for real large-scale testbeds because simulation cannot fully reflect real scenarios.Source: E. Real Testbeds Evaluation · p. 26

F. A Thought on RPL Deployments

  • The survey identifies both RPL scalability problems in large bidirectional networks and emerging long-range wireless technologies that may reduce the case for multi-hop routing.It notes that these technologies may negatively affect RPL adoption.Source: F. A Thought on RPL Deployments · p. 26
Loading 1902.01888v1…