## 4 TB-RPL Mechanism
### Detailed Process of TB-RPL
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

Figure 10: End-to-end path length of UDP messages on various network sizes. 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 \(\alpha\) 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, \(\alpha\) (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

Figure 11: End-to-end delay of UDP messages on various network sizes. 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.