# Congestion Control in CoAP Observe Group Communication
## 2 CoAP Congestion Control  
CoAP is regarded as a Representational State Transfer style (RESTful) protocol [19] designed for constrained nodes and constrained networks which support IoT functions. With lightweight messages, it requires fewer resources and less server energy consumption than other competing protocols. It can also support activations from clients. As mentioned earlier, it was designed and developed by the Internet Engineering Task Force (IETF) [20]. It falls under a two-layer structure: (1) a messaging layer which deals with the UDP for communications, and (2) a request/response layer which supports the RESTful protocol. The latter is based on the URI/URL of the request message for retrieving data. Broadly speaking, CoAP defines four message or transaction types: (1) confirmable (CON), (2) non-confirmable (NON), (3) acknowledgement (ACK), and (4) reset (RST) [19]. Regarding the CoAP message exchange in the request/response layer interaction model, the request layer deals with either the CON request or the NON request in terms of message transmission. The response layer deals with delivering messages by means of a piggyback response which goes along with the ACK message. In other words, reliable message transmission in the CoAP occurs due to the CON message, which is reliable and is based on the default timeout and Binary Exponential Backoff (BEB) during the retransmissions. At this stage, the server that receives the data sends back the ACK message with exactly the same (confirmable) message ID (MID) as the client previously delivered. On the other hand,for unreliable message transmissions, the CoAP can send the NON message, meaning the server does not send back the ACK response. The server itself records the MID to detect the same message instead. Specifically, the reliable message transmission [21; 22; 23] of the CoAP for the CON message exchange is classified into two types: (1) the CoAP (CoAP-based) protocol, and the Observing Resource (Obs) protocol, as illustrated in Figure 1a,b, respectively. It is notable that the Obs, which this study focuses on, requires registration from the client as an observer. Then, the server sends notifications with the CON message. This differs from the CoAP-based protocol whereby the CON message is initially sent from the client. Another important aspect relies on the CoAP congestion control [17; 18], which was established to limit the delay between requests for message transmission and to limit the number of messages exchanged. As the CoAP works on the four message types previously mentioned, this operation is performed under the request/response layer. The reliable messages in the CoAP-based communication from either the CoAP-based transmission or the Obs transmission were obtained using the CON message and required an ACK message from the server. In addition, the congestion control mechanisms allow the CON message to retransmit up to four times before considering the transmitted message to be an error or failure. For the first message transmission, the RTO value was randomly selected from an interval of 2-3 s as an initial value. The BEB was also applied to the RTO, causing the RTO value for each transmission to double. This was, therefore, similar to TCP [3]. Please see Figure 2 for the whole picture of the congestion control via reliable messages. Figure 1: (a) Constrained Application Protocol (CoAP)-based message transmission; (b) Observing Resource message transmission. CON: confirmable; ACK: acknowledgement. Figure 2: (a) Default CoAP-CON mode; (b) Observing Resource-CON mode. RTO: retransmission timeout; BEB: binary exponential backoff. The default CoAP mechanism typically relies on RTO and BEB as its two core algorithms. Indeed, the CoAP does not adjust the RTO in accordance with the round-trip time (RTT). Consequently, if the chosen RTO value for the default CoAP mechanism is below a certain RTT, this may result in a failure of retransmission from the CoAP.