Multi-Topology Based QoS-Differentiation in RPL for Internet of Things Applications

The rapid development of the Internet of Things (IoT) concept has promoted the presence of routing protocol for low power and lossy network (RPL). Unlike traditional applications, many applications envisioned for IoT networks may have different and sometimes conflicting requirements. In this context, the underlying routing protocol requires to provide quality of service (QoS) for multipurpose IoT and is inevitable. However, the routing approach in RPL is not efficient because default objective functions (OFs) rely on a single metric, which can result in a tradeoff in routing performance, particularly for multipurpose IoT that enchant different QoS requirements in the same network. Although RPL specification allows the use of multiple metrics for parent selection, however, no specific guideline is defined for metric combinations. Besides, many studies have revealed that RPL encounters severe problems in large scale networks as it was mainly designed for low data traffic network. To address these problems, in this paper, we primarily focus on QoS differentiation by exploiting the multi-topology routing feature of the RPL standard. For this, we propose different OFs, which ensures the QoS differentiation at the network level by splitting the physical network virtually into multiple RPL Instances. Each Instance can incorporate different traffic by associating with differing OFs, and routed it through the corresponding virtual network topology. We also present a new parent selection framework based on a multi-attribute decision-making approach that addresses the single routing metric problem in RPL. The extensive simulation results verify that our multi-topology routing approach can support the QoS provisioning and is suitable for large scale networks as compared with standard RPL.

Internet because of the lack of IP-based network architecture, which limits their real impact [6]. To address this need, the concept for the constrained network has been standardized and commonly known as the IPv6 over low-power wireless personal area networks (6LoWPAN) [7].
Low power and lossy networks (LLNs) has been a key enabler in the IoT ecosystem. One of the prime concerns of LLNs is how to build and maintain network topology to make efficient use of limited network resources. Therefore, the characteristics of LLN render new challenges to develop efficient routing solutions for resource-constrained networks. To overcome these challenges, routing over low power and lossy networks (RoLL), a working group of IETF, has designed a routing protocol specification for the resourceconstrained network, namely IPv6 routing protocol for low power and lossy networks (RPL) [8]. It provides mechanisms to support various traffic patterns in LLN applications and provide Internet connectivity through different links such as IEEE 802. 15.4, and bring the concept of IoT into real life by addressing the LLN requirements for 6LoWPAN networks.  In LLN, different applications have their different routing requirements, as a representative application, the RoLL working group defined the unique routing requirement, for urban application in [9], industrial application in [10], home automation in [11], and building automation in [12]. Since the LLN characteristics impose unique routing requirements, the RoLL concluded that existing routing solutions could not meet these specific requirements, so RPL came into existence to fulfill the specific routing requirements of various types of LLN applications. RPL is a proactive distance-vector routing protocol that can build a directed acyclic graph (DAG) based on defined routing metrics. RPL organizes the routing topology as one or more destination oriented directed acyclic graphs (DODAG), each rooted at one or more single point typically known as LLN border router (LBR) or DODAG root. The DODAG root acts as a transit point to connect the LLN with the outside world (mostly, IPv6 network or Internet). Any node that cannot directly communicate with the LBR can use other nodes as parent nodes to send its data toward the LBR in a hop-by-hop manner. Therefore, in the RPL-based network, the parent selection process plays a critical role in forwarding data from a source node to the LBR of IoT architecture [13].
RPL allows users to describe routing strategies according to the application requirements. This feature fulfills the conflicting requirements of various IoT applications through the objective function (OF) because, in RPL, the OF concept is separated from the core operation such as packet processing and forwarding [8]. The OF provides the optimization criteria to address the application-specific goal, such as minimizing the delay, maximizing the reliability, etc. As described in [14], the set of link and node routing metrics can be adopted during the routing path construction phase. Therefore, the OF may use these metrics to build the DAGs with different objectives, for instance, constructing a DAG to maximize reliability by using the link reliability metric to compute the best route.
Technically, the OF can be used for two purposes; firstly, it defines how the rank of a node is computed, secondly, how a node selects the preferred parent based on single or multiple routing metrics. However, default OFs in RPL rely on a single metric, which can result in a tradeoff in routing performance, particularly for the IoT applications that enchant different quality of service (QoS) requirements in the same network [15]. Besides, these OFs are mainly designed for networks with low data traffic, therefore, it encounters severe problems in large scale networks [16]. Although RPL specification allows the use of multiple metrics for parent selection, however, no specific guideline is defined for a metric combination [17].
The RPL is considered suitable in the IoT ecosystem to deal with different application requirements and varied network characteristics because of its loop detection, self-configuration, self-healing, dual-mode of operation, and multi-topology routing features. Recent studies on RPL optimization focuses on load balancing, energy efficiency, congestion alleviation, security, etc. by leveraging different RPL features, but QoS provision has ignored mostly. Also, many studies have revealed that RPL encounters severe problems in large scale networks as it was mainly designed for low data traffic network. Even though many existing approaches define OF and routing metrics composition to deal with various issues in single network topology, the extent to which their use for QoS provision in multipurpose large scale networks is unknown. Furthermore, some RPL implementations either use a single metric or combine multiple routing metrics regardless of the metric's cost and benefit criteria. In essence, such approaches in large scale networks may lead to several problems, such as network instability (i.e., consecutive parent change), low throughput, network imbalance, etc., thereby VOLUME 8, 2020 multipurpose IoT networks cannot work seamlessly and that impact on QoS support. Therefore, for multipurpose IoT networks where applications generate different types of traffic with different QoS requirements, the routing strategy in RPL should consider QoS differentiation. In this context, our approach not only considers the cost and benefit criteria of routing metrics but also takes advantage of the multi-topology routing feature of RPL to address the current limitations and QoS requirements of IoT applications.
Based on this backdrop, in this paper, we mainly focus on QoS differentiation by exploiting the multi-topology routing feature of RPL specification. For this, we present different OFs that satisfy the requirements of IoT applications having different types of data traffic. As routing topology is built based on these OFs, it can incorporate different traffic through association with differing OFs. In this way, each traffic class will associate with a different OF and is routed with a particular DODAG structure. We also present a new parent selection framework based on a multi-attribute decision-making approach that addresses the limitations of a single routing metric in RPL implementation. Unlike other RPL implementations, in our approach, the rank calculation and the preferred parent selection is detached.
The remainder of the paper structure is as follows. Section II presents a brief description of the multi-topology routing in RPL and motivation. Section III discusses the most recent related works. In section IV, we describe the problems and our contributions. Then, in section V, we present the QoS differentiation approach. Section VI presents our parent selection framework. After that, in section VII, we evaluate the proposed approach in different aspects and compare the results. Finally, section VIII draws the concluding remarks.

II. OVERVIEW OF MULTI-TOPOLOGY ROUTING IN RPL A. MULTI-TOPOLOGY OPERATION
RPL does not support predefined topology structure but builds based on the concept of a DAG. Each node in a DAG connects in a way that a tree-shaped structure is formed where no cycles present. Unlike a traditional tree structure, DAG uses a tree structure where each node is allowed to have more than one parent node. In particular, RPL organizes these nodes in the form of DODAGs, and these DODAGs are created based on the OF. As multiple DODAGs can operate in a network, so they are arranged into groups known as RPLInstance. Several RPLInstances can be in a network, and they are identified by RPLInstanceID. DODAGID is used to identify each DODAG in an RPLInstance. To validate the integrity of DODAG, DODAGVersionNumber is used. RPL uses the Internet control message protocol version 6 (ICMPv6) message to exchange these parameters. In RPL, a node may join multiple DODAGs only if these DODAGs belong to different RPLInstances. Nodes participating in a DODAG are specified by a combination of unique addresses, such as DODAGID and RPLInstanceID. DODAGID is unique within an RPLInstance, and RPLInstanceID is unique within the scale of the network.
As described in [8], the RPL Instance is a function of one or multiple DODAGs that provides a specific objective derived by an OF. This concept enables RPL to build and categorize multiple DODAGs in the same physical topology. In this manner, RPL allows running multiple RPLInstances simultaneously in a network. Fig. 2 shows the DAG routing structure over a physical network using different OFs that are designed to fulfill different QoS requirements of IoT applications and adheres to the feature of RPL of concurrent operation of multiple RPLInstances and multiple DODAGs.

B. ROUTING MECHANISM
The DODAG root node (sink node) is liable to construct and maintain the network topology, and it provides the default routing towards the Internet. The DODAG construction is controlled by three different types of ICMPv6 control messages that are, DODAG information solicitation (DIS), DODAG information object (DIO), and destination advertisement object (DAO). Root node starts broadcasting a DIO message to construct a new DODAG. The DIO message contains various network information, including DODAGID, RPLInstanceID, DODAGVersionNumber, and Rank. Nodes that reside within a communication range receive the DIO message and decide according to their OF whether to join the network or not. When a node decides to join the network, it adds the DIO sender as a parent to its routing table. The node computes its Rank within the DAG. If a node is configured as an intermediate node (router), it starts broadcasting the DIO message containing updated network information to neighboring nodes. Otherwise, if configured as a leaf node, it only joins in the DAG and does not send a DIO message. In case, if a node does not receive a DIO message within the stated time, it first requests a DIO message from the neighbor nodes by sending a DIS message. Upon receiving a DIO message, the node responds with a DAO message. Each node repeats this procedure and continues until all the nodes participate in DAG to construct a tree-shaped topology and building parent sets. As a result, each node obtains multiple parents, from which it selects one as the preferred parent that is the next-hop on the path toward the DODAG root. In this way, each node of the network has routing records towards the DODAG root, through which nodes can transmit its data packets either directly or in a hop-by-hop manner. To verify if a node has stale routing information, the Trickle algorithm in RPL implements a consistency check model. In addition, it is used to govern the frequency of DIO transmission. The interested reader can find an in-depth explanation of the Trickle algorithm in [18].

C. MOTIVATION
In a real-world IoT infrastructure, many applications need to support multiple tasks such as collection, control, and 96688 VOLUME 8, 2020 FIGURE 2. Example of multi-topology routing. The virtual structure of the RPL network topologies built with two different RPL Instances and DODAG roots based on different optimization criteria of the specific objective function. The red color shows the DODAG formation with the ETX metric, which focused on delivering data with high reliability, whereas green color DODAG constructs with delay metric aiming to forward data with lower delay. monitoring within the same network. Considering that most of the IoT applications have varied nature and diverse requirements, the underlying routing operations for LLNs needs to be optimized to support different traffic scenarios [19] and application requirements [20]. Additionally, because of the varied nature of these applications, the data generated may include different types of traffic (regular, critical), which may have different QoS requirements such as latency, reliability, and energy efficiency [21], [22]. Therefore, in a network having multiple traffic types, different paths should be built to support different classes of traffic according to their QoS requirements, such as reliabilitysensitive routing and delay-sensitive routing. In this case, different DODAGs need to build within the same network in a way that optimizes for corresponding QoS requirements. For this motive, we adopt the concept of multi-topology routing, in which nodes can get the opportunity to perform in multiple DODAGs to support particular QoS requirements of the applications.
On the other hand, the OFs used to select the parent node (forwarding node) in the RPL may suffer from long hops problem when the network becomes heavy or the number of nodes increases [23]. This is due to the construction of the routing paths that mainly rely on a single metric such as hop count [24] or expected transmission count (ETX) [25]. Also, the parent selection scheme in RPL may result in a flocking effect, which refers to the incidence of attracting nodes and switching from one to other parents consecutively. As a result, this flocking phenomenon will significantly impact on QoS provisioning that ultimately limits the IoT application services offered to the users through the tree-based network structure. The fact that the RPL parent selection scheme is not likely to fit in large scale IoT networks due to lack of metric composition so motivates a new parent selection technique.

III. RELATED WORKS
The main objective of RPL is to support networks comprise of many resource-constrained devices, where the connection between devices is through low-cost wireless communication technologies. In recent years, there are many studies carried out on different aspects of RPL enhancements, such as load balancing, mobility, security, and congestion control [26], [27], [28]. However, QoS provisioning in RPL operation is still a widely unexplored research field. While RPL uses OF and routing metrics to build and maintain network topology, it is noting that the RPL specification does not mention specific OF and routing metrics for a particular application. Therefore, RPL separates it from core operations so that users can formulate routing strategies to achieve various application goals. Moreover, RPL specification allows the use of multiple routing metrics in the OF. As a result, the manipulation of the RPL OFs and its parameters is possible. This flexibility renders the implementer to be more resilient over choosing and combining different routing metrics. However, the specification in [14] has not explained how to select and combine different sets of routing metrics.
In this regard, some studies [29], [30] present the design and evaluation of primary and composite routing metrics implementing in the RPL based network for satisfying the routing requirements of different applications. The network performance depends on the underlying routing protocols and the metrics used to determine the routes, so this prompts the researcher to study and design of various routing metrics for achieving the specific QoS aspects of the applications. For instance, to reduce routing overhead and improve overall network performance, Jevtic and Malnar [31] have presented different versions of ETX-based routing metrics such as light ETX (L-ETX), light reverse ETX (LR-ETX) and power light reverse ETX (PLR-ETX), particularly for dynamic wireless ad hoc networks. VOLUME 8, 2020 On the other hand, most protocols use hop number count, node residual energy, link quality indication (LQI) as a default routing metric [32]. Some other implementations of RPL in [33], [34] presents several routing metrics to cope with the unique feature of low power and lossy networks, such as hopcount, queue length, end-to-end delay, residual energy ratio, ETX, queue utilization, and residual energy, each of which is targeting at link conditions or specific node behaviors. However, alone these routing metrics often do not satisfy the diverse requirements of the multipurpose IoT networks.
As described in [35], the proper combination of multiple routing metrics is of utmost importance to satisfy the various routing requirements for a single network. There are several mechanisms adopted to effectively combine different types of node and link routing metrics, all of which have advantages and disadvantages. Among them, the most widely adopted combining technique is additive [35], [36], [37] and lexicographic [38], [39]; or sometimes also in hybrid manner (both additive and lexical) [40]. In addition, some other mechanisms have been pursued, such as Fuzzy Logic in [41], Genetic Algorithm in [33], and Game Theory in [42]. Fig. 3 categorizes the works that are focused on using different types of routing metrics and their combinations.
As it is known, the OF in RPL constructs and evaluates the path based on the specific routing metric and constraints. The existing OFs enhancements differ in such a manner as to how they utilize the routing metrics. So, based on the needs of the applications and network scenarios, the network designer can decide which metrics to select and how to combine them into OFs. As a result, defining OFs in different aspects of RPL-based networks is a topic of intense study. Concerning this, Lamaazi and Benamar [43] have presented a comprehensive survey on the enhancements and assessment of the RPL objective functions. The authors also categorize the composite metrics according to the techniques adopted. Furthermore, statistical analysis of the proposed OFs has been presented. Besides, as RPL does not mandate the use of a specific OF or routing metric, several studies have proposed alternative objective functions for RPL that take into account various routing metrics.
In [50], Gozuacik et al. have proposed a new parent-aware objective function (PAOF) intended to address the network load balancing problem in LLNs. It combines a new routing metric, called parent count, with ETX to perform the rank calculation and optimal parent selection. The parent count metric is the number of potential best parents of the nodes in a network. PAOF combines both metrics in a lexical manner. While choosing the preferred parent, the default decision is based on the ETX metric, PAOF uses the second metric only if there is a noteworthy difference in the ETX values of the candidate parent nodes.
Another study in [51], a novel energy-aware objective function (OF-EC), which combines three different node and link routing metrics using fuzzy logic, has been proposed by Lamaazi and Benamar. Also, the authors highlight the limitations of using a single metric. OF-EC aims to improve overall network performance, and it keeps the RPL efficiency independent of network structure and transmission range. A similar approach is presented in [52], where the authors have defined a novel OF using a multi-fuzzy logic system (ML-FL). The ML-FL system includes three different classes of metrics that is link-oriented metrics, node-oriented metrics, and channel-oriented metrics. ML-FL selects the preferred parent by considering several individual metrics of these categories. Furthermore, the authors have proposed a new multicast forwarding algorithm, known as enhanced bidirectional multicast RPL forwarding (EBMRF), aiming to reduce the delay and suppress the duplicate packets. Mostly, these duplicate packets caused by the forwarding of packets to multiple parents. Another fuzzy-based approach has been applied in [47] to support different application requirements. In addition, the authors pointed out that only one, or a simple combination of metrics might be inefficient to satisfy the diverse application requirements.
Recently, several efforts have been made to optimize the RPL operation in various aspects. For instance, Singh and Chen in [53] have focused on the RPL enhancement for a parent selection procedure. The new parent selection mechanism is mainly to balance the load so as avoiding the occurrence of congestion by preventing the selection of a congested node as a parent from child nodes. To do so, the authors proposed a new objective function, named OF-ER based on the composite efficient routing (CER) metric. This composite metric considers several node and link metrics to select the optimum parent. Another parent selection approach has been used in [54] in order to provide a better congestion mechanism. The problem of the selection of parents within congestion is modeled as a decision-making problem, and the authors apply the GRA technique to resolve it. The proposed congestion control scheme utilizes both resource and traffic control approaches to alleviate congestion as needed. In the resource control approach, each node attempts to find a noncongested path; therefore, the node uses the GRA method to calculate the rank by combining multiple routing metrics and forms the candidate parent set. Among them, the node with the best rank is selected as a preferred parent. In terms of the decision-making problem and metric combination, this parent selection approach is close to our proposal. However, some design choices of RPL is distinct in our approach. The main difference is in the rank calculation, as we use GRA simply to select the preferred parent. Besides, in our implementation, we utilize both the cost and benefit attributes, whereas [54] only uses cost attributes. The metrics considered in these two GRA systems are not the same. The ETX metric is common in both systems, but we compute it by using the EWMA filter so as reduce the measurement error.
Similarly, to support the bidirectional data delivery, the authors in [55] proposed an improved version of the RPL, called DT-RPL. In DT-RPL, the wireless link quality is updated rapidly by both downward and upward traffic, so as it supports diverse traffic patterns. Additionally, Tahir et al. [56] have proposed an RPL extension called backpressure RPL to encounter the issues of network dynamicity and node mobility. Depending on the network environments, this backward-compatible RPL adaptively switches between RPL and backpressure routing, which enhances mobility support.
Subsequently, the authors in [57] presented a new version of RPL to cope up with heavy and dynamic traffic load that overcomes the problem of packet loss and energy depletion. To this end, the new context-aware and load-balancing RPL obtains a load and power balanced route through a contextaware routing metric (CARF), which includes the remaining energy and queue utilization of parent chain to DODAG root in a recursive way. In order to support point-to-point (P2P) communication efficiently, in [58], Zhao et al. have presented an energy-efficient region-based RPL (ER-RPL), which finds the energy-efficient route without compromising the reliability. Moreover, only a subset of nodes is required to discover the P2P route in ER-RPL. Then, in [59], the authors proposed a new routing protocol support a cognitive radio enabled advanced metering infrastructure network and is termed as cognitive and opportunistic RPL. In [60], Ko et al. have proposed DualMOP-RPL, an enhanced version of RPL, which supports both (storing and non-storing) mode of operations of RPL for downward routing to enable robust bidirectional data delivery in a single RPL network. Likewise, the authors have presented an enhanced version of RPL for congestion-aware, load balancing, RPL security attacks, and energy balancing in [26], [61]- [63], respectively. Nevertheless, these enhancements do not include QoS provisioning using the multi-topology feature of the RPL specification.
It is also feasible to implement more than one objective function in the RPL scope. With regard to this, the authors in [64] have proposed four different types of context-aware OFs for RPL. These OFs are substituted to construct the routing path according to the application requirements. The OFs are chosen dynamically based on the context information from the application needs, such as energy usage, reliability, delay, and QoS. Different four versions of delivery quality and context-aware (DQCA-OF) objective functions select the preferred parent based on the fusion of three different routing metrics that is ETX, the number of hops, and energy consumed (EC). Also, DQCA-OF uses the fuzzy logic model to combine these routing metrics. Applying several OFs in a single RPL Instance may not be a reasonable approach for a multipurpose network, particularly when applications have different and sometimes antagonistic requirements [13], [17]. Farooq et al. [65] proposes multiple OFs and analyze their impact on RPL network performance in situations where nodes have to select one between different DODAG roots. However, the proposed OF includes various routing metrics such as available bandwidth, buffer occupancy, hop count, delay, and ETX, but the initial decision on route selection is based merely on the shortest hop count metric. Meanwhile, other metrics are used as tie-breaking metrics when there are multiple paths towards the root in terms of equal hopcounts. Additionally, the default route selection scheme is similar to the RPL OF0 [24], which is not suitable for multipurpose large-scaled IoT networks. In essence, the proposed parent selection technique sometimes may disrupt the diverse requirements of the IoT use cases.
In [66], Rajalingham et al. have proposed the idea of QoS provision through multiple Instances in RPL. To support QoS requirements, it constructs two different Instances, one for reliability that based on ETX, whereas another for the minimum delay and uses the hop count as a metric. However, the RPL Instance implementation is in a IEEE 802.11b based network, which may not perform the same for IEEE 802.15.4 based networks, because the characteristics of IEEE 802.15.4 is different as compared to IEEE 802.11b. In [67], Long et al. puts forward a QoS-aware cross-layer mechanism to support priority traffic by exploiting a multi-Instance feature of RPL and assumes two types of nodes (regular and VOLUME 8, 2020 alarm) in the network to construct two different Instances. For both regular and alarm traffic flows, two topologies are built based on specific node types using one objective function for both two RPL Instances. However, this might not always be a valid assumption in a multipurpose IoT system. Besides, using a single OF for different scopes may only work in networks where nodes are deployed for a particular purpose, which is not always rational. In the RPL scope, Mayzaud et al. in [68], uses the multi-topology feature for monitoring against the security attacks in the network. Even though security in RPL is essential, it is not within the scope of this work. In essence, multiple OFs can be used within the same network by establishing various routing topologies virtually. Therefore, to address the QoS requirements of many applications, in this paper, we take into account the multi-topology routing mechanism of RPL that supports QoS differentiation through each RPL Instances.

IV. PROBLEM DESCRIPTION AND CONTRIBUTIONS A. PROBLEM DESCRIPTION
Currently, several studies have shown that using multiple routing metrics together can significantly improve the performance of RPL networks. Principally, to optimize the network or to select the best parent toward the destination, RPL uses the routing metric in OF [8]. Based on the routing metric used, each node calculates its rank, and according to the rank policy, the node obtains a candidate parent set, from which the node selects the best parent based on certain criteria. However, the default OFs in RPL select the best parent differently, yet both use a single routing metric. In low data traffic or small networks, this approach can satisfy the network performances to some extent but may degrade in large scale networks such as IoT, where applications have diverse and sometimes conflicting requirements. These circumstances allow concluding that a single metric approach cannot handle data traffic properly, especially when the network traffic is heavy [26]. As a result, multipurpose IoT networks confront several problems, such as high packet loss rate, low throughput, delay, and energy depletion, which in the end affects the QoS requirements of the applications. The single metric based routing problem is as follows: 1) The network topology construction is done based on the rank policy. Default OFs uses the same metric for both rank computation and preferred parent selection (next hop to the DODAG root) [24], [25]. According to [8], based on the smaller rank value, each node selects their preferred parent from the candidate parent set. This parent selection process may lead to the flocking effect phenomena, which abruptly attracts the nodes and affect the network balance. To better understand this problem, consider the topology shown in fig 4.
In this topology, nodes d and c are candidate parents of several nodes and holds a rank value of 4 and 5, respectively. The blue circle shows the joint coverage area of the nodes. As the candidate parent, node d holds a lower rank than node e, as per rule, all the corresponding nodes in their vicinity will select d as their preferred parent because it broadcast the smallest path cost. After a while, when the candidate parent e broadcasts lower rank than node d and all the nodes residing in coverage area satisfies the rank policy, then all the corresponding nodes switch their preferred parent to node e. Afterwards, if a new node joins the network and broadcasts the better rank, then nodes will again switch their preferred parent. This situation creates the flocking phenomena of repeating parent switching from one to the other rapidly. Flocking effect results in frequent parent change and thus lead to network instability, mostly in large scale IoT networks. As a result, network cannot work seamlessly, and even it will significantly impact QoS requirements. Another challenge of RPL implementation in multipurpose networks is the metric combination. Since RPL specification does not provide any mechanisms for combining different routing metrics, so merging multiple routing metrics to set diverse QoS goals in large scale heterogeneous IoT networks has yet to be sufficiently addressed. Although some studies in this domain have suggested different mechanisms, yet some drawbacks exist that need to improve. We summarize these limitations as follows: 1) Two or more routing metrics such as residual energy, hop count, delay, and ETX are merged to select the preferred parent (next hop toward the destination). Based on some criteria and application requirements, all of these metrics can have a significant influence on the routing decision. However, some existing metric composition has purely added multiple routing metrics regardless of the metric's benefit and cost criteria. For instance, the metrics hop-count and delay can be considered as cost criteria because their lower value is the better option, whereas residual energy is benefit criteria as its higher value is the better option. Therefore, without considering these properties, the optimum parent that satisfies QoS requirements is hard to choose, and it might impact on the network performance. With this in mind, to satisfy the diverse requirements of the applications in multi-purpose IoT networks, these attributes of metrics should consider correctly. 2) In metrics composition, normalization plays an important role, particularly in additive technique, but most of the existing approaches have neglected it. When units or scale varies for different routing metrics, for example, some metric is measured in joule, while others in seconds, the influence of some metrics on the routing decision may dominate others. Therefore, normalization should be considered, through which each metric can have the same unit scale. 3) Instead of the distribution theory, the weighting factor of metrics is determined based on the personal experience of experts. According to the network situation, such approaches cannot adjust the corresponding weights of the routing metrics on time. As a result, the QoS of the network is affected by comparatively. Therefore, the weights of routing metrics should determine adaptively.

B. CONTRIBUTIONS
With the abovementioned motivations, in this paper, we aim to put forward an enhancement of RPL operations for large scale IoT networks. The main contributions of this work are summarized as follows: 1) We propose different RPL compliant OFs, aiming to enable the QoS differentiation at the network layer by splitting the physical network virtually into multiple RPLInstances of the DODAG network topology. This multi-topology routing can transmit each traffic class through a particular DODAG network graph according to the associated objective function. 2) We present a new framework for solving the problem of optimum parent selection in multipurpose large IoT networks. More precisely, we address a single routing metric problem in RPL by adopting a grey relational analysis (GRA) procedure [69] of the multi-attribute decision-making technique, which makes use of the several routing metrics together. Besides, this process considers cost and benefit criteria depending on the characteristics of each routing metric. 3) To address the weighting issue in metrics combination, we determine the weights of the metrics based on the standard deviation. In this manner, the finest weighting factors can be obtained to select the best parent from the candidate parents.

4) We analyze how different objective functions supports
QoS differentiation for multiple traffic classes over the same physical network.

V. DESIGN OF QoS DIFFERENTIATION IN RPL
In this section, we first provide an overview of our system model and some assumptions regarding the design of QoS differentiation in RPL. After that, we describe the objective function and QoS classification, and topology construction, and routing. The node x maintains its neighbor table (Nb_tab) and always adds new node y ∈ Nb(x), only when x has an empty neighbor table or have enough space to store. In this way, |Nb(x)| is the number of neighbors of x. Further, each node x ∈ N creates a candidate parent set P(x) from its Nb(x), from which a node will select its preferred parent. This entire process is carried out based on the rank of every single node in the network. The rank is a scalar value that represents the node's abstract distance from the DODAG root in the topology. The use of rank allows the node to decide its candidate parents based on the monotonicity property of the rank computation. Node x can select its candidate parent p x from Nb(x) when the following conditions satisfied.
where R is the rank of a node. Considering that P(x) is a subset of ∀x i ∈ N , therefore, it is P(x i ) ⊂ N , which can be seen as: In the network, the node that does not have any candidate parents is S x ∈ S, which can be seen as: Topologically, RPL allows splitting the physical network into several topologies through RPL Instances, in which every Instance builds a logical topology containing one or more DODAGs. Each virtual topology can simultaneously perform different routing objectives within the same physical network. Suppose Z is a set of all available DAGs in the network, and VOLUME 8, 2020 therefore S z signifies the set of all DODAG root for each DAG z ∈ Z . In view of that, for ∀z ∈ Z , in the network, the set of all DODAG root can be determined as followed.
Moreover, we assume that all nodes x ∈ N are stationary, have the same communication range, and consume equal energy to transfer one bit of data. These nodes are uniquely identified by a Node_ID, for instance, an IPv6 address of the node. Further, at any time, each IoT device is supposed to be aware of their available energy level, link performance between neighbors, in terms of link quality and delay, and remaining buffer space. In addition, we undertake that there exists an IPv6's neighbor discovery protocol.

B. QoS CLASSIFICATION AND OBJECTIVE FUNCTION DESIGN
In RPL, constructing the network topology is based on OF that aims to optimize specific routing objectives, such as minimizing delay and maximizing reliability. Within an RPL Instance, all DODAGs share the same OF. Therefore, we define three different OFs for multi-topology routing with which a particular traffic type will be correlated to satisfy the QoS differentiation through different RPL network Instances. As a result, routing over different DODAG structure allows for traffic differentiation at the network layer.
In this paper, we consider three types of traffic, such as noncritical, critical, and regular traffic, to deal with the different data traffic that may be present in various IoT applications. Moreover, in our proposition, three different classes of QoS requirements are identified, which are reliability, latency, and energy consumption. Thus, different OF will be defined for each of these traffics to construct the logical DODAGs for ensuring required QoS. To exploit the QoS differentiation, the objective function selected by each of these traffic classes must be correlated with the specified application objective. Given these classes of QoS requirements, the OFs enable the nodes to construct the network topology and select the best route (preferred parent) based on the combination of respective metrics. The traffic classification for different RPLInstances with specific QoS requirements is defined as follows: • Non-critical traffic: it is also known as reliabilitysensitive traffic. These packets require high reliability, which must be delivered without loss or with a minimal loss. However, non-critical packets may admit a reasonable delay. As a representative example, a device firmware update may come under this category.
• Critical traffic: it is defined as high importance data traffic. It requires both a short delay and high reliability.
As an example, emergency alerts for safety come under this class.
• Regular traffic: it is regular monitoring traffic that does not have any stringent QoS requirements, such as delay and reliability. Nevertheless, energy consumption becomes vital, as regular data transmission is typically required. Considering this classification and the QoS requirements, different routing metrics need to include in the specific OF for the correlation between OFs and traffic classes. In this approach, we propose routing metrics as representatives of delay, reliability, and energy, which are as follows.
We consider the ETX metric as a representative of the reliability-based routing metrics. It is the expected number of transmissions a node required to successfully deliver a data packet to a destination through the wireless link. As described in [70], in a wireless multi-hop network, this metric obtains the high-throughput path toward the root. Suppose e(x, y) is a ETX metric that characterizing l x,y in a route r connecting node x s to node y d . Therefore, r(x s , y d ) = {x s , x s+1, x s+2, . . . , x s+n , y d } is expressed as a set of nodes belonging to the route r. The metric e is an additive metric if it adds ETX of each link e(l(x s , y d )) in the route r as follows.
e(x s , y d ) = e(x s , x s+1 ) + e(x s+1 , x s+2 ) + . . . + e(x s+n , y d ) As the value of metric e decreases, link quality increases, therefore the ETX value close to one provides the finest quality communication link. Thus, using the best e metric can help to find the best route, which comprises relatively high-quality links. In our implementation, ETX is calculated every second and uses an exponentially weighted moving averages (EWMA) filter to reduce the measurement variance. This technique makes ETX robust against sudden changes in the link state. At each node, the ETX is measured as follows. e xy (t) = β × e xy (t − 1) + (1 − β) × e xy (t) (6) where e xy (t), e xy (t − 1) and e xy (t) are new average ETX, old average ETX, and recent measured ETX, respectively, and β is the smoothing rate such that 0 < β < 1, and t is a unit time. Based on ContikiRPL, we have set β = 0.9 for the greater smoothing effect. As a representative of delay-based metric, we consider delay metric. The delay metric is important because the amount of time spent by the data packet in the queue affects the packet delivery rate. We obtain the delay d, based on the method as described in [71]. The delay in a queue of a node depends on the incoming and outgoing traffic rate through a node x at unit time t. Thus, the delay d of a packet at time t is expressed as follows.
where, T in (t) is the input traffic and T out (t) is the transmitted traffic at time t. The input traffic in a unit time interval can be define as follows.
where λ(m) is the instantaneous packet arrival rate at time t, and κ(m) is the instantaneous packet drop rate at time t.
Similarly, the transmitted traffic in a unit time interval can be define as follows. (9) where ξ (m) is the instantaneous packet service rate at time t.
In this manner, to obtain the total delay, the delay of each packet can be accumulated per unit time. In our proposition, we use the time unit of one second.
Further, we consider the queue utilization (QU) metric for representing both reliability and delay characteristics. As described in [26], ETX alone is not able to reflect that packet loss occurs, in particular when the network traffic is heavy, because the queue size in resource-constrained IoT devices is small and starts to overflow before link loss. In addition to this, as described in [65], selecting a parent node using the delay metric may lead to a congestion situation due to heavy traffic. It is because that in RPL based LLN network, senders and receivers are not synchronized, which in turn consume time when d at a node is relatively higher. So, to overcome such situations, we take into account the QU metric, so that providing reliable service. Therefore, we define QU as a queue occupancy ratio of a node x, and it is measured as follows.
where NPq(x) is the total number of packets waiting to be transmitted in x's queue, and QSz(x) is the total queue size of x. In our proposition, to adopt the lossy network conditions, we calculate QU every second by applying the EWMA filter. In the rest of the paper, we use q as the notation for queue utilization of a node.
In addition, we use the remaining energy (RE) metric as a representative of network lifetime. Therefore, EC is used to avoid selecting such nodes as a parent that has low remaining energy. The energy consumption of the node x is determined based on its different operating states. In general, these states are reception (R x ), transmission (T x ), processing (CPU), and low power mode (Sleep). The Energest, an energy estimation module of Contiki OS [72], is used to know how long these operating states last. Moreover, the power consumed by these states can be found in the CC2420 chipset datasheet. Finally, the current energy expenditure e cr (x) of a node x over time is, as follows.
where T state represents the time duration that the node spent in each operating state, and P state is the power expenditure in the corresponding state in a unit time. The remaining energy re(x)is measured as the difference between maximum energy and current energy expenditure by a node x as follows.
re(x) = e max (x) − e cr (x) (12) where e max (x) is the maximum energy of a node x. Finally, we present the objective functions to ensure QoS differentiation through multi-topology routing using multiple RPL Instances, which manage three types of traffic described above. To satisfy the QoS requirement by constructing the virtual DODAGs, the OFs should incorporate appropriate network information, for instance, to achieve high reliability, the OF needs to include reliable links, likewise to achieve lower latency, delay metric should incorporate in the OF. The energy-based metric can be conjoined with all traffic types because all types of applications need to prolong the network lifetime. Table 1 shows the RPL Instances that coexist in the network. Now, for each of the classified traffic, we define different OFs as follows. 1. QoS-Aware delay-tolerant objective function (QAD-OF). It determines and maintains the data forwarding path, considering the multiple routing metrics such as ETX, QU, and RE to achieve high reliability and minimal loss.
Minimize (e(x) ∧ q(x)) ∀x ∈ P(x) Maximize (re(x)) ∀x ∈ P(x) For the routing objective, the above expression means that from the set of candidate parents for node x i , select the preferred parent that has the lowest ETX and queue occupancy and has the maximum remaining energy. Each DODAG in the RPL Instance (I 1 ) is constructed based on the rank value, and the rank R(x) of each node ∀x ∈ N in z ∈ Z is calculated as follows.
where P p (x) is the rank value of the preferred parent of node x in DODAG z, and δ is the constant integer to ensure loopfree routing and for satisfying the condition expressed as in (1). In our implementation, we have set δ = 1. Also, R x z ≥ 0 is the rank value of the root node in the DODAG, and it is the smallest value in the tree-shaped network topology.
2. QoS-Aware critical objective function (QAC-OF). It determines and maintains the data forwarding path, considering various routing metrics such as delay, VOLUME 8, 2020 ETX, QU, and RE to achieve short delay and high reliability.

minimize(d(x) ∧ e(x) ∧ q(x)) ∀x ∈ P(x) maximize(re(x)) ∀x ∈ P(x)
The above expression means that from the set of candidate parents, select the preferred parent that has the lowest delay, ETX, and queue occupancy and has the maximum RE. For each DODAG in the RPL Instance (I 2 ), the rank R(x) of each node ∀x ∈ N in z ∈ Z is calculated as follows.
where P p (x) is the rank value of the preferred parent of node x in DODAG z, and the rest of the parameters are the same as in (14).

QoS-Aware regular objective function (QAR-OF).
It determines and maintains the data forwarding path, considering two different routing metrics such as hop count and RE for selecting the appropriate route and prolong the network lifetime. Based on QAR-OF, a node select the candidate parents based on the shortest hop count h from node x to the DODAG root. From the set of the candidate parents, a node selects the preferred parent that has shortest hop-count, and if there are multiple such candidate parents, it selects the one that has maximum RE. The expression is as follows.
minimize(h(x)) ∀x ∈ P(x) maximize(re(x)) ∀x ∈ P(x) (17) For each DODAG in the RPL Instance I 3 , the rank R(x) of each node ∀x ∈ N in z ∈ Z is calculated as follows.
where P p (x) is the rank value of the preferred parent of node x in DODAG z, and the rest of the parameters are the same. In our objective functions, for calculating the rank value, the constant integerδ is used as a rank increase factor to ensure the rank difference between the node and its parent. Note that in our proposition, the best parent of node x is not the lowerrank neighbor, but the preferred parent is selected based on the combination of different metrics considered in respective OF, and the parent selection technique is described in section VI.

C. DODAG TOPOLOGY FORMATION AND ROUTING
For multi-topology routing, the DIO messages are used to construct and categorize the logical DODAG topologies in the same physical network. Establishing the DODAG topology is a distributed approach, but is initially initiated by a DODAG root S = {s 1 , s 2 , . . . , s n } by broadcasting the DIO message. The DIO message carries different network parameters that allow nodes to discover RPLInstance, OFs, and select the candidate parent set. The other information includes the DIO sender's rank R and several chosen metrics. The information on the metrics contains in the DAG metric container of the options field of the DIO message. Besides, in the DAG metric container, different routing metrics are defined in the form of the metric data object. The routing object indicates the metric of a particular type, which may present in the metric data field in any order. Therefore, we specify the routing metric data object in the DIO message structure in the manner as described in [14]. For instance, re comes under node energy object, and q is declared as a node state object. To store the metric type, length, and value, we use six additional bytes in the DIO message. See [8] for a detailed description of the structure of the DIO message.
To create effective routing, we define the neighbor set as a subset of the nodes that can communicate through link-local multicast. After receiving the DIO message, each neighbor node x ∈ Nb(x) in the network recognizes DODAGs using DODAGID and RPLInstanceID and computes its rank based on the respective OF. Next, the candidate parent set P(x) is achieved as a subset of the neighbor set, which satisfies the conditions as described in (1). Finally, the node selects a preferred parent P p (x) from the candidate parent set, which has the best path characteristics toward the DODAG root. Further, each node creates a routing table (R_tab) to store information about identified DODAGs, and the records maintained in the table includes node's rank (R_s i ), candidate parent (p_s i ), RPLInstance(I i ), DODAG root ID (s i _ID), and a joined flag, which indicates whether a node has joined the graph or not. Additionally, we denote an Instance of the DIO message by DIO_Msg, so we use it as a prefix with the parameters.
Initially, for all DODAGs, the rank of the root and R_s i is set to 0 and ∞. Let's assume that O_Inst i is the OF associated with an RPLInstance I i , and DIO_Msg_Src denotes the node that broadcast the DIO message. After receiving the DIO message, a node checks whether to join the DODAG. For this, it examines the RPLInstance and correlated parameters and computes the rank. Each node joins the graph if the DIO contains a new O_Inst i , or the broadcasted DIO_Msg.R_s i is better than the existing one. Based on the rank values, each node creates the candidate parent sets and classify them according to the corresponding RPLInstances in the routing table. Afterward, each node x in z ∈ Z under each I i selects a preferred parent in the manner described in section VI to forward the particular data traffic. Thus, when x receives the data packets correlated with an RPLInstance, it transmits them to its P p (x). Similarly, P p (x) repeats this procedure until a DODAG root s ∈ Sz in I i receives the data packets. Moreover, receiving the DIO from a lower-ranked sender can cause no update in the R_tab and is considered as consistent DIO for consistency check in Trickle algorithm. Algorithm  configured based on the QAD-OF, the node will broadcast I 1 and respective metric values. Unlike the default RPL scheme, the rank calculation and parent selection metrics are distinct.

VI. PARENT SELECTION FRAMEWORK
As discussed earlier, selecting a preferred parent using a single routing metric can lead to numerous issues, such as a flocking effect, which could significantly impact on QoS requirements of the application. Hence, we combine multiple routing metrics by exploiting the GRA approach to address such kind of problem. Furthermore, to address the decision-making problem of parent selection from the candidate parents, this method combines entire performance attribute (routing metric) values being considered for each potential parent so that the relational grade of a preferred parent can be calculated. This approach has been applied in many fields, such as engineering [73], [74], management [75] for solving complex decision-making problems.
For a parent selection problem, decision-maker node x has a candidate parent (alternatives) set of P = {p 1 , p 2 , p 3 , . . . , p n } with a set of m routing metrics (performance attributes) A = {a 1 , a 2 , a 3 , . . . , a m }. Let us consider that the weight vector W = {w 1 , w 2 , w 3 , . . . , w m } is the importance of each attribute. Now, the decision-making problem of parent selection can be represented in a matrix X = m × n as follows.
p n x n1 x n2 x n3 · · · x nm (19) where p n indicates the potential n parents from which the node x has to select one as a preferred parent and a m indicates the m routing metrics (criteria) with which possible parent's performance is evaluated.
x ij represents the value of i th potential parent with respect to j th routing metric, for all i = 1, 2, 3, . . . , n and j = 1, 2, 3, . . . , m. In our proposition, we use j th value according to the selected OF under each RPLInstance. For instance, when QAD-OF is selected the matrix adopts m = 1, 2, 3i.e., a 1 = e, a 2 = q and a 3 = re. Likewise, for QAC-OF, the attributes m = 1, 2, 3, 4 in which a 1 = d, a 2 = e, a 3 = q and a 4 = re. After creating the referential series in the form of a grey relational matrix X , which consists of a set of potential parents and routing metrics, to generate the comparative routing grade among the candidate parents, the remaining GRA procedure [69] is as follows.
1. Normalization of grey relational matrix. In this process, data can be dealt with two types, larger is better and smaller is better. Therefore, in our parent selection framework, we consider the metric's benefit and cost criteria. In this regard, the routing metrics e, d, q, and h are cost criteria; i.e., the smaller the value is the better option. Conversely, re is the benefit criteria; i.e., the higher the value, is the better option. Thus, for higher is better (benefit criteria) transformation, the expression can be defined as: in which all the performance values of j th routing metrics with respect to i th parent are normalized into y ij ∈ [0, 1], where i = 1, 2, 3, . . . , n and j = 1, 2, 3, . . . , m.
Similarly, for smaller is better (cost criteria) transformation, the expression can be defined as follows.
where y ij is the normalized value of j metrics (attributes) of i potential parents. max ∀i {x ij } and min ∀i {x ij } are the maximum and minimum value of metrics j for all potential parent i.
2. Reference sequence definition. After normalization, all the performance values of grey relational matrix are scaled into [0,1]. Therefore, if all performance values (metrics value) are equal to or close to one, the potential parent will be the best choice. However, there may not generally exist a probable parent of this type. As a result, the reference (ideal) sequence is used to find out the potential parent whose comparability sequence is the closest to the reference sequence. So, for the parent selection framework, we define the ideal sequence for all j = 1, 2, 3, . . . , m as (x 01 , x 02 , x 03 , . . . , x 0j , . . . , x 0m ) = (1, 1, 1, . . . , 1, . . . , 1). 3. Calculate the grey relational coefficient. It is calculated to determine how close x ij is to x 0j . The greater the grey relational coefficient is, the closer the x ij and x 0j will be, which can be computed as follows.
where η(x ij , x 0j ) is the grey relational coefficient between x ij and x 0j , for all i = 1, 2, 3, . . . , n; j = 1, 2, 3, . . . , m, ζ ∈ [0, 1] is the distinguishing factor, which aims to compress or stabilize the outcomes of the grey relational coefficient with moderate effects. 4. Calculate the grey relational grade. It is the correlation between the comparability sequence and the reference sequence. The grey relational grade for each potential candidate parent P i can be computed as follows.
where w j denotes the weight of routing metrics (attributes) for j = 1, 2, 3, . . . , m satisfying that m j=1 w j = 1. The weighting of routing criteria in the decision-making process signifies the importance of the selected routing metrics. To obtain the weights of the attributes adaptively, we use the standard deviation method [76] in our framework. This technique determines the weights of routing metrics as follows.
in which σ j denotes the standard deviation of the values of a j obtained as follows.
For each routing metrics j, the weights w 1 , w 2 , w 3 , w 4 , and w 5 denote the significance of d, e, q, re, and h. The weights are determined according to the OF and associated routing metrics.
5. Grey relational ranking. It is based on the degree of the relational grade. After calculating the gray relational grade of each candidate parent, we can score (sort) each in accordance with their highest Z(p i ) values. Now, for the decision-making process of a preferred parent of node x, the potential parent with the highest score is selected. In this manner, the parent selection framework chooses the optimum parent for each DODAG in the I i .

A. PARENT SELECTION OVERHEAD
Using GRA to select the best parent from a set of candidate parents is an appropriate approach because the calculation is easy and straightforward for the IoT devices with limited processing power. The complexity of this technique relies on the elements of candidate parent set |P(x)| and routing metrics |a j |, which is O(n × m). Here, n denotes the number of candidate parent of each node x and m denotes the used routing metrics. Basically, the computational complexity is linear and consistent with n and m. Thus, the calculation is easy, and the cost is not high. Consequently, there are no issues with resource-constrained IoT devices.

VII. PERFORMANCE EVALUATION AND RESULTS
In this section, we evaluate the performance of the proposed scheme through simulation experiments. The simulation tests were conducted using the Cooja simulator [77], the widely used cross-layer network simulator of Contiki OS, which can run real code for a resource-constrained IoT device using the emulated hardware. In a multi-topology scenario, the system behavior needs to be studied broadly. Therefore, we analyze the impact of the data traffic load and the network scale on the performance of the OFs in different situations. Besides, to verify that multi-topology routing is an effective approach for a large scale IoT network, we compare the proposed scheme with the default RPL OFs. Note that even though our analysis and evaluation are ContikiRPL based, the proposed scheme can be applied to other RPL implementation.

A. SIMULATION ENVIRONMENT SETUP
In our simulation scenario, we consider a multipurpose IoT network in which applications generate three types of data traffic, as described in table 1. We use topologies with three different RPL Instances, and the network consists of a total of 300 IoT devices randomly placed in a 300 m square area. The network setup time is about 60 s after that each device starts transmitting data packets and, each data frame has a 127-byte payload. To better realize the LLN characteristics, in the Cooja simulator, all the devices were configured as Tmote Sky motes with MSP430-based microcontroller and IEEE 802.15.4 compatible CC2420 wireless transceiver having a data transfer rate of 250 kbps. Moreover, we adhere to the power consumption model of CC2420 chipset.
For the MAC driver, a typical carrier sense multiple access with collision avoidance (CSMA/CA) was selected in Contiki 2.7. As far as the multi-topology is concerned, nodes can participate in multiple RPL Instances for different objectives with specific OFs. Besides, specific RPL Instance could be configured at the application tier to enable traffic differentiation. Each type of data is generated by the nodes associated with a different RPL Instance, and the data packets generated from different RPL Instances cannot be aggregated. Some modification has been made to the constant bit rate to accommodate different traffic types. In the simulated IoT network, we consider different packet generation rates to examine the proposed scheme. The total length of each simulation test is 540 s, and data is collected after the transient phase (i.e., network setup). All results plotted on the graph are the average of 10 simulation iterations. The error bars show 95% confidence intervals based on a t-distribution with ten sample sizes. Table 2 shows the rest of the used simulation parameters.

B. COMPARATIVE RESULT ANALYSIS
We show the effect of traffic load on network performance concerning the particular OF of each RPLInstance in Figs. 5-7. The end-to-end delay is an important performance metric for evaluating the QoS provisioning. We calculate it as the average time taken in the network during data transmission caused by transmission time, retransmission, and queuing time. The average end-to-end (E2E) delay of default RPL and proposed OFs under varied traffic load is illustrated in Fig. 5. As the traffic load increases, it can be observed that the E2E delay of QAC-OF is stable. On the  other hand, as compared to the default OFs and QAR-OF, the E2E delay of QAD-OF is decreased. This is because that our scheme enables the QoS differentiation at the network layer by splitting the single network into multiple virtual networks and transmit each traffic type through virtual topologies. However, the end-to-end delay of QAR-OF increases with increasing traffic load, which is expected because it builds the route to forward the regular traffic without stringent QoS requirements. The reason for the increased E2E delay of default OFs is that it uses the same metric for both topology construction and preferred parent selection. In addition, it relies on the single routing metric, which leads to the flocking phenomenon and affects the network load balance.
We examine the packet loss ratio for varied traffic loads in Fig. 6. It specifies the ratio of the total number of packets lost due to the channel and queue limitation, and the total number of packets transmitted. As can be observed in Fig. 6, with the increasing traffic load increases the packet loss trend of the network, so it can be inferred that there is a correlation between packet loss and traffic load. However, the result reveals that the packet loss rate of QAD-OF and QAC-OF is significantly lower as compared to RPL OFs. At high traffic load (i.e., 150 ppm), QAD-OF has a 12.7 % lower packet loss rate than QAC-OF, and the packet loss rate of QAR-OF is 14.2% higher than QAC-OF. This shows that in the default RPL network, the parent selection process cannot solve the load balancing issue because OFs cannot construct the topology that balances network load. Multitopology routing networks, on the other hand, create a logical topology for sending specific data traffic, and the GRAbased parent selection procedure resolves the load-balancing problem, thus eliminating the flocking effect. At the highest traffic load, the OF0 has about a 49.6% higher packet loss rate than QAD-OF.
Another key performance metric for evaluating the QoS provisioning is the packet delivery ratio (PDR). In Fig. 7, we have examined the PDR with respect to different traffic loads. It signifies the total number of successfully received data packets by the DODAG root over the total number of transmitted packets by the source node in the network. In the multipurpose large scale network, for both critical and noncritical traffic classes, high reliability is of paramount need. As we can notice that the PDR of both critical and noncritical packets is higher than regular traffic. Here, it is worth mentioning that QAC-OF and QAD-OF construct the routing topology to forward critical and non-critical data traffic, respectively. As compared to QAD-OF, the PDR of QAC-OF is higher under high traffic load, in which QAC-OF achieves the minimum and maximum PDR of 76.1 % and 82.5%, while QAD-OF maintains 67.8% and 78.9%, respectively. In contrast, the PDR of QAR-OF is relatively higher because it constructs routing topology for regular traffic, which is expected. On the other hand, the PDR of OF0 and MRHOF decreases with the increased traffic load.
Next, we tried to verify the performance from another perspective. To this end, we examined the scalability of the OFs with different network sizes. To analyze the impact of topology variation on QoS provisioning, we set the number of nodes from 60 to 600, and the traffic generation rate is 60 ppm/node. The other simulation settings are the same.
The average end-to-end delay with different network sizes is illustrated in Fig. 8. As expected, the E2E delay of QAC-OF  for critical traffic is significantly lower than that of the QAD-OF and QAR-OF. When the network size is over 300 nodes, the average delay difference between QAC-OF and QAD-OF is approximately 78.14%. Furthermore, the result indicates that the E2E delay for critical traffic is relatively flat with increased network size, while for all other traffic, the E2E delay is sharply increased. The reason is that QAC-OF follows both the delay and queue utilization information in the routing decision. In contrast, QAD-OF pursues queue utilization but does not consider delay metric. Besides, this OF aims to construct topology mainly for the delay-tolerant traffic. On the other hand, the E2E delay for default RPL OFs increases with increased network size. The MRHOF shows the worst E2E delay performance. This is because of the ETX metric that does not construct a balanced network, particularly in a dense network. However, OF0 maintains a relatively lower E2E delay, because the routing decision is made based on a hop-count; still, it is not enough for QoS provisioning in our multipurpose IoT network scenario.
As we can see in Fig. 9, for all OFs, the packet loss ratio increases as the network size increased. However, the loss rate of QAD-OF is lowest than that of all others. The packet loss rate of QAC-OF is slightly higher than QAD-OF. It is because QAD-OF can be aware of the buffer backlog state of each node during topology construction, while QAC-OF only considers queue state during parent selection process. Consequently, QAC-OF increases the packet loss rate by almost 12.4%. With the increase in network size, the packet loss trend of OF0, MRHOF, and QAR-OF is also rapidly increasing. This impact shows that these OFs are not able to be aware of the node's queue state and confirms that the single metric based parent selection process faces balancing issues, which may lead to a severe flocking effect in large networks. Fig. 10 illustrates the packet delivery ratio with different network sizes. It can be noticed that as the number of nodes increases, the PDR of all OFs is increasing. As compared to the default RPL routing process, our multi-topology routing scheme determines more routing paths to transmit data packets successfully towards the root, mainly in a dense network. Therefore, the proposed OFs achieves high PDR than that of others. As the number of nodes increases from 300 to 600, the PDR of QAD-OF increased by almost 13.6%; whereas, QAC-OF, QAR-OF, MRHOF, and OF0 increases the PDR by 12.4%, 11.2%, 11.1%, and 10.4%, respectively. This higher increment in QAD-OF and QAC-OF is due to the use of multiple routing metrics and the parent selection process to respond against the flocking effect that influences the QoS support.
After these evaluations, we analyzed the impact of the varying link quality on QoS provisioning under high traffic. In this regard, we define the link quality as the ratio of the transmission success ratio (Tx) and receiving success ratio (Rx). To realize the heavy traffic load in a dense network, we set the traffic generation rate to 120 ppm per node.
We examined the throughput of all OFs with respect to different link quality conditions. We define it as the amount of data received by the DODAG root in bytes. For this, the control packets such as DIO and DAO are not considered. As can be seen from Figs. 11-12, not only the size of the network and the traffic load affect the QoS, but also the link quality conditions can influence the QoS performance in a multipurpose IoT network. In Fig. 11a-f, we have presented  the throughput for different OFs at different link quality conditions. The result reveals that the networks with better link quality conditions have a higher throughput. With the increased Tx/Rx, both QAD-OF and QAC-OF achieves the greater throughput than that of other OFs under high traffic load. This is expected because both QAD-OF and QAC-OF are designed to explore and maintain routing paths for data packets that require high reliability. In contrast, QAR-OF and OF0 lose most of the data packets, during transmission, and thus achieves the lowest throughput. Moreover, these OFs do not consider the metric related to link quality in the routing decision. VOLUME 8, 2020 Similarly, we further evaluated the impact of node status in terms of buffer overflow on the routing decision. Here, we define the queue loss ratio as the ratio between the number of data packets dropped due to buffer overflow and the total number of injected packets into the node's queue. Fig. 12 illustrates the queue loss ratio under different link quality conditions in the last t time. The result shows that the QAD-OF and QAC-OF have decreased the queue loss ratio significantly as compared to the default RPL OFs. At the worst and best link quality conditions (i.e., Tx/Rx-50 and Tx/Rx-100%), the average improvement on the queue loss ratio of QAD-OF and QAC-OF is better than MRHOF and OF0.

C. ROUTING OVERHEAD ANALYSIS
In this section, we investigated the routing overhead of the proposed multi-topology routing approach from different aspects. In our multipurpose IoT network, we only consider upward traffic, so, we examine the overhead of the DIO control message of each node. In this simulation test, we set the traffic generation rate to 60 ppm per node. The Trickle timer is used in our multi-topology approach to realize the low routing tree construction and repair overhead. So, we take into account the Trickle parameter I max , the maximum time interval in ms, to analyze the routing control overhead. It is defined as the ratio between the total number of DIO messages and the number of data successfully received at the DODAG root. In fig. 13, we can observe the normalized control message overhead with the varying size of the I max . Each node that associated with Instance-1 of multi-topology DODAG tree structure incurs extra routing control overhead than that of Instance-3. Similarly, the same situation occurs with the nodes in Instance-2. This overhead is due to resetting the Trickle timer more frequently to disseminate network information (i.e., queue state) timely. Instance-3 uses only hop count as a core metric to construct a routing path, so it does not reset Trickle timer frequently. In a multi-topology system, inappropriate parent selection can also have a significant effect on QoS provisioning. In addition, frequent parent change can result in network instability, and this behavior severely affects the network balance. As a result, the routing performance is affected.
To this end, we have examined the parent change tendency from different perspectives. Fig. 14 depicts the result of this examination. As shown in fig.14a, with a short I max interval, the average parent change of default RPL is higher than that of our proposed multi-topology routing approach. Although default RPL incurs relatively low control overhead because of its pre-established route, the parent change frequency is high. It is because, with a short I max interval, the topology building and repair quickly reaches the convergence phase, but due to the rapid change in routing information, a single metric based parent selection process keeps changing its parent frequently. As a result, the flocking situation arises in the default RPL network. However, our proposed parent selection framework manages this flocking situation. Fig. 14b indicates that our proposed approach does not impose extra overhead in terms of parent change when the traffic load is high, as compared to default RPL. Similarly, we have considered the energy consumption as another key benchmark in terms of overhead. Therefore, to evaluate the proposed work in terms of energy depletion, we compare it with the default RPL in various aspects. For this, we have conducted simulation tests under two different scenarios, one is at a traffic load of 6o ppm, and the other is at 90 ppm. Fig. 15 depicts the result of this examination. As can be observed in fig. 15a, with the decreasing control messages, the average energy consumption decreases for both approaches in each scenario. However, when the interval I max is shortest, our proposed work performs about 34.3% and 23.6% better at a traffic load of 60 ppm and 90 ppm, respectively. One of the main reasons for high energy consumption in RPL is its DODAG tree depth. Fig. 15b shows the average energy consumption under Tx/Rx ratio. From the figure, we can see that the energy consumption decreases as the Tx/Rx ratio increases. However, compared to the default RPL, the proposed work outperforms in both scenarios. It is clear from the results that the proposed approach not only limits the routing overhead but also extends the life of the network.

D. IMPACT OF DESIGN PARAMETER
After these evaluations, we also analyzed the influence of a design parameter in parent selection on the performance. We aim to verify how the design parameter contributes to enhancing QoS provisioning in multi-topology routing. For this, we selectively adjust the distinguishing factor, a design parameter in the GRA model, and compare the outcome of each adjustment with different RPL Instances. We set the traffic generation rate to 60 ppm per node. To evaluate the performance, we consider the sub-DODAG size and sub-DODAG depth as performance metrics. Here, by depth, we denote the total hop-counts between the parent and its sub-DODAG nodes. Fig. 16 shows the maximum size of the sub-DODAG for a different distinguishing factor. To analyze the sensitivity of ζ , we set the value of distinguishing factor to 0.1, 0.3, 0.5, 0.7, and 0.9, respectively. From the result, we can see that adjusting the distinguishing factor can have an impact on the grey relational coefficient. However, this impact on parent selection is minimal. As we can see from the result, the variation in the size of the sub-DODAG for all values is not very large, but at 0.5, the size is the smallest one. Likewise, fig. 17 shows the maximum hop distance in the sub-DODAG for a different distinguishing factor. From the result, we can notice that adjusting the value to 0.5 reduces the maximum hop distance compared to other adjustments. Now, by comparing both sub-DODAG size and depth, we can presume that correlation is there between them. With this in mind, it can be assumed that small sub-DODAG sizes may reduce hop depth. Instance 1 and 2 dramatically achieves performance improvement in terms of hop depth over Instance 3. We believe, in large scale networks, QAD-OF and QAC-OF have more opportunity to select potential parents in a balanced manner by exploiting the benefit and cost feature of the GRA method during metric composition. In contrast, QAR-OF selects the potential parent based on a tie-breaking metric.
Based on the above analysis, we conclude that the design parameter, distinguishing factor, does affect the network performance in some way, and we empirically optimized this parameter by observing the QoS performance. Results show that GRA-based parent selection is suitable for multi-purpose large scale networks and provides the best network performance when ζ = 0.5. Therefore, we have used this value in our simulation testing and evaluation.

VIII. CONCLUSION
In this paper, we have proposed the multi-topology routing approach to deal with the issue of QoS differentiation in RPL for large scale networks having different traffic types. Three different RPL compliant objective functions are defined to enable traffic differentiation at the network level. Besides, we identified the parent selection problem in RPL, and also, the metrics composition method cannot efficiently handle the QoS requirements of the diverse application in large scale networks. Our approach resolves the problem by using a new parent selection framework, which takes into account the benefit and cost criteria of different routing metrics and responds against the flocking effect. In this way, the parent selection framework helps in utilizing the network resources effectively. Extensive simulation tests have been performed in different scenarios to validate the effectiveness of our approach for QoS differentiation. The results verified that our multi-topology routing approach significantly improves the QoS provision in terms of reliability, delay, and packet loss while ensuring the stability and minimal overhead on the network compared to default RPL. Thus, from our study, it appears clear that our proposed approach can support the QoS differentiation for diverse traffic types, and this makes it suitable for large scale multipurpose networks. We expect that our multi-topology routing approach can yield better performance in a realistic setting. Therefore, in the future, we intend to implement and verify it on a real IoT testbed.