4. Sep 2022

Received 30 August 2022, accepted 21 September 2022, date of publication 3 October 2022, date of current version 10 October 2022.
Digital Object Identifier 10.1109/ACCESS.2022.3211296
Fuzzy Congestion Control and Avoidance

for CoAP in IoT Networks
THIEU NGA PHAM1 , DANG HAI HOANG2 , AND THI THUY DUONG LE 1
1 Faculty of Information Technology, University of Civil Engineering, Hanoi 10000, Vietnam
2 Posts and Telecommunications Institute of Technology, Hanoi 10000, Vietnam
Corresponding author: Dang Hai Hoang (haihd@ptit.edu.vn)
ABSTRACT In Internet of Things (IoT) networks, congestion is growing with the increasing number of
devices, and a large amount of collected data must be transferred. Congestion control is one of the most
significant challenges for such networks. The Constrained Application Protocol (CoAP) has been adopted
for the IoT to satisfy the demand for smart applications. However, CoAP uses a basic congestion control
algorithm that operates only when congestion occurs. Thus, the basic CoAP and most similar loss-based
congestion control schemes have remaining issues for burst data transfer in dynamic network environments.
This paper proposes a novel rate-based congestion control scheme using fuzzy control for CoAP, called
FuzzyCoAP. We use the round-trip time gradient and bottleneck bandwidth gradient as inputs for FuzzyCoAP
to infer the degree of congestion. FuzzyCoAP uses this indicator to predict early congestion and adjusts the
sending rate to avoid congestion. FuzzyCoAP uses the congestion degree to update the variable RTO for
retransmissions. On the other hand, FuzzyCoAP dynamically checks for the available bandwidth to gain
high performance for burst data transfer. Various simulation experiments have demonstrated the feasibility
of the FuzzyCoAP in different traffic scenarios. We compared the proposed scheme with representative loss-
based CoAP schemes, that is, the basic CoAP. The simulation results proved that FuzzyCoAP provides high
performance in terms of delay, throughput, loss rate, and retransmissions compared with the basic CoAP.
INDEX TERMS Congestion control, rate control, fuzzy control, constrained application protocol, Internet
of Things.
I. INTRODUCTION CoAP uses congestion control (CC) to alleviate network con-

With the growth of Internet of Things (IoT) networks, various gestion.
smart applications have been deployed to improve the quality There has been debate regarding the deployment of TCP
of human life. Typical applications include event- monitoring in IoT networks because TCP is the dominant transport layer
networks in healthcare, agriculture, or environmental areas. for the Internet. TCP was designed with congestion control
An IoT network typically consists of a considerable number and reliable data delivery to efficiently transport bulk of data
of IoT devices that collect data from the physical environment over the Internet. However, TCP faces significant challenges
and send burst data to a server at a remote center. and has been neglected in IoT networks [4].
The Internet Engineering Task Force (IETF) standardized IoT networks have distinctive characteristics compared to
the Constrained Application Protocol (CoAP) as a transport traditional computer networks. IoT devices typically have
layer protocol for IoT networks [1]. CoAP is a lightweight limited resources and processing capabilities. IoT networks
protocol that works on top of an unreliable User Data- are often dynamic and have a high bit error rate. Many IoT
gram Protocol (UDP) but provides a reliable connection- applications rely not only on the occasional transmission of
oriented data transfer mode such as the Transmission Control small data patterns but must also transfer a large amount of
Protocol (TCP) [2], [3]. Similar to other transport protocols, collected data to the server, resulting in enormous traffic on
the network [5]. One example of such an application is the
The associate editor coordinating the review of this manuscript and camera monitoring system [6]. To support the burst traffic of
approving it for publication was Md. Arafatur Rahman . typical applications, the design of a suitable CC for CoAP
This work is licensed under a Creative Commons Attribution 4.0 License. For more information, see https://creativecommons.org/licenses/by/4.0/
VOLUME 10, 2022 105589
T. N. Pham et al.: Fuzzy Congestion Control and Avoidance for CoAP in IoT Networks
is undoubtedly necessary. However, this issue has not been size, whereas rate-based CC schemes control the transmis-
resolved satisfactorily. The current standardized CoAP [1] sion rate. Delay-based CC schemes rely on window adjust-
uses basic congestion control that works only when con- ment mechanisms (e.g., [18] and [42]). In contrast, rate-based
gestion occurs. When a timeout occurs, CoAP assumes that CC schemes are based on rate adjustment (e.g., [23], [28],
the network is congested. In response, CoAP triggers the and [29]). Rate-based CC schemes are the most promising
retransmission of the lost packets. This implies that the basic approaches because they operate in regions with low delays
CoAP cannot detect early congestion. In addition, CoAP and high throughput. This point will be described in the next
strictly limits the number of simultaneous outstanding inter- section. These schemes adjust the sending rate before con-
actions [1, p. 26]. Thus, the current CoAP does not sup- gestion occurs. Thus, we can call these congestion avoidance
port a burst traffic transfer. RFC 7252 [1] shows that further schemes.
consideration of CoAP congestion control is expected in the In this study, we focus on rate-based CC approaches. As the
future. sending rate increased, the load on the network increased and
Congestion control (CC) is a broad research topic. This the round-trip delay increased rapidly. Most rate-based CC
study focuses only on end-to-end CC solutions for the trans- schemes measure round-trip delays and use this information
port layer because CoAP operates on top of an unreli- to set timeout timers and adjust the sending rate (or load).
able transport protocol (i.e., UDP). Existing end-to-end CC There are three crucial issues related to congestion control:
schemes for transport protocols can be classified into three 1) decisions on the increment/decrement of the sending rate
main groups: 1) loss-based CC; 2) delay-based CC; and 3) (or load), 2) the number of changes, and 3) frequency of
rate-based CC. In general, all CC schemes require feedback changes.
from the network or destination to the senders (in terms of The decision to increase or decrease is clear for loss-based
timeout, packet loss, delay, or throughput) to control the load CC schemes, as they should decrease in case of a packet loss
to the network (reduced window, load, or rate). Examples of and increase otherwise. This decision is more complicated
existing CC schemes can be found in [7], [8]. for rate-based CC schemes. It is difficult to determine the
Loss-based CC schemes use timeout or packet losses as an bounds of the RTT, load, and rate to make decisions because
indication of network congestion to reduce the window. Typ- of the variance in these parameters, high burst traffic, and
ical examples are the schemes in [3], [9], and [10] for TCP, dynamic network conditions. In addition, such parameters are
and [11], [12], [13], [14], [15], [16], [17] for CoAP. CoAP often fuzzy (i.e., not sharp, uncertain, vague, and ambigu-
and most of its variants [11], [12], [13], [14], [15], [16], [17] ous). A fuzzy control system (FCS) is an excellent choice
use a loss-based CC approach based on a retransmission for solving such complex problems. An FCS converts crisp
timeout (RTO) with a backoff strategy. It should be noted inputs into fuzzy sets, and then produces crisp outputs based
that CoAP uses a fixed window size called NSTART, whose on fuzzy rules and an inference engine [30].
default value is one [1]. In the case of packet loss, the CoAP Fuzzy control has been widely applied to network conges-
sender attempts to retransmit the packet using a reduced tion control in the past (e.g., [31], [32], [33], [34], [35], [36],
retransmission rate (i.e., reduced load) in the backoff phase. [37], [38], [39], and [40]), either for TCP or other protocols
Delay-based CC schemes utilize packet delay, round-trip time such as routing. Such schemes use fuzzy control to infer the
(RTT), or load to predict network congestion. The window packet drop probability or congested routes based on mea-
or load is adjusted for each round-trip time. Examples are surements of buffer sizes in the network nodes. For CoAP,
some schemes proposed for TCP in [18], [19], [20], [21], a fuzzy logic system was proposed in [41] for the backoff
and [22]. Rate-based CC schemes leverage measurements of strategy and RTO adjustment. However, this system addresses
round-trip time (RTT), packet loss, or throughput to adjust only the issues of RTO estimation.
the transmission rate, thus avoiding congestion. Examples To the best of our knowledge, no study has applied fuzzy
include the TCP and TCP-friendliness schemes in [25], [26], control to the problem of rate control to avoid congestion in
and [27]. Recently, several rate-based schemes have been CoAP. In this paper, we propose a fuzzy control system (FCS)
proposed for CoAP, such as those in [23], [24], [28], for CoAP CC in IoT networks. Our scheme uses two crisp
and [29]. inputs: the RT-gradient and bottleneck bandwidth gradient,
Loss-based CC schemes are activated only when network which are computed based on the ACK messages (acknowl-
congestion occurs. Their drawback is that they require an edgment) from the server. Based on these inputs, the FCS
additional mechanism for early loss detection to avoid suc- predicts the degree of network congestion and uses this indi-
cessive packet losses due to congestion. In the case of TCP cator to control the sending rate and to avoid congestion. The
schemes, Random Early Drop (RED) [10] is a good example proposed scheme can be implemented for burst data transfers
of such a mechanism to support TCP. However, RED is not in IoT networks.
an end-to-end CC approach. Such schemes require support The remainder of this paper is organized as follows.
from the network routers. Delay-based and rate-based CC Section II presents the background and related work.
schemes are similar in that they both use RTT measures to In Section III, we propose an FCS for a CoAP. The pro-
predict congestion. However, they differ with respect to the posed FuzzyCoAP is presented in Section IV. In Section V,
control object. Delay-based CC schemes control the window we evaluate the performance of the proposed system and
105590 VOLUME 10, 2022

discuss the related issues. Finally, Section VI concludes the increases slowly, whereas the RTT increases significantly
paper. because some queues build up at the bottleneck link. In the
third region (buffer-limited), packets are dropped because
II. BACKGROUND AND RELATED WORK of buffer overflows. The network was said to be congested.
A. CONGESTION CONTROL AND AVOIDANCE The RTT increased drastically, and the throughput decreased
Network congestion is a state of degraded performance due to rapidly after the cliff point. Loss-based CC schemes oper-
the saturation of network resources (link bandwidth, buffers, ate at the right edge of the cliff point, whereas delay-based
and processing capabilities). Adapted from [18] and [42], and rate-based CC schemes operate in a bandwidth-limited
Figure 1 presents a formal relationship between the sending region. The knee is the theoretical optimal point, but we
rate, RTT, throughput, and load. The network state was iden- could not determine it in practice because of dynamic network
tified by three regions: app-limited, bandwidth-limited, and conditions [42]. Therefore, our proposed scheme attempts to
buffer-limited. The sending rate is the objective of any CC maintain the network state in the zone between the knee and
scheme because it must be increased or decreased according cliff (shaded zone in the figure).
to the congestion state to adjust the load on the network. The
knee is the point at which the sending rate saturates the bottle- B. COAP CONGESTION CONTROL
neck link. A connection (i.e., a path from a client to the server) CoAP [1] is a lightweight web transfer protocol developed
has exactly one bottleneck, that is, the slowest link in the for constrained devices and networks. CoAP was designed
path. The bottleneck link is important because it determines to exchange messages over datagram-oriented transport (i.e.,
the maximum sending rate, and it is where persistent queues UDP) in the client/server model. CoAP defines four types
form [42]. The load represents the inflight packets (packets of messages: confirmable (CON), non-confirmable (NON),
sent but not yet acknowledged). A cliff is the point at which acknowledgment (ACK), and reset (RST). CON messages
congestion occurs [18]. must be acknowledged by the receiver (server). The CON
and ACK messages ensured a reliable data transfer. If a
CON message is not acknowledged within a fixed predefined
retransmission timeout (RTO), the CoAP client initiates its
retransmission. The initial RTO was fixed between two and
three seconds as indicated in [1].
The basic congestion control of CoAP is loss-based. If a
CoAP client detects packet losses, it is assumed that conges-
tion has occurred. The CoAP reduces its retransmission rate
using a binary exponential backoff (BEB) (i.e., the RTO is
doubled for each retransmission). Four retransmissions are
allowed. Subsequently, the transaction is considered failed.
CoAP restricts the number of concurrent messages that can
be sent without receiving an ACK (NSTART is one [1]).
CoCoA [11] is an enhancement to remedy the issues of the
basic congestion control of CoAP. CoCoA uses two estima-
tors to adjust the RTOs based on RTT measurements. In addi-
tion, CoCoA uses a variable backoff factor (VBF) instead of
a fixed BEB to compute the RTOs. The RTOs were computed
based on the formulas specified in RFC 6298 [43]. CoCoA+
[12], [13] is another enhancement that uses a more advanced
CC. CoCoA+ introduces a smaller RTT variance factor to
adjust the RTO values. Furthermore, CoCoA+ has a new
aging policy for RTO calculation and resolves the problem
of weak RTO estimation in CoCoA.
Most other proposed variants of CoAP have focused on the
issue of RTO computation for CC in CoAP. The calculation
FIGURE 1. Overview of parameters for congestion control. of RTO is important because it determines the retransmission
rate and efficiency of the protocol. Nevertheless, the RTO
The app-limited region is characterized by low sending calculation depends on the estimation of variable RTTs. Many
rates (e.g., there are insufficient packets to be sent). In this researchers have focused on the accuracy of RTO calculations
region, the throughput increases linearly with the load and using several enhanced algorithms for the measurement of
the RTT increases weakly with the load. As the load reaches RTT variances and adjustment of retransmission rates. The
the knee point, the network state is in the second region typical CoAP variants are as follows. The authors in [14]
(bandwidth-limited). In the second region, the throughput proposed a retransmission counter in the option field of a
VOLUME 10, 2022 105591

CoAP header to update the RTO dynamically. Fast and slow less or greater than 20%, respectively. CoAP-SC [45] can be
RTO algorithms were proposed in [15]. Fast RTO was calcu- called a rate-based scheme, because it regulates the sending
lated for unambiguous RTT samples whereas slow RTO was rate based on flow control with error handling for streaming
performed for ambiguous RTT samples. The backoff logic services. This requires adding sequence numbers to the option
follows three transitive states based on fast and slow RTO. field headers of the packets. Based on the difference between
The authors in [16] proposed a pCoCoA with a transmis- the sending and receiving sequence numbers, the CoAP-SC
sion count option to match the ACK message with the cor- can detect congestion. Recently, RCOAP [29] was proposed
responding CON message, even for retransmission. pCoCoA as a rate-based CC scheme for burst data transfer. It uses
introduces different methods to update the RTT and limits probe packets to infer the bottleneck bandwidth and regu-
the minimum RTO to reduce spurious retransmissions. The lates the rate according to an additive increase/multiplicative
AdCoCoA scheme [17] proposes a smooth estimation of the decrease policy. This allows for inflight packets and can
RTT variances to enhance the RTO computation algorithm distinguish congestion losses from wireless losses based on
in CoCoA+. CoCo-RED [44] proposed a combination of CC probe packets. A good survey for challenges and issues in the
with revised Random Early Detection (RED) and a Fibonacci current CoAP can be found in [46].
backoff algorithm. The importance of RTT variances has been As presented above, rate-based CC schemes offer several
recognized in most studies. Various methods for RTT vari- advantages: 1) they operate in a bandwidth-limited zone,
ance estimation have been considered in recent works [15], 2) they can vary the transmission rate based on the network
[16], [17], [44], [46]. state and bottleneck bandwidth, and 3) they support inflight
According to our survey, all the mentioned schemes are packets. Consequently, the proposed scheme used a rate-
loss-based CC schemes because they focus only on RTO, based approach.
retransmission, and backoff. The main differences between
them are in the RTT estimation, RTO computation, and C. FUZZY CONTROL
backoff policies. Their congestion control is activated only Zadeh [47] introduced fuzzy theory in 1965. Since then, the
when packet loss has been detected, that is, when conges- fuzzy theory has been applied in many fields, with fuzzy con-
tion occurs. These schemes attempt to mitigate congestion by trol being an important application. Fuzzy control is a method
reducing the retransmission rate (not the sending rate). These based on fuzzy theory, which is used to control dynamic sys-
schemes do not allow for inflight packets, because they limit tems with ambiguous inputs. A fuzzy control system (FCS)
the number of outstanding packets. Therefore, these schemes has the advantage of controlling highly nonlinear, complex
are unsuitable for burst data transfer. systems. Detailed information on the concept of FCS can be
RTT-CoAP [24] is a delay-based CC scheme proposed found in [47] and [50] for fuzzy sets, [48], [49] for fuzzy
for CoAP. This scheme monitors the growth of the RTT controllers, [51], [52] for membership grades and member-
variances to infer the network state and determine the ship functions, and [30], [49], [52] for fuzzy relations, lin-
sending rate to prevent network congestion. RTT-CoAP guistic variables, fuzzy rules, fuzzification processes, fuzzy
defines four traffic regions: low congestion, normal opera- inference engines, and defuzzification processes.
tion, medium operation, and high variability. The sending rate Fuzzy control has been proven successful in congestion
was adjusted accordingly: fast/slow increased or fast/slow control, as shown in [31], [32], [33], [34], [35], [36], [37],
decreased depending on the network state in the regions. The [38], [39], [40], and [41]. In fact, it is difficult to develop
scheme uses an additive increase/additive decrease (AIAD) a precise analytical model for congestion control owing its
policy. However, it is unclear how to select the factors for complexity. The network conditions are dynamic because of
increments and decrements. the burst nature of data transfer and the fluctuation of the
CoAP-R [28] is a rate-based CC scheme for CoAP. This parameters involved. In addition, the uncertainty in deter-
scheme uses a tree-based routing deployment and supports mining network parameters makes it challenging to obtain
burst traffic. This requires information on the node tree to a realistic and cost-effective solution for congestion control.
discover bottleneck links. Congestion is detected using the Thus, fuzzy control is a feasible approach to the congestion
present and past channel loads and the ratio between the control problem.
current sending rate and allocated rate for a local node. This In [31], the author demonstrated the difficulty of estimat-
scheme uses a multiplicative increase/multiplicative decrease ing the flow parameters in practice. A fuzzy controller was
policy. However, this requires information on the buffer occu- proposed to predict the time series parameters to adjust the
pancy of the nodes. In addition, it is difficult to determine flow rate. The authors in [32] proposed a Fuzzy-RED based
the allocation rates of nodes. BDP-CoAP [23] is another on buffer length variations to predict congestion in TCP traf-
rate-based CC scheme for CoAP that leverages the BBR fic [53]. The fuzzy CC scheme in [33] used buffer occupancy,
(bottleneck bandwidth and round-trip propagation time) traffic rate, and number of participating nodes to determine
protocol [42]. Based on bottleneck bandwidth estimation, the congestion level in wireless sensor networks (WSN). The
BDP-CoAP determines the sending rate and keeps inflight authors in [34] proposed combining RED with a fuzzy con-
packets bounded to the bandwidth-delay product. The pacing troller to adjust the sending rate for each node in a WSN
gain is either 0.6 or 0.2 when the retransmission frequency is using queue length differences and the variation of errors at
105592 VOLUME 10, 2022

each node. An FCS was proposed in [35] using the number of However, to reduce the complexity of CoAP CC, we use
contending nodes, buffer occupancy percentage of next-hop two inputs. The inputs of our FCS were the RT-gradient and
sensor nodes, and traffic load for video streams over a WSN. BG-gradient. The RT-gradient indicates an increase in round-
The authors in [36] proposed an FCS for routers using queue trip time. The BG-gradient is defined as the ratio of the
lengths and window size based on active queue management delivery rate to the bottleneck bandwidth. To reflect the
(AQM). Several studies have proposed the application of congestion level, one output, namely, the congestion degree
fuzzy control for route selection [37], [38], [39]. In [37], (C-degree), is sufficient. Therefore, the proposed FCS is a
an FCS was proposed for route selection using an AQM in a MISO system.
WSN. This scheme isolates malfunctioning nodes to reduce The system model of the proposed FCS is shown in
the route congestion. In [38], a fuzzy priority-based RED Fig. 2 with four components: fuzzification, rule base, fuzzy
mechanism was proposed to estimate the node congestion inference engine, and defuzzification. µ(x), µ(y), and µ(z) are
level based on the drop probability and find a less congested the membership functions of inputs and outputs, respectively.
route. The fuzzy CC scheme in [39] uses node buffer occu- Zc is the crisp output (C-degree) of the FCS.
pancy, priority, and packet arrival rates to estimate congestion
levels and regulate the sending rate. In [40], an FCS for rate
adjustment was proposed, which leverages the queuing model
in the node buffer to estimate congestion. The authors used
buffer queue length and the ratio of RTT/RTO to estimate the
network state and adjust the sending rate. In [41], an FCS was
proposed for CoAP. However, this FCS is only for RTO esti-
mation and backoff to reduce the number of retransmissions
and not for sending rate control. Because this scheme is based
on timeouts, it is a loss-based CC scheme.
FIGURE 2. The system model of the proposed fuzzy control system.
In summary, the complexity and difficulty of congestion
control motivated the use of fuzzy control as an appropriate
solution to address the dynamic nature of network conditions The design of the inputs and outputs of the FCS is par-
and variations in the network parameters. ticularly important and is one of the main contributions
For CoAP, no research has addressed the application of of this study. In the following subsections, we present the
fuzzy control for rate adjustment to avoid congestion. There- inputs, outputs, and detailed components of our proposed
fore, this study proposes a rate-based congestion control and FCS. Table 1 lists the notations used in this study.
avoidance scheme for CoAP based on a fuzzy control system.
In Section III, we present the design of our fuzzy control TABLE 1. Notations.
system that computes the degree of congestion to reflect the
congestion state. This indicator is used to adjust the RTO
and sending rate to avoid congestion, which is described in
Section IV.
III. PROPOSED FUZZY CONTROL SYSTEM FOR COAP

A. OVERVIEW
An FCS consists of four basic components: fuzzification,
fuzzy rule base, fuzzy inference engine, and defuzzifica-
tion [49], [52]. Fuzzification transforms crisp input values
into a set of fuzzy values with membership functions for
all linguistic variables and assigns grades of input mem-
bership. The fuzzy rule base presents a set of IF-THEN
rules that define the input-output mapping based on mem-
bership functions. A fuzzy inference engine is used to infer
the output based on the defined fuzzy rules and fuzzy
implication operators. Defuzzification generates crisp out-
puts from the output fuzzy set provided by the fuzzy inference
engine.
Depending on the number of inputs and outputs, an FCS
system can be a single-input-single-output (SISO) system, a
multiple-inputs-single-output (MISO) system, or a multiple-
inputs-multiple-outputs (MIMO) system. Owing to the com-
plexity of the congestion control, multiple inputs are required.
VOLUME 10, 2022 105593

B. RT-GRADIENT absolute difference in the RTT variances, as follows

End-to-end CC schemes consider round-trip time (RTT) as a RTT s (k) −RTT min (k)
key parameter for CC and use it in diverse ways. Loss-based RT (k) = (1)
RTT max (k) − RTT min (k)
schemes use RTT for RTO estimation and RTO adjustment to
limit the retransmission rate (e.g., [11], [12], [19], and [41]). RTT s (k), RTT max (k), and RTT min (k) were determined as
Delay-based and rate-based schemes use RTT measure- follows
ments to infer the possible congestion (e.g., [18], [23], [24],
and [28]). It is well-known that RTT variances can be used as RTT s (k) = (1−α)×RTT s (k −1)+α×RTT m (k) (2)
a good indication of the network state. Most solutions lever- RTT min (k) = min (RTT min (k − 1) , RTT m (k)) (3)
age TCP rules [19], [43] to estimate RTT samples using three RTT max (k) = max (RTT max (k − 1) , RTT m (k)) (4)
variables: measured RTT, estimated RTT, and RTT variation.
A smoothing factor was used to remove noise in the RTT where k and k-1 are the step k and k-1, respectively, of the
measurements. The minimum of all measured RTTs (or all sampling periods in the discrete time interval. The sampling
observed RTTs in a predefined time window) can be used period T(k-1, k) is the interval between two successive ACKs.
to determine the network state [42], [23]. Recent schemes RTTs (k) are the estimated RTT for each time interval (k-1,
proposed for CoAP [23], [24] use the RTT variation variable k). RTTm (k) is the current measured RTT at step k. α is a
to address the growth of RTT variance and define the regions parameter, and we choose α = 025 for a smooth estimation
of the network states. However, it has been recognized that the of RTT according to [12], [43]. RTTmin (k) and RTTmax (k)
difference between RTT variations is meaningful [18]. Thus, are the minimum and maximum RTT, respectively, in each
the relative growth of RTT variations must be considered. interval (k-1, k). RT(k) is the RT-gradient at step k. Based
We conducted several simulation experiments using on Eq. (1), the value of RT(k) is in the range of (0, 1).
NS-3 [54] to explore changes in round-trip time (RTT) dur- RT(k) is zero if RTT s (k) = RTT min (k), and RT(k) is one
ing congestion. In the experiments, ten CoAP clients sent if RTT s (k) = RTT max (k).
back-to-back packets to a remote server to build a congestion Fig. 4 shows the evolution of the RT-gradient according
situation. The common link bandwidth was 250 Kbps with to the variation of RTT, as shown in Fig. 3. The RT-gradient
a link delay of 50 ms. The simulation duration was 300 s. was varied between zero and one. RT-gradient values close
Fig. 3 shows the growth of the average RTT when congestion to one indicate the likelihood of congestion. Therefore, the
occurred. RT-gradient was a good input for our fuzzy control system.
FIGURE 4. Example of the RT-gradient.

FIGURE 3. Average RTT of CoAP in congestion.
As shown in Fig. 3, congestion started at 200 s with a sig- C. BOTTLENECK BANDWIDTH GRADIENT
nificant growth in the RTT. Various RTT peaks were observed The fuzzy control system is more efficient when a second
in the time interval between 90 and 200 s. The RTT peaks input is used. Intuitively, the traffic load can be selected.
may indicate congestion threats. However, single values of However, it is difficult to determine the maximum load as
the RTT or RTT variances are insufficient for predicting con- the threshold for congestion detection. Another possibility is
gestion. the use of a bandwidth-delay product (BDP). The BDP of a
In this study, we propose the RT-gradient to indicate connection is defined as the product of its round-trip delay
the difference and relative growth of RTT variances. The and bottleneck bandwidth [42]. However, BDP is often small
RT-gradient is defined as the ratio between the relative and in IoT environments. In addition, BDP is directly derived
105594 VOLUME 10, 2022

from RTT. Thus, BDP is not a good choice because both the link bandwidth, and number of nodes on the path). The
FCS inputs have the same effect. instantaneous bW(k) fluctuates depending on the number and
Therefore, we propose using bottleneck bandwidth for load of connections sharing the network path. The maximum
the second input of our FCS. Specifically, we propose a bWmax is computed at the end of the startup stage and remains
bottleneck bandwidth gradient (BG-gradient) instead of a unchanged. An analogy was given in [42], where the network
single bottleneck bandwidth value. As indicated in [42], path was a physical pipe and bWmax was its diameter. The
bottleneck bandwidth is one of the most important parameters instantaneous bW(k) of a connection is part of the maximum
for congestion control. The bottleneck bandwidth is defined bWmax . The duration of the startup stage can be between six
as the slowest link (or bottleneck) in the end-to-end path of and ten RTT cycles, as indicated in the next section. Based on
a connection. In practice, the bottleneck bandwidth continu- Eq. (5), the value of BG(k) is in the range (0, 1). BG(k) is zero
ously changes depending on the variable load and the number if dR (k) = 0, and BG(k) is one if dR (k) = bW max .
of active connections that share a common network path. Fig. 5 shows the evolution of the BG-gradient according
According to [42], if the network path is a physical pipe, to the variation in the data delivery rate. As shown in Fig. 5,
the maximum bottleneck bandwidth is its diameter. To avoid the BG-gradient varies between zero and one. BG-gradient
congestion, the transmission rate must be less than or equal values close to one indicate the possibility of congestion.
to the maximum bottleneck bandwidth. From this evidence, If the network is less congested, then the BG-gradient values
we can deduce that the data delivery rate must be less than or are close to zero. Thus, the BG-gradient was selected as the
equal to the maximum bottleneck bandwidth. second input for our fuzzy control system.
Let bWmax denote the maximum bottleneck bandwidth
and dR(k) be the instantaneous delivery rate in the discrete-
time interval T (k-1, k). The bottleneck bandwidth gradient
(BG-gradient) is defined as follows
min(bW max , dR (k))
BG (k) = (5)
bW max
The instantaneous delivery rate dR(k) can be computed as
follows
De (k − 1, k)
dR (k) = (6)
T (k − 1, k)
where De(k-1, k) is the amount of data delivered during time
interval T (k-1, k). The sampling interval T(k-1, k) for dR(k)
can be selected as the time interval between two successive
ACKs. FIGURE 5. Example of the BG-gradient.
The value of bWmax can be determined at the startup stage
of a connection as follows. The CoAP client continuously
sends back-to-back packets to the server during the startup
D. CONGESTION DEGREE
stage. The server recursively computes the minimal deliv-
ery time (Tmin ) between two successive received packets and We define the congestion degree (C-degree) as the output of
sends this value back to the client using piggyback ACK the fuzzy control system, which ranges from minus one to
responses. The client computes bWmax as follows plus one (−1 to 1). The C-degree can be used to interpret the
network state as follows:
s
bW max = max(bW (k), ) (7) If the C-degree value is greater than zero, we assume
Tmin that the network is in a non-congested state. The closer the
where s is the ratio between the probe packet size and data C-degree is to 1, the less congested is the network.
packet size. bW(k) is the estimated bottleneck bandwidth in If C-degree =1, it can be assumed that there is no conges-
step k. Our scheme uses probe packets to estimate the bottle- tion in the network. The operating point corresponds to the
neck bandwidth. In our implementation, the size of a probe left knee point, as shown in Fig. 1 (app-limited region). The
packet was 49 bytes, and the size of each data packet was sending rate can be aggressively increased.
106 bytes. At the end of the startup stage, the client obtains By contrast, if the C-degree value is negative, the network
the final values for bWmax . is assumed to be congested. The sending rate must be reduced
We used the same simulation experiments as those to avoid congestion. The decrease in the sending rate corre-
shown in Subsection III.B to explore the evolution of the sponds to a negative value of the C-degree. The closer the
BG-gradient in congestion. Using the experiments, we rec- C-degree is to −1, the more congested is the network. The
ognized that the maximum bWmax of a connection can be point with a C-degree = −1 is corresponding to the cliff point
accurately estimated within an interval of six to ten RTTs (see Fig. 1). If the C-degree value is zero, then the sending rate
under the fixed network conditions (fixed route, unchanged must remain unchanged.
VOLUME 10, 2022 105595

That is, the C-degree provides the direction and magni- variable u ranges over U . For instance, let µx (u) denotes
tude of the sending rate adjustment. If the load is low, the the membership function of a linguistic variable X and let
congestion possibility is low and the C-degree is positive. M̃ (medium) denote a fuzzy subset of U that assigns a meaning
If the load is high, the congestion possibility is high, and the to the term medium. We have
C-degree is negative. Therefore, by computing the C-degree,
M̃ (medium) = (u, µmedium (u)u[0, 1] (9)
we can determine the direction and the amount of increases/
decreases in the sending rate for a connection. Similarly, we define the term set for the second input as
Until now, we have already answered the issues raised in follows
Section I, that is, the decision on increase/decrease depends
on the sign of the computed congestion degree (C-degree). T (BG − gradient) = small,medium,large (10)
This implies that the decision corresponds to the RT-gradient Several types of shapes can be deployed for membership
and BG-gradient, which represent the current network state. functions including triangular, trapezoidal, and Gaussian.
The amount of increase or decrease depended on the value However, triangular and trapezoidal shapes are often used
of the C-degree. One round-trip time was selected as the to represent the membership functions of inputs and outputs.
sampling period for the RT-gradient and BG-gradient. The In this study, we applied triangular and trapezoidal shapes to
sending rate is adjusted for each RTT interval to avoid the membership functions as follows.
congestion. Let a, b, c, and d represent the x coordinates of the mem-
bership function µM (x) in M = (a, b, c, d), where M is a
E. DESIGN OF THE FUZZY CONTROL SYSTEM fuzzy set (a is the lower boundary, d is the upper boundary
As mentioned in the previous subsection, the fuzzy control where the membership grade is zero, and b and c are in the
system comprises four key modules: fuzzification, fuzzy rule middle, where membership grade is one). The trapezoidal
base, inference engine, and defuzzification. The design of shape membership function is defined as follows
the FCS followed the standard steps indicated in [49], [52], { { }}
x−a d −x
and [30]. µM (x) = max 0 min 1  (11)
b−a d −c
1) FUZZIFICATION If b coincides with c, let m represent the coincident coordi-
The function of this component is to represent the input nates of b and c. Then, we define a triangular shape member-
and output data with linguistic variables and to derive their ship function as follows
membership functions. This component converts crisp input { { }}
x−a d −x
data into fuzzy data. For each input, the number of linguistic µM (x) = max 0 min 1  (12)
m−a d −m
variables should be odd, from three to seven, as recommended
in [52]. Intuitively, the number of linguistic variables depends where M = (a, m, d) is a fuzzy set (a is the lower boundary,
on the scale of each input and output variable. However, d is the upper boundary where the membership grade is zero,
there is often no concrete scale for input. Furthermore, the and m is the center where the membership grade is one).
complexity of the system may increase with the number of Fig. 6 and Fig. 7 show the membership functions of the
linguistic variables. In the case of CoAP, we consider two linguistic variables for the inputs to the FCS.
inputs and three linguistic variables for each input in this
study.
The first input was the RT-gradient, which was normalized
to the range [0, 1]. The second input was the BG-gradient,
which was normalized to the range [0, 1]. We define the
following linguistic variables for the inputs:
• RT-gradient: small, medium, large
• BG-gradient: small, medium, large
Linguistic variables are ‘variables whose values are not
numbers but words or sentences in a natural or artificial
language’ [52]. According to the definition of linguistic FIGURE 6. Membership functions of RT-gradient.
variables in [52, p.142], we can demonstrate the linguistic
variables of RT-gradient input as follows. Let X denote a The three sets of linguistic variables for the input
linguistic variable with a label called ‘‘RT-gradient’’. The RT-gradient are: small (XS), medium (XM), and large (XL).
term set T for this input is as follows Similarly, there are three sets of linguistic variables for the
T (RT − gradient) = small,medium,large (8) input BG-gradient: small (YS), medium (YM), and large (YL).
Fuzzy sets may overlap each other in some parts. The size
Each term in this set is a fuzzy set. For our FCS, the of the overlapping parts depends on the characteristics of the
universe of discourse U is in the interval [0,1], and a base input characteristics.
105596 VOLUME 10, 2022

TABLE 2. Fuzzy Rules.
FIGURE 7. Membership functions of BG-gradient.
We propose membership functions for the output, that is,

the C-degree, of our FCS, as shown in Figure 8. The output
C-degree ranges from −1 to 1. These membership functions
represent the arguments indicated in subsection III.D. Five
linguistic variables were defined for the output as follows: 1) The membership grade of the result set was calculated.
This involves the use of a rule base (Table 2 ).
• C-degree: very low, low, medium, high, very high
2) Using inference methods for generating output fuzzy
The term set T for this output will be the following sets. There are several inference methods such as max-
min, max-product, and singletons. Our FCS uses the
T (C − degree) = verylow,low,medium,high,veryhigh
max-min method for inference because of its fast
Accordingly, linguistic variables for the output were operation.
divided into five sets: very low (ZVL), low (ZL), medium (ZM),
high (ZH), very high (ZVH). 4) DEFUZZIFICATION
This component is used to convert fuzzy output data into crisp
output data.
For defuzzification, this study used the well-known center
of gravity (CoG) approximation method [52]. The crisp val-
ues at the output can be approximated using the mean of the
centers as follows
∑N
i=1 Zi × µ(Z i )
C_degree = Z c = ∑ N
(13)
i=1 µ(Z i )
where Zc is the crisp output (mean of center of gravity among

N fuzzy sets), zi is the center of gravity of each output set,
FIGURE 8. Membership functions of FCS output (C-degree).
and µ(zi ) is the membership grade. The resulting Zc is the
C-degree, ranging between −1 and 1, which interprets the
network congestion state, as indicated in Subsection III.D.
2) FUZZY RULE BASE
This component defines the rules for determining the output IV. PROPOSED FuzzyCoAP
linguistic variables based on the input linguistic variables. In this section, we present the specific mechanisms of our
We propose the set of rules in Table 2. proposed protocol, FuzzyCoAP, using FCS designed in the
A rule base is a set of IF-THEN rules, each of which is previous section. FuzzyCoAP is an extended version of the
described by a fuzzy set, and fuzzy implication operators such basic CoAP over the UDP but with several modifications.
as AND and OR. In this study, the FCS had two inputs, each of FuzzyCoAP replaces the loss-based CC algorithm of basic
which had three linguistic variables. Our FCS uses the AND CoAP with a rate-based CC algorithm that uses the designed
operators. Thus, we obtained 3 × 3 = 9 fuzzy rules. FCS.
For instance, a rule can be described as follows: Fig. 9 provides an overview of the proposed FuzzyCoAP.
Rule 3: IF the RT-gradient is ‘‘Small’’ AND the BG- The shaded blocks represent the three core states in the pro-
gradient is ‘‘Large’’, THEN the congestion degree is ‘‘Low’’. posed scheme. The other blocks represent the core functions
of the FuzzyCoAP.
3) FUZZY INFERENCE ENGINE The novelty of FuzzyCoAP is the design of an FCS for
The fuzzy inference engine determines the fuzzy output set. the CoAP CC that detects congestion and controls the send-
This process consists of two steps: ing rate to avoid congestion based on the measurements of
VOLUME 10, 2022 105597

detection and returns it. During steady state, if packet loss is

detected, the sender enters the backoff state. At this moment,
several packets may be in flight, including recently trans-
mitted and retransmitted packets. Packet loss indicates that
congestion has occurred. To avoid further congestion, the
sender should not send further packets. In the backoff state,
the sender checks the ACK during each RTT interval. If an
ACK is received, then the sender updates the C-degree. Sub-
sequently, the sender returns to a steady state. Otherwise, the
transaction is considered to have failed after the maximum
transaction time, as defined in [1]. The proposed FuzzyCoAP
is presented in detail in the following subsections.
A. STARTUP
Algorithm 1 presents the pseudocode for the startup stage of
FuzzyCoAP.
FIGURE 9. Overview of the FuzzyCoAP scheme.
Algorithm 1 Startup
1: function Startup
RTTs and bottleneck bandwidth, namely, the RT-gradient and 2: mState = Startup
BG-gradient. Using dynamic rate control, FuzzyCoAP 3: if (Cycle > maxCycle) then
enables inflight packets and is efficient for burst data trans- 4: EndStartup()
fers. FuzzyCoAP controls the sending rate bounded by the 5: else
maximal bottleneck bandwidth of the connection, and keeps 6: packet ← SendNextPacket() //probe packets
the inflight packets limited to the bandwidth-delay product. 7: if (ACK == true) then
FuzzyCoAP primarily consists of algorithms at the sender 8: nACK = nACK + 1
to achieve effective congestion control. In FuzzyCoAP, each 9: Update 1(RT(k), BG(k). dR(k))
sender estimates bWmax and dR(k) during the startup stage 10: IPG = 1dR(k)
of the connection. The startup stage is typically in the range 11: else
of six to ten RTTs (we use ten RTTs in our implementa- 12: if ((nACK == 0)&&(Cycle = maxCycle)) then
tion). The estimated dR(k) is used to determine the sending 13: Restart()
rate. In steady state, the sender continuously estimates RTT, 14: endif
bW(k), and dR(k) whenever an ACK is received. The esti- 15: endif
mated RTT, bW(k), and dR(k) values are used by the FCS to 16: Cycle = Cycle + 1
compute the C-degree, which is used to adjust the sending 17: Schedule (IPG, Startup)
rate. In addition, FuzzyCoAP uses the C-degree to adjust the 18: endif
RTO values as follows 19: end function
20: function EndStartup()
RTT s (k) = 075×RTT s (k −1)+025×RTT m (k) (14) 21: Srate = nACK (now − t)
D_RTT s (k) = RTT s (k) − RTT s (k − 1) (15) 22: (IPG = 1/Srate
23: Update2(bWmax )
RTO (k) = RTT s (k)+C_degree(k)×D_RTT s (k) (16)
24: mState = Steady
where D_RTT s (k) is the RTT variance computed at step 25: Steady()
k, C_degree(k) is the computed crisp output of the FCS 26: end function
at step k, and RTO(k) is the retransmission timeout value
at step k. The estimation of RTTs (k) follows Eq. (2) using At startup, a FuzzyCoAP client performs its probe phase
α = 025 [43]. to determine bWmax and the start sending rate. To this end,
If the sender does not receive an ACK within the computed the client sends back-to-back packets to probe bottleneck
RTO, the sender attempts to retransmit the corresponding bandwidth. The startup phase does not use the timeout timer
packet and checks for the possible transmission of other pack- for the probe packets, that is, the lost probe packets are not
ets. Four retransmissions are allowed for each retransmitted retransmitted. In each cycle, the client sends the next probe
packet. The RTO value is updated for each retransmission. packet (line 6). Upon receiving a packet, the server imme-
FuzzyCoAP does not estimate the bottleneck bandwidth from diately sends an ACK back to the client. When an ACK is
retransmitted packets. received (line 7), the client updates the necessary parameters
After four unsuccessful retransmissions, the timeout timer (line 9), as indicated in Eq. (1)–(4) and (5)–(7), using the
function marks the corresponding lost packet for loss function Update1(RT(k), BG(k), dR(k)), and increments the
105598 VOLUME 10, 2022

number of received ACKs by one (line 8): Algorithm 2 Steady

1: function Steady
nACK = nACK + 1 (17)
2: mState = Steady
The pacing time IPG was updated accordingly (line 10). 3: t = now
If no ACK is received, the client checks for connection time- 4: BDP = bWmax × RTTmin
out (line 12). If nACK 6 = 0 or Cycle < maxCycle, the client 5: if (inflight ≤ BDP) then
invokes the next startup cycle after IPG seconds using the 6: packet ← SendNextPacket()
schedule function (lines 16-17). In the last loop (i.e., Cycle= 7: if (t ≥ last_adjust + RTTs ) then
maxCycle), the variable nACK can be less than or equal to 8: Update(RT(k). BG(k))
maxCycle. If nACK 6 = 0 (line 12), the client considers that at 9: C_degree = FCS(RT(k), BG(k))
least one ACK has been received. The client then continues 10: Srate = Srate + C_degree × (1RTTs )
to schedule the next startup (lines 16-17). At the beginning 11: IPG = 1Srate
of the next loop, the startup phase finishes (lines 4 and 20) 12: RTO_Update(C_degree, RTO)
because Cycle > maxCycle. If nACK = 0 and Cycle = max- 13: last_adjust = t
Cycle (line 12), the client does not receive an ACK after all 14: endif
cycles. In this case, the client must restart the connection 15: else
from the beginning (line 13). The initial IPG is unimportant 16: if (ACK == true) then
because it changes when an ACK is received (line 10). In our 17: packet ← SendNextPacket()
implementation, we initialize the IPG by one millisecond for 18: endif
back-to-back packet transmission. The variable t is the start 19: endif
time of the startup state. 20: if (PacketLoss) then
At the end of the startup stage (line 20), the client computes 21: mState = Backoff
the sending rate Srate (line 21) and IPG (line 22) and updates 22: Backoff()
the final bottleneck bandwidth bWmax (line 23) using (7). The 23: else
FuzzyCoAP client then enters a steady state (line 25). 24: Schedule (IPG, Steady)
The startup stage typically lasts for six to ten RTT cycles. 25: endif
This is because the connection and network require time to 26: end function
be stable. Through experiments, we found that an interval of
six RTT cycles may be sufficient for the startup phase. Note
that BBR [42] requires eight RTT cycles and BDP-CoAP [23] updates the new RTO (Line 12) and the next adjustment time
requires ten RTT cycles for the initial stage. (line 13).
If the number of inflight packets exceeds BDP (line 15), the
B. STEADY client must slow the transmission. The reason is that there are
The pseudocode for the steady state of the FuzzyCoAP is a lot of inflight packets that can cause congestion. To this end,
presented in algorithm 2. the client sends only a new packet (line 17) when an ACK is
At the beginning of the steady stage, the FuzzyCoAP client received (line 16).
computes the bandwidth-delay product BDP (line 4) based on During the steady state, the client checks for packet loss
the bottleneck bandwidth bWmax computed at the startup. The (line 20). Flag PacketLoss causes a gap in the receiving ACKs
number of inflight packets will be checked. If this number is for the transmitted packets. Packet loss indicates that con-
less than or equal to the BDP (line 5), the client sends the next gestion has occurred. Successive packet losses occurred in
data packet (line 6). The client sets the initial RTO for each the case of heavy congestion. If packet loss is detected, the
new packet. If the timer expires, the timeout timer function client exits the steady state and enters the backoff state (lines
(not presented in the algorithm) checks for a retransmission. 21-22). Otherwise, the client schedules the next loop of the
If the client has not received an ACK from the server for the steady state after IPG seconds (line 24) by using the function
packet and the number of retransmission attempts is less than schedule (IPG, steady).
four, the timeout timer function retransmits the corresponding The FuzzyCoAP client adjusts the sending rate Srate (k)
packet and sets an updated RTO. If four retransmissions occur based on C_degree(k) as follows (line 10):
unsuccessfully, the timeout function marks a flag PacketLoss • If 1 ≥ C_degree(k) > 0, the sending rate will be
for the lost packet. increased. The amount of the increase is the absolute
After each estimated RTT (line 7), the client updates the value of the congestion degree C_degree(k), which
RT_gradient and BG_gradient (line 8). It then calls the FCS determines a fast or slow increase.
function to compute C_degree (line 9). The client adjusts
the sending rate (line 10) and the new inter-packet interval Srate (k) = Srate (k − 1) + C_degree(k)x1RTT s (k)
IPG (line 11). The RTTs are smooth estimated RTT computed • If C_degree(k) = 0, the sending rate will be unchanged.
based on Eq. (14) for each RTT cycle. A smooth RTT estima-
tion helps to avoid the impact of RTT fluctuations. The client Srate (k) = Srate (k − 1)
VOLUME 10, 2022 105599

• If −1 ≤ C_degree(k) <0, the sending rate will be further packets. Packets that were already sent in the previous
decreased. The amount of the decrease is the absolute stage (including the retransmitted packets) may be in flight.
value of the congestion degree C_degree(k), which If an ACK is received (line 4), the client assumes that conges-
determines a fast or slow decrease. tion has been resolved. The client then sends a new packet
(line 5), updates the parameters (line 6-10), and returns to
Srate (k) = Srate (k − 1) − C_degree(k)x1RTT s (k) steady state (line 11-13).
FuzzyCoAP differs from other CoAP schemes in that it If no ACK is received (line 14), the client checks for maxi-
allows for the sending of inflight packets. This means that mum transmission time (defined in [1]). If no ACK is received
FuzzyCoAP attempts to send the next packets while the after this value (line 15), the transaction is considered to have
retransmitted packets are in flight. FuzzyCoAP does not failed (line 16). The connection stopped. Otherwise, the client
use BW estimates from the retransmissions. This is because schedules the next backoff period after the next pacing time
parameters such as RTT and delay of retransmitted packets (line 18-19). The client may switch between steady state and
can lead to incorrect estimation of the bottleneck bandwidth, backoff in the case of several packet losses due to heavy
as indicated in [23], [42], and [43]. congestion. This change depends on the occasional ACK
Packet duplication may occur because the retransmitted received for the transmitted or retransmitted packets.
packet is sent to the receiver during flight. In addition, the
V. PERFORMANCE EVALUATION
received packets may be disordered at the receiver owing
to the retransmission. These issues can be solved at the In this section, we first present the simulation setup used
higher protocol layer, where the application can rearrange the for the performance evaluation of our FuzzyCoAP. Then,
sequences of the received packets and discard the duplicated we present results for a variety of different simulation scenar-
packets. However, these issues are beyond the scope of this ios. We use the network simulator NS-3 [54] as the simulation
study. platform to implement the basic CoAP and the FuzzyCoAP.
NS-3 is a discrete event network simulator that supports fast
and efficient prototyping.
C. BACKOFF
The core implemented functions of the basic CoAP are
Algorithm 3 shows the pseudocode for the backoff state.
startup, send, receive, retransmit, and timeout-timer. For
FuzzyCoAP enters this state in the case of congestion, i.e.,
FuzzyCoAP, we implemented the core functions at the
if packet losses are detected.
client, including startup, steady, backoff, fuzzy control, send,
receive, retransmit, and timeout-timer. On the server, both
Algorithm 3 Backoff FuzzyCoAP and basic CoAP perform the main functions for
1: function Backoff receiving packets and sending ACKs. The method for creat-
2: mState = Backoff ing CoAP headers was adapted from [55], [56]. In [55], the
3: t = now authors presented a partial implementation of the basic CoAP
4: if (ACK == true) then for multicast topology and DNS experiments in NS-3. This
5: packet ← SendNextPacket() implementation was based on the code sketch for CoAP in
6: Update(RT (k), BG(k)) the Spark Core system provided in [56]. Both authors in [55]
7: C_degree = FCS(RT(k), BG(k)) and [56] used the same method to create basic CoAP header
8: Srate = Srate + C_degree × (1RTTs using standard parameters indicated in RFC 7252 [1]. The
9: IPG = 1Srate same standard parameters were used for the CoAP header.
10: RTO_Update(C_degree. RTO) Network simulator NS-3 provides numerous facilities to
11: mState = Steady create various traffic scenarios similar to real networks. In our
12: Steady() simulation, all clients were implemented at the wireless nodes
13: return in the Wi-Fi network. The clients are connected to the server
14: else through a Wi-Fi access point (AP node) and a bottleneck link
15: if (t > maxTransactionTime) then (see Fig. 10). The clients and access point (AP) are imple-
16: ConnectionFailed() mented using the standard IEEE 802.11, standard internet
17: else stack, standard mobility model, and standard interface models
18: next_pacing = t + IPG provided by NS-3 [54].
19: Schedule (next_pacing, Backoff) In our simulation, the size of the CON packet was
20: endif 106 bytes, including a fixed header of 4 bytes and payload
21: endif of 102 bytes. The size of an ACK message was 49 bytes,
22: end function including 4 bytes added in the option field. This field is
used by the server to piggyback the delivery time to clients.
The client must slow transmission to avoid further conges- The clients use delivery time to accurately measure the delay
tion. In this state, the client continues to check the acknowl- and bottleneck bandwidth. To investigate different congestion
edgment from the server after a pacing time without sending states and dynamic bottleneck bandwidth, we used various
105600 VOLUME 10, 2022

FuzzyCoAP or basic CoAP. Heterogeneous traffic scenar-

ios are used for a mixture of FuzzyCoAP, basic CoAP,
and unresponsive clients. The unresponsive client used in
the experiment was an unconfirmable (NON) CoAP client
that sent messages without the need for acknowledgment.
Dynamic traffic scenarios use TCP flow and unresponsive
flow (UDP) as background traffic. Unresponsive flow dynam-
ically changes the transmission rate. The purpose of these
experiments was to demonstrate the behavior of the schemes
under dynamic network conditions.
We used random start times for the flows in all experi-
ments. The random seed was set between 0 ms and 200 ms
FIGURE 10. Simulation model for the homogenous traffic scenarios. to generate the start time for each flow. Thirty random test
runs were conducted for each experiment. We used real-time
tracing data for delay, retransmission, packet duplication, and
configuration parameters for the link bandwidth and delay throughput to produce the graphic data. The instantaneous
between the access point and the server. The details are pro- throughput was calculated using the received packet and the
vided for specific traffic scenarios. Moreover, we assume time difference between sending and receiving packets at the
that each client has sufficient collected data to demonstrate server. The average values of the delay and throughput were
burst traffic transfer. All clients can generate two traffic types: calculated using confidence intervals with a normal distribu-
continuous traffic and burst traffic. The simulation time was tion.
300 s for all experiments. Although various link bandwidths and link delays can be
Although many CoAP variants have been proposed, the selected for the simulation experiments, we used specific link
basic CoAP has been standardized by the IETF [1], [57]. bandwidths and link delays to demonstrate the bottleneck
In Section II, we explain how the basic CoAP and most of bandwidth for cases with no congestion, single congestion,
its variants use loss-based approaches. In this paper, it will and heavy congestion. The aim of these experiments was to
be meaningful to compare two types of CC schemes: loss- compare the schemes under the same network conditions.
based and rate-based schemes. Therefore, we focused only on
the performance comparison between our rate-based Fuzzy-
CoAP and basic CoAP, because basic CoAP is representative B. HOMOGENOUS TRAFFIC SCENARIOS
of loss-based CoAP variants. 1) CHECKING THE FUZZY CONTROLLER
We evaluated FuzzyCoAP and the basic CoAP using the The network topology for homogenous traffic scenarios is
following indicative metrics: illustrated in Fig. 10. To verify the fuzzy controller, three
• End-to-end delay: The delay between the sending time FuzzyCoAP flows were used. In these experiments, the link
at the client and the receiving time at the server. bandwidth between the AP and router was 250 Kbps with
• Throughput: the delivery rate computed at the server for a link delay of 50 ms. The link between the router and
each time interval of one RTT. server had a bandwidth of 45 Kbps and a link delay of
• Retransmission: the number of retransmissions and the 300 ms. The three FuzzyCoAP flows shared a common link
percentage of retransmissions. bandwidth. The measured bottleneck bandwidth was approx-
• Packet duplication: the number of duplicated packets. imately 2.6 Kbps, which was much smaller than the link
• Packet loss: the number and percentage of packet losses. bandwidth in these experiments owing to the competence of
the flows.
A. SIMULATION SETUP Fig. 11 presents the behavior of the RT-gradient,
Two network topologies were used for simulation: star and BG-gradient, and computed congestion degree (C-degree)
dumbbell topologies. In the star topology, clients send data over time for FuzzyCoAP flows.
to a common server via the access point and router. The As shown in the figure, the clients started shortly after the
link between the router and the server was the bottleneck initial stage and sent burst data. The load increased quickly
link for the experiments. In dumbbell topology, clients send (BG-gradient line). RTT increased accordingly (RT-gradient
data to different servers via the access point, network router, line). A short positive C-degree peak at 10 s indicates that
and edge router that connects to the remote servers. The link the client tried to test the available bandwidth. Subsequently,
between the network router and edge router was considered the C-degree became negative. This implies that the client
the bottleneck link for the experiments. must send packets at a lower rate. In the interval between
We used three types of traffic scenarios for experi- 10 s and 70 s, the client retained the sending rate to maintain
ments: 1) homogenous traffic, 2) heterogenous traffic, and its performance. The rate was updated at each RTT interval.
3) dynamic traffic scenarios. Homogenous traffic scenar- The instantaneous packet delay was large, because several
ios are used for clients using the same CC scheme, either packets were on flight to the server. At 75 s, the C-degree
VOLUME 10, 2022 105601

FIGURE 11. Behavior of RT-gradient, BG-gradient, and C-Degree. FIGURE 13. End-to-end delay of FuzzyCoAP flows.
2) PERFORMANCE OF FuzzyCoAP FLOWS

became positive, indicating a low congestion threat. The
We used the same network topology as that shown in
client can then increase the sending rate. That is why the load
Fig. 10 for the performance evaluation of the three Fuzzy-
(BG-gradient) was increased. In the time interval from 90 s
CoAP flows. Fig.13 presents the end-to-end delay of the
to 160 s, the C-degree decreased owing to the increase in the
FuzzyCoAP flow. After the initial few seconds, the client
RT-gradient. The client must reduce the sending rate to avoid
attempted to measure bottleneck bandwidth. The measured
congestion. The same control process was repeated for the
value was 2.6 Kbps for each flow. Subsequently, clients
subsequent intervals.
started to send burst data. At the start of the connection, most
The variation in the C-degree depends on the available
of the packets exhibit a small delay. Packet delay increases
bandwidth of the bottleneck link. As presented, FuzzyCoAP
with an increasing number of inflight packets. If the load is
can predict early congestion based on the computed C-degree
high, more packets are delayed. However, we can see that
and adjusts the sending rate accordingly.
the average packet delay was less than 410 ms for all flows.
This is because FuzzyCoAP limits the sending rate below
the bottleneck bandwidth. According to the current measured
available bandwidth, FuzzyCoAP flows attempt to maintain
the sending rate smaller than the bottleneck bandwidth to
avoid congestion. Thus, FuzzyCoAP can limit the maximum
delay in flow.
There were some spikes in the delay. This is because of the
competing packets of flows. As the number of inflight packets
increases, more spikes are observed. However, the values of
the spikes were less than 420 ms for all flows. This implies
that the instantaneous sending rate may temporarily be larger
than the bottleneck bandwidth without causing congestion,
as explained in Section III.
Fig. 14 shows the throughput of the three FuzzyCoAP
flows in the homogeneous experimental set.
Although the bottleneck bandwidth of the shared link was
FIGURE 12. Change of C-Degrees of FuzzyCoAP flows. 2.6 Kbps, the throughput of each flow reached an aver-
age of 8 Kbps. This means that FuzzyCoAP can achieve a
In Fig. 12, we compare the C-degrees of the three Fuzzy- high performance. The throughput may vary at the begin-
CoAP flows sharing a common bottleneck link. As shown in ning of the flow, but it becomes more stable in the long
the figure, the C-degrees are increased or decreased accord- term.
ing to the RT-gradient and BG-gradient inputs, as shown in In Table 3, we present the comparative performance of the
Fig. 11. The changes in the C-degrees are different because three FuzzyCoAP flows using various metrics. In this set of
the flows compete for the available bandwidth of the bot- experiments, no packet loss was observed. There was only
tleneck link. However, the difference was small, indicating one retransmission for each flow owing to timeout. How-
fairness between the flows. ever, this retransmitted packet is duplicated. This is because
105602 VOLUME 10, 2022

FIGURE 15. Simulation model for the heterogenous traffic scenarios.
The link between the router and the edge router is a bot-
tleneck. For the link between the edge router and servers,
FIGURE 14. Throughput of FuzzyCoAP flows.
we used a higher link bandwidth to quickly solve the inflight
packets. This configuration ensures that only one bottleneck
link exists in the end-to-end connection path.
Fig. 16 shows a comparison of the packet delays in Fuzzy-
FuzzyCoAP uses variable RTOs. In the case of a small RTO, CoAP and basic CoAP flows. As indicated in the figure, the
a packet may be received immediately after its timeout, result- packet delay fluctuated in both schemes owing to competition
ing in the retransmission of its duplication. However, no con- between the flows. If the load increases, more packets will be
gestion loss occurred during this experiment. Note that the delayed, and the delay may increase. However, the maximum
delay was not computed for retransmitted duplications. The delay was less than 430 ms for all the flows. The density in
results indicate that FuzzyCoAP flows can compete for high the plot indicates the number of packets sent by each flow,
throughput without congestion loss. Congestion situations with a corresponding delay.
will be studied in the subsequent experiments.
TABLE 3. Performance comparison: FuzzyCoAP flows.
FIGURE 16. End-to-end delay of FuzzyCoAP and basic CoAP.

C. HETEROGENOUS TRAFFIC SCENARIOS
1) COMPARATIVE PERFORMANCE FOR THE FuzzyCoAP AND For the basic CoAP, the average delay was 390.31 ms for
BASIC CoAP FLOWS 389 packets sent within 300 s of the simulation. The confi-
We used a dumbbell network topology, as shown in Fig. 15, dence interval was computed for 389 samples using a confi-
for the heterogeneous traffic scenarios (i.e., a mixture of basic dence level of 99%, giving confidence intervals of (389.46,
CoAP and FuzzyCoAP flows). 391.17). The sending rate does not change. The delay varia-
For the experiments, the following parameters were used: tion was only due to the delayed ACKs and competition of
- The link bandwidth between the AP and router the flows.
was 250 Kbps with a link delay of 50 ms. In the case of FuzzyCoAP, the average delay was
- The link bandwidth between the router and the edge 392.43 ms, but for 2558 packets. The confidence interval
router was 60 Kbps with a link delay of 300 ms. was computed for 2558 samples using a confidence level of
- The link bandwidth between the edge router and servers 99%, giving confidence intervals of (392.02, 392.85). That is,
was 1 Mbps with a link delay of 20 ms. the FuzzyCoAP successfully delivered more packets than the
VOLUME 10, 2022 105603

basic CoAP. This is because FuzzyCoAP sent higher sending confidence level of 99%. In contrast, the average throughput
rates using FCS. It had more packets in flight and, in turn, was approximately 8.35 Kbps in FuzzyCoAP with confidence
more delay variation owing to the CC control. This is why intervals of (8.24, 8.50) using a confidence level of 99%. This
FuzzyCoAP has more delayed packets than the basic CoAP. means that FuzzyCoAP achieved high performance without
However, the sending rate of FuzzyCoAP was bounded by the congestion. Table 4 presents a performance comparison of
bottleneck bandwidth (60 Kbps in these experiments). Thus, FuzzyCoAP and CoAP.
FuzzyCoAP limits the maximum delay in flows and avoids The FuzzyCoAP flow successfully sent 2558 packets,
congestion. whereas the basic CoAP flow sent only 389 packets on aver-
Fig. 17 shows the throughput evaluation for the age. The average throughput of FuzzyCoAP was much higher
FuzzyCoAP and basic CoAP flows. Owing to the bottle- than that of the basic CoAP flows. Both schemes exhibited
neck bandwidth and competition of flows, the basic CoAP no packet losses. No congestion loss was observed in either
flow cannot send more packets than the allocated available scheme. The average delay was 392.43 ms for 2558 packets
bandwidth. By contrast, FuzzyCoAP can send more packets. in FuzzyCoAP. The basic CoAP flows had an average delay
At startup, the FuzzyCoAP flow attempted to measure the of 390.31 ms for 389 packets. This means that FuzzyCoAP is
available bandwidth. This is why there was some spike in more efficient than the basic CoAP because it can maintain a
the figure. Subsequently, the FuzzyCoAP flow attempted to high throughput with a low packet delay in the competition.
increase throughput while avoiding congestion. As explained A single retransmission was observed in FuzzyCoAP
in Section III, the instantaneous sending rate may be tem- owing to timeout. This retransmitted packet was dupli-
porarily larger than the bottleneck bandwidth, without caus- cated. This is because of the variable RTOs of FuzzyCoAP,
ing congestion. The results provide evidence that FuzzyCoAP as explained previously. In addition, neither scheme com-
operates in a congestion avoidance zone with a high through- putes the delay for the retransmitted duplications. Duplicated
put and low delay, as shown in Figure 1. packets were discarded and did not affect the average delay of
the flows. A retransmission percentage of 0.04% is acceptable
for a high number of packets sent by FuzzyCoAP.
The results indicated that FuzzyCoAP flows can send more
packets with congestion avoidance based on the FCS. Fuzzy-
CoAP is more efficient than basic CoAP in terms of high
throughput, high received rate, and acceptable delay under
high-load conditions.
2) SINGLE CONGESTION SCENARIOS

In this experimental set, we investigate the case of a single
congestion situation by adding an unresponsive active flow.
This active flow sent several packets at a high sending rate
ranging from 20 to 90 Kbps to cause a single congestion dur-
ing the time interval from 50 to 120 s for the basic CoAP flow
and FuzzyCoAP flow. Fig 18 shows the delay comparison
between the FuzzyCoAP and basic CoAP flows. The delay
values were large between 50 s and 130 s because of several
FIGURE 17. Throughput comparison for FuzzyCoAP and basic CoAP. retransmission timeouts.
Again, there were more delayed packets in FuzzyCoAP
TABLE 4. Performance comparison: FuzzyCoAP and basic CoAP. than in basic CoAP because FuzzyCoAP sent more packets
than basic CoAP. However, the average delay in FuzzyCoAP
was less than that in the basic CoAP, owing to the variable
RTOs. The RTO was doubled for each retransmission in both
the schemes. Thus, the delay was longer than 25 s for some
retransmitted packets.
Fig. 19, Fig. 20, and Fig. 21 present the retransmissions,
duplicated retransmissions, and throughput of FuzzyCoAP
and basic CoAP, respectively, under the same single con-
gestion. There were nine retransmissions in in FuzzyCoAP
and seven in the basic CoAP, as indicated in Fig. 19. The
vertical axis represents the number of retransmission attempts
for each packet. In this figure, four packets are success-
The average throughput of the basic CoAP flows was fully received using four retransmission attempts for both
1.27 Kbps with confidence intervals of (1.26, 1.28) using a the schemes. In Fig. 20, the number of duplicated packets is
105604 VOLUME 10, 2022

FIGURE 18. Delay of schemes in single congestion situation. FIGURE 20. Duplicated packet retransmissions in single congestion.
FIGURE 19. Retransmissions of schemes in single congestion. FIGURE 21. Throughput of schemes in single congestion.
one, two, or three if the same packet is duplicated one, twice, to other flows. There was only one FuzzyCoAP flow and
or thrice, respectively. The results indicated that FuzzyCoAP one basic CoAP flow in the time interval from 130 to 300 s.
and basic CoAP have the same number of duplicated packets The FuzzyCoAP flow gained the bandwidth released by the
(i.e., the same four duplicated packet retransmissions) under unresponsive flow. This is why its throughput was higher after
these experimental conditions. 130 s compared to the previous time interval. The results
Fig. 21 shows the average throughput of both schemes. indicate that FuzzyCoAP can achieve a higher performance
At startup, the throughput increased with the load. Owing to than the basic CoAP when the network operation becomes
the competition with the unresponsive flow, the throughput normal without congestion.
of FuzzyCoAP was approximately 1.8 Kbps and remained Table 5 summarizes the results of the experimental set.
unchanged from 0 s to 50 s. The throughput of the basic CoAP Within a simulation time of 300 s, the FuzzyCoAP flow
was unchanged at approximately 1.4 Kbps during the same sent 1660 packets. Among them, 1658 packets were success-
time interval. When congestion occurred from 50 s to 130 s, fully received, and two packets were lost because of con-
both schemes were in the backoff phase with low throughput. gestion. By contrast, the basic CoAP flow sent only 372
After the congestion had been resolved at 130 s, both packets, with 370 successful received and only two lost
schemes attempted to improve performance. The Fuzzy- packets. This is because FuzzyCoAP can adapt the sending
CoAP flow checked for available bandwidth and achieved a rate based on the FCS according to the congestion state,
throughput of 8.50 Kbps. In contrast, the throughput of the whereas basic CoAP cannot. The number of retransmis-
basic CoAP flow was only approximately 1.4 Kbps. The unre- sions was nine in FuzzyCoAP and seven in the basic CoAP.
sponsive flow terminated and released its occupied bandwidth Both schemes had four packet duplications. However, the
VOLUME 10, 2022 105605

percentages were much lower for FuzzyCoAP owing to the

high number of delivered packets. The average delay in
FuzzyCoAP (458.64 ms) was lower than that of the basic
CoAP (650.23 ms). Consequently, the average throughput of
the FuzzyCoAP (5.40 Kbps) was much higher than that of the
basic CoAP (1.21 Kbps). The mean values were computed
using 1658 samples in FuzzyCoAP and 370 samples in basic
CoAP.
The results indicated that in the case of single congestion
scenarios, FuzzyCoAP is more efficient than basic CoAP
in terms of average throughput, average delay, packet loss,
retransmissions, and duplication percentages.
3) HEAVY CONGESTION SCENARIOS

In this set of experiments, we investigated the case of heavy
congestion by adding an unconfirmable CoAP flow. The
FIGURE 22. Delay of schemes in heavy congestion.
common link bandwidth was changed to 75 Kbps with a
link delay of 300 ms. The unresponsive flow started sending
packets at 2 Kbps during the time interval from 0 to 160 s. TABLE 5. Performance comparison under single congestion.
At 160 s, the rate was increased in a stepwise manner by

1 Kbps during the time interval from 160 to 200 s. This action
aimed to create severe congestion at the end of the simulation
period. After 200 s, the unresponsive flow decreased its rate
in a stepwise manner by 2 Kbps to quickly resolve the inflight
packets. Heavy congestion can be expected in the time inter-
val between 180 s and 280 s. Using this experimental set,
we show the behavior of FuzzyCoAP and basic CoAP under
a heavy congestion situation.
Fig 22 shows the delay for both schemes. During the inter-
val from 0 to 160 s, both the FuzzyCoAP and basic CoAP
schemes operated without congestion. As the load increased
with unresponsive flow, the delay in both schemes increased.
Several retransmissions occurred from 155 to 180 s. At 180 s,
packet losses were observed in both schemes (the delay was
not computed for lost packets). The delay values were large
between 220 s and 280 s because of the retransmission time-
out of the packets. The delay plot of FuzzyCoAP is sparser
than that of the basic CoAP. This means that FuzzyCoAP
had fewer delayed packets than the basic CoAP. The figure
indicates that the average delay in FuzzyCoAP was less than
that in the basic CoAP. This is because FuzzyCoAP uses
variable RTOs provided by the FCS. Thus, the number of
retransmissions in FuzzyCoAP was less than that in the basic
CoAP (see the density of the plot).
Fig. 23 presents the retransmissions for both schemes.
As indicated, there were several retransmissions in both
schemes during the congestion interval. Most packets
required a maximum number of four retransmissions. This is FIGURE 23. Retransmissions of schemes in heavy congestion.
why the average delay was high for both schemes. In the case
of heavy congestion, FuzzyCoAP attempted to retransmit
lost packets similar to basic CoAP. However, the retransmis- Fig. 24 shows the duplicated retransmissions in the Fuzzy-
sions of FuzzyCoAP were less than those of the basic CoAP. CoAP and the basic CoAP. Several packets were duplicated
The number of retransmissions was 669 for FuzzyCoAP during retransmission in both schemes. The number of dupli-
and 2954 for the basic CoAP. This is because the variable cations was 571 for FuzzyCoAP and 922 for basic CoAP.
RTOs in FuzzyCoAP help reduce the number of unnecessary As shown in the figure, several packets were duplicated four
retransmissions. times. The number of duplications used one time, two times,
105606 VOLUME 10, 2022

TABLE 6. Performance comparison under heavy congestion.
received packets in FuzzyCoAP was significantly higher than

that in the basic CoAP. This number was 2020 (95.92%) in
FIGURE 24. Duplicated packet retransmissions in heavy congestion. FuzzyCoAP and 1840 (58.01%) in the basic CoAP. More
lost packets were in basic CoAP than in FuzzyCoAP. The
number of lost packets was 86 (4.10%) for FuzzyCoAP and
and three times was smaller. The duplicated packets were dis- 1332 (41.99%) for basic CoAP. The number of packet retrans-
carded at the receiver and neglected in the delay computation. missions was 669 (31.77%) in FuzzyCoAP, which was much
smaller compared to 2954 (93.13%) in basic CoAP. The num-
ber of duplicated packets was 571 (27.11%) for FuzzyCoAP,
and 922 (29.07%) for basic CoAP. All percentage values were
computed with respect to the number of packets sent. Due to
the higher number of successful received packets (duplicated
packets were excluded), the average delay was 4304.14 ms
in FuzzyCoAP, which was much smaller than 8639.60 ms
in basic CoAP. The average throughput was 6.97 Kbps in
FuzzyCoAP and was 6.32 Kbps in basic CoAP.
The simulation results indicated that FuzzyCoAP provided
better performance than the basic CoAP in the case of heavy
congestion.
D. DYNAMIC TRAFFIC SCENARIOS

1) DYNAMIC SCENARIOS USING FuzzyCoAP, BASIC CoAP,
AND UNRESPONSIVE FLOWS
Using this experimental set, we studied the behavior of
FIGURE 25. Throughput of schemes in heavy congestion. FuzzyCoAP and the basic CoAP in dynamic traffic scenar-
ios. We used the same network topology with ten flows,
In Fig. 25, we present the throughput comparison of the as shown in Fig. 15. One FuzzyCoAP flow competes for the
schemes. It should be noted that the average throughput was available bandwidth with eight basic CoAP flows and one
computed for acknowledged packets, including duplicated non-confirmable flow (a basic UNCON CoAP flow, called
packets. Keeping this in mind, the plot does not reflect the BUNCON flow). The BUNCON flow started sending pack-
real throughput of the flows (i.e., only acknowledged packets at a rate of 0.5 Kbps. The rate was increased in a step-
ets). The condensed plot of the basic CoAP was due to many wise manner to 25 Kbps. Subsequently, the rate dropped to
retransmissions and duplications from 230 s to 300 s. The real 0.5 Kbps. This procedure was repeated three times. Finally,
average throughput of the flows was smaller in these heavy the BUNCON flow decreased its rate and stopped at 280 s.
congestion scenarios. Although the plot of FuzzyCoAP was The aim of this action was to create a dynamic network con-
sparser, FuzzyCoAP provided a real average throughput that dition for all the flows.
was much higher than that of the basic CoAP. Fig. 26 shows the delay in the FuzzyCoAP, basic CoAP,
Table 6 presents a performance comparison of the schemes and BUNCON flow. As indicated, the delay of all flows
in heavy congestion scenarios. increased during the short congestion situation at 55, 110,
As shown in the table, the number of sent packets was and 150 s. The high load was caused by the increased rate
high in both schemes owing to the high bandwidth and num- of BUNCON flow during these time intervals. The measured
ber of retransmissions. However, the number of successful delay was less than 800 ms for FuzzyCoAP, whereas it was
VOLUME 10, 2022 105607

2) DYNAMIC SCENARIOS USING FuzzyCoAP, BASIC CoAP,

UDP, AND TCP FLOWS
In this experimental set, we compared the performance of
FuzzyCoAP and basic CoAP in the case of background traf-
fic using UDP and TCP flows. The same network topology
was used, as shown in Fig. 15. However, the bottleneck link
bandwidth was set to 500 Kbps with a link delay of 500 ms.
The TCP flow was established using the standard TCP socket
of the network simulator NS-3 with a data rate of 10 Mbps
and a data segment size of 1040 bits. The UDP flow was
created using the standard UDP socket of NS-3. The UDP
flow started with a data rate of 20 Kbps. The rate was then
changed to 50 Kbps at 80 s, 150 Kbps at 150 s, and 5 Kbps at
200 s. The purpose of this experiment was to create mixed
dynamic background traffic scenarios for simulation using
FIGURE 26. Delay performance in dynamic traffic scenarios. the FuzzyCoAP and basic CoAP flows. All flows started at
random times between 0 and 200 ms. We executed 30 random
test runs for this experiment.
approximately 950 ms on average for all basic CoAP flows. Fig. 28 shows the comparable delay performance of
The average delay was 725.91 ms for FuzzyCoAP with confi- FuzzyCoAP and the basic CoAP in the case of TCP/UDP
dence intervals of (700.40, 751.43) and was 973.95 for basic background traffic.
CoAP with confidence intervals of (948.03, 999.86).
Fig. 27 shows a throughput comparison of the schemes.
In the case of congestion (from 40 s to 70 s, from 80 s to
120 s, and from 140 s to 180 s), the average throughput was
0.49 kbps with a confidence interval of (0.479, 0.501) for
FuzzyCoAP and was 0.48 Kbps with a confidence interval of
(0.477, 0.495) for basic CoAP, respectively. The FuzzyCoAP
flow achieved a throughput comparable to that of the basic
CoAP flows. This is because the BUNCON flow used almost
all available bandwidth. Thus, the FuzzyCoAP flow cannot
gain more available bandwidth to increase the sending rate,
as shown in previous experimental set. However, the average
throughput of the FuzzyCoAP flow was higher than that of
the basic CoAP flows during the congestion situation. The
results indicate that FuzzyCoAP reacts better than the basic
CoAP in dynamic traffic scenarios.
FIGURE 28. Delay performance of FuzzyCoAP and basic CoAP using
TCP/UDP background traffic.
As indicated, the delay in both schemes fluctuated depend-

ing on the rate of change in the UDP flow. A large delay was
observed during the time interval from 80 s to 120 ms and
from 150 s to 200 s because the UDP flow sent packets at
a high speed during that time interval. The average delay in
the basic CoAP was approximately 1563.25 ms with confi-
dence intervals of (1550.77, 1575.74). The large delay was
2004 ms at 7 s and 1970 ms at 153 s. By contrast, the average
delay was approximately 1561.26 ms with a confidence inter-
val of (1554.82, 1579.70) for FuzzyCoAP. The maximum
delay in the FuzzyCoAP flow was 1888 ms at 153 s, which
was smaller than that of the basic CoAP (2004 ms). This is
because of the variable RTOs in the FuzzyCoAP flow.
Fig. 29 shows the throughput of the Fuzz CoAP and basic
FIGURE 27. Throughput performance in dynamic traffic scenarios. CoAP. In the time interval from 0 to 50 s, all flows compete
105608 VOLUME 10, 2022

for the available bandwidth of the bottleneck link. Fuzzy- the sending rate according to the dynamic network state.
CoAP flow gained a higher bandwidth than the basic CoAP Thus, FuzzyCoAP can be used to predict early congestion.
during this time interval. FuzzyCoAP can limit the maximum delay while maintaining
At 80 s, the UDP flow was changed from 20 to 50 Kbps. a high throughput performance.
At this moment, the FuzzyCoAP flow attempted to lever- All experiment results demonstrate that the rate-based
age the recently released bandwidth to increase its sending FuzzyCoAP behaves more efficiently than the loss-based
rate. Owing to the recently updated bottleneck bandwidth, the basic CoAP in various traffic scenarios.
FuzzyCoAP flow could increase throughput during 80-90 s
based on its FCS. By contrast, the basic CoAP flow cannot E. DISCUSSION
maintain its throughput. This paper proposes a new rate-based CC scheme for CoAP.
During the moment of the rate change of the UDP We focused on experiments to compare the performance of
flow at 150 s, both FuzzyCoAP flow and the basic the rate-based CC and the existing loss-based CC scheme,
CoAP flow attempted to gain the bandwidth released by that is, the basic CoAP. As discussed in Section II, most of
the UDP flow. However, the basic CoAP flow could not, the existing CoAP variants follow a loss-based CC approach.
whereas the FuzzyCoAP could obtain some more bandwidth We chose the basic CoAP for comparison because it is repre-
to increase its throughput based on its updated bottleneck sentative of the loss-based CC schemes that have been stan-
bandwidth. However, the throughput of FuzzyCoAP fluctu- dardized. Moreover, the aim of this study is to demonstrate
ated owing to competition between the flows. Several packets the feasibility and efficiency of a fuzzy rate-based CC scheme
were lost for both schemes from 150 s to 200 s because of the for CoAP compared to the loss-based CC scheme for CoAP.
high rate of UDP flow. Thus, the throughput of both schemes Experiments with other related schemes will be a topic for
degraded accordingly. further studies.
A key issue in the design of our FCS is the computation
of the bottleneck bandwidth to determine the BG-gradient.
As presented in Section III, we used a simple method for
sending back-to-back packets at the startup stage. The initial
state of FuzzyCoAP requires six to ten RTT cycles to estimate
the bottleneck compared with the ten cycles indicated in [23]
and [42]. This is because the clients and network require some
time to be stable. This overhead is negligible compared to the
total time of burst data transfer. In addition, another method
can be deployed for bottleneck bandwidth estimation, such as
the packet pair method indicated in [58]. However, this issue
will be a topic for further study.
In the proposed FuzzyCoAP, we use the C-degree to adjust
the sending rate of the clients, as well as the RTO values
for retransmissions. Accurate computation of variable RTOs
can reduce the number of unnecessary retransmissions and
packet duplications. Our experiment results indicate that the
FIGURE 29. Throughput performance of FuzzyCoAP and basic CoAP using C-degree can be used to adjust the RTOs, which are used to
TCP/UDP background traffic. adjust the retransmission speed. The issue of RTO adjustment
is a topic for further research.
At 200 s, the UDP flow rate was decreased to 5 Kbps.
FuzzyCoAP can gain more available bandwidth to increase its VI. CONCLUSION
throughput, whereas the basic CoAP flow cannot. However, Constrained Application Protocol (CoAP) has been adopted
the throughput of FuzzyCoAP fluctuated because many pack- for IoT networks to satisfy the growing demand for numerous
ets remained in flight. The average throughput was approx- smart applications. Congestion control (CC) is one of the
imately 1.895 Kbps with confidence intervals of (1.863, most challenges in such networks owing to the requirements
1.927) in the basic CoAP. This is because the basic CoAP had for reliable burst data transfer and the dynamic network con-
more retransmitted and duplicated packets in the congested ditions. CoAP uses a basic CC algorithm that only regulates
interval. In contrast, the average throughput was approx- the retransmission rate, that is, in the case of timeout or
imately 9.228 Kbps with confidence intervals of (7.907, packet loss. This typical loss-based CC algorithm operates
10.549) in FuzzyCoAP. only when a network congestion occurs. Enhancement of
We can conclude that FuzzyCoAP can leverage the CoAP CC is undoubtedly necessary, particularly for burst
available bandwidth of the bottleneck shared by flows to data transfers.
increase its performance. By contrast, the basic CoAP could In this study, we proposed a novel rate-based CC scheme
not. This is because FuzzyCoAP uses the FCS to control called FuzzyCoAP based on fuzzy control system (FCS).
VOLUME 10, 2022 105609

An FCS can be an excellent choice because parameters such [7] H. Haile, K.-J. Grinnemo, S. Ferlin, P. Hurtig, and A. Brunstrom,
as RTT, delivery rate, and traffic load are not sharp, unclear, ‘‘End-to-end congestion control approaches for high throughput and low
delay in 4G/5G cellular networks,’’ Comput. Netw., vol. 186, Feb. 2021,
approximate, or ambiguous. Thus, an FCS can help in mak- Art. no. 107692.
ing appropriate decisions for congestion control. We chose [8] H. Jiang, Q. Li, Y. Jiang, G. Shen, R. Sinnott, C. Tian, and M. Xu, ‘‘When
the RT-gradient and BG-gradient as inputs to the FCS. The machine learning meets congestion control: A survey and comparison,’’
Comput. Netw., vol. 192, Jun. 2021, Art. no. 108033.
crisp output of the FCS, that is, the C-degree, reflects the [9] V. Jacobson, ‘‘Congestion avoidance and control,’’ in Proc. Symp. Proc.
congestion state. Using the FCS, the proposed FuzzyCoAP Commun. Archit. Protocols SIGCOMM, New York, NY, USA, 1988,
can detect early congestion and adjust the sending rate to pp. 314–329.
[10] S. Floyd, R. Gummadi, and S. Shenker, ‘‘Adaptive RED: An algorithms
avoid congestion threats. To the best of our knowledge, this for increasing the robustness of RED’s active queue management,’’ Int.
study is the first to address the application of FCS for CoAP Comput. Sci. Inst. (ICSI), Berkeley, CA, USA, Tech. Rep. 301, Aug. 2001.
[Online]. Available: https://www.icsi.berkeley.edu/icsi/node/2032
CC using a rate-based approach. [11] A. Betzler, C. Gomez, I. Demirkol, and J. Paradells, ‘‘CoAP congestion
Numerous experiments and traffic scenarios have been control for the Internet of Things,’’ IEEE Commun. Mag., vol. 54, no. 7,
conducted to demonstrate the feasibility of the proposed pp. 154–160, Jul. 2016.
[12] A. Betzler, C. Gomez, I. Demirkol, and J. Paradells, ‘‘CoCoA+: An
FuzzyCoAP. We compared the performance of FuzzyCoAP advanced congestion control mechanism for CoAP,’’ Ad Hoc Netw., vol. 33,
with that of the basic CoAP because it is representative of pp. 126–139, Oct. 2016.
loss-based schemes. The results demonstrate that the pro- [13] C. Bormann, A. Betzler, C. Gomez, and I. Demirkol. (Feb. 2018).
CoAP Simple Congestion Control/Advanced. Internet-Draft. Accessed:
posed FuzzyCoAP is feasible. FuzzyCoAP frequently checks Jul. 24, 2021. [Online]. Available: https://tools.ietf.org/id/draft-bormann-
for network congestion and reduces the likelihood of conges- core-cocoa-03.txt
tion by decreasing the transmission rate. Furthermore, Fuzzy- [14] J. J. Lee, K. T. Kim, and H. Y. Youn, ‘‘Enhancement of congestion control
of constrained application protocol/congestion control/advanced for Inter-
CoAP enables high throughput by dynamically checking the net of Things environment,’’ Int. J. Distrib. Sensor Netw., vol. 12, no. 11,
available bandwidth to increase the sending rate. FuzzyCoAP pp. 1–13, Nov. 2016.
is more efficient than basic CoAP in terms of delay, through- [15] I. Jarvinen, M. Kojo, I. Raitahila, and Z. Cao, Fast-Slow Retransmission
Timeout and Congestion Control Algorithm for CoAP, document draft-
put, retransmission, packet duplication, and packet loss ratio ietf-core-fasor-01, IETF CoRE Working Group, 2020. [Online]. Available:
in different traffic scenarios. Moreover, FuzzyCoAP is effi- https://core-wg.github.io/fasor/draft-ietf-core-fasor.html
cient for burst data transfer. [16] S. Bolettieri, G. Tanganelli, C. Vallati, and E. Mingozzi, ‘‘PCoCoA: A
precise congestion control algorithm for CoAP,’’ Ad Hoc Netw., vol. 80,
FuzzyCoAP uses a variable RTO estimation based on the pp. 116–129, Nov. 2018.
computed congestion degree provided by the FCS. There- [17] S. Deshmukh and V. T. Raisinghani, ‘‘AdCoCoA-adaptive congestion con-
fore, FuzzyCoAP reacts better to dynamic network states than trol algorithm for CoAP,’’ in Proc. 11th Int. Conf. Comput., Commun. Netw.
Technol. (ICCCNT), Kharagpur, India, Jul. 2020, pp. 1–7.
basic CoAP in both single and heavy congestion situations. [18] R. Jain, ‘‘A delay-based approach for congestion avoidance in inter-
Using variable RTOs, FuzzyCoAP can reduce the number connected heterogeneous computer networks,’’ CM SIGCOMM Comput.
of retransmissions, packet duplications, and loss rate, while Commun. Rev., vol. 19, no. 5, Oct. 1989, pp. 56–71, doi: 10.1145/74681.
74686.
maintaining a reasonable delay and high throughput. The use [19] A. Gurtov, T. Henderson, and S. Floyd, The NewReno Modification to
of the computed congestion degree for the RTO adjustment TCP’s Fast Recovery Algorithm, document RFC 3782, 2004.
[20] S. Ha, I. Rhee, and L. Xu, ‘‘CUBIC: A new TCP-friendly High-speed TCP
can be studied in future research.
variant,’’ in Proc. SIGOPS Oper. Syst. Rev., vol. 42, no. 5, 2008, pp. 64–74.
[21] R. Mittal, V. T. Lam, N. Dukkipati, E. Blem, H. Wassel, M. Ghobadi,
ACKNOWLEDGMENT A. Vahdat, Y. Wang, D. Wetherall, and D. Zats, ‘‘TIMELY: RTT-based con-
gestion control for the datacenter,’’ ACM SIGCOMM Comput. Commun.
The authors would like to thank the Hanoi University of Civil Rev., vol. 45, no. 4, pp. 537–550, Oct. 2015.
Engineering (HUCE) and the Posts and Telecommunications [22] S. Liu, T. Basar, and R. Srikant, ‘‘TCP-Illinois: A loss- and delay-based
Institute of Technology (PTIT) for the facilities, and also congestion control algorithm for high-speed networks,’’ Perform. Eval.,
vol. 65, nos. 6–7, pp. 417–440, Jun. 2008.
would like to thank the anonymous reviewers for their valu- [23] E. Ancillotti and R. Bruno, ‘‘BDP-CoAP: Leveraging bandwidth-delay
able comments. product for congestion control in CoAP,’’ in Proc. IEEE 5th World Forum
Internet Things (WF-IoT), Limerick, Ireland, Apr. 2019, pp. 656–661.
[24] E. Ancillotti, E. Bolettieri, and R. Bruno, ‘‘RTT-based congestion control
REFERENCES for the Internet of Things,’’ in Proc. 19th IEEE Int. Symp. Wired/Wireless
Internet Commun. (WWIC), vol. 10866, Jun. 2018, pp. 3–15.
[1] The Constrained Application Protocol (CoAP), document RFC 7252,
[25] R. Rejaie, M. Handley, and D. Estrin, ‘‘RAP: An end-to-end rate-based
Jun. 2014. [Online]. Available: https://rfc-editor.org/info/rfc7252
congestion control mechanism for realtime streams in the internet,’’ in
[2] CUBIC for Fast Long-Distance Networks, document RFC 8312, [Online].
Proc. IEEE INFOCOM Comput. Commun. Societies, vol. 3. Mar. 1999,
Available: https://rfc-editor.org/info/rfc8312
pp. 1337–1345.
[3] T. Henderson, S. Floyd, A. Gurtov, and Y. Nishida, The NewReno Modifi- [26] S. Floyd, M. Handley, J. Padhye, and J. Widmer, ‘‘Equation-based conges-
cation to TCP’s Fast Recovery Algorithm, document RFC 6582, Apr. 2022, tion control for unicast applications,’’ in Proc. ACM SIGCOMM Comput.
[Online]. Available: https://rfc-editor.org/info/rfc6582 Commun. Rev., Oct. 2000, vol. 30, no. 4, pp. 43–56.
[4] C. Gomez, A. Arcia-Moret, and J. Crowcroft, ‘‘TCP in the Internet of [27] D. H. Hoang, Quality of Service Control in the Mobile Wireless Environ-
Things: From ostracism to prominence,’’ IEEE Internet Comput., vol. 22, ment. Bern, Switzerland: PeterLang Publisher, 2002.
no. 1, pp. 29–41, Jan./Feb. 2018. [28] E. Ancillotti, R. Bruno, C. Vallati, and E. Mingozzi, ‘‘Design and evalua-
[5] C. Bormann and Z. Shelby. Block-Wise Transfers in the Constrained Appli- tion of a rate-based congestion control mechanism in CoAP for IoT appli-
cation Protocol (CoAP). Accessed: Jun. 24, 2021. [Online]. Available: cations,’’ in Proc. IEEE 19th Int. Symp. World Wireless, Mobile Multimedia
https://rfc-editor.org/info/rfc7959 Networks (WoWMoM), Chania, Greece, Jun. 2018, pp. 14–15.
[6] W. U. Rahman, Y.-S. Choi, and K. Chung, ‘‘Performance evaluation of [29] D. H. Hoang and T. T. D. Le, ‘‘RCOAP: A rate control scheme for
video streaming application over CoAP in IoT,’’ IEEE Access, vol. 7, reliable bursty data transfer in IoT networks,’’ IEEE Access, vol. 9,
pp. 39852–39861, 2019. pp. 169281–169298, 2021, doi: 10.1109/ACCESS.2021.3135435.
105610 VOLUME 10, 2022

[30] T. J. Ross, Fuzzy Logic with Engineering Applications, 3rd Ed. Hoboken, [53] D. H. Esawi, G. Attiya, and G. Allam, ‘‘Fuzzy controller based TCP-Vegas
NJ, USA: Wiley, 2010. enhancement for congestion control,’’ Menoufia J. Electron. Eng. Res.,
[31] S. Keshav, ‘‘A control-theoretic approach to flow control,’’ in Proc. SIG- vol. 30, no. 2, pp. 39–44, Jul. 2021.
COMM Comput. Commun. Rev., Sep. 1991, vol. 21, no. 4, pp. 3–15, doi: [54] NS-3 Network Simulator, NS3.36. Accessed: Aug. 16, 2022. [Online].
10.1145/115994.115995. Available: https://www.nsnam.org/
[32] C. Chrysostomou, A. Pitsillides, L. Rossides, M. Polycarpou, and [55] S. Maesoser. A Partial CoAP Implementation With mDNS Support, Mul-
A. Sekercioglu, ‘‘Congestion control in differentiated services net- ticast. Accessed: Aug. 16, 2022. [Online]. Available: https://github.com/
works using Fuzzy-RED,’’ IFAC Control Eng. Pract., vol. 11, no. 19, maesoser/ns3-coap/
pp. 1153–1170, 2003. [56] H. Hirotakaster. CoAP Client, Server Library for Spark Photon, Spark
[33] S. Jaiswal and A. Yadav, ‘‘Fuzzy based adaptive congestion control in Core. Accessed: Aug. 16, 2022. [Online]. Available: https://github.com/
wireless sensor networks,’’ in Proc. 6th Int. Conf. Contemp. Comput. (IC3), hirotakaster/CoAP
Aug. 2013, pp. 433–438. [57] M. Boucadair and J. Shallow. (May 2021). Constrained Application Pro-
[34] A. A. Rezaee and F. Pasandideh, ‘‘A fuzzy congestion control protocol tocol (CoAP) Block-Wise Transfer Options Supporting Robust Trans-
based on active queue management in wireless sensor networks with med- mission. Internet-Draft. Accessed: Jun. 20, 2021. [Online]. Available:
ical applications,’’ Wireless Pers. Commun., vol. 98, no. 1, pp. 815–842, https://tools.ietf.org/id/draft-ietf-core-new-block-14
Jan. 2018, doi: 10.1007/s11277-017-4896-6. [58] S. Keshav, ‘‘The packet pair flow control protocol,’’ Int. Comput. Sci.
[35] C. Sonmez, O. D. Incel, S. Isik, M. Y. Donmez, and C. Ersoy, ‘‘Fuzzy-based Inst. (ICSI), Berkeley, CA, USA, Tech. Rep. TR-91-028, 1991. [Online].
congestion control for wireless multimedia sensor networks,’’ EURASIP J. Available: http://www.icsi.berkeley. edu/pubs/techreports/tr-91-028.pdf
Wireless Commun. Netw., vol. 2014, no. 1, p. 63, Dec. 2014.
[36] W. Chang, P. Chen, and C. Yang, ‘‘Robust fuzzy congestion control of
TCP/AQM router via perturbed Takagi–Sugeno fuzzy models,’’ Intl. J.
Fuzzy Syst., vol. 15, no. 2, pp. 203–213, Jun. 2013.
THIEU NGA PHAM received the Diploma-Ing.
[37] M. Zarei, A. M. Rahmani, and R. Farazkish, ‘‘CCTF: Congestion control
(M.Eng.) degree in technical cybernetics and
protocol based on trustworthiness of nodes in wireless sensor networks
using fuzzy logic,’’ Int. J. Ad Hoc Ubiquitous Comput., vol. 8, Jan. 2011, automation and the Dr.-Ing. degree in informat-
pp. 54–63. ics and automation from the Technical Univer-
[38] P. Aimtongkham, T. G. Nguyen, and C. So-In, ‘‘Congestion control and sity of Ilmenau, Germany, in 1987 and 2000,
prediction schemes using fuzzy logic system with adaptive membership respectively.
function in wireless sensor networks,’’ Wireless Commun. Mobile Comput., Since 2006, she has been a Senior Lecturer at
vol. 2018, pp. 1–19, Aug. 2018. the Faculty of Information Technology, University
[39] M. H. Homaei, F. Soleimani, S. Shamshirband, A. Mosavi, N. Nabipour, of Civil Engineering, Hanoi, Vietnam. Her cur-
and A. R. Varkonyi-Koczy, ‘‘An enhanced distributed congestion rent research interests include fuzzy control, fuzzy
control method for classical 6LowPAN protocols using fuzzy deci- optimization, fuzzy decision, expert systems, wireless sensor networks, the
sion system,’’ IEEE Access, vol. 8, pp. 20628–20645, 2020, doi: IoT networks, system techniques, and control systems.
10.1109/ACCESS.2020.2968524.
[40] G. Cui, H. Wang, Z. Fan, and P. Li, ‘‘NDN congestion control based on
fuzzy comprehensive evaluation algorithm,’’ J. Phys., Conf., vol. 1883,
no. 1, Apr. 2021, Art. no. 012008. DANG HAI HOANG received the Diploma-
[41] P. Aimtongkham, P. Horkaew, and C. So-In, ‘‘An enhanced CoAP scheme
Ing. (M.Eng.) degree in technical cybernetics and
using fuzzy logic with adaptive timeout for IoT congestion control,’’ IEEE
automation and the Dr.-Ing. and Dr.-Ing. (Habil-
Access, vol. 9, pp. 58967–58981, 2021.
itation) degrees in telematics and communication
[42] N. Cardwell, Y. Cheng, C. S. Gunn, S. H. Yeganeh, and V. Jacobson,
‘‘BBR: Congestion-based congestion control,’’ Queue, vol. 14, no. 5, p. 50, systems from the Technical University of Ilmenau,
Oct. 2016. Germany, in 1984, 1999, and 2002, respectively.
[43] Computing TCP’s Retransmission Timer, document RFC 6298, [Online]. Since 2009, he has been an Associate Professor
Available: https://rfc-editor.org/info/rfc6298 at the Posts and Telecommunications Institute of
[44] C. Suwannapong and C. Khunboa, ‘‘Congestion control in CoAP observe Technology, Hanoi, Vietnam. His current research
group communication,’’ Sensors, vol. 19, no. 15, p. 3433, Aug. 2019, doi: interests include information security, communi-
10.3390/s19153433. cation protocols, communication systems, QoS mechanisms, and control
[45] J. H. Jung, M. Gohar, and S. J. Koh, ‘‘CoAP-based streaming control systems.
for IoT applications,’’ Electronics, vol. 9, no. 8, p. 1320, 2020, doi:
10.3390/electronics9081320.
[46] M. A. Tariq, M. Khan, M. T. R. Khan, and D. Kim, ‘‘Enhancements and
challenges in CoAP—A survey,’’ Sensors, vol. 20, no. 21, p. 6391, 2020, THI THUY DUONG LE received the B.S. degree
doi: 10.3390/s20216391. in telecommunications and electronic engineering
[47] L. A. Zadeh, ‘‘Toward a theory of fuzzy systems,’’ NASA, Washington, and the M.S. degree from the Technical University
DC, USA, Tech. Rep. CR-1432, 1969, pp. 1–35. of Hanoi, Vietnam, in 2002 and 2008, respectively.
[48] L. A. Zadeh, ‘‘Outline of a new approach to the analysis of com-
She is currently pursuing the Ph.D. degree with the
plex systems and decision processes,’’ IEEE Trans. Syst., Man, Cybern.,
Posts and Telecommunications Institute of Tech-
vol. SMC-3, no. 1, pp. 28–44, Jan. 1973.
[49] E. H. Mamdani, ‘‘Applications of fuzzy algorithms for simple dynamic
nology, Hanoi, Vietnam.
plant,’’ Proc. IEEE vol. 121, no. 12, pp. 1585–1588, Dec. 1974. Since 2005, she has been a Lecturer with the
[50] R. E. Bellman and L. A. Zadeh, ‘‘Decision-making in a fuzzy environ- Faculty of Information Technology, University of
ment,’’ Manage. Sci., vol. 17, no. 4, pp. 141–164, Dec. 1970. Civil Engineering, Hanoi. She is currently a Senior
[51] S.-H. Chen, ‘‘Ranking fuzzy numbers with maximizing set and minimizing Lecturer. Her current research interests include computer and communi-
set,’’ Fuzzy Sets Syst., vol. 17, no. 2, pp. 113–129, Nov. 1985. cation systems, wireless sensor networks, QoS mechanisms, and network
[52] H. J. Zimmerman, Fuzzy Set Theory—And Its Applications, vol. 17, 4th ed. performance.
Norwell, MA, USA: Kluwer Academic, 2001.
VOLUME 10, 2022 105611

4. Sep 2022

Uploaded by

Copyright:

Available Formats

4. Sep 2022

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

4. Sep 2022

Uploaded by

Copyright:

Available Formats

Received 30 August 2022, accepted 21 September 2022, date of publication 3 October 2022, date of current version 10 October 2022.

Digital Object Identifier 10.1109/ACCESS.2022.3211296

Fuzzy Congestion Control and Avoidance

Corresponding author: Dang Hai Hoang (haihd@ptit.edu.vn)

I. INTRODUCTION CoAP uses congestion control (CC) to alleviate network con-

105590 VOLUME 10, 2022

VOLUME 10, 2022 105591

105592 VOLUME 10, 2022

III. PROPOSED FUZZY CONTROL SYSTEM FOR COAP

VOLUME 10, 2022 105593

B. RT-GRADIENT absolute difference in the RTT variances, as follows

FIGURE 4. Example of the RT-gradient.

105594 VOLUME 10, 2022

VOLUME 10, 2022 105595

105596 VOLUME 10, 2022

TABLE 2. Fuzzy Rules.

FIGURE 7. Membership functions of BG-gradient.

We propose membership functions for the output, that is,

where Zc is the crisp output (mean of center of gravity among

VOLUME 10, 2022 105597

detection and returns it. During steady state, if packet loss is

105598 VOLUME 10, 2022

number of received ACKs by one (line 8): Algorithm 2 Steady

VOLUME 10, 2022 105599

105600 VOLUME 10, 2022

FuzzyCoAP or basic CoAP. Heterogeneous trafﬁc scenar-

VOLUME 10, 2022 105601

2) PERFORMANCE OF FuzzyCoAP FLOWS

105602 VOLUME 10, 2022

FIGURE 15. Simulation model for the heterogenous traffic scenarios.

TABLE 3. Performance comparison: FuzzyCoAP flows.

FIGURE 16. End-to-end delay of FuzzyCoAP and basic CoAP.

VOLUME 10, 2022 105603

2) SINGLE CONGESTION SCENARIOS

105604 VOLUME 10, 2022

VOLUME 10, 2022 105605

percentages were much lower for FuzzyCoAP owing to the

3) HEAVY CONGESTION SCENARIOS

At 160 s, the rate was increased in a stepwise manner by

105606 VOLUME 10, 2022

TABLE 6. Performance comparison under heavy congestion.

received packets in FuzzyCoAP was signiﬁcantly higher than

D. DYNAMIC TRAFFIC SCENARIOS

VOLUME 10, 2022 105607

2) DYNAMIC SCENARIOS USING FuzzyCoAP, BASIC CoAP,

As indicated, the delay in both schemes ﬂuctuated depend-

105608 VOLUME 10, 2022

VOLUME 10, 2022 105609

105610 VOLUME 10, 2022

VOLUME 10, 2022 105611

You might also like