## 5 The Proposed Protocol
### Communication Overhead of the Proposed Protocol
#### 5.6.2 Optimized Data Fusion in Devices/Links Failures and Recovery
More specifically, local repair is the act of resolving problems or failures that are restricted to a small portion of the network, usually impacting a single DFG or a small number of SNs. The primary benefit of the local repair is its promptness; it may be carried out quickly, reducing the network's exposure to the breakdown. Another benefit is reduced overhead since only a small portion of the network is affected by the local repairs, which lowers communication and computational overhead. The following situations call for local repair, along with the techniques needed to recover them:  
* For a NDFGM: According to our proposed approach, DFGMs communicate with their PDFHs, FSDFHs, and SSDFHs on a regular basis regarding their health check messages. When a DFGM fails to transmit a data message during TS, or when PDFH receives information about abnormal parameters from DFGM via the health status information added to its data message, PDFH will provide a new, updated TDMA schedule that will undoubtedly omit the failing DFGM. * For a PDFH: The proposed protocol requires that a PDFH includes its health status information in its data message, which it then delivers to both its FSDFH, SSDFH, and the sink node. As was previously indicated, both FSDFH and SSDFH stay in active mode and keep an eye on the data messages that PDFH sends to the sink node. When at least (1.15 \(\times\) RT) of the anticipated time to receive data from PDFH passes without any transmission, or when abnormal parameters, particularly internal transmit/receive circuits, are detected by FSDFH in the PDFH health status information, then FSDFH assumes the role of PDFH, aggregates the received data, and transmits it to the sink node. On the other hand, SSDFH does the same tasks if FSDFH fails. Specifically, if (1.3 \(\times\) RT) of the anticipated time to receive data from PDFH or FSDFH passes without any transmission from PDFH or FSDFH, SSDFH takes the role of PDFH. The reasons behind this are attributed to the elimination of the use of global repair. * For an FSDFH or SSDFH: According to our proposed protocol, FSDFH and SSDFH regularly transmit their health status information to the sink node separately while appending it to their data message, which is subsequently transmitted to their PDFH. FSDFH or SSDFH will be deleted from the sink node table message and will not be used for any further network operations if the sink node finds aberrant parameters in this message. However, regrouping will still occur in the next batch, so this is not an urgent scenario. Global repair, in contrast to local repair, is the process of identifying and resolving problems or failures that impact a greater percentage of the network or the network as a whole. Global repair is advantageous because it allows for a thorough recovery by resolving broad problems, which guarantees the network's overall health and performance in addition to effective resource utilization and the avoidance of future failures. Within the proposed protocol, global repair is a component of the dynamic regrouping process, a crucial recovery mechanism intended to improve the resilience and efficiency of the network. To preserve network integrity, it entails rearranging PDFH, FSDFH, and SSDFH roles inside DFGs as well as reestablishing communication channels (PDFRs, FSDFRs, and SSDFRs). In order to adjust to changes like SN failures, energy depletion, or changes in network architecture, this procedure is essential. To sum up, the core purpose of dynamic regrouping is to keep SNs' energy consumption evenly distributed, which will increase the network's lifespan overall. Furthermore, it minimizes data loss and communication delays by assigning crucial tasks to the most competent SNs. The following situations demand global repair, along with the approaches needed to recover them:  
* If the sink node does not obtain any data from PDFH, FSDFH, SSDFH, and PDFRs after 45% of the anticipated time to receive data messages (i.e., 1.45 \(\times\) RT). In other words, we assign a 15% delay for each role.