Dynamic-RPL: Enhancing RPL-Based IoT Networks with Effective Support of Dynamic Topology Management

Abstract

The inherent characteristics and limitations of Internet of Things networks make it hard to avoid facing adverse network conditions. Addressing high performance in extreme situations still remains a challenge even for a standardized routing protocol like the IPv6 Routing Protocol for Low Power and Lossy Networks (RPL). No effective support is provided by the design of RPL to guarantee high network performance in the presence of such challenging conditions. To address such a compelling need, an innovative approach referred to as Dynamic-RPL is proposed in this research paper. With only limited in-protocol modifications to RPL, Dynamic-RPL provides effective support of dynamic topology management in a distributed manner. Seamless optimization of network topology is realized with dynamic topological adjustments to sustain high network performance and stability. It incorporates modified RPL topology establishment, customized RPL objective function and parent selection, a new dynamic topology management algorithm, and additional inter-routing support. The evaluation results demonstrated the ability of Dynamic-RPL to maintain high overall network performance irrespective of the adversity of ongoing network conditions. Considering varying-scale experimental setups, high QoS performance and low energy consumption were achieved without much increase in network overhead. Dynamic-RPL succeeded in adapting responsively with little time required to have the network performance successfully restored and network topology completely converged.

1. Introduction

The proliferation of the Internet of Things (IoT) technology has opened the doors for a myriad of technological advancements and opportunities. Advanced provisioning of smart IoT services in different domains such as healthcare [1], industry [2], and agriculture [3] becomes remarkably evident. A revolutionary development of a variety of new smart IoT solutions is being widely witnessed nowadays for a broad scope of IoT applications. Examples are industrial automation, a smart city, environmental monitoring, and smart metering. The widespread deployment of IoT with expanding scope and scale has led to exponential growth in the number of IoT-connected objects during recent years. This has been forecasted to increase to more than 30 billion IoT devices in 2030 [4]. It has also been estimated that the IoT industry will generate USD 3.9–11.1 trillion a year in revenue by 2025 [5].

For energy-efficient wireless IoT networking, Low Power and Lossy Networks (LLNs) are widely adopted. It enables the establishment of effective IoT network infrastructures interconnecting resource-constrained IoT devices over wireless links of a limited bandwidth and high loss rate. Addressing effective network routing at the network layer of the LLN architecture is achieved with an IETF-standardized routing protocol referred to as the IPv6 Routing Protocol for Low Power and Lossy Networks (RPL). The development of the protocol is based on strict adherence to the inherent LLN features and limitations. However, RPL provides no standard support to rectify adverse network performance situations. The presence of stability and load issues across the network makes it hard for the standard RPL to operate effectively and maintain high network performance. The potential damages of a network collapse as well as complete communication disruption and data loss would then become inevitable. Its potential vulnerability to performance degradation is still a major design challenge. Therefore, there is a vital need to provide RPL with effective and advanced support to address these limitations and sustain high performance under challenging network conditions.

To such a critical end, this paper proposes an innovative approach for dynamic RPL topology management, referred to as Dynamic-RPL. It provides an effective solution toward more topology flexibility and dynamicity in varying-scale networks deployed for any IoT application. It introduces simple in-protocol modifications to the standard RPL for extending its functionality to a further effective limit. Dynamic-RPL incorporates modified RPL topology establishment, customized RPL objective function and parent selection, a new dynamic topology management algorithm, and additional inter-routing support. These practically integrated protocol properties represent the novelty of this research work.

Dynamic-RPL leverages the standard support of multi-instance and multi-sink topology formation to realize dynamic topology management. It is based on applying effective topology partitioning and aggregation in response to any load and stability changes in an RPL network. These operations are performed in a dynamic and distributed manner to optimize the network toward better performance and stability. To enable effective and informative decisions, cooperative communications among only the relevant nodes in the network are realized with a simple RPL setup. Dynamic-RPL ensures that a multi-sink network is always kept well-maintained from the topological and performance perspective. It also works effectively when the network is formed with a single sink setup.

This research work provides a four-fold contribution. First, it provides a novel lightweight and distributed scheme to enhance RPL functionality with dynamic topology management. Second, it introduces a customized RPL objective function and dynamic parent selection strategy that only requires simple modifications to limited RPL operational aspects. Third, it addresses effective multi-sink inter-routing support in varying-scale RPL networks without imposing additional complexity. Fourth, an extensive evaluation of the proposed solution considering varying-scale scenarios is provided.

The rest of the paper is organized as follows: Section 2 provides an overview of the RPL protocol. Section 3 presents and discusses the related work. Then, a brief description of preliminary networking assumptions is provided in Section 4. In Section 5, the design properties of Dynamic-RPL are detailed. The evaluation methodology and result analysis are presented in Section 6 and Section 7, respectively. Finally, Section 8 concludes the paper and presents future perspectives.

2. RPL Overview

IoT networks can be characterized as being formed with a varying number of resource-limited embedded devices over wireless LLNs. These are typically small-sized devices of constrained capabilities with respect to computation, energy, and storage. The establishment of LLN connectivity among these devices is achieved with low-cost wireless links and without incurring high complexity and energy. A common technology that is adopted at the LLN link layer is IEEE 802.15.4. However, these are scarce wireless links that come at the prices of no high performance and reliability guarantees.

For reliable end-to-end IP communications, additional networking support is maintained for the LLN architecture. An additional IP adaptation layer is incorporated to implement header compression and fragmentation. This is achieved using IPv6 over Low Power Wireless Personal Area Networks (6LowPAN) as specified in RFC 4944 [6] and RFC 6282 [7]. 6LowPAN enables simple integration of LLNs with traditional IPv6 networks.

At the network layer, addressing effective network routing is a challenging functionality. This is more evident in IoT deployments of strict networking requirements. The IETF ROLL working group has defined a set of LLN routing requirements for various IoT applications. These include urban, industrial, home automation, and building automation applications, which are specified in RFC 5548 [8], RFC 5673 [9], RFC 5826 [10], and RFC 5867 [11], respectively. Taking such requirement diversity into consideration, an IETF-standardized routing protocol referred to as the IPv6 Routing Protocol for Low Power and Lossy Networks (RPL) is specified in RFC 6550 [12].

RPL enables loop-free and customizable IPv6 routing functionality over restricted LLN connectivity. The development of RPL is oriented toward addressing routing challenges in the LLN environment. It works as a distance-vector routing protocol with a proactive operational mode. In addition to adhering to LLN characteristics, the protocol design of RPL is based on a routing framework that can be customized to achieve objective-oriented routing optimization. Different application-specific routing objectives can be implemented in RPL networks using single or composite routing metrics. Therefore, RPL can be effectively adopted to fulfill the distinct network requirements of different IoT applications.

RPL structures an LLN network as a Directed Acyclic Graph (DAG) that is formed with single or multiple RPL instances. An instance is constructed as one or more Destinations-Oriented DAGs (DODAGs). The network topology of each DODAG incorporates a designated RPL sink node to which multiple non-sink RPL nodes are interconnected. As presented in Figure 1, an RPL network can have a multi-instanced RPL setup with each instance having a varying number of DODAGs. Ins-1 is an instance formed with three DODAGs whereas Ins-2 is a single-DODAG RPL instance. Each one of the sink nodes (S1–S4) can act as an Internet gateway to the nodes in its respective DODAG. Note that having some nodes such as N13 and N14 attached to both instances complies with the RPL standard. However, it is not allowed for a node to join more than one DODAG in a single instance.

For the successful establishment of a DODAG topology, upward and downward network paths need to be constructed across the DODAG. At the initial stage, the sink node initiates this process by periodically broadcasting DODAG Information Object (DIO) messages. Recipients keep forwarding the messages after being updated with their relevant RPL information. Having the process repeated across the DODAG would eventually allow the successful establishment of the upward routes.

The routing information necessary for successful DODAG discovery and maintenance is contained in the DIO messages. This includes the RPL Instance ID, DODAG ID, and version number. DODAG identification is realized using both the instance and DODAG IDs whereas the version number is important for tracking topological updates. Other parameters such as IPv6 addresses and node-ranking values are also disseminated to support recipients making effective DODAG attachment decisions.

In addition, information regarding the Objective Function (OF) being currently implemented for the instance is contained in the DIO messages. Each instance is associated with only one OF to be applied in all its DODAGs. The topology formation of the DODAGs is then dictated using the applied OF to achieve certain routing optimization objectives and fulfill application-specific routing requirements. The OF design is made customizable to flexibly implement specific optimization goals and address certain network requirements such as reliability and energy reservation.

Application-oriented OF formulation can be realized using single or composite routing metrics and constraints. Each one of these is a quantitative value calculated using specific networking parameters to represent a defined network characteristic. RFC 6551 [13] presents a set of common choices that are categorized into node and link routing metrics and constraints. There are two default standard OFs specified for RPL. These are Objective Function Zero (OF0) and Minimum Rank with Hysteresis Objective Function (MRHOF), which are specified in RFC 6552 [14] and RFC 6719 [15], respectively. OF0 provides a simple single-node-metric-OF that is based on the hop-count metric. MRHOF was developed to address network reliability using a single link metric. It utilizes the Estimated Transmission Count (ETX), which enables the calculation of the total number of transmissions/retransmissions made to successfully deliver data packets.

Upon the reception of a DIO message, the advertised OF is applied by the recipient for node ranking and preferred parent selection. The rank information included in the received message is first utilized for the calculation of the recipient’s rank. The rank value then represents the virtual distance of the node to the sink node of its current DODAG. By having the rank values increased when going deeper in the topology of the DODAG, routing loops can be prevented. Each node maintains a parent set containing all the lower-ranked neighbor nodes. OF-based selection of a preferred parent from the parent set is then performed. This enables the node to complete the attachment to the DODAG and establish a default route for upward DODAG routing.

Following the establishment of upward routes, downward routing is initiated to establish internal routing paths for all the destinations across the network. Upon the reception of a DIO message and successful attachment to the DODAG, the node propagates its routing information over its default upward route. It unicasts a Destination Advertisement Object (DAO) message containing its IPv6 address to its preferred parent node. The DAO information is then kept disseminated using all the nodes along the upward paths to the sink node. These nodes also update their routing tables accordingly as long as they run RPL in a storing mode. Data packets destined for this node can then be internally routed via a common parent or ancestor node. If the nodes operate in a non-storing mode, no state can be maintained and internal routing of data packets is performed commonly via the sink node.

In addition, RPL design incorporates the implementation of the Trickle algorithm [16] to realize low-cost DODAG construction and topology maintenance. It limits network overhead in a DODAG by controlling the transmission of DIO messages according to the stability of its topology. The algorithm defines the configurable minimum and maximum transmission interval values. It allows RPL to initially broadcast DIO messages based on the minimum interval value. As long as the DODAG remains stable with no changes to its topology, the transmission interval is increased exponentially until it reaches the maximum interval value. If there is a network inconsistency such as updates to a preferred parent or version number, it is reset to the minimum interval value and the procedure then starts over.

To effectively address node or link failures, two procedures were defined using RPL. One is the local repair, which allows for performing an immediate switch to an alternative parent node to address any failure with the current one. The other procedure is the global repair, which is based on a wider action that needs to be taken by all the nodes in the failed DODAG. This is initiated using the sink node upon the detection of a DODAG failure such as routing loops and inconsistency. It increments the current version number of the DODAG to commence full topology reformation. Although it results in resetting the Trickle timer and incurring additional overhead, this procedure guarantees a simple approach for immediate failure recovery.

3. Related Works

The standard RPL specification [12] defines how PRL operates for a single-DODAG topology in a single-instance setup. However, the design of RPL supports the construction of multi-instance RPL networks and the formation of multi-DODAG topologies. Accordingly, several research efforts have been made to realize such potential functionality. Further research attempts have also been made to utilize this support for developing dynamic topology management. A brief overview of these research works is discussed in this section and a summary is presented in

Table 1. Summary and comparison of related work.

Ref.	Methodology	Multi- Instance	Multi-DODAG	Dynamic Management	Aggregate-Able Topology	Customized-OF
[17]	Multi-instanced DODAG management	√	×	×	×	√
[18]	Single-OF multi-instance management	√	×	×	×	√
[19]	On-demand instance formation	√	×	√	×	×
[20]	Dynamic node attachment to multiple instances	√	×	√	×	×
[21]	Dynamic node attachment to multiple instances	√	×	√	×	×
[22]	A multi-DODAG coordination framework	×	√	√	×	×
[23]	Dynamic DODAG partitioning	×	√	√	×	×
[24]	Dynamic DODAG partitioning	×	√	√	×	×
[25]	Dynamic activation and deactivation of RPL nodes as sinks	×	√	√	√	×
This Study	Dynamic multi-DODAG topology management	√	√	√	√	√

.

The proposed work in [17] addressed multi-instance RPL network management to enable QoS-Differentiation over a single-sink DODAG. It was based on forming multiple logical DODAGs over the physical DODAG topology. Each logical DODAG then runs in a distinct instance applying a different OF. In [18], a similar approach was adopted to support effective multi-instance management over a DODAG but using a single tunable OF.

In those cases where multiple instances can coexist over a single DODAG, the proposed solution in [19] provides dynamic multi-instance management. It enables the on-demand formation of an instance as per the network requirements of QoS-classified data traffic. Inactive or unwanted instances are removed after a certain configured time. The proposed architecture incorporated several software components such as an instance scheduler, message controller, and instance database.

A different approach was proposed in [20] to enable a multi-DODAG topology to merge into a single-sink DODAG setup. The merged sink nodes then act as a virtual sink with each running a separate RPL instance. The nodes then perform dynamic instance attachment/detachment based on the current performance of the network. It was assumed that RPL operates in a non-storing mode for all the nodes. A similar approach was also proposed in [21] to address the dynamic management of multiple RPL instances over a single-DODAG topology. It enabled flexible node attachment to an instance in order to fulfill certain network traffic requirements. This was based on supporting effective cooperation among the instances to exchange instance information.

It can be noticed that these research works considered dynamic management of multiple instances over a simple DODAG setup. Other solutions were also proposed to address the dynamic management of multi-DODAG setups based on topological DODAG partitioning. The proposed work in [22] introduced a simple approach to enable dynamic multi-DODAG topology based on managing DODAG sizes. It defined a coordination framework for the sink nodes to exchange their DODAG and performance information using DIO and DAO messages. The information helps each sink to make decisions toward scaling down its DODAG to address any performance issues. This is achieved by applying a maximum rank limit, which allows a sink to limit the broadcast of DIO messages to a certain topology level. In this case, only the recipients then maintain their DODAG attachments whereas other nodes detach to join other DODAGs.

In [23], the dynamic split of a single DODAG topology into multiple DODAGs was proposed to overcome performance degradation. In response to any performance issue, the affected nodes send emergency requests. Once a response is received from a nearby emergency sink node deployed in the network, the split operation is initiated. The affected nodes detach from their current DODAG and join the DODAG of the responding sink nodes. As a result, a multi-DODAG topology is formed with separate sink nodes to address performance degradation. Multiple sink nodes then coexist without any coordination and thus there are no practical possibilities for topology aggregation once the situation is rectified. Partitioning the topology of a single DODAG into multiple interconnected network segments was also considered in [24]. This was proposed for addressing effective data management in large-scale IoT deployments.

A different approach was adopted in [25] to enable the dynamic activation and deactivation of multiple sink nodes in a single DODAG topology. It was based on having certain non-sink RPL nodes in the topology to serve as on-demand sink nodes in the case of performance degradation. This process is managed in a dynamic way to adjust the number of sink nodes in the network as needed. It defined three decision schemes: autonomous, delegated, and centralized. The first and second ones allow each sink to make its own decisions and the decisions of the sinks in its sub-DODAG, respectively. The third scheme requires a central decision-making node.

Moreover, there have been practical considerations towards introducing specific OF designs for effective routing in multi-instance and multi-DODAG setups. Examples are QAD-OF [17], OFQS [18], Multi-OF [26], and MEHOF [27]. These OFs provide RPL networks with the ability to apply different routing optimization objectives for complex RPL setups in a managed and flexible manner. It is evident that customizing OF development to address effective routing in multi-instance and multi-DODAG topologies is a practical consideration.

It has also been shown that effective multi-instance RPL support can be leveraged to address efficient networking solutions for different IoT applications. Examples are a smart grid [18], smart farming [24], and e-healthcare monitoring [28]. This was also successfully adopted for other variants of IoT. These include multimedia-IoT [29] and industrial-IoT [30].

However, a different approach is considered in this work to address more dynamic topology management of RPL networks. Addressing such support in the literature was limited to either multi-instance [17,18,19,20,21] or multi-DODAG management [22,23,24,25]. Most of the proposed solutions focused on dynamic DODAG partitioning to address network situations without enabling flexible DODAG aggregation [17,18,19,20,21,22,23,24]. This proposed work introduces more flexibility and dynamicity to the network topology. It leverages the multi-instance RPL support to enable dynamic adjustments for single- and multi-DODAG topologies during adverse network conditions. DODAG partitioning and aggregation are both supported in a dynamic and distributed manner. It also incorporates customized OF, an improved parent selection strategy, and simple multi-DODAG inter-routing support.

4. Preliminary Networking Assumptions

This work is based on different RPL characteristics and network assumptions. It is assumed that an RPL network is initially established with a single-DODAG or multi-DODAG topological setup. Each DODAG is formed with a single sink node and multiple non-sink RPL nodes. The RPL operates in a storing mode for all the initiated DODAGs. All the nodes run an RPL implementation that is based on the RFC-6550 RPL specification. The implementation is considered to support multi-instance configurations in addition to the slight modifications introduced in this work.

It is also assumed that all the nodes are deployed in a homogeneous and stationary IoT network setup using small-sized IoT devices. They are powered with rechargeable batteries, which makes it critical to take into account energy efficiency and resource utilization. Although they would be resource-limited, the devices have enough memory to locally cache routing and multi-DODAG information. In addition, each device has a communication module for low-power wireless connectivity. Wireless connections are established among the devices in the network to enable RPL communications. A multi-hop topology is formed among the nodes in each DODAG over the wireless links. This would result in more than one multi-hop network path established up to the sink node across the network.

The deployment of the network is assumed to target a specific IoT application. Examples of possible applications are a smart city, e-health, and smart agriculture. Accordingly, IoT devices are equipped with the necessary smart hardware components such as sensors and actuators to enable the collection of application-specific IoT data. Data communications are carried out periodically based on configured time intervals. The data are transmitted in UDP packets over the established routing paths. Forwarding the data further to/from the Internet is only performed at the sink nodes, which act as Internet gateways.

5. Design

The design of Dynamic-RPL is introduced in this section in detail. It is based on simply maintaining an RPL network with two separate instances. One is an instance containing the single or multiple DODAGs in the RPL network. The other one is a management instance established among only the relevant nodes in the network. These are referred to as the local-instance and global-instance, respectively. The former is a normal RPL instance formed with any number of normal RPL DODAGs (local-DODAGs). It can apply any local OF for optimizing data traffic routing according to specific-application requirements. The latter is a distinct instance with a single-DODAG topology (global-DODAG) formed among specific nodes in the network (global-nodes). It runs a customized OF (global-OF) and special parent selection strategy to facilitate dynamic topology management. It enables cooperative communications over the network to make informative topological adjustment decisions and address adverse network situations in a dynamic and distributed manner.

In Section 5.1, a description of the global-DODAG establishment is presented. The modified global-parent selection strategy is then described in Section 5.2 in addition to introducing a new OF for the global-DODAG. In Section 5.3, the dynamic multi-DODAG algorithm is illustrated. Section 5.4 explains how inter-routing can be managed over the network. Finally, example scenarios demonstrating the functionality of the Dynamic-RPL are presented in Section 5.5.

5.1. Dynamic DODAG Establishment

Once it establishes its local-DODAG, the first-running sink node in an RPL network also initiates a global-DODAG in a separate RPL instance. It is also possible to have a particular sink node in the network administratively configured to initiate it. As a result, two different RPL instances need to be maintained for the RPL network. One is the multi-DODAG local-instance containing the local-DODAGs individually initiated using their respective sink nodes (local sink nodes). The other one is a global-instance of a single-DODAG interconnecting the local sink nodes in the entire network. In addition, non-sink RPL nodes at the first level of the local-DODAGs can also join the global-DODAG and act as global-nodes. Figure 2 shows an example of an RPL network of three local-DODAGs (LD1–LD3). The dashed arrows demonstrate how the global-DODAG is established among the relevant global-nodes (S1–S3 (local-sinks) and N1–N7 (local-non-sink)).

The global-sink (global-DODAG-initiating node) broadcasts global-DIO messages that contain a specific Instance ID and DODAG ID in addition to a special flag indicating a global-DODAG advertisement. The messages also advertise a special global-OF (more details in Section 5.2) designed to enable effective management of the global-DODAG. Upon the reception of these messages, a newly joining sink node to the RPL network attaches to the advertised global-DODAG after having its local-DODAG established. All the level-1 non-sink nodes locally attaching to the sink node also join the global-DODAG. To avoid adding much to the protocol complexity, the same functionality of the standard single-DODAG RPL is maintained for the global-instance. That is, each global-node uses the OF advertised in the DIO messages to join a single global-parent and form a standard DODAG topology. Since it is designed towards optimizing the multi-DODAG RPL network efficiency, the advertised global-OF enables each sink node to join the best global-parent available and ensure optimal interconnectivity and dynamicity. More details of the design of the adopted OF are provided in the following subsection. In the case of a new sink node not receiving the global-DIO message, it sends a DIS message soliciting the global-DIO transmission as per the standard RPL specification. The message includes a flag indicating a request to broadcast the global-DIO messages.

As a result, a tree-like DODAG topology is formed among the different global-nodes. The node that initiated this global-DODAG becomes its sink node (global-sink) whereas the other attaching global-nodes become normal RPL nodes to the global-DODAG. Each local-sink then separately maintains its local-DODAG and the global-DODAG connectivity. It runs the normal RPL sink functionality via one interface while acting as a global-DODAG RPL node at another interface, except for the global-sink, which acts as the sink node for each DODAG individually. For level-1 nodes, non-sink RPL functionality is maintained at both the local-DODAG and global-DODAG. This means that both local-sinks and level-1 non-sink nodes become non-sink RPL nodes running the basic standard RPL operations in the global-DODAG.

In the example presented in Figure 2, it can be seen that a standard RPL DODAG is established among the different global-nodes. S1 represents the sink of the global-DODAG whereas S2 acts as a non-sink global-node and attaches to S1 as a standard RPL child node. Being a level-1 node, N5 joins the global-DODAG and attaches to S2, which is its local sink node. However, S3 has no direct wireless connectivity with S2. Therefore, it has no choice in joining the global-DODAG but to attach to N5, which then represents an external non-sink global-parent.

5.2. Global-Parent Selection

To enable such a flexible global-DODAG establishment presented in the previous section, the global-parent selection strategy needs to be slightly modified. This is important to also ensure the dynamic management of the multi-DODAG network. Figure 3 presents the modified algorithm for global-parent selection, which is run upon the reception of a new global-DIO message. It first ensures that only eligible global-nodes process the message and join the global-DODAG. The message is discarded if it indicates a source that is currently the receiver’s global-parent or advertising a higher or equal rank. It is also discarded in cases such as providing no update about a member of the receiver’s global-parent set. These also include advertising an irrelevant global-DODAG (any possibly initiated global-DODAG other than GD1, which represents the main global-DODAG in an RPL instance).

Otherwise, the receiver proceeds to process the message and add the source as a member of its global-parent set. It then attaches to the source as its global-parent unless other options are available in the set. In this case, the receiver needs to select the best available option based on the advertised global-OF. This is also applied in case the message is indicating updated information about a source already added to the global-parent set.

The process starts by grouping the well-performing nodes among the least-ranking members of the set. It then first tries to select the best of those not locally attached to its local-DODAG. If no such options exist, it then selects the best among all the grouped options. These considerations are oriented to the operation of the dynamic multi-DODAG algorithm as explained later in the following subsection. In case all the members of the global-parent set are not performing well, the global-parent selection is run for all the available members. Finally, the receiver attaches to the selected global-parent.

After completing the attachment process, a global-node needs to participate in the establishment of the up-routes of the global-DODAG as per the RPL specification. It unicasts a global-DAO message indicating its local-DODAG prefix to its global-parent. This helps enable simple management of inter-routing among the different local-DODAGs as illustrated later in Section 5.4.

The global-parent selection process is performed based on a new global-OF, referred to as Load and Stability Objective Function (LSOF). It is customized to enable effective dynamic topology management considering two main network aspects. These are the network load and topology stability, which are measured for local-DODAGs using a set of different metrics. For load measurement, the size of the local-DODAG is an important consideration to assess how much a local-DODAG can be scaled up in a dynamic topology. It is also critical to factor in the data Forwarding Rate to consider how busy a local-DODAG is. Another important metric is the Maximum Hop Count in the local-DODAG in order to consider how expandable it is. Different measures can also be incorporated to indicate topology stability. These include global and local repair rates, which provide information on how long the topology is maintained unchanged. Other parameters such as the parent change rate and No-Path Message Rate are also important to consider how much the local-DODAG is stable. Note that LSOF runs only in a global-DODAG considering the specific metrics explained above whereas any OF can be applied in the local-DODAGs within a local-instance. For example, the local-DODAGs can have one of the default OFs, OF0 or MRHOF, or any application-oriented OF running in each of them. This is very applicable since the global-DODAG and local-DODAGs operate in different instances.

All the LSOF measures are collected locally using each global-node and then exchanged globally in the global-DIO messages. Instead of introducing a new message and adding much to the communication overhead, a new DIO message option is introduced to the global-DIO base object. It is referred to as the Load and Stability Information Option (LSIO), which complies with the standard ICMP options. It contains all LSOF information in a limited number of bytes appended to each global-DIO message.

Upon the reception of a global-DIO message, a global-node retrieves the LSOF information contained in the LSIO option. To store this information, the global-node maintains a global multi-DODAG list in its local cache. A new entry is added to the list for each nearby global-neighbor in the global-DODAG. The entry is kept updated every time a relevant global-DIO message is received. The list is made accessible for the global-parent selection process. The dynamic multi-DODAG algorithm is also provided with open access to this information to enable making informative decisions, as explained later.

5.3. Dynamic Multi-DODAG Algorithm

Figure 4 shows how the dynamic multi-DODAG algorithm works. It enables dynamic topological adjustments for optimizing an RPL network toward better performance and stability. It defines two main operations: DODAG aggregation and partitioning. The former allows two local-DODAGs to be merged into a single one (Merge operation) whereas the latter enables splitting a local-DODAG into separate local-DODAGs (Split operation). These are performed based on the positions of global-nodes within a global-DODAG in addition to certain performance and topological considerations regarding their individual local-DODAGs. The algorithm identifies the different global-nodes as global-sinks, local-sinks, and potential-sinks (non-sink-global-nodes). The algorithm can be configured to run at specific time intervals, in response to any local-DODAG updates, and upon any dynamic topological changes in the entire network.

As illustrated in Figure 4, the algorithm is run using all the nodes in a global-DODAG except for certain ones such as the global-sink (GS). These also include any local-sink (LS) with its global-parent (GP) being a potential-sink (PS) or another local-sink that used to be its local-child (Old-LC). In addition, a local-sink having a local-child (LC) with external global attachment to any global-node should not also be considered. These also include a potential-sink connecting to a small-sized and stable local-DODAG (LD-Size). All these kinds of global-nodes should be restrained from any dynamic activities in order to effectively maintain manageable and optimizable topological management.

Eligible global-nodes carry out the two main operations of the algorithm based on their current status of the global-DODAG and under specific conditions regarding their local-DODAGs. Both operations can be carried out using the global-nodes unless it is a local-sink that can only run the Merge operation. It is not reasonable for local-sinks to perform the Split operation and disjoin their local-DODAG to establish a new one.

Each eligible local-sink is left with only the aggregation decision to make based on the topological size (LD-Size) and current LSOF indicators (LD-LSI) of its local-DODAG. LD-Size is basically the total number of local-nodes in the local-DODAG whereas LD-LSI is periodically calculated at the sink node according to the following formula:

LD-LSI = (w¹ ∗ FR + w² ∗ MHC + w³ ∗ GRR + w⁴ ∗ NPMR)/TN

(1)

where w¹–w⁴ represent non-negative tunable weights that account for the importance of the corresponding parameters and

• FR (Forwarding Rate): the number of forwarded data packets per second;
• MHC (Maximum Hop Count): the length of the longest path across a DODAG;
• GRR (Global Repair Rate): the total number of initiated global repairs;
• NPMR (No-Path Message Rate): the number of messages per second;
• TN (Total Nodes): the total number of nodes in a DODAG.

Therefore, each eligible local-sink merges its local-DODAG with one of its global-parents once two conditions are met. One is that the local-sink and its global-parent perform well as indicated with their current LSOF indicators. The other one is ensuring that merging the two local-DODAGs does not scale to a large LD-Size. Otherwise, the algorithm stops running without any topological adjustments. It is also held back if the local-sink has a global-parent and mergeable global-child but the performance measures indicate that the global-child is better-performing. That is, waiting for the global-child to merge would result in a better-performing aggregated-local-DODAG than the current possible one. Note that defining the limit values for LD-LSI and LD-Size is implementation-specific.

In the case of an eligible potential-sink, it proceeds to run the algorithm unless the measurements indicate that its local-DODAG is still stable and uncongested with an under-limit size. The decision is made using the algorithm to carry out the Split operation if any of three conditions are met. First, the potential-sink has a global-child and globally attaches to another potential-sink locally connected to another local-DODAG. Second, the current LD-LS-Index calculations indicate that merging with its global-parent would result in unacceptable local-DODAG performance. Third, the merging movement would lead to an over-sized local-DODAG. Otherwise, it ceases the Split operation and decides for merging its sub-DODAG with one of its global-parents.

The algorithm ensures that a multi-DODAG network is always kept enhanced from the topological and performance perspective. It also works effectively when the network has its local-instance with a single local-DODAG. In this case, the network contains only a single local-sink, which becomes the global-sink of the global-DODAG. All the level-1 non-sink nodes then become potential-sinks attaching to the global-sink. These global-nodes are the only nodes being attached to the global-DODAG while the local-DODAG is connecting all the nodes in the network. This setup is maintained as long as the network is under-sized with a stable and non-congested topology. Otherwise, the algorithm would enforce one or more potential-sinks to perform the Split operation. It causes the local-DODAG to be split into two or more separate local-DODAGs to rectify the situation. It is evident that the algorithm adds much to the flexibility and efficiency of RPL networks against challenging network conditions.

A global-node initiates a dynamic operation by first detaching from its current local-DODAG. The RPL specification specifies how a node poisons its DODAG to initiate the detach process. This is achieved by advertising INFINITE_RANK in its DIO messages to force the recipients to disjoin the DODAG and find alternative parent nodes. The same procedure is adopted for the algorithm operations with a slight modification. Instead of disjoining their current parent nodes, the recipients maintain their parent associations and wait for their parents to complete the operation.

The global-node first sends a DIO message with INFINITE_RANK and a special flag indicating that this is a dynamic poisoning. Once received, the recipient clears the state of its current local-DODAG and waits for further DIO messages from their current local-parents. In the case of a Split operation, the global-node then detaches from its current local-DODAG and initiates a new local-DODAG. It acts as the local-sink of the newly initiated local-DODAG and broadcasts local-DIO messages with new DODAG initiation information. These messages cause the recipients to reattach again and join the new local-DODAG. The Merge operation is also initiated following the same poisoning procedure but without initiating a new local-DODAG. Instead, the merging global-node attaches to its global-parent and starts forwarding the local-DIO messages being received. This enables the recipients to complete the merging operation by attaching to their local-parents again and joining the merged local-DODAG.

5.4. Multi-DODAG Inter-Routing

More effective use of the proposed approach can be further recognized by facilitating inter-routing among the different local-DODAGs in an RPL network. The network is administratively configured with a global-prefix for the global-DODAG in addition to a different local-prefix for each local-DODAG. During the global topology formation stage, the local-prefixes are exchanged over the global-DODAG. After a global attachment, only local-sinks initiate the global advertisements of their respective local-prefix. Potential-sinks need to participate in this process by only forwarding these advertisements globally. If it is the global-parent of its local-sink, a potential-sink also locally forwards the global advertisement to its local-sink. This is performed to ensure that all local-sinks maintain the required routing information to route data traffic among the different local-DODAGs. These considerations are important to avoid routing redundancy and stop creating potential routing loops or inconsistencies.

Considering the example in Figure 5, N5 is the global-parent of N6 and N8 is the global-parent of S3. However, both N5 and N8 share the same global-parent of S2. If we let N6 and S3 exchange their local-prefix (P3), S2 would eventually receive different routing information regarding P3. This is a non-preferable situation that would result in routing inefficiency. Avoiding potential routing issues while maintaining full inter-routing is realized by limiting the initiation of local-prefix exchange to local-sinks. Only S3 advertises P3 to N8 whereas N6 is restrained from the exchange of P4 information. N8 then forwards the P3 advertisement globally to S2 as well as locally to S4 in a similar way.

Each local-sink includes its local-prefix in the standard RPL Target Option (TO), which is added to its global-DAO messages. TO has an unused flag field of which one bit is set to signal that this is the local-prefix of the global-sender. By receiving such information, its global-parent (whether a local-sink or potential-sink) stores the learned local-prefix in the relevant entry of the sender in the global multi-DODAG list. It then updates its routing table accordingly before forwarding such information further up to its global-parent using a new global-DAO message. This process keeps running to enable the global-sink to maintain an updated routing table entry for each local-DODAG in the network.

A data packet transmitted from a source in one of the local-DODAGs to a destination in another local-DODAG is processed normally in the first one. It is routed over the established local-default-routes up to the local-sink of the source’s local-DODAG. Then, the local-sink uses the global routing information in its routing table to forward the packet over the global-DODAG. If the local-sink is at an upper level in the global-DODAG compared to the destination’s local-DODAG, it then would have a relevant routing entry that can be used to correctly forward the packet. Otherwise, it uses the global-default-route to forward the packet to its global-parent. Eventually, the packet would arrive at the relevant global-node in the destination’s local-DODAG, which then routes it locally to the destination.

In Figure 5, a packet is routed locally in LD3 if it is destined from N17 to N15 for example. It first arrives at S3 after having local-recipients in LD4 use their local-default-routes for packet forwarding. Then, S3 uses its global-default-route to forward the packet to its global-parent, N8, which also repeats the same procedure to forward the packet to S2. Having a local-entry in its routing table for N15, S2 is then able to forward the packet locally to N4, which also uses its local routing information to forward the packet to its final destination. If a reply packet is then destined to N18, it would indicate a global-packet destined to LD3 as this can be learned from the destination prefix. Accordingly, S2 uses the relevant global-entry of LD3 to forward the packet to N8 once it receives the packet over the local-DODAG. N8 also has a relevant global-entry for LD3 in its routing table, which enables it to forward the packet to S3. Once it arrives, the packet is processed and delivered locally via N7 to its destination.

5.5. Example Dynamic-RPL Scenarios

Figure 6 shows an example scenario of a multi-DODAG RPL network that consists of eight local-DODAGs (LD1-LD8). S1 is the first-running local sink node in the network and initially establishes its local-DODAG (LD1) in the local-instance. Then, it initiates the global-DODAG in the global-instance by broadcasting global-DIO messages with the global-flag set to one. S1 also collects and includes the load and stability measures of LD1 into the LSIO option of the message. Being a level-1 non-sink node, N1 and N2 attach to S1 upon the reception and processing of the global-DIO message. They join the global-DODAG and then act as potential-sinks for the dynamic multi-DODAG algorithm.

After that, S2 runs and then initiates LD2 before processing any global advertisement. Once that is completed, S2 receives and acts upon the global-DIO messages of S1. It then decides to join the global-DODAG by instantly attaching to S1 as its global-parent since no other options are available. It then keeps broadcasting the DIO messages of the global-DODAGs. Then, the same procedure is repeated for S3 and S4 after receiving the global-DIO messages from S1 and S2, respectively, which become their respective global-parents. N3-N8 also join the global-DODAG via their respective local-sinks and operate as potential-sinks for the dynamic multi-DODAG algorithm.

The situation is a bit different in the case of S5 as it receives the global-DIO messages of both S2 and S3. Since they are local-sinks performing locally well, S5 applies the advertised LSOF to select the best global-parent among them. The parent selection process ends up with S2 being preferred and selected. This decision is made since S2 has better load and stability measures as indicated with the collected LSOF information. That is, it would be better for S5 to merge into S2 than S3 in the case of being decided later using the dynamic multi-DODAG algorithm. S5 attaches to S2 and then carries on forwarding the global-DIO messages. N9-N10 also join the global-DODAG via S5 and operate as potential-sinks for the dynamic multi-DODAG algorithm.

In the case of S6, the only nearby global-node to which it can globally attach is a potential-sink locally joining a different local-DODAG. This is N8, which maintains both local and global attachments via S4. S6 joins the global-DODAG and attaches to N8. It then continues receiving and sending global-DIO messages. This enables N11–N12 to join the global-DODAG and establish global attachments with S6.

For S7, no global-parent is initially available once it completes the establishment of its local-DODAG. This situation continues until its local-child (N13) has succeeded in joining the global-DODAG via S2. N13 then becomes a potential-sink globally attached to an external local-sink. After that, S7 globally attaches to N13 as its global-parent while separately maintaining local attachment. The algorithm ensures that this is risk-free while keeping them maintained over the two separate RPL instances. Note that N13 also receives but discards the global advertisements of S4 as a higher LSOF ranking is indicated. N14-N15 then receive the global-DIO messages of S7 and decide to attach to it and join the global-DODAG.

In addition, N16 receives the global-DIO messages from N15 and N8 but then decides to attach to N15 after running the parent selection algorithm. It concludes that N15 performs better than N8 based on their advertised load and stability information. Then, S8 runs the parent selection algorithm, which concludes that S6 has a lower ranking and better LSOF measures than N16. Therefore, S8 attaches to S6 as its global-parent and starts forwarding the global-DODAG advertisements. Finally, N17 receives the global-DIDO messages of S8 and then decides to attach to it and join the global-DODAG. Then, a complete convergence of the initial global-DODAG topology is realized.

Figure 7 demonstrates how the dynamic multi-DODAG algorithm operates and shows the dynamic adjustments to the topology during adverse conditions of the network. It is assumed that LD1, LD2, LD3, LD5, and LD6 are performing well while the other local-DODAGs are not. Therefore, S2 and S3 need to individually decide whether to merge with S1. As the algorithm concludes that no performance risks or scaling issues are expected with the Merge decision, S3 merges with S1 into a single local-DODAG. However, the algorithm restrains S2 as it finds out that merging S2 and its global-child (S5) together would yield a better outcome. Once it is run using S5, the algorithm then decides to merge S5 with S2 to form a better aggregated-local-DODAG. It estimates that the load and stability performance would be higher compared to the case of the possible S2–S1 aggregation. In addition, the aggregated-local-DODAG can also be later considered for further aggregation with S1. Note that this would not be possible if S2 has already merged with S1. The S5–S2 global attachment would then be a local-sink-to-potential-sink attachment, which would stop the algorithm from performing the Merge operation.

Later, the decision is also made for N13 to merge with S2 to address the ongoing load and stability issues in LD7. In the case of LD4, the LSOF measures indicate an unstable local-DODAG and the need for dynamic topological adjustment. Since it has a global attachment with its local-sink, N8 performs the Split operation and initiates a separate local-DODAG. As a result, the situation in LD4 is rectified and steady network performance is restored. This later drives the algorithm to decide for merging S4 with S2 as the network conditions become better. This topological adjustment is effectively made after confirming that LD2 would still not be oversized and the overall performance would be well maintained.

Let us now consider that the adverse network conditions later fade out in LD7 as a result of the early dynamic topological adjustment. Then, the challenging network situation in LD8 makes the algorithm to decide for merging N16 with N15. Although they have an external potential-sink-to-potential-sink attachment, this movement is eligible since N16 is a global-leaf node. Once the aggregation is accomplished, S8 is now freed to perform the Merge operation as it has no local-child maintaining external global attachment. After confirming that no potential performance risk exists, the decision is made to merge S8 with S6. After a while, a further Merge operation is performed using S6 to merge with N8, which now acts as a local-sink. This is decided using the algorithm as both respective local-DODAGs perform very well and the aggregated-local-DODAG would not unacceptably scale up.

Up to this stage, the algorithm has succeeded in addressing performance degradation in the struggling local-DODAGs and realizing better multi-DODAG topology. Only limited adjustments were made to rectify the situations in LD4, LD7, and LD8 and enhance the overall performance of the network. It can also be seen that the entire network topology was optimized with fewer local-DODAGs. Instead of having eight separate local-DODAGs, the network now contains only four that are performing well. Yet, the topology is flexible to address any future performance issue and make necessary topological changes. For example, S4 would perform the Split operation and initiate its local-DODAG again if LD2 is experiencing degraded overall performance. This may also result in N8 deciding to merge back with S4 when the algorithm confirms no risk of an over-sized local-DODAG or unacceptable overall performance.

Another example scenario is presented in Figure 8 with a single large-scale local-DODAG setup. Figure 9 demonstrates how the algorithm operates if the network becomes highly congested with unstable topology. It starts with S1 initiating a global-instance and establishing a global-DODAG after having its local-DODAG converged successfully. Then, N1–N4 globally attaches to S1 upon the reception of its global-DIO messages. These are the only global-nodes eligible to join the global-DODAG at this stage. Based on the advertised LSOF information, the algorithm at N1 discovers the performance degradation of the local-DODAG. Accordingly, N1 performs the Split operation and initiates a separate local-DODAG. N5–N7 then become global-nodes eligible for processing global advertisements. Then, they globally attach to N1 and join the global-DODAG. However, such a Split movement is not enough to rectify the adverse situation in LD1. Therefore, N4 disjoins the local-DODAG and initiates a separate one after being decided using the algorithm. As a result, N12–N15 globally attach to N4 and join the global-DODAG.

After that, the overall network performance of LD1 becomes better and no more Split movements are taken. However, the newly initiated local-DODAG using N4 still experiences stability and congestion issues. This causes a decision to be made using N12 to perform the Split operation and initiate a separate local-DODAG. As a result, the network converges into a more stable state with better overall performance. Although it is expanded into multiple local-DODAGs, the network becomes more reliable while still having a manageable topology.

6. Experimentation

There are different operation systems (OSs) customized for IoT devices with constrained resources and limited capabilities. Choices that are widely adopted are ContikiOS [31] and TinyOS [32], which provide open-source implementations. A number of the IoT devices in the market support both OSs such as Zolertia-Z1 [33]. The network stacks of these OSs are IPv6-based with the full support of 6LowPAN and RPL. 6LowPAN provides IP adaptation whereas IPv6-based network routing is enabled using the RPL implementation. However, ContikiOS incorporates an additional software component that supports IoT simulation development. It comes with the Cooja network simulator, which provides an effective environment for developing a wide range of RPL-based IoT simulations. It enables the emulation of a variety of IoT setups using different choices of virtual IoT motes while running the real implementation of Contiki OS. In this work, the Cooja simulator was utilized for the implementation and experimentation of the proposed solution.

The implementation of the proposed solution required certain modifications to the code base of RPL in the network stack of ContikiOS. Most of these were applied to specific source files. The rpl-dag.c and rpl-icmp6.c files were modified to implement the global control messages, global-parent selection strategy, and dynamic multi-DODAG algorithm. Note that the thresholds for LD-LSI (x) and LD-Size (y) were set to the values of 85% and 7, respectively. It was considered that an acceptable performance indicator should be at least 85% and the sizes of local-DODAGs should be relatively balanced according to the total number of nodes (that made seven as the approximate value). The rpl-mrhof.c file was then modified to incorporate the implementation of LSOF.

An experimental evaluation methodology was designed to study the efficiency of the proposed solution. It was based on utilizing the Cooja simulator to investigate the overall performance of the proposed solution in two experimental setups, referred to as S1 and S2. These were designed to consider varying-scale and varying-complexity scenarios. The network in S1 was initially set up to build a single-DODAG topology of 28 nodes. S2 has a network of an initial topology formed with 45 nodes in a multi-DODAG setup. These were multi-hop network topologies established over wireless connections. The random position strategy was adopted for placing the nodes in a simulated deployment area of 300 × 300 m.

The Zolertia-Z1 mote implemented using Cooja was selected for all the nodes. It runs an MSP430 16-MHz MCU with 8 KB of RAM and 92 KB of flash memory. No serious issues were encountered with such limited memory capacity as it was enough to successfully accommodate the modified RPL implementation. The motes also have CC2420 transceivers, which enabled the establishment of IEEE 802.15.4 wireless connectivity.

Additional configurations were also made to enable each node to run a UDP client and transmit IoT data traffic. Frequent transmissions of the data packets were set for each node at a varied transmission interval of ±5 s. The communications were carried out using the nodes with other local nodes in addition to external destinations. In addition, different Cooja plugins were also run at each node to facilitate easy collection of the simulation data. These include the “collect-view” and “powertrace” Cooja modules, which provide experimental data regarding overall network performance and energy consumption. Other important settings were also adjusted for each node to have a communication range and interference range of 25 and 50 m, respectively. A summary of the simulation parameters is presented in

Table 2. Simulation Parameters.

Simulation Parameter	Value
Area Size	300 × 300 m
S1	28 Nodes
S2	45 Nodes
Topology	Random
Mote Type	Zolertia Z1
Mote Current Consumption in CPU Mode	0.5 mA at 3 V
Mote Current Consumption in LPM Mode	0.0005 mA at 3 V
Mote Current Consumption in Tx Mode	17.4 mA at 3 V
Mote Current Consumption in Rx Mode	18.8 mA at 3 V
Radio Medium Model	UDGM: Distance Loss
MAC Layer	ContikiMAC
RPL Routing Mode	Storing Mode
Communication Range	25 m
Interference Range	50 m
Traffic Type	CBR
Data Transmission Interval	±5 s
Control Message Size	4 Bytes
Data Packet Size	40 Bytes
Confidence Level	95%
x in Dynamic-RPL	85%
y in Dynamic-RPL	7
Simulation Duration	45 min

.

Four main evaluation stages were considered to achieve effective experimentation of the proposed solution. The first stage was based on running the implementation of the original RPL for both experimental setups. No stability and congestion issues or oversizing situations were considered in this stage. This enabled the establishment of the performance baseline required to realize effective comparison with the experimental results obtained in the next stages. The Dynamic-RPL implementation was then experimented with in the next stage under the same ideal performance consideration for both experimental setups. The results obtained for these initial evaluation stages were examined to provide an initial analysis of the efficiency and performance of Dynamic-RPL.

In the third and fourth evaluation stages, the original RPL and Dynamic-RPL implementations were again tested, respectively, but under adverse network conditions in each experimental setup. The load and stability measures were artificially degraded for some local-DODAGs to simulate the required challenging scenarios. Different local-DODAGs and varying scenarios of different load and stability settings were considered for each experimental setup during these stages. Each scenario was applied 10 minutes after the simulation start time to make sure that it happened after the complete convergence of the network. The simulation duration was set to 45 min for each simulation run. The results were collected for each simulation run after being repeated ten times. Then, the averages of the obtained results were calculated. All these considerations were deemed important for achieving an effective investigation of the Dynamic-RPL with well-considered experimentation.

Afterward, network performance comparisons among the experimental results collected for all the different stages were made. Then, a comparison with other existing relevant approaches ([17,19,20,24]) was also carried out. For an effective performance analysis, a set of network measures that provide practical indications of the overall network performance were considered. In addition, some operational protocol measures, particularly convergence time and dynamic adjustment delay, were also considered to investigate protocol efficiency. All the considered evaluation measures can be categorized as follows:

• QoS-oriented measures: Packet Delivery Ratio (PDR), throughput, delay, and ETX.
• Control overhead: DIO transmission rate and overall control message transmission rate.
• Energy efficiency: consumed energy.
• Protocol responsiveness: convergence time, resolution time, and adjustments’ time.

The calculation of these network performance parameters was based on a well-defined measurement. This can be simply explained as follows:

• PDR: the ratio of all the successfully received data packets to all the data transmissions made across the network.
• Throughput: the average of the total number of bits in all the successful transmissions of the data packets per second.
• Delay: the average time taken using all the data packets from being transmitted to received.
• ETX: the average of the total number of transmissions/retransmissions made to achieve successful delivery of the data packets.
• Overhead rate: the average number of local and global control packets being exchanged over the network.
• Energy consumption: the energy consumption data provided with the powertrace module indicate the time spent during different mote states (CPU, low power mode, transmit, and listen states). Having these multiplied by their corresponding current consumption levels and the power supply voltage (as specified in [33]), the average energy consumption was then calculated in the unit of Joules.
• Convergence time: the time needed using all nodes to join the network after having the network originally initiated using the first-running sink node.
• Resolution time: the time required for Dynamic-RPL to completely restore the network performance after it started to degrade. This was calculated and then averaged for each simulation run.
• Adjustment time: the average time taken using a node running Dynamic-RPL to complete a dynamic topological adjustment during each simulation run.

7. Results and Discussion

The results presented in

Table 3. QoS Performance Results During a Steady State of the Network.

Protocol	Setup	PDR	Throughput	Delay	ETX
RPL	S1	99.06	238.15	128.44	195.12
	S2	95.43	352.89	130.26	243.51
Dynamic-RPL	S1	98.78	235.01	128.87	197.96
	S2	94.96	346.07	133.86	252.18

indicate the QoS performance of the standard RPL and Dynamic-RPL for each experimental setup when the networks were stable. It can be noticed that both performed well considering all the collected QoS performance measurements. High PDR and throughput were achieved in addition to having the delay and ETX maintained at low levels. This is reasonable as the situation in the network is quiet without any stability or load issues.

However, Dynamic-RPL exhibited slight increases in delay and ETX of less than 4% particularly in the multi-DODAG and relatively larger-scale setup of S2. Another increase of less than 5% in energy consumption can also be seen in the case of S2 as indicated in Figure 10a. These were caused with the higher network overhead imposed with Dynamic-RPL. Figure 11a shows that Dynamic-RPL increased the overhead rate by a little more than 20%. All these increases are attributed to the additional global communications maintained using Dynamic-RPL among the global-nodes, which constituted up to 30% of the topology. As a result, most of the wireless links became a bit more busy compared to the case of standard RPL. Despite such insignificant degradations, Dynamic-RPL was able to maintain almost similar overall QoS performance to standard RPL during the steady state of the network.

However, standard RPL struggled when the situation in the network deteriorated. As presented in

Table 4. QoS Performance Results During Adverse Network Conditions.

Protocol	Setup	PDR	Throughput	Delay	ETX
RPL	S1	91.37	203.62	199.14	287.9
	S2	84.92	289.66	223.59	375.38
Dynamic-RPL	S1	96.04	227.69	131.15	206.22
	S2	91.44	323.78	138.61	266.09

, it experienced reductions of up to 18% in PDR and throughput compared to its performance when the network was stable. It also ended up with increased delay and ETX by more than 48%. Figure 10b shows that the situation led to a high level of energy consumption with increases of more than 67%. In addition, network overhead also noticeably increased as shown in Figure 11b. These results indicate that it became challenging for standard RPL to maintain high performance in the presence of stability and load issues across the network. Standard RPL lacks the means to rectify the situation and restore the network to its steady state.

In the case of Dynamic-RPL, such an impact on the overall network performance was kept to a bare minimum. It successfully detected and reacted to the stability and load issues without serious damage to the network. As presented in Table 4, Dynamic-RPL was able to address the stability issues with very little sacrifice of QoS performance. Only 6% reductions in PDR and throughput as well as increases in delay and ETX were experienced at most. The energy consumption increased by 10% only as indicated with Figure 10b. Although Figure 11b shows that network overhead increased by less than 55%, this was very much lower than the case of standard RPL as discussed above.

It is evident that Dynamic-RPL can function effectively under deteriorated network situations compared to standard RPL. The results show that it was able to maintain a higher QoS performance of approximately 20% than standard RPL. It also managed to lower the energy consumption and network overhead by more than 30% and 60%, respectively. The ability of Dynamic-RPL to adapt allowed the network to successfully retain its steady state. However, it is important to understand how responsive it was to the situations in both experimental setups.

Before that, Figure 12 shows Dynamic-RPL added to the time taken using the network to converge after being initiated. Compared to standard RPL, that was less than 6 s even in the relatively more complex and large-scale setup of S2. This extra time was taken using the global-DODAG establishment stage, which imposed additional communications after each completely-established-local-DODAG. In regard to how responsive it was, Dynamic-RPL did not need much time to resolve the stability and load issues as indicated in Figure 13. Only up to 23 s was required to restore the overall performance of the network. Figure 14 also shows that each dynamic operation imposed using Dynamic-RPL took as little as a maximum of 7 s to be completely performed. While Dynamic-RPL was able to adapt with a reasonably low delay, standard RPL continued to struggle with the challenging situations without being able to effectively settle down.

Although they demonstrated similar performance variations for both experimental setups, all the observations were more significant in the case of S2. This is due to its relatively large-scale setup, which was developed in a more complex form with a multi-DODAG topology. Increasing the size and complexity of the network topology had noticeable performance impacts on both protocol variants. However, this is more evident in the case of standard RPL under unstable network conditions. Dynamic-RPL experienced less performance variation as the network scaled up in all the scenarios.

The comparison provided in

Table 5. Comparison of Dynamic-RPL with Relevant Existing Solutions.

Solution	PDR	OH Rate	Fully Dynamic Topology	Inter-routing Support
[17] (2020)	85%	20 (per node)	×	×
[19] (2020)	76%	75	×	×
[20] (2019)	92%	97	×	×
[24] (2020)	90%	82	×	×
Dynamic-RPL	91%	64	√	√

demonstrates the efficiency and feasibility of Dynamic-RPL compared to relevant existing solutions. Although Refs. [20,24] provided high PDR results, Dynamic-RPL achieved similar performance with the least network overhead rate. It succeeded in reducing network overhead by more than 13%. It is apparent that Dynamic-RPL provides a promising dynamic topology management solution. It effectively guarantees competitive overall performance, better adaptation to network deteriorations, and more dynamic and effective functionality.

8. Conclusions

The vulnerability to performance degradation and failure under adverse network conditions is still a serious challenge for RPL networks. No standard support is provided to address stability and load issues being experienced across the network. The evaluation results indicated the inability of standard RPL to adapt and maintain high overall performance during challenging network situations. However, Dynamic-RPL provides an effective solution to rectify such situations and restore the high performance of the network. It introduces dynamic topology management to the original RPL functionality without adding much to its design complexity. It is based on applying effective DODAG aggregation and partitioning in a dynamic and distributed manner for optimizing the network toward better performance and stability.

The extensive evaluation of Dynamic-RPL exhibited its high robustness and efficiency considering different scenarios in varying-scale setups. In addition to revealing similar QoS performance to standard RPL during steady network conditions, Dynamic-RPL noticeably maintained higher performance in challenging situations. Compared to the standard RPL, it was able to achieve 20% higher QoS performance while lowering energy consumption and network overhead by more than 30% and 60%, respectively. The ability of Dynamic-RPL to successfully adapt allowed for restoring the network to its steady state in a responsive manner. Only a few seconds were required for successful dynamic topological adjustments and complete network convergence.

It is evident that Dynamic-RPL provides effective functionality with enriched support toward practical network flexibility and dynamicity. It effectively guarantees competitive overall performance, better adaptation to network deteriorations, and fully dynamic functionality. This is important to enrich the efficiency and revive the potentiality of RPL for a broader range of IoT applications.

The plan for future work is to implement and evaluate Dynamic-RPL in a physical testbed environment using real IoT devices with more realistic data communications. Another important consideration is investigating how the dynamic functionality of Dynamic-RPL can be utilized to address an effective security solution. The ability to dynamically adjust the topology in response to network changes can be further extended to defend against RPL security attacks. Moreover, incorporating additional modules to effectively support other networking aspects such as failure recovery and load balancing would be another research direction for the future.