IJCNC 05

CONGESTION AND ENERGY AWARE MULTIPATH LOAD BALANCING ROUTING FOR LLNS

Kala Venugopal and T G Basavaraju

Department of Computer Science and Engineering, Government Engineering College, Hassan, Karnataka, India

ABSTRACT
The Internet of Things (IoT) is presently in its golden era with its current technological evolution towards digital transformation. Low-power and Lossy Networks (LLNs) form the groundwork for IoT, where the IPv6 Routing Protocol for Low-Power and Lossy Networks (RPL) is designated by Internet Engineering Task Force as the benchmark protocol for routing. Although RPL, with its unique capabilities, has addressed many IoT routing requirements, Load balancing and Congestion control are the outliers. This paper builds on the RPL protocol and proposes a multipath Congestion and Energy Aware RPL (CEARPL) that alleviates the load balancing and congestion concerns associated with RPL and improves the network performance. For congestion avoidance, a Congestion and Energy Aware Objective Function (CEA-OF) is suggested during parent selection that considers multiple metrics like Child Count metric, Estimated Lifetime metric, and Queue Occupancy metric, to equally distribute the traffic in LLNs. The Queue Occupancy metric is used to detect congestion in the network, and a Multipath routing strategy is utilized to mitigate the congestion in the network. A comparison of the performance of CEA-RPL was made against the existing Objective Functions of RPL, OFO, and MRHOF, as well as COM-OF, utilizing Contiki OS 3.0’s Cooja emulator. CEA-RPL projected superior results with power consumption lowering by 33%, endto-end delay decreasing by 30%, queue loss ratio reducing by 49%, and packet receiving rate and network lifetime improving by 7% and 49%, on an average, respectively.

KEYWORDS

Congestion, Multipath routing, Internet of Things, Load balancing, Low-power Lossy Networks, Objective function & RPL

1. INTRODUCTION

The Internet of Things has quickly emerged as one of the most important technological developments of the twenty-first century. It is a futuristic idea where physical objects are connected to the virtual world and can operate as physical access control points to the Internet and its services. In IoT, “things” refer to a collection of physical objects embedded with sensors, actuators, software, processing power, network connectivity, etc., that can collect and exchange data with real-world systems and devices over an already-existing network infrastructure. The collected data is sent through the IoT gateway to be analyzed on other devices or in the cloud. IoT devices are expected to generate 73.1 ZB (zettabytes) of data by 2025 [1].

The IoT ecosystem encompasses a particular class of networks called Low-Power and Lossy Networks that have restrictions on the routers and their connectivity [2]. The majority of nodes in LLNs are constrained, having little memory, processing capability, and occasionally even energy if they are powered by batteries or energy scavengers. A standard protocol called IPv6 over Lowpower Wireless Personal Area Networks (6LoWPAN) enables IPv6 communication on wireless networks made up of low-power wireless modules. 6LoWPAN is considered one of the preferred

protocols for implementing the Internet of Things. For the LLNs, several routing protocols have been proposed that include 6LoWPAN ad hoc on-demand distance vector routing (LOAD), Dynamic MANET ON-Demand for 6LoWPAN (DYMO-low), hierarchical routing over 6LoWPAN (hilow), Tiny ad hoc on-demand distance vector (TinyAODV), hybrid routing protocol for lossy and low-power networks (Hydro), etc. However, there was a growing demand for a standard solution due to all these proprietary solutions failing to achieve much traction in the market.

The IETF (Internet Engineering Task Force) ROLL (Routing Over Low-Power and Lossy Networks) working group [3][4] developed an IPv6 routing protocol that is specifically optimized for wireless LLNs called the Routing Protocol for Low-Power and Lossy Networks (RPL) [2]. RPL has numerous outstanding qualities, including quick topology creation, low battery consumption, loop-freeness, and self-healing capabilities. RPL’s design for lossy links, is a crucial component of the protocol, making it vulnerable to high Packet Error Rates (PER) and link outages [5]. However, RPL still has to be enhanced in many areas, such as load balancing, support for mobility, and stability, even though it is now standardized and widely recognized by the community [6].

Load imbalance is regarded as one of the severe flaws in this protocol [7]. RPL is more concerned with the non-uniform distribution of load that can result in uneven traffic distribution in LLNs. As a result, the overloaded nodes’ energy will be depleted considerably more quickly than that of other nodes. Also, congestion is one of the frequent problems caused by an unbalanced load in the network resulting in packet losses and delays in the network [8]. This could lead to energy wastage and reduced network lifetime. Therefore, load balancing is crucial to congestion and network longevity.

A Multipath Congestion control routing strategy called Congestion and Energy Aware RPL (CEA-RPL) is presented in this research work to balance the network load and thereby achieve network lifetime extension, stability, and reliability of RPL networks. The key features of the proposed technique include the following.

• Congestion Awareness at the parent node using the Queue Occupancy metric.
• Congestion Notification utilizing the Emergency DODAG Information Object message to inform about the congestion at the parent node to the child nodes.
• Congestion Mitigation using the Multipath routing technique. 
• Congestion Avoidance using the Congestion and Energy Aware Objective Function (CEA-OF) based on multiple metrics to construct a congestion and energy aware load balanced DODAG (Destination Oriented Direct acyclic graphs) that alleviates energy consumption, extends the lifespan of the network, and enhances reliability and stability of the network in comparison to the standard RPL.

The paper is organised in the following manner: Section 2 of this research discusses the working, relevant survey, and issues of the RPL protocol. An understanding of the proposed Congestion and Energy Aware RPL (CEA-RPL) is presented in Section 3. Section 4 projects the proposed work’s performance evaluation. Finally, Section 5 includes the paper’s conclusion and suggestions for further research, together with the list of references.

2. BACKGROUND AND RELATED WORK
2.1. Routing in LLNs

IPv6 over Low-power Wireless Personal Area Network (6LoWPAN) is a significant standard that connects constrained low-power devices to the IPv6 network. To address the routing issues in 6LoWPAN, the IETF, ROLL working group has recommended a routing protocol called RPL (Routing Protocol for Low-Power and Lossy Networks) as the standard routing protocol for LLNs. The foundation of the RPL protocol is the 6LoWPAN, which is linked to the IP network through the sink or root node, as shown in Figure 1.

Figure 1. RPL IoT Network

RPL is a proactive distance vector routing protocol that operates on IEEE 802.15.4 Physical (PHY) and Medium Access Control (MAC) layers. The foundation of RPL is the topological idea of Directed Acyclic Graphs (DAGs) [5] that specifies the default paths between the LLN nodes in a topology resembling a tree. RPL structures a DAG topology which is then divided into additional DODAGs (Destination Oriented DAGs), with a sink allotted to a DODAG. The RPL nodes of an RPL Instance select and optimize routes according to the Objective Function, abbreviated as OF. RPL uses two Objective Functions (OFs), Minimum Rank with Hysteresis OF (MRHOF) [10] and Objective Function Zero (OF0) [9], to optimize the choice of a path to the root node. Objective Function Zero (OF0) aims to locate the nearest grounded root. OF0 employs the hop count metric to calculate a node’s rank and determine the path to the sink node. In contrast to OF0, the MRHOF chooses reliable routes that lower the metrics like Expected Transmission Count which quantifies the number of successful packet transmissions to the destination.

The construction of DODAG is based on the neighbour discovery process, which uses four types of RPL control messages [5]. The ICMPv6 protocol specifies the following message types: DODAG Information Object (DIO), DODAG Information Solicitation (DIS), Destination Advertisement Object (DAO), and Destination Advertisement Acknowledgement (DAO-ACK). When a new node attempts to connect and link to a network, it sends a DIS message to investigate the DODAG nodes in its immediate area. The root node transmits the DIO messages to the network’s child nodes based on the Trickle timer. It is important to note that the Trickle timer is used for managing the amount of time that passes before DIOs are sent [17]. The surrounding nodes can recognize the RPL Instance using the DIO messages and select a parent depending on the Rank and other design criteria. A node’s rank indicates its position in regard to the DODAG root and in reference to the other nodes in the network [2]. A node’s rank accurately advances in the downward direction and declines in the upward direction. 

A new node that accepts the DIO message, updates the parent list with the sender’s address, and uses the objective function to determine its new rank. The DIO message then announces this rank. When an existent node gets a DIO message, it can either ignore it or compute the rank using the objective function. If a node’s evaluated rank is lower than its present rank, it adopts a better place in the DODAG dropping the current parent. If not, it may continue to hold its current position in the DODAG. Thus, it is possible to eliminate routing loops in the DODAG by considering the fact that the parent nodes’ rank must be lower than the child nodes’ rank. In response to the DIO message, child nodes send the parent a DAO message that communicates the route information for the construction of the reverse route. A node sends back a DAO-ACK messages after receiving a DAO message. Following the construction of the DODAG, each node routes traffic to the root node using the most preferred parent node as its default route.

The two major modes of operations stated by RPL are the Storing mode and the non-storing mode. In the non-storing mode, the whole routing table is only present in the border routers of the RPL domain. Whereas, in the storing mode, the whole routing table of the RPL domain is stored on all nodes. Each node is capable of immediately communicating with every other node. In the DODAG Version, nodes use their DODAG parents to provide routing table entries for the destinations listed in the DIO message. As a result, we can state that each node in the RPL maintains a Parent Table (PT), which includes a list of all the prospective parents and serves as a parent node. A node adds DIO messages that it receives from nearby nodes to the PT.

2.2. Multipath Routing in RPL

One of the research challenges for RPL in IoT is Multipath routing. RPL supports single-path routing where at every node, the flow of data traffic is directed over a single parent, which is selected in accordance with an objective function [11]. One could argue that single-path routing limits the utilization of IoT network resources and the protocol’s potential to provide more effective routing across constrained LLN networks. In RPL, when a node is in use and experiences a broken link, a local repair mechanism is utilized to fix such broken links. This is one of the constraints of single-path routing in RPL. The node suffering the broken link will, similar to the first time it joined the network, disseminate a DIS message to obtain the latest topology information and then wait for a DIO message during a local repair. Additionally, more DIO messages are broadcast as a result of its neighbours’ resetting their DIO trickle timers after receiving this DIS message. Consequently, local repair increases the nodes’ energy consumption and delay [18].

Multipath routing discovers and utilizes numerous pathways to route the data between source and destination node pairs as opposed to using only a single-path [11] [12] [13]. When a network link fails, Multipath routing chooses an alternative path to transfer the packets rather than relying on the route discovery process. Utilizing these additional channels for data forwarding when an active path is congested decreases the amount of time needed to reconfigure the network’s topology, increasing the throughput and network longevity [14]. The multipath technique can also reduce the stability and convergence issues caused by these frequent DODAG reconstructions [15].

Higher reliability, fault tolerance, better throughput, congestion alleviation, and hole avoidance are few of the multiple goals that Multipath routing can achieve [16]. Multipath routing has a plethora of projected benefits, that include fault Tolerance and reliability, load balancing, bandwidth aggregation, Quality of Service (QoS) improvement and security [12] [13] [19] [20]. Multipath routing’s primary function is the development of many pathways in a network and the distribution of traffic across the discovered paths. Multipath routing is basically designed based on three principles: Path Discovery, Traffic Allocation or Distribution, and Path Maintenance [12][13][19].

2.3. Related Survey

As aforementioned, load balancing is a significant challenge in RPL, and researchers have proposed many Objective Functions and metrics based on Multipath routing, Congestion Awareness, etc., to enhance load balancing, fault tolerance, and the quality of service in RPL networks. A brief review of these proposed methods is given below.

Energy-balancing routing protocol, which is an energy-balanced variation of RPL, is devised in [22] to increase the lifetime of constraint nodes by permitting each node to consume an equal amount of energy. A multipath strategy, which is an extension of [15], is recommended in this article to get around the issue of convergence, which might cause network instability. A unique metric referred to as the Expected Lifetime metric is presented to calculate the remaining time before a node runs out of energy. RPL was emulated using WSNet, a robust event-controlled WSN simulator. The results of simulations demonstrated enhanced routing reliability as well as the lifetime of the network while simultaneously minimizing the number of DAG reconfigurations. M-RPL, which stands for “Multipath extension of RPL,” is proposed in [23], which is an extension to the work in [16], to offer temporarily multiple paths when there is congestion over a particular path in the network. Buffer size and packet delivery ratio at forwarding nodes are used to detect congestion. Once congestion is discovered, the parent node sends periodic DIO messages containing Congestion Notification messages to the child node. Creating partially disjoint alternative pathways and avoiding packet forwarding over the congested node alleviate congestion. Here, the packet forwarding rate of a node is halved to the overloaded node and alternate packets are transmitted to any neighbouring node other than its preferred parent. This reduces congestion on the congested parent node and creates partially disjoint paths. Detailed simulation of M-RPL against RPL in the grid and random topologies using the Contiki Operating System and Cooja simulator demonstrates that M-RPL mitigates congestion and boosts network throughput.

On-Demand Selection (ODeSe), a cutting-edge Multipath routing method, is presented by the authors in [25] and addresses the trade-off between energy utilization and reliability in the industrial IoT environment. In this scenario, the MAC protocol is Time Slotted Channel Hopping (TSCH) according to IEEE Standard 802.15.4-2015, and the routing protocol is RPL. This study is an enhancement of [24], which uses the Common Ancestor (CA) algorithms, where multipath with CA achieves great reliability using multipath approaches at the expense of increased energy utilization. The suggested ODeSe algorithm improves the reliability against energy consumption trade-off by achieving very high reliability with lower energy usage. To enhance the network’s availability and dependability, the Replication and Elimination, Packet Automatic Repeat reQuest, and Overhearing (PAREO) services are implemented. ODeSe surpasses single-path RPL in dependability and multipath RPL in energy usage, retaining a packet delivery ratio of 99.14%. The issues with RPL routing protocol with regard to QoS and congestion control under heavy traffic load are explored in [26]. By lowering congestion and increasing quality of service, an enhanced protocol known as Congestion and QoS-aware RPL (CQARPL) was developed. The ETX metric, the circumstances of the routes to the root, the hop count, congestion, and residual energy are all evaluated by this protocol for choosing the parents. Additionally, CQARPL keeps the DODAG graph in balance by controlling the selection of parents and acceptance of children. In addition, it allows for the prediction of congestion and the prevention of its occurrence to the greatest extent possible. Utilizing the Cooja simulator, the proposed protocol is put into practise and evaluated against a number of scenarios as well as Context-Aware and Load balancing RPL (CLRPL) and RPL. According to the simulation results, CQARPL outperformed RPL and CLRPL, imposed minimal network overhead, maintained transmission quality, and controlled congestion in IoT. 

2.4. Load Balancing issue and Problem Description in RPL

Due to the fact that RPL is designed for networks with diverse devices, it must control erratic and excessive traffic. The connection of LLNs can be impacted when there is an excessive traffic or an imbalance in the amount of traffic or load in the network, which can result in a variety of problems such as network congestion, overuse of the node’s energy, and a reduction in the network’s longevity, dependability, and stability [28]. Congestion, as mentioned, is one of the major issues caused by RPL Objective Functions and metrics that does not take load balancing into consideration.

Load imbalance and the ensuing congestion in a network is induced due to various reasons that include the hotspot problem, bottleneck problem, thundering herd problem, instability problem, or the randomly unbalanced network problem. In the hotspot problem [29], a chosen parent node turns into a network’s hotspot when overburdened with traffic during network congestion. To control the traffic, the node advances the amount of data relayed, thereby consuming more energy, and shortening the network’s lifetime. Bottleneck nodes are the first-hop hotspots to the root. Since majority of the traffic is forced to pass via the bottleneck nodes, the energy levels at those nodes deplete much more quickly, causing the bottleneck problem [7]. The Thundering herd problem also called the herding effect problem [27], arises when a group of nodes makes a fruitless effort to ensure that the load is distributed evenly in a network during congestion by alternating between the preferred parent nodes. A problem known as network instability [30] raises similar concerns. This issue occurs when nodes continuously change which parent they wish to be connected to based on the parent’s most recent rank and link metric. The “Randomly unbalanced network” problem [6] is another factor that might result in load imbalance entirely by chance. In this situation, a preferred parent is chosen repeatedly and arbitrarily from a pair of parent nodes with the same rank.

The rank a node propagates, in RPL, is usually centred on its hop count value (shortest distance) to the root node, as in OF0 [9], or based on the reliability of the link towards the root node based on the ETX value, as in MRHOF [10]. Therefore, a rank a node propagates directly reflects the link congestion toward the sink node. However, the node congestion is totally ignored or not taken into consideration in RPL for the rank calculation and for the selection of parent node. It is worth noting that despite tremendous traffic, the ETX remains mostly constant in RPL because links often have more capacity than queues at nodes [27]. In Low-power Lossy Networks, as the queue size at a node is significantly smaller when compared to high-rate communication devices, the queue at each node overflow far before the congestion gets severe enough to be detected using ETX. Therefore, the RPL parent selection mechanism does not reflect the energy utilization and node congestion but only the link congestion. Also, as the trickle in RPL is unaware of the congestion, the impacted node cannot report congestion in RPL, forcing the child nodes to continue with the existing congested parent. Therefore, to solve the load balancing issue with RPL, it is preferable to employ a new routing measure and a parent selection technique that considers both energy consumption of the nodes and congestion both at the node and link level.

3. THE PROPOSED CEA-RPL: CONGESTION AND ENERGY AWARE RPL

In this section, a multipath Congestion and Energy Aware RPL (CEA-RPL) that considers load balancing in LLNs is proposed to alleviate the load balancing and congestion issues mentioned in the previous section.

3.1. Proposed Routing Metrics

In an objective function, the metric, which is referred to as the path cost, is used to guide the decision-making process while choosing a path [31]. The metric could be a link- based metric like ETX or a node-based metric like energy. The following list provides a discussion of the metrics of interest that were taken into consideration for our proposed work.

1) Queue Occupancy metric (QO) for Congestion Detection: Queue Occupancy factor measures how many packets are in a node’s queue in relation to the size of the overall queue as given in Equation 1. QO is a node metric that reflects a node’s buffer occupancy rate. The QO metric is used to measure the node-level congestion in a network and is selected for the purpose of identifying and disseminating information concerning congestion. It accurately portrays the current state of congestion at each node.

Where NpQ(k) and Qs(k) represents the packets in node k’s queue and the size of node k’s queue respectively.

2) Expected Lifetime metric (ELT) for Energy Awareness and Reliability: ELT metric calculates the Expected Lifetime of a node, which is the remaining time before a node runs out of energy while transmitting the same amount of traffic. When using an objective function that is based on ELT, the child node will select the parent from among the neighbouring nodes based on which node has the most extended lifetime.

The ELT of a node N, ELT (N), is computed as the proportion of a node’s remaining energy or residual energy, Eresd(N), to the energy used to transmit the traffic to and from it, Etrans(N), as given in Equation (2).

Thus, it is simpler to identify the bottleneck nodes and balance the overloaded nodes when using the Expected Lifetime metric (ELT), as it also considers a node’s residual energy (Eres), the data traffic at a node, and the link reliability (ETX).

3) The Expected Transmission Count metric (ETX): The Expected Transmission count metric is the estimated number of transmissions needed to reliably transport packets from the sender to the receiver node with no faults. ETX metric is a link metric that reflects the link reliability in terms of quality of the link. Therefore, the ETX metric can be utilized to detect the link level congestion in a network. The ETX metric is calculated for a link using Equation (3)

Here, PSR represents the probability that the sender’s packet will reach the recipient successfully, and PRS represents the probability that the sender will successfully receive an acknowledgement from the receiver before the timeout expires.

4) The Residual energy metric: Residual energy is a node metric that shows a node’s leftover energy. It represents the Expected Lifetime of a node and helps prevent selecting nodes with low residual energy, thereby improving the network’s lifetime. The residual energy of a node, Eresd(N), is computed as the ratio of the node’s initial energy, Einit(N), to the current energy of the node, Ecur(N), as given in Equation (4)

5) The Child Count metric (CC): While building a DODAG in the RPL network, as part of the parent selection process, we use the Child Count metric to maintain a record of a specific parent node’s child nodes [7]. This metric allows to accomplish the goal of maximizing the node’s lifetime while also addressing the problem of overloading it. During RPL DODAG building, a parent node normally discards the child node’s DIO message. Our proposed work buffers the child node’s DIO message and determines its child node count [7]. The RPL InstanceID, the objective function, and information about the node’s rank are added to the DIO message along with the node’s Parent ID to achieve this. The parent node adds the child node’s DIO message to a buffer set and matches the Parent ID to its own. If found similar, by incrementing the child set value by one, the parent node keeps track of the number of child nodes during DODAG creation.

3.2. Congestion Awareness using Queue Occupancy metric

Congestion in a network refers to heavy or bursty traffic in the network that exceeds the capacity of the network. This can result in packet losses and high latency rate and affect the network’s quality of service. RPL networks that do not consider load balancing eventually leads to congestion in the network, consuming more energy and reducing the network lifetime, reliability, stability, etc. The awareness or detection of this congestion in the network and the dissemination of this information to the other nodes in the network is very important to further control the congestion and alleviate load balancing issues.

Since the queue or the buffer at a node in the network overflows far before congestion gets to be noticed by ETX metric, in our proposed work, we use the Queue Occupancy metric to identify the node-based congestion in a network as given in Equation 1. Here, the average Queue Occupancy of a node is monitored for a certain interval of time called the Congestion Interval (CI) [23]. The duration of the CI is representative of the decision time necessary to identify congestion. If the average QO value crosses a specific threshold value during the Congestion Interval, then congestion is detected in the network, and the same must be notified to the child nodes. Here, we consider the QO threshold value as 0.5, which is 50% of the buffer occupancy at a node. We picked a threshold value of 0.5 since a lower value would not induce network congestion and would generate unnecessary load balancing congestion mitigation activity. If we picked a higher threshold value, congestion detection would be delayed causing further packet loses and latency in the network.

In our proposed work, the Congestion Interval time and the duration of the trickle timer are not in line with each other. The DIO messages in RPL are sent after the expiry of the trickle timer, and the DIO interval varies to cope with the network conditions. If congestion is detected at a node and if the expiry of the trickle timer is lesser than or equal to half the CI, the DIO message itself does the notification of the congestion by carrying the updated increased rank value of the

congested parent node, reflecting the recent QO value based on Equation (1). On the other hand, if congestion is detected at a node and if the expiry time of the trickle timer is more than half the CI value, then a Congestion Notification (CN) message is sent immediately using an Emergency DIO (EDIO) message [23]. Therefore, in our work, the only single additional message included in RPL is the EDIO message, which is used to alert congestion right away when the periodic DIO messages are not available.

Table 1. Notations used in Algorithm 1

The algorithm for the Congestion Awareness using Queue Occupancy metric is given in Algorithm 1 (cf. notation in Table 1).
Algorithm 1: Congestion Awareness using QO metric Begin

3.3. Congestion Mitigation through Multipath routing

Congestion mitigation is initiated when a child node receives an EDIO message with Congestion Notification or the notification through the updated incremented rank value of the congested parent node. To enhance and address the congestion issue of single-path RPL, we use the Multipath routing system for the congestion mitigation process. Here, every node has the capability of storing in the parent list of its Parent table, several accessible parent nodes or alternate parent nodes, considering their Queue Occupancy metric, Child Count metric and Expected Lifetime metric, as explained in CEA-OF (Congestion and Energy Aware Objective Function) in the next section. Here, as suggested in [36], we use a hybrid scheme using both traffic control and resource control to mitigate congestion issues.

When congestion at a node exceeds the threshold value and notification regarding the same is sent to the child node, the child node’s data forwarding rate is immediately reduced to half and split into numerous paths as part of Multipath routing [21]. One packet is forwarded by the child node to its congested parent, whereas the subsequent packet is forwarded to another parent stored in the parent table list. Here, the data is split into two routing paths. Since the proposed work considers CEA-OF to select the alternate parent, the parent with the least congestion, child count, and better load balancing is selected from among the other parents to forward the packet. As the packet rate or traffic to the congested node is reduced by half, Multipath routing helps to alleviate the congestion at a node.

However, when congestion is identified in a network by a node receiving the notification, there are possibilities that the node chooses a newly congested neighbour to temporarily forward the data. To identify and keep track of the neighbouring nodes or alternate parents that are congested with sudden or bursty traffic, a node also records the CN message from its neighbouring nodes in its Parent table. This will help to avoid congested path selection in Multipath routing. This process also wouldn’t require any extra additional cost in terms of communication or processing because the CN is sent in a DIO message which is heard by all the neighbouring nodes in RPL. Finally, the node stops splitting the of traffic to multiple paths when it does not hear the CN message or when the rank value of the congested parent is reduced. This Multipath routing strategy helps maintain the network’s stability and reduce the instability problem caused by frequent preferred parent changes, to a certain extent, during congestion.

3.4. Congestion Avoidance using CEA-OF: Congestion and Energy Aware
Objective Function

In LLNs, Congestion Awareness, Notification, and Mitigation are alone insufficient to alleviate the load balancing issues mentioned in section 2.4. All these strategies come into existence once the congestion is triggered in the network. The most important criterion for Lossy Networks is congestion avoidance so that a load balanced DODAG is constructed, minimizing the energy usage, and increasing the network’s lifetime, reliability, stability, etc. In [28], a Combined metric Objective Function (COM-OF) incorporates residual energy, ETX, network longevity, and node child count to generate a load balanced DODAG. However, congestion in the network and Multipath routing strategy was not taken into consideration here. Therefore, the network was not prepared for the bursty traffic from the nodes in the network.

To solve the above issue, we propose a Congestion and Energy Aware Objective Function (CEAOF) that considers, and to a great extent avoids the congestion in the network, while being aware of energy utilization and network longevity. Here, a load balanced DODAG is constructed taking into consideration the congestion at the nodes, the child count at the nodes, their estimated lifetime, which also takes into account the nodes’ residual energy and connection dependability. In RPL, a node typically ignores or discards the DIO message it gets from its child node. As stated in section 3.1, the DIO message is appended with the Parent ID during DODAG construction in our proposed work. When a node receives a DIO message, it checks to see if the message came from one of its child nodes by comparing the Parent ID with its own ID. DIO message from a child node is buffered to maintain track of the child count using the Child Count metric. Every node calculates the congestion at a node using the Queue Occupancy metric as explained and given in Equation (1). It also calculates the residual energy at a node as given in Equation (4), the link reliability to its parent node as given in Equation (3), and the throughput metric of the node traffic [22]. These values are, in turn, used to calculate the Expected Lifetime of the node as given in Equation (2), reflecting the time before which a node runs out of energy while transmitting the traffic at a particular rate.

We suggest utilizing the metrics listed above in our work because it offers several benefits. The Child Count metric can help distribute the load evenly in the network in terms of the parent node’s child count, thereby avoiding congestion in a network due to heavy traffic from too many child nodes joining a node. This, in turn, aids in network load balancing avoiding the hotspot problem. By calculating rank based on the parent node’s Queue Occupancy, which indicates a less congested path, network congestion can be avoided by selecting a parent node with a lower QO value. A node also utilizes the Expected Lifetime of its parent node in terms of residual energy and link reliability, thereby choosing a parent with prolonged ELT value. This aids in avoiding the data forwarding bottleneck nodes and improving network load balancing. As a result, the suggested objective function CEA-OF chooses the preferable parent node based on congestion avoidance and load balancing with minimal child count value, energy consumption, queue occupancy, ETX value, and maximum lifetime and reliability of the network. Algorithm 2 (cf. notation in Table 2) provides the proposed Congestion and Energy Aware Objective Function (CEA-OF).

Table 2. Notations used in Algorithm 2

Algorithm 2: Congestion and Energy Aware Objective Function (CEA-OF)

The metrics in our proposed work, QO and CC, are minimizable except for the ELT metric, which is maximizable. The derived metrics need to be converted into the same domain [33] to calculate the rank value. Therefore, to calculate the rank, the inverse lifetime minimization [34] as given in Equation (5) is utilized to represent the network lifetime maximization.

where InvELT(N) is the Inverse Lifetime value of node N.
Finally, the minimum objective function is defined as given in Equation (6)
CEA-OFmin (QO, InvELT, CC) = a x QO (N) + b x InvELT (N) + c x CC (N) (6)
Where a, b, and c are the three constant parameters utilized to optimize the influence of each metric on the network. Based on multiple simulations, we use the values a=0.4, b=0.3, and c=0.3, that should be between 0 and 1, with an overall value of 1, to have a better impact on the network.
The flowchart explaining the process of CEA-RPL is given in Figure 2.

Figure 2. Flowchart of the process of CEA-RPL

The steps involved in the process of CEA-RPL (flowchart) are explained briefly in steps given below.

Step 1: A new node on receiving its first DIO message, adds the sender as its parent node and calculates its rank with respect to the parent node using the CEA-OF. It then sends back the DAO message to its parent node and finally multicasts the DIO message carrying its rank to its neighbours.
Step 2: When an existing node gets a DIO message, it first verifies that it meets some RPLspecified constraints or requirements. This involves accepting or rejecting the DIO message for further processing. Malformed DIO messages cannot be processed, and hence will not satisfy the constraints and will get rejected.
Step 3: A node keeps a buffer for each DIO message it gets from its child nodes, incrementing the child count value and keeping track of the child count as explained in section 3.1. Step 4: The Queue Occupancy metric, as described in Algorithm 1, is used by a node to determine whether its current parent node is congested if it receives a DIO message from that node. If congestion is detected at the parent node, then congestion mitigation is initiated using the Multipath routing technique, as explained in section 3.3. If not, it calculates its rank using CEAOF and updates its position in the DODAG.
Step 5: A node adds the parent to its parent list kept in the Parent table if it receives the DIO message from other parent nodes. It then calculates the QO, ELT, and CC values to compute the updated rank based on CEA-OF. In case the newly calculated rank is lower when compared to node’s current rank, the sender parent node will be accepted as the node’s new parent, thereby updating its position in the DODAG, and discarding the existing parent.

4. PERFORMANCE EVALUATION

The simulation environment and the performance evaluation of the proposed multipath Congestion and Energy Aware RPL (CEA-RPL) against the COM-OF [28] and the existing RPL Objective Functions RPL-OF0 [9] and RPL-MRHOF [10] are examined in this section. In addition, we contrast the protocols from the perspective of network’s traffic volume and density.

4.1. Simulation Environment

Our simulation experiments were run on the Contiki Operating System [32] utilizing the Cooja simulator to evaluate and compare the performances of CAE-RPL with the COM-OF [28] and the existing RPL Objective Functions RPL-OF0 [9] and RPL-MRHOF [10]. A widely used, approachable, and open-source operating system called Contiki has been created specifically for the Internet of Things. To simulate Contiki-based applications, a potent cross-layer network simulation software tool called Cooja was developed. Although Cooja is written in Java, sensor nodes can be implemented using C language and allows users emulate Contiki motes of both small and enormous networks.

The Contiki OS 3.0 is used with IEEE 802.15.4 communication protocol. For our simulation, we emplo Tmote sky motes, which are wireless sensor modules with fast data rates of 250 kbits/sec and low-power requirements that facilitate compatibility with IEEE 802.15.4 devices [35]. For radio medium, Cooja UDGM (Unit Disk Graph Medium) with distance loss is utilized. The simulation is carried out for 20 to 100 Tmote sky nodes in steps of 20 that are deployed in a 300 x 300 network for 60 minutes. We compare CEA-RPL with COM-OF and the existing OF0 and MRHOF Objective Functions with respect to the density of the network and the traffic load. The performance parameters considered are the power consumption, Packet Receiving Rate, End-to-End Delay, Queue Loss ratio, and Network lifetime. Table 3. presents the simulation parameters considered for the evaluation.

Table 3. Simulation Parameters

4.2. Results and Discussions

The performance criteria that were examined for evaluating the proposed protocol include the power consumption, End-to-End Delay, Packet Receiving Rate, Queue Loss ratio, and Network lifetime. To make comparisons between the protocols, the network density, and the quantity of traffic present in the network are both considered. In the case of Network density-based performance comparison of the protocols, we consider 20 to 100 Tmote sky nodes (in steps of 20) with a constant traffic rate of 50pps (packets per second). In the case of traffic load-based performance comparison of the protocols, we consider traffic loads of 20pps (packets per second) to 100pps (in steps of 20) for a 60 nodes network. 

4.2.1. Power Consumption

A node’s power consumption is one of the most important aspects that must be taken into account when load balancing in RPL. The amount of energy used by all the network’s nodes on average during its existence is expressed in milliwatts (mW) as power consumption. Because the nodes are powered by batteries, the lifetime of the network is directly proportional to the node’s energy consumption. The power consumption of a node is calculated using Equation (7).

Here, Econ(N) is the energy consumption of a node, and RTime represents the amount of time that passes between a node’s various modes.

1) Network Density and Power Consumption

A comparison of the average power consumption in mW (milliwatts) for 20 to 100 nodes for OF0, MRHOF, COM-OF, and CEA-RPL is given in Figure 3(a). It is obvious that as the number of nodes grows, there is an increase in energy consumption due to the increased data transfer in terms of transmitting and receiving data between the intermediate nodes. However, the results show that our proposed CEA-RPL consumes much lesser power when compared to the other three Objective Functions. On an average, the power consumption of CEA-RPL is decreased by 28.3% and 40.8% when compared to the standard OF0, MRHOF and by 18.3% when compared to COM-OF Objective Functions, respectively. The decrease in the consumption of power is for the reason that CEA-RPL, when compared to OFO and MRHOF, considers load balancing, thereby reducing the energy depleted due to the overloaded nodes caused by uneven traffic distribution. Also, even though COM-OF considers balancing of load to a certain extent, the additional energy wastage is due to the local repair mechanism for broken links in single-path routing when compared to Multipath routing in CEA-RPL.

2) Traffic Load and Power Consumption

The average power consumption with varying traffic load in the network is shown in Figure 3(b). Considering a network with 60 nodes, the energy utilization of the nodes was traced by increasing the traffic rate from 20pps to 100pps in steps of 20. It can be clearly seen that as the traffic increases in the  network, more energy is consumed by the nodes to transfer the data in the network. CEA-RPL outperforms the three Objective Functions by decreasing the average power consumption by 37% when compared to OFO, 48% when compared to MRHOF, and 25% when compared to COM-OF Objective Functions. With increased traffic, CEA-RPL performs remarkably well because it considers network congestion and queue occupancy at each node before routing the packets, minimizing packet losses and retransmissions. This, in turn, lowers the energy usage at the network nodes. Multipath routing in CEA-RPL also distributes the traffic to different paths during congestion or higher traffic loads, thereby reducing power consumption.

Figure 3. Comparison of Power consumption against Network density and Traffic load

4.2.2. Packet Receiving Rate

The Packet Receiving Rate (PRR) is the proportion of packets accepted at the root node to packets transmitted by the source nodes, as defined in Equation (8)

1) Network Density and Packet Receiving Rate

Figure 4(a). compares the Packet receiving rate of the Objective Functions OFO, MRHOF, COM-OF, and CEA-RPL with varied network density. It is seen that, given a constant traffic rate, adding nodes to the network result in a corresponding rise in the PRR. This is due to the fact that as network density rises, there are more nodes available to forward data, which alleviates congestion at network nodes compared to when there are fewer nodes. For network densities up to 100 nodes, CEA-RPL estimates a PRR of up to 98%. On average, the PRR provided by OFO is 89%, MRHOF is 91%, and COM-OF is 94% compared to CEA-RPL, which gives an average PRR of 96%. CEA-RPL performs much better than RPL Objective Functions as OFO and MRHOF do not consider load balancing while forwarding the data, which could cause data loss in the network. Though COM-OF considers load balancing to a certain extent, CEA-RPL outperforms COM-OF as it also considers Multipath routing in data forwarding, thereby maximizing the data delivery in the network.

2) Traffic Load and Packet Receiving Rate

The results of the comparison of the performance of PRR against the traffic load in a network for the above-mentioned Objective Functions is given in Figure 4(b). It is evident that the packet reception rate drops as the network’s traffic load rises. This is due to the fact that an increase in traffic volume causes network congestion, which results in queue overflow at the nodes and subsequently causes data loss. As a result, the packet reception rate decreases. However, with a heavy traffic load of 100pps, CEA-RPL achieves a PRR of 85% when compared to OFO, MRHOF, and COM-OF, with PRRs of 69%, 72%, and 79%, respectively. This is clear since CEA-RPL uses Queue Occupancy metric, Congestion Notification, and Multipath routing to perform Congestion Awareness, Mitigation, and Control while routing. Conversely, OF0, MRHOF, and COM-OF do not take network congestion into account during routing, though COM-OF does control network congestion to some extent using load balancing metrics. Thus, on an average, CEA-RPL achieves almost a 10% increase in the average PRR with 92% compared to OFO, MRHOF, and COM-OF, with average PRRs of 80%, 83%, and 88%, respectively

Figure 4. Comparison of Packet Receiving Rate against Network density and Traffic load

4.2.3. End-to-End Delay

End-to-end delay or latency represents the time needed to transfer a packet from a transmitter to a receiver. It is calculated as the ratio of the difference between the data reception time and the data sending time divided by the number of data packets delivered effectively, as given in Equation (9) [26].

1) Network Density and End-to-End Delay

The average end-to-end delay of the packets with the increase in the network density is shown in Figure 5(a). It is evident that as a network’s nodes grow, the end-to-end delay also grows. This is related to the additional number of hops to route the data as the network grows in terms of the intermediary nodes in the network. Accordingly, OFO performs better than MRHOF as it considers the least number of hops as the metric to route the data. However, the RPL Objective Functions, OF0 and MRHOF, underperform when compared to the other two OFs, as they do not support load balancing or Congestion control, thereby causing packet loss or delay in the network. In terms of network load balancing, COM-OF outperforms RPL Objective Functions. However, because it does not take Congestion control into account, its performance is inferior to that of CEA-RPL. Therefore, CEA-RPL outperforms all the three OFs by reducing the delay by an average of 34% when compared to OF0, 42% when compared to MRHOF, and 18% when
compared to CEA-RPL.

2) Traffic Load and End-to-End Delay

Figure 5(b). shows the impact of increasing traffic load in a network with end-to-end delay. It can be seen that end-to-end delay is directly proportional to the traffic in a network. A network experiences congestion on sudden rise in traffic load, which delays the delivery of packets to their destination. Due to the fact that OF0, MRHOF, and COM-OF do not take network Congestion control into account, an increase in traffic volume causes buffering of packets for an extended period of time in the network, lengthening the delay. As a congestion aware, detecting, and controlling multipath protocol, CEA-RPL may route traffic to the least crowded path to reduce packet queuing. Thus CEA-RPL reduces the end-to-end delay when contrasted with OF0 by 30%, MRHOF by 39%, and COM-OF by 15% on average, during varied traffic loads.

Figure 5. Comparison of End-to-End Delay against Network density and Traffic load

4.2.4. Queue Loss Ratio

Queue loss ratio is the percentage of packets lost due to the overflow of buffer to total packets transmitted, as given in Equation (10).

1) Network Density and Queue Loss Ratio

Figure 6(a). compares the average Queue loss ratio with the network density, given a constant traffic rate. It is observed that the queue loss ratio reduces with the increasing network density. As the traffic rate is constant, more nodes to forward the data in the network reduces buffer occupancy at the nodes, thereby reducing congestion and the queue loss ratio in the network. It is evident that the performance of CEA-RPL is superior to that of OFO, MRHOF, and COM-OF as it considers load balancing and Congestion control in the network, which will alleviate the queue loss in the network. It is noticed that the queue loss ratio of CEA-RPL is 60% less when compared to OF0, 49% less when compared to MRHOF, and 21% less when compared to COMOF.

2) Traffic Load and Queue Loss Ratio

Figure 6(b). shows the rise in traffic load in the network with the Queue loss ratio. Here, the queue loss ratio increases with the increase in traffic load. A surge in traffic volume results in network congestion, which overflows queues at nodes and raises the queue loss ratio. As OFO, MRHOF, and COM-OF do not consider congestion in the network for data forwarding, the queue loss rate is much higher than the CEA-RPL. A comparison of the queue loss ratio of CEA-RPL for varying traffic load shows a decrease of 65%, 59%, and 41% (on an average) in the queue loss ratios when compared to that of OF0, MRHOF, and COM-OF, respectively.

Figure 6. Comparison of Queue Loss Ratio against Network density and Traffic load

4.2.5. Network Lifetime

The period of time before the first node in the network gets exhausted of energy is known as the Network lifetime. As already mentioned before, the energy consumption of the nodes is directly proportional to the network lifetime.

1) Network Density and Network Lifetime

The network lifetime (in mins) is compared with the increasing network density, as shown in Figure 7(a). The lifetime of a network decreases with the growing network density. As the number of nodes expands, there is a corresponding rise in the energy required due to the increased volume of data transfer, both in terms of sending and receiving information between the intermediate nodes. The nodes’ increasing consumption of energy shortens the lifetime of the network. As OFO and MRHOF do not consider load balancing while routing, their energy consumption is really high, and thereby network lifetime is considerably low. Also, COM-OF’s local repair method for broken links in single-path routing wastes more energy than CEA-RPL’s Multipath routing, reducing its network lifetime. Thus, considering load balancing, Congestion control, and Multipath routing in CEA-RPL, we see that CEA-RPL has considerably high network lifetime when compared to the three OFs. The percentage of increase in network lifetime in CEA-RPL is 92% more when compared to OF0, 51% more when compared to MRHOF, and 13% more when compared to COM-OF.

2) Traffic Load and Network Lifetime

Figure 7(b). examines how CEA-RPL performs in relation to the three OFs, OF0, MRHOF, and COM-OF, in regard to network longevity and traffic load. The network’s lifespan shortens as traffic volume rises. This is due to the fact that a network’s lifetime is shortened due to the direct correlation between network traffic and the power consumption of its nodes. CEA-RPL outperforms the three Objective Functions by increasing the network lifetime by 87% when compared to OF0, 36% when compared to MRHOF and 13% when compared to COM-OF Objective Functions. As CEA-RPL evenly distributes traffic throughout the network by taking into account network congestion, Queue Occupancy, and Multipath routing, it operates effectively even under conditions of increasing traffic. By doing this, the network’s lifespan is increased while its power consumption is reduced.

Figure 7. Comparison of Network lifetime against Network density and Traffic load

5. CONCLUSIONS

A multipath Congestion and Energy Aware RPL (CEA-RPL) is presented to alleviate the major issues of load balancing and congestion in RPL for LLNs. The proposed work was simulated on the Contiki Operating System using the Cooja simulator and compared with the existing OF0 and MRHOF RPL Objective Functions along with our previously proposed COM-OF objective function. With respect to the network density, on an average, CEA-RPL reduces the power consumption by 29%, queue loss ratio by 43%, end-to-end delay by 31%, increases the PRR and network lifetime by 5% and 52% respectively, when compared to the OFO, MRHOF, and COMOF Objective Functions. However, with respect to the traffic load, when compared to the OFO, MRHOF, and COM-OF, CEA-RPL raises the PRR by 9%, extends the network lifetime by 45%, and reduces power consumption by 37%, queue loss ratio by 55% and end-to-end delay by 28%. In our upcoming work, we intend to develop Objective Functions considering contextaware routing and cross-layer strategies that also consider network mobility and stability, along with load balancing for specific IoT applications.

CONFLICT OF INTEREST

The authors declare no conflict of interest.

REFERENCES

[1] https://dataprot.net/statistics/iot-statistics/
[2] T. Winter et al., (2012) “RPL: IPv6 Routing Protocol for Low-Power and Lossy Networks”, IETF RFC 6550.
[3] The Internet Engineering Task Force (IETF), 2010. <http:// http://www.ietf.org/>.
[4] Routing Over Low Power and Lossy Networks (ROLL), 2004. <https:// datatracker.ietf.org/wg/roll/charter/>.
[5] O. Gaddour & A. Koubaa, (2012) “RPL in a nutshell: A survey”, Elsevier, Computer Networks, Volume 56, Issue 14, Pages 3163-3178, doi: 10.1016/j.comnet.2012.06.016
[6] Doruk Pancaroglu, Sevil Sen, (2021) “Load balancing for RPL-based Internet of Things: A review”, Ad Hoc Networks, Volume 116, 102491, ISSN 1570-8705, https://doi.org/10.1016/j.adhoc.2021.102491.
[7] B. G. Mamoun Qasem, Ahmed Al-Dubai & Imed Romdhani, (2017) “Load balancing objective function in RPL”, ROLL – WG INTERNET DRAFT, pp. 1–10
[8] C, Lim, (2019) “A Survey on Congestion Control for RPL-Based Wireless Sensor Networks”, Sensors 19, no. 11: 2567. https://doi.org/10.3390/s19112567
[9] P. Thubert, (2012) “Objective function zero for the routing protocol for low-power and lossy networks (RPL)”, RFC 6552.

[10] O. Gnawali & P. Levis, (2012) “The Minimum Rank with Hysteresis Objective Function”, RFC 6719
[11] Ibrahim S. Alsukayti, (2020) “The support of multipath routing in IPv6-based internet of things”, International Journal of Electrical and Computer Engineering (IJECE). 10. 2208. 10.11591/ijece.v10i2.pp2208-2220.
[12] J. Tsai & T. Moors, (2006) “A Review of Multipath Routing Protocols: From Wireless Ad Hoc to Mesh Networks”, 17-18 July
[13] M. Geuzouri, N. Mbarek & A. Temar, (2020) A new way of achieving multipath routing in wireless networks”, International Journal of Wireless and Mobile Computing. 18. 101. 10.1504/IJWMC.2020.10026464.
[14] A. Bhat & V. Geetha, (2017) “Survey on routing protocols for Internet of Things”, 7th International Symposium on Embedded Computing and System Design (ISED), pp. 1-5, doi: 10.1109/ISED.2017.8303949.
[15] O. Iova, F. Theoleyre & T. Noel, (2015) “Exploiting multiple parents in RPL to improve both the network lifetime and its stability”, 2015 IEEE International Conference on Communications (ICC), pp. 610-616, doi: 10.1109/ICC.2015.7248389.
[16] M. A. Lodhi, A. Rehman, M. M. Khan & F. B. Hussain, (2015) “Multiple path RPL for low power lossy networks”, 2015 IEEE Asia Pacific Conference on Wireless and Mobile (APWiMob), pp. 279- 284, doi: 10.1109/APWiMob.2015.7374975.
[17] P. Levis, T. Clausen, J. Hui, O. Gnawali & J. Ko, (2011) “The trickle algorithm”, March 2011, IETF RFC 6206.
[18] Q. Le, T. Ngo-Quynh & T. Magedanz, (2014) “RPL-based multipath Routing Protocols for Internet of Things on Wireless Sensor Networks”, 2014 International Conference on Advanced Technologies for Communications (ATC 2014), pp. 424-429, doi: 10.1109/ATC.2014.7043425.
[19] Radi, Marjan, Behnam Dezfouli, Kamalrulnizam Abu Bakar, & Malrey Lee, (2012) “Multipath Routing in Wireless Sensor Networks: Survey and Research Challenges”, Sensors 12, no. 1: 650685. https://doi.org/10.3390/s120100650
[20] W. Lou, W. Liu & Y. Zhang, (2006) “Performance Optimization Using Multipath Routing in Mobile Ad Hoc and Wireless Sensor Networks”, 10.1007/0-387-29026-5_5.
[21] Z. Wang, L. Zhang, Z. Zheng et al., (2018) “Energy balancing RPL protocol with multipath for wireless sensor networks. Peer-to-Peer Networks”, Appl. 11, 1085–1100, https://doi.org/10.1007/s12083-017-0585-1
[22] Oana Iova, Fabrice Theoleyre & Thomas Noel, (2015) “Using Multiparent Routing in RPL to Increase the Stability and the Lifetime of the Network”, Ad Hoc Networks, Elsevier, 29, 10.1016/j.adhoc.2015.01.020, hal-01206380
[23] M. Lodhi, Abdul Rehman, Meer Khan, M. Asfand-E-yar & F. Hussain, (2017) “Transient multipath routing protocol for low power and lossy networks”, KSII Transactions on Internet and Information Systems,11, 2002-2019, 10.3837/tiis.2017.04.010.
[24] T. L. Jenschke, G. Z. Papadopoulos, R. -A. Koutsiamanis & N. Montavont, (2019) “Alternative Parent Selection for Multi-Path RPL Networks”, 2019 IEEE 5th World Forum on Internet of Things (WF-IoT), pp. 533-538, doi: 10.1109/WF-IoT.2019.8767236.
[25] Tomas Lagos Jenschke, Remous-Aris Koutsiamanis, Georgios Papadopoulos, Nicolas Montavont, (2021) “ODeSe: On-Demand Selection for multipath RPL networks”, Ad Hoc Networks, Elsevier, 114, pp.102431. 10.1016/j.adhoc.2021.102431. hal-03122968v2f
[26] F. Kaviani & M. Soltanaghaei, (2022) “CQARPL: Congestion and QoS-aware RPL for IoT applications under heavy traffic”, The Journal of Supercomputing, 78, 10.1007/s11227-02204488-2. [27] H. -S. Kim, H. Kim, J. Paek & S. Bahk, (2017) “Load Balancing Under Heavy Traffic in RPL Routing Protocol for Low Power and Lossy Networks”, in IEEE Transactions on Mobile Computing, vol. 16, no. 4, pp. 964-979, 1 April 2017, doi: 10.1109/TMC.2016.2585107.
[28] Kala Venugopal & T. G. Basavaraju, (2022) “A Combined Metric Objective Function for RPL Load Balancing in Internet of Things”, International Journal of Internet of Things, Vol. 10 No. 1, 2022, pp. 22-31. doi: 10.5923/j.ijit.20221001.02. [29] S. Wakatsuki, N. Komuro, H. Sekiya & S. Sakata, (2014) “Prolonging network lifetime for 6LoWPAN / RPL wireless sensor network using mobile sink with dynamic sojourn time”, 2014
[30] M. Aboubakar, M. Kellil, A. Bouabdallah & P. Roux, (2019) “Toward intelligent reconfiguration of RPL networks using supervised learning”, 2019 Wireless Days (WD), Manchester, United Kingdom, pp. 1-4, 2019, DOI: 10.1109/WD.2019.8734236.

[31] Mah Zaib Jamil, Danista Khan, Adeel Saleem, Kashif Mehmood & Atif Iqbal, (2019) “Comparative performance analysis of RPL for low power and lossy networks based on different objective functions”, International Journal of Advanced Computer Science and Applications, Vol. 10, No. 5, DOI: 10.14569/IJACSA.2019.0100524
[32] Contiki O.S and Cooja simulator, http://www.contiki-os.org/
[33] T. Zahariadis & P. Trakadas, (2022) “Design guidelines for routing metrics composition in LLN”, ROLL Internet Draft, 2022
[34] Nesrine Khernane, Jean Couchot & Ahmed Mostefaoui, (2018) “Maximum network lifetime with optimal power/rate and routing trade-off for wireless multimedia sensor networks”, Computer Communications, Elsevier, 124, pp.1 – 16, hal-02182832
[35] Moteiv Corporation. Tmote sky: Datasheet (2006): https://insense.cs.standrews.ac.uk/files/2013/04/tmote-sky-datasheet.pdf, Nov 13, 2006
[36] H.A.A. Al-Kashoash, H. Kharrufa, Y. Al-Nidawi. et al., (2019) “Congestion control in wireless sensor and LoWPAN Networks: toward the Internet of Things”, Wireless Netw 25, 4493-4522, https://doi.org/10.1007/s11276-018-1743-y

AUTHORS

Kala Venugopal is a Research Scholar, pursuing her PhD under the Visvesvaraya Technological University (VTU) at Government Engineering College, Hassan, India. Kala Venugopal works as an Assistant Professor in the Department of Information Science and Engineering, Acharya Institute of Technology, Bengaluru, since 2005 and received her Bachelor of Engineering and MTech degrees from VTU. Her research interests include Internet of Things (IoT), Wireless Ad hoc Networks and Information Management Systems.

Dr. T G Basavaraju is currently working as Professor and Head of Computer Science and Engineering Department at Government Engineering College, Hassan. Prof. Basavaraju holds a Ph.D. (Engg.) from Jadavpur University, Kolkata in Mobile Ad hoc Networks. He obtained his master’s degree in Computer Science and Engineering from University Visvesvaraya College of Engineering (UVCE), Bangalore University, Bangalore and secured first place. He holds a bachelor’s degree in Computer Science and Engineering from University BDT College of Engineering (UBDTCE), Kuvempu University, Davangere. He has more than 25 years of experience in Teaching and Industry. He has authored and co-authored five text books in the area of Computer Networking. His major areas of research include Wireless Ad hoc, Sensor and Mesh Networks, Internet of Things (IoT) and Cloud Computing. His name was listed in Marquis Who’s Who in the World, America in the year 2010. uLektz Wall of Fame listed him as “Top Most Promising Educators in Higher Education Across India” in the year 2019. He has been selected as MARGADARSHAK from AICTE to mentor Engineering Institutions for Accreditation