TB-RPL: A Try-the-Best Fused Mode of Operation to Enhance Point-to-Point Communication Performance in RPL

Abstract

RPL is the IPv6 routing protocol for low-power and lossy networks in the Internet of Things which supports point-to-point (P2P) communication. However, the partition of two modes of operations (MOPs) in downward routing complicates achieving high performance. In the non-storing mode, a downward route with the longest path length is often picked. In the storing mode, the downward routes to some child nodes cannot be stored by their parent because of the limitation of memory space, which makes some nodes unreachable. In addition, there are extra performance costs of mixing or switching the two modes in the existing hybrid-MOPs works. Therefore, this article proposes TB-RPL to achieve an enhancement of RPL with a better performance of P2P communication. It allows all nodes to behave in a single and uniformly fused MOP that solves the problems mentioned above. The proposed mode uses a modified routing header format and introduces a threshold to the number of route entries. We implemented and compared TB-RPL with related mechanisms in Cooja simulator based on the Contiki-NG operating system. Simulation results verify that TB-RPL eliminates the three identified problems. Consequently, it significantly improves the performance of P2P communication in LLN.

1. Introduction

The Internet of things (IoT) provides a big picture and foundation for a new era. Diverse types of “things”, ranging from tiny chip-embedded physical objects to powerful computers, are allowed to connect and communicate with each other through the IoT [1]. The IoT has attracted plenty of application implementations and protocol designs from industry and academia [2]. Applications can run on the IoT, along with a set of supporting technologies, such as designated modifications of IPv6, network stacks with light-weight requirements for hardware, etc. Currently, there are still open issues in several areas, such as interoperation with different networks, heterogeneity adaption resolutions, efficient routing with hardware constraints, transmission security, and so on [3,4]. There are plenty of categories of IoT networks, among which the low-power and lossy network (LLN) was considered as a key target network scenario by the Routing over Low Power and Lossy Network Working Group (ROLL WG) of the Internet Engineering Task Force (IETF) (https://datatracker.ietf.org/wg/roll/about/ (accessed on 5 February 2023)), which is an essential building block in the IoT-based infrastructure [5].

LLN works with unstable connections and resource-constrained devices. The unstable connections cannot sustain reliable long-range communications, while the resource-constrained devices bring strong limitations in data computing and storage capabilities. In the designs of the routing protocol for LLN, all the above features play important roles, which makes conditions more limited than that in traditional host networks [6]. In order to meet these challenges, the IPv6 routing protocol for low-power and lossy networks (RPL) [7,8] is proposed and adopted as a routing solution to the scenarios defined in IEEE 802.15.4e [9]. In around 2009, RPL was discussed to perform as a routing protocol to meet the particular requirements of wireless sensor networks, through a gradient routing strategy [10]. Specifically, IETF ROLL WG worked to implement it and proposed the early foundational works [11,12]. With continuous improvements, RPL was recognized as a standard for LLN in RFC 6550 [13] in 2012.

RPL adopts an ad hoc logical routing topology, which is based on, but different from, a physical device layer topology. The basic unit of RPL is an instance. One instance consists of one or more destination-oriented directed acyclic graphs (DODAGs) [14,15]. Each instance has different environment parameter settings, and a DODAG can be upgraded by issuing a new version number. Briefly, a DODAG is a directed acyclic graph anchored on a single root that is also called a LLN border router (LBR) [16,17]. LBR governs the internal RPL network, and also acts as a bridge to interoperate between the internal RPL network and the external IPv6 networks. Figure 1 illustrates this high-level structure.

In the RFC 6550 [13], RPL is designed with three in-built categories of communications: (1) point-to-point (P2P); (2) point-to-multipoint (P2MP); and (3) multipoint-to-point (MP2P) communications. Specifically, P2P refers to the data traffic from any node to any node, P2MP means the data traffic from root to multiple nodes, and MP2P indicates the data traffic from multiple nodes to root. Two distinct routing schemes, upward routing and downward routing, are proposed to support these communication patterns. Upward routing refers to the data flow from leaf node, through routers, to the root. On the contrary, the data flow from root to leaf nodes is defined as downward routing. MP2P is implemented by upward routing, P2MP utilizes downward routing. Finally, P2P adopts a combination of upward routing and downward routing.

However, that three types of communications are supported differently according to RFC 6550. Because upward routing is just sending messages to its preferred parent, which is already determined in the topology setting up stage, MP2P is a primitive scheme and receives efficient support from the standard. P2MP and P2P are also supported by the standard, but extraneous control mechanisms and huge control messages are required to perform, which causes the performances of both P2MP and P2P to subside. In conclusion, the performance of the MP2P communication pattern is completely supported in RFC 6550, whereas the supports to P2MP and P2P patterns are trivial.

Precisely, in upward routing, control information is transferred from children to their parent, then to the parent of the parent recursively until it reaches the root. Upward routing is deeply embedded with the DODAG formation process. When a DODAG is formed, an upward routing is established. As a counterpart, downward routing happens after or within a DODAG formation stage. Generally, downward routing drives data from a parent to its children, then to the children of the children recursively until to a destination node or a leaf node.

Furthermore, downward routing can be divided into two types of mode of operations (MOPs): storing mode and the non-storing mode. When a node starts to establish a downward routing, it sends destination advertisement object messages (DAOs) to its preferred parent, which includes all the information for finding a child. In the non-storing mode, a parent does not store or even not process the DAOs from its children. Instead, a parent forwards that DAOs to its parent up to the root. In this case, all downward routing information is stored in the root, and such a scheme is known as source routing. On the other hand, in storing mode, all the related parents extract and store the downward routing information of their subtrees from that DAOs. In summary, both MOPs require enough memory space in the nodes or root, which is a limitation on resource-constrained devices.

Due to the different levels of performance support to different data traffic patterns in RPL, in the networks adopting RPL as a routing protocol, MP2P communication with an upward routing scheme dominates the scenarios among such types [18]. However, P2P communication is also an important component in certain LLN applications where a node needs to exchange data with another node [19]. In a given deployment of RPL, RFC 6550 prescribes that all nodes must use the same MOP. So, it is compulsory to choose one of the two MOPs in a DODAG. This problem is termed the MOPs incompatibility problem in this article. Consequently, in a memory constrained LLN, the non-storing mode is preferred, which may reduce the requirement for the memory capacity of intermediate nodes. On the other hand, when memory is not a severe concern, the storing mode is a better choice for improving the downward routing performance by reducing unnecessary overhead.

In a network where only one MOP is required to work efficiently, there is no MOPs incompatibility problem. However, if two MOPs can be compatible in a heterogenous network, where different hardware configurations and performance expectations coexist, the efficiency of downward routing will be significantly improved. Because it can flexibly choose different MOPs according to the actual situation of each node to maintain the advantages of the two MOPs and avoid the disadvantages of both at the same time. Therefore, in order to achieve high performance of P2P communication, the related LLN applications prefer to solve the MOPs incompatibility problem in RPL to achieve the above objectives [20]. How to support the two MOPs working in a single network is still an open issue. It is also the requirement for and the purpose of this research to propose an effective hybrid-MOPs solution to the MOPs incompatibility problem in RPL.

To achieve this hybrid-MOPs objective, we propose the try-the-best RPL (TB-RPL), where each node tries its best to store DAO messages to achieve high performance of downward routing in RPL. In a high-level description, all the nodes in TB-RPL should run in a single and uniformly fused mode by default. Two cases are defined based on a threshold α for the maximum number of route entries. The node stays in a normal case and stores children’s information normally if the memory space for route entries does not run out. Otherwise, the node enters a weak case and asks its preferred parent to help save that information. If this preferred parent also runs out of the space for route entries, it repeats the previous mechanism until the root obtains a request to help save the route information. In this design, there is no distinction between MOPs; put it in other words, the MOPs incompatibility problem is solved. All nodes perform in a single TB-RPL mode that includes the consistent logic and the same working context.

Furthermore, based on the proposed TB-RPL, the RPL reliability is improved to some extent. Specifically, the downward routing collapse problem in the non-storing mode caused by DODAG root failure is relieved. In the non-storing mode, the downward routes of all nodes are stored by a root. If a root fails (even if temporarily), all the downward routings are broken, which is termed the DODAG root failure problem in this article. In TB-RPL, it allows for not relaying all P2P traffic through the root. So, in case of a DODAG root failure, the root’s immediate children can take over the root duty in their own subtree. This process can be performed recursively. That means part of the DODAG can still work when the DODAG root failure problem occurs. In conclusion, TB-RPL mitigates the DODAG root failure problem, and consequently improves the RPL reliability.

Within the above theoretical framework, three more detailed problems are identified in this article, existing in the current downward routing mechanisms in RFC 6550 and related works. They are the long-path problem, children-unreachable problem, and hybrid-overhead problem. The children-unreachable problem is derived from memory limitation, which is more visible in a network. In this research, they can be considered the same. We executed a series of experiments to ensure that the proposed TB-RPL deals with these problems and improves network performance in terms of a lower end-to-end delay by solving the long-path problem, a higher packet delivery ratio by overcoming the children-unreachable problem, and a lower packet loss by avoiding the hybrid-overhead problem. Furthermore, the three problems also affect each other. An overall performance promotion relies on solving a set of problems, instead of just solving any single one.

To summarize, the motivations of this article are:

-

Providing an efficient P2P communication mechanism which standard RPL did not achieve. At the same time, improving the memory limitation problem on resource-constrained devices;

-

Solving the MOPs incompatibility problem in standard RPL to act as a specific mean by which the performance of P2P communication is improved in a heterogenous LLN.

While the contributions of this article are:

-

The two set objectives from the above motivations are achieved successfully by the proposed TB-RPL;

-

TB-RPL improves RPL reliability by mitigating the DODAG root failure problem recursively;

-

Three more detailed problems are defined explicitly, which provides a framework for clearer qualitative and quantitative analyses of P2P communication performance issues in RPL;

-

To the best of our knowledge, it is a breakthrough to achieve two MOPs fusion and unification, where all nodes perform in the same single TB-RPL mode that includes the consistent logic and the common working context.

The rest of this paper is organized as follows. Section 2 presents a literature review to solve the commonly concerned problems, which is the state of the art of this topic. Section 3 provides preliminaries of standard RPL, detailed definitions of the issued three problems, as well as the practical motivation to propose new mechanisms. Section 4 illustrates the complete mechanism of TB-RPL in detail. Section 5 shows the experiment settings and corresponding results and discussions. Section 6 concludes this article and suggests future works. Abbreviation provides a summary and expansion of abbreviations in this article.

2. Literature Review

In this section, the main mechanisms of related works are stated in sequence. Then a summary and analysis of the related works will be provided. Last, compared to related works, the differences and contributions of our work will be discussed.

There have been several works on the hybrid-MOPs topic [21,22] since the first related research was proposed by Gan et al. [23], which is called a more memory-efficient RPL (MERPL). MERPL provides a way to change the non-storing mode to the storing mode and determines the upper limit of the number of route entries for each node of the storing mode, through which to reduce memory consumption. However, downward routes establishment starts from leaf nodes and proceeds to the root, which indicates that children would receive full memory earlier than parents in normal case. It is a reverse order of the proposed mechanism. Moreover, the switch from the non-storing mode to the storing mode requires a statistic number of route entries of each child, which introduces new control overhead.

Ko et al. [24] have proposed the DualMOP RPL. Their work solves the network connectivity problem by allowing interoperation between by mixing the two modes in downward routing, without switching them. The nodes in the storing mode save downward routing information and make decisions based on conditions of the next-hop node. If there is the non-storing mode of the next-hop node, the current node performs a source routing to destination. Otherwise, the current node sends packets normally to the next-hop in a standard storming mode way. However, the coexistence of two modes keeps drawbacks of them both. Even though that downward routing avoids partition from connectivity, there is still room for a higher network performance compared to switching modes dynamically. Moreover, extra control overhead also is introduced, due to the fact that a parent must know which MOP its child uses.

Kiraly et al. [25] have proposed the D-RPL, which uses a multicast group that acts as the special memory space for downward routing. When a node’s preferred parent’s memory is full and cannot store downward routes information, the node issues a request to register as a member of the downward routing multicast group. Then it is termed a junction node, due to the fact that it can perform both in the normal case and in that multicast group case. The root transmits some packets to a junction node in that group, when the root does not know where the packets’ destination is. Then, the junction node takes the duty to forward these packets through normal downward routing. Even though nodes of full memory can be skipped in downward routing, the memory space in the multicast group is still part of network, which does not improve the memory limitation of overall network. Moreover, the long-path problem is not solved thoroughly; there are still many packets going through the root.

Ghaleb et al. [26] have proposed the Enhanced RPL. According to their work, a node is permitted to send DAO messages through multiple parents to lighten the storage burden of a single preferred parent. In detail, a node sorts all its candidate parents based on the parents’ rank. The parent of highest rank in the list is selected to receive DAO messages. However, the parent can refuse DAO messages. If it does so, it will be removed from the list of children to send DAO messages. Then, the child continues to try to send DAO to the first parent in the current list. Generally, the proposed mechanism is more related to the selection of DAO parents instead of handling MOPs. In this case, the memory limitation problem can be improved by polling each candidate parent in sequence. However, a polling process is time and resources consuming, which is also a control overhead. Moreover, results are more random and unpredictable, so the proposed mechanism is not efficient enough.

Oh et al. [27] have proposed the hybrid mode RPL. In this scheme, the authors try to achieve both advantages of two modes in RPL. Specifically, the root only saves downward route information of leaf nodes, while other middle nodes store route information of non-leaf nodes. In addition, a modified hop extension header is designed to provide the last one hop from routers to leaf nodes. This mechanism reduces the storage burden of the root. However, the large number of middle nodes still suffer memory limitations, which leads to the child-unreachable problem when a network size is large.

Vyas et al. [28] have proposed an adaptive RPL (ARPL). The authors utilized the situation where the required number of route entries of a node depends on the relative position to the root. The closer to the root, the greater number of entries are required. Therefore, a mechanism was proposed to switch MOPs adaptively based on whether a node’s memory space is full of route entries. Initially, all the nodes work in storing mode. However, the nodes in the storing mode perform like the root in the non-storing mode to perform source routing to destinations. When the number of route entries is full, the MOP is switched to the non-storing mode. At the same time, the entries of mode-switched nodes are removed. Other schemes are kept the same with operations in RFC 6550. Amal et al. [29] have proposed the H-RPL, which is like the design in [28]. However, it considered the residual battery condition of nodes. Generally, the authors provide a better method to utilize the memory space of each node by switching MOPs on certain conditions. However, the switch is unidirectional and introduces hybrid-overhead by flushing the previously established route entries during the MOP switch process.

In addition, A. K. Mishra et al. [22] have proposed a new hybrid MOP scheme for P2P communication. There are two cases defined, where ranks and number of children are considered to decide MOPs in case one. In case two, the probabilities of transmission are included as a condition and performed in cellular schemes. However, it is similar to the other hybrid-MOPs works in that extra control overheads are introduced along with the more complex data control and information collection mechanisms.

All the previous related works can be viewed as to attempts to implement hybrid-MOPs in downward routing of RPL. Generally, three categories could be classified based on the specific hybrid methods: (1) interoperation; (2) switch; (3) modification of storing mode. Furthermore, the term “interoperation” means that the two MOPs are existing at the same time and fixed, and the concern is how to foster interaction between the two different modes. The term “switch” indicates that the MOPs of nodes could be changed on some conditions. Specifically, the storing mode changes to the non-storing mode or vice versa. The last one is the modification of storing mode. In this category, compared to the standard way, the mechanism of the storing mode is modified to meet some specific functions in order to obtain hybrid-MOPs. The summary of related works is shown in

Table 1. Comparative summary of existing modes of operations presented in RPL.

MOPs in RPL	Year	Classification	Features	Limitation
MERPL [23]	2013	Switch between MOPs	Upper limits of the number of route entries in storing mode	Hybrid-overhead problem is not solved
DualMOP RPL [24]	2015	Interoperation between MOPs	Coexistence of two MOPs	Hybrid-overhead problem is not solved
D-RPL [25]	2015	Modification of storing mode	Multicast group for downward routing is used	Long-path and memory limitation problems are not solved
Enhanced RPL [26]	2017	Modification of storing mode	Polling each candidate parent	Hybrid-overhead problem is not solved
Hybrid mode RPL [27]	2018	Modification of storing mode	Modified hop extension header is used	Memory limitation problem is not solved
ARPL [28]	2018	Switch between MOPs	Number of route entries is considered	Hybrid-overhead problem is not solved
H-RPL [29]	2020	Switch between MOPs	Residual battery condition is considered	Hybrid-overhead problem is not solved
New hybrid RPL [22]	2022	Switch between MOPs	Multiple parameters are considered together	Hybrid-overhead problem is not solved

, based on previous classification.

Given all the related works, TB-RPL in this article constructs a new single type of MOP, which is a functional fusion of the storing mode and the non-storing mode intended to produce a new single one. It is different from the previous three hybrid-MOP types. There is no distinction between different modes. All nodes perform in the same single TB-RPL mode that includes the consistent logic and the common working context, which achieves the advantages of the storing mode and the non-storing mode simultaneously. Based on the review of previous works, and to the best of our knowledge, it is a breakthrough to achieve MOPs fusion and unification. The proposed TB-RPL aims to achieve better network performance by solving the long-path problem, overcoming the children-unreachable problem, and avoiding the hybrid-overhead problem. In the following sections, we describe, explain, and verify the specification of TB-RPL in detail.

3. Preliminaries and Motivations

This section aims to provide fundamentals about RPL, which include basic message formats and control flow mechanisms. The key point is the downward routing scheme in RFC 6550, which is used to implement P2P communication in RPL. Then, detailed definitions of the three problems that exist in RFC 6550 and related work, are provided.

3.1. RPL Fundamentals

RPL is designed to enable joined nodes to perform three types of communications. Initially, LBR broadcasts the initial DODAG information object (DIO) message [30] to start establishing RPL topology. There is a lot of information involved in DIO to complete an instance; specifically, an instance number, DODAG ID, version number, and objective function [31] are decided in that initial DIO. Objective function is a method used by nodes to determine their ranks, which logically represent relative positions to LBR. In the general case, the calculation of rank is related to quality of service [32,33].

3.1.1. Topology Formation

After accepting the DODAG settings in LBR’s DIO, based on the receiving rank in DIO, a node can select a preferred parent and then decides its own rank. The quadruples of instance number, DODAG ID, version number, and rank can uniquely identify one node. Then, that node will update its own information and broadcast a new DIO message containing the updated fields. This step is relayed and repeated periodically through a DIO timer by each node, until all nodes join the DODAG. Figure 2 illustrates this process. If a node wants to join quickly, it can broadcast a DODAG information solicitation message actively. The node which receives this type of message will broadcast its DIO message immediately, which will accelerate the DODAG formation process.

3.1.2. Routing Establishment

After setting up the basic topology, the routing mechanism starts to work. RPL routing contains three roles of nodes. LBR is known as a root in the routing perspective. The nodes that only send and receive data are termed leaf nodes, while a router indicates a node that can perform the routing function and data communication. Typically, leaf nodes are located on the edge of DODAG, otherwise they would cut off that network routing. Routers are placed in the middle of DODAG, which is the main constituent of the routing mechanism. Based on the data transmission direction, RPL routing is classified into two types: upward routing and downward routing. In RFC 6550, downward routing is distinguished from two modes: the non-storing mode and storing mode. The downward routing mode is determined by the primitive DIO message broadcast by root. According to standard, once the downward routing mode has been decided, it cannot be changed during the whole DODAG process.

In the non-storing mode, every DODAG-joined node unicasts a DAO message to its preferred parent. However, the receiver of DAO is root. During a path, all the middle nodes will not store or process it; they will just forward it to preferred parents until it reaches the root. Then root stores the related information of the DAO original source. In more detail, that related information contains the DAO original source’s own and its preferred parent’s IPv6 addresses. Based on that information, which is collected from each node, the root produces a source routing header to allow downward routing. For example, in Figure 3b, node E starts to establish its downward routing. It firstly sends DAO to the preferred parent node C, then nodes C and B, one after another, forward that DAO to the LBR node A. Then, the downward route to node E has been established through node A’s source routing table.

On the contrary, in storing mode, the receiver of DAO is that sender’s preferred parent, instead of the root. In this case, the preferred parent will store the related information of incoming DAO message, and then process a new DAO message to its preferred parent. This process will be repeated by each node within the path to the root. Finally, the root receives a DAO message from its children. Each node stores its subtree’s routing information, which allows the hop-by-hop routing scheme [34]. Figure 3c illustrates an example of the process in the storing mode to set up a downward routing to node E, as well as the corresponding changes of routing table of each middle node. The combination of all related nodes’ routing tables consists of the downward routing path to node E. The detailed content of the DAO message and routing table is explained in the next section, as a comparison between the proposed RPL in this research and the standard RPL.

A downward routing of RPL can be summarized as follows:

-

DAOs are generated by a node and sent to the preferred parent;

-

The preferred parent will process the DAO (as illustrated in Figure 3);

-

Finally, the preferred parent will forward or generate, then send the DAO to its preferred parent;

-

All those involved DAOs during a downward routing establishment form a DAOs set in logic.

After the above processes, each node’s downward routing table is established and maintained.

3.2. Problems Definition

From RFC 6550, the non-storing mode and the storing mode are mutually excluded on a single node. Furthermore, the way to make the two modes hybrid in a single DODAG is still an open issue. The separation and mutual exclusion of the non-storing mode and the storing mode in RPL produce difficulties in implementing P2P communication among nodes. In the non-storing mode, the upward routing is first asked to find a path from source node to LBR, and then a downward routing is performed to set a path from LBR to the destination node. In the storing mode, an upward routing just needs to find a common parent (node C in Figure 3 for example) of the two P2P nodes (nodes D and E in Figure 3 for example); then, a downward routing is executed to the destination node. Next, we focus on the detailed definitions of the three problems.

3.2.1. Long-Path Problem in The Non-Storing Mode

The goal of the non-storing mode is to save memory space for the resource-constrained devices, whose memory limitation is heavy [18]. However, in this case, LBR takes much burden to generate source routing headers of all nodes in a RPL network. Moreover, the size of a source routing header is not only much longer, but also is variable (depending on the depth of a P2P path). These features bring communication overhead and increase the complexity of the processing logic.

More severely, all the P2P communications in the non-storing mode must go through LBR. In this case, a P2P path is usually unnecessarily much long, which is defined as the long-path problem in this article. The long-path problem decreases the transmission performance among the whole network. Particularly, in a dense mesh network, this problem becomes more damageable because a mass of transmissions and retransmissions lead to network congestion.

3.2.2. Children-Unreachable Problem in Storing Mode

Oppositely, the storing mode can avoid source routing overheads, as well as the long-path problem. In fact, it performs similarly to the traditional store-and-forward routing function on the Internet. However, every node assumes the duty to store routing information of all its children in a subtree. If a network is large scale and P2P communications happen frequently, it can run out of the memory space of some nodes, which makes those nodes unable to support application-level functions. Moreover, the downward route information of some children might be lost due to the lack of memory space to store, which is defined as the children-unreachable problem.

3.2.3. Hybrid-Overhead Problem in Hybrid-MOPs Mode

Because the two MOPs cannot coexist or interoperate with each other, there are three options allowed: only non-storing, only storing, and no downward routing at all. These options are decided by the LBR setting. All other RPL nodes just accept and obey LBR’s rule. Here, the two scenarios are met: (a) if the downward routing mode is set in a RPL instance, it cannot be changed in the future, and the whole network uses the same mode; therefore, two RPL instances cannot communicate if they adopt different MOPs; (b) furthermore, if a new node uses a different MOP, it cannot join the existing RPL instance.

If a hybrid-MOP is not permitted, the previous two cases cannot be overcome. There are related works to meet those cases by: (1) interoperation with two MOPs; however, each node’s self MOP cannot change; (2) the other methods to switch between two MOPs based on some condition; however, there are time and resource overheads for switching MOPs, which leads to a decrease in network performance. In this article, we define it as the hybrid-overhead problem.

3.3. Practical Research Motivation

From the perspective of practice, a new hybrid-MOP with higher performance is valuable to seek. For instance, some advanced metering infrastructure networks or industrial monitoring networks [20,24] might coexist in the same or overlapped regions. Each application network makes up a RPL instance. These networks may be managed by different organizations. If different MOPs are chosen, they cannot perform interoperation with each other or be organized into a single RPL instance, even if an interoperation is needed to improve network performance and robustness or to meet some application requirements in the future. Therefore, achieving the better solution of hybrid-MOPs in downward routing becomes a practically meaningful issue.

4. TB-RPL Mechanism

Here, we state the proposed TB-RPL mechanism at the general level. Three components are crucial: (1) data structure of DAO message; (2) functions to process input and output DAO messages; (3) a specific downward routing table. This section introduces these three components in sequence.

4.1. Presentation of TB-RPL Mechanism

TB-RPL slightly modified the original DAO format to fit the proposed functions. The modified DAO format is shown in Figure 4. The Flags is an 8-bit undefined field reserved for future use, which benefits our design exactly. The first bit in that field is used to indicate whether it is a weak DAO message. That is the only modification of the standard DAO format. The components of DAO, as well as the combination of options, are the foundation of the whole process. In the RPL standard, a DAO message format consists of a base object along with several other options. These options include target options (TO) and transit information options (TIO), in which both options can be more than one.

Based on the context of standard RPL, three terms are defined explicitly: originator, producer, and forwarder of the DAO. A DAO originator indicates the node to whom downward routes are provided. A DAO forwarder refers to the node that works in the non-storing mode and just forwards the DAO initialized by the originator. A DAO producer means the node works in the storing mode and produces the current DAO in the DAOs set initialized by the originator.

Among types of DAO message components, the following is the summary of the most important and closely related fields:

-

The “TO” field: it contains the IPv6 address of an originator node. That IPv6 address is also called the destination used by the DAO producer to reach the originator; also, the originator node itself can be a DAO producer;

-

The “TIO” field: it includes the IPv6 address of the direct DAO parent of this DAO producer (in the storing mode)/originator (in the non-storing mode), which is stored in the parent address subfield.

For more details, the destination is the ID (IPv6 address) of the originator, to whom downward routes are provided. In standard RPL, this corresponds simply to what is advertised by a node in its DAO messages. In TB-RPL, however, any node on the path to the DODAG root may advertise one of its downstream nodes by generating a DAO containing the ID thereof as a TO. A node that generates such a DAO with a TO for one of its downstream nodes is called a DAO producer. DAOs are treated like any corresponding types of DAOs in standard RPL.

First, a DAO initialized by the originator contains: (1) the ID of the originator of the DAOs set (contained in TO, and the child is the originator node itself in this case); (2) the ID of the preferred parent of the originator (contained in TIO). Second, a DAO transmitted through a forwarder contains the same as that of the originator (because it is just a simple forwarding). Third, a DAO made by a producer contains: (1) the ID of the originator of the DAOs set (contained in TO, and the originator is a child of the current forwarder); (2) the ID of the preferred parent of the current producer (contained in TIO). Last, an example of detailed two types of downward routing schemes in RPL is illustrated in Figure 5.

In Figure 5a, node E is the originator, nodes C and B are forwarders, and node A is the root. “1:DAO(E, C)” here means the originator of the whole DAOs set is node E, and the preferred parent of the originator is node C, and the number 1 before “:” refers to that it is the first DAO message in the DAOs set. “2:DAO(E, C)” and “3:DAO(E, C)” follow the same rule.

In Figure 5b, node E is the originator, nodes C and B are producers, and node A is the root. “1:DAO(E, C)” here means the originator of the whole DAOs set is node E, and the preferred parent of the originator is node C. “2:DAO(E, B)” means that the originator is node E and the preferred parent of the current producer is node B. “3:DAO(E, A)” indicates that the originator is node E, and the preferred parent of the current producer is node A.

Specifically, for node E, all the DAOs shown in Figure 5 are necessary. If any DAO in the logical set is missed, then the downward routing of node E cannot be established. They form the indivisible whole. Each node performs the role of originator (in both modes) and forwarder (in the non-storing mode)/producer (in the storing mode) and sends corresponding types of DAO to its preferred parent periodically by the control of a DAO timer.

The node, of which the memory space for storing downward routing table runs out, is defined as a weak node. A weak node will set a weak flag that is defined as the indicator that the current DAO is produced by a weak node. Figure 4 shows the usage of this flag in a DAO message. The function of the weak flag is to tell the receiver of this DAO that it should read and store the content of TIO field in the provided order for producing a source routing header in the future (the mechanism to implement this step is the same as the source routing mechanism of the root in the non-storing mode).

One or more TO(s) must be followed by one or more TIO(s). In this designated option sequence, a TIO represents a DODAG parent, while a TO describes a child node [13]. A typical non-storing node operates multiple TIOs and sends DAO message directly to the root. A typical storing node employs one TIO without a parent address subfield and sends the DAO message to the preferred parent. Assume that Trg(T) represents a TO for a target T, and Trnst(P) refers to a TIO including a parent P. Then, a complete DAO message is defined as follows:

$$\mathrm{DAO}=\left[\left\{Trg\right(T_i\right)\left|i\text{∈}(1,2,3,...,n)\},\left\{Trnst\right(P_j\right)\left|j\text{∈}(1,2,3,...,m)\}\right],$$

(1)

where m ≥ n in standard RPL and thus the set Trg(T) is defined to own parents Trnst(P). The DAO producer itself also belongs to Trg(T). Even though the two MOPs have the same DAO structure, the contents are different. In the non-storing mode, the parent address subfield must be filled in for LBR to generate source routing header.

However, this subfield is empty in the storing mode. Because the DAO message is processed by the sender’s direct parent itself, there is no need to set parent information in the DAO message. The receiver just stores the originator address and next-hop address information, which is enough for implementing a hop-by-hop routing function. It is worth noting that the next-hop address is not included in DAO message, while it is implicitly the sender address in the IPv6 header. In summary, both MOPs use the same DAO message structure, which involves one base object, one or more TO, and one or more TIO. However, the parent address subfield must be written in the non-storing mode, while it is empty in the storing mode.

In summary, each node performs:

• In the storing mode by default;
• If the memory space used to store downward routing table runs out, this node becomes a weak node;
• Then, a weak flag is set in the currently produced DAO, with the corresponding content of TO and TIO;
• In detail, the content of TIO contains the segment of the path to originator that the middle weak node(s) cannot store. While TO is still simply the originator of the DAOs set;
• When the receiver obtains this DAO including the weak flag, it (if the receiver is not a weak node) will read and store the content of TIO field in the provided order for producing a source routing header in the future and then performs the related functions like the LBR in the non-storing mode.

For comparison, in the storing mode of standard RPL, when a node’s memory is full and cannot store more routing entries, the new coming DAO will be just discarded. Then, the node will not send any consequent DAOs to its preferred parent, while, in our proposed work, the designed content in a designated order is contained in DAOs to solve that problem.

TB-RPL DAOs set works on the above foundation. Figure 6 describes a complete process of TB-RPL to establish a downward route. In this case, node G is assumed to finish a downward routing establishment before node F. Currently, node C stores the downward route information of nodes G and D, then it runs out of memory space for route entries. So, node C does not save node F’s downward route. When 2:DAO(F,C) arrives at node C, it turns into a weak node and outputs a DAO with the weak flag to its preferred parent node B. For a weak DAO, the order of element in Trg(T) is strictly designated, which will be used by node B to perform source routing in the future. This order-designated Trg(T) is stored by node B into an ordered tuple [C, E] as an atomic unit. At last, 4:DAO(F,A) is processed by node A, then the downward routes to node G and F have been established, respectively.

Based on this downward route, node G and node F can send messages to each other. Figure 7 illustrates the data flows and related message control headers. Node B produces a source routing header, due to node C not storing the related route segment to node F. With the guide of source routing from node B, node C successfully forwards packets to node E. Then, the source routing finishes, and node E can find a route to F through its own route table. The other packets are transmitted as designed. P2P communications between node G and F are performed successfully.

4.2. Detailed Process of TB-RPL

In the previous section, a representation of the overall workflow was provided, which is a big picture of TB-RPL. This section offers the perspective of each node to process TB-RPL in detail. At the beginning, all the nodes select TB-RPL MOP. This MOP decision has been made already in the initialization DIO messages from LBR. After a DODAG is formed, each node starts to unicast its own DAO message to the preferred parent, and the downward routing establishment begins.

During the downward routing path establishment, the deeply resource-constrained devices cannot keep storing routing information about their children continuously. When a network is large-scale and contains a mass of nodes, these devices’ memory space will finally be used up to store the subtree routing information. In order to avoid the memory failure of weak nodes, a route entries threshold α is defined as the upper boundary of a node’s allowed number of route entries. Every node tries it best to store children’s routing information. When a node’s number of stored route entries is higher than α, it asks for help from its preferred parent.

If the parent node’s memory is enough, it will store the weak DAO message from its children. Otherwise, the parent node asks its own parent for help—in the worst case, until it reaches LBR. In this sense, the middle parents perform source routing for some P2P paths located in its subtree. Figure 8 summarizes the logic flow when a parent node receives a DAO message. It is worth noting that neighbor table is the prerequisite of setting up downward routes. In RFC 6550, three sets are defined and have the following relationship [13]. The preferred parent set is the subset of the parent set, which is the subset of the candidate neighbor set. In further detail, the establishment and maintenance of those three sets are performed by a specific neighbor discovery mechanism and objective function. If a node is not recognized as a neighbor, it cannot be included as a route further. The neighbor table is governed by a tailored policy. In addition, there is a point worth explaining, i.e., that the specific mechanism for neighbor discovery is not decided in RFC 6550, which will finally depend on the implementation choice.

There are four functions referred to in the logic flow, which are the essential functions of TB-RPL. Algorithm 1 shows the pseudocode about the identified four functions in Figure 8. Generally, currNode is the current node that performs current processing function. pkt refers to the DAO packet waiting to be handled. Specifically, inPkt is the input DAO, while the outPkt is output DAO. Then, trgLst is abbreviation for target list, which is a general list data structure. For the function WeakDaoOutput, its purpose is to produce an output DAO based on the input DAO’s set of Trg(T) in a strict order, which is utilized by the parent to produce source routing header. Function WeakDaoInput updates the current node’s route entries based on the input DAO by producing and storing a source routing information in weak case. The remained functions, NormalDaoOutput and NormalDaoInput, are the normal routines to handle corresponding DAO messages.

In summary, TB-RPL provides a unified framework and mechanism to allow every memory limited node to do its best to save downward routing information, so overall memory availability increases. The memory limited problem has been improved. Moreover, in downward routing, the shortest route is generally selected by nodes at any given situation. The long-path problem has been solved. Finally, with the consistent logic and common working context, there are no concepts of switch or interoperate with different MOPs required, so time and resource overheads for switching or interoperating between MOPs are saved. The hybrid-overhead problem has been overcome.

Algorithm 1: TB-RPL DAO message process

5. Evaluation and Analysis

5.1. Simulation Environment Settings

In order to verify the proposed TB-RPL performance, several sets of evaluation are performed on Cooja simulator [35], embedded in the Contiki-NG operating system [36]. Contiki-NG is a practical and matured executable code that can run on a range of real hardware platforms. During Contiki’s development history, it has produced mainly two generations. Contiki 2.0/3.0 is the early generation series, and Contiki-NG was designed for optimization. Contiki-NG contains the whole network protocol stack to support communications in LLN, from physical layer, MAC layer, network layer, transport layer, until application layer. A complete RPL protocol in RFC 6550 is implemented as the native routing mechanism working in network layer. Particularly, RFC 6550 only formulates a main body of RPL; there are still some auxiliary functions reserved to be decided, such as neighbor discovery mechanism, objective function, various timers, and so on. Moreover, Contiki-NG contains a companioned simulator named Cooja, which is a convenient tool for performance evaluation of RPL. Cooja simulates hardware device functions and provides the relevant interfaces to upper layers implemented in Contiki-NG operating system.

It is worth noting that the specific neighbor discovery mechanism in Contiki-NG implementation is the neighbor discovery for IP version 6, which is standardized in RFC 4861 [37]. Generally, that mechanism is used to obtain other nodes’ link-layer addresses and to detect and maintain information about reachable nodes, such as the related information of each path to a neighbor. The detailed mechanism specification is out of the scope of this research. In all evaluations, the default settings of this neighbor discovery mechanism embedded in the Contiki-NG operating system are always kept.

In our evaluation, Z1 motes and Sky motes [38,39] are selected as hardware platforms, which are directly supported and simulated by Cooja. Specifically, the memory spaces of Z1 and Sky are both much limited. The Z1 mote’s number of routing table entries is 8 by default in Contiki-NG, while that of Sky mote is 16. In the MAC layer, CSMA is used, as well as an adaption layer 6LoWPAN. Based on the previous layers, RPL along with IPv6 operate at the network layer. As the core parts of RPL, the objective function and timers of control message are kept at the default settings which are the minimum rank with hysteresis objective function (MRHOF) [40] and trickle timer [41], respectively.

Aiming to evaluate P2P communication efficiently, UDP is selected to act on transport layer. Finally, the unit disk graph radio medium model is used to determine the radio propagation features during simulation, such as transmission range, interference range, and propagation loss scheme. Particularly, the threshold of the number of route entries, queue size, and maximum number of neighbors during experiments, and so on are summarized in

Table 2. Simulations environment configuration.

Parameter	Value	Parameter	Value
MAC protocol.	CSMA	Nodes deployment	Grid
Adaption protocol	6LoWPAN	Distance between nodes	20 m
IP protocol	IPv6	Network size	9, 16, 25, 36, 49, 61, 81, 100 nodes
Routing protocol	RPL modifications	Radio model	Unit disk graph medium
Objective function	MRHOF	Loss model	Distance loss
Transport protocol	UDP	Receive success ratio	60%, 80%, 100%
Maximum neighbors	16	Transmission range	30 m, 50 m, 70 m
Route entries threshold α	4, 8, 16	Interference range	1.5 × transmission range
Queue size	8	Period per running	10 virtual minutes in simulator

. These constrained settings reveal the seriousness of the three defined problems more clearly.

In all simulations, nodes are set to be static, and the position of each node is placed in grid deployment. Moreover, the position of root is always set to the top left corner. Z1 motes perform middle routers, while Sky mote is chosen to be the LBR. In grid deployment, nodes are regularly and uniformly arranged in a rectangular experimental area. The nature of grid deployment is that it represents an application scheme in which all nodes’ position can be decided by network designers. Figure 9 shows a grid deployment example used in our simulation. Generally, the vertical and horizontal distances between nodes are both 20 m. The number of nodes is defined as the term network size, and the largest network size is 100 nodes, so the maximum simulation area is 200 × 200 m².

Finally, P2P communication performs with the above environment settings and data models. A sender node sends an UDP packet to a receiver node in every 10 s with a small random variation. Each running lasts 10 min in simulator virtual time. For each turn, 10 times running are repeated to obtain a statistically average result. All the captured packets are analyzed by Wireshark.

5.2. Discussion on Node Topology

Before staring the evaluations, there is a need for more detailed discussion about the validity and variability of the grid node topology used in the evaluations. Even though the positions of senders and receivers are fixed in grid topology of each network size, the DODAG and P2P path are generated randomly. Because the initial states of DAO timer and DIO timer of each node are randomly different in each running, the DODAG and P2P path formed by which are also randomly different in each running.

In the above case, if the length of a P2P path is too short, it is difficult to expose the children-unreachable problem. This is because the shorter P2P path length, the nearer and easier to obtain the common parent, which reduces the opportunity of middle nodes to lose their children information, while, if the length of a P2P path is too long, it is difficult to examine the long-path problem due to the fact that the common parent of such a long P2P path is highly probable the LBR. In this case, there are no obvious discriminations between different versions of RPL; all the paths of which are nearly the same length. Therefore, a moderate length of a P2P path is preferred to verify the three issued problems in a logically valid and uncomplicated way. In our evaluations in grid topology, five UDP senders and five corresponding receivers are selected on the edges of a grid network; the aim is to make the path lengths sufficiently long to collect representative data which can be evaluated via different metrics to verify whether the issued three problems in this research are improved.

In addition, in order to simulate in as many network environments as possible, there are sets of network settings designed with the following: (1) the route entries threshold α is set to different values to show the performance of TB-RPL in different degrees of memory limitation; (2) the transmission ranges are adjusted to different values to indicate the performance in different neighbor densities; (3) the different values of receive success ratio are used to represent various transmission qualities of network. Through the combinations of those different factors, more variabilities are introduced, even though the network topology is a grid. In summary, the variabilities of evaluation settings are from two sources: (1) the random formation of DODAG and P2P paths in each running of experiment; (2) the various combinations of different network properties.

5.3. Performance Evaluation and Analysis

This section presents the evaluation results of diverse RPL implementations based on different metrics. To ensure that the proposed work is suitable for memory-constrained nodes in LLN, we examine and compare TB-RPL with H-RPL [29] and two modes in standard RPL [13]. H-RPL is selected for comparison due to the fact that it also takes the number of route entries into consideration, which is the most relevant concern of our proposed TB-RPL, compared to other related works. However, it still adopts the logic of switching MOPs that introduces extra control overhead, while TB-RPL uses a fused MOPs mechanism. Through comparison with H-RPL, the improvement of TB-RPL by solving the hybrid-overhead problem can be illustrated directly.

5.3.1. Comparative Results Analysis

In this set of simulations, four RPL mechanisms are measured on different metrics within different network sizes to compare the performances between each other. The results indicate whether the three problems issued previously in this research are improved by TB-RPL. In each turn, the positions of UDP senders and receivers are kept the same for comparison. For all evaluations in this set, the transmission ranges are 70 m, the receive success ratios are 100%, and the thresholds of the number of route entries α are 8 for all nodes except for the LBR. Finally, the network sizes in evaluation are set to 9 nodes, 16 nodes, 25 nodes, 36 nodes, 49 nodes, 64 nodes, 81 nodes, and 100 nodes.

Figure 10 displays the result of path length metric on UDP packets. From the result, the end-to-end path lengths of all kinds of RPL increase along with the network size increasing. The reason is that the more nodes, the greater the distance from the UDP sender to receiver, which leads to a longer average path length. Before the network size arrives at 81 nodes, the non-storing mode of RPL results in the longest path length. It is caused by the long-path problem, i.e., that all downward routes must go through LBR.

Besides the storing mode, the other three RPL implementations still work successfully after the network size is greater than 81 nodes due to the fact that LBR helps store the downward routes. There is no interruption of P2P communication occurs. It is noted that TB-RPL and H-RPL have the shorter path length than that in non-storing RPL. Because TB-RPL and H-RPL depend not only on LBR’s source routing but also on the middle nodes storing its children’s downward routes. Finally, the path length of H-RPL is approaching that of the non-storing mode of RPL, while TB-RPL still keeps the shortest path length. This is because H-RPL flushes its route table and turns into the non-storing mode after the node’s memory space is full. This switch of MOPs sets up a new source routing from LBR but wastes the previous stored downward route information of children; in other words, this performance falling of H-RPL is caused by hybrid-overhead problem, while TB-RPL always tries its best to store route information without hybrid-overhead. The result shows that TB-RPL keeps the shortest path length during the whole evaluation period.

There are some unusual or typical points that are worth discussion. After the network size exceeds 81 nodes, the path length of the storing mode of RPL arrives beyond the upper bound. The reason is that the threshold of the number of route entries α is 8. When a node runs in storing mode, it could not store its entire subtree’s routes, due to the number of which is far more 8. This situation leads to an interruption of downward routes to some children, namely the children-unreachable problem. When the network size is greater than 81 nodes, the node that is the more near to root, the more children’s routes lost. In our evaluation, it is shown as the path length is over upper bound, which indicates the failure of P2P communication or the infinite path length.

Figure 11 illustrates the end-to-end delay of UDP packets. Even though end-to-end delay is related to path length in some sense to represent the connectivity of two end-nodes, they have different concerns. End-to-end delay describes the time perspective of performance. As shown in the result, the end-to-end delay of all kinds of RPL increases along with the network size growing. This phenomenon could be explained by path length. Usually, the longer path length, the longer the delay. However, it is not applicable in reverse. Before the network size arrives 81 nodes, the non-storing mode of RPL results in the highest end-to-end delay. It is also caused by the long-path problem, i.e., that all downward routes are forwarded through LBR.

Obviously, the non-storing mode of RPL still keeps the longest end-to-end-delay, except for that in storing mode, after the network size is greater than 81 nodes. The other two RPL mechanisms continuously perform fine because LBR still helps store the downward routes. However, the MOPs switch in H-RPL clears up all the route tables of middle nodes. Then, it works in the non-storing mode, which drives its delay nearly to that of the non-storing mode of RPL. Finally, TB-RPL outperforms them all, and keeps the lowest end-to-end delay.

There is also an unexpected point in need of discussion. While the network size is over 81 nodes, the end-to-end delay of the storing mode of RPL exceeds the upper bound. The reason is the same with the situation in path length part, α (the threshold of the number of route entries) is too small for middle nodes to save all their children’s route entries, which causes failures in some P2P communications. This result is represented as the delay of the storing mode being over the upper bound in the evaluation.

Figure 12 describes the end-to-end PDR of UDP packets. PDR could usually indicate the connectivity between two nodes, which is a different dimension from the previous two metrics. Path length and delay concern the statistics of packets that have already arrived destinations successfully; they do not pay attention to the lost packets. The PDR metric covers the considerations of lost packets. It could be learned from the result that the end-to-end PDR of all kinds of RPL decrease when the network size increasing. This is because the more nodes, the greater the number of packets, including data packets and control messages, which travel through the network. A large enough number of packets would produce network congestion, which prevents the packets arriving at destination correctly. Before the network size arrives at 36 nodes, the non-storing mode of RPL results in the worst end-to-end PDR. It is again caused by the long-path problem. The longer the path length, the greater the number of transmissions and retransmissions. Consequently, network congestion is more likely to occur.

The performance of the storing mode drops quickly when the network size is greater than 36 nodes instead of 81 nodes. This is different from the previous two cases and requires more detailed discussion. The result suggests that some nodes start to run out of the memory space for route entries before the network size reaches 81 nodes. It means that the consuming of memory space is a gradual procedure, which does not just begin at the network size revealed by the path length and delay metrics. After the network size is over 36 nodes, the PDR of the storing mode of RPL decreases sharply. Instead of network congestion, the reason is again that the α is too small (compared to the network size) for middle nodes near the LBR to save their children’s route entries, which causes failures in some P2P communications. It is worth noting that the root cause of the sharp drops of performance is still the memory limitation. The unusually small number of α makes such situation happen in even small-scale networks, which also means that the memory limitation problem is exposed more quickly. In the 100 nodes case, the PDR of the storing mode comes to 0, which expresses that no UDP packets arrive at destinations during simulation.

As for the other three RPLs, the non-storing mode of RPL continually stays the worst performance of PDR. TB-RPL keeps the best performance, while H-RPL has a shift from the higher PDR to approach the same performance as that of the non-storing mode of RPL. The reason is that the more nodes of memory overloaded, the more similar the behavior of H-RPL to the non-storing mode of RPL. It is worth noting that compared to the storing mode of RPL, H-RPL exchanges time for connectivity; that is, it flushes the route tables and enters the non-storing mode to avoid the children-unreachable problem happening in the storing mode. However, the time consumption and resource waste are also kinds of hybrid-overhead.

Figure 13 depicts the end-to-end packet loss of UDP packets. Packet loss is related to PDR but in different perspectives, which is an absolute number of the failed packets that usually represents the link quality of networks. In our evaluations, because the UDP packets are produced and sent regularly around 60 packets in every 10 min, and the success ratios of receiving and transmitting packets are also kept the same to every link in the P2P paths, the results analysis and discussion of end-to-end packet loss are logically consistent with that in the above PDR situations.

5.3.2. Impacts of Parameters

This section presents the results in the extra three groups of evaluation to verify TB-RPL and the impacts of different network parameters settings. Generally, these parameters represent different dimensions in describing a network. For all the extension groups of evaluation, the network sizes are fixed to 49 nodes.

Figure 14 illustrates the group of different values of α, such as 4, 8, and 16. The transmission range is 70 m and the receive success ratio is 100%. From the results shown in Figure 14a, the worst end-to-end PDR is always maintained by the storing mode of RPL. This is because for all the three subgroups of evaluation, the memory for route entries of plenty of nodes has already been filled. In these cases, the children-unreachable problem in the storing mode occurs, so the PDR decreases heavily. Specifically, when the α equals 4, it indicates that the memory space for the route table is much more limited, so the PDR is much lower than that of the non-storing mode. When the values of α are 8 and 16, they behave by the same logic; however, the children-unreachable problems are comparatively in the milder degrees. For the other three RPL implementations, the PDRs of which are almost the same with different values of α because the memory space limitations of middle nodes do not affect the PDR performance of the non-storing mode, as well as TB-RPL and H-RPL.

As a conclusion, for all the subgroups of results, H-RPL performs with a little lower PDR than the non-storing mode of RPL due to the flushing of downward route tables of nodes and the reconstruction of source routing from the root. During that period, some related downward routes are interrupted shortly. On the other hand, TB-RPL performs the best, which fits the previous analysis.

In Figure 14b, the end-to-end packet loss metric is evaluated. The situation and trend are almost the reverse of that of PDR metric, so their conclusions are logically consistent. TB-RPL outperforms the other three RPL modifications. However, there is a scenario in both Figure 14a,b worth further discussion, where the performances of the storing mode drop drastically when the values of α decrease. The reason is that the values of α (those are 4, 8, and 16) are too small to compare with the network size of 49 nodes. Consequently, some common parents of the P2P pair of nodes are full of the memory to store routing information. Especially for that common parent very near to the LBR, the probability to lose a child’s downward routing information is drastically high.

For the result depicted in Figure 14c, the three subgroups are almost in the same patterns. In all these cases, the non-storing mode of RPL has the longest path length. Because the path length metric only considers the packets that have already arrived successfully, even though the PDR of the storing mode is lower, the path length is still shorter than that of the non-storing mode. For those packets arriving at their destination through middle common parents, the path length should be shorter. In these cases, the storing modes of RPL, H-RPL, and TB-RPL would result in a similar path length. TB-RPL always obtains the lowest path length, besides that in storing mode, because the stored route entries are not removed; the related nodes could also utilize them to build the P2P path. The evaluation result verifies this situation. Finally, Figure 14d illustrates the comparison of end-to-end delay. It generally matches the situation of path length metric, i.e., that the longer the path length, the longer the end-to-end delay. In conclusion, TB-RPL outperforms the other PRL implementations in all cases, even in greatly memory-limited situations.

Figure 15 shows the group of different transmission ranges, such as 30 m, 50 m, and 70 m. The α is 8 and the receive success ratio is 100%. Because the distance between each node is fixed in a grid deployment, the shorter the transmission range, the smaller the number of neighbors which could be found. In the perspective of a single node, the neighbors of which become less dense; thus, it has a longer P2P route length. Figure 15a illustrates the comparison on PDR. It could be observed that the storing mode maintains the worst PDR performance; specifically, the shorter the transmission range, the lower the PDR that the storing mode has. This is because the network becomes sparse of neighbors in a single node’s view, and every middle node must store a greater number of route entries of children; in other words, as the number of levels of the DODAG increases, each node has more children comparatively. However, the middle nodes do not have enough route entries to store the increased downward routing information, so the children-unreachable problem occurs. In this case, the P2P paths to those children are broken down.

There is a non-evident point that requires more detailed discussion. When the transmission range is 30 m, it is sharply unstable with respect to PDR in the storing mode and is extreme low (nearly 3% for the average statistics). Because the routes to most of a node’s children are lost due to memory limitation from storing the greater number of children routing information, the remaining 3% PDR comes from the nodes that have the common parent and whose corresponding route has been also stored, which are very rare cases. The other 97% packets have been sent to the root due to there being no route in the middle nodes. Then, they are discarded by the root because the root, if lacking the support from middle nodes, also does not have the corresponding route information. However, the non-storing mode is not affected by the memory limitation of the middle nodes; all the route information is collected by root itself. TB-RPL and H-RPL operate successfully, and TB-RPL will still always obtain the highest PDR compared to others.

In Figure 15b, the results of packet loss follow the same analysis and discussion as those in the above cases. Figure 15c,d verifies the situations with respect to path length and end-to-end delay metrics. For the storing mode, the path lengths rise slowly along with the transmission ranges expanding from 30 m to 70 m. The reason is that with more limited memory space for overall nodes, there is a higher probability that the route with shorter end-to-end path length would be stored completely. For the non-storing mode of RPL, the higher the transmission range, the lower the path length. The is because the higher the transmission range, the fewer levels in DODAG. In this case, the hops between parent to child are decreased, so the path length becomes lower. TB-RPL and H-RPL obey the same logic as the above subgroups, and TB-RPL still outperforms the others. The results of end-to-end delay follow a similar analysis and discussion.

Figure 16 shows the group of different receive success ratios, namely, 60%, 80%, and 100%. The receives success ratio usually indicates the quality of the transmission environment. The situation in this group is comparatively apparent in logic. For the PDR and packet loss, all the different implementations of RPL suffer a similar decrease of PDR when the receive success ratios become lower. It is because the lower the receive success ratio, the greater the number of packet retransmissions, which leads to some degree of network congestion and results in a lower PDR. The result of the packet loss metric obeys the same logic.

As for the path length and end-to-end delay, the storing mode of RPL performs better than the non-storing mode in all subgroups. This is because the receive success ratio does not affect the required number of route entries. In this case, before the memory space for routes runs out, the P2P communication of the storing mode naturally has lower path length and end-to-end delay. However, it is worth discussing that the trend of end-to-end delay behaves differently from the trend of path length. The reason is that the delay metric not only reflects the path length but also represents the factor of transmission success ratio. Therefore, the end-to-end delay of all RPL implementations increases with the reduction of receive success ratios. However, in any case, TB-RPL maintain a comprehensively better performance throughout.

6. Conclusions

In this article, we propose a single and uniform hybrid-MOP-based TB-RPL to resolve the existing problems of downward routing MOPs in RFC 6550 and the present related works. Since RPL is the core routing solution in the LLN paradigm, analyzing the performance of a new hybrid-MOPs from both theoretical and practical perspectives is a meaningful development. To this end, TB-RPL achieves the expected objectives by dealing with the three identified critical problems. Specifically, TB-RPL utilizes a modified DAO message format and a threshold of the number of route entries to implement a robust mechanism that deals with the normal and weak cases in downward routing. Every node does its best to save route entries; otherwise, it also does its best to transmit the route information to another node. As a result, TB-RPL outperforms the other RPL variants.

Besides theoretical design, we implemented TB-RPL in a runnable operating system Contiki-NG. Moreover, based on the implementation, a comparative performance evaluation has been performed using Cooja simulator to compare TB-RPL with the related works. Simulation results verify that the proposed fused mode of TB-RPL is more stable and efficient in almost all cases. Apart from that, the fused hybrid-MOPs are better suited to P2P communications in networks with plenty of memory-constrained nodes.

In our design, we do not consider the mobile nodes in LLN. However, it is an attractive issue for us to efficiently interoperate mobile nodes using TB-RPL as some IoT applications require the mobility of certain nodes. Therefore, enabling TB-RPL to work in mobile scenarios will be undertaken in future work.