1. Introduction
In 1999, the term “Internet of Things”, abbreviated as IoT, was introduced to the world for the first time by the British computer scientist Kevin Ashton [1]. Ever since then, IoT has been a buzzword which is driving academic and industrial attention alike. Now, with the huge number and types of devices connected to the IoT, it has become an inevitable part of all walks of life [2]. Devices connected in the IoT, referred as nodes, are constrained in memory, processing, and power. Also, they operate in lossy networks with narrow bandwidth. These special characteristics can often cause low throughput and large packet errors. IETF has been focusing on deriving protocols suitable for such environments. Their contributions include constrained application protocol (CoAP) [3], routing protocol for low power lossy network (RPL) [4], IPv6 over low power wireless personal area network (6LoWPAN) [5].
Congestion is an undesired event when the node or link propagates more packets than it can handle. Considering the constrained capacities of nodes and networks, congestion is a critical problem in IoT. In general, constrained devices in IoT networks exchange small amounts of data periodically. When many such devices interact simultaneously, demand of resources exceeds its availability and results in congestion. Consequences of congestion are packet drop from buffer, increased queuing delay, decreased throughput etc. [6]. Therefore, congestion control (CC) technique is necessarily deployed to detect and reduce congestion.
CoAP is one of the promising UDP based application layer protocols for IoT. When reliability is required by the application, CoAP includes confirmable message and acknowledgement. When the ACK is not received at the application layer in stipulated time, the CC method is triggered. Therefore, the waiting time for the ACK, referred to as retransmission time out (RTO), needs to be known at the application layer [7].
A static value of RTO is insufficient for catering to the needs of the dynamics of the network. Instead, deriving an RTO, aligned with the congestion level of the network, ought to be introduced in CoAP [8]. The attributes which signal the congestion level need to be introduced to make the RTO more responsive and accurate. However, tracking, computation and storing of attributes that signal congestion shall not overhead the constrained nodes.
The default CC method in CoAP computes RTO using binary exponential backoff (BEB). The simplicity of this method also has a downside that RTO is insensitive to congestion in the network. Such insensitivity can result in small RTOs at high congestion levels and large RTOs at low congestion levels [9]. This in turn makes the node inappropriately aggressive and conservative. Hence the default CC method is inefficient to deliver data promptly to the server node. As a consequence, the efficiency of many crucial monitoring applications in health care, disaster management, pollution tracking etc. can be adversely impacted.
CoAP simple congestion control/advanced (COCOA) is the most popular alternative proposed [9] and later revised [10]. Round trip time (RTT) is used to compute RTO by means of exponential weighted moving average method (EWMA). RTT samples computed from packets delivered with and without retransmissions result in two types of RTT: namely weak RTT and strong RTT. Each of them is used to derive weak RTO and strong RTO respectively. The overall RTO estimate of COCOA is updated when either weak RTO or strong RTO is updated.
Both RTT and its type are indicators of congestion level. Increase in RTT indicates an increase in congestion and vice versa. Similarly, the type of RTT samples shows if sender runs into retransmission, which implies whether congestion being built up in the network. Therefore, both RTT and type of RTT help to derive RTO sensitive to congestion. Many evaluations show that COCOA outperforms the default CC method in CoAP [9], [10].
However, on the other hand, the constant weight values in the EWMA based RTO estimation create concern about the performance. The constant weight values always make the current sample contribute the same share irrespective of changes in the congestion. This causes a delay in fluctuating RTO sensitively. Weight values in the RTO estimations can also contribute to the effectiveness of COCOA if they are network sensitive. Therefore, the idea of adaptive weight value setting in RTO estimation should be examined.
In this paper, we propose a novel approach called Flexi COCOA, for computing RTOs using adaptive weight value for strong RTO. We show that the proposed method is more effective than COCOA to derive better RTO, more packet transmissions, and less retransmissions for periodic data transfer nodes. The main contributions of this paper are as follows.
-
We introduce, to our knowledge, the first method of considering ratio of RTTs as measure for the weight value estimation of strong RTO.
-
The proposed method is implemented in Contiki Operating System with minimal changes in COCOA algorithm.
-
We demonstrate the effectiveness of the proposed method on Cooja simulator.
The rest of the paper is organized as follows. We describe the details of CoAP in Sect. 2 and related work in Sect. 3. The proposed method is presented in Sect. 4. Details about evaluation and results are presented in Sect. 5. We conclude this paper with future research directions in Sect. 6.
2. CoAP Protocol
CoAP [3] is designed to be a lightweight application layer protocol adhering to request-response model following representational state transfer (REST) architecture. Requests are originated by the client and destined to the server. On receiving a request, server originates responses that are destined to the client. Therefore, for the CoAP messaging model, in the context of requests, client and server are sender and receiver respectively. Similarly, for response, server and client are sender and receiver respectively. Like HTTP, CoAP uses the methods such as GET, POST, PUT and DELETE to access or manipulate resources on the server. Four message types are defined by this protocol; namely non-confirmable (NON), confirmable (CON), reset (RST) and acknowledgment (ACK).
NON request message is used when reliability is not expected via acknowledgments. CON request messages are always coupled with ACK messages from the receiver and hence provide reliability. Message id helps to match CON message and ACK message. Sender can attempt, by default, up to four retransmission attempts if ACK is not received in stipulated time. This waiting time is derived by an RTO estimator of the CC method. A conservative restriction is set on sender to have only one request per destination to have no ACK received yet. When the message is received in error, the receiver replies with RST.
RFC 7252 [3] suggests a trivial default CC method of CoAP. A random RTO is chosen from [\(2, 3\)] seconds for every new CON transmission. A timer starts at the sender to follow RTO. If the timer expires and ACK is not received, then a packet loss is assumed. The sender attempts retransmission of the same packet, after BEB is applied to RTO. BEB is applied on RTO to double its value for each retransmission as shown in Eq. (1).
| \[\begin{equation*} RTO_\text{current}= RTO_\text{previous} \times 2. \tag{1} \end{equation*}\] |
The advantage of default CC is that there is no need to manage information about the end-to-end data transfer. However, the simplicity of the default method also results in a serious drawback. Computation of RTO does not keep track of congestion in the network. Therefore, an estimated RTO may become an overestimate or underestimate. In case of an underestimated value, the sender spuriously transmits packets into the constrained network, worsening the congestion. An overestimated value makes the sender transmit less packets and underutilize resources. Consequently, a network sensitive algorithm is necessary.
3. Related Work
COCOA is a network sensitive end-to-end CC technique for CoAP message transmission. The first version of COCOA is presented in [9]. COCOA+ [10] is the latest version with minor improvements on [9]. Henceforth, we use the word COCOA instead of COCOA+. In this section, we present the working of COCOA algorithm and different enhancements on COCOA.
3.1 Congestion Control in COCOA
COCOA [10] is an improvement over the default CC method of CoAP by associating RTT value with RTO computation. It follows the principles of the Karn-Patridge algorithm [11] as in TCP, to estimate RTO from RTT. TCP assumes packet loss is caused by network congestion and for this reason ignores RTT samples of retransmitted packets. However, packet loss is expected in lossy network by high bit error rate (BER) also. Therefore, COCOA pays attention to retransmitted packets.
RTT sample of the packet which is acknowledged without retransmission is called strong RTT and that with retransmission is called weak RTT. Strong RTO is computed from strong RTT, and weak RTO is computed from weak RTT. A precise mapping of whether the ACK corresponds to original CON message or retransmitted copy, is not possible. Therefore, the number of retransmissions in weak RTT measurement is limited to two. Further retransmissions, if any, are avoided in estimation to reduce the precision error.
For each CoAP receiver, a CoAP sender needs to maintain two types of state variables for all the related measures as well. When a strong or weak RTT is measured, the corresponding estimator gets updated. Let \(rtt\) and \(x\) denote the RTT value measured and the type of RTT respectively. Smoothed \(RTT\), smoothed variance of \(RTT(RTVAR)\), and \(RTO\) are updated as follows.
| \[\begin{eqnarray*} &&\!\!\!\!\! RTT_{x} = (1-\alpha) \times RTT_{x} + \alpha \times rtt \tag{2} \\ &&\!\!\!\!\! RTVAR_{x}= (1-\beta) \times RTVAR_{x} + \beta \times \lvert RTT_{x} - rtt \rvert \tag{3} \\ &&\!\!\!\!\! RTO_{x} = RTT_{x} + K_{x} \times RTVAR_{x} \tag{4} \end{eqnarray*}\] |
COCOA follows the recommendation of RFC 6298 [12] to assign the value of \(\alpha\), \(\beta\) and \(K_{strong}\) as \(0.125\), \(0.25\) and \(4\) respectively. The value of \(K_{weak}\) is assigned to be \(1\) to reduce the inaccuracy from ambiguity issues. New RTO is calculated as given below, with \(weight_{strong}\) as \(0.5\) and for \(weight_{weak}\) as \(0.25\).
| \[\begin{equation*} RTO_{new}=weight_{x} \times RTO_{x} +(1- weight_{x}) \times RTO_{new} \tag{5} \end{equation*}\] |
Using a dithering technique, initial RTO for the next transmission, RTO\(_{init}\), is selected from RTO\(_{new}\).
| \[\begin{equation*} RTO_{init} = [ RTO_{new}, 1.5 \times RTO_{new}] \tag{6} \end{equation*}\] |
In case of retransmissions, COCOA considers a variable backoff mechanism (VBF) to calculate new RTO value, RTO\(_{current}\).
| \[\begin{equation*} RTO_{current} = RTO_{previous}\times VBF \tag{7} \end{equation*}\] |
This is to control the RTO value becoming smaller or larger. VBF is 3 if RTO\(_{init}\) is less than \(1\) second, and it is \(1.3\) when RTO\(_{init}\) greater than \(3\) seconds. Otherwise VBF is \(2\), which is normal BEB.
COCOA also introduces a mechanism to age the estimations in case RTT samples are not available for a certain duration. Motivation is that, in a lossy environment, it is normal not to get samples for a long period and the past values become stale. Therefore, the aging mechanism is required to converge the estimation into default values.
In general, COCOA incorporates congestion level indicators such as RTT, variation in RTT and retransmissions for RTO computation. Therefore, COCOA is advantageous over the default CC method, with the ability to adjust RTO dynamically to network changes. Evaluations in [9], [10] and [13] compare COCOA against default CoAP.
3.2 Varaints of COCOA
Multiple solutions are available to address different deficiencies of COCOA [14]-[29]. We summarize them in Table 1. Most of the methods in Table 1 depend on constant weight values for RTO estimation. COCOA suffers from a critical drawback due to the constant weight values used in the RTO computation. Irrespective of the network dynamics, constant weight values force the current RTT sample to always contribute identically. This can slow down the fluctuation of RTO and thereby affect the data delivery of periodic monitoring applications. Thus, a network sensitive weight value is necessary to accelerate the RTO fluctuation. Our analysis about existing solutions addressing the constant weight problem is given below.
Table 1 Summary of COCOA variants. |
 |
AdCOCOA [21] suggests all parameters being dynamic. Weak RTO estimator is eliminated in AdCOCOA; however weak RTT samples are considered. The difference between smoothed RTT and current RTT is taken as an indication of network status and is used to derive the multipliers for scaling the parameters. Results show that lower RTO and higher packet sending rate with lesser retransmissions are achieved. When the RTT is measured after retransmissions, the scaling factors can grow larger at once. Therefore, a larger RTO results which further can cause long idle period. Bounding of scaling factor is important in this aspect; however it is not included. CoAP recommends keeping message overhead small, thus limiting the need for fragmentation at lower layers. Fragmentation reduces the probability of packet delivery. Loss or delay of even a single fragment can eventually cause the original CON packet to be resent. In the constrained environment, such retransmissions induce additional traffic that may worsen congestion level of the network. It is noteworthy that layer 2 packet size is limited to \(127\) bytes by 6LoWPAN [5]. A payload must fit into a single 6LoWPAN frame to avoid fragmentation. Simulation parameters in AdCOCOA shows that the packet size used in the experiments is \(1010\) bytes. Such a packet size can cause fragmentation problems at 6LoWPAN. Therefore, block-wise trasnsfer method would be opted for larger packet size.
mlCOCOA [24] estimates parameters using support vector machine (SVM) based on client number, packet size and packet delivery ratio. The predicted values are used in the COCOA in place of their default values. mlCOCOA achieves higher throughput in comparison to CoAP and COCOA. A major drawback of mlCOCOA is that it demands clients with plentiful resources and hence not suitable for constrained devices. Prediction based on client number also raises questions. In case an expected node does not participate in RPL due to error, or power outage or mobility, the predicted values may not be suitable for the network. Also, the learning phase from the training set is static. This can be different from dynamic evaluations.
GSRTC [26] enhances COCOA in lossless network conditions. GSRTC derives a geometric series based weight for strong RTO. Weight value is updated on each consecutive strong RTT. When a strong RTT sample is obtained, \(weight_{strong}\) is derived from Eq. (8).
| \[\begin{equation*} weight_{new}=weight_{prev} +(\frac{1}{2}) ^{count} \tag{8} \end{equation*}\] |
\(weight_{new}\) is used as \(weight_{strong}\) in Eq. (5), \(weight_{prev}\) denotes the weight obtained from the previous strong RTT sample and \(count\) indicates count of consecutive strong RTT samples. When a weak RTT sample is acquired, GSRTC adopts the Fullbackoff2 variant of COCOA [17]. With Fullbackoff2, GSRTC selects RTO for the subsequent transmission as maximum among backed off RTO and \(RTO_{new}\). Furthermore, \(weight_{prev}\) and \(count\) are reset to \(0\) resulting in an aggressive reduction of \(weight_{strong}\).
GSRTC achieves better flow completion time, better throughput, and lower number of retransmissions in the performance evaluation. Consecutive strong RTT samples are mandatory for GSRTC to improve over COCOA. A constrained network cannot guarantee consecutive strong RTT samples. Aggressive increase of weight value is exhibited by GSRTC whenever it receives consecutive strong RTT samples. As a result, RTO value becomes smaller quickly and cause a larger number of packets to reach the network in a short span of time. This can cause overhead in constrained nodes. Another drawback is the quick reduction of \(weight_{strong}\) when a weak RTT is received. Since packet collisions can also result in weak RTT, a quick reduction of weight value may overestimate the congestion level of the network. Such an approach can degrade the rate of RTO fluctuation.
In general, existing solutions addressing the constant weight value problem achieve better performance than COCOA. However, each of such solutions compromise the general characteristics of data transfer for constrained nodes outlined in [3], such as small payload size, resource bounded devices or lossy network conditions. Therefore, a new solution, adhering to the general characteristics, needs to be developed.
4. Proposed Method
In this paper, we propose Flexi COCOA through its motivation, overview, algorithm, and an illustration of a sample client-server interaction.
4.1 Motivation
In [9], the authors indicate about improving the performance of COCOA using adaptive parameter setting having tradeoff with complexity. COCOA algorithm makes use of many constant parameter values such as \(\alpha\), \(\beta\), \(K_{strong}\), \(K_{weak}\), \(weight_{strong}\) and \(weight_{weak}\). However, the contribution of COCOA is confined only to \(K_{weak}\), \(weight_{weak}\) and \(weight_{strong}\). The rest of the values are inherited from TCP. We aim at improving the parameters contributed by COCOA. The accuracy of weak RTT is a hindrance for making \(K_{weak}\) and \(weight_{weak}\) to be adaptive. Modification of \(K_{weak}\) and \(weight_{weak}\) is improper without addressing the precision of the weak RTT sample. Our analysis, thus, focuses on improving the weight associated with strong RTT sample, \(weight_{strong}\).
4.2 Overview
Flexi COCOA enhances the RTO computation of COCOA by flexible weight derived using strong RTT samples. Gradual adjustment of weight is favored in Flexi COCOA to prevent overreactions such as those seen in GSRTC. Upon receiving a strong RTT sample, Flexi COCOA analyzes the trend in their count and revises the weight value accordingly. The revised weight aims to reduce transmission delay proportional to the number of packet losses.
The core idea is to increase and decrease the weight value of RTO\(_{strong}\) in Eq. (5) gradually based on the count of strong RTT samples to achieve faster RTO adaptation than COCOA. An increase in the count of strong RTT samples always signals less congestion. Therefore, weight value should be increased to provide more weightage to RTO\(_{strong}\) and produce small RTO for subsequent transmission. A gradual increase is preferable to prevent spurious transmissions. A decrease in the count of strong RTT samples can be caused by congestion, bit errors, or both. Flexi COCOA, like other COCOA variants, doesn’t engage with lower layers of the protocol stack to identify packet loss causes, to preserve the lightweight application layer. While a reduction in weight value is necessary, resetting the weight value to a pre-determined constant value is improper as the cause of loss is unidentified. Therefore, a gradual weight reduction is preferred for RTO\(_{strong}\) to prevent overestimation of RTO.
A network sensitive weight value thus requires incorporating strong RTT samples observed, to incorporate fluctuation of congestion, and evolving cautiously. Therefore, we define weight value as the ratio between count of strong RTT samples and count of total RTT samples. The proposed weight value speeds up RTO convergence to the actual RTT compared to COCOA. This modification addresses transmission delay relative to the number of packets experiencing timeout retransmission. The advantage of such an RTO convergence is vital when strong RTT samples are collected after a weak RTT sets RTO to be large value. At any point in time, the proposed weight value is dynamic and considers the overall performance of client-server message exchange rather than that of a brief time.
Flexi COCOA makes minimal changes to the standard COCOA. Hence, resourceful devices are not a necessary requirement for the implementation of Flexi COCOA. Also, any stringent condition such as consecutive strong RTT samples is not mandated by Flexi COCOA to deliver desired performance.
4.3 Algorithm
Algorithm 1 shows the functioning of Flexi COCOA. Flexi COCOA is prevented from updating default COCOA weight, \(0.5\), for the first strong RTT sample for a cautious start-up of packet transmission. We introduce two new variables to the existing COCOA method: count_RTT and count_SRTT. count_RTT monitors aggregate count of RTT samples regardless of their type and count_SRTT exclusively monitors count of strong RTT samples. Both are initialized as zero.
 |
count_RTT is updated for each RTT sample as shown in line 6 of the algorithm. When a weak RTT sample is collected, the proposed method inherits the weight value of \(0.25\) from COCOA. If the RTT sample is identified as strong RTT, count_SRTT is updated by the algorithm in line 12. For every strong RTT sample, the weight value is revised as the fraction of count_SRTT over count_RTT as in line 13 of the algorithm. We bound the value of this weight as, \(0 <\textit{ weight}<1\), at any instance. Lines 15 to 18 of the algorithm correspond identically to Eq. (2) through Eq. (5). The revised weight value provides flexible weightage to RTO\(_{strong}\), while computing RTO\(_{new}\) as in line 18 of the algorithm. count_RTT and count_SRTT are reset to initialization if RTO value is reset to default initial value by invoking RTO aging technique. Flexi COCOA relies on VBF of COCOA to compute RTO value for retransmission as per Eq. (7).
COCOA, with constant weight, fluctuates the RTO at a steady rate. This can cause transmission delay. RTO adaptation using the network sensitive weight value of the proposed method can impact transmission delay in the following ways. Weight value in line 13 increases as the count of strong RTT sample increases. As a result, RTO\(_{strong}\) gains more weightage in line 18. RTO\(_{new}\), derived with such higher weightage on RTO\(_{strong}\), approaches to actual RTT faster than RTO\(_{new}\) from COCOA.
On the contrary, weak RTT sample normally sets theRTO\(_{new}\) to be large. Flexi COCOA benefits from adaptive weight value, when strong RTT samples are received after weak RTT sample. If weak RTT sample was a result of congestion, receiving strong RTT samples afterwards can be seen as an improvement in congestion. If weak RTT sample was caused by collision, receiving strong RTT samples afterwards shall address the overly setRTO\(_{new}\) by the weak RTT sample. In both cases, a faster convergence of RTO to RTT is the reaction required from the CC algorithm. Flexi COCOA exhibits faster RTO convergence compared to COCOA until it reaches a weight of \(0.5\), which is the weight used in COCOA. Weight value of Flexi COCOA remains larger than \(0.5\), until the count of weak RTT samples surpasses the count of strong RTT samples.
By offering accelerated RTO convergence, Flexi COCOA addresses transmission delay better than COCOA. As a result, clients can transmit a greater number of request packets in comparison to COCOA. During periods of severe congestion, the likelihood of obtaining a strong RTT sample is minimal, leading to a higher count of weak RTT samples compared to strong RTT samples. This can hinder the efficacy of Flexi COCOA. However, during periods of severe congestion, minimizing transmission delays may not be a significant concern. In such cases, the effectiveness of Flexi COCOA may not be a critical factor.
GSRTC [26] is a comparable solution to Flexi COCOA, as it adapts the weightage of RTO\(_{strong}\) based on strong RTT samples. GSRTC incorporates network dynamics exclusively from the lossless duration and therefore Eq. (8) aggressively boosts the weight of GSRTC to reduce RTO rapidly. Such an RTO reduction can lead to spurious transmissions. The weight updating process in Flexi COCOA progresses gradually, as instances of losses also impact the weight through denominator of the fraction in line 13 of Algorithm 1. This helps prevent spurious transmissions compared to GSRTC. Upon receiving a strong RTT sample after a weak RTT sample, GSRTC consistently resets the weight to \(0.5\). In such situations GSRTC is only capable of delivering RTO convergence rate equivalent to that of COCOA. In a comparable scenario, Flexi COCOA delivers superior performance than GSRTC. The weight value of Flexi COCOA may reach \(0.5\) only in congested periods where the speed of convergence is not a significant factor.
4.4 Illustration
We illustrate the weight updating using Flexi COCOA with the help of sample client-server interaction. Referring to Fig. 1, a client sends CON message to server and server sends back ACK message. The client receives ACK without retransmission for all packets except the second and sixth. Second and sixth packet attempted retransmissions and receive ACK. Therefore, RTT computed for second and sixth packets are weak RTT samples and others are strong RTT samples. Client updates the corresponding variables after receiving each ACK.
 |
Fig. 1 Illustration of Flexi COCOA. |
count_RTT is increased for all RTT samples and count_SRTT is updated for all strong RTT samples. The first strong RTT sample uses a weight of 0.5. Thereafter Flexi COCOA revises weight value. Flexi COCOA retains the default weight of COCOA for weak RTO computation. All updates of Flexi COCOA are highlighted in Fig. 1. Weight values are rounded to two decimal places for ease. Except for the first strong RTT, Flexi COCOA results in a larger weight value against 0.5 of COCOA. Also, it is evident that the occasional drops of second and sixth packets do not downgrade the \(weight_{strong}\) to as low as 0.5 of COCOA.
5. Performance Evaluation
Flexi COCOA is implemented in Contiki-3.0 and simulated with Cooja simulator [30], [31]. Modifications are made to the er-cocoa.c file in the implementation of COCOA shared by the authors. We compare Flexi COCOA with COCOA and GSRTC. Apart from being the latest in existing methods, GSRTC can work on constrained nodes and retains the notion of strong RTT and weak RTT with clearly defined actions on each type of RTT. Also, GSRTC leverages the improvements already made in COCOA through Fullbackoff2. Therefore, we choose GSRTC from existing methods described under Sect. 3.2. This section provides details about the experiments set up, result analysis and discussion about the result.
5.1 Experiment Setup
Experiments are conducted on Cooja simulator which supports emulation of off-the shelf sensor node hardware by including the real specific node hardware. The compiled binary image file is to be uploaded into the simulated nodes, where the compiled code is then executed with the emulation model of the selected node type during simulations. At the physical and MAC layers, the nodes utilize IEEE \(802.15.4\), with a data transmission speed of \(250\) kbps in the \(2.4\) GHz radio frequency band.
Topologies used in the evaluation are Grid of 9 nodes and Dumbbell of 21 nodes as shown in Fig. 2. Grid and Dumbbell are widely used in evaluation of CC algorithms in CoAP [10], [14], [21]. In both topologies, one node is border router, one node is server, and the rest of the nodes are clients. Among the nodes in Fig. 2, the red color node is the border router, the yellow color node is the server, and the rest of the nodes are clients. For the simulation, T-mote Sky mote [32] is used to configure border router and Zolerita Z1 mote [33] is used to configure rest of the nodes.
 |
Fig. 2 Topologies. |
Table 2 shows the mote specification. Border router is responsible for initiating and collecting the RPL protocol messages and storing the routing information of all nodes. Therefore, the RAM requirement of border router is higher than other types of nodes in the network. Therefore, Sky mote is selected to configure border router. Z1 motes offer large ROM capacity which is beneficial for us to code applications and implement CC algorithm. Hence, Zolerita Z1 mote is selected to configure server and clients. Every client waits for 20 seconds, including the RPL to set up. Thereafter, clients send CoAP POST request to the server at specified frequency.
Table 2 Sensor mote configuration. |
 |
Simulation parameters of the experiments are summarized in Table 3. Cooja’s Unit Disk Graph Medium (UDGM) with distance loss model is used for radio transmissions. The transmission range and the interference range of nodes are set to \(10\) meters and \(20\) meters respectively. When a node transmits packets, nodes in transmission range can receive those packets and nodes in interference range cannot. However, nodes in interference range can cause collisions if there are simultaneous packets. For UDGM, we can manually set the packet error rate (PER) in Cooja. Transmission ratio and reception ratio are provided in the user interface to introduce error. We use \(0\%,5\%,10\%\) error rates to compare the performance of COCOA, GSRTC and Flexi COCOA.
Table 3 Simulation parameters. |
 |
Radio duty cycling handles the sleep and wakes up cycle depending on the type of the RDC method used by the motes. Motes are configured without Radio Duty Cycling (NullRDC), to never switch the radio off and to keep the motes always in listening mode. We use NullMAC as the MAC driver instead of traditional CSMA to prohibit retransmission mechanism at layer \(2\). MAC layer retransmissions, which is optional in IEEE \(802.15.4\), may improve the performance of a collision-prone network. By disabling MAC layer retransmissions, we simulate an increased risk of degraded network performance due to a higher likelihood of packet loss and subsequent retransmissions initiated from the application layer. The capability of CC algorithm to manage and mitigate packet losses in such a worst-case scenario can be thus evaluated.
Each topology is simulated using each packet transmission frequency and PER combination. The test is repeated \(12\) times with different random seeds. An average of each performance metric from them is presented in this paper.
5.2 Result Analysis
We compare the performance of Flexi COCOA with COCOA and GSRTC based on total packet transmissions and retransmission effort.
5.2.1 Total Packet Transmissions
We denote total packet transmissions as the number of packets successfully delivered from the clients to the server. Figures 3 and 4 report the total packet transmissions. We do not consider retransmitted copy of the packets in this count. Each result is presented with \(95\)% confidence interval. In every scenario, Flexi COCOA achieves a significant increase in total packet transmissions than COCOA and GSRTC. Consequently, Flexi COCOA can significantly enhance the efficiency of periodic data monitoring applications by offering greater data transfer competence. Achievement in total packet transmission is correlated with addressing transmission delay. RTO value provides insight into managing transmission delay. Therefore, we analyze the RTO value obtained by each algorithm.
 |
Fig. 3 Total Packet Transmissions of Grid Topology. |
 |
Fig. 4 Total Packet Transmissions of Dumbbell Topology. |
Tables 4 and 5 present the RTO values obtained from COCOA, GSRTC and Flexi COCOA. RTO values are in unit of seconds. Results in Tables 4 and 5 reveal that GSRTC and Flexi COCOA, with the help of variable weight parameter, derive lower RTOs than COCOA in all our experiments. Adaptive weight values of GSRTC and Flexi COCOA make the larger RTOs converge faster than COCOA. As a result, GSRTC and Flexi COCOA exhibit a larger total packet transmissions compared to COCOA.
Table 4 RTO values of Grid Topology. |
 |
Table 5 RTO values of Dumbbell Topology. |
 |
The average values of adaptive weight from GSRTC and Flexi COCOA in Grid topology and Dumbbell topology are reported in Tables 6 and 7. Referring the Tables 6 and 7, we can realize that in general GSRTC uses larger weight values than Flexi COCOA. Larger weights of GSRTC make aggressive reduction of RTO compared to Flexi COCOA and results in spurious transmissions. We report the number of strong RTT samples obtained by GSRTC and Flexi COCOA in Tables 8 and 9. GSRTC achieves a smaller number of strong RTT samples than Flexi COCOA and thus we confirm spurious transmissions of GSRTC. Correspondingly, RTO values of GSRTC are greater than that of Flexi COCOA. Smaller RTO values can result in spurious transmissions if the RTO convergence approach is aggressive. Similarly, if the weight reduction is aggressive, smaller weights may reduce the speed of convergence, adversely affecting transmission delay. Therefore, any method which results in smaller weight or smaller RTO doesn’t always imply an enhancement over COCOA. Furthermore, optimal values for weight and RTO may be unreasonable in this context, as packet loss is not always caused by congestion. The cautious adaptation of Flexi COCOA helps prevent aggressive changes in weight and RTO, potentially enhancing the performance of COCOA in comparison to GSRTC.
Table 6 Weight values in Grid Topology. |
 |
Table 7 Weight values in Dumbbell Topology. |
 |
Table 8 Strong RTT samples in Grid Topology. |
 |
Table 9 Strong RTT samples in Dumbbell Topology. |
 |
Both in Grid and in Dumbbell topologies, total packet transmissions tend to decrease with higher PER or lower packet transmission frequency. RTO of COCOA tends to increase when PER increases or packet transmission frequency decreases. For every packet transmission frequency, as the PER increases, the impact of weak RTT samples increases, increasing RTO. For every PER, when the network is lightly loaded, sequence of similar small strong RTT samples is accumulated. This causes the impact of RTVAR in Eq. (3) to vanish which consequently leads to the generation of small RTO and sporadic retransmissions, and such retransmissions increase RTO. The weight value in Flexi COCOA and GSRTC are resulted from strong RTT samples and therefore also gets influenced similarly.
The tendency of RTO values in Flexi COCOA and GSRTC is also the same as that of COCOA for the same reasons explained. However, the loss of packets is not uniformly distributed. GSRTC increases weight value faster whenever possible and becomes aggressive. As a result, higher weight value and higher RTO are observed in GSRTC than in Flexi COCOA. On the contrary, Flexi COCOA makes gradual changes to weight value and reduces RTO better than GSRTC. Consequently, total packet transmissions of Flexi COCOA are larger than that of GSRTC and COCOA in the context of higher PER or lower packet transmission frequency.
From Figs. 3 and 4, we can observe that Dumbbell topology has a greater number of packet transmissions compared to Grid topology. The positioning of nodes varies between the Grid topology with 9 nodes and the dumbbell topology with 21 nodes as shown in Fig. 2. In both topologies, each node has direct neighbors 10 meters away. The number of direct neighbors and the number of nodes simultaneously competing for the radio channel are more in Dumbbell topology than in Grid topology. The radio link connecting two halves of the Dumbbell is a bottleneck, causing an increase in retransmissions if not shared fairly. Consequently, Dumbbell topology results in more weak RTT samples than Grid topology. This is evident from Tables 6 and 7 that the weight values of Dumbbell are generally less than that of Grid. As a result, the RTO of Dumbbell topology is greater than that of Grid topology as in Tables 4 and 5. However, packet loss varies among nodes of Dumbbell topology due to the randomization of algorithms implemented across different layers of the protocol stack.
The Dumbbell topology provides a benefit over the Grid topology regarding the length of RTT. The length of route between CoAP client and CoAP server can lead to the length of RTT. In Grid topology, the number of hops between them varies, since many combinations of links for the connection of client and server nodes are possible. Hence, RTT varies accordingly. In Dumbbell topology, clients on half circles are two hops away from the CoAP server. Therefore, the length of strong RTT sample is lesser in Dumbbell topology than in Grid topology. Nodes experiencing higher losses back off from transmission for longer durations. Nodes experiencing lesser losses exploit the back off duration of nodes with higher losses to successfully deliver packets to the server, taking advantage of the length of RTT in the Dumbbell topology. Consequently, the total packet transmissions in the Dumbbell topology are higher than Grid topology.
GSRTC and Flexi COCOA further improves the delay in transmission with the help of adaptive weight values by providing more weightage to current strong RTT. However, Flexi COCOA demonstrates a competent refining of weight value than GSRTC. Performance of GSRTC is affected by the impulsive reset of weight to 0.5 after a weak RTT is computed. Flexi COCOA manages RTO computation better than COCOA and GSRTC even with infrequent weak RTT samples. Therefore, Flexi COCOA exhibits better performance than COCOA and GSRTC in total packet transmissions. Upgrading the bandwidth of the bottleneck link may help alleviate congestion in a Dumbbell topology. However, the limited memory and processing speed of constrained nodes make discussions on higher bandwidth utilization irrelevant.
5.2.2 Retransmission Effort
Retransmission in constrained network is costlier. Therefore, retransmission is a crucial evaluation criterion. We analyze the context of retransmission using retransmission effort metric. The retransmission effort of the client is defined as the average number of retransmissions attempted to deliver each data packet to the server. The ratio between total retransmissions and total data packets is computed as retransmission effort. Tables 10 and 11 show the results obtained. Flexi COCOA achieves lower retransmission effort than COCOA and GSRTC in all the experiments we conducted. The tendency of retransmission effort values is like that of RTO values. The reasons are same as already explained for RTO. For the sake of brevity, we do not repeat the explanation.
Table 10 Retransmission effort of Grid Topology. |
 |
Table 11 Retransmission effort of Dumbbell Topology. |
 |
We dissect the RTO\(_{init}\) and RTO\(_{new}\) to understand the result further. The number of message transmissions that start with large RTO\(_{new}\) values in COCOA is higher than that of Flexi COCOA. However, when strong RTT is obtained in COCOA, RTO\(_{new}\) coverages to RTT uniformly based on the constant weight value. On the other hand, Flexi COCOA breaks the uniformity in converging RTO\(_{new}\) to RTT. The weight value of Flexi COCOA is never a pre-fixed value and does not exhibit monotonic increase or decrease. Therefore, RTO\(_{new}\) in Flexi COCOA, responds quickly to network dynamics than COCOA and derives sensible RTO\(_{init}\) values. As a result, retransmission effort in Flexi COCOA is less than COCOA. When weak RTT is computed, GSRTC inherits Fullbackoff2 [17] and controls retransmissions. Using Fullbackoff2, a new transmission after a weak RTT sample makes uses maximum of back off RTO or RTO\(_{new}\) as RTO\(_{new}\). Hence, GSRTC achieves smaller retransmission effort than COCOA by reusing larger RTO value from previous transmission. However, the rapid increase of weight value using strong RTT samples makes the retransmission effort of GSRTC larger than that of Flexi COCOA.
Tables 10 and 11 show that retransmission effort of Dumbbell topology is greater than that of Grid topology. The number of nodes simultaneously competing for the radio channel is more in Dumbbell topology than in Grid topology. Therefore, retransmission due to packet collision increases. The radio link between two halves of the Dumbbell is also a critical point. When the bandwidth offered by this link does not suffice, retransmission increases. Such characteristics of Dumbbell topology give rise to more retransmission effort when compared to Grid.
Using smaller RTO values, the number of transmissions is expected to increase. However, if the reduction in RTO is inefficient, retransmissions increase due to packet loss. An efficient RTO needs to be always as much associated with network dynamics as possible. Flexi COCOA is always adaptive to changes in the network signaled by strong RTT samples. Therefore, RTT samples contribute sensitively in Flexi COCOA compared to COCOA and GSRTC. Retransmission effort values of Flexi COCOA prove the reduction of RTO is efficient.
5.3 Discussion
Flexi COCOA outperforms COCOA and GSRTC in all performance metrics of our experiments. We analyze the result in three aspects: packet transmission frequency, PER and topology. The general trend we observed in the performance evaluation is that Flexi COCOA exhibits the best performance for high frequency transmissions in an error free environment.
In an error free network, the probability of obtaining strong RTT is larger. Therefore, the weight value becomes proportionally higher, and the reduction of RTO is faster. Flexi COCOA reduces transmission delay using a gradually changing weight value against the rapid change of GSRTC and gives the best result in our experiments. When the packet transmission frequency reduces, a flexible weight value still reduces the delay in transmission. However, nodes also must wait until the frequency timer expires. Therefore, high frequency transmission shows more change than low frequency transmissions.
CoAP expects that the constrained nodes may work in the lossy network. Therefore, we introduced PER in the network to understand the performance of Flexi COCOA in lossy network. In lossy network, we attempt to utilize all chances of obtaining strong RTT and improve the weight parameter whenever it is possible. Even with PER, GSRTC is found to be more aggressive than Flexi COCOA. From the results, we prove that Flexi COCOA is more reliable than COCOA and GSRTC, for applications even to work in the presence of errors. Flexi COCOA solely depends on strong RTT samples to improve the efficiency of RTO computation using better weight value than COCOA and GSRTC. When PER increases, strong RTT decreases and accordingly declines the weight value. This poses a challenge for Flexi COCOA to deliver better RTO than COCOA. Reduction of weight value as the PER increases is visible in Tables 6 and 7. When the number of weak RTT increases more than that of strong RTT, the network is extremely lossy. A conservative mechanism is beneficial over aggressive mechanism here. Hence Flexi COCOA contributes only the least.
We evaluated Grid topology and Dumbbell topology to understand how positioning of nodes affect the performance of Flexi COCOA. When there are more direct neighbors, the probability of simultaneous access of the same link increases and which in turn results in weak RTT samples. Therefore, Dumbbell topology shows larger RTO and more retransmission effort compared to Grid. When a greater number of nodes are closer to the server, the length of strong RTT becomes lesser and the number of transmissions can be improved. As a result, Dumbbell topology has more packet transmissions compared to Grid topology. Thus, the positioning of nodes can impact the margin of performance differences that Flexi COCOA can offer against COCOA and GSRTC.
6. Conclusion and Future Work
In this paper, we proposed Flexi COCOA to enhance the network sensitivity of COCOA using flexible weight value. We successfully addressed the challenge of generating network sensitive RTO with the help of flexible weight value of strong RTO computation. Flexi COCOA exhibits desired performance with change in frequency or PER. Results indicate that the proposed method can improve the QoS of IoT monitoring applications. Flexi COCOA can be easily integrated into COCOA. The proposed method utilizes monitoring of already available measures in COCOA. Therefore, Flexi COCOA does not increase computation and communication overheads when compared to COCOA.
As future work, we will evaluate the perspective of traffic bursts, fairness, and energy consumption.
References
[1] K. Ashton et al., “That ‘internet of things’ thing,” RFID Journal, vol.22, no.7, pp.97-114, 2009.
[2] L. Atzori, A. Iera, and G. Morabito, “The internet of things: A survey,” Computer Networks, vol.54, no.15, pp.2787-2805, 2010.
CrossRef
[3] Z. Shelby, K. Hartke, and C. Bormann, “The constrained application protocol (CoAP),” RFC 7252, 2014.
CrossRef
[4] T. Winter, P. Thubert, A. Brandt, J. Hui, R. Kelsey, P. Levis, K. Pister, R. Struik, J.P. Vasseur, and R. Alexander, “RPL: IPv6 routing protocolfor low-power and lossy networks,” Technical Report, RFC 6550, 2012.
CrossRef
[5] N. Kushalnagar, G. Montenegro, and C. Schumacher, “IPv6 overlow-power wireless personal area networks (6LoWPANs): Overview, assumptions, problem statement, and goals,” RFC 4919, 2007.
CrossRef
[6] D. Pandey and V. Kushwaha, “An exploratory study of congestion control techniques in wireless sensor networks,” Computer Communications, vol.157, pp.257-283, 2020.
CrossRef
[7] L. Eggert and G. Fairhurst, “Unicast UDP usage guidelines for application designers,” RFC 5405, 2008.
CrossRef
[8] L. Eggert, “Congestion control for the constrained application protocol (CoAP),” draft-eggert-core-congestion-control-01 (work in progress), 2011.
URL
[9] A. Betzler, C. Gomez, I. Demirkol, and J. Paradells, “CoAP congestion control for the internet of things,” IEEE Commun. Mag., vol.54, no.7, pp.154-160, 2016.
CrossRef
[10] A. Betzler, C. Gomez, I. Demirkol, and J. Paradells, “CoCoA+: An advanced congestion control mechanism for CoAP,” Ad Hoc Networks, vol.33, pp.126-139, 2015.
CrossRef
[11] P. Karn and C. Partridge, “Improving round-trip time estimates in reliable transport protocols,” ACM SIGCOMM Computer Communication Review, vol.17, no.5, pp.2-7, 1987.
CrossRef
[12] V. Paxson, M. Allman, J. Chu, and M. Sargent, “Computing TCP’s retransmission timer,” RFC 6298, 2011.
CrossRef
[13] E. Ancillotti and R. Bruno, “Comparison of CoAP and CoCoA+ congestion control mechanisms for different IoT application scenarios,” IEEE Symposium on Computers and Communications (ISCC), pp.1186-1192, 2017.
CrossRef
[14] R. Bhalerao, S.S. Subramanian, and J. Pasquale, “An analysis and improvement of congestion control in the CoAP internet-of-things protocol,” IEEE Annual Consumer Communications & Networking Conference (CCNC), pp.889-894, 2016.
CrossRef
[15] H. Meng, H. HongBing, and L. WeiPing, “An adaptive congestion control algorithm with CoAP for the Internet of Thing,” Int. J. Comput. Tech., vol.4, pp.46-51, 2017.
[16] I. Jarvinen, I. Raitahila, Z. Cao, and M. Kojo, “Fasor retransmission timeout and congestion control mechanism for CoAP,” IEEE Global Communications Conference (GLOBECOM), pp.1-7, 2018.
CrossRef
[17] I. Järvinen, I. Raitahila, Z. Cao, and M. Kojo, “Is CoAP congestion safe?,” Proc. Applied Networking Research Workshop, pp.43-49, 2018.
CrossRef
[18] S. Bolettieri, G. Tanganelli, C. Vallati, and E. Mingozzi, “pCoCoA: A precise congestion control algorithm for CoAP,” Ad Hoc Networks, vol.80, pp.116-129, 2018.
CrossRef
[19] V. Rathod, N. Jeppu, S. Sastry, S. Singala, and M.P. Tahiliani, “CoCoA++: Delay gradient based congestion control for Internet of Things,” Future Generation Computer Systems, vol.100, pp.1053-1072, 2019.
CrossRef
[20] C. Suwannapong and C. Khunboa, “Congestion control in CoAP observe group communication,” Sensors, vol.19, no.15, p.3433, 2019.
CrossRef
[21] S. Deshmukh and V.T. Raisinghani, “Adcocoa-adaptive congestion control algorithm for CoAP,” IEEE International Conference on Computing, Communication and Networking Technologies (ICCCNT), pp.1-7, 2020.
CrossRef
[22] G.A. Akpakwu, G.P. Hancke, and A.M. Abu-Mahfouz, “CACC: Context-aware congestion control approach for lightweight CoAP/UDP-based Internet of Things traffic,” Trans. Emerging Telecommunications Technologies, vol.31, no.2, p.e3822, 2020.
CrossRef
[23] R.K. Yadav, N. Singh, and P. Piyush, “Genetic CoCoA++: Genetic algorithm based congestion control in CoAP,” IEEE International Conference on Intelligent Computing and Control Systems (ICICCS), pp.808-813, 2020.
CrossRef
[24] A.K. Demir and F. Abut, “mlCoCoA: A machine learning-based congestion control for CoAP,” Turkish Journal of Electrical Engineering and Computer Sciences, vol.28, no.5, pp.2863-2882, 2020.
CrossRef
[25] D.H. Hoang and T.T.D. Le, “RCOAP: A rate control scheme for reliable bursty data transfer in IoT networks,”IEEE Access, vol.9, pp.169281-169298, 2021.
CrossRef
[26] V. Rathod and M.P. Tahiliani, “Geometric series based effective RTO estimation technique for CoCoA,” Ad Hoc Networks, vol.130, p.102801, 2022
CrossRef
[27] G.A. Akpakwu, G.P. Hancke, and A.M. Abu-Mahfouz, “An optimization-based congestion control for constrained application protocol,” International Journal of Network Management, vol.32, no.1, p.e2178, 2022.
CrossRef
[28] F. Righetti, C. Vallati, D. Rasla, and G. Anastasi, “Investigating the CoAP congestion control strategies for 6tisch-based IoT networks,” IEEE Access, vol.11, pp.11054-11065, 2023.
CrossRef
[29] P.K. Donta, S.N. Srirama, T. Amgoth, and C.S.R. Annavarapu, “iCoCoA: Intelligent congestion control algorithm for CoAP using deep reinforcement learning,” J. Ambient Intell. Human. Comput., vol.14, no.3, pp.2951-2966, 2023.
CrossRef
[30] “Contiki,” https://github.com/contiki-os/contiki
URL
[31] “Contiki tutorial,” https://anrg.usc.edu/contiki/index.php/Contiki_tutorials
URL
[32] “Tmote sky,” https://telosbsensors.wordpress.com/
URL
[33] “Zolertia Z1 mote,” https://github.com/Zolertia/Resources/wiki/The-Z1-mote
URL
Authors
Sophia University
received B.Tech degree in Information Technology from Kerala University, India in 2006. She received M.Tech degree in Computer Science and Engineering from Amrita Vishwa Vidyapeetham, India in 2013. She is currently a Ph.D. student in the Department of Information and Communication Sciences at Sophia University, Japan. Her current research interests include IoT and congestion control.
 |
Sophia University
received the B.E. and M.E. degrees in Electrical Engineering and the Ph.D. degree in Information and Computer Science from Keio University, Japan in 1996, 1998, and 2004, respectively. From 2004 to 2010, he was an assistant professor at Shizuoka University, Japan. He is currently a professor in the Department of Information and Communication Sciences at Sophia University, Japan. His current research interests include computer networks, network computing, and applications.
 |
