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 CO2 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. RTOdistance = δ * RTTstr
5. if (RTOdistance < RTOdef)
6. RTOweight = Nweight * RTOdistance
7. else
8. RTOweight = Nweight * (RTOdistance - RTOdef)
9. RTO = RTTstr + RTOweight
|
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.