Figure 1. Architecture of IoT
The Internet Engineering Task Force (IETF) designed the Constrained Application Protocol (CoAP) for Internet of Things (IoT) gadgets. The IoT devices with restricted radio channel limits and equipment assets are called constrained devices. Network communications in constrained devices face congestion because of their limited resources. To face the congestion, CoAP uses a basic (CC) congestion control mechanism for solid transmission. Alternative CoAP CC mechanisms CoCoA and CoCoA+ are introduced by the IETF Constrained RESTful Environments (CoRE) Working Group. However, there had been limited evaluations have done on CoAP CC mechanisms. In this paper, the authors focus on this crucial study and perform evaluations that show how the default and alternative CC mechanisms contrast with one another. They utilize the Cooja simulation condition, which is one of the Contiki advancement toolsets for simulating CoAP CC mechanisms in different network topologies and varying in different link delivery ratios in global event traffic scenario. By evaluating the generated results, CoCoA+ shows better performance compared to default CoAP and CoCoA.
Internet of Things (IoT) is a new generation of innovation that every smart devices or humans could be connected to the internet. The devices with restricted resources, for example, CPU, memory (ROM and RAM), and battery life are called constrained devices. These devices frequently work as sensors gathering data, Machine to Machine (M2M) correspondence or savvy devices controlling electrical apparatuses or services. When these devices are associated with a network they will be known as "things" and become some portion of what is known as the "internet of things".
IoT is a network of things, for example, embedded Computers, controllable and insightful computerized devices (brilliant gadgets), and sensors, with the capacity to associate and trade information with different devices and services. IoT has many applications such as home automation, manufacturing, environmental monitoring, medical and health care systems, and transportation. By being associated with the web, IoT devices can conceivably give data and administrations in the physical world to anybody, whenever, anyplace. With IoT, clients can get to their device data, which has been transferred and put away on a web server or cloud storage, and interacts with and controls their devices through the web, mobile, and cloud interfaces and applications. The count of IoT devices increased to 31%.
IoT includes broadening internet availability past standard devices, for example, desktops, PCs, cell phones, and tablets, to any scope of customarily dumb or non-web empowered physical devices, Embedded with innovation, these devices can communicate and cooperate over the web, and they can be remotely checked and controlled. Figure 1 portrays a common IoT network in a home. The figure demonstrates distinctive IoT devices associated legitimately to an Internet switch or by utilizing an IoT gateway, which goes about as an extension between the obliged IoT network and the internet.
Figure 1. Architecture of IoT
From the above figure, IoT devices connect to the internet to upload data and to receive requests from a server. Users can access uploaded data from their devices through a web interface and control them using web applications installed on the server. Devices can communicate utilizing web standards and protocols like that of a web stack, for example, HTTP, MQTT, and CoAP to enable them to associate with, browse, and share information over the web expanding their convenience and availability.
In this article, the main spotlight will be on the exhibitions of advanced congestion control mechanisms for CoAP in constrained devices. The constrained devices are end nodes with sensors/actuators that can deal with a particular application purpose. They are generally associated with gateway like gadgets, low power lossy system, and in return interact with the IoT cloud platforms. Regularly they communicate by means of low power remote protocols like BLE, 802.15.4 (6LoWPAN, ZigBee, Thread, and Wireless HART, etc.), LPWAN and for the most part battery controlled with the low data rate.
Network communications in constrained devices face congestion problem. Network congestion happens when the produced traffic load reaches the network limit. Traffic loads that can cause congestion are probably going to occur in CoAP communications when Messages between substantial quantities of devices are traded. (CC) Congestion Control Mechanisms have the ability to detect congestion in the devices network and apply measures to avoid congestion for reliable network performance. Investigation of CC Mechanisms for constrained devices that runs CoAP is also important. However, performance evaluations have to confirm which congestion control mechanism is suitable for CoAP. In this paper, Cooja simulator is used, which is part of the Contiki Operating System (OS) toolset, to simulate CoAP CC mechanisms.
Congestion Control/Advanced (CoCoA) (Gomez, Deminkol, Bormann, & Betzler, 2014) are assessed with three different network topologies, in particular, a grid topology, a dumbbell topology and a chain topology with various NSTART parameter values. The outcomes demonstrate that CoCoA has preferred execution in throughput over the Default CoAP. CoCoA can reduce MAC buffer overflows (Betzler, Gomez, Deminkol, & Paradells, 2013).
By analyzing default CoAP and CoCoA, a few downsides of their execution are distinguished. By alterations of these CC mechanisms with new generation Variable Back off Factor (VBF) and a new RTO aging mechanism (Betzler, Gomez, Deminkol, & Paradells, 2015) introduced a new CC mechanism for CoAP: Congestion Control Advanced/Plus (CoCoA+). The execution aftereffects of default CoAP, CoCoA, and CoCoA+ demonstrate that CoCoA+ can provide better performance than default CoAP and CoCoA regarding PDR upgrades of up to 19.8% and a decrease of end-to-end delays amid bursts of packets of up to 31.2% are estimated in contrast with default CoAP and CoCoA.
The CoAP is a web transfer protocol at the application layer intended to be used with constrained devices (e.g., low-power node, sensors, switches, or actuators) and constrained (e.g., low-power, lossy) networks. The Internet Engineering Task Force (IETF) working group has designed this protocol to be used for M2M applications, IoT objects and suitable for constrained devices that have a limited amount of ROM and RAM.
CoAP runs on the User Datagram Protocol (UDP) as the transportation layer, which provides the less packet size because UDP only uses 8 bytes as the packet header. Moreover, CoAP uses a comparable and a common communication model with HTTP, which is a Representational State Transfer (REST) (Fielding, 2000). Since REST has comparative task and a similar framework as HTTP, there is no requirement for a mind boggling translator for CoAP to interoperate with HTTP.
Generally, CoAP architecture could be described as a two-layer approach: a message layer and a request/response layer shown in Figure 2. The lower layer deals with UDP and asynchronous technique, while the upper one manages the mapping between the requests and responses using technique and Response Codes. The after two sections will present both layers.
Figure 2. CoAP Protocol Layer
The CoAP interaction model is like client and server medel similar to the HTTP client/server model. CoAP requests and responses semantics are carried For CoAP messages that incorporate either a Method code or response code. The CoAP solicitations are sent by a client to demand an activity on a resource on a server. The server at that point sends back a CoAP reaction with a response code. The client requests an activity utilizing a Method code on a resource, which is recognized by Uniform Resource Identifier (URI) on a server. The CoAP defines four different method codes:
The messaging model of CoAP is based on the interchanging of complex messages over User Datagram Protocol (UDP) between endpoints. Messages are transported, by default, over UDP. However, CoAP can be used over DTLS and other transports, such as TCP, SMS, or SCTP. Messages are shared by requests and responses. Each message has an ID used to find the duplicated messages and for reliability. CoAP defines four types of messages:
Since UDP does not execute end-to-end reliability, but rather now and then it might require by the application. When an application requires end-to-end reliability, (CON) messages are utilized for the (ACK) reply from destination endpoint. If not (NON) messages are utilized. In Default CoAP, when a confirmable (CON) message is sent, CoAP haphazardly picks a Retransmission timeout (RTO) value from the interim between [2 s, 3 s] for the message retransmission. When timer of the RTO values terminates and source of the message transmission has not gotten an ACK from the destination endpoint, a message loss will occur and the CoAP message will be retransmitted (Shelby, Hartke, & Bormann, 2014).
Sometimes after retransmission timeout, both client CON message and server ACK message are collided each other and create congestion. To avoid congestion in the network, a Binary Exponential Backoff (BEB) is applied, multiplying the RTO estimation of the retransmitted packet (Balardina, Koucheryavy, & Gurtov, 2013). The main contrast in the conduct of CoCoA contrasted with Default CoAP is the utilization of Round-Trip Time (RTT) estimations to ascertain the RTO of the primary transmission of a CoAP message. CoCoA runs two RTO estimators in parallel for every destination endpoint, a strong and weak RTO estimator that is refreshed when estimating strong RTTs or weak RTTs.
The measurement of an RTTx is used to refresh RTOx as
where X means strong or weak RTTstrong is computed when an ACK is gotten after the primary transmission of a CON message. RTTweak is computed when an ACK is gotten after primary Re- transmission of a CON message.
As per the CoCoA, when RTOstrong or RTOweak is refreshed subsequent to getting an RTT estimation, a general RTO (RTOoverall) is recalculated.
In the case of CoCoA+, a swap of the BEB utilized for retransmissions by a Variable Backoff Factor (VBF) is utilized. The VBF is a vital change to the back off conduct utilized by default CoAP and CoCoA. Rather than multiplying the past RTO value (RTOprevious) to get the RTO applied to the following retransmission (RTOnew), it is multiplied by a variable,
where VBF relies upon the RTOinit of a CoAP trade as below:
CoCoA does not have a Decay mechanism for long RTOs that may wind up out of date after longer times of not acquiring fresh RTT estimations. CoCoA+ had presented another RTO mechanism, which expresses that if RTOoverall is bigger than the base RTO from the default CoAP particular of 2 s, and it is not refreshed amid in excess of 30 s, on the following transmission the RTOoverall is refreshed as:
The above equation revives the RTOoverall of an estimator to a value that is nearer to the default estimation of 2 s (Betzler et al., 2015).
In this section, points of interest on the simulation setup are used to do performance evaluations of the three CC mechanisms. This incorporates the configuration of the simulator, constant traffic scenario, the network topologies, and the performance metric were used to do the performance assessments.
Contiki is a high level multitasking operating system developed for wireless sensor networks and constrained devices (Dunkels, Gronvall, & Voigt, 2004). Contiki OS allows small devices with limited hardware resources like RAM, memory, and network capacities to interact with the internet using protocols (IPv4 and IPv6) with low power consumption.
Contiki has tools that allow the user to monitor the data collection in real time through a GUI. It has a full-featured simulator suite that allows rapid testing of software for functional correctness. Contiki OS currently supports over 25 platform ports. It has the first and smallest IPv6 compatible network stack and allows easy access and direct modifications to the stack. Contiki allows the user to check the energy usage with the largest library that can easily be extended based on the user needs. When Contiki is configured to duty cycle with Contiki MAC, nodes can achieve up to 99% lower energy Consumption than non-duty cycle configurations.
Cooja is a Wireless Sensor Network (WSN) simulator, which is one of the Contiki OS toolsets. It is an adaptable Java-based simulator, which bolsters utilizing C programs to create application software by Java Native Interface. Cooja main feature is the assessment of the remote sensor nodes equipment that considers the equipment determinations and handling capacities of real nodes (Osterlind, Dunkels, Eriksson, Finne, & Voigt, 2006).
In Cooja, the binary image of a node can be transferred into the virtual nodes, where the accumulated program code is then executed with the assessment model of the chosen node compose amid the simulations as though it were a real node. Cooja's another feature is that application developer can alter parts of the simulation environment without changing any Cooja main code. It implies that the framework can be included new parts, for example, interfaces, modules and radio mediums or reconfigured existing parts. With these focal points of Cooja, execution of variation simulations with various conditions and framework settings, for example, different packet age rates, diverse MAC protocols, and different network topology.
A simulator is an exceptionally helpful tool for the application programming advancement in WSNs. In past, the code improvement was exceptionally troublesome for clients because of the long compilation and troubleshoots time and the transplant issue of the program. In the case of the simulator, clients can acquire numerous advantages amid the product improvement stage and vast scale test stage. In this paper, CC mechanisms will be evaluated in global event traffic scenario.
The performance metric used to evaluate the generated results is the Settling Time.
The ST metric is utilized as performance metric in the global event traffic scenario, demonstrating how strong the system is against pinnacles of congestion and how rapidly it reacts to changes in the network state. With this arrangement of performance metric, it may be dissected how vital issues brought about by congestion, in particular packet losses, delays, and long ST qualities are tended to by the diverse CC systems. The default communication protocol stack created by IETF along with this implementation in Contiki, which is used to evaluate in this paper is shown in below Figure 3.
Figure 3. Examination of the IETF Communication Protocol Stack (Left) and its Implementation in Contiki (Right)
Contiki is built-in with the Erbium CoAP implementation, with observe (Hartke, 2015) and Blockwise transfers (Shelby & Bormann, 2016).
The evaluations of Default CoAP, CoCoA, and CoCoA+ CC mechanisms will be analyzed in constant traffic scenario. In this scenario, nodes intermittently generate CoAP messages to the sink node. In the IoT, such traffic can be seen when information is generated from sensor readings and that information should be exchanged in a database for storing and handling the information. This situation helps to know how the CC mechanisms perform for various measures of offered traffic loads. In this paper, Confirmable Messages (CON) with end-to-end reliability is used for the Acknowledgement (ACK) and CoAP actuator/toggle URI, which is used to change the state of a variable of the sensor nodes is used. All CoAP messages are 71 bytes. Four types of network topologies are used for the analysis of network performance
(a) chain with 17 nodes,
(b) dumbbell with 21 nodes,
(c) grid with 36 nodes (6 X 6), and
(d) grid with 49 nodes (7 x 7).
Figure 4 demonstrates the four topologies with one RPL Border Router (Green node), erbium CoAP client nodes (yellow nodes), primary sink nodes (hubs in blue), and secondary sink nodes for notifications (nodes in blue with a circle). Because of space constraints, grid 6x6 topology is shown as a part of the grid 7x7 topology, be that as it may, in the simulations, these Topologies are separated scenarios.
Figure 4. Left: Dumbbell Topology, Right: 7 x 7 Grid and 6 x 6 Grid, and Bottom: Chain Topology. The 6 x 6 Grid is shown as a Subset of the 7 x 7 Grid. The Corners of Unit Squares are 10 M Long
RPL border router is utilized for starting the Destination Oriented Directed Acyclic Graph (DODAG) and storing the gathered routing data for all nodes that are a part of the DODAG (Winter et al., 2012). In the simulations, the RPL border router is characterized to serve just as a relay for CoAP messages it does not make CoAP messages and is not the destination endpoint of CoAP messages for passing DODAG Information to all the CoAP nodes RPL Node is set amidst all the system topologies.
For investigation of CoAP CC mechanisms did in this paper, destination endpoint must be a solitary IPV6 address, which in the simulations is a solitary IPv6 sensor node. The proposal of the CoAP base detail to set the NSTART to 1 is set (Osterlind et al., 2006), implying that just a single trade for every destination endpoint is permitted. For radio transmissions, Cooja Simulator default Unit Disk Graph Medium (UDGM) radio model with the circular transmission is chosen and interference areas are applied. The transmission ranges of the nodes are set to 10 m, which gives a unit square edge in the grids shown in Figure 4. The interference range of the nodes is set to 20 m. Nodes in transmission range can receive the packets and the nodes in interference range cause congestion.
In this paper, simulations are done on Default CoAP, CoCoA, and CoCoA+ CC mechanisms by evaluating in different Link Delivery Ratios (LDR) by 100% LDR, 50% LDR, and 25% LDR. LDR settings are accordingly in transmission success ratio and Reception success ratio in UDGM plugin of Cooja simulator. When the simulation starts the RPL DODAG formation will take up to 60 s for network formation after that CoAP messages will be generated.
The simulations of the constant traffic scenario have a duration of 10 min, the simulation runtime will be given in milliseconds in the simulation script editor of Cooja. After the timeout, the simulation will be stopped and the generated data will be collected from Radio Messages plugin of Cooja simulator into log files. For further evaluation of generated the data, Wireshark Protocol Analyser is used.
The simulations are repeated 4 times for each configuration of CoAP CC mechanism with different random simulator seed to obtain meaningful average results.
When a test run is begun, the RPL-border router will make RPL-DODAG by spreading DAG information Objects (DIOs) everywhere throughout the network. The CoAP CC execution will begin after entire formation of RPL-DAG. After that nodes will begin creating CoAP requests. The generation of traffic is execution by running cyclic timers.
These cyclic timers create new CoAP requests upon their depletion. A working simulation of grid topology with 100% LDR settings can be seen in Figure 5, where on the network window can observe the RPL-DODAG formation.
Figure 5. Running Cooja Simulation of Grid Topology with 100% LDR
For evaluation, the data can be collected from “Radio messages” by applying a 6lowpan filter, the data will be generated in pcap format, which are stored at build directory of Contiki. After collecting all the data from each configuration, the generated data will be analyzed in the Wireshark protocol analyzer. The generated RPL-DODAG and CoAP CON and ACK messages can be observed in Wireshark Protocol Analyser. ICMPV6 means internet control message protocol over IPv6. It is a built-in part of the IPv6 and performs operations like error reporting and other diagnostic functions. All CoAP requests are POST messages that change the state of sensor nodes. A message ID and node ID of the source node is included in the payload of the CoAP request. Including all headers and the payload of a CoAP request has a size of 71 bytes. Figure 6 shows the data that is generated from one of the simulation test runs with ICMPV6 and CoAP messages of CON and ACK messages.
Figure 6. Wireshark Protocol Analyser
Figure 7 portrays the burst time readings from Wireshark properties. All the generated burst time readings generated from the simulations with different link delivery ratios will noted and further used for calculating the confidence intervals.
Figure 7. Burst Time in Wireshark Properties
Figure 8 illustrates the IO graph showing the normal state operation after the burst from Wireshark analyser. The peak point in the graph shows the exact time of the burst occurred.
Figure 8. Wireshark IO Graph showing Normal State Operation after Burst
Confidence intervals are built at a certainty level, for example, 95% chosen by the client. On the off chance that a similar simulation is inspected on various events and interval appraisals are made on each event, the subsequent intervals would be between in roughly 95% of the cases. These intervals give more data than point estimates. Whenever repeated tests were taken and the 95% confidence interval registered for each example, 95% of the interval would contain the populace mean. Normally, 5% of the interval would not contain the population mean. It is normal to translate a 95% confidence interval as an interval with a 0.95 probability of containing the population mean. The confidence interval can be calculated by mean, standard deviation, and with a number of samples. Confidence intervals can be calculated by using below formula.
where, X is the mean
Z is the Z-distribution value
S is the standard deviation
n is the number of samples
In this section, the results generated from the evaluation of CC mechanisms in global event traffic scenario by using Cooja simulator and Wireshark are discussed.
The Settling Time (ST) is analysed for the global event scenarios. In these scenarios, the nodes produce an overall normal network load of 4 kbps in the grid topologies and 2 kbps in different topologies towards the primary sink node. During the burst, CoCoA and CoCoA+ measure numerous feeble RTTs, prompting an expansion of the overall RTO. In the wake of transmitting all the notifications, the grid begins working normally once again. Default CoAP has no state memory and applies the default RTO to all message transmissions. Upon a init condition of abrupt congestion, it, subsequently, does not adjust its RTO values. The RTO timers of CoCoA and CoCoA+ after the burst are as yet influenced by the RTT estimations acquired during the condition of substantial congestion and need to adjust to the normal traffic once again. Tables 1, 2, and 3 list the STs for the three CC mechanisms in all topologies considered for the 100%, 50%, and 25% LDR settings, respectively with enabled MAC layer retransmissions and null RDC.
Table 1. Settling Time Values with 95% Confidence Intervals in 100% LDR. Best Results are Highlighted in Bold
Table 2. Settling Time Values with 95% Confidence Intervals in 50% LDR. Best Results are Highlighted in Bold
Table 3. Settling Time Values with 95% Confidence Intervals in 25% LDR. Best Results are Highlighted in Bold
In addition to the average ST, the 95% confidence intervals are given, indicating how much the ST values oscillate for the repetitions of the burst traffic simulations. In the grid and chain topologies, CoCoA+ recovers from congestion faster than the other CC mechanisms, except for the 7x7 grid scenario with 50% LDRs, where default CoAP recovers as fast.
When using CoCoA, it takes longer for the network to get back to its original state, since the RTOs are set to very high values and packet losses lead to large delays. Also, high RTO values calculated during the notification burst require the exchange of several CoAP messages in the not congested network to get back to low values. Default CoAP does not increase its RTO timers during the burst event and therefore continues transmitting messages during and after the burst with default RTOs. As a result, it does not adapt its initial RTOs like CoCoA and CoCoA+ do. On one hand, this means that it avoids the issues CoCoA has when adapting to the congestion by heavily incrementing the RTOs. On the other hand, it does not increase the RTO values at all.
As a consequence of behaving independently from network conditions, it can be observed that the performance of default CoAP in comparison to the other CC mechanisms varies with each topology. In the grid topologies it performs better than CoCoA and in the chain and dumbbell topologies, it performs worse than CoCoA. However, CoCoA+ always outperforms default CoAP or performs at least as well.
In this paper, a performance investigation is done on Default CoAP, CoCoA, and CoCoA+. By evaluating the generated results of the three CC mechanisms, CoCoA+ can beat Default CoAP and CoCoA in the vast majority of the assessed topologies, global event traffic scenario and different Link Delivery Ratio settings. CoCoA+ is flexible against sudden changes in network traffic and adjusts rapidly to various conditions of network congestion. In some scenarios, CoCoA+ underperforms CoCoA. Although it performs still better or fundamentally the same as Default CoAP.
In actuality, CoCoA cannot give a reliably preferred execution over default CoAP, frequently failing to meet expectations. Considering that the main criterion is to propose a suitable congestion control mechanism for CoAP, CoCoA is not an appropriate mechanism. In light of this paradigm and the outcomes acquired in this paper, CoCoA+ to be an exceptionally strong and promising proposition for an advanced CC mechanism for CoAP.
As future work, the CoAP advanced congestion control mechanisms have to be evaluated in more network topologies and need to be evaluated in real IoT constrained devices for finding the interactions over the internet will be important to affirm the performances of CC mechanisms. Moreover, investigations of newly proposed CoCoA+ parameters are required.