A Reliable CoAP Protocol for IoT Communication

A Reliable CoAP Protocol for IoT Communication | Research Square window.SnipcartSettings = { analytics: { enabled: false } }; (function() { var accessVector = localStorage.getItem('access_vector') || ''; window.dataLayer = window.dataLayer || []; if (accessVector) { window.dataLayer.push({ user: { profile: { profileInfo: { snid: accessVector } } } }); } })(); (function(w,d,s,l,i){w[l]=w[l]||[];w[l].push({'gtm.start':new Date().getTime(),event:'gtm.js'});var f=d.getElementsByTagName(s)[0],j=d.createElement(s),dl=l!='dataLayer'?'&l='+l:'';j.async=true;j.src='https://www.googletagmanager.com/gtm.js?id='+i+dl;f.parentNode.insertBefore(j,f);})(window,document,'script','dataLayer','GTM-K279D39R'); Browse Preprints In Review Journals COVID-19 Preprints AJE Video Bytes Research Tools Research Promotion AJE Professional Editing AJE Rubriq About Preprint Platform In Review Editorial Policies Our Team Advisory Board Help Center Sign In Submit a Preprint Cite Share Download PDF Research Article A Reliable CoAP Protocol for IoT Communication Sharu Bansal, Dilip Kumar This is a preprint; it has not been peer reviewed by a journal. https://doi.org/ 10.21203/rs.3.rs-1974849/v1 This work is licensed under a CC BY 4.0 License Status: Posted Version 1 posted You are reading this latest preprint version Abstract The request-response model for constrained devices is achieved via RESTful architecture of Constrained Application Protocol (CoAP) in IoT. An enhanced CoAP is proposed to address the limitations of CoAP to achieve an efficient IoT network. Unlike existing protocols that operate on instantaneous Round-Trip Time (RTT) in IoT, it also makes use of CoAP options, payload, and node distance for defining the network state in a better way. Various new parameters viz. timestamps, priority, message path, device status is introduced and CoAP payload is defined using SenML representation of data. The processing unit at the network level is used for data analysis of the integrated parameters that are timely communicated to this unit from the network nodes. The algorithm with varying data rates is used in homogeneous and mixed traffic to calculate the performance. The significant improvement in terms of delay, priority, congestion, retransmissions ensure reliable communication in the network. CoAP IoT Delay Congestion Priority Figures Figure 1 Figure 2 Figure 3 Figure 4 Figure 5 1. Introduction The CoAP is an application layer web transfer protocol. CoAP is designed for constrained environment considering energy and machine-to-machine (M2M) communication implementations. Request/response interaction model between endpoints is provided by CoAP which also supports in-built mechanism for service/resources discovery. It is a constrained implementation of REST architecture and is based on protocols like HTTP [1]. It supports Web concepts such as URIs and media types etc. It is designed to interface with HTTP via proxy for web integration, multicast support scalability and efficiency which is achieved with low overhead and simplicity [2][3]. Some M2M features provided by are asynchronous messaging, multicast support and built-in discovery. The cost of header and complexity of parsing is low in CoAP. The security binding is via Datagram Transport Layer Security (DTLS) for CoAP-CoAP, HTTP-CoAP proxy communication [4][5]. The client sends a CoAP request for an action on a server-side resource. The response is sent by the server containing response code. CoAP communication is asynchronous over a datagram-oriented transport like UDP [6]. Four types of CoAP defined messages are Confirmable, Non-confirmable, Acknowledgement, Reset. CoAP requests are Confirmable and Non-confirmable and CoAP response can be Acknowledgement along with Confirmable and Non-confirmable [7]. In constrained network, CoAP is a messaging protocol used as a standard for constrained nodes and devices. In the network of constrained devices, nodes or devices are not able to respond well on time due to large delay and congestion. So, there is need of a protocol which works on this problem to give the better performance. In this paper, we introduce RCoAP which gives reliable transmission by using the delay, priority factor and congestion. To solve the problem of delay there is need to add the delay tolerance factor in the CoAP protocol in both sides’ client and server. The client or server require the information or data after some time. At that time, they may respond to some other urgent tasks by introducing delay tolerance in the request. Whenever the data is transferred from client/server side, it always gives the information that how much time it can tolerate the delay so that higher priority task gets completed. By receiving the information, server or client schedule their all the task according to the priority. There is also an issue when server/client is too busy to respond any request. At that time, they can go to the sleep mode until its request get responded. By doing this, lot of energy will be saved. It also solves the problem of scheduling of server and client whenever they are busy. In constrained network the probability of packet loss and latencies is high. This leads to untimely delivery of data messages i.e., delayed messages. Moreover, the message should be prioritized. In case message priority is sent along, the combination of delay and priority can be used to control the flow of messages in network. The delay leads to loss of energy, network blockage. CoAP message currently don’t support delay and priority in default standards. But the options in CoAP can be used to send delay and priority parameters. This change would promote communication improvement in constrained network. Incorporating delay awareness would help both server and client end by saving energy. When client and servers are aware of delay, they could go to sleep mode. The network confronts congestion because of an increase in hardware requirements on a small network. Congestion causes delay, packet loss, and collisions in network. Some mechanism to control and avoid congestion is required. Congestion control is essential for smooth operation and timely delivery. The CoAP protocol's congestion control method is critical. CoAP makes use of UDP, which has no congestion control. Retransmissions are part of the CoAP implementation to help in congestion avoidance. To minimise transmission rates, an exponential back-off method is used between retransmissions. However, collisions might result in multiple retransmissions, which can result in packet loss and congestion issues. The main aim of the work is to introduce a protocol for reliable transmission in terms of delay, priority, and congestion. The novelty and contributions of the paper- This paper tries to give a solution for a real-time problem of a reliable CoAP protocol transmission compared to the existing CoAP using node and communication state. Priority and Delay control mechanism, enhanced congestion control mechanism has been brought together to build an enhanced CoAP. Various new CoAP message parameters have been introduced for enhanced CoAP. Data compression mechanism has been introduced to mitigate the overhead of increased packet size due to new parameters added to enhanced CoAP messages The unconstrained central unit has been introduced for processing the information captured by existing and new CoAP parameters and thus reducing the processing overhead at constrained node. Performance is evaluated by considering two different traffic scenarios– homogeneous and mixed traffic and three performance metrics are considered by taking different topologies. 2. Rcoap CoAP message format comes with set of defined parameters. Some of the significant parameters are source address, destination address, Token ID, Message ID. Along with these parameters Reliable CoAP (RCoAP) define some additional CoAP options and payload for enhancing the reliability of existing CoAP. RCoAP is enhanced CoAP which adds new parameters to CoAP. This protocol works in sync with central unit and defines features like data transfer path, gateway-sensors mapping, time, priority, activation/deactivation of constrained devices and more parameters. The increased size of the CoAP message due to the added parameters has been mitigated by introducing Data compression using SenML language. The output of this protocol results in increased and managed throughput on same bandwidth. The data flow channels would be managed to restrict collisions and void messages. The priority factor would be a considered for ordering the message processing. The delay in the network is regularly observed to control the future messages flow. 2.1 Problems statements addressed by RCoAP 1. No Delay indicator – RCoAP would use CoAP parameters to define a delay flag indicating the presence of delay both at server and client side. Whenever a CoAP message will start, the start timestamp would be added to parameters. Along with the delay flag, the absolute delay time range would also be shared which is relative to start timestamp. Once the message departs then timestamp is captured. All this data will be captured and shared to central unit for saving and analysing the information [8]. The benefit to server and client is as follow a) Client – Delay message sent from client to Server would indicate that client would be available in the time range specified. It would help server to work on other requests. b) Server – Delay message from client to server would help server to go into sleep mode while there would be no message coming for a specified range. c) IoT network - When both client and server are aware of the availability of each other, then the messages would be sent accordingly. This would help control the IoT traffic and hence streamline the flow of messages d) Data shared to central unit – As the data would be shared to central system. So, the central system can analyse and control throughput. It could pass instructions to the servers and clients for due actionable. 2. No priority indicator – There is a big lag in CoAP that CoAP message format don’t define priority indicator, RCoAP could define priority indicator as an option. Priority concern comes into play at server end. Based on priority the message could be processed. The priority information would be passed on by a sensor node that central unit will provide [9]. 3. Retransmission indicator – According to CoAP standards, there are chances of message remaining undelivered. CoAP reply on acknowledgement for the same and further retransmits message four times [10]. But the message retransmission information is not saved and remains unused. However, this retransmission information can be used for turning CoAP into RCoAP. Server/Client could define options to capture this information. RCoAP uses retransmission indicator to represent the number of retransmissions occurred along the timestamps of retransmission. This represents busy or broken network. 4. Update indicator – CoAP identifies the update based on the Token ID. But for R-CoAP, update indicator represents the update in delay. So, in case of an update in delay message, the update information would be sent along with the original message delivery. This would reduce processing of the nodes. 5. Failed message indicator – Post maximum retransmission, the message is considered as failed. The new message with new token and message ID is sent. But failed information is not saved. But for R-CoAP, the timestamp and retransmissions are captured [11]. 6. Distance indicator - Distance indicator would contain the distance between the two nodes where the message will travel. Based on the distance the CoAP initial RTO could be calculated to reduce the chances of retransmission. All the above information is further timely passed on to the central unit 2.2 Mechanisms introduced to default CoAP 2.2.1 Delay mechanism IoT applications are a way of connecting things. At real world, IoT applications is more towards enabling connected things with no human presence. This can be ensured by avoid bad situations before it occurs or at the starting stage. Delay mechanism becomes a key factor for ensuring reliability. The new parameters are added to CoAP messages are message send timestamp, Delay flag, Delay time There are situations in IoT world where delay tolerated message are acceptable but simultaneously there are critical messages where delays are not acceptable. Consider a fire alarm sensor for sensing a spark or a fire. For IoT system the delay should be least. In case water or CO 2 extinguishers are present, the client sends message with no delay the mishappening would be saved. While there are sensers measuring like humidity, temperature for the day, the delay could be tolerated even in case some messages are missed [12]. Following are the key requirements for implementing the delay mechanism Requirement 1 – Timely arrival of data . There are scenarios where a miss or delay of data impact the system negligibly whereas for some systems even a small delay can make the situation worse e.g. In one system is maintaining the average humidity, temperature of the day while other system is a fire extinguishing setup. Requirement 2 – Cost of the operational energy . The operational cost is dependent on the messages being sent. So, in case node 1 is communicating with node 2 but is unaware that node 2 is corrupted, would cause a lot of f operational energy while the other scenario is the one node is waiting for the response from node 2 where the energy could be saved in sleep mode during the inactive timings. Requirement 3 – Cancelling the old unnecessary/delayed requests. The node keeps waiting for the response while the system is aware of the old successful communication between the nodes could cause unnecessary retransmissions. The other scenario is that the server sends where response would not reach within RTO time and the client send retransmission. This results in energy time wastage of server as well as client node. This would create unnecessary messages to travel thus reducing network bandwidth. Delay can be made aware via 3 messages of existing CoAP that are Delay tolerance for Client CON – DCC, Delay update for Server CON – DSC, Delay update for Server ACK - DSA DCC - this is a delay parameter sent from client side to update server about the time tolerance that exists for client before message goes invalid. So, client will wait maximum for a particular time. This is very fruitful for client to save energy. The client sleep mode and wake mode can be adjusted, and time is sent accordingly. DSC - This is the delay update shared by server to all the clients to share unavailability or if processing queue is full. Now the possibility is that server needs to go to sleep mode, or server analysed congestion in network or a scenario that server can take only high priority request as the queue to solve requests is full. This message to the client would help not to send more messages on the network thus avoiding the bandwidth to reduce. This will avoid packet loss and delay. DSA - This is delay integrated along with acknowledgement to the client request send by server to client to inform that the response would be delayed by this tenure. In case the server has taken the request, but it won’t be able to respond in the time frame shared by client. In this scenario server updates client not to wait for response in the time frame. But also instructs client about the delay after which response will come. This avoids unnecessary retransmissions in the network. 2.2.2. Delay based possible solutions Client-side - For CON send message, client sends a message to server with max delay wait time and client sends a message to server in case of system fault/battery low with a delay as possible recovery time. For ACK receive message, client receives an acknowledgement regarding the delay in response and receives an acknowledgement regarding the server not able to process with a possible time when client should reconnect. For CON receive message, client receives CON regarding the server fault/battery down so that client can destroy the current message and go sleep and when client receives a message on the update of delay in response from server. Server-side - For CON receive message, server checks for the delay and accordingly align the message in the processing queue and server sending CON message to the clients to update with the status of unavailability due to low battery/system fault. For ACK send message, server sends an acknowledgement with the possible delay in message due to FULL processing queue. Also, server can send the initial delay in form of acknowledgement to client. For update CON send message, server sends update if the response could not be delivered within the initial mentioned delay time 2.2 Priority Mechanism Each server has a queue. Normally requests are processed in FIFO order. All incoming request is to be processed by the server which is placed in the queue. As per the priority mechanism the request is to be processed based on the request priority. In case a high priority request comes, it should be given precedence. In case a high priority request comes, the server should removes/delay the lowest priority and updates the corresponding client. The priority is assigned to each sensor node as a node attribute based on the type of sensor. The fire alarm sensor has highest priority set where’s the humidity sensor measuring daily humidity of a city is assigned a least priority. The sensor priority is assigned based on the IoT system in which the sensor is installed. The node algorithm picks the device priority parameter and sends it along with the CoAP message. The server reads the message and bases on the priority adds the message to the queue. The schedular invokes the priority algorithm, passing the request as an input (line 1). The algorithm looks for a slot based on the request priority (line 2). The algorithm examines four priorities (00, 01, 10, 11), with 00 being the highest and 11 being the lowest. This has been updated to include no slots (line 12-17). A function looks for a priority-based slot in the queue (line 19). This algorithm assures that all slots over 95 percent are reserved for priority 00, all slots above 90-95 percent for priority 01, all slots above 85-90 percent for priority 10, and all slots above 80-85 percent for priority 11. To ensure that the highest priority message gets an empty slot, this algorithm will only accept priority 00 requests and ignore priority 01, 10, and 11 requests (line 19-34). When the maximum slots for a priority are full up for 10 and 11, and no lower priority requests can be withdrawn in the case of 00 and 01, the function no slot comes into play. When there's a chance of getting an empty slot, the future time is calculated, and an acknowledgement is provided to the client notifying them of the rejected action and the new proposed time (line 35-38). If a slot is available, the lower priority request is changed with the current request, and the lower priority client is notified that the request will not be processed, as well as the new possible time for an empty slot. (line 39-46). Algorithm I Priority 1. function Ser_Req_Priority(REQ){ 2. flag_slot = check_queue_slot(REQ.priority) 3. if(priorty = 00 || priorty = 01){ 4. if(!flag_slot){ 5. flag_remove = remove_low_priority(priorty) 6. if(flag_remove) 7. schedule (REQ) 8. else { 9. no_slot(REQ) 10. } 11. } 12. else if (flag slot){ 13. schedule (REQ) 14. } 15. else { 16. no_slot(REQ) 17. } 18. } 19. function check_queue_slot (priority) { 20. if (priority == 00) { 21. flag = slot_95_100_per () 22. } 23. else if (priority == 01) { 24. flag = slot_90_95_per () 25. } 26. else if (priority == 02) { 27. flag = slot_85_90_per () 28. } 29. else if (priority == 03){ 30. flag = slot_80_85_per () 31. } 32. else 33. TRUE 34. } 35. no_slot(REQ){ 36. time = compute_proposed_time(REQ) 37. ACK_update(ACK, time) 38. } 39. remove_low_priority(priorty){ 40. REQ = find_low_priority() 41. if (REQ.found) 42. ACK_update(ACK, time) 43. return true 44. else 45. return false; 46. } 2.3 Congestion mechanism The congestion mechanism makes use of the distance between nodes to calculate the retransmission timeout (RTO) value, which helps understand if the two communicating nodes are nearby or distant ones. In basic CoAP, RTO was not dependent on RTT value and later certain solutions came where different RTO values computed considering RTT. However, the paper [13] consider distance between the nodes along with the RTT values for computing RTO. This mechanism would enable to pick nearly optimal value based on the distance ensuring for nearby nodes RTO is small while for distance nodes initial RTO is large. These calculations would be computed by central unit and the logical programs at node end would use the analysed information before the message is sent. This would ensure the void messages and avoid unnecessary transmissions implementing a congestion mechanism. For enabling the mechanism two important factors are the distance between all the nodes of the network and the second is the RTO computing factor which decides the RTO value based on distance. When the number of retransmissions is less than two, Algorithm 2 is used; otherwise, the default technique is used. Strong RTT is calculated using the RTT value (line 2). Node weight (line 4) is determined depending on the levels, and then distance based RTO is calculated (line 5). For computing future RTO, final weighted RTO in terms of RTO, is added to strong RTO (line 6-9). Algorithm II RTO Calculation function RTO_DIS (RTT, level, CON) 1. RTTstr = RTT 2. RTTstr = (1 −α) RTTstr + αRTT 3. NW = level * k 4. RTO distance = δ * RTTstr 5. if (RTO distance < RTOdef) 6. RTO weight = N weight * RTO distance 7. else 8. RTO weight = N weight * (RTO distance - RTO def ) 9. RTO = RTTstr + RTO weight 2.4 SenML language for data compression Sensor Markup Language (SenML) is a specification defining media types for carrying sensor information in CoAP protocol. It was designed for constrained processors to encode sensor measurements to SenML media type at client side and at server side parses the data efficiently for large number of sensor measurements. Most of the meta data about the nodes are not carried in this media type thus reducing the data size ensuring efficient decoding. The meta-data is published out-of-band using the CoRE Link Format [RFC6690][14]. The data feeds are pushed from a sensor to a collector as a resource representation (e.g., "GET/sensor/temperature"). SenML is defined by a data model and meta-data about measurements and devices. The data is structured as a single array that contains base value object(s) and array(s) of entries. Each entry is an object that has attributes such as a unique identifier for the sensor, the time the measurement was made, and the current value. Serializations for this data model are defined for JSON, CBOR, XML, and Efficient XML Interchange (EXI). For example, the following shows a measurement from a temperature gauge encoded in the JSON syntax. [{},[ { “n": "urn:dev:ow:10e2073a01080063", "v":23.5, "u":"Cel" } ] ] In the example above, the first element of the root array is empty object since there are no base values. The second array inside the root array has a single measurement for a sensor named "urn:dev:ow:10e2073a01080063" with a temperature of 23.5 degrees Celsius. The semantics of SenML language represents that each SenML carries a single array representation of set of measurements and/or parameters. The array constitutes one base object of optional attributes and one mandatory array of multiple entries [15]. Base Name(optional): A string prepended to names in entries. Base Time(optional): A time added to time in entries. Base Units(optional): A unit assumed for all entries. Version(optional defaults to 2): Version of media type format. The measurement/parameter array are mapped to sensor measurement or other parameters viz configuration with at least one entry and is called measurement array. each array entry has multiple attributes(optional/mandatory) Name(mandatory if base name not present): Sensor/Parameter name. The global unique identifier for the resource is once added with base name. Units(Optional): Measurement unit. Value(Mandatory if sum is not present) Value of the entry. Represented with 3 data types, Floating point numbers ("v" is "Value"), Booleans ("bv" is "Boolean Value") and Strings ("sv" is "String Value"). One is must Sum(Optional): Sum of the values over time in seconds. Time(Optional): Recorded time. Update Time(Optional): Time interval in seconds to provide reading. Used to detect the failure of sensors/communication. SenML format features to extend custom attributes in both base/entries of arrays. Reading system should check for the version. Each system should not process object beyond its version limit. E.g. - Name value concatenated with Base Name to get unique sensor identifier. URI also identifies the name of the resource of request. Uniqueness needs to be guaranteed uniqueness. Similarly other attributes are computed. The missing attribute default value is zero. A negative value indicates action in past. SenML can carry the minimum dynamic information about measurements and does not carry static meta-data for devices for efficient communication but is carried out of band like using the CoRE Link Format [RFC6690] via listing and reteriving the resouces list. The sample attributes are title, resource type, interface description, and content-type etc JSON Representation (application/senml+json) Base object variables: +------------+------+--------+ | SenML | JSON | Type | +------------+------+--------+ | Base Name | bn | String | | Base Time | bt | Number | | Base Units | bu | Number | | Version | ver | Number | +------------+------+--------+ Measurement or Parameter Entries: +---------------+------+----------------+ | SenML | JSON | Notes | +---------------+------+----------------+ | Name | n | String | | Units | u | String | | Value | v | Floating point | | String Value | sv | String | | Boolean Value | bv | Boolean | | Value Sum | s | Floating point | | Time | t | Number | | Update Time | ut | Number | +---------------+------+----------------+ 2.5 Role of Central Unit Central Unit is analytical and logical part of IoT system where large programs have been designed by the programmers. This system has no constraint in terms of storage, power, and computational capability [16]. Few of the analysis that are performed in central system with consideration of R-CoAP are as follows based on thousands and lakhs of messages flow- 1. Identification of the frequency of messages from client/server 2. Identification of the duration at which each device is most occupied 3. Identification of the priority messages route and most active duration 4. Identification of busy route along with timestamps 5. Identification of busy or broken network. This analysis is based on the message failure and retransmissions. 6. Identification of best path to avoid network issue due to high message flow. 7. Computing the initial ideal RTO based of the distance between the nodes. All the information is captured and saved in central DB. Multiple programs run on them to find out a high-level graphical pattern of the network. 2.5.1 Central Unit analysed information usage A table of final observations formed is timely passed on to the devices using SenML. This information gets updated regularly on network defined algorithm. This information is very brief, so that constrained devices can capture and use while transmission. A logical program is installed on all nodes. Whenever a constrained device (client/server) needs to send any CoAP message, the logical program runs. The Analytical information from Central unit is used by this program to add R-CoAP parameters to the CoAP message before sending [17]. Some of the key benefits are- There are also chances the during a certain duration of day a device is highly occupied and sending more messages would increase device overhead which may lead to device break. So, the messages can be streamlined and send based on priority. Some of the messages of very low importance can be avoided in network and sent when retransmission rate is very low. In case of high retransmission only high priority messages would flow in network. The devices could sleep and become active based on the analytical assumption. Central system can control the flow of messages wherein energy consumed is high and network outcome is negligible. The activation and deactivation of devices can be controlled so that the frequency and packet flow is proportional to bandwidth and inversely proportional to latency and packet loss. Best route is defined according to the message flow and avoid collisions and network failure. 2.6 Additional parameters and their requirement in RCoAP First requirement is to sub classify the CoAP messages. For this MSG_SUB_TYPE is added. CoAP provides CON, ACK, NON, RST. But RCoAP algorithms need a detailed message type to differentiate the activity and message source client/server. These are SER_CON, SER_ACK, CLI_CON, CLI_ACK, SER_UPD, CLI_UPD, UPD_OLD. Second requirement is to capture Retransmission observations. Parameters for this are CRT(Count Retransmission), RT1, RT2, RT3 and RT4 (Retransmission TIMEstamp) CRT is to tell the count of retransmission but RTX defines the proper time stamp of retransmission. Also, RCoAP requires to capture FAILED_STATUS in case all retransmissions are unsuccessful. This would help identify congested network. Third requirement is to indicate the delay. This delay can be either for client or server. So, the parameters are DELAY_IND, DELAY_TIME_START_RANGE, DELAY_TIME_STOP_RANGE. DELAY_IND is to tell if delay needs to be processed and remaining parameters have time in milli seconds Fourth requirement is to capture the actual time stamp of the message which is identified by parameter MESSAGE_TIMESTAMP. Fifth requirement is to keep the status of updates. This can be used by server/client to update on existing values rather than a complete processing of the message again. Parameters are UPDATE_IND and UPDATE_TIMESTAMP Sixth and one of the most important features of RCoAP for reliability is to define priority of the message on a scale of 1-4 as an option. This will allow high priority messages to be processed earlier. Seventh requirement is to hold the distance (DIS) between the client node and the server node for CoAP RTO calculation to avoid retransmission and network congestion. In last the RCoAP message is appended with device ID of each while data travels in multi-hop system to keep track of path. As part of RCoAP, there would be timely message delivered to the devices from the central unit of IoT system after processing the parameters in RCoAP. As IoT is a constrained network, this data will flow as CoAP payload after a predefined interval. Each device information will flow in the form of an object as a CoAP payload and to reduce the bandwidth overhead that would be caused due to the additional parameters, data compression mechanism is introduced using the SenML langauage. 2.7 Algorithms and Flowchart for RCoAP 2.7.1 Client side - RCoAP program handles all incoming and outgoing messages. Whether it is an incoming message or an outgoing message, the message must undergo certain steps. CoAP message flows in with certain attributes like Token ID, message ID, Source/Destination nodes etc. There are sub programs which are called in an order. The first program called is "PRO_ANALYSE_INPUT" which analyses the message and decides on incoming/outgoing message. So, in case if it is an incoming message, it furthers checks about the type of incoming message and accordingly call the program to analyse the message. Based on the message indicator as new or update the PRO_SERVER_NEW_MESSAGE_ANALYSER or PRO_SERVER_UPDATE_MESSAGE_ANALYSER is called to capture the parameters in the message for central unit analysis. Algorithm III Client Side Input : CoAP Message with parameters like message type, Token ID, Message ID, source and destination servers Output : Parameterized DTO for Data storing and processing and flowing CoAP_Delay_Handler_START(Input, Output) 1 PRO_ANALYSE_INPUT(Input, Output) 2 if(MSG_FLOW := IN) 3 IF(RESPONSE_TYPE := NEW) 4 PRO_SERVER_NEW_MESSAGE_ANALYSER(Input, Output) 5 ELSE(RESPONSE_TYPE := UPDATE) 6 PRO_SERVER_UPDATE_MESSAGE_ANALYSER(Input, Output) 7 else if(MSG_FLOW := OUT) 8 IF((MESSGAE := UPDATE_ON_OLD) 9 PRO_ADD_UPD_PARAMS(Input, Output) 10 ELSE 11 PRO_ADD_NEW_PARAMS(Input, Output) 12 PRO_SET_PRIORITY(Input, Output) 13 WHILE(RETRANSMISSION<=3) 14 PRO_DELAY_UPDATE(Input, Output) 15 SEND_MESSAGE 16 IF(ACK_RECEIVED) 17 BREAK; 18 ELSE 19 PRO_UPDATE_RE_TRANS_PARAMS(Input, Output) 20 IF(RETRANSMISSION = 4) 21 PRO_UPDATE_FAILED_PARAMS(Input, Output) 22 BREAK TO STOP; 23 PRO_ACK_FROM_SERVER(Input, Output) 24 PRO_STORE_INFO_FOR_ANALYTICS(Input, Output) 25 PRO_ACK_TO_CLIENT(Input, Output) 26 PRO_CLIENT_ACTION(Input, Output) CoAP_Delay_Handler_STOP Algorithm IV Server Side Input : CoAP Message with parameters like message type, Token ID, Message ID, source and destination servers Output : Parameterized DTO for Data storing and processing and flowing CoAP_Delay_Handler_START(Input, Output) 1 PRO_ANALYSE_INPUT(Input, Output) 2 if(MSG_FLOW := IN) 3 IF(RESPONSE_TYPE := NEW) 4 PRO_PRIORITY_ANALYSER(Input, Output) 5 PRO_CLIENT_MESSAGE_ANALYSER(Input, Output) 6 ELSE(RESPONSE_TYPE := UN_ACK) 7 PRO_ACK_FROM_CLIENT(Input, Output) 8 else if(MSG_FLOW := OUT) 9 IF(REQUEST_TYPE := SEND_SERVER_AVAILBILITY) 10 PRO_ADD_AVIAL_PARAMS(Input, Output) 11 ELSE 12 IF((MESSGAE := UPDATE_ON_OLD) 13 PRO_ADD_UPD_PARAMS(Input, Output) 14 ELSE 15 PRO_ADD_NEW_PARAMS(Input, Output) 16 WHILE(RETRANSMISSION<=3) 17 PRO_DELAY_UPDATE(Input, Output) 18 SEND_MESSAGE 19 IF(ACK_RECEIVED) 20 BREAK; 21 ELSE 22 PRO_UPDATE_RE_TRANS_PARAMS(Input, Output) 23 24 IF(RETRANSMISSION = 4) 25 PRO_UPDATE_FAILED_PARAMS(Input, Output) 26 BREAK TO STOP; 27 PRO_ACK_FROM_CLIENT(Input, Output) 28 PRO_ACK_TO_CLIENT(Input, Output) 29 PRO_STORE_INFO_FOR_ANALYTICS(Input, Output) 30 PRO_SERVER_ACTION(Input, Output) CoAP_Delay_Handler_STOP Similarly, if the message is coming from client node, the program checks if the node is sending an update with respect to an already sent message or it is a new communication. For update message PRO_ADD_UPD_PARAMS program runs to add parameters and for new PRO_ADD_NEW_PARAMS program executes to add parameters. Once parameters with respect to the type of message are added then PRO_SET_PRIORITY sets priority based on node priority. Once the transmission sends triggers, it checks for three more retransmissions and accordingly call PRO_DELAY_UPDATE program to keep updating delay parameters analysed from previous network transmissions. If acknowledgement is received, the transmission is completed else it tries for three more times and keep capturing and updating retransmission parameters using program PRO_UPDATE_RE_TRANS_PARAMS. If transmission fails four times, then PRO_UPDATE_FAILED_PARAMS program captures failure related to full data so that data is analysed and next time the retransmission parameters are accordingly set to avoid failure. Once an acknowledgement is received PRO_ACK_FROM_SERVER program captures data related to the transmission. PRO_STORE_INFO_FOR_ANALYTICS programs capture all data of transmissions, and this data is analysed by the central unit for upcoming transmissions. PRO_ACK_TO_CLIENT programs look for the acknowledgement received related from server end and based on which PRO_CLIENT_ACTION ensures to act on clients like sleep in case response time is huge to save energy. 2.7.2 Server side- RCoAP program handles all incoming and outgoing messages in the similar way. Based on incoming/outgoing message, the message undergoes predefined steps. The CoAP messages have attributes like Token ID, message ID, Source/Destination nodes etc are stored in Parameterized DTO for message processing. The first program "PRO_ANALYSE_INPUT" is called to analyse the message and decide if the message is incoming/outgoing. For incoming message, it checks for message type and call the appropriate program for message analysis. For new message the program PRO_PRIORITY_ANALYSER is called to analyse message priority and then PRO_CLIENT_MESSAGE_ANALYSER program analyses client message. In case of an acknowledgement PRO_ACK_FROM_CLIENT the acknowledgement from client is managed. Similarly for out messages from server, the program checks if the message is on the server availability, PRO_ADD_AVIAL_PARAMS is called. Program PRO_ADD_UPD_PARAMS is called in case of the update on an existing request while PRO_ADD_NEW_PARAMS program is called for the new request. The program respectively updates the parameters based on the message type. Once the message triggers, three more retransmissions are done in case of acknowledgement not received. In case of retransmission PRO_DELAY_UPDATE program executes to update delay parameters analysed from previous network transmissions. If acknowledgement is received the transmission is considered completed else, it tries for three more times and keep capturing and updating retransmission parameters using program PRO_UPDATE_RE_TRANS_PARAMS. If transmission fails four times, then PRO_UPDATE_FAILED_PARAMS program captures failure related to full data so that data is analysed and next time the retransmission parameters are accordingly set to avoid failure. Once an acknowledgement is received PRO_ACK_FROM_CLIEN program captures data related to the transmission. PRO_STORE_INFO_FOR_ANALYTICS programs capture all data of transmissions, and this data is analysed by the central unit for upcoming transmissions. PRO_ACK_TO_CLIENT programs send an acknowledgement to the client about the message received an processing status. PRO_SERVER_ACTION takes server-side actions according to the parameters received and processed. 3. Performance Evaluation Of Rcoap Based on the routing protocol (RPL) one border router, one server node, and numerous client nodes make up the RCoAP network model. All the nodes are distributed over a 100 m * 100 m space. The following are the assumptions made during the simulation, and the results are assessed using a variety of metrics. All three types of nodes are static: border router, server, and client. At regular intervals, the server nodes receive messages from the client side. Real-world nodes behave similarly to virtual nodes that have been analysed using the Contiki and Cooja simulators. TABLE I. Specification of Wismote Specifications Wismote Clock Speed 8 MHz Architecture RISC MCU Device TI MSP430F5437 RAM 16 KB ROM 256 KB By simulating Contiki and Cooja, this section shows how the RCoAP protocol's algorithms are implemented. Contiki is an open-source operating system, while Cooja is an open-source simulator. Sensor nodes that operate as server and client can be configured in the Cooja simulator, and this virtual hardware can be set as real-world nodes with real-time processing abilities and process parameters. The simulation script is described within the Cooja interface to record the performance of the simulation setup. The sensor nodes' code file for the simulation has been compiled and uploaded. The Contiki implementation, like IEEE 802.15.4, uses the default network stack, which includes physical and MAC layers as well as RPL as the routing layer. The Wismote nodes are utilized as virtual nodes in performance evaluation. The specification of Wismote is shown in Table 1. In the implementation of the enhanced protocol, the options described in the CoAP message format are used for status changes. The RPL border router relays CoAP communications. TABLE II. Simulation Parameters Specifications Operating System Ubuntu 12.04 LTS 64bit, Vmware Player 12.5.6, Instant Contiki-3.0 Language C Physical Layer IEEE 802.15.4 Routing Protocol RPL Number of Nodes 49 (Z1 and Wismote) Transmission Range 50m Area 100m * 100m Radio medium Unit Disk Graph Medium (UDGM) Traffic Type Homogenous and Mixed The border router is responsible of message routing. Once the RPL network is fully operational, client nodes begin sending CoAP messages on a regular basis. This duration value is changed during the simulation to specify the rate at which messages flow. These messages are transmitted to the sink node, which is the server node. To connect to the external network, the IPv6 for Low-Power and Lossy Networks is utilised as a border router in this design. Table II shows the simulation parameters and their relative values utilised in our simulation design. The radio medium specification indicates that the simulation uses a propagation loss model with distance loss to make it more realistic. 3.1 Performance Metrices and Traffic Type Three measures average latency, packet loss and retransmission are taken to measure the RCoAP network performance. These will help to evaluate the performance of default CoAP with RCoAP by using four types of topologies, two traffic types. On the application layer, the average latency is the time that a CoAP packet takes to travel from the source to the destination node. Packet loss is the number of packets for which the interaction was unexpectedly terminated, and the node-to-node message is lost. The number of packets retransmitted because of RTO. This assures that the number of retransmissions is reduced. The number of retransmissions is related to the amount of congested traffic. Furthermore, the lower retransmissions, the greater the network capacity and, as a result, the better the network performance. The main objective of the analysis is to figure out how many received ACK messages there are in each transaction. We analyse two different traffic scenarios homogeneous traffic and mixed traffic. The assumption in homogeneous traffic is that the network contains only reliable CoAP traffic. The transmitting rate for CoAP messages is increased in homogeneous traffic. But in mixed traffic, the network contains both reliable and unreliable traffic. The transfer rate of CoAP reliable traffic remains constant. But the main aim of analysis of mixed traffic is to see how increasing non-reliable traffic affects the reliability of CoAP traffic. 3.2 Topologies The setup can be implemented by using various static topologies. Throughout the simulation, the nodes have fixed locations and no movement. Grid, dumbbell, flower, and chain topologies are all considered. Grid topologies are used in smart grid, industrial automation, and building automation applications that need long range and large area coverage. Here, we are considered both 6m * 6m grid and 7m * 7m grid. They are designed in such a way that there is always a node within each node's transmission range. The data packets are routed through several nodes before being delivered to the server to separate the network range from the transmission range of each node. The dumbbell topology can be used to calculate the retransmissions to check the congestion in the network. Here we use 21 nodes in which border router is present at centre and all other nodes are there in shape of dumbbell. In chain topology, we consider total 20 nodes are present in straight line. This topology gives less congestion as compared to other topologies. Flower topology is used in satellite network and wide area network. As the name suggests, total 36 nodes which are arranged in form of petal. The result shows that the RCoAP improves the overall network's performance. When compared to default CoAP, RCoAP reduces average latency by 25%, and packet loss by 35%, and retransmission by 40%, resulting in improved network performance. CoAP networks with mixed traffic performance is slightly lower than a homogeneous network due to containing of void messages, but the performance metrics are much better than default CoAP. Average latency reduces by 20%, packet loss reduces by 10%, and retransmission reduce by 5% in mixed traffic, when compared to homogeneous traffic, however mixed traffic performance still improves significantly when compared to default-CoAP. TABLE III. Comparison of Topologies in terms of performance metrices Topologies Average Latency (s) Packet Loss Retransmissions CoAP (Default) RCoAP CoAP (Default) RCoAP CoAP (Default) RCoAP Grid (6m *6m) 1.734 1.612 52 35 255 102 Grid (7m *7m) 2.823 2.223 49 32 262 105 Dumbbell 0.089 0.083 30 21 172 85 Flower 1.523 1.499 33 24 180 94 Chain 0.523 0.478 46 33 235 98 4. Conclusion The paper started with proposing an enhanced CoAP for addressing the reliability concern at application layer communication for constrained IoT network. RCoAP is designed by using the existing CoAP message format leveraging the use of CoAP message options and payload to capture communication parameters. The parameters have been identified and explained with the usage. The significance of delay mechanism, priority mechanism, congestion control mechanism and the data compression mechanism with the help of SenML has been explained. All of them have been brought together and implemented for enhancing CoAP capabilities. A central unit with unconstrained capacity in terms of power, memory, processing capabilities has been identified for processing the communication parameters. Then the algorithm and flowchart has been designed for implementing the proposed enhanced CoAP. The paper simulates the RCoAP algorithm using Cooja and Contiki. The results shows that the implemented RCoAP outperforms the CoAP in terms of the identified performance matrices. The hardware/software costs are increased for the central unit, but the central unit could be used for multiple parallel small networks thus allowing the minimizing the central unit cost. There is an increased processing in the nodes but has been well compensated by the RCoAP. As the retransmissions are reduced the effective lost processing of retransmissions are utilized by RCoAP to ensure that the not only performance is better but now CoAP is a reliable protocol for constrained IoT network. Declarations Funding declaration The Authors declare that this research did not receive any specific grant from public, commercial, or not-for-profit funding agencies. Declaration of Conflicting Interest The Authors declare that there is no conflict of interest. They have no known competing financial interests or personal relationships that could have appeared to influence the work reported in this paper. Author Contribution The Author Sharu Bansal has participated in study conception and design, data collection, analysis, and interpretation of results, draft manuscript. All authors reviewed the results and approved the final version of the manuscript. References Shelby, Z., Hartke, K., Bormann, C.: The constrained application protocol (CoAP), (2014). http://www.ietf.org/rfc/rfc7959.txt Tariq, M.A., Khan, M., Raza Khan, M.T., Kim, D.: Enhancements and Challenges in CoAP—A Survey. Sensors , 20 (21), p.6391. (2020) Bansal, S., Kumar, D.: ‘IoT Ecosystem: A Survey on Devices, Gateways, Operating Systems, Middleware and Communication’. Int. J. Wireless Inf. Networks. 27 (3), 340–364 (2020) Gupta, B.B., Quamara, M.: An overview of Internet of Things (IoT): Architectural aspects, challenges, and protocols. Concurrency and Computation: Practice and Experience. 32 (21), e4946 (2020) Pawar, P., Trivedi, A.: Device-to-device communication based IoT system: benefits and challenges. IETE Tech. Rev. 36 (4), 362–374 (2019) Bormann, C., Castellani, A.P., Shelby, Z.: Coap: An application protocol for billions of tiny internet nodes. IEEE Internet Comput. 16 (2), 62–67 (2012) Bansal, S., Kumar, D.: ‘IoT Application Layer Protocols: Performance Analysis and Significance in Smart City’,In 2019 10th International Conference on Computing, Communication and Networking Technologies (ICCCNT), July (pp. 1–6). IEEE. (2019) Roy, A., Acharya, T., DasBit, S.: Quality of service in delay tolerant networks: A survey. Comput. Netw. 130 , 121–133 (2018) Safara, F., Souri, A., Baker, T., Al Ridhawi, I., Aloqaily, M.: PriNergy: A priority-based energy-efficient routing method for IoT systems. The Journal of Supercomputing , pp.1–18. (2020) Betzler, A., Gomez, C., Demirkol, I., Paradells, J.: CoCoA+: An advanced congestion control mechanism for CoAP. Ad Hoc Netw. 33 , 126–139 (2015) Akpakwu, G.A., Hancke, G.P., Abu-Mahfouz, A.M.: ‘CACC: Context‐aware congestion control approach for lightweight CoAP/UDP‐based Internet of Things traffic’. Trans. Emerg. Telecommunications Technol. 31 (2), e3822 (2019) Ferrari, P., Flammini, A., Sisinni, E., Rinaldi, S., Brandão, D., Rocha, M.S.: Delay estimation of industrial IoT applications based on messaging protocols. IEEE Trans. Instrum. Meas. 67 (9), 2188–2199 (2018) Bansal, S., Kumar, D.: Distance-based congestion control mechanism for CoAP in IoT. IET Commun. 14 (19), 3512–3520 (2020) Shelby, Z.: Constrained RESTful environments (CoRE) link format (p. 30). RFC 6690, DOI 10.17487/RFC6690, August 2012,< (2012). https://www . rfc-editor. org/info/rfc6690 Jennings, C., Shelby, Z., Arkko, J., Keranen, A., Bormann, C.: Sensor Measurement Lists (SenML)-RFC 8428. RFC Editor (2018) Bellatreche, L., Leung, C., Xia, Y., El Baz, D.: Advances in cloud and big data computing-Foreward to the special issue. Concurrency and Computation: Practice and Experience. 31 (2), e5053 (2018) Yosuf, B.A., Musa, M., Elgorashi, T., Elmirghani, J.: Energy efficient distributed processing for IoT. IEEE Access. 8 , 161080–161108 (2020) Additional Declarations No competing interests reported. Cite Share Download PDF Status: Posted Version 1 posted You are reading this latest preprint version Research Square lets you share your work early, gain feedback from the community, and start making changes to your manuscript prior to peer review in a journal. As a division of Research Square Company, we’re committed to making research communication faster, fairer, and more useful. We do this by developing innovative software and high quality services for the global research community. Our growing team is made up of researchers and industry professionals working together to solve the most critical problems facing scientific publishing. Also discoverable on Platform About Our Team In Review Editorial Policies Advisory Board Help Center Resources Author Services Accessibility API Access RSS feed Manage Cookie Preferences © Research Square 2026 | ISSN 2693-5015 (online) Privacy Policy Terms of Service Do Not Sell My Personal Information {"props":{"pageProps":{"initialData":{"identity":"rs-1974849","acceptedTermsAndConditions":true,"allowDirectSubmit":true,"archivedVersions":[],"articleType":"Research Article","associatedPublications":[],"authors":[{"id":130326345,"identity":"89ce8d34-9616-452a-8fac-1685757057af","order_by":0,"name":"Sharu Bansal","email":"data:image/png;base64,iVBORw0KGgoAAAANSUhEUgAAAZAAAAAyAQMAAABI0h/eAAAABlBMVEX///8AAABVwtN+AAAACXBIWXMAAA7EAAAOxAGVKw4bAAAA/UlEQVRIiWNgGAWjYBACAzBZwJAAog5IVABJZuYGIrQYgLUwHrA4A9LCSLwW5gOVbSAeAS3m7GcPf/hhUJfHP/uMwYGb82qj+duBWn5UbMOpxbInL02yx+BwscS5HIODM7cdz51xmLGBsefMbdwOO5BjxsBjcCCx4QyPwWHJbcdyG4BamBnb8Gg5/8b44x+DusT5IC1/5xzLnU9Qy40cA2keA+bEDUAtByQbanI3ENJiOeONmbSMweHEjWfYCg5IHDuQuxGo5SA+v5jz5xh/fFNRlzjvDPPmDxI1dbnzzh8++OBHBW4t6OAwmDxAtHogqCNF8SgYBaNgFIwQAACt9mG6QG7vMAAAAABJRU5ErkJggg==","orcid":"","institution":"Sant Longowal Institute of Engineering and Technology","correspondingAuthor":true,"submittingAuthor":false,"prefix":"","firstName":"Sharu","middleName":"","lastName":"Bansal","suffix":""},{"id":130326346,"identity":"eda04d7f-1b91-4248-8fef-6659d5c829e9","order_by":1,"name":"Dilip Kumar","email":"","orcid":"","institution":"Sant Longowal Institute of Engineering and Technology","correspondingAuthor":false,"submittingAuthor":false,"prefix":"","firstName":"Dilip","middleName":"","lastName":"Kumar","suffix":""}],"badges":[],"createdAt":"2022-08-18 12:59:24","currentVersionCode":1,"declarations":"","doi":"10.21203/rs.3.rs-1974849/v1","doiUrl":"https://doi.org/10.21203/rs.3.rs-1974849/v1","draftVersion":[],"editorialEvents":[],"editorialNote":"","failedWorkflow":false,"files":[{"id":25565672,"identity":"69d4c3b6-9aef-4302-a55b-07a925bf6965","added_by":"auto","created_at":"2022-08-23 17:49:26","extension":"png","order_by":1,"title":"Figure 1","display":"","copyAsset":false,"role":"figure","size":11274,"visible":true,"origin":"","legend":"\u003cp\u003eAdditional Parameters\u003c/p\u003e","description":"","filename":"Figure1.png","url":"https://assets-eu.researchsquare.com/files/rs-1974849/v1/59a20c12595ed3d96eed5f39.png"},{"id":25566289,"identity":"52205c7b-493b-418c-b720-600434c2ada1","added_by":"auto","created_at":"2022-08-23 17:54:26","extension":"png","order_by":2,"title":"Figure 2","display":"","copyAsset":false,"role":"figure","size":56916,"visible":true,"origin":"","legend":"\u003cp\u003eFlowchart for client side in RCoAP\u003c/p\u003e","description":"","filename":"Figure2.png","url":"https://assets-eu.researchsquare.com/files/rs-1974849/v1/bfbb11b02b3e61c608e872d1.png"},{"id":25565669,"identity":"92ba00d1-4ef1-42a5-9ebb-594573f47460","added_by":"auto","created_at":"2022-08-23 17:49:26","extension":"png","order_by":3,"title":"Figure 3","display":"","copyAsset":false,"role":"figure","size":63229,"visible":true,"origin":"","legend":"\u003cp\u003eFlowchart for server side in RCoAP \u003c/p\u003e","description":"","filename":"Figure3.png","url":"https://assets-eu.researchsquare.com/files/rs-1974849/v1/40b0143aa8d7801786340fc4.png"},{"id":25566691,"identity":"1ea64c7c-9232-4714-b381-876e25da8a9c","added_by":"auto","created_at":"2022-08-23 17:59:26","extension":"png","order_by":4,"title":"Figure 4","display":"","copyAsset":false,"role":"figure","size":33063,"visible":true,"origin":"","legend":"\u003cp\u003eComparison of CoAP (default) with RCoAP in terms of a) Average latency b) Packet loss c) Retransmissions\u003c/p\u003e","description":"","filename":"Figure4.png","url":"https://assets-eu.researchsquare.com/files/rs-1974849/v1/fb16ce485d35111f044e4913.png"},{"id":25565673,"identity":"66e93f85-9f32-457a-839d-1f6708661da0","added_by":"auto","created_at":"2022-08-23 17:49:26","extension":"png","order_by":5,"title":"Figure 5","display":"","copyAsset":false,"role":"figure","size":23630,"visible":true,"origin":"","legend":"\u003cp\u003eComparison of CoAP (default) with RCoAP in homogeneous and mixed traffic a) Average latency b) Packet loss c) Retransmissions\u003c/p\u003e","description":"","filename":"Figure5.png","url":"https://assets-eu.researchsquare.com/files/rs-1974849/v1/e1f14109872d98a2a9e87777.png"},{"id":27168927,"identity":"d30ff2d0-c8e7-4859-bd9a-9dcf585cfad8","added_by":"auto","created_at":"2022-09-30 05:14:19","extension":"pdf","order_by":0,"title":"","display":"","copyAsset":false,"role":"manuscript-pdf","size":416556,"visible":true,"origin":"","legend":"","description":"","filename":"manuscript.pdf","url":"https://assets-eu.researchsquare.com/files/rs-1974849/v1/6f21b4e8-95a4-4b7c-ab30-c0d160dee88c.pdf"}],"financialInterests":"No competing interests reported.","formattedTitle":"A Reliable CoAP Protocol for IoT Communication","fulltext":[{"header":"1. Introduction","content":"\u003cp\u003eThe CoAP is an application layer web transfer protocol. CoAP is designed for constrained environment considering energy and machine-to-machine (M2M) communication implementations. Request/response interaction model between endpoints is provided by CoAP which also supports in-built mechanism for service/resources discovery. It is a constrained implementation of REST architecture and is based on protocols like HTTP [1]. It supports Web concepts such as URIs and media types etc. It is designed to interface with HTTP via proxy for web integration, multicast support scalability and efficiency which is achieved with low overhead and simplicity [2][3]. Some M2M features provided by are asynchronous messaging, multicast support and built-in discovery. The cost of header and complexity of parsing is low in CoAP. The security binding is via Datagram Transport Layer Security (DTLS) for CoAP-CoAP, HTTP-CoAP proxy communication [4][5].\u003c/p\u003e\n\u003cp\u003eThe client sends a CoAP request for an action on a server-side resource. The response is sent by the server containing response code. CoAP communication is asynchronous over a datagram-oriented transport like UDP [6]. Four types of CoAP defined messages are Confirmable, Non-confirmable, Acknowledgement, Reset. CoAP requests are Confirmable and Non-confirmable and CoAP response can be Acknowledgement along with Confirmable and Non-confirmable [7].\u0026nbsp;\u003c/p\u003e\n\u003cp\u003eIn constrained network, CoAP is a messaging protocol used as a standard for constrained nodes and devices. In the network of constrained devices, nodes or devices are not able to respond well on time due to large delay and congestion. So, there is need of a protocol which works on this problem to give the better performance. In this paper, we introduce RCoAP which gives reliable transmission by using the delay, priority factor and congestion.\u0026nbsp;\u003c/p\u003e\n\u003cp\u003eTo solve the problem of delay there is need to add the delay tolerance factor in the CoAP protocol in both sides\u0026rsquo; client and server. The client or server require the information or data after some time. At that time, they may respond to some other urgent tasks by introducing delay tolerance in the request. Whenever the data is transferred from client/server side, it always gives the information that how much time it can tolerate the delay so that higher priority task gets completed. By receiving the information, server or client schedule their all the task according to the priority. There is also an issue when server/client is too busy to respond any request. At that time, they can go to the sleep mode until its request get responded. By doing this, lot of energy will be saved. It also solves the problem of scheduling of server and client whenever they are busy. In constrained network the probability of packet loss and latencies is high. This leads to untimely delivery of data messages i.e., delayed messages. Moreover, the message should be prioritized. In case message priority is sent along, the combination of delay and priority can be used to control the flow of messages in network. The delay leads to loss of energy, network blockage. CoAP message currently don\u0026rsquo;t support delay and priority in default standards. But the options in CoAP can be used to send delay and priority parameters. This change would promote communication improvement in constrained network. Incorporating delay awareness would help both server and client end by saving energy. When client and servers are aware of delay, they could go to sleep mode.\u0026nbsp;\u003c/p\u003e\n\u003cp\u003eThe network confronts congestion because of an increase in hardware requirements on a small network. Congestion causes delay, packet loss, and collisions in network. Some mechanism to control and avoid congestion is required. Congestion control is essential for smooth operation and timely delivery. The CoAP protocol\u0026apos;s congestion control method is critical. CoAP makes use of UDP, which has no congestion control. Retransmissions are part of the CoAP implementation to help in congestion avoidance. To minimise transmission rates, an exponential back-off method is used between retransmissions. However, collisions might result in multiple retransmissions, which can result in packet loss and\u0026nbsp;congestion issues. The main aim of the work is to introduce a protocol for reliable transmission in terms of delay, priority, and congestion. The novelty and contributions of the paper-\u003c/p\u003e\n\u003col\u003e\n \u003cli\u003eThis paper tries to give a solution for a real-time problem of a reliable CoAP protocol transmission compared to the existing CoAP using node and communication state.\u003c/li\u003e\n \u003cli\u003ePriority and Delay control mechanism, enhanced congestion control mechanism has been brought together to build an enhanced CoAP. Various new CoAP message parameters have been introduced for enhanced CoAP.\u003c/li\u003e\n \u003cli\u003eData compression mechanism has been introduced to mitigate the overhead of increased packet size due to new parameters added to enhanced CoAP messages\u003c/li\u003e\n \u003cli\u003eThe unconstrained central unit has been introduced for processing the information captured by existing and new CoAP parameters and thus reducing the processing overhead at constrained node.\u003c/li\u003e\n \u003cli\u003ePerformance is evaluated by considering two different traffic scenarios\u0026ndash; homogeneous and mixed traffic and three performance metrics are considered by taking different topologies.\u003c/li\u003e\n\u003c/ol\u003e"},{"header":"2.\tRcoap ","content":"\u003cp\u003eCoAP message format comes with set of defined parameters. Some of the significant parameters are source address, destination address, Token ID, Message ID. Along with these parameters Reliable CoAP (RCoAP) define some additional CoAP options and payload for enhancing the reliability of existing CoAP. RCoAP is enhanced CoAP which adds new parameters to CoAP. This protocol works in sync with central unit and defines features like data transfer path, gateway-sensors mapping, time, priority, activation/deactivation of constrained devices and more parameters. The increased size of the CoAP message due to the added parameters has been mitigated by introducing Data compression using SenML language. The output of this protocol results in increased and managed throughput on same bandwidth. The data flow channels would be managed to restrict collisions and void messages. The priority factor would be a considered for ordering the message processing. The delay in the network is regularly observed to control the future messages flow.\u003c/p\u003e\n\u003cp\u003e\u003cem\u003e2.1 Problems statements addressed by RCoAP\u003c/em\u003e\u003c/p\u003e\n\u003cp\u003e1. No Delay indicator \u0026ndash; RCoAP would use CoAP parameters to define a delay flag indicating the presence of delay both at server and client side. Whenever a CoAP message will start, the start timestamp would be added to parameters. Along with the delay flag, the absolute delay time range would also be shared which is relative to start timestamp. Once the message departs then timestamp is captured. All this data will be captured and shared to central unit for saving and analysing the information [8]. The benefit to server and client is as follow\u003c/p\u003e\n\u003cp\u003ea) Client \u0026ndash; Delay message sent from client to Server would indicate that client would be available in the time range specified. It would help server to work on other requests.\u003c/p\u003e\n\u003cp\u003eb) Server \u0026ndash; Delay message from client to server would help server to go into sleep mode while there would be no message coming for a specified range.\u0026nbsp;\u003c/p\u003e\n\u003cp\u003ec) IoT network - When both client and server are aware of the availability of each other, then the messages would be sent accordingly. This would help control the IoT traffic and hence streamline the flow of messages\u003c/p\u003e\n\u003cp\u003ed) Data shared to central unit \u0026ndash; As the data would be shared to central system. So, the central system can analyse and control throughput. It could pass instructions to the servers and clients for due actionable.\u003c/p\u003e\n\u003cp\u003e2. No priority indicator \u0026ndash; There is a big lag in CoAP that CoAP message format don\u0026rsquo;t define priority indicator, RCoAP could define priority indicator as an option. Priority concern comes into play at server end. Based on priority the message could be processed. The priority information would be passed on by a sensor node that central unit will provide [9].\u003c/p\u003e\n\u003cp\u003e3. Retransmission indicator \u0026ndash; According to CoAP standards, there are chances of message remaining undelivered. CoAP reply on acknowledgement for the same and further retransmits message four times [10]. But the message retransmission information is not saved and remains unused. However, this retransmission information can be used for turning CoAP into RCoAP. Server/Client could define options to capture this information. RCoAP uses retransmission indicator to represent the number of retransmissions occurred along the timestamps of retransmission. This represents busy or broken network.\u0026nbsp;\u003c/p\u003e\n\u003cp\u003e4. Update indicator \u0026ndash; CoAP identifies the update based on the Token ID. But for R-CoAP, update indicator represents the update in delay. So, in case of an update in delay message, the update information would be sent along with the original message delivery. This would reduce processing of the nodes.\u003c/p\u003e\n\u003cp\u003e5. Failed message indicator \u0026ndash; Post maximum retransmission, the message is considered as failed. The new message with new token and message ID is sent. \u0026nbsp; But failed information is not saved. But for R-CoAP, the timestamp and retransmissions are captured [11].\u003c/p\u003e\n\u003cp\u003e6. Distance indicator - Distance indicator would contain the distance between the two nodes where the message will travel. Based on the distance the CoAP initial RTO could be calculated to reduce the chances of retransmission.\u003c/p\u003e\n\u003cp\u003eAll the above information is further timely passed on to the central unit\u003c/p\u003e\n\u003cp\u003e\u003cem\u003e2.2 Mechanisms introduced to default CoAP\u003c/em\u003e\u003c/p\u003e\n\u003cp\u003e2.2.1 Delay mechanism\u003c/p\u003e\n\u003cp\u003eIoT applications are a way of connecting things. At real world, IoT applications is more towards enabling connected things with no human presence. This can be ensured by avoid bad situations before it occurs or at the starting stage. Delay mechanism becomes a key factor for ensuring reliability. The new parameters are added to CoAP messages are message send timestamp, Delay flag, Delay time\u003c/p\u003e\n\u003cp\u003eThere are situations in IoT world where delay tolerated message are acceptable but simultaneously there are critical messages where delays are not acceptable. Consider a fire alarm sensor for sensing a spark or a fire. For IoT system the delay should be least. In case water or CO\u003csub\u003e2\u003c/sub\u003e extinguishers are present, the client sends message with no delay the mishappening would be saved. While there are sensers measuring like humidity, temperature for the day, the delay could be tolerated even in case some messages are missed [12]. Following are the key requirements for implementing the delay mechanism\u003c/p\u003e\n\u003cp\u003e\u003cem\u003eRequirement 1 \u0026ndash; Timely arrival of data\u003c/em\u003e. There are scenarios where a miss or delay of data impact the system negligibly whereas for some systems even a small delay can make the situation worse e.g. In one system is maintaining the average humidity, temperature of the day while other system is a fire extinguishing setup.\u003c/p\u003e\n\u003cp\u003e\u003cem\u003eRequirement 2 \u0026ndash; Cost of the operational energy\u003c/em\u003e. The operational cost is dependent on the messages being sent. So, in case node 1 is communicating with node 2 but is unaware that node 2 is corrupted, would cause a lot of f operational energy while the other scenario is the one node is waiting for the response from node 2 where the energy could be saved in sleep mode during the inactive timings.\u003c/p\u003e\n\u003cp\u003e\u003cem\u003eRequirement 3 \u0026ndash; Cancelling the old unnecessary/delayed requests.\u003c/em\u003e The node keeps waiting for the response while the system is aware of the old successful communication between the nodes could cause unnecessary retransmissions. The other scenario is that the server sends where response would not reach within RTO time and the client send retransmission. This results in energy time wastage of server as well as client node. This would create unnecessary messages to travel thus reducing network bandwidth.\u003c/p\u003e\n\u003cp\u003eDelay can be made aware via 3 messages of existing CoAP that are Delay tolerance for Client CON \u0026ndash; DCC, Delay update for Server CON \u0026ndash; DSC, Delay update for Server ACK - DSA\u003c/p\u003e\n\u003col class=\"decimal_type\"\u003e\n \u003cli\u003eDCC - this is a delay parameter sent from client side to update server about the time tolerance that exists for client before message goes invalid. So, client will wait maximum for a particular time. This is very fruitful for client to save energy. The client sleep mode and wake mode can be adjusted, and time is sent accordingly.\u0026nbsp;\u003c/li\u003e\n \u003cli\u003eDSC - This is the delay update shared by server to all the clients to share unavailability or if processing queue is full. Now the possibility is that server needs to go to sleep mode, or server analysed congestion in network or a scenario that server can take only high priority request as the queue to solve requests is full. This message to the client would help not to send more messages on the network thus avoiding the bandwidth to reduce. This will avoid packet loss and delay.\u003c/li\u003e\n \u003cli\u003eDSA - This is delay integrated along with acknowledgement to the client request send by server to client to inform that the response would be delayed by this tenure. In case the server has taken the request, but it won\u0026rsquo;t be able to respond in the time frame shared by client. In this scenario server updates client not to wait for response in the time frame. But also instructs client about the delay after which response will come. This avoids unnecessary retransmissions in the network.\u003c/li\u003e\n\u003c/ol\u003e\n\u003cp\u003e2.2.2. Delay based possible solutions\u003c/p\u003e\n\u003cp\u003e\u003cem\u003eClient-side\u003c/em\u003e - For CON send message, client sends a message to server with max delay wait time and client sends a message to server in case of system fault/battery low with a delay as possible recovery time. For ACK receive message, client receives an acknowledgement regarding the delay in response and receives an acknowledgement regarding the server not able to process with a possible time when client should reconnect. For CON receive message, client receives CON regarding the server fault/battery down so that client can destroy the current message and go sleep and when client receives a message on the update of delay in response from server.\u0026nbsp;\u003c/p\u003e\n\u003cp\u003e\u003cem\u003eServer-side\u003c/em\u003e - For CON receive message, server checks for the delay and accordingly align the message in the processing queue and server sending CON message to the clients to update with the status of unavailability due to low battery/system fault. For ACK send message, server sends an acknowledgement with the possible delay in message due to FULL processing queue. Also, server can send the initial delay in form of acknowledgement to client. For update CON send message, server sends update if the response could not be delivered within the initial mentioned delay time\u003c/p\u003e\n\u003cp\u003e\u003cem\u003e2.2 Priority Mechanism\u003c/em\u003e\u003c/p\u003e\n\u003cp\u003eEach server has a queue. Normally requests are processed in FIFO order. All incoming request is to be processed by the server which is placed in the queue. As per the priority mechanism the request is to be processed based on the request priority. In case a high priority request comes, it should be given precedence. In case a high priority request comes, the server should removes/delay the lowest priority and updates the corresponding client.\u0026nbsp;\u003c/p\u003e\n\u003cp\u003eThe priority is assigned to each sensor node as a node attribute based on the type of sensor. The fire alarm sensor has highest priority set where\u0026rsquo;s the humidity sensor measuring daily humidity of a city is assigned a least priority. The sensor priority is assigned based on the IoT system in which the sensor is installed. The node algorithm picks the device priority parameter and sends it along with the CoAP message. The server reads the message and bases on the priority adds the message to the queue.\u003c/p\u003e\n\u003cp\u003eThe schedular invokes the priority algorithm, passing the request as an input (line 1). The algorithm looks for a slot based on the request priority (line 2). The algorithm examines four priorities (00, 01, 10, 11), with 00 being the highest and 11 being the lowest. This has been updated to include no slots (line 12-17). A function looks for a priority-based slot in the queue (line 19). This algorithm assures that all slots over 95 percent are reserved for priority 00, all slots above 90-95 percent for priority 01, all slots above 85-90 percent for priority 10, and all slots above 80-85 percent for priority 11. To ensure that the highest priority message gets an empty slot, this algorithm will only accept priority 00 requests and ignore priority 01, 10, and 11 requests (line 19-34). When the maximum slots for a priority are full up for 10 and 11, and no lower priority requests can be withdrawn in the case of 00 and 01, the function no slot comes into play. When there\u0026apos;s a chance of getting an empty slot, the future time is calculated, and an acknowledgement is provided to the client notifying them of the rejected action and the new proposed time (line 35-38). If a slot is available, the lower priority request is changed with the current request, and the lower priority client is notified that the request will not be processed, as well as the new possible time for an empty slot. \u0026nbsp;(line 39-46).\u003c/p\u003e\n\u003ctable border=\"1\" cellpadding=\"0\" cellspacing=\"0\"\u003e\n \u003ctbody\u003e\n \u003ctr\u003e\n \u003ctd valign=\"top\" width=\"100%\"\u003e\n \u003cp\u003eAlgorithm I Priority\u003c/p\u003e\n \u003c/td\u003e\n \u003c/tr\u003e\n \u003ctr\u003e\n \u003ctd valign=\"top\" width=\"100%\"\u003e\n \u003cp\u003e1. \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; function Ser_Req_Priority(REQ){\u0026nbsp;\u003c/p\u003e\n \u003cp\u003e2. \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; flag_slot = check_queue_slot(REQ.priority)\u003c/p\u003e\n \u003cp\u003e3. \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; if(priorty = 00 || priorty = 01){\u003c/p\u003e\n \u003cp\u003e4. \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; if(!flag_slot){\u003c/p\u003e\n \u003cp\u003e5. \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; flag_remove = remove_low_priority(priorty)\u003c/p\u003e\n \u003cp\u003e6. \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; if(flag_remove)\u003c/p\u003e\n \u003cp\u003e7. \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp;schedule (REQ)\u003c/p\u003e\n \u003cp\u003e8. \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; else {\u0026nbsp;\u003c/p\u003e\n \u003cp\u003e9. \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp;no_slot(REQ)\u003c/p\u003e\n \u003cp\u003e10. \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp;}\u003c/p\u003e\n \u003cp\u003e11. \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; }\u003c/p\u003e\n \u003cp\u003e12. \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; else if (flag slot){\u003c/p\u003e\n \u003cp\u003e13. \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp;schedule (REQ)\u003c/p\u003e\n \u003cp\u003e14. \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; }\u003c/p\u003e\n \u003cp\u003e15. \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp;else {\u003c/p\u003e\n \u003cp\u003e16. \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp;no_slot(REQ)\u003c/p\u003e\n \u003cp\u003e17. \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; }\u003c/p\u003e\n \u003cp\u003e18. \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp;} \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp;\u0026nbsp;\u003c/p\u003e\n \u003cp\u003e19. \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp;function check_queue_slot (priority) {\u0026nbsp;\u003c/p\u003e\n \u003cp\u003e20. \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp;if (priority == 00) { \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp;\u003c/p\u003e\n \u003cp\u003e21. \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp;flag = slot_95_100_per ()\u003c/p\u003e\n \u003cp\u003e22. \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp;}\u003c/p\u003e\n \u003cp\u003e23. \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp;else if (priority == 01) {\u003c/p\u003e\n \u003cp\u003e24. \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp;flag = slot_90_95_per ()\u003c/p\u003e\n \u003cp\u003e25. \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; }\u003c/p\u003e\n \u003cp\u003e26. \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; else if (priority == 02) {\u003c/p\u003e\n \u003cp\u003e27. \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; flag = slot_85_90_per ()\u003c/p\u003e\n \u003cp\u003e28. \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp;}\u003c/p\u003e\n \u003cp\u003e29. \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; else if (priority == 03){\u003c/p\u003e\n \u003cp\u003e30. \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp;flag = slot_80_85_per () \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp;\u0026nbsp;\u003c/p\u003e\n \u003cp\u003e31. \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp;}\u003c/p\u003e\n \u003cp\u003e32. \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp;else \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp;\u003c/p\u003e\n \u003cp\u003e33. \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; TRUE\u003c/p\u003e\n \u003cp\u003e34. \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp;}\u003c/p\u003e\n \u003cp\u003e35. \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp;no_slot(REQ){\u003c/p\u003e\n \u003cp\u003e36. \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; time = compute_proposed_time(REQ) \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp;\u0026nbsp;\u003c/p\u003e\n \u003cp\u003e37. \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp;ACK_update(ACK, time)\u003c/p\u003e\n \u003cp\u003e38. \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp;}\u003c/p\u003e\n \u003cp\u003e39. \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; remove_low_priority(priorty){\u003c/p\u003e\n \u003cp\u003e40. \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp;REQ = find_low_priority()\u003c/p\u003e\n \u003cp\u003e41. \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; if (REQ.found)\u003c/p\u003e\n \u003cp\u003e42. \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp;ACK_update(ACK, time)\u003c/p\u003e\n \u003cp\u003e43. \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; return true\u003c/p\u003e\n \u003cp\u003e44. \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp;else\u003c/p\u003e\n \u003cp\u003e45. \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; return false;\u003c/p\u003e\n \u003cp\u003e46. \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; }\u003c/p\u003e\n \u003c/td\u003e\n \u003c/tr\u003e\n \u003c/tbody\u003e\n\u003c/table\u003e\n\u003cp\u003e\u0026nbsp;\u003cem\u003e2.3 Congestion mechanism\u003c/em\u003e\u003c/p\u003e\n\u003cp\u003eThe congestion mechanism makes use of the distance between nodes to calculate the retransmission timeout (RTO) value, which helps understand if the two communicating nodes are nearby or distant ones. In basic CoAP, RTO was not dependent on RTT value and later certain solutions came where different RTO values computed considering RTT. However, the paper [13] consider distance between the nodes along with the RTT values for computing RTO. This mechanism would enable to pick nearly optimal value based on the distance ensuring for nearby nodes RTO is small while for distance nodes initial RTO is large.\u003c/p\u003e\n\u003cp\u003eThese calculations would be computed by central unit and the logical programs at node end would use the analysed information before the message is sent. This would ensure the void messages and avoid unnecessary transmissions implementing a congestion mechanism. For enabling the mechanism two important factors are the distance between all the nodes of the network and the second is the RTO computing factor which decides the RTO value based on distance.\u003c/p\u003e\n\u003cp\u003eWhen the number of retransmissions is less than two, Algorithm 2 is used; otherwise, the default technique is used. Strong RTT is calculated using the RTT value (line 2). Node weight (line 4) is determined depending on the levels, and then distance based RTO is calculated (line 5). For computing future RTO, final weighted RTO in terms of RTO, is added to strong RTO (line 6-9).\u003c/p\u003e\n\u003ctable border=\"1\" cellpadding=\"0\" cellspacing=\"0\"\u003e\n \u003ctbody\u003e\n \u003ctr\u003e\n \u003ctd valign=\"top\" width=\"100%\"\u003e\n \u003cp\u003eAlgorithm II RTO Calculation\u003c/p\u003e\n \u003c/td\u003e\n \u003c/tr\u003e\n \u003ctr\u003e\n \u003ctd valign=\"top\" width=\"100%\"\u003e\n \u003cp\u003efunction RTO_DIS (RTT, level, CON)\u003c/p\u003e\n \u003cp\u003e1. \u0026nbsp; RTTstr = RTT\u003c/p\u003e\n \u003cp\u003e2. \u0026nbsp; RTTstr = (1 \u0026minus;\u0026alpha;) RTTstr + \u0026alpha;RTT\u003c/p\u003e\n \u003cp\u003e3. \u0026nbsp; NW = level * k\u003c/p\u003e\n \u003cp\u003e4. \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; RTO\u003csub\u003edistance\u003c/sub\u003e = \u0026delta; * RTTstr\u003c/p\u003e\n \u003cp\u003e5. \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; if (RTO\u003csub\u003edistance\u003c/sub\u003e \u0026lt; RTOdef)\u0026nbsp;\u003c/p\u003e\n \u003cp\u003e6. \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; RTO\u003csub\u003eweight\u0026nbsp;\u003c/sub\u003e= N\u003csub\u003eweight\u003c/sub\u003e * RTO\u003csub\u003edistance\u003c/sub\u003e\u003c/p\u003e\n \u003cp\u003e7. \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; else\u003c/p\u003e\n \u003cp\u003e8. \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; RTO\u003csub\u003eweight\u003c/sub\u003e = N\u003csub\u003eweight\u003c/sub\u003e * (RTO\u003csub\u003edistance\u003c/sub\u003e - RTO\u003csub\u003edef\u003c/sub\u003e)\u003c/p\u003e\n \u003cp\u003e9. \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; RTO = \u0026nbsp;RTTstr + RTO\u003csub\u003eweight\u003c/sub\u003e\u003c/p\u003e\n \u003c/td\u003e\n \u003c/tr\u003e\n \u003c/tbody\u003e\n\u003c/table\u003e\n\u003ch2\u003e2.4 SenML language for data compression\u003c/h2\u003e\n\u003cp\u003eSensor Markup Language (SenML) is a specification defining media types for carrying sensor information in CoAP protocol. It was designed for constrained processors to encode sensor measurements to SenML media type at client side and at server side parses the data efficiently for large number of sensor measurements. Most of the meta data about the nodes are not carried in this media type thus reducing the data size ensuring efficient decoding. The meta-data is published out-of-band using the CoRE Link Format [RFC6690][14]. The data feeds are pushed from a sensor to a collector as a resource representation (e.g., \u0026quot;GET/sensor/temperature\u0026quot;).\u0026nbsp;\u003c/p\u003e\n\u003cp\u003eSenML is defined by a data model and meta-data about measurements and devices. The data is structured as a single array that contains base value object(s) and array(s) of entries. Each entry is an object that has attributes such as a unique identifier for the sensor, the time the measurement was made, and the current value. Serializations for this data model are defined for JSON, CBOR, XML, and Efficient XML Interchange (EXI).\u003c/p\u003e\n\u003cp\u003eFor example, the following shows a measurement from a temperature gauge encoded in the JSON syntax.\u0026nbsp;\u003c/p\u003e\n\u003cp\u003e[{},[\u003c/p\u003e\n\u003cp\u003e\u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; {\u003c/p\u003e\n\u003cp\u003e\u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026ldquo;n\u0026quot;: \u0026quot;urn:dev:ow:10e2073a01080063\u0026quot;,\u003c/p\u003e\n\u003cp\u003e\u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026quot;v\u0026quot;:23.5,\u003c/p\u003e\n\u003cp\u003e\u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026quot;u\u0026quot;:\u0026quot;Cel\u0026quot;\u0026nbsp;\u003c/p\u003e\n\u003cp\u003e\u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; }\u003c/p\u003e\n\u003cp\u003e\u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; ]\u003c/p\u003e\n\u003cp\u003e]\u003c/p\u003e\n\u003cp\u003eIn the example above, the first element of the root array is empty object since there are no base values. The second array inside the root array has a single measurement for a sensor named \u0026quot;urn:dev:ow:10e2073a01080063\u0026quot; with a temperature of 23.5 degrees Celsius. The semantics of SenML language represents that each SenML carries a single array representation of set of measurements and/or parameters. The array constitutes one base object of optional attributes and one mandatory array of multiple entries [15].\u003c/p\u003e\n\u003col\u003e\n \u003cli\u003eBase Name(optional): A string prepended to names in entries.\u003c/li\u003e\n \u003cli\u003eBase Time(optional): A time added to time in entries.\u003c/li\u003e\n \u003cli\u003eBase Units(optional): A unit assumed for all entries.\u003c/li\u003e\n \u003cli\u003eVersion(optional defaults to 2): Version of media type format. The measurement/parameter array are mapped to sensor measurement or other parameters viz configuration with at least one entry and is called measurement array. each array entry has multiple attributes(optional/mandatory)\u003c/li\u003e\n \u003cli\u003eName(mandatory if base name not present): Sensor/Parameter name. The global unique identifier for the resource is once added with base name.\u003c/li\u003e\n \u003cli\u003eUnits(Optional): Measurement unit.\u003c/li\u003e\n \u003cli\u003eValue(Mandatory if sum is not present) Value of the entry. Represented with 3 data types, Floating point numbers (\u0026quot;v\u0026quot; is \u0026quot;Value\u0026quot;), Booleans (\u0026quot;bv\u0026quot; is \u0026quot;Boolean Value\u0026quot;) and Strings (\u0026quot;sv\u0026quot; is \u0026quot;String Value\u0026quot;). One is must\u003c/li\u003e\n \u003cli\u003eSum(Optional): Sum of the values over time in seconds.\u003c/li\u003e\n \u003cli\u003eTime(Optional): Recorded time.\u003c/li\u003e\n \u003cli\u003eUpdate Time(Optional): Time interval in seconds to provide reading. Used to detect the failure of sensors/communication.\u003c/li\u003e\n\u003c/ol\u003e\n\u003cp\u003eSenML format features to extend custom attributes in both base/entries of arrays. Reading system should check for the version. Each system should not process object beyond its version limit. E.g. - Name value concatenated with Base Name to get unique sensor identifier. URI also identifies the name of the resource of request. Uniqueness needs to be guaranteed uniqueness. Similarly other attributes are computed. The missing attribute default value is zero. A negative value indicates action in past.\u003c/p\u003e\n\u003cp\u003eSenML can carry the minimum dynamic information about measurements and does not carry static meta-data for devices for efficient communication but is carried out of band like using the CoRE Link Format [RFC6690] via listing and reteriving the resouces list. The sample attributes are title, resource type, interface description, and content-type etc\u003c/p\u003e\n\u003cp\u003eJSON Representation (application/senml+json)\u003c/p\u003e\n\u003cp\u003e\u0026nbsp;Base object variables:\u003c/p\u003e\n\u003cp\u003e\u0026nbsp;+------------+------+--------+\u003c/p\u003e\n\u003cp\u003e\u0026nbsp;| SenML | JSON | Type |\u003c/p\u003e\n\u003cp\u003e\u0026nbsp;+------------+------+--------+\u003c/p\u003e\n\u003cp\u003e\u0026nbsp;| Base Name | bn | String |\u003c/p\u003e\n\u003cp\u003e\u0026nbsp;| Base Time | bt | Number |\u003c/p\u003e\n\u003cp\u003e\u0026nbsp;| Base Units | bu | Number |\u003c/p\u003e\n\u003cp\u003e\u0026nbsp;| Version | ver | Number |\u003c/p\u003e\n\u003cp\u003e\u0026nbsp;+------------+------+--------+\u003c/p\u003e\n\u003cp\u003e\u0026nbsp;Measurement or Parameter Entries:\u003c/p\u003e\n\u003cp\u003e\u0026nbsp;+---------------+------+----------------+\u003c/p\u003e\n\u003cp\u003e\u0026nbsp;| SenML | JSON | Notes |\u003c/p\u003e\n\u003cp\u003e\u0026nbsp;+---------------+------+----------------+\u003c/p\u003e\n\u003cp\u003e\u0026nbsp;| Name | n | String |\u003c/p\u003e\n\u003cp\u003e\u0026nbsp;| Units | u | String |\u003c/p\u003e\n\u003cp\u003e\u0026nbsp;| Value | v | Floating point |\u003c/p\u003e\n\u003cp\u003e\u0026nbsp;| String Value | sv | String |\u003c/p\u003e\n\u003cp\u003e\u0026nbsp;| Boolean Value | bv | Boolean |\u003c/p\u003e\n\u003cp\u003e\u0026nbsp;| Value Sum | s | Floating point |\u003c/p\u003e\n\u003cp\u003e\u0026nbsp;| Time | t | Number |\u003c/p\u003e\n\u003cp\u003e\u0026nbsp;| Update Time | ut | Number |\u003c/p\u003e\n\u003cp\u003e\u0026nbsp;+---------------+------+----------------+\u003c/p\u003e\n\u003cp\u003e\u003cem\u003e2.5\u0026nbsp;\u003c/em\u003e\u003cem\u003eRole of Central Unit\u003c/em\u003e\u003c/p\u003e\n\u003cp\u003eCentral Unit is analytical and logical part of IoT system where large programs have been designed by the programmers. This system has no constraint in terms of storage, power, and computational capability [16]. Few of the analysis that are performed in central system with consideration of R-CoAP are as follows based on thousands and lakhs of messages flow-\u003c/p\u003e\n\u003cp\u003e1. \u0026nbsp;Identification of the frequency of messages from client/server\u003c/p\u003e\n\u003cp\u003e2. \u0026nbsp;Identification of the duration at which each device is most occupied\u003c/p\u003e\n\u003cp\u003e3. \u0026nbsp;Identification of the priority messages route and most active duration\u003c/p\u003e\n\u003cp\u003e4. \u0026nbsp;Identification of busy route along with timestamps\u003c/p\u003e\n\u003cp\u003e5. \u0026nbsp;Identification of busy or broken network. This analysis is based on the message failure and retransmissions.\u003c/p\u003e\n\u003cp\u003e6. \u0026nbsp;Identification of best path to avoid network issue due to high message flow.\u003c/p\u003e\n\u003cp\u003e7. \u0026nbsp; Computing the initial ideal RTO based of the distance between the nodes.\u003c/p\u003e\n\u003cp\u003eAll the information is captured and saved in central DB. Multiple programs run on them to find out a high-level graphical pattern of the network.\u003c/p\u003e\n\u003cp\u003e2.5.1 Central Unit analysed information usage\u003c/p\u003e\n\u003cp\u003eA table of final observations formed is timely passed on to the devices using SenML. This information gets updated regularly on network defined algorithm. This information is very brief, so that constrained devices can capture and use while transmission. A logical program is installed on all nodes. Whenever a constrained device (client/server) needs to send any CoAP message, the logical program runs. The Analytical information from Central unit is used by this program to add R-CoAP parameters to the CoAP message before sending [17]. Some of the key benefits are-\u003c/p\u003e\n\u003col\u003e\n \u003cli\u003eThere are also chances the during a certain duration of day a device is highly occupied and sending more messages would increase device overhead which may lead to device break. So, the messages can be streamlined and send based on priority. Some of the messages of very low importance can be avoided in network and sent when retransmission rate is very low.\u003c/li\u003e\n \u003cli\u003eIn case of high retransmission only high priority messages would flow in network.\u003c/li\u003e\n \u003cli\u003eThe devices could sleep and become active based on the analytical assumption.\u003c/li\u003e\n \u003cli\u003eCentral system can control the flow of messages wherein energy consumed is high and network outcome is negligible.\u003c/li\u003e\n \u003cli\u003eThe activation and deactivation of devices can be controlled so that the frequency and packet flow is proportional to bandwidth and inversely proportional to latency and packet loss.\u003c/li\u003e\n \u003cli\u003eBest route is defined according to the message flow and avoid collisions and network failure.\u003c/li\u003e\n\u003c/ol\u003e\n\u003cp\u003e\u0026nbsp;\u003cem\u003e2.6 Additional parameters and their requirement in RCoAP\u003c/em\u003e\u003c/p\u003e\n\u003col\u003e\n \u003cli\u003eFirst requirement is to sub classify the CoAP messages. For this MSG_SUB_TYPE is added. CoAP provides CON, ACK, NON, RST. But RCoAP algorithms need a detailed message type to differentiate the activity and message source client/server. These are SER_CON, SER_ACK, CLI_CON, CLI_ACK, SER_UPD, CLI_UPD, UPD_OLD.\u003c/li\u003e\n \u003cli\u003eSecond requirement is to capture Retransmission observations. Parameters for this are CRT(Count Retransmission), RT1, RT2, RT3 and RT4 (Retransmission TIMEstamp) CRT is to tell the count of retransmission but RTX defines the proper time stamp of retransmission. Also, RCoAP requires to capture FAILED_STATUS in case all retransmissions are unsuccessful. This would help identify congested network.\u003c/li\u003e\n \u003cli\u003eThird requirement is to indicate the delay. This delay can be either for client or server. So, the parameters are DELAY_IND, DELAY_TIME_START_RANGE, DELAY_TIME_STOP_RANGE. DELAY_IND is to tell if delay needs to be processed and remaining parameters have time in milli seconds\u003c/li\u003e\n \u003cli\u003eFourth requirement is to capture the actual time stamp of the message which is identified by parameter MESSAGE_TIMESTAMP.\u003c/li\u003e\n \u003cli\u003eFifth requirement is to keep the status of updates. This can be used by server/client to update on existing values rather than a complete processing of the message again. Parameters are UPDATE_IND and UPDATE_TIMESTAMP\u003c/li\u003e\n \u003cli\u003eSixth and one of the most important features of RCoAP for reliability is to define priority of the message on a scale of 1-4 as an option. This will allow high priority messages to be processed earlier.\u003c/li\u003e\n \u003cli\u003eSeventh requirement is to hold the distance (DIS) between the client node and the server node for CoAP RTO calculation to avoid retransmission and network congestion.\u003c/li\u003e\n \u003cli\u003eIn last the RCoAP message is appended with device ID of each while data travels in multi-hop system to keep track of path.\u003c/li\u003e\n\u003c/ol\u003e\n\u003cp\u003eAs part of RCoAP, there would be timely message delivered to the devices from the central unit of IoT system after processing the parameters in RCoAP. As IoT is a constrained network, this data will flow as CoAP payload after a predefined interval. Each device information will flow in the form of an object as a CoAP payload and to reduce the bandwidth overhead that would be caused due to the additional parameters, data compression mechanism is introduced using the SenML langauage.\u003c/p\u003e\n\u003cp\u003e2.7 Algorithms and Flowchart for RCoAP\u003c/p\u003e\n\u003cp\u003e2.7.1 Client side - RCoAP program handles all incoming and outgoing messages. Whether it is an incoming message or an outgoing message, the message must undergo certain steps. CoAP message flows in with certain attributes like Token ID, message ID, Source/Destination nodes etc. There are sub programs which are called in an order. The first program called is \u0026quot;PRO_ANALYSE_INPUT\u0026quot; which analyses the message and decides on incoming/outgoing message. So, in case if it is an incoming message, it furthers checks about the type of incoming message and accordingly call the program to analyse the message. Based on the message indicator as new or update the PRO_SERVER_NEW_MESSAGE_ANALYSER or PRO_SERVER_UPDATE_MESSAGE_ANALYSER is called to capture the parameters in the message for central unit analysis.\u003c/p\u003e\n\u003ctable border=\"1\" cellpadding=\"0\" cellspacing=\"0\"\u003e\n \u003ctbody\u003e\n \u003ctr\u003e\n \u003ctd valign=\"top\" width=\"100%\"\u003e\n \u003cp\u003eAlgorithm III Client Side\u003c/p\u003e\n \u003c/td\u003e\n \u003c/tr\u003e\n \u003ctr\u003e\n \u003ctd valign=\"top\" width=\"100%\"\u003e\n \u003cp\u003eInput : CoAP Message with parameters like message type, Token ID, Message ID, source and destination servers\u003c/p\u003e\n \u003cp\u003eOutput : Parameterized DTO for Data storing and processing and flowing\u003c/p\u003e\n \u003cp\u003eCoAP_Delay_Handler_START(Input, Output)\u003c/p\u003e\n \u003cp\u003e1 \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp;PRO_ANALYSE_INPUT(Input, Output)\u003c/p\u003e\n \u003cp\u003e2 \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp;if(MSG_FLOW := IN)\u003c/p\u003e\n \u003cp\u003e3 \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp;IF(RESPONSE_TYPE := NEW)\u003c/p\u003e\n \u003cp\u003e4 \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp;PRO_SERVER_NEW_MESSAGE_ANALYSER(Input, Output)\u003c/p\u003e\n \u003cp\u003e5 \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp;ELSE(RESPONSE_TYPE := UPDATE)\u003c/p\u003e\n \u003cp\u003e6 \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp;PRO_SERVER_UPDATE_MESSAGE_ANALYSER(Input, Output)\u003c/p\u003e\n \u003cp\u003e7 \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp;else if(MSG_FLOW := OUT)\u003c/p\u003e\n \u003cp\u003e8 \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp;IF((MESSGAE := UPDATE_ON_OLD)\u003c/p\u003e\n \u003cp\u003e9 \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp;PRO_ADD_UPD_PARAMS(Input, Output)\u003c/p\u003e\n \u003cp\u003e10 \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; ELSE\u003c/p\u003e\n \u003cp\u003e11 \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; PRO_ADD_NEW_PARAMS(Input, Output)\u003c/p\u003e\n \u003cp\u003e12 \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; PRO_SET_PRIORITY(Input, Output)\u003c/p\u003e\n \u003cp\u003e13 \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; WHILE(RETRANSMISSION\u0026lt;=3)\u003c/p\u003e\n \u003cp\u003e14 \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; PRO_DELAY_UPDATE(Input, Output)\u003c/p\u003e\n \u003cp\u003e15 \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; SEND_MESSAGE\u003c/p\u003e\n \u003cp\u003e16 \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; IF(ACK_RECEIVED)\u003c/p\u003e\n \u003cp\u003e17 \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; BREAK;\u003c/p\u003e\n \u003cp\u003e18 \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; ELSE\u003c/p\u003e\n \u003cp\u003e19 \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; PRO_UPDATE_RE_TRANS_PARAMS(Input, Output)\u003c/p\u003e\n \u003cp\u003e20 \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; IF(RETRANSMISSION = 4)\u003c/p\u003e\n \u003cp\u003e21 \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; PRO_UPDATE_FAILED_PARAMS(Input, Output)\u003c/p\u003e\n \u003cp\u003e22 \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; BREAK TO STOP;\u003c/p\u003e\n \u003cp\u003e23 \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; PRO_ACK_FROM_SERVER(Input, Output)\u003c/p\u003e\n \u003cp\u003e24 \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; PRO_STORE_INFO_FOR_ANALYTICS(Input, Output)\u003c/p\u003e\n \u003cp\u003e25 \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; PRO_ACK_TO_CLIENT(Input, Output)\u003c/p\u003e\n \u003cp\u003e26 \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; PRO_CLIENT_ACTION(Input, Output)\u003c/p\u003e\n \u003cp\u003eCoAP_Delay_Handler_STOP\u003c/p\u003e\n \u003c/td\u003e\n \u003c/tr\u003e\n \u003c/tbody\u003e\n\u003c/table\u003e\n\u003cp\u003e\u003cbr\u003e\u003c/p\u003e\n\u003ctable border=\"1\" cellpadding=\"0\" cellspacing=\"0\"\u003e\n \u003ctbody\u003e\n \u003ctr\u003e\n \u003ctd valign=\"top\" width=\"100%\"\u003e\n \u003cp\u003eAlgorithm IV Server Side\u003c/p\u003e\n \u003c/td\u003e\n \u003c/tr\u003e\n \u003ctr\u003e\n \u003ctd valign=\"top\" width=\"100%\"\u003e\n \u003cp\u003eInput : CoAP Message with parameters like message type, Token ID, Message ID, source and destination servers\u003c/p\u003e\n \u003cp\u003eOutput : Parameterized DTO for Data storing and processing and flowing\u003c/p\u003e\n \u003cp\u003eCoAP_Delay_Handler_START(Input, Output)\u003c/p\u003e\n \u003cp\u003e1 \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp;PRO_ANALYSE_INPUT(Input, Output)\u003c/p\u003e\n \u003cp\u003e2 \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp;if(MSG_FLOW := IN)\u003c/p\u003e\n \u003cp\u003e3 \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp;IF(RESPONSE_TYPE := NEW)\u003c/p\u003e\n \u003cp\u003e4 \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp;PRO_PRIORITY_ANALYSER(Input, Output)\u003c/p\u003e\n \u003cp\u003e5 \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp;PRO_CLIENT_MESSAGE_ANALYSER(Input, Output)\u003c/p\u003e\n \u003cp\u003e6 \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp;ELSE(RESPONSE_TYPE := UN_ACK)\u003c/p\u003e\n \u003cp\u003e7 \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp;PRO_ACK_FROM_CLIENT(Input, Output)\u003c/p\u003e\n \u003cp\u003e8 \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp;else if(MSG_FLOW := OUT)\u003c/p\u003e\n \u003cp\u003e9 \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp;IF(REQUEST_TYPE := SEND_SERVER_AVAILBILITY)\u003c/p\u003e\n \u003cp\u003e10 \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; PRO_ADD_AVIAL_PARAMS(Input, Output)\u003c/p\u003e\n \u003cp\u003e11 \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; ELSE\u003c/p\u003e\n \u003cp\u003e12 \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; IF((MESSGAE := UPDATE_ON_OLD)\u003c/p\u003e\n \u003cp\u003e13 \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; PRO_ADD_UPD_PARAMS(Input, Output)\u003c/p\u003e\n \u003cp\u003e14 \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; ELSE\u003c/p\u003e\n \u003cp\u003e15 \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; PRO_ADD_NEW_PARAMS(Input, Output)\u003c/p\u003e\n \u003cp\u003e16 \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; WHILE(RETRANSMISSION\u0026lt;=3)\u003c/p\u003e\n \u003cp\u003e17 \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; PRO_DELAY_UPDATE(Input, Output)\u003c/p\u003e\n \u003cp\u003e18 \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; SEND_MESSAGE\u003c/p\u003e\n \u003cp\u003e19 \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; IF(ACK_RECEIVED)\u003c/p\u003e\n \u003cp\u003e20 \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; BREAK;\u003c/p\u003e\n \u003cp\u003e21 \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; ELSE\u003c/p\u003e\n \u003cp\u003e22 \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; PRO_UPDATE_RE_TRANS_PARAMS(Input, Output)\u003c/p\u003e\n \u003cp\u003e23 \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp;\u0026nbsp;\u003c/p\u003e\n \u003cp\u003e24 \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; IF(RETRANSMISSION = 4)\u003c/p\u003e\n \u003cp\u003e25 \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; PRO_UPDATE_FAILED_PARAMS(Input, Output)\u003c/p\u003e\n \u003cp\u003e26 \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; BREAK TO STOP;\u003c/p\u003e\n \u003cp\u003e27 \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; PRO_ACK_FROM_CLIENT(Input, Output)\u003c/p\u003e\n \u003cp\u003e28 \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; PRO_ACK_TO_CLIENT(Input, Output)\u003c/p\u003e\n \u003cp\u003e29 \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; PRO_STORE_INFO_FOR_ANALYTICS(Input, Output)\u003c/p\u003e\n \u003cp\u003e30 \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; PRO_SERVER_ACTION(Input, Output)\u003c/p\u003e\n \u003cp\u003eCoAP_Delay_Handler_STOP\u003c/p\u003e\n \u003cp\u003e\u0026nbsp;\u003c/p\u003e\n \u003c/td\u003e\n \u003c/tr\u003e\n \u003c/tbody\u003e\n\u003c/table\u003e\n\u003cp\u003e\u0026nbsp;Similarly, if the message is coming from client node, the program checks if the node is sending an update with respect to an already sent message or it is a new communication. For update message PRO_ADD_UPD_PARAMS program runs to add parameters and for new PRO_ADD_NEW_PARAMS program executes to add parameters. Once parameters with respect to the type of message are added then PRO_SET_PRIORITY sets priority based on node priority. Once the transmission sends triggers, it checks for three more retransmissions and accordingly call PRO_DELAY_UPDATE program to keep updating delay parameters analysed from previous network transmissions. If acknowledgement is received, the transmission is completed else it tries for three more times and keep capturing and updating retransmission parameters using program PRO_UPDATE_RE_TRANS_PARAMS. If transmission fails four times, then PRO_UPDATE_FAILED_PARAMS program captures failure related to full data so that data is analysed and next time the retransmission parameters are accordingly set to avoid failure. Once an acknowledgement is received PRO_ACK_FROM_SERVER program captures data related to the transmission. PRO_STORE_INFO_FOR_ANALYTICS programs capture all data of transmissions, and this data is analysed by the central unit for upcoming transmissions. PRO_ACK_TO_CLIENT programs look for the acknowledgement received related from server end and based on which PRO_CLIENT_ACTION ensures to act on clients like sleep in case response time is huge to save energy.\u003c/p\u003e\n\u003cp\u003e\u0026nbsp;2.7.2 Server side- RCoAP program handles all incoming and outgoing messages in the similar way. Based on incoming/outgoing message, the message undergoes predefined steps. The CoAP messages have attributes like Token ID, message ID, Source/Destination nodes etc are stored in Parameterized DTO for message processing. The first program \u0026quot;PRO_ANALYSE_INPUT\u0026quot; is called to analyse the message and decide if the message is incoming/outgoing. For incoming message, it checks for message type and call the appropriate program for message analysis. For new message the program PRO_PRIORITY_ANALYSER is called to analyse message priority and then PRO_CLIENT_MESSAGE_ANALYSER program analyses client message. In case of an acknowledgement PRO_ACK_FROM_CLIENT the acknowledgement from client is managed. Similarly for out messages from server, the program checks if the message is on the server availability, PRO_ADD_AVIAL_PARAMS is called. Program PRO_ADD_UPD_PARAMS is called in case of the update on an existing request while PRO_ADD_NEW_PARAMS program is called for the new request. The program respectively updates the parameters based on the message type. Once the message triggers, three more retransmissions are done in case of acknowledgement not received. In case of retransmission PRO_DELAY_UPDATE program executes to update delay parameters analysed from previous network transmissions. If acknowledgement is received the transmission is considered completed else, it tries for three more times and keep capturing and updating retransmission parameters using program PRO_UPDATE_RE_TRANS_PARAMS. If transmission fails four times, then PRO_UPDATE_FAILED_PARAMS program captures failure related to full data so that data is analysed and next time the retransmission parameters are accordingly set to avoid failure. Once an acknowledgement is received PRO_ACK_FROM_CLIEN program captures data related to the transmission. PRO_STORE_INFO_FOR_ANALYTICS programs capture all data of transmissions, and this data is analysed by the central unit for upcoming transmissions. PRO_ACK_TO_CLIENT programs send an acknowledgement to the client about the message received an processing status. PRO_SERVER_ACTION takes server-side actions according to the parameters received and processed.\u003c/p\u003e"},{"header":"3. Performance Evaluation Of Rcoap","content":"\u003cp\u003eBased on the routing protocol (RPL) one border router, one server node, and numerous client nodes make up the RCoAP network model. All the nodes are distributed over a 100 m * 100 m space. The following are the assumptions made during the simulation, and the results are assessed using a variety of metrics. All three types of nodes are static: border router, server, and client. At regular intervals, the server nodes receive messages from the client side. Real-world nodes behave similarly to virtual nodes that have been analysed using the Contiki and Cooja simulators.\u003c/p\u003e \u003cp\u003eTABLE I. Specification of Wismote\u003c/p\u003e \u003cp\u003e \u003cdiv class=\"gridtable\"\u003e\u003ctable float=\"No\" id=\"Tabe\" border=\"1\"\u003e \u003ccolgroup cols=\"2\"\u003e \u003cdiv align=\"left\" class=\"colspec\" colname=\"c1\" colnum=\"1\"\u003e\u003c/div\u003e \u003cdiv align=\"left\" class=\"colspec\" colname=\"c2\" colnum=\"2\"\u003e\u003c/div\u003e \u003cthead\u003e \u003ctr\u003e \u003cth align=\"left\" colname=\"c1\"\u003e \u003cp\u003eSpecifications\u003c/p\u003e \u003c/th\u003e \u003cth align=\"left\" colname=\"c2\"\u003e \u003cp\u003eWismote\u003c/p\u003e \u003c/th\u003e \u003c/tr\u003e \u003c/thead\u003e \u003ctbody\u003e \u003ctr\u003e \u003ctd align=\"left\" colname=\"c1\"\u003e \u003cp\u003eClock Speed\u003c/p\u003e \u003c/td\u003e \u003ctd align=\"left\" colname=\"c2\"\u003e \u003cp\u003e8 MHz\u003c/p\u003e \u003c/td\u003e \u003c/tr\u003e \u003ctr\u003e \u003ctd align=\"left\" colname=\"c1\"\u003e \u003cp\u003eArchitecture\u003c/p\u003e \u003c/td\u003e \u003ctd align=\"left\" colname=\"c2\"\u003e \u003cp\u003eRISC\u003c/p\u003e \u003c/td\u003e \u003c/tr\u003e \u003ctr\u003e \u003ctd align=\"left\" colname=\"c1\"\u003e \u003cp\u003eMCU Device\u003c/p\u003e \u003c/td\u003e \u003ctd align=\"left\" colname=\"c2\"\u003e \u003cp\u003eTI MSP430F5437\u003c/p\u003e \u003c/td\u003e \u003c/tr\u003e \u003ctr\u003e \u003ctd align=\"left\" colname=\"c1\"\u003e \u003cp\u003eRAM\u003c/p\u003e \u003c/td\u003e \u003ctd align=\"left\" colname=\"c2\"\u003e \u003cp\u003e16 KB\u003c/p\u003e \u003c/td\u003e \u003c/tr\u003e \u003ctr\u003e \u003ctd align=\"left\" colname=\"c1\"\u003e \u003cp\u003eROM\u003c/p\u003e \u003c/td\u003e \u003ctd align=\"left\" colname=\"c2\"\u003e \u003cp\u003e256 KB\u003c/p\u003e \u003c/td\u003e \u003c/tr\u003e \u003c/tbody\u003e \u003c/colgroup\u003e \u003c/table\u003e\u003c/div\u003e \u003c/p\u003e \u003cp\u003eBy simulating Contiki and Cooja, this section shows how the RCoAP protocol's algorithms are implemented. Contiki is an open-source operating system, while Cooja is an open-source simulator. Sensor nodes that operate as server and client can be configured in the Cooja simulator, and this virtual hardware can be set as real-world nodes with real-time processing abilities and process parameters. The simulation script is described within the Cooja\u003c/p\u003e \u003cp\u003einterface to record the performance of the simulation setup. The sensor nodes' code file for the simulation has been compiled and uploaded. The Contiki implementation, like IEEE 802.15.4, uses the default network stack, which includes physical and MAC layers as well as RPL as the routing layer. The Wismote nodes are utilized as virtual nodes in performance evaluation. The specification of Wismote is shown in Table\u0026nbsp;1. In the implementation of the enhanced protocol, the options described in the CoAP message format are used for status changes. The RPL border router relays CoAP communications.\u003c/p\u003e \u003cp\u003eTABLE II. Simulation Parameters\u003c/p\u003e \u003cp\u003e \u003cdiv class=\"gridtable\"\u003e\u003ctable float=\"No\" id=\"Tabf\" border=\"1\"\u003e \u003ccolgroup cols=\"2\"\u003e \u003cdiv align=\"left\" class=\"colspec\" colname=\"c1\" colnum=\"1\"\u003e\u003c/div\u003e \u003cdiv align=\"left\" class=\"colspec\" colname=\"c2\" colnum=\"2\"\u003e\u003c/div\u003e \u003cthead\u003e \u003ctr\u003e \u003cth align=\"left\" colspan=\"2\" nameend=\"c2\" namest=\"c1\"\u003e \u003cp\u003eSpecifications\u003c/p\u003e \u003c/th\u003e \u003c/tr\u003e \u003c/thead\u003e \u003ctbody\u003e \u003ctr\u003e \u003ctd align=\"left\" colname=\"c1\"\u003e \u003cp\u003eOperating System\u003c/p\u003e \u003c/td\u003e \u003ctd align=\"left\" colname=\"c2\"\u003e \u003cp\u003eUbuntu 12.04 LTS 64bit, Vmware Player 12.5.6, Instant Contiki-3.0\u003c/p\u003e \u003c/td\u003e \u003c/tr\u003e \u003ctr\u003e \u003ctd align=\"left\" colname=\"c1\"\u003e \u003cp\u003eLanguage\u003c/p\u003e \u003c/td\u003e \u003ctd align=\"left\" colname=\"c2\"\u003e \u003cp\u003eC\u003c/p\u003e \u003c/td\u003e \u003c/tr\u003e \u003ctr\u003e \u003ctd align=\"left\" colname=\"c1\"\u003e \u003cp\u003ePhysical Layer\u003c/p\u003e \u003c/td\u003e \u003ctd align=\"left\" colname=\"c2\"\u003e \u003cp\u003eIEEE 802.15.4\u003c/p\u003e \u003c/td\u003e \u003c/tr\u003e \u003ctr\u003e \u003ctd align=\"left\" colname=\"c1\"\u003e \u003cp\u003eRouting Protocol\u003c/p\u003e \u003c/td\u003e \u003ctd align=\"left\" colname=\"c2\"\u003e \u003cp\u003eRPL\u003c/p\u003e \u003c/td\u003e \u003c/tr\u003e \u003ctr\u003e \u003ctd align=\"left\" colname=\"c1\"\u003e \u003cp\u003eNumber of Nodes\u003c/p\u003e \u003c/td\u003e \u003ctd align=\"left\" colname=\"c2\"\u003e \u003cp\u003e49 (Z1 and Wismote)\u003c/p\u003e \u003c/td\u003e \u003c/tr\u003e \u003ctr\u003e \u003ctd align=\"left\" colname=\"c1\"\u003e \u003cp\u003eTransmission Range\u003c/p\u003e \u003c/td\u003e \u003ctd align=\"left\" colname=\"c2\"\u003e \u003cp\u003e50m\u003c/p\u003e \u003c/td\u003e \u003c/tr\u003e \u003ctr\u003e \u003ctd align=\"left\" colname=\"c1\"\u003e \u003cp\u003eArea\u003c/p\u003e \u003c/td\u003e \u003ctd align=\"left\" colname=\"c2\"\u003e \u003cp\u003e100m * 100m\u003c/p\u003e \u003c/td\u003e \u003c/tr\u003e \u003ctr\u003e \u003ctd align=\"left\" colname=\"c1\"\u003e \u003cp\u003eRadio medium\u003c/p\u003e \u003c/td\u003e \u003ctd align=\"left\" colname=\"c2\"\u003e \u003cp\u003eUnit Disk Graph Medium (UDGM)\u003c/p\u003e \u003c/td\u003e \u003c/tr\u003e \u003ctr\u003e \u003ctd align=\"left\" colname=\"c1\"\u003e \u003cp\u003eTraffic Type\u003c/p\u003e \u003c/td\u003e \u003ctd align=\"left\" colname=\"c2\"\u003e \u003cp\u003eHomogenous and Mixed\u003c/p\u003e \u003c/td\u003e \u003c/tr\u003e \u003c/tbody\u003e \u003c/colgroup\u003e \u003c/table\u003e\u003c/div\u003e \u003c/p\u003e \u003cp\u003eThe border router is responsible of message routing. Once the RPL network is fully operational, client nodes begin sending CoAP messages on a regular basis. This duration value is changed during the simulation to specify the rate at which messages flow. These messages are transmitted to the sink node, which is the server node.\u003c/p\u003e \u003cp\u003eTo connect to the external network, the IPv6 for Low-Power and Lossy Networks is utilised as a border router in this design. Table II shows the simulation parameters and their relative values utilised in our simulation design. The radio medium specification indicates that the simulation uses a propagation loss model with distance loss to make it more realistic.\u003c/p\u003e \u003cdiv id=\"Sec13\" class=\"Section2\"\u003e \u003ch2\u003e3.1 Performance Metrices and Traffic Type\u003c/h2\u003e \u003cp\u003eThree measures average latency, packet loss and retransmission are taken to measure the RCoAP network performance. These will help to evaluate the performance of default CoAP with RCoAP by using four types of topologies, two traffic types. On the application layer, the average latency is the time that a CoAP packet takes to travel from the source to the destination node. Packet loss is the number of packets for which the interaction was unexpectedly terminated, and the node-to-node message is lost. The number of packets retransmitted because of RTO. This assures that the number of retransmissions is reduced. The number of retransmissions is related to the amount of congested traffic. Furthermore, the lower retransmissions, the greater the network capacity and, as a result, the better the network performance.\u003c/p\u003e \u003cp\u003eThe main objective of the analysis is to figure out how many received ACK messages there are in each transaction. We analyse two different traffic scenarios homogeneous traffic and mixed traffic. The assumption in homogeneous traffic is that the network contains only reliable CoAP traffic. The transmitting rate for CoAP messages is increased in homogeneous traffic. But in mixed traffic, the network contains both reliable and unreliable traffic. The transfer rate of CoAP reliable traffic remains constant. But the main aim of analysis of mixed traffic is to see how increasing non-reliable traffic affects the reliability of CoAP traffic.\u003c/p\u003e \u003cp\u003e \u003c/p\u003e \u003cp\u003e \u003c/p\u003e \u003c/div\u003e \u003cdiv id=\"Sec14\" class=\"Section2\"\u003e \u003ch2\u003e3.2 Topologies\u003c/h2\u003e \u003cp\u003eThe setup can be implemented by using various static topologies. Throughout the simulation, the nodes have fixed locations and no movement. Grid, dumbbell, flower, and chain topologies are all considered. Grid topologies are used in smart grid, industrial automation, and building automation applications that need long range and large area coverage. Here, we are considered both 6m * 6m grid and 7m * 7m grid. They are designed in such a way that there is always a node within each node's transmission range. The data packets are routed through several nodes before being delivered to the server to separate the network range from the transmission range of each node. The dumbbell topology can be used to calculate the retransmissions to check the congestion in the network. Here we use 21 nodes in which border router is present at centre and all other nodes are there in shape of dumbbell. In chain topology, we consider total 20 nodes are present in straight line. This topology gives less congestion as compared to other topologies. Flower topology is used in satellite network and wide area network. As the name suggests, total 36 nodes which are arranged in form of petal.\u003c/p\u003e \u003cp\u003eThe result shows that the RCoAP improves the overall network's performance. When compared to default CoAP, RCoAP reduces average latency by 25%, and packet loss by 35%, and retransmission by 40%, resulting in improved network performance. CoAP networks with mixed traffic performance is slightly lower than a homogeneous network due to containing of void messages, but the performance metrics are much better than default CoAP. Average latency reduces by 20%, packet loss reduces by 10%, and retransmission reduce by 5% in mixed traffic, when compared to homogeneous traffic, however mixed traffic performance still improves significantly when compared to default-CoAP.\u003c/p\u003e \u003cp\u003eTABLE III. Comparison of Topologies in terms of performance metrices\u003c/p\u003e \u003cp\u003e \u003cdiv class=\"gridtable\"\u003e\u003ctable float=\"No\" id=\"Tabg\" border=\"1\"\u003e \u003ccolgroup cols=\"7\"\u003e \u003cdiv align=\"left\" class=\"colspec\" colname=\"c1\" colnum=\"1\"\u003e\u003c/div\u003e \u003cdiv align=\"left\" class=\"colspec\" colname=\"c2\" colnum=\"2\"\u003e\u003c/div\u003e \u003cdiv align=\"left\" class=\"colspec\" colname=\"c3\" colnum=\"3\"\u003e\u003c/div\u003e \u003cdiv align=\"left\" class=\"colspec\" colname=\"c4\" colnum=\"4\"\u003e\u003c/div\u003e \u003cdiv align=\"left\" class=\"colspec\" colname=\"c5\" colnum=\"5\"\u003e\u003c/div\u003e \u003cdiv align=\"left\" class=\"colspec\" colname=\"c6\" colnum=\"6\"\u003e\u003c/div\u003e \u003cdiv align=\"left\" class=\"colspec\" colname=\"c7\" colnum=\"7\"\u003e\u003c/div\u003e \u003cthead\u003e \u003ctr\u003e \u003cth align=\"left\" colname=\"c1\"\u003e \u003cp\u003eTopologies\u003c/p\u003e \u003c/th\u003e \u003cth align=\"left\" colspan=\"2\" nameend=\"c3\" namest=\"c2\"\u003e \u003cp\u003eAverage Latency (s)\u003c/p\u003e \u003c/th\u003e \u003cth align=\"left\" colspan=\"2\" nameend=\"c5\" namest=\"c4\"\u003e \u003cp\u003ePacket Loss\u003c/p\u003e \u003c/th\u003e \u003cth align=\"left\" colspan=\"2\" nameend=\"c7\" namest=\"c6\"\u003e \u003cp\u003eRetransmissions\u003c/p\u003e \u003c/th\u003e \u003c/tr\u003e \u003c/thead\u003e \u003ctbody\u003e \u003ctr\u003e \u003ctd align=\"left\" colname=\"c1\"\u003e\u0026nbsp;\u003c/td\u003e \u003ctd align=\"left\" colname=\"c2\"\u003e \u003cp\u003eCoAP\u003c/p\u003e \u003cp\u003e(Default)\u003c/p\u003e \u003c/td\u003e \u003ctd align=\"left\" colname=\"c3\"\u003e \u003cp\u003eRCoAP\u003c/p\u003e \u003c/td\u003e \u003ctd align=\"left\" colname=\"c4\"\u003e \u003cp\u003eCoAP\u003c/p\u003e \u003cp\u003e(Default)\u003c/p\u003e \u003c/td\u003e \u003ctd align=\"left\" colname=\"c5\"\u003e \u003cp\u003eRCoAP\u003c/p\u003e \u003c/td\u003e \u003ctd align=\"left\" colname=\"c6\"\u003e \u003cp\u003eCoAP\u003c/p\u003e \u003cp\u003e(Default)\u003c/p\u003e \u003c/td\u003e \u003ctd align=\"left\" colname=\"c7\"\u003e \u003cp\u003eRCoAP\u003c/p\u003e \u003c/td\u003e \u003c/tr\u003e \u003ctr\u003e \u003ctd align=\"left\" colname=\"c1\"\u003e \u003cp\u003eGrid (6m *6m)\u003c/p\u003e \u003c/td\u003e \u003ctd align=\"left\" colname=\"c2\"\u003e \u003cp\u003e1.734\u003c/p\u003e \u003c/td\u003e \u003ctd align=\"left\" colname=\"c3\"\u003e \u003cp\u003e1.612\u003c/p\u003e \u003c/td\u003e \u003ctd align=\"left\" colname=\"c4\"\u003e \u003cp\u003e52\u003c/p\u003e \u003c/td\u003e \u003ctd align=\"left\" colname=\"c5\"\u003e \u003cp\u003e35\u003c/p\u003e \u003c/td\u003e \u003ctd align=\"left\" colname=\"c6\"\u003e \u003cp\u003e255\u003c/p\u003e \u003c/td\u003e \u003ctd align=\"left\" colname=\"c7\"\u003e \u003cp\u003e102\u003c/p\u003e \u003c/td\u003e \u003c/tr\u003e \u003ctr\u003e \u003ctd align=\"left\" colname=\"c1\"\u003e \u003cp\u003eGrid (7m *7m)\u003c/p\u003e \u003c/td\u003e \u003ctd align=\"left\" colname=\"c2\"\u003e \u003cp\u003e2.823\u003c/p\u003e \u003c/td\u003e \u003ctd align=\"left\" colname=\"c3\"\u003e \u003cp\u003e2.223\u003c/p\u003e \u003c/td\u003e \u003ctd align=\"left\" colname=\"c4\"\u003e \u003cp\u003e49\u003c/p\u003e \u003c/td\u003e \u003ctd align=\"left\" colname=\"c5\"\u003e \u003cp\u003e32\u003c/p\u003e \u003c/td\u003e \u003ctd align=\"left\" colname=\"c6\"\u003e \u003cp\u003e262\u003c/p\u003e \u003c/td\u003e \u003ctd align=\"left\" colname=\"c7\"\u003e \u003cp\u003e105\u003c/p\u003e \u003c/td\u003e \u003c/tr\u003e \u003ctr\u003e \u003ctd align=\"left\" colname=\"c1\"\u003e \u003cp\u003eDumbbell\u003c/p\u003e \u003c/td\u003e \u003ctd align=\"left\" colname=\"c2\"\u003e \u003cp\u003e0.089\u003c/p\u003e \u003c/td\u003e \u003ctd align=\"left\" colname=\"c3\"\u003e \u003cp\u003e0.083\u003c/p\u003e \u003c/td\u003e \u003ctd align=\"left\" colname=\"c4\"\u003e \u003cp\u003e30\u003c/p\u003e \u003c/td\u003e \u003ctd align=\"left\" colname=\"c5\"\u003e \u003cp\u003e21\u003c/p\u003e \u003c/td\u003e \u003ctd align=\"left\" colname=\"c6\"\u003e \u003cp\u003e172\u003c/p\u003e \u003c/td\u003e \u003ctd align=\"left\" colname=\"c7\"\u003e \u003cp\u003e85\u003c/p\u003e \u003c/td\u003e \u003c/tr\u003e \u003ctr\u003e \u003ctd align=\"left\" colname=\"c1\"\u003e \u003cp\u003eFlower\u003c/p\u003e \u003c/td\u003e \u003ctd align=\"left\" colname=\"c2\"\u003e \u003cp\u003e1.523\u003c/p\u003e \u003c/td\u003e \u003ctd align=\"left\" colname=\"c3\"\u003e \u003cp\u003e1.499\u003c/p\u003e \u003c/td\u003e \u003ctd align=\"left\" colname=\"c4\"\u003e \u003cp\u003e33\u003c/p\u003e \u003c/td\u003e \u003ctd align=\"left\" colname=\"c5\"\u003e \u003cp\u003e24\u003c/p\u003e \u003c/td\u003e \u003ctd align=\"left\" colname=\"c6\"\u003e \u003cp\u003e180\u003c/p\u003e \u003c/td\u003e \u003ctd align=\"left\" colname=\"c7\"\u003e \u003cp\u003e94\u003c/p\u003e \u003c/td\u003e \u003c/tr\u003e \u003ctr\u003e \u003ctd align=\"left\" colname=\"c1\"\u003e \u003cp\u003eChain\u003c/p\u003e \u003c/td\u003e \u003ctd align=\"left\" colname=\"c2\"\u003e \u003cp\u003e0.523\u003c/p\u003e \u003c/td\u003e \u003ctd align=\"left\" colname=\"c3\"\u003e \u003cp\u003e0.478\u003c/p\u003e \u003c/td\u003e \u003ctd align=\"left\" colname=\"c4\"\u003e \u003cp\u003e46\u003c/p\u003e \u003c/td\u003e \u003ctd align=\"left\" colname=\"c5\"\u003e \u003cp\u003e33\u003c/p\u003e \u003c/td\u003e \u003ctd align=\"left\" colname=\"c6\"\u003e \u003cp\u003e235\u003c/p\u003e \u003c/td\u003e \u003ctd align=\"left\" colname=\"c7\"\u003e \u003cp\u003e98\u003c/p\u003e \u003c/td\u003e \u003c/tr\u003e \u003c/tbody\u003e \u003c/colgroup\u003e \u003c/table\u003e\u003c/div\u003e \u003c/p\u003e \u003c/div\u003e"},{"header":"4. Conclusion","content":"\u003cp\u003eThe paper started with proposing an enhanced CoAP for addressing the reliability concern at application layer communication for constrained IoT network. RCoAP is designed by using the existing CoAP message format leveraging the use of CoAP message options and payload to capture communication parameters. The parameters have been identified and explained with the usage. The significance of delay mechanism, priority mechanism, congestion control mechanism and the data compression mechanism with the help of SenML has been explained. All of them have been brought together and implemented for enhancing CoAP capabilities. A central unit with unconstrained capacity in terms of power, memory, processing capabilities has been identified for processing the communication parameters. Then the algorithm and flowchart has been designed for implementing the proposed enhanced CoAP. The paper simulates the RCoAP algorithm using Cooja and Contiki. The results shows that the implemented RCoAP outperforms the CoAP in terms of the identified performance matrices. The hardware/software costs are increased for the central unit, but the central unit could be used for multiple parallel small networks thus allowing the minimizing the central unit cost. There is an increased processing in the nodes but has been well compensated by the RCoAP. As the retransmissions are reduced the effective lost processing of retransmissions are utilized by RCoAP to ensure that the not only performance is better but now CoAP is a reliable protocol for constrained IoT network.\u003c/p\u003e\n"},{"header":"Declarations","content":"\u003cp\u003eFunding declaration\u003c/p\u003e\n\u003cp\u003eThe Authors declare that this research did not receive any specific grant from public, commercial, or not-for-profit funding agencies.\u0026nbsp;\u003c/p\u003e\n\u003cp\u003eDeclaration of Conflicting Interest\u003c/p\u003e\n\u003cp\u003eThe Authors declare that there is no conflict of interest. They have no known competing financial interests or personal relationships that could have appeared to influence the work reported in this paper.\u003c/p\u003e\n\u003cp\u003eAuthor Contribution\u003c/p\u003e\n\u003cp\u003eThe Author Sharu Bansal has participated in study conception and design, data collection, analysis, and interpretation of results, draft manuscript. All authors reviewed the results and approved the final version of the manuscript.\u003c/p\u003e"},{"header":"References","content":"\u003col\u003e\n \u003cli\u003e\u003cspan\u003eShelby, Z., Hartke, K., Bormann, C.: The constrained application protocol (CoAP), (2014). \u003cspan class=\"ExternalRef\"\u003e\u003cspan class=\"RefSource\"\u003ehttp://www.ietf.org/rfc/rfc7959.txt\u003c/span\u003e\u003c/span\u003e\u003c/span\u003e\u003c/li\u003e\n \u003cli\u003e\u003cspan\u003eTariq, M.A., Khan, M., Raza Khan, M.T., Kim, D.: Enhancements and Challenges in CoAP\u0026mdash;A Survey. \u003cem\u003eSensors\u003c/em\u003e, \u003cem\u003e20\u003c/em\u003e(21), p.6391. (2020)\u003c/span\u003e\u003c/li\u003e\n \u003cli\u003e\u003cspan\u003eBansal, S., Kumar, D.: \u0026lsquo;IoT Ecosystem: A Survey on Devices, Gateways, Operating Systems, Middleware and Communication\u0026rsquo;. Int. J. Wireless Inf. Networks. \u003cstrong\u003e27\u003c/strong\u003e(3), 340\u0026ndash;364 (2020)\u003c/span\u003e\u003c/li\u003e\n \u003cli\u003e\u003cspan\u003eGupta, B.B., Quamara, M.: An overview of Internet of Things (IoT): Architectural aspects, challenges, and protocols. Concurrency and Computation: Practice and Experience. \u003cstrong\u003e32\u003c/strong\u003e(21), e4946 (2020)\u003c/span\u003e\u003c/li\u003e\n \u003cli\u003e\u003cspan\u003ePawar, P., Trivedi, A.: Device-to-device communication based IoT system: benefits and challenges. IETE Tech. Rev. \u003cstrong\u003e36\u003c/strong\u003e(4), 362\u0026ndash;374 (2019)\u003c/span\u003e\u003c/li\u003e\n \u003cli\u003e\u003cspan\u003eBormann, C., Castellani, A.P., Shelby, Z.: Coap: An application protocol for billions of tiny internet nodes. IEEE Internet Comput. \u003cstrong\u003e16\u003c/strong\u003e(2), 62\u0026ndash;67 (2012)\u003c/span\u003e\u003c/li\u003e\n \u003cli\u003e\u003cspan\u003eBansal, S., Kumar, D.: \u0026lsquo;IoT Application Layer Protocols: Performance Analysis and Significance in Smart City\u0026rsquo;,In 2019 10th International Conference on Computing, Communication and Networking Technologies (ICCCNT), July (pp.\u0026nbsp;1\u0026ndash;6). IEEE. (2019)\u003c/span\u003e\u003c/li\u003e\n \u003cli\u003e\u003cspan\u003eRoy, A., Acharya, T., DasBit, S.: Quality of service in delay tolerant networks: A survey. Comput. Netw. \u003cstrong\u003e130\u003c/strong\u003e, 121\u0026ndash;133 (2018)\u003c/span\u003e\u003c/li\u003e\n \u003cli\u003e\u003cspan\u003eSafara, F., Souri, A., Baker, T., Al Ridhawi, I., Aloqaily, M.: PriNergy: A priority-based energy-efficient routing method for IoT systems.\u003cem\u003eThe Journal of Supercomputing\u003c/em\u003e, pp.1\u0026ndash;18. (2020)\u003c/span\u003e\u003c/li\u003e\n \u003cli\u003e\u003cspan\u003eBetzler, A., Gomez, C., Demirkol, I., Paradells, J.: CoCoA+: An advanced congestion control mechanism for CoAP. Ad Hoc Netw. \u003cstrong\u003e33\u003c/strong\u003e, 126\u0026ndash;139 (2015)\u003c/span\u003e\u003c/li\u003e\n \u003cli\u003e\u003cspan\u003eAkpakwu, G.A., Hancke, G.P., Abu-Mahfouz, A.M.: \u0026lsquo;CACC: Context‐aware congestion control approach for lightweight CoAP/UDP‐based Internet of Things traffic\u0026rsquo;. Trans. Emerg. Telecommunications Technol. \u003cstrong\u003e31\u003c/strong\u003e(2), e3822 (2019)\u003c/span\u003e\u003c/li\u003e\n \u003cli\u003e\u003cspan\u003eFerrari, P., Flammini, A., Sisinni, E., Rinaldi, S., Brand\u0026atilde;o, D., Rocha, M.S.: Delay estimation of industrial IoT applications based on messaging protocols. IEEE Trans. Instrum. Meas. \u003cstrong\u003e67\u003c/strong\u003e(9), 2188\u0026ndash;2199 (2018)\u003c/span\u003e\u003c/li\u003e\n \u003cli\u003e\u003cspan\u003eBansal, S., Kumar, D.: Distance-based congestion control mechanism for CoAP in IoT. IET Commun. \u003cstrong\u003e14\u003c/strong\u003e(19), 3512\u0026ndash;3520 (2020)\u003c/span\u003e\u003c/li\u003e\n \u003cli\u003e\u003cspan\u003eShelby, Z.: \u003cem\u003eConstrained RESTful environments (CoRE) link format\u003c/em\u003e (p.\u0026nbsp;30). RFC 6690, DOI 10.17487/RFC6690, August 2012,\u0026lt; (2012). \u003cspan class=\"ExternalRef\"\u003e\u003cspan class=\"RefSource\"\u003ehttps://www\u003c/span\u003e\u003c/span\u003e. rfc-editor. org/info/rfc6690\u003c/span\u003e\u003c/li\u003e\n \u003cli\u003e\u003cspan\u003eJennings, C., Shelby, Z., Arkko, J., Keranen, A., Bormann, C.: Sensor Measurement Lists (SenML)-RFC 8428. RFC Editor (2018)\u003c/span\u003e\u003c/li\u003e\n \u003cli\u003e\u003cspan\u003eBellatreche, L., Leung, C., Xia, Y., El Baz, D.: Advances in cloud and big data computing-Foreward to the special issue. Concurrency and Computation: Practice and Experience. \u003cstrong\u003e31\u003c/strong\u003e(2), e5053 (2018)\u003c/span\u003e\u003c/li\u003e\n \u003cli\u003e\u003cspan\u003eYosuf, B.A., Musa, M., Elgorashi, T., Elmirghani, J.: Energy efficient distributed processing for IoT. IEEE Access. \u003cstrong\u003e8\u003c/strong\u003e, 161080\u0026ndash;161108 (2020)\u003c/span\u003e\u003c/li\u003e\n\u003c/ol\u003e"}],"fulltextSource":"","fullText":"","funders":[],"hasAdminPriorityOnWorkflow":false,"hasManuscriptDocX":true,"hasOptedInToPreprint":true,"hasPassedJournalQc":"","hasAnyPriority":false,"hideJournal":true,"highlight":"","institution":"","isAcceptedByJournal":false,"isAuthorSuppliedPdf":false,"isDeskRejected":"","isHiddenFromSearch":false,"isInQc":false,"isInWorkflow":false,"isPdf":false,"isPdfUpToDate":true,"isWithdrawnOrRetracted":false,"journal":{"display":true,"email":"[email protected]","identity":"researchsquare","isNatureJournal":false,"hasQc":true,"allowDirectSubmit":true,"externalIdentity":"","sideBox":"","snPcode":"","submissionUrl":"/submission","title":"Research Square","twitterHandle":"researchsquare","acdcEnabled":true,"dfaEnabled":false,"editorialSystem":"","reportingPortfolio":"","inReviewEnabled":false,"inReviewRevisionsEnabled":true},"keywords":"CoAP, IoT, Delay, Congestion, Priority ","lastPublishedDoi":"10.21203/rs.3.rs-1974849/v1","lastPublishedDoiUrl":"https://doi.org/10.21203/rs.3.rs-1974849/v1","license":{"name":"CC BY 4.0","url":"https://creativecommons.org/licenses/by/4.0/"},"manuscriptAbstract":"\u003cp\u003eThe request-response model for constrained devices is achieved via RESTful architecture of Constrained Application Protocol (CoAP) in IoT. An enhanced CoAP is proposed to address the limitations of CoAP to achieve an efficient IoT network. Unlike existing protocols that operate on instantaneous Round-Trip Time (RTT) in IoT, it also makes use of CoAP options, payload, and node distance for defining the network state in a better way. Various new parameters viz. timestamps, priority, message path, device status is introduced and CoAP payload is defined using SenML representation of data. The processing unit at the network level is used for data analysis of the integrated parameters that are timely communicated to this unit from the network nodes. The algorithm with varying data rates is used in homogeneous and mixed traffic to calculate the performance. The significant improvement in terms of delay, priority, congestion, retransmissions ensure reliable communication in the network.\u003c/p\u003e","manuscriptTitle":"A Reliable CoAP Protocol for IoT Communication","msid":"","msnumber":"","nonDraftVersions":[{"code":1,"date":"2022-08-23 17:49:24","doi":"10.21203/rs.3.rs-1974849/v1","editorialEvents":[{"type":"communityComments","content":0}],"status":"published","journal":{"display":true,"email":"[email protected]","identity":"researchsquare","isNatureJournal":false,"hasQc":true,"allowDirectSubmit":true,"externalIdentity":"","sideBox":"","snPcode":"","submissionUrl":"/submission","title":"Research Square","twitterHandle":"researchsquare","acdcEnabled":true,"dfaEnabled":false,"editorialSystem":"","reportingPortfolio":"","inReviewEnabled":false,"inReviewRevisionsEnabled":true}}],"origin":"","ownerIdentity":"f56cee22-b437-4357-bd3e-20f35d21d9ba","owner":[],"postedDate":"August 23rd, 2022","published":true,"recentEditorialEvents":[],"rejectedJournal":[],"revision":"","amendment":"","status":"posted","subjectAreas":[],"tags":[],"updatedAt":"2022-09-30T05:14:09+00:00","versionOfRecord":[],"versionCreatedAt":"2022-08-23 17:49:24","video":"","vorDoi":"","vorDoiUrl":"","workflowStages":[]},"version":"v1","identity":"rs-1974849","journalConfig":"researchsquare"},"__N_SSP":true},"page":"/article/[identity]/[[...version]]","query":{"redirect":"/article/rs-1974849","identity":"rs-1974849","version":["v1"]},"buildId":"cBFmMYwuxLRRLfASyISRj","isFallback":false,"isExperimentalCompile":false,"dynamicIds":[84888],"gssp":true,"scriptLoader":[]}