**1. Introduction**

Recently, there have been active studies for big data analysis using networking to collect, process, and analyze a large amount of data [1]. In order to not only collect various data but also fast process information, the technologies of collecting and transmitting data have emerged as a very important issue. Here, there is no doubt that the transmission technology among wireless sensors is important for big data technology. Research on various wireless sensor networking technologies to transmit the collected data has been actively conducted for decades [2,3].

A lot of wireless sensors are properly distributed through the observation area to collect the interested data [4,5]. It is not difficult to distribute the sensors to accessible areas to human, however unmanned mobile devices (unmanned air vehicle, drone, etc.) could be used in large inaccessible areas. After deploying the sensors, let us consider that data collection occurs frequently in particular area. There is an inherent problem that a small sensor has limited energy. To remedy this power limitation, wireless charging systems for IoT sensors have been researched actively recently [6]. However, charging system for the sensors is not always available, especially in inaccessible area like rugged terrain. Thus, it is necessary that the sensor relocation protocol to recover sensing hole employs energy e fficient scheme as a preemptive measure. Some sensors may be quickly drained of energy while continuously collecting and transmitting data in the particular area. This case is called a sensor node failure, the communication of the entire network may be disconnected, and the desired data could not be collected in the worst case. The particular area, where a certain number of sensors become faulted and cannot collect the interested data anymore, is called as a sensing hole [7]. In order to prevent a sensing hole occurred, various studies such as schemes of minimizing energy consumption by adjusting the active/idle states and energy e fficient routing protocols have been conducted [8–10]. Although the energy limit of the sensor node can be reduced by various applications, it is impossible to solve the sensor node failure problem completely. Therefore, it is necessary to recover it by moving other sensors to the sensing hole occurred, as the most realistic solution. For this reason, researches on mobile sensors have received a lot of attention. The failure sensors depleted of energy could be replaced by mobile sensors moved from other area. The authors of [11] considered a case that a wheel-based mobile node could temporarily replace the role of a fixed node by moving if a fixed sensor node is failed in the interested area. However, there are limitations in the migration of wheel-based sensors. In other words, energy consumption has to be further considered in order to move, however wheel-based movement is essentially inadequate in very rough areas.

In order to overcome the limitation of wheel-based mobility, a hopping-based moving model is introduced. A hopping-based sensor node is bionically designed to jump itself, like a frog. For example, a mobile unit implemented by DARPA (Defense Advanced Research Projects Agency, USA) is able to do up to 100 jumps with one full fuel injection and jump up to 10 m high [12,13]. The paper [14] by MSU (Michigan State University, USA) describes the performance comparisons for the maximum jump height, jumping distance, and so on for various jumping robots, in detail. Researches on not only the implementation of jump-based mobility but hopping sensor relocation algorithm to recover the sensing holes that occurred, have been actively conducted [15–18]. However, most of studies so far require that every cluster header sensor node has to know all information for the current whole network area and set up routes to supply/reques<sup>t</sup> hopping sensors to recover sensing holes occurred. In fact, no matter how small the observation field to obtain interested data is, the exchange of information and establishment of paths among the cluster header sensors are di fficult in real world, and involve a storm of numerous control messages. Recently, our research team has solved these problems drastically [19]. First of all, every cluster header does not need to know all information of other cluster headers or all networks. It is a distributed networking-based relocation protocol that recovers a sensing hole by simply requesting necessary sensor nodes from neighbor cluster headers. A cluster header node selects appropriate hopping sensors based on information communicated among all sensor nodes in its cluster, and they are moved to the requesting neighbor cluster. Up to now, however, most relocation protocols have assumed that the observation fields, in which mobile sensors are scattered, are ideal environments. In other words, the areas where sensors move are likely to be irregular, under the existence of obstacles like stones or mud. Reference [18] is the first study of hopping sensor relocation based on probabilities of existence of obstacles, however there is a limitation that the assumption that every cluster header sensor grasps all information of rugged terrains in all regions is not very realistic.

In this paper, a novel relocation protocol that considers the probabilities of the level of obstacles using the information of success rate for migration is proposed. Here, it is not necessary for each cluster header sensor node to know all information of entire network; the cluster header only knows the information such as the probabilities between neighbor clusters. In addition, as far as we know, it can be very meaningful to have the first realistic simulation with OMNeT++ [20], similar to the actual environment.

The rest of this paper is organized as follows. Section 2 summarizes the mobility model of hopping sensor and the related relocation protocol. In Section 3, the proposed relocation protocol is explained along with the scenario in detail. The simulation results are analyzed in Section 4, and Section 5 concludes this paper.

#### **2. Previous Work**

#### *2.1. Characteristics and Movement Models of Hopping Sensors*

Typical mobile sensors are based on wheels. This structure has the disadvantage that it is very difficult to move in rough terrain such as gravel, sand, and so on. In order to overcome the mobility problem, hopping sensors that mimic movements such as a grasshopper or a frog have been devised. In addition, the hopping sensor enables communication among sensor nodes in environments where it is difficult for a sensor to communicate each other because the distance between sensor nodes is farther than a normal communication radius of a sensor, or where there are various obstacles which block communication propagation. Up to now, various researchers have shown that the connectivity between hopping sensors could be improved by the jumping of each hopping sensor. The papers [21,22] have shown that the communication radius is increased about six times compared to the one on the ground when a hopping sensor jumps 1 m from the ground. The paper [23] actually implemented a hopping sensor using a separate launcher for jumping and measured the transmission radius varied according to the height of the jump. The changed transmission radii were compared with the results of [21], and it was confirmed that they had similar results.

Compared to a wheel-based sensor node, a hopping sensor, which is moving on jump, might be inherently less accurate to migrate to the desired area. In fact, it would be more desirable to have a positive explanation for enabling movement in an environment that cannot be moved with wheels, rather than a negative idea that movement accuracy is poor. The paper [15] first attempted a performance analysis of how a hopping sensor node was affected by wind when jumping and moving. It is obvious that the movement of hopping model is more vulnerable to air resistance than that of wheel-based model. Mathematical modeling of this hopping movement can be explained as follows.

As shown in Figure 1, the hopping sensor does not land exactly the targeted location (*T*) after jumping, and it is more likely to land near it (i.e., actual landing location; *L*). Let the variables *T* and *L* be vectors of the target and actual landing locations. The error vector *D* with respect to the difference between the locations can be expressed as *L* − *T*. Here, we assume that *D* follows the two-dimensional standard normal distribution with means (0, 0), standard deviations (<sup>σ</sup>*x*, <sup>σ</sup>*y*), and correlation ρ. The probability density function can be defined as

$$f\_{XY} = \frac{1}{2\pi\sigma\_x\sigma\_y\sqrt{1-\rho^2}}e^{-\frac{1}{2}\left(\frac{\mathbf{r}^2}{1-\rho^2}\right)\frac{\mathbf{r}^2}{\sigma\_x^2} + \frac{\mathbf{r}^2}{\sigma\_y^2} - \frac{2\rho\mathbf{r}\mathbf{y}}{\sigma\_x\sigma\_y}}{} \tag{1}$$

Let us consider that the hopping range is 2, standard deviations are 0.3, and the correlation is zero. The movement of the hopping sensor is as shown in Figure 1. The movement of the red circle is an ideal movement, but the movement of the blue circle is a movement that reflects the mentioned constraints. It can be easily seen that the movement of the blue circle more appropriately reflects the movement in rough environment suitable for the hopping sensor than that of the red circle. Therefore, the above error vector of the movement would be preferably applied to the simulation in Section 4.

**Figure 1.** An example of the movement of a hopping sensor considering movement-error.

#### *2.2. Basic Assumptions about Hopping Sensors and Relocation Protocol*

In the traditional research fields of wireless sensor networks (WSNs), there are various methods for clustering and cluster header selection of sensor nodes randomly distributed in the interested areas [24]. In fact, since the purpose of this paper is to study the relocation of hopping sensor nodes, it is assumed that the clustering and selection of the cluster headers have already been completed by various existing methods. For example, hopping sensor nodes are randomly scattered firstly on the interested area in which we want to collect data. After that, the area is divided by an appropriate clustering algorithm, and a cluster header node is selected for each cluster zone. The cluster header periodically communicates with member sensor nodes in its cluster zone, and it manages representative information of each member. Considering the network connectivity problem, communication between each cluster header and all member sensor nodes could jump to send and receive messages with its maximum transmission radius. Moreover, every hopping sensor node contains a GPS unit capable of knowing its current location [25].

The terms used in this paper are explained in Figure 2. Every hopping sensor node can be either a cluster header node or a member sensor node. Since the maximum transmission radius is defined as a cluster zone when the cluster header maximally jumps, there is a high possibility that direct communication between the cluster headers could be impossible. However, some member sensor nodes in the area intersecting with the cluster zones (that is, near the maximum transmission radius of each cluster header) may communicate with two or more cluster headers. This hopping sensor node is called as a relay node, and the role of the node could help to facilitate communication between cluster headers [18].

**Figure 2.** The defined terms for hopping sensor network.

Unlike hopping sensor relocation protocols, which were only theoretically studied, the paper [19] proposed a relocation protocol suitable for a distributed environment so that it could be applied to a real environment. The protocol proposed in the mentioned paper is briefly summarized using an example in Figure 3. If the cluster zone C is a sensing hole, the protocol strategy to recover the problem is as follows.

**Figure 3.** An example of recovering a sensing hole with cross-clusters.

**Step 1**. The cluster header HC sends a REQ message requesting one hopping sensor to the relay node R2.

**Step 2**. The relay node R2 forwards the REQ message received from HC to the cluster header HB of the cluster zone B.

**Step 3**. The cluster header HB sends a MOVE message for moving to neighbor cluster zone C to the hopping sensor M3 selected as a moveable member in its zone B.

**Step 4**. At the same time, the cluster header HB predicts that its zone could also be a sensing hole, and it sends a REQ message for requesting one hopping sensor to relay node R1.

**Step 5**. The relay node R1 forwards the message REQ to its another cluster header HA.

**Step 6**. The cluster header HA chooses M2 among hopping member sensor nodes of its zone A in its zone and commands the movement. As a result, one sensor is properly allocated to each cluster zone, and the sensing zone (cluster zone C) could be recovered.

#### **3. The Proposed Relocation Protocol for Rugged Terrains**

Although the distributed-based relocation protocol [19] has made up for the drawbacks of the previous central-based relocation protocols, questions still remain whether it is suitable for the real world. In fact, it should be noted that the environment in which hopping sensors are deployed would be different from the general terrain. In the relocation protocol [19], topographical information on obstacles around the cluster zones were not taken into account. The movement of hopping sensors fails due to obstacles and the relocation cannot satisfy the movement requested from the cluster header of sensing hole. Thus, the number of messages continuously requested may increase to overcome the persisting sensing hole. This could put a heavy load on the entire network, and it would be very negative in terms of energy. Therefore, we propose a relocation protocol for more realistic hopping sensor networks by indirectly predicting the topographic information around sensing holes.

#### *3.1. Basic Operation of the Proposed Relocation Protocol*

In this section, we propose a novel relocation protocol that takes into account the environment surrounding the sensing hole occurred. Figure 4 shows the message flows between hopping sensors that the types are cluster header, relay node, and member sensor node. The detailed formats of the messages for the proposed relocation protocol and the message flows for each sensor node are described in detail as follows.

**Figure 4.** Scenario and message flow diagram for describing the proposed protocol.

**Step 1**: The cluster header of the cluster zone A periodically broadcasts a HELLO message inside its zone to identify member sensor nodes. If a member node receives HELLO for the first time, the source address of the received HELLO message is memorized as its cluster header.

> HELLO: = {message type, source address, destination address (broadcasting)}

**Step 2**: The member that received the HELLO message responds to the cluster header with a HELLO-ACK message to notify its health. If different HELLO messages are received from several cluster headers in Step 1, the member node is aware of that it has become a relay node for each cluster header. Thus, it also indicates whether a relay node or not, when the HELLO-ACK message is replied.

HELLO-ACK: = {message type, source address, destination address, relay node? (T/F)}

**Step 3**: The cluster header determines whether or not, currently, its zone is a sensing hole using the number of addresses of HELLO messages received. In the case of a sensing hole, the cluster header sends a relay message to all its relay nodes.

> RELAY: = {message type, source address, destination address (multicasting)}

**Step 4**: As soon as the relay nodes receive the RELAY message, they send a RELAY-ACK message back to the cluster header. The cluster header may sequentially receive several RELAY-ACK messages. Among them, the relay node of the RELAY-ACK message, which is first received at the cluster header, is selected and other RELAY-ACK messages are ignored. Also, if a relay node overhears a RELAY-ACK message from another relay node while preparing to send a RELAY-ACK message, it immediately stops sending its message.

> RELAY-ACK: = {message type, source address, destination address}

**Step 5**: So far, the cluster header is able to detect that a sensing hole has occurred (Step 3), and it could choose a relay node to forward a message to the neighbor cluster header for requesting member hopping sensor nodes needed (Step 4). Here, the required number of members is the difference (*T* − *C*) between the threshold value (*T*) to determine the sensing hole and the current number of members

(*C*). However, the environment around the detected sensing hole may be rough terrain in reality, the sensing hole would continue because it might be high probability that the number of relocated hopping sensors is smaller than the requested number (*T* − *C*). Therefore, the cluster header checks the numbers of previously requested members and successfully moved members and calculates the movement success rate (*p* = number of members successfully moved/number of members requested) of the surrounding environment for the current cluster zone. Here, the number of requesting member sensors (*cnt*) that can overcome the sensing hole can be calculated as follows.

$$cnt \colon = \text{Celling}[(T - \mathcal{C}) \* (1 + (1 - p))] \tag{2}$$

The cluster header sends a REQ message to the selected relay node.

REQ: = {message type, source address, destination address, *cnt*, sensing hole address, sensing hole GPS info.}

**Step 6**: When the relay node receives the REQ message from the cluster header of the sensing hole occurred, it forwards the received REQ message to another cluster header. Here, the source and destination addresses of the currently received REQ message are modified to its own address and the address of the another cluster header to be delivered, respectively.

**Step 7**: When the neighbor cluster header of the occurred sensing hole receives the REQ message forwarded, it broadcasts an ADV message to determine movable member hopping sensor nodes among the current members in its zone.

> ADV: = {message type, source address, destination address (broadcasting) }

**Step 8**: Each member node that receives the ADV message sends an ADV-ACK message containing its current physical information to the cluster header.

> ADV-ACK:= {message type, source address, destination address, some info.}

Here, above 'some info.' indicates several type of information for relocation strategy [19], including the current energy state, capability of hopping movement, GPS coordinate information, etc.

**Step 9**: The cluster header receives ACK messages and selects the appropriately movable hopping sensor nodes. Then, it sends MOVE message, which includes the location information about the sensing hole, to the hopping sensors selected.

> ADV: = {message type, source address, destination address (multicasting), sensing hole address, sensing hole GPS info.}

**Step 10**: The member nodes receiving the MOVE message have to hop to the neighbor zone using the GPS information of the cluster header of the sensing hole. Here, as every hopping member is taking into account the usual transmission radius of the neighbor cluster header, it could calculate the coordinates of where to move properly. Thus, each member hopping sensor node no longer moves when the member node has moved as desired location.

**Step 11**: As mentioned in Step 1, the cluster header of the sensing hole broadcasts a HELLO message at periodic times. After a predetermined time, when the relocated member sensor node receives the new HELLO message, the member updates its previous cluster header information as the current one. If the relocated member sensor node receives multiple HELLO messages at this time, it would be changed to a relay node. In addition, each cluster header is able to update the current movement success rate p through the number of HELLO-ACK messages to properly reflect the level of obstacles. All hopping sensors have modules that can perform Steps 1 to 11 independently. Each

module of a hopping sensor could be activated depending on whether it is currently playing a role of {cluster header, relay node, member sensor node}. This is summarized as follows.

$$\text{Cluster header:} = \{ \text{Steps 1, 3, 5, 7, 9, 11} \}$$

$$\text{Relay node:} = \{ \text{Steps 3, 4, 5, 6} \}$$

$$\text{Member sensor node:} = \{ \text{Steps 2, 8, 10} \}$$

#### *3.2. Descriptions of the Proposed Protocol*

So far, most previous studies on hopping sensor relocation are central-based manner which each cluster header know all network information, but this is not a very practical study. The research of [19] only conducted a distributed-based approach to consider the realistic environment, but it still failed to take into account the surrounding obstacle information. That is, it is important to consider the environment using hopping sensors, not using the wheel-based ones. The following examples of simple scenarios in Figure 5 are described to understand the di fference between cases reflected the surrounding obstacle information or not.

(**c**) Sensor M3 is failed to move due to obstacle (**d**) Sensor M4 is also failed to move due to obstacle

**Figure 5.** Examples of comparison between the previous and proposed relocations.

In Figure 5a, we assume that the cluster zone B has to maintain five member sensor nodes, except for the cluster header HB, for data collection. The cluster header determines that the sensing hole occurs when the number of members is smaller than 5. Here, the cluster zone B was a sensing hole due to a lack of one member (i.e., before moving M1). In order to recover the sensing hole, after the cluster header HB of zone B requests one member from zone A (the first REQ), the member sensor node M1 of zone A moves to zone B.

In the first scenario, let us consider the relocation of hopping sensors without taking into account obstacles as mentioned previous literatures. In Figure 5b, two member sensor nodes fail due to energy exhausted in the cluster zone B. The cluster header HB is aware of the state of sensing hole, and it requests two members from the neighbor cluster zone A (the second REQ). Two members, which were ordered to move to the cluster zone B, are moving as shown in Figure 5c. One member M2 is successfully moved to the cluster zone B, while the other M3 is failed to move due to obstacle. The cluster header of the cluster zone B perceives the state of sensing hole again, and it requests one member from the cluster zone A (the third REQ). In Figure 5d, since the selected member M4 fails to move because of unexpected obstacle, the cluster zone B is still a sensing hole. In order to overcome the sensing hole, the cluster header HB requests one member from the cluster zone A repeatedly (the fourth REQ). The member M5 is successfully moved, and the sensing hole is finally recovered.

In the second scenario, let us take into account the relocation based on probabilities of existence of obstacles. In Figure 5b, the cluster header HB should recognize the state of the sensing hole and request some members from the neighbor cluster zone A. First of all, let the initial value of the movement success rate *p* be 1. The success rate *p* is used to calculate the requested number of member sensors. According to Equation (2), the number of the requested members is 2, Ceiling[(5 − 3) ∗ (1 + (1 − 1))], the cluster header HB requests two members from the cluster zone A (the second REQ). In Figure 5c, the cluster header HA commands two members to move to the cluster zone B. As described in the above first scenario, one member M2 moves successfully, but the other member M3 fails to move due to the obstacle. Thus, the cluster header HB updates the value of *p* as 1/2, and it is also aware of the sensing hole. The cluster HB calculates the number of requesting members using Equation (2), Ceiling[(5 − 4) ∗ (1 + (1 − 1/2))], so two members are requested to the cluster HA (the third REQ). One of the two members of A, the member M3 fails to move to the zone B, as in the first previous scenario. However, the other member M2 can successfully move to the zone B to overcome the state of sensing hole.

As we are looking at the mentioned two scenarios, it might be thought that the probability of successful movement represents the state of obstacles between cluster zones. Therefore, it is a good example to see that the use of the above probability could reduce the number of request messages, when the cluster header of sensing hole is requesting members to the neighbor zones. Actually, the number of REQ messages of the first scenario is greater than that of the second scenario.

Message flow charts for the above described two scenarios could be explained easily, as shown in Figure 6. The cluster header HB of the zone B first detects its sensing hole occurred, and it transmits the first REQ message to the cluster header HA of the neighboring zone A, here the REQ includes that the number of member sensor node needed is one (i.e., *cnt* = 1). In fact, a direct communication between the cluster headers is impossible, but for convenience, transmission and reception of their messages with a RELAY node are omitted in the middle. The header HA selects M1 appropriately among its member nodes, and it sends a MOVE message to relocate to the sensing hole, zone B. Member node M1, which received MOVE, was able to recover the sensing hole without any problems for moving.

**Figure 6.** Message flows for two scenarios.

First, the message flows for the first scenario are depicted in Figure 6a. The cluster header of B, HB, detects a sensing hole occurred again, and it sets two members (*cnt* = 2) for recovery in the REQ message, and sends the message (the second REQ) to the neighbor header HA. HA appropriately selects two members (M2, M3) and transmits MOVE message to them to relocate, and the member node M2 of them is moved to the zone B without any problems. However, the other member M3 is not able to move to the zone B due to an unexpected obstacle. After a certain time, the cluster header HB determines that the sensing hole is not recovered. HB transmits a message (the third REQ) to request one member needed to the zone A. H A directly sends MOVE message to the member M4, but M4 unfortunately crashes into an obstacle and fails to recover the sensing hole. After a certain amount of time again, the header HB checks the current status of zone B, and it inserts that the value of *cnt* is 1 (i.e., requires one member) in the requesting message and sends the message (the fourth REQ). The member M5 receiving MOVE from its cluster header H A successfully is moved to the sensing hole zone B without colliding with obstacles.

Next, the message flows for the second scenario are depicted in Figure 6b. The header HB detects a sensing hole occurred again and sends a message to request some hopping sensors. Here, HB appropriately calculates the number of members required using that the movement success rate *p* is one and sets the value of *cnt* to two. H A chooses two members, M2 and M3, to transmit MOVE for relocation, and then M2 is successfully moved to the neighbor zone B. However, another hopping sensor M3 is unable to move because of unexpected obstacles. The cluster header HB determines that the sensing hole is not recovered after broadcasting HELLO message repeatedly. The header of zone B transmits a message (the third REQ) to request some members needed from the header of zone A.

At this time, since the movement success rate for the previous REQ message is *p* = 1/2 (50%), the header of B could request two members calculated by Ceiling[(5 − 4) ∗ (1 + (1 − 1/2))], even though the zone B currently needs one member to recover the sensing hole. That is, HB recognizes that the level of obstacles between cluster zones is high and requests a large number of sensors from H A for rapid recovery. As expected, member M4 collided again with an obstacle, but member M5 successfully moved to neighbor zone B. Since the proposed relocation protocol reduces the number of REQ messages compared with the previous one, it could be verified that our protocol is energy efficient for wireless hopping sensor networks.

#### **4. Simulation Results and Analysis**

Unlike hopping sensor relocation studies so far, one of the most significant contributions this paper is the use of OMNeT++ [26], which can realistically reflect wireless communications situations in real-world environments. Table 1 describes the environment parameters used in the simulation for performance evaluation.


**Table 1.** Simulation environments.

As shown in Figure 7, 285 hopping sensors are randomly scattered to the whole area of 250 m × 150 m to collect data. As mentioned in the previous Sections, since the aim of our research is not clustering techniques, we assume that the 15 cluster zones and headers are properly pre-set up in well-known ways. If there are fewer than 10 member sensor nodes in each cluster zone, excluding the cluster headers, the cluster header determines that its zone is a sensing hole.

(**c**) snapshot (obstacles 2%) (**d**) snapshot (obstacles 3%)

**Figure 7.** Simulation snapshots for each environment.

As shown in Figure 7, obstacles are randomly generated with values of 1%, 2%, and 3% over the entire area. Although the size of the obstacle is very large in Figure 7d, the obstacle is actually 1 m × 1 m. Only for visual effects, we make the obstacle appear to be large. A communication model between sensors is used, IEEE 802.11, and the regular transmission radius is assumed to be 20 m. More specifically, *antennaType*, *transmitterType*, and *receiverType* parameters are set as IdealRadioMedium module environment in OMNeT++ [27]. While jumping as high as possible, each hopping sensor has a maximum radius of 29 m of transmission. It also can move forward 2 m with one jump.

In order to reflect the effect of the realistic environment (wind, etc.), the movement model of each hopping sensor node is assumed with two-dimensional standard normal distribution, where standard deviations are 0.3 and the correlation is zero, as shown in Figure 1. The movement of the hopping sensor is indicated by a solid line as shown in Figure 7. For the performance analysis of the proposed relocation protocol, the sensing hole occurred in the middle of area, as shown in Figure 7.

We assume the scenario that the sensor nodes continuously gather data in the middle cluster zone, and they consume energy rapidly. Each sensor in the middle cluster generates a data collection event with an exponential distribution (average of 5 min). For convenience, the initial energy value for sensing is set to 100, and the energy consumption is 1 for each event occurred. Any energy model can be adopted, but a specific energy model is not considered here for simplicity. The main flow of the paper is about the creation and restoration of the sensing hole. An occurrence of a sensing hole (less than 10 member sensor nodes) is determined by a cluster header after HELLO message for every 15-minute interval. In particular, to perform the simulation on relocation of member sensor nodes to recover the sensing hole occurred, sensor nodes in other zones are assumed to perform no data collection. It also indicates in yellow that a sensor has become faulted due to energy depletion after continuous data collection in Figure 7.

In the majority of the hopping sensor relocation protocols so far, each sensor node knows all network information; like a central-based relocation protocol, it only considers the shortest path between cluster zones. However, it is very difficult to implement in reality; therefore, we propose a distributed-based relocation protocol, in order to overcome the drawbacks of the previous central-based relocation protocols. The implementation of the proposed protocol and simulation for performance evaluation are based on OMNeT++, which takes all communication system layers into account and also reflects both distributed computing of all sensors and actual environments. As far as we know, our implementation of hopping movement model considering obstacles is the first attempt in this field of study.

As previously explained, a sensing event occurs only in the middle cluster zone. After a three-day-long simulation, the result is shown in Figure 8. The dead member sensor node is colored yellow and the path of each hopping sensor is plotted by a solid line. Also, the movement of the sensor is shown as a zigzag due to environmental factors such as wind. It can also be confirmed that sensors captured in obstacles can no longer move and become faulted.

(**a**) obstacles 1% (**b**) obstacles 3%

**Figure 8.** Simulation snapshots finished for each obstacle.

We have simulated the relocation protocols using a sensor network topology generated randomly, and the results are described in Figures 9 and 10. First, Figure 9 shows the sensor retention rate in the middle cluster. Since the minimum number of members for each cluster to properly gather data is 10, the sensor retention rate is 1 if there are more than 10 member sensor nodes. For example, if there are five sensor nodes, the sensor retention rate is 0.5 (= 5/10), and if there is only one sensor, the sensor retention rate is 0.1. Since the previous hopping sensor relocation protocol [19] ignores the existence of obstacles, the sensor retention rate of it tends to be much lower than that of the proposed protocol, as shown in Figure 9. Figure 9 shows the change of each sensor retention rate during about three days. Since the sensing hole of the middle cluster occurs continuously, the neighbors' cluster headers might provide redundant sensors to recover the middle cluster's sensing hole until around 1000 min. However, neighbors' nodes are also depleted at that moment, thus the sensor retention rates in both schemes start to drop as shown in the green circle of Figure 9a. The blue circle of Figure 9a indicates that the proposed method considering obstacles shows better retention rate than previous scheme.

Figure 9b illustrates the difference between the sensor retention rates of the proposed and the previous protocols. It is easy to see that the number of top marks is more than that of below marks in Figure 9b. Since the sensor retention rates are only considered in the middle cluster zone, the denominator is ten, which is the minimum number of sensors to recover a sensing hole. In other words, if the difference of the rates is the positive 0.5, the proposed method accommodates five more sensors than the previous method at the same instance. A higher retention rate would result in requesting a smaller number of sensors compared with another method and generating fewer messages for movements to neighboring cluster zones. Hence, the proposed scheme would consume smaller energy to generate messages compared to the previous scheme and can play a major role in extending the lifetime of the network.

**Figure 9.** Sensor retention rates at the middle cluster.

Specially, in Figure 9d of obstacles 3%, our protocol successfully recovers the sensing hole better than that of the previous one. In other words, it is possible to strongly predict that data collection could be better than the compared protocol, even if the cluster zone still cannot recover the sensing hole.

In the simulation, every HELLO message is periodically broadcasted by each cluster header. The interval is set to be 15 min, and the cluster header should determine whether or not its zone is a sensing hole for every interval time. Whenever each cluster header checks the state of the sensing hole and sends REQ message, the moments for sensing hole appearance are shown in Figure 10. The delayed occurrence of sensing holes of this protocol compared to previous one indicates that more successful data collection is achieved. In addition, as we mentioned earlier in the message flows, the short duration of each occurrence of the sensing hole means that numerous messages are generated for REQ throughout the entire network. This could lead to unnecessary energy consumption due to message storms. Furthermore, in order to successfully accomplish the continuous desired data correction at the end of the wireless sensor network (i.e., the sink nodes), a relocation protocol has to avoid unnecessary energy consumption. Therefore, our relocation protocol is appropriate to reduce unnecessary energy consumption.

**Figure 10.** The moments for sensing hole appearance at the middle cluster zone.
