# Efficient Actor Recovery Paradigm for Wireless Sensor and Actor Networks
## 3 Related Work  
In this section, the salient features of relevant related approaches are discussed. WSANs are difficult to deploy, even though WSANs are known to improve the overall network performance. One shortcoming of WSANs is that these networks adversely are affected by inadequate positioning, power restraints, and routing limitations. To avoid these issues, the sensor and actor nodes should be deployed randomly or at fixed position based on the application requirements. Actor nodes can either be mobile or static. Hence, the node mobility improves the network performance metrics such as coverage, connectivity and lifetime [5]. A number of localization techniques were studied and introduced for WSANs. Some techniques focus on nodes positioning are provided in [6], while some other studies focus on failure node recovery process [7; 8; 9; 10; 11; 12; 13; 14; 15]. WSANs are mainly deployed in harsh areas, and are supposed to support long network lifetime. As we mentioned earlier, actor nodes are very essential nodes in WSAN. Thus, it is essential for WSAN algorithms to support not only actor node deployment and actor mobility, but they should be robust enough to provide failure detection and self-healing network recovery. Some works presented in the literature manage to handle the actor node deployment and mobility [16; 17; 18; 19; 20; 21; 22; 23]. Nevertheless, they do not provide solutions in the case of the occurrence of actor node failure. The study in [20] presents a framework for real-time data report and task execution (RTRE) which aims to achieve event assignment through multi-actor coordination and data collected coordination between sensor and actors real-time sensor-actuator data collection. The authors of [23] present a self-organizing mobility control in WSANs based on virtual electrostatic interactions which aim to enhance actor node deployment and control actors' mobility. The main purpose of the previously mentioned techniques is to manage actor mobility during deployment or during event handling. Meanwhile, actor mobility features may cause continuous changes to the network topology. Thus, an actor may go outside a specific region range and is then defined as failed. In WSANs, actor failure can be due to their limited power, mobility, or topology changes. The mobility feature can cause actors to go outside the communication range. Moreover, network topology may be affected by such behavior. Effective topology management techniques should be implemented. Several proposed mechanisms where introduced in order to manage network failure concerning topology management [11; 13; 24; 25; 26; 27; 28; 29; 30; 31; 32]. Fault detection mechanisms are classified into proactive and reactive methods. In proactive methods, fault and restoration mechanisms are addressed during the network setup. Some mechanisms implement fault tolerance topologies in the network setup while others use redundant and backup nodes to ensure fault tolerance [33]. On the other hand, a reactive scheme pursues to utilize the network resources and performs recovery through node repositioning. Reactive schemes require network monitoring in order to maintain node status. Network status, recovery algorithms, and recovery scope are important factors in reactive schemes. Reactive recovery algorithms are classified into centralized algorithms or distributed algorithm and have been widely used in the literature [26; 29; 30; 32; 33; 34; 35; 36; 37; 38]. Scope of recovery refers to how many nodes are involved in the recovery. Some mechanisms require a single node [35; 36] while others identify a block of nodes for the recovery process [10; 39]. Moreover, actor fault impact can vary depending on the node's importance and type. Some fault management detection and recovery procedures classify the actor nodes into critical nodes and non-critical nodes [10; 24; 37]. A critical node refers to a node which failure causes network partitioning. Most algorithms define the critical nodes using 2-hop message exchange information [8; 36].