Abstract
In wireless sensor networks (WSNs), the presence of congestion increases the ratio of packet loss and energy consumption and reduces the network throughput. Particularly, this situation will be more complex in Internet of Things (IoT) environment, which is composed of thousands of heterogeneous nodes. RPL is an IPv6 routing protocol in low power and lossy networks standardized by IETF. However, the RPL can induce problems under network congestion, such as frequently parent changing and throughput degradation. In this paper, we address the congestion problem between parent nodes and child nodes in RPL-enabled networks, which typically consist of low power and resource constraint devices. To mitigate the effect of network congestion, we design a parent-change procedure by game theory strategy, by which the child nodes can change next hop neighbors toward the sink. Comparing to the ContikiRPL implementation, the simulation results show that our protocol can achieve more than two times improvement in throughput and reduce packet loss rate with less increasing of average hop count.
1. Introduction
In the past few years, we have witnessed the next big evolution of Internet of Things (IoT) in our life. IoT is used to connect industrial devices, hospital instruments, and household appliances such as refrigerators, air conditions, and TV sets with human applications. With IoT connected, people can control and receive messages from household appliances everywhere by their smart devices such as laptop computers, smart TV sets, and even mobile phones. These systems usually include many end devices conforming the IEEE 802.15.4 standard and they are often characterized by short transmission range, low data rate, low cost, and low communication power. In order to achieve connectable and accessible features of these devices, the Internet protocol IPv6 is proposed and serves as the best solution because of its popularization, applicability, sufficient address space, supporting for stateless address autoconfiguration, and easiness to access [1].
However, there are some difficulties to implement IPv6 in the wireless personal area networks. For instance, IEEE 802.15.4 uses only 127 bytes as maximum transmission size and IPv6 need 1280 bytes as the maximum transmission size. Thus, the Internet Engineer Task Force (IETF) working group has standardized an adaptive layer used in the devices with IEEE 802.15.4 MAC/PHY called IPv6 over low power wireless personal network (6LoWPAN) [2]. With 6LoWPAN implementation, IEEE 802.15.4 devices will gain the ability to receive, process, and forward IPv6 packets. Based on 6LoWPAN, IETF further proposed IPv6 routing protocol for low-power and lossy networks (RPL) [3]. In low-power and lossy networks (LLNs), the routers are constrained in limited processing power, memory, and energy. Thus, the interconnections between nodes are normally suffered by low data rates, high loss rates, and long delay time. As routing protocol based on LLNs, RPL is a tree-like topology routing protocol supporting multipoint-to-point (nodes to sink), point-to-point, and point-to-multipoint (sink to nodes) traffic which can be used in the applications of wireless sensor networks (WSNs) such as environment monitoring and body sensing. Because of the tree-like topology, if an event occurs in the leaf nodes, all the nodes in the event region will send packets to sink and may cause network congestion toward sink node. However, the congestion control is more difficult to achieve than other types of network because of the features of lower power and lower computing abilities in LLNs. In WSNs, congestion control [4] contains congestion detection and congestion avoidance under limited resource environment. In general, congestion detection adopts some metrics such as buffer occupancy, channel loading, and the ratio of packet interarrival time to packet service time to detect the presence of congestion. When congestion is detected, we will use the congestion avoidance mechanisms to mitigate the presence of congestion.
Currently, there is no explicit mechanism to detect or avoid congestion in RPL protocol. In fact, RPL protocol uses a simple parent selection mechanism to avoid selecting parents with bad link quality, large hop count, or large expected transmission count [5]. However, these schemes may result in ping-pong effect which refers to the phenomenon of repeated state switching from one to the other. If ping-pong effect occurs on a node, it will change its parent frequently. For example, a node will select its new parent node when it detects the congestion that occurs on the path including its old parent node. However, when congestion occurs on its new parent node later, even just after the node changes its parent, it must select its old parent node again if there is no available parent in its neighbors. As a result, the node will change its parent very frequently so that it cannot work well for relay and transmission. Even, ping-pong effect will significantly lead to packet loss, decreasing throughput, and increasing packet delay.
In this paper, we mainly focus on tree topology for two reasons. Firstly, we address the congestion problem in RPL-enabled networks routing protocol which are tree-like topology routing protocol which can be used in the applications of WSNs. In RPL pattern, if an event occurs in the leaf nodes, all the nodes in the event region will send packets to sink and may cause network congestion toward sink node. Secondly, the congestion control in tree topology is more difficult to achieve than other types of network, so that there are no researches with congestion mechanism in RPL and also they do not aim at tree-like network topology. We propose a Game Theory Based Congestion Control Protocol (GTCC) to alleviate the effect of congestion. In our approach, nodes will be informed about the presence of congestion by their parents through control messages. In this case, a child node will decide whether it changes its parent or not based on the game theory strategy [6]. Thus, our scheme can alleviate congestion by changing parent with light load and avoid the ping-pong effect. We evaluate our protocol with Cooja simulator [7]. Comparing with ContikiRPL implementation [8], our simulations show that GTCC can achieve more than two times improvement in reduction of packet loss rate and increasing of throughput with less average hop count to the sink.
The rest of this paper is organized as follows. Section 2 introduces related work. The detail of our protocol is presented in Section 3. The simulation results are described in Section 4, and Section 5 concludes this paper.
2. Related Work
In order to mitigate and avoid the presence of congestion, there are some proposed schemes aimed at congestion control in traditional WSNs. In [9], the authors reviewed various existing techniques for detecting and controlling congestion in WSNs. The research hotspots and difficulties in this area which need to be further studied were also pointed out in this paper. Depending on the control policy, the congestions control protocols are divided into resource control and traffic control. Resource control protocols are classified according to the type of resource to be tuned. In traffic control mechanisms, the protocols are divided into reactive and preventive (avoiding). Reactive solutions are classified as the reaction scale, while preventive solutions are split up into buffer limitation and interference control.
In our work, we divide previous congestion control schemes into two categories in traffic control: rate adjustment schemes and alternative path selection schemes. In rate adjustment mechanisms, the nodes will reduce their sending rate to decrease the number of packets in local and global networks when they detect the congestion. In alternative path selection mechanisms, if a node detects congestion, it would try to find another better path to transmit packets. We will review both kinds of mechanisms in this section.
2.1. Rate Adjustment Mechanisms
In COngestion Detection and Avoidance (CODA) protocol [10], the congestion can be detected by queue length and wireless channel load. When congestion is detected, all the source nodes whose source event rates exceed a threshold need to wait for the acknowledge message from sink node after sending the sensing data. If a source node cannot receive acknowledge message from sink, it will reduce its transmission rate. In [1], the authors proposed hop-by-hop congestion control and load balancing scheme called CONSEQ in WSNs. It uses special effective queue length (EQL) as metric of congestion degree. CONSEQ dynamically adjusts transmission rate according to congestion degree of each node in its forwarding set which contains neighbor nodes with smaller hop count to sink. If congestion is not mitigated, each node will use fuzzy logic to reduce the transmission rate.
The authors in [8] proposed a Priority-Based Congestion Control Protocol (PCCP). PCCP uses ratio of packet interarrival time to packet service time as metric of congestion. Once the congestion is detected, nodes will use the transmission rate of upward nodes and priority of packet to adjust its transmission rate. Also, in [11], the authors proposed a bioinspired congestion control approach for WSNs streaming applications that necessitate controlled performance with graceful degradation. A deterministic population balance equation inspired from biological systems is used as a throughput formula to adjust the sending rate of sensor nodes and to achieve adaptability to changing traffic loads, scalability, and fairness among flows.
In [12], the authors presented HRTC, a hybrid scheme for congestion control in WSNs. This scheme attempts to complement the resource control method with traffic control. The advantage of this hybrid solution lies on the fact that, due to the frequent variations that take place in WSNs topologies and node placements, each node is able to figure out which congestion control method is the most appropriate to apply at any moment, giving priority to resource control that extends network lifetime as well as throughput.
DDR [13] uses buffer occupancy as congestion metric and specifies a high threshold value for this metric. If the buffer occupancy is greater than the high threshold, the congestion notification bit will be set to one and it will use queuing theory to adjust the new transmission rate. Moreover, DDR calculates the hop count between each flow from source to sink and measures the reporting rate. It assigns low reporting rate to nodes which are located closer to sink.
In [14], the authors addressed the rate control and resource allocation problem for heterogeneous wireless sensor networks, which consist of diverse node types or modalities such as sensors and actuators and different tasks or applications. Each node calculates the source rate based on the aggregate price of capacity and energy along its path to the sink and constantly updates the data rate based on both the capacity and energy of the passing flows as well as from a feedback from the sink.
2.2. Alternative Path Selection Mechanisms
In [15], the authors proposed a new scheme called Siphon. Siphon uses special virtual sinks distributed in the whole network, which have more powerful radio than normal sensor nodes. When congestion is detected, sensor nodes will forward packets to near virtual sink and the virtual sink will forward the packets to real physical sink via other radio networks such as Wi-Fi. However, it needs another connected radio network which is infeasible in both low power and low cost consideration WSNs.
A new concept of routing protocol with congestion alleviation called Traffic-Aware Dynamic Routing (TADR) is proposed in [16]. TADR considers network traffic pattern as a “bowl” with sink residing at the bottom, and all data packets flow down just like water along the surface of the bowl. TADR uses combination of depth field force and queue length potential force to indicate which neighbor should be the next forwarder. Although TADR guides node to detour the congestion path, it has big chance to form one or more routing loops and increases the end-to-end delay.
LACAR [17] is a location aided congestion aware routing protocol which provides a proactive way to avoid congestion. LACAR uses buffer occupancy and average number of transmission attempts per successful transmission to detect congestion. It uses knowledge of each neighbor and sink node combined with congestion metric to route a path with less congestion and energy consumption. However, LACAR uses the knowledge of nodes’ location which is normally unavailable in WSNs. In [18], cross-layer congestion control optimal algorithms are presented for congestions occurred simultaneously at node-level and link-level in WSNs. Contention channels were reasonably allocated through the maximum spanning tree searching. The algorithms guaranteed data effective transmission, heavily highlight throughput, and maintain the energy consumption at low communication overhead.
Game theory can be used in researches to deal with the problem of congestion in wireless networks. In [19], the authors formulated the problem of congestion control using coalition game theory and propose a centralized assignment algorithm to dynamically assign Cell Access Nodes (CANs) to Access Points (APs) in wireless network and can achieve airtime-balancing Nash equilibrium. Also, they proved that the assignment algorithm terminates in a stable partition which attains optimal grand aggregate utility for the network. In [20], the authors presented a game theoretic model at the power control MAC layer of IEEE 802.11p for wireless transmission in network. For selfish and nonselfish nodes of unknown type, a Bayesian noncooperative game was formulated to model the decision making process of nodes to broadcast a beacon packet for the radio bandwidth in an incomplete information environment. They considered the proposed strategy as Bayesian Nash equilibrium, where the nodes transmit a beacon packet according to a channel gain based threshold based on power control.
3. Game Theory Based Congestion Control Protocol (GTCC)
In this paper, we prefer to mitigate congestion via alternative path selection mechanisms for the following reasons. The first one is that, in rate adjustment scheme, dropping packets are a common way to notify the source to reduce their packets generation rate. But in RPL, packets are usually fragmented so that dropping packets will cause entire packet retransmission. Moreover, the nodes in RPL networks usually have limited resources such as buffer size, which may degrade the performance of congestion control based on rate adjustment mechanism because the buffer of each node will be full quickly as transient packet burst. The second reason is for the consideration of maximizing the throughput and utilization. If we find another path with enough bandwidth toward sink, we can keep original transmission rate and get more throughput and utilization from alternative path scheme.
We propose the congestion control protocol GTCC in RPL. When congestion is detected by net packet flow rate, which is packet generation rate subtracted by packet service rate, nodes in congestion region will execute parent-change procedure based on game theory strategy in order to find another better parent to improve network throughput. To explain our protocol more explicitly, we first describe how RPL works. After that, we propose our congestion control protocol.
3.1. Congestion in RPL
In RPL, the network topology is a Destination Orientated Direct Acyclic Graph (DODAG). Each node will emit DODAG Information Object (DIO) packet to all its neighbors to maintain the network connectivity. The DIO packets are controlled by a polite gossip policy [3], where each node periodically broadcasts a DIO packet to local neighbors but stays quiet if it has recently heard a DIO packet sent by itself. The DIO packet includes RPLInstanceID which is a unique identity of the network, rank field which is the sender’s rank, and the option field which is used to store optional information such as objective function of RPL. The objective function is used to calculate the rank of nodes. In our protocol, we use the first bit of rank field as congestion notification bit (CN bit) and we will store the sending node’s children information, including their IP addresses and sending rates and the sending rates of the sender into the option field. When a node receives a DIO packet, it will use the objective function and the rank of the DIO sender to calculate an expected rank. If the expected rank is smaller than its current rank, the node will consider changing its parent to the DIO sender.
For example, we consider an RPL topology in Figure 1(a). We assume that the objective in this network is to minimize the hop count to the DODAG root. Thus, the rank of a node indicates the hop count between root node (indicated by ) and the node. When node receives DIO packets from nodes , , and , their corresponding hop counts (ranks) required to root are 3, 2, and 3, respectively. Thus, node will select node as its parent to get the minimal rank. For most applications in WSNs, traffic flow in a network is light for a long time until one of the predefined events occurs in the sensing region. When the source sensors begin to collect data, sensors in the region will start transmitting a large amount of packets. Once the packets number is large enough to form transient packet burst, it will possibly cause congestion on the path from source nodes toward the sink nodes. However, mitigating the congestion by reducing the rate of upstream node will violate fidelity level required by applications and decrease the throughput in RPL [16].
(a)
(b)
Our protocol will redirect the traffic flow to another path by parent-change procedure. In this procedure, nodes change their parents with maximum benefit such as less hop count, less buffer occupancy, or higher link quality. After that, the traffic flow will be scattered, this will improve the throughput of communication and reduce the packet dropping rate. For example in Figure 1(a), if node starts a long-term packet burst transmission, node will become a bottleneck for nodes and . In this case, nodes and will change their parents to nodes and , respectively, which can deliver their packets more quickly than node as shown in Figure 1(b).
3.2. The Proposed Protocol
Our GTCC protocol will redirect the traffic flow to another path by parent-change procedure. In this procedure, nodes change their parents with maximum benefit such as fewer hop count, smaller buffer occupancy, or higher link quality. After that, the traffic flow will be scattered. It will improve the throughput of communication and reduce the packet loss rate. In GTCC, each node will continue reading the CN bit in DIO packet from parent. On the other hand, we will try to find an alternative path to scatter the traffic flow when congestion is detected. Thus, our protocol combines advantages of both alternative path selection scheme and rate adjustment scheme.
In RPL network, DIO packets are used to maintain the network connectivity. Upon receiving a DIO packet, a node will save the sending rate and link quality into its neighbor table and check if the DIO sender is its parent. If the DIO packet is sent from its parent, the node will check the CN bit first. If the CN bit is clear, it means that there is no congestion and the child node will calculate its rank as regular. Otherwise, the child node knows that the congestion occurs on its parent. Therefore, all children nodes associated with the parent will use game theory based strategy to determine their new parents. If congestion cannot be mitigated through the parent-change procedure, each node will notify its children through the DIO packet with CN bit set and the congestion information will be broadcasted to all leaf nodes.
3.2.1. Congestion Detection Metrics
In recent congestion control protocols, several congestion detection metrics were proposed such as using dual buffer thresholds and weighted buffer difference for congestion detection [21], congestion detection by evaluation of channel loading [15], and computing different congestion levels based on the queue length evolution [22]. To evaluate the congestion in tree topology WSNs, a metric must be introduced to describe the occurrence and degree level of congestions so that we use the net packet flow rate which is packet generation rate subtracted by packet service rate as metric for detecting the presence of congestion on parent node. We define the congestion metric as follows:
In (1), the congestion metric is defined as the difference of packet generation rate and packet service rate . The value of can be treated as the buffer occupation growing rate. If is greater than , the probability of congestion is considerable. Conversely, if is less than or equals , the probability of congestion is low. In RPL standard [3], DIO packets can be used to disseminate the net packet flow rate. Furthermore, we assume that the period of DIO packet is small enough for information exchange in congestion control and we can use DIO packets to inform the presence of congestion to all the neighbors by adding a CN bit.
3.2.2. Rank Value of Nodes
The most important part of our protocol is to decide the rank value of each node in a DODAG network. The rank value can directly influence the network topology and the performance of network because each node will select a parent to minimize its rank value. Many metrics and constraints were studied to calculate the rank of a node such as energy state, hop count, expected transmission count, delay, and throughput. In our protocol, we use the link quality (LQ) of a candidate parent and the rank of the candidate parent to calculate the rank of a node :
RI is a constant which represents a rank increasing between a node and its parent. The rank increasing is used to prevent routing loop [3] and the value is varied by implementations. We set RI to 256 in our protocol. And is the rank of the candidate parent . is the link quality from node to node . Here, we use link quality indicator (LQI) of each received packet to measure the link quality between two communication nodes. We note that link quality distribution might not be homogeneous. Thus, when a node receives a packet from a sender, it will piggyback LQI of the received packet into its ACK message and send the packet back to the sender. By choosing LQ as the metric of rank calculation, we can get LQI directly from the received packet, which is computed in MAC layer by Received Signal Strength Indication (RSSI). Also, LQI cannot only detect congestion but also detect node failure or other unavailable status of node. As a result, the usage of LQI can help node to bypass congested and low performance paths. Considering the link quality and rank which are different metrics for rank computation, we use an LQ function to map the LQI to the scale of rank, LQ (LQI).
According to (2), a node’s rank depends on the rank of its candidate parent and the of the link from its candidate parent. Let denote the link quality indicator between nodes and . Considering a simple network topology of three nodes , , and in Figure 2, the expected direction of packet flow is from to . Node can directly connected to nodes and , and also node has a direct link to node . In general, node will choose node as its parent because of less hop count to sink than via and to sink. However, if the is much lower than and , the two-hop communication from to via may perform better than one-hop direct communication from to . So a threshold of LQI is necessary to estimate the current performance of link quality in real network. In order to find the threshold value of , we execute experiments in a testbed built by Octopus II sensor platform [23]. The experiment result is shown in Figure 3.
From the result of experiments, when the LQI value is larger than , the transmission time of 1000 packets (127 Bytes/packet) is about 15 seconds. However, the packet transmission time increases dramatically when LQI is less than . Moreover, the transmission time is double as the LQI is equal to . When LQI is smaller than , the transmission time is unacceptable. We notice that different hardware platforms have different value of , , and . According to (2), in the example above, if node wants to select node as its parent, the following equations must be hold: Thus, we have
In order to prevent ping-pong effect, we add a hysteresis loop from to in function to avoid the link quality oscillates around as shown in Figure 4. We set in our experiments.
Therefore, we have
When , we set . This is because if there is a two-hop communication with good link quality, we can eliminate a rank increasing with the two good links. When is between and or between and , we set value proportional to the transmission time of link quality as shown in Figure 4. When is below or equal to the value , we set value to . Thus, if the is less than , node can select node as its parent as long as and are greater than or equal to .
3.2.3. Parent-Change Procedure
In the above subsection, we have described our congestion detection method and rank calculation in RPL. When congestion is detected, each node in the congested area will start the parent-change procedure, although it does not mean that every node has to change their current parents. In parent-change procedure, each node uses the potential game theory method [6] to find a better parent to improve the network performance. Based on the potential game theory, we can converge to a stable state called Nash Equilibrium (NE) which is also the best parent allocation for whole nodes in the congested area. As we have discussed before, each node will select a parent which can minimize its rank. However, if too many nodes select the same parent, the load in this parent node will significantly increase to lead to congestion also. Thus, we can treat the behavior of parent selection as a game called parent-selection game. Parent-selection game is a game such that each player (node) attends a competition of parent selection to minimize its rank. In this game, the action (a node makes its decision of parent selection) of each node will affect other node’s utility (i.e., throughput). For example, in Figure 1(a), it is shown that nodes , , and are competing for parents , , and . If every node only considers the state of itself, they will select a same parent node because it has the least hop to the sink if all links have same link quality. However, if nodes , , and have lots of data packets for transmission, node is not capable of dealing with the large amount of packets and the congestion is inevitable. Thus, we will try to prevent this condition and maximize the network throughput by game theory based method. In the following, we will describe the mechanism of parent-selection game.
Our parent-change procedure starts with a parent node that sends a congestion message to its children through the DIO packet. In potential game theory, we can reach NE by restricting only one node that can change its parent with minimal utility in a time. We use a random timer to randomly diffuse the timing of changing parent of every node. When node changes its parent, it will broadcast a new DIO packet to notify other children and increase the rank of old parent by to avoid changing back to the old parent. We note that we can adjust the timer according to new metrics instead of random timer for better global effect because any changes on each node will affect the utility function, such that we can generate the shorter timer for nodes with higher transmission rates to reach NE faster.
3.2.4. Parent-Selection Game
In game theory, each player’s action will affect other player’s utility. The difficulty in finding an optimal action is that each player only knows about the utility of itself. Thus, nodes cannot know which selection is better for the global interest. Fortunately, as a subset of game theory, potential game theory can be used to deal with this problem. A game is a potential game if the incentive of all players to change their selection can be expressed using a single global function called the potential function [6]. With the aid of potential function, each node can determine whether a parent is worth changing or not by only considering its utility function. For the use of potential game, we will transform our parent-selection problem into a game representation and present the parent-change procedure. When congestion is detected by a node, it will set the CN bit in DIO packet, which contains the parent information, children list, corresponding transmission rate, and , and forward it to all its children. The children nodes receiving this message will consider changing parents according to the potential function. The potential function is built from information in neighbor table of each node, and the table will be updated upon the node which received DIO messages from its neighbors. Each node can use this potential function to find a new parent which can decrease the value of this function in each round toward NE according to two properties of potential game [6]. Property (1) is that the NE exists in each ordinal potential game. Property (2) is that if we limit only one node that can change its parent at a time, we can converge to NE.
We define the parent-selection game as , where is the set of players, is the set of actions, and is the utility function set. For each player , we defined the following terms.
(1) Player Set . The player set is defined as all children nodes of the DIO sender. We denote player set as . The set contains children.
(2) Parent Set . The parent set of is defined as all neighbors of player whose ranks are less than . We denote parent set as if there are parents for player . is the union of parents of the children, assuming .
(3) Action Set . The action set is composed of any possible actions of each player. For player , is used to represent the parent selection decision of , where . For instance, represents that node chooses node as its parent. The action set of this game is defined as . Therefore, each element in is matrix which shows the decision of every player in . Thus, means that player selects parent as parent in action . Noting that if , will be 0.
(4) Utility Function . For player , utility function is defined as . The utility function is used to represent how much does node cost to reach sink node for action . We use the cost to describe the utility because the cost to reach sink node is most important fact for transmission of relay nodes on one hand, not only for single node but also for network as a whole. We can get better transmission performance by decreasing the cost of transmission. On the other hand, we can use the cost of a node to sink node to evaluate the benefit of a node in networks by game theory. For example, if a node selects it parent by evaluation of cost, it will affect the selection of other nodes by game theory. Thus, the smaller the value of utility is, the lower the cost and the higher the efficiency the transmission is. We define utility function of player with action as where is the parent candidate of player (), is the link quality between nodes and , and is the number of children of parent . The utility function of player is composed of four terms: rank increase per hop, link quality between nodes and , rank of , and the sum of packet transmission rate of all children of . In utility function (6), we consider the rank of candidate parent and transmission rate of each child associating with . Hence, the utility function is able to reflect the load of a candidate parent. Noting that we multiply to the transmission rate of node () is to balance the number of children in each parent node. This is because selecting a parent with high will increase the cost of utility function quickly. The LQ function is defined in (5) and the transmission rate function is defined in where is the packet delivery rate and is the maximum packet delivery rate of each node. When a node reaches its maximum rate, it will not be able to handle more data packet. Thus, we let the rate function be equal to when it reaches the maximum packet delivery rate. This will lead nodes to select other parents when the load of the candidate parent is satisfied.
An example is shown in Figure 5. For node , the player set is , , and , where and represent that node can selects nodes and as parents, respectively. We assume that the maximum packet rate of each node is 20, the packet rates of nodes , , , and are 5, 5, 2, and 3, respectively, value of link to is −128, and rank of node is 200. The utility of node when it selects node as parent is , according to (6) and (7).
A game is an ordinal potential game if it admits an ordinal potential function. A function is an ordinal potential for if for every and for every , where and the condition in (8) is satisfied, where is the action without player (i.e., ):
We define our ordinal potential function as the following equation and prove that it will satisfy (8) in Theorem 1:where . The potential function is able to reflect the global interest in a network. In (9), the potential function contains the rank of each node’s parent, link quality between parent and its children, and the packet rate of each child multiplied by the number of children in its parent.
Theorem 1. The parent-selection game is an ordinal potential game with ordinal potential function .
Proof. We need to prove that is a potential function in parent-selection game which satisfies (8). Assuming that a player changes its parent to from , it makes the action changes to from . The difference of utility function is Then the difference of potential function isLet . ConsiderBecause only node changed its parent from to , we can only consider the columns and in and , respectively. Thus, the number of children of in is one less than that in action and the number of children of in is one more than that in action . Thus, we have and , and (12) can be deduced as follows:So .
Theorem 1 shows that our parent-selection game is an ordinal potential game. Thus, we can reach NE by each node changing its parent with minimal utility in a time.
We will give an example of how the parent-selection game works. Figure 6(a) shows the network topology including rank (numbers besides node ID), link (arrows between two nodes), and packet rate (numbers in the block) of each node before the congestion happened. We assume the link quality of all links is larger than which means that the is a constant of 128. We assume some events detected by node 7 and the packet rate of node 7 increases to 20 as shown in Figure 6(b). Assume the maximum packet rate of each node is 20. The net packet flow rate of node 3 will be equal to and the congestion is detected.
(a)
(b)
Thus, node 3 emits DIO with CN bit set. When the children of node 3 receive the DIO packet, they will start changing parent with random timer. We assume that the generated timer for nodes 6, 7, and 8 is 3, 5, and 8, respectively. Node 6 will change its parent first. The original utility of node 6 is 768, . To minimize the utility of node 6, we will change its parent to node 5 and decrease its utility to 448. After that, node 6 will emit a new DIO to notify its neighbor. Then the utility of node 7 is decreasing to 832 from 1152. Node 7 will select node 9 as its parent which will decrease its utility to 640. After node 7 changed its parent to node 9, node 8 will not change its parent because it is already in NE and congestion is alleviated. The final topology is shown in Figure 7.
3.2.5. Rate-Reduction Mechanism
When congestion occurs, the congested parents will use DIO packet with CN bit set to notify their children to invoke the parent-change procedure. As every child is already in NE, the congestion will be alleviated. If congestion is not mitigated after the parent-change scheme, the children of the congested parent will start the procedure of rate-reduction to reduce the packet rate. We illustrate the packet flow in Figure 8.
The packet generation rate of a node is composed of the packet rate of itself, which the current node serves as a source node and the packet rate from its children, which the current node serves as a relay node. In rate-reduction procedure, a child reduces its packet rate multiplied by the value of reduction rate where is the packet output rate. If there is no congestion occurs, the output packet is equal to the sum of source packet and the relay packet, in other words, . However, in most congestion scenarios, the output packets of a relay node come from relay transmission, so that the transmission packets of output are approximately equal to the relay packets that means . In the rate-reduction scheme, we want to reserve the bandwidth of the packet rate and reduce the packet rate . Thus, we can limit the total packet rate of children to .
We can give an example by Figure 5. Assume the packet rates of nodes , , , and are all 5 and and of node are 4 and 20, respectively. We can calculate the reduction rate as After the rate reduction computation, the packet rates of nodes , , , and are reduced to 4. So we can keep the packet rate of node .
4. Performance Evaluation
In the related works, there are no researches with congestion mechanism in RPL and also they do not aim at tree-like network topology. Thus, we compare the performance of our proposed protocol to ContikiRPL with OF0 and OF-ETX denoted as CRPL-OF0 and CRPL-OF-ETX [8]. The rank of each node in CRPL-OF0 and CRPL-OF-ETX is calculated by the metric of hop count and expected transmission times from source to sink, respectively. We evaluate the performance of each protocol on throughput, packet loss rate, and average hop count by Cooja simulation tool [7] in Contiki system. Cooja is a cross-level sensor simulator. Unlike NS-2 and other simulators, a node in Cooja is actually compiled and executing in Contiki. Thus, we can actually simulate every instruction in every node of our implementation.
4.1. Simulations without Parent Change Procedure
Nodes in simulation are categorized into three types: sink node, relay nodes, and sensing nodes. Sink node is the root node in RPL which collects sensing data, relay nodes are used to relay data to the sink node, and sensing nodes are responsible to sensing the environmental data within its sensing area. To evaluate our proposed protocol more explicit and intuitionistic, especially in our rate-reduction mechanism, we assume that the relay nods relay transmission only but do not generate sensing data. There is no parent changing mechanism in RPL, so we first evaluate the performance of our protocol without parent changing comparing to CRPL-OF0 and CRPL-OF-ETX. In this scenario, we put the sink node in the center of 150 m × 150 m area and randomly deploy nine relay nodes and ten sensing nodes. We send two packets per second with packet size of 100 bytes. In our protocol GTCC, we set , , and according to our rank calculation design. We evaluate our protocol, CRPL-OF0 and CRPL-OF-ETX, by packet loss rate under different standard derivation. The result is shown in Figure 9.
The packet loss rate of CRPL-OF0 increases continuously when the standard derivation of link qualities grows. This is because the large standard derivation of link qualities will lead the packet loss rate of direct link to sink to increase. CRPL-OF0 tends to select the least hop count to the sink so its packet loss rate is greater than others. The packet loss rates in CRPL-OF-ETX and GTCC are both under 0.3 for all standard derivation of link qualities. This is because they try to find another path when link quality is low, but our rank calculation scheme can avoid adding a parent with low quality link whose link quality is less than , by detouring to another parent with link quality greater than . Thus, our protocol outperforms CRPL-OF0 and CRPL-OF-ETX.
4.2. Simulation with Parent Change Procedure
We evaluate the performance of our protocol by two scenarios in simulations with parent change procedure and their nodes deployments are shown in Figure 10. In scenario 1, we deploy the sink node in the center of the sensing area to collect data. Each sensing node has one or two parents. In scenario 2, we deploy the sink node in the top of the sensing area to evaluate the effect of sensing nodes with three or four parents. We use Unit Disk Graph Medium (UDGM) with distance lose module as radio interference. The success rate of transmission in UDGM module decreases as distance increasing. We set our packet size to 100 bytes to avoid packet fragmentation. This is because there is no retransmission mechanism in Contiki and it will cause entire packet retransmission even if only one fragment is lost. The area size is 220 m × 220 m, simulation time is 200 seconds, radio range is 50 m, and the numbers of nodes are 26 and 22 in scenarios 1 and 2, respectively.
(a)
(b)
Our metrics for performance comparison are the average packet loss rate, average throughput, and average hop count. The average packet loss rate is the ratio of total number of data packets lost to total number of data sent from sensing nodes. To measure the average packet loss rate, we simulate different transmission rates ranged from 2.5 to 18.2 packets per second for the above metrics. In order to evaluate the maximum throughput, we evaluate GTCC with or without Rate Reduction (RR) scheme in our simulations. Moreover, for fairly evaluating the performance of GTCC and ContikiRPL protocols, we set the link quality of all links to values above in the following simulation. In the following simulations, we can reach NE by no more than 13 times of parent changing.
In Figure 11, the packet loss rate of our protocol is less than 25% while the loss rates of CRPL-OF0 and CRPL-OF-ETX are both higher than 57% when the packet transmission rate of each node is equal to 10. When the transmission rate of node grows, the loss rates of CRPL-OF0 and CRPL-OF-ETX are significantly increasing. This is because nodes in CRPL-OF0 and CRPL-OF-ETX tend to select parent with fewer hop count to the sink. As the transmission rate grows, there are too many packets injected into the same candidate parent nodes than they can afford. On the other hand, nodes in our protocol can change their parents to keep the global load balance and avoid congested path, so that the lower loss rates are achieved. In addition, we enable the rate reduction mechanism to restrict the transmission rate of each node to 7.5 packets per second that will reduce the packet loss rate to below 20%.
Figure 12 shows the throughput with different packet transmission rates. When the transmission rate of each node grows, the throughput of our protocol is two times better than CRPL-OF0 and CRPL-OF-ETX. Moreover, the peak throughput of CRPL-OF0 and CRPL-OF-ETX is around 7.5 packets per second, and the peak throughput indicates the maximum packet flow that network can carry. The peak throughput can extend to 10 packets per second in our protocol. Also, the throughput of GTCC with RR is lower than GTCC without RR.
In Figure 10 of scenario 2, sensing nodes (7–10 and 16–18) are located in the bottom of the sensing area. There are seven nodes (11, 13, 15, 19, and 21–23) that can be chosen as the parents of the sensing nodes. Since nodes 15, 19, and 23 have the less hop count to sink, this will make nodes 15, 19, and 23 become hotspots and congestion will occur in high probability in ContikiRPL protocols. However, our protocol can avoid the congested path and outperforms CRPL-OF0 and CRPL-OF-ETX.
In Figure 13, it is shown that GTCC reduces packet loss rate more than 20% compared to CRPL-OF0 and CRPL-OF-ETX with various transmission rates. For transmission rate being 5 packets per second, the packet loss rates of CRPL-OF0 and CRPL-OF-ETX are both near 50% while GTCC is 20% because the sensing nodes in ContikiRPL protocols are selecting nodes 15, 19, and 23 as parent nodes; even there are other available candidate parents. Thus, we can notice that GTCC can take advantage of changing parent and mitigate the congestion. Furthermore, GTCC with RR scheme can restrict the transmission rate to 7.5 packets per second which have lower packet loss rate than other protocols.
In Figure 14, it is shown that the average throughputs of CRPL-OF0 and CRPL-OF-ETX are almost fixed as the packet transmission rate grows because of packet congestion. On the other hand, GTCC is 2.5 times better than CRPL-OF0 and CRPL-OF-ETX in scenario 2. Although GTCC with RR scheme can reduce packet loss rate, it degrades the throughput to some extent too. Also, we can notice that the throughput of GTCC with RR is lowest although the gap is small enough, because, in the scenario 2, the sink is in the most edge far away from center of WSN, in other words, it is a most ultimate condition of implementation. By contrast, the other most ultimate condition is described in scenario 1, where the sink node is the center of all nodes. We can expect and evaluate that the throughput of GTCC with RR in normal scenarios between two most ultimate conditions will be distributed between the lowest one in Figure 14 and better one in Figure 12.
In Figure 15, the average hop count to the sink in our protocol is 2.6 and 4.6 in scenarios 1 and 2, respectively. It is a little higher than CRPL-OF0. But, our protocol can achieve higher throughput and less packet loss rate. Finally, we can see that CRPL-OF-ETX has the largest hop count among all protocols in scenario 1 because nodes are easily changing their parents to the ones which have longer hops than original parents to the sink in case of congestion happened.
5. Conclusions
In traditional congestion control scheme, rate reducing mechanisms are used to mitigate the presence of congestion. However, rate reducing will degrade the throughput and lose the fidelity of application’s request. Instead of alleviating the congestion only by reduction the rate of transmission, we try to find another scheme based on game theory to improve the throughput. In this paper, we propose a novel congestion control protocol based on game theory over RPL to maximize the throughput. Our protocol exploits a parent selection scheme which can improve the throughput of communications. When congestion occurred, nodes will change their parents according to the utility function in game theory to avoid the congested path. If congestion is not alleviated, we conduct a rate reduction mechanism to reduce the transmission rate of source nodes. We implement our protocol in Contiki OS and evaluate the performance via simulator Cooja. It is shown that our protocol has two times improvement in throughput and less packet loss rate compared to ContikiRPL protocols with a little average hop count increasing to sink node. Furthermore, GTCC with RR schemes has two times improvement in packet loss rate and 25% degrade in throughput compared by GTCC without RR.
Conflict of Interests
The authors declare that there is no conflict of interests regarding the publication of this paper.