The support of multipath routing in IPv6-based internet of things

ABSTRACT

. RPL network architecture

RPL operation and control messages
RPL operation is basically based on different control messages periodically broadcasted among all the nodes in an RPL network. DODAG formation is initiated when a sink node starts broadcasting DODAG Information Object (DIO) messages allowing DODAG discovery and attachment. Such messages include RPL network details such as Instance ID, DODAG ID, version number, and rank value. They also include RPL configuration parameters such as the Objective Code Point (OCP), which identifies the objective function and related metrics and constraints.
After deciding to join a DODAG, a DIOs recipient applies the advertised objective function to calculate its rank value and attaches to the network. This stage also involves the preferred parent selection process for establishing a default route via a selected parent from the Parent List (contains the senders of the received DIOs as candidate parents). In order to maintain loop-free topology, receiving a DIO message not indicating a lower rank value causes the recipient to discard the message. At each node, the DIO messages are updated and then disseminated further down the DODAG. For establishing the downward routes, the Destination Advertisement Object (DAO) messages are propagated by each child node over the established upward routes. This enables the exchange of different routing information with their preferred Int J Elec & Comp Eng ISSN: 2088-8708  The support of multipath routing in IPv6-based internet of things (Ibrahim S. Alsukayti) 2211 parent up to the root. As shown in Figure 1, the DIO & DAO processing and propagation procedures are carried out by each node in order to completely build the DODAG and establish the routes with the DODAG root. Overhead over the RPL control plane and adaptation to the stability of the RPL topology are managed using the Trickle algorithm as specified in RFC 6206 [16]. It guarantees that control traffic is effectively minimized by controlling the DIO transmission interval to exponentially increase as long as no topological changes exist. Moreover, RPL provides a newly joining node with the DODAG Information Solicitation (DIS) message for actively triggering DIO transmission if there is no DIO broadcasting during trickle time.

RPL MULTIPATH ROUTING SUPPORT
RPL is a single-path routing protocol enabling the establishment of a tree-based routing model. Data traffic routing at each node is performed over a single parent selected according to a certain OF, while other parents are kept as backups. This would lead to inefficient utilization of the available resources in IoT networks. Single-path routing can be considered a limitation that would limit the potentiality of the protocol to support more effective routing over the unreliable LLN links. Considering the ability of RPL to construct DODAGs in which a node can connect to multiple parents, RPL has the potentiality of supporting multipath routing. RPL functionality can be flexibly extended to realize data transmission over multiple forwarding routes and improve RPL performance in different IoT deployments.
Great contributions have been made for enhancing RPL with multipath routing support. The focus has been on certain networking aspects, namely load balancing, QoS management, congestion control, energy balancing, and mobility support. Based on these networking aspects, taxonomy is proposed for effective classification of the research efforts towards RPL multipath routing support. The following sub-sections present the proposed classification and summarize the relevant research works in the literature. Further discussion of the reviewed literature and outline of future eprospects are provided in the following section.

Load balancing
The support of multipath routing opens the doors for incorporating effective load balancing and better utilization of network resources. In [17], the researchers proposed an RPL multipath routing solution incorporating an Energy-awareness Load Balancing (ELB) mechanism. It is based on a simple approach to distribute data traffic among multiple parents at each RPL node. The parent selection process is based on a new routing metric that considers residual node energy and hops count. Furthermore, ELB was combined with a fast-local repair mechanism incorporating loop detection and avoidance. This is based on enabling RPL nodes to increase its rank and select neighbors, of the same rank, as next hop. However, allowing a rank to increase in this way can cause a node to be of the same rank as its child nodes. This would restructure the topology and lead to an increase in processing overhead, particularly in large deployments. The proposed solution was tested in a simulation environment of more than a hundred sensor nodes using the OMNeT++ simulator. The simulation results indicated the higher performance of the solution compared to the original RPL. It experienced better PDR and lower networking overhead, end-to-end delay, and power consumption.
Further evaluation tests were carried out in [18] with different OMNeT++ simulation setups considering specific IoT application for greenhouse environmental monitoring. The simulation results showed that similar conclusion to [17] can be drawn in terms of PDR. Additionally, the monitoring quality was examined by calculating data error received at the gateway. Lower data error was experienced compared to the original RPL. On the other hand, the proposed solutions introduced additional end-to-end delay, which could be less relevant to the considered application. However, this would be a noticeable limitation for the IoT applications having hard-guaranteed network delay limits.
The research work in [19] proposed a Heuristic Load Distribution (HeLD) algorithm on top of a braided multipath routing extension (MRPL) to the RPL protocol. The focus is on finding optimum traffic rate for each link and equalizing traffic load among the nodes at the same DODAG depth in a distributed manner. Upon the reception of each DIO message, the recipient obtains the rank of its sender and the ETX of its link. These are then used to calculate a relative cost of the corresponding path to the sink. The calculation considers the share of traffic being sent to each parent after assuming initial shares. Then, the rank calculation is performed by the recipient based on the relative costs of the parents advertising good distances to the sink. After joining a DODAG successfully, the node runs the HeLD algorithm which requires the estimation of its input traffic rate and those of its parents. The algorithm incorporates a traffic share adaptation procedure for dynamic load balancing. It enables gradual changes of the initial traffic shares of a node's parents in predefined intervals until a balanced load is managed among the parents. However,  ISSN: 2088-8708 Int J Elec & Comp Eng, Vol. 10, No. 2, April 2020 : 2208 -2220 2212 the algorithm involves a pair-wise rate comparison between the parent nodes and performs rate adjustments per each comparison. In addition, it is based on the assumptions of homogeneity and equal communication ranges among RPL nodes in IoT subnets. It also assumes the existence of a direct relationship between input and output traffic rates of each node. These would limit the feasibility of the solution to a limited number of IoT applications.
An extension to this solution to incorporate an additional mechanism for dynamic range adjustment was presented in [20]. A node can extend its communication range to have more parents and increase its load balancing options. However, this would come with the cost of additional transmission power consumption. The evaluation of the proposed algorithm was conducted for different simulated IoT scenarios, considering node density level, connectivity degree, and traffic load. Compared to the original RPL and some other multipath RPL schemes, the results showed that the algorithm succeeded in increasing network lifetime and throughput. However, network lifetime decreases, and collision rate increases in situations of high density or connectivity degree. Less reliable data transmission was experienced as the loss rate increased and more than the tenth of the packets were dropped. The proposed algorithm performed well in only low dense scenarios of low traffic load and node connectivity up to two parents.
On the other hand, the researchers in [21] focus on the alternative parent selection process to effectively facilitate optimal traffic distribution over multipath RPL networks. They define and examine different selection approaches which are based on varying methods such as wireless medium overhearing in conjunction with a Packet Replication mechanism. It allows a node to generate copies of the data packets and enables its available parents to overhear them in order to improve the probability of packet delivery. Moreover, the effect of selecting an alternative parent that have a common or uncommon ancestor with the primary parent is explored. Partially and completely disjoint paths would be developed in the case of uncommon ancestor selection whereas braided multipath would result from having common ancestor selection. The experimental results demonstrate the improvement in network reliability and robustness when testing the proposed schemes against the standard RPL. However, forwarding duplicates over packets disjoint multipath routing would incur noticeable overhead across IoT networks. This effect would be amplified as the network increases in size and number of RPL nodes.

QoS management
Multipath routing would provide a feasible approach to optimize QoS support for demanding IoT applications, particularly in the industrial and healthcare domains. In [22], a Multiclass Multipath RPL (M2RPL) that enables multiclass QoS-based load distribution in braided multipath communications was proposed. M2RPL defines three of the DiffServ classes, namely Expedited Forwarding (delay metric), Assured Forwarding (Packet loss metric), and Best Effort. After DODAG construction, packets are classified at each node to be accordingly queued into a different queue for each class. In order to enable QoS support, a priority packet scheduler and weighted round robin packet forwarder are utilized. The priority and initial traffic rate of the packets in each queue are firstly specified. Then, the packets are forwarded via the available parents while adaptively adjusting traffic rate in accordance with certain delay and packet loss constraints. This requires the nodes to perform regular calculations of the weighted averages of the delay and packet loss values, which are disseminated into the DIO messages, for each path. The proposed solution was evaluated in a MATLAB simulation setup and compared with the original RPL and some other multipath RPL schemes. The results show that the algorithm was successful in improving network lifetime and packet delivery while minimizing delay. However, network lifetime decreases while delay and collision rate increase in those cases of high-density situations.
The authors in [23] provide a QoS multipath opportunistic RPL routing solution based on a multilayer approach. At the MAC layer, a modification to the IEEE802.15.4 standard is proposed to enable the reception of multiple beacons at each node from multiple neighbors. In addition, RPL is extended at the network layer with opportunistic traffic forwarding over multiple parent nodes in a dynamic per-packet basis. On top of that, QoS routing is addressed to optimize packet delivery and minimize delay for timesensitive traffic. This is based on classifying IoT traffic into critical traffic of a low delay requirement, alarm traffic of specific delivery deadline, and the best effort traffic. Accordingly, each data packet is assigned a deadline, which indicates its order in the queue. The next packet in the queue is opportunistically transmitted after receiving a MAC layer beacon from one of the available parents. However, the provided support only considered the IoT communications following the multipoint-to-point scheme. The proposed solution was tested using the WSNet simulator. The results indicate that the proposed methods improved RPL performance in terms of PDR and delay.

Congestion control
Effective congestion control has been addressed for RPL networks using multipath routing in several research proposals. The solution proposed in [24] enables the detection of congested RPL nodes and then reliably distributing data traffic in a non-intrusive manner. An overloaded RPL parent delays the transmission of its DIO messages for a period of time proportional to its current load. This is received as a signal of congested network paths. The packets are then forwarded to the senders of the earlier DIO messages. However, this could contradict with the RPL Trickle algorithm which increases DIO interval as the network becomes more stable. It is important to ensure that the proposed signaling approach prohibits incorrect interpretation of other DIO delays than those caused by overloaded buffers. A large-scale simulation test was conducted using the NS2 simulator with a number of nodes of different buffer sizes. The solution succeeded in controlling network congestion and forwarding a similar amount of data packets to the nodes at the same level. It also performed better in regard to PDR, packet loss, and delay, particularly when large buffer sizes were implemented.
The research work in [25] address congestion alleviation for RPL networks using multipath routing in a reactive manner. Once a preferred path becomes congested, affected nodes start the congestion mitigation procedure by forwarding traffic over multiple paths. This is performed on a temporary basis until the affected routing path becomes uncongested. Congestion detection is based on the calculation of the PDR metric at each parent node between a source and its sink. This requires additional communications over the IoT subnet. Each child node over one path communicates its current forwarding rate using DAO messages.
Such overhead can be eliminated using a congestion detection metric based on buffer occupancy as proposed in [26]. Buffer occupancy is locally monitored during a preconfigured Congestion Interval (CI). Once a congested node is detected, a Congestion Notification (CN) message is sent over the DIO communications according to the Trickle algorithm. If the remaining trickle time is more than half the CI, an Emergency DIO (EDIO) is immediately transmitted without waiting for the next DIO message. However, it is not specified whether the trickle time is reset after sending an EDIO message. Receiving a CN message triggers the child nodes to start multipath routing by splitting the traffic in half. One packet is forwarded to the currently congested parent and the next one to a selected parent node from its Parent List. In case of the alternative nodes are being congested, the CN message would be forwarded down towards the source node. This would cause a wider reaction in the IoT network and having the traffic split over more routing paths. However, the multipath routing is enabled temporarily and stopped once there are no CN messages being received. The results of the Cooja simulation experiment show that the proposed extension increased throughput and decreased power consumption, compared to the standard RPL. It is also shown that multipath routing introduced additional delay initially before it settled down. The test only focuses on the IoT scenario where having no congested alternative parent. It would be more illuminating to examine the proposed solution when all or most of the alternative paths are congested as well.
A similar reactive approach that addresses congestion alleviation for RPL using multipath routing was followed in [27]. Once a node detects congestion, it starts distributing data packets between its original congested parent and an alternate parent from its candidate list. This would help in reducing forwarding rate over the congested path. Congestion detection is based on the Congestion Detection Factor that needs to be calculated at each node. Thus, congestion information needs to be disseminated across the IoT subnet in a timely manner to realize immediate congestion detection. However, it is not clear how the algorithm would react when the congestion situation has been rectified. The solution was tested in a simulation setup using the Cooja simulator. The test results indicate improved performance in regards to PDR, delay, network lifetime.
Another RPL congestion mitigation solution using multipath routing for IoT is proposed in [28,29]. At each node, traffic is forwarded via multiple parents in a dynamic and adaptive manner. Paths selection is performed regularly and based on the current congestion situation of the network. Each path is dynamically assigned a weight in order to distribute data packets accordingly. Weight calculation is based on congestion-related measurements including the number of re-transmissions required over a link, number of received packets during an interval, and hop count. For minimizing the average delay along a path, the calculation also incorporates a new metric considering the ContikiMAC radio duty cycle. Including this metric helps in forwarding packets to the first awaken parent and reduce the waiting time until the receiver wakes up. However, it is assumed that equal duty cycle exists for all the nodes in an RPL network, which would not be valid for all use cases. These measurements are regularly calculated at every node to be then included in its DIO messages. Each node only uses the two paths having the highest weights to distribute its traffic load. The simulation experiment shows that the proposed solution succeeded in improving the performance of RPL in different IoT scenarios. Compared to the standard RPL, the evaluation results  (PRN) and throughput. A reduction in packet loss rate and end-to-end delay was also experienced, although being affected by network density.

Energy balancing
Another critical aspect that can be effectively supported using RPL multipath routing in IoT networks is balancing energy consumption. The researchers in [30] proposed the Expected Lifetime (ELT) metric to extend their early single-path based proposal [31] for supporting multipath routing. ELT measures the time before a node dies if it keeps on forwarding the same amount of network traffic. It enables the estimation and maximization of the network lifetime of every route in an RPL network in a distributed manner. In this proposal, ELT is used for balancing energy consumption across bottleneck nodes in a multipath RPL network. ELT calculation is based on different measures including node throughput, ETX, and transmission rate. It also considers energy, but only takes into account energy drained by radio transmission and reception. The proposed solution requires each node to calculate ELT for itself and every relevant bottleneck node in the network. Based on that, only the parent nodes that maximize the lifetime of all the bottlenecks are selected. However, bottleneck node information required for the calculation is exchanged over the RPL control plane, an approach that would increase overhead in a large IoT deployment. It would also be a concern that having too many bottleneck nodes being advertised can lead to fragmentation. In addition, the proposal allows a node to attach to a higher-rank node that advertises a new bottleneck node of better ELT.
Furthermore, a greedy load balancing algorithm that can maximize the minimum ELT among bottleneck nodes was also proposed in [32,33]. The algorithm calculates a weight assigned to each parent node and accordingly distributes traffic among the available bottlenecks. After having traffic divided into equal fractions at a node, the algorithm iterates over its parent set for each fraction separately to decide the best next hop that improves ELT among the bottleneck nodes. Upon the reception of a new DIO message, the weights of the current parent nodes are dynamically recomputed. However, the proposed algorithm is based on iterative computations that would introduce additional processing delay and overhead. The proposed work was evaluated in a WSNet setup with an IoT subnet of fifty RPL nodes and considering up to ten bottleneck nodes. Comparing it with the original RPL using different metrics, the ELT-based multipath routing solution achieved almost the same reliability provided by ETX-RPL. It also exhibited similar energy efficiency of RPL using the residual energy metric. The evaluation results also show an improvement in routing stability as both the number of nodes performing parent changes and the number of changes are reduced. However, the results demonstrate that the higher the network density the lower the lifetime of the IoT network. The proposed solution also fails to achieve much improvement when testing its performance regarding delay.
The proposed work in [34] introduced a multipath RPL solution with energy balancing and delay minimization schemes. The energy balancing scheme is based on the estimation of the residual energy of the bottleneck nodes. The calculation is based on energy consumption due to radio transmission, reception, and processing. Each node also needs to estimate the impact of its traffic load on the survival time of the bottleneck nodes considering multipath forwarding. The energy dispersion degree measurement of the bottleneck nodes is then performed using the Pareto's evaluation model. This measurement is used for optimal distribution of the traffic load according to a unified algorithm combining the Newton's and steepest descent methods. For the end-to-end delay minimization scheme, the average waiting time of data packets is computed based on cache utilization. Then, the dispersion degree of the remaining cache size at the bottleneck nodes is calculated. Accordingly, each parent node is assigned a weight, calculated with greedy iteration over all the parent nodes to approximate delay-optimized traffic distribution. In addition, the authors propose the integration of the two multipath schemes to adaptively meet the different requirements of IoT applications. The energy-balancing scheme is adopted, unless in the case of delay-sensitive applications that require the delay minimization scheme. Then, the algorithm would adaptively switch to the other scheme at a certain threshold. However, it is important to ensure that this procedure does not lead to unstable algorithm implementation particularly for highly dynamic IoT scenarios. The proposed schemes were compared with the original RPL in an experimental setup. Improvement in network lifetime, end-to-end delay, reliability, and stability are demonstrated under different network sizes and cache capacities. In large setups of a high node number and few bottleneck nodes, however, the results show that the algorithms perform poorly and at certain points fail to maintain the network.

Mobility support
Multipath routing would facilitate effective mobility support for moving RPL nodes in mobile IoT deployments. The MDMR solution proposed in [35] considers mobility support for RPL sink nodes in IoT networks. It provides a dynamic RPL repair mechanism over multipath routing. MDMR is based on Each node receiving the messages updates its DODAG ID, in addition to the rank value based on lexically combining the calculation of three metrics. These are hop count, node energy, and Link Quality Indicator (LQI). This causes frequent updates of the Parent List at each node during new DODAG construction and in reaction to sink node mobility. In the case of node or link failure, local repair is supported to reconnect an RPL node with an alternative parent or sibling node. In case of having no alternatives, global repair can be initiated. The proposed approach evidently provides the means for having data traffic routed over multiple parents, but the operation of multipath routing is not clearly described. MDMR was evaluated in an NS-2.5 simulation setup of an RPL network with multiple sink nodes and a number of sensor nodes. The experiments examined the impact of increasing the speed of sink nodes in one scenario and the number of sink nodes in another one. The results show that MDMR supports better energy efficiency and end-to-end delay in both scenarios compared to selected routing protocols. While the previous solution addressed mobility support for sink nodes only, the mobility based Braided Multipath RPL (MBM-RPL) in [36] supports the mobility of sensor nodes. It enables the on-demand establishment of alternative routing paths braided with the default path before a failure occurs. The DODAG is firstly constructed based on a proposed routing metric that provides an estimation of links lifetimes. This is based on the calculation of sensor nodes speed distributions using a Bayesian Inference Model. Such calculation is periodically performed and exchanged between neighboring nodes using a Hellobeaconing mechanism, instead of utilizing the underlying RPL DIO messages. Every Hello message includes the calculated Mean and Standard Deviation of the Predicted Velocity Distribution. The mechanism helps in implementing fast link failure detection since the Hello-timeout period is independent of the RPL Trickle Time algorithm. During a Hello messaging interval, an RPL node evaluates the stability of its links to detect those about to fail and prevent default path failure. If the probability that the link with the preferred parent is above a predefined threshold, the operation of alternative path establishment is triggered to use other candidates. However, frequent Hello messages exchange would result in additional communication overhead and consequently more power consumption. Using the Cooja simulator, the proposed MBM-RPL was implemented and compared against the original RPL in addition to a mobility-supported RPL with single-hop routing. As the results indicate, the proposed solution shows better performance in terms of packet loss rate and average transmission delay.
The DAG Multipath Routing (DMR) proposed in [37] enables routing redundancy to support mobile RPL scenarios in dynamic IoT environments. In addition, DMR addresses fast local failure recovery and allows multipath routing over sibling nodes. DMR also enables global RPL failure recovery and DODAG re-construction in the case of having no available parent or sibling nodes. The presented solution was tested in a simulation environment with a number of mobile nodes using the NS2 simulator. The results show that DMR maintains low routing overhead, and improves PDR and energy efficiency. However, an increase in the end-to-end delay was experienced as a result of link failure. It can also be noticed that the proposed solution was compared with AODV and AOMDV protocols which are considered as MANET routing protocols while more relevant ones could be of more interest.

INSIDHTS AND PERSPECTIVES
A summary of the review presented in this paper is provided in Table 1. It is evident that these solutions considered the support of different networking aspects to advance IoT applications. We can also see that different routing metrics were adopted for effective management of RPL routing over multiple paths. In addition, most of the proposed solutions followed certain strategies for better support of multipath routing. In regards to the evaluation methodologies, a number of network simulators were utilized and a variaty of assessment measures was adopted. These remarks are discussed in the remianing of this section.

Consideration of specific networking aspects
Most of the proposals focused on load balancing and introduced different traffic distribution algorithms. Load balancing can be achieved using a basic algorithm [17,18], whereas a dynamic adaptation algorithm would allow gradual adjustment of the traffic share among unbalanced parents [19,20]. It was also presented that link layer solutions can be adopted to address effective multipath load distribution. An example is the wireless medium overhearing in conjunction with a Packet Replication mechanism [21]. In regards to QoS management over multipath routing, the focus was on traffic classification and queuing. Different QoS-oriented approaches were followed based on two main methods, weighted round robin forwarding [22] and packet deadline control [23].
Another important aspect that was considered in different multipath solutions is congestion control. Multipath routing was utilized to alleviate detected congestion in a reactive manner [25][26][27]. A congestion control algorithm based on dynamic multipath routing was considered in [28,29]. In these proposals, however, multipath routing over a limited number of parents was considered enough to alleviate congested situations. In addition, the implemented calculations were based on some measures that need to be communicated between a child and its parents [25,28,29]. As a result, RPL communications would have additional overhead which can be addressed using local calculations [26,27]. On the other hand, a different approach was followed in [24] to enable signaling an overloaded parent by delaying the transmission of its DIO messages. This allows RPL nodes to select only uncongested parents with up-to-date DIO communications. Other networking approaches applicable for multipath routing such as opportunistic routing introduced over the RPL multipath model were also considered in [23].
Another critical aspect for IoT deployments is energy balancing in addition to maximizing network lifetime. However, the focus was only on energy balancing over the bottleneck nodes in RPL networks. A simple approach incorporating a greedy balancing algorithm based on an energy-aware metric was utilized in [30,32,33]. Moreover, a Pareto's model and the combination of Newton's and steepest descent methods were adopted for optimal energy distribution [34]. Other considerations for RPL multipath routing include mobility support, which was addressed at different levels: sink nodes only [35] and sensor nodes [36]. Another approach in this context was based on routing redundancy [37]. However, the solutions in both [35] and [37] relied on the RPL fast local and global repair for reacting to failure. A preventive approach to predict failure and act upon it would be more effective to support mobility in dynamic IoT scenarios [36].
It is also considered that the RPL multipath routing model would effectively support network failure recovery solutions [17,18,37]. Although the RPL specification prohibits joining a DODAG via a neighbor of the same or greater rank, this was reconsidered in different proposals in order to address fast local repair. Some solutions enabled joining a DODAG via sibling RPL nodes [17,18,[35][36][37] whereas others allowed the selection of higher-ranked nodes [30,32,33]. While this could result in the formation of routing loops, the detection and avoidance of such loops were only addressed in [17,18].

Routing metrics
The management of multipath traffic routing in the reviewed literature was based on different metrics. PDR, ETX, LQI, retransmission rate, end-to-end delay, and packet loss were mostly considered. Some proposals adopted energy-related metrics such as node residual energy collectively with other link metrics [17,18,34,35]. Other metrics for lifetime estimation were also adopted to estimate Node Expected Lifetime [30,32,33] and Link lifetime based on estimating node speed using a Bayesian Inference model [36]. Other node metrics that are based on different aspects including buffer occupancy and radio duty cycle were also considered in some proposals [26][27][28]34].

Solution strategies
It can also be noticed that the reviewed proposals addressed different networking aspects using different networking strategies. A number of the proposals shared the concept of link weight assignment according to the calculation of different metrics in order to facilitate multipath management [22,[28][29][30][32][33][34]. On the other hand, the multipath RPL solutions in some of the proposals targeted specific IoT applications such as greenhouse environmental monitoring [18,23,34]. In terms of RPL responsiveness, most of the proposals relied on DIO communications in case of the need for additional and immediate information exchange. Such an approach would not always guarantee a low response delay in case of dynamic IoT scenarios. To address such a deficiency, a Hello-beaconing mechanism can be incorporated independently of the RPL control plane for the implementation of fast failure detection [36]. However, this would come at the cost of additional implementation complexity and overhead. Another consideration for making RPL more responsive is adopting a reactive and on-demand approach [35] despite the proactive nature of RPL. Moreover, routing redundancy and packet duplication over multiple paths is another approach that has been recently considered [21].

Evaluation approaches
The reviewed literature in this paper followed different evaluation methodologies. However, the focus has been on only using network simulation. Different network simulators were used for performance evaluation according to different network measures. Some of the proposals utilized specific wireless and LLN simulators such as Cooja which provides a practical RPL implementation [21,[25][26][27][28][29]36]. Another example which was adopted by earlier research works is WSNet [23,30,32,33]. Other general network simulators were also popular among the reviewed proposals. These include NS-2 [24,35,37] and OMNet++ [17][18][19][20]. Other uncommon choices for the implementation of LLN networks, such as MATLAB, were also considered [22]. As it can be apparently noticed, there was no consideration given to physical testbed testing. Therefore, the need for more realistic and practical experimentation over physical and real-life testbeds becomes apparent.

Performance assessment
On the other hand, different considerations were taken for the performance assessment of the proposed multipath solutions. As being a critical performance measure for multipath routing architecture, delay evaluation was common among all the reviewed papers. It is apparent that multipath routing can result  [17,18,25,26,[30][31][32]37]. Other link performance measures such as packet delivery ratio, throughput, and packet loss were of interest to most of the reviewed proposals. On the other hand, Energy-related measures were also commonly considered among the different research works to target improvement to energy efficiency and network lifetime. Other considerations such as network density can have a noticeable effect on the performance of multipath RPL networks [19, 20, 22, 29-32, 34, 36]. Such critical limitations would raise a need for more effective investigations in this context towards understanding the possible correlation among such criteria. It is also evident that less consideration was given to performing functional testing of the considered functionalities including load distribution, energy balancing, and mobility efficiency. We can also notice the lack of a comprehensive evaluation approach among the reviewed literature.

CONCLUSION
The review in this paper demonstrates the versatility and flexibility of the RPL routing model. The standard RPL protocol provides a basic routing framework for IoT networks. Incorporating advanced routing mechanisms into such a framework is a feasible approach to realize more optimized IoT routing solutions. The support of multipath routing improves routing efficiency in RPL networks and provides a viable functionality. Such advance RPL support enables realizing a number of effective networking aspects to advance IoT applications. These include load distribution, congestion control, QoS management, energy balancing, mobility support, and failure recovery. It is evident that RPL multipath solutions provide noticeable improvements to network performance in different IoT scenarios. Energy efficiency, network reliability, and protocol overhead can be enhanced with less computational and communication complexity. However, we can see that there is a room for future research efforts to realize further RPL routing improvement. There is still a need for addressing certain limitations regarding the performance of multipath routing in dense IoT environments. It is also important to always ensure that multipath routing introduces no additional delay, particularly in dynamic IoT scenarios. On the other hand, the feasibility of integrating multipath routing with other mechanisms needs to be investigated. For example, a comprehensive RPL solution incorporating multipath and multi-gateway support would be a possible approach to revive the protocol potentiality for more IoT applications.