Tree Reconstruction Protocol

In the following, we introduce a tree reconstruction protocol to support emergency monitoring.

Emergencies are usually accompanied by damage to communication links, so this protocol is triggered when the reporting tree in Gc is broken.

The protocol works in a distributed manner. When a sensor x loses its parent by receiving a HELLO with a larger hop count than its current record or an emergency announcement EMG from its parent, x sets NO PARENT = true and executes the following steps:

1. Check its neighbor table to find another sensor, say y, with a hop count smaller than or equal to that of its original parent.

(a) If y exists, x sets y as its parent. If multiple candidates exist, the one with the best signal quality is chosen. Then, go to step 2.

(b) Otherwise, x deletes all its children in its neighbor table. If x’s neighbor table is

still non-empty, it chooses a neighbor with the smallest hop count as its parent and goes to step 2. Otherwise, it goes to step 3.

2. Broadcast a HELLO packet with its new hop count and parent, sets NO PARENT=false, and ends the procedure.

3. Set its hop count to infinity and broadcasts a HELLO packet with hop count= ∞. Then x waits for HELLO packets. Any HELLO with a finite hop count will cause x to choose the sender as its parent. Then go back to step 2.

The above reconstruction protocol is for quick recovery by avoiding cycles. Step 1(a) is to choose a new parent with at least the same hop count as its original one. Step 1(b) is to find a new parent in other subtrees. Both steps are to guarantee that no internal loops are formed.

When there are multiple emergencies, two sensors may set each other as their parents. This can be resolved when an up-to-date HELLO is received. Although HELLO packets may suffer from loss, up-to-date HELLOs will remove temporary cycles.

6.4 Simulation Results

This section presents our simulation results. We first consider a 10×10 grid networks. Each sensor has four navigation links to neighboring sensors on its east, west, north, and south.

A_emg is set to 200 and δ is set to 0.1. We compare our algorithm with the one in [44]. We use packet count and convergence time as performance metrics. Note that the packet count does not include packets used during the initialization phase. An unslotted CSMA/CA protocol following the IEEE 802.15.4 [37] is simulated with a data rate of 20 kbps. The convergence time is measured in ms.

Fig. 6.5 shows our simulation results. In case 1, the sensor located in the middle of the network detects an emergency event. However, this emergency event does not change the relative altitudes of neighboring sensors. So our algorithm only spends very few messages and quickly converges. In case 2, the placement of sensors is the same as the first case, except

660 /

Method of Li et al. Our method (D=2)

1

Method of Li et al. Our method (D=2)

No pkt. count/

Figure 6.5: Comparison of packet count and convergence time (in ms) in a 10×10 grid net-work.

that an emergency is detected by the exit sensor A. Although both algorithms will compute the same navigation paths, the algorithm in [44] will incur more messages, because sensors near A will first be attracted to, and then repelled from, A. In case 3, an emergency event is detected near exit A. As shown in the figure, without the concept of hazardous region, [44] will guide some users to pass through the hazardous region, which is undesirable. Our algorithm can effectively avoid guiding users through the hazardous region. In case 4, some sensors are bounded by hazardous regions. Although guiding users through hazardous regions is inevitable, our scheme will choose paths that are as farther away from emergency locations as possible. In case 5, we add one more exit in the lower-left corner. The algorithm in [44]

will direct some sensors to pass the hazardous regions to reach that exit, but the problem can be avoided in our algorithm. Case 6 shows a scenario that the network is almost partitioned by emergencies. Again, we see that the navigation paths discovered by our algorithm are safer than what are discovered by [44].

Fig. 6.6 illustrates our navigation results in networks with various forms. As can be seen,

205 /

Figure 6.6: Navigation results in various forms of networks.

our scheme can effectively lead people to exits and avoid hazardous regions. These results also imply that our protocol can be applied to variable forms of buildings. We have also simulated our algorithm in a large-scale sensor network with 2500 sensor nodes. There are 1% to 5% of random sensors being selected as exits, and 1% of random sensors as emergency points. The parameter D is set to 5. The convergence times of 1%, 2%, 3%, 4%, and 5% exit sensors are 21.6s, 10s, 9.1s, 2.9s, and 2.0s, respectively. This result demonstrates that our algorithm is quite scalable when applying to large networks.

D is an important parameter in our algorithm, which is used to form hazardous regions.

While the value of D is to reflect the dangerous range affected by an emergency event, its value may also affect the navigation results and system performance. For a small network, a D that is too large is meaningless, because a few emergency events may result in a network which is all covered by hazardous regions. Fig. 6.7(a) shows different settings of D in a 10×10 grid network. A small D may result in users being guided via paths close to emergency sources. On the contrary, a large D can help find safer paths, but the message overhead also increases. Fig. 6.7(b) shows the effects of δ and Aemg on the quality of escape paths and

204

Figure 6.7: (a) The effect of D on the quality of escaping paths and message overheads. (b) The effects of δ and A_emg on the quality of escape paths and message overheads.

message overheads. We observe that using a smaller A_emg with a larger δ may make it easier to guide users to cross hazardous regions (as the third case in Fig. 6.7(b)). This is because a larger δ may quickly increase the altitudes of sensors with local minimum to values larger than those a sensors in hazardous regions. We thus recommend to use a relatively larger Aemg with a relatively smaller δ. In our current design, these parameters, D, Aemg and δ, are configured at the deployment stage, and can be determined via simulations by manual involvement.

Next, we compare our emergency monitoring scheme against DD [39] and PEQ [23]. We consider a grid sensing field ranging from 10m × 10m to 24m × 24m. In each 1m × 1m grid, we deploy a sensor at a random location. Sensors’ transmission distance ranges from 2 to 3 m. A sink is placed at the upper left corner of the network. We randomly generate 20% sensors as emergency nodes so as to trigger our tree reconstruction protocol, and observe the convergence time, number of packet exchanges, and number of temporary cycles. Each result is the average of 100 simulations. Assuming perfect channels, Fig. 6.8(a) compares the

1

10x10 12x12 14x14 16x16 18x18 20x20 22x22 24x24

Convergence time (ms)

10x10 12x12 14x14 16x16 18x18 20x20 22x22 24x24

Number of packets

10x10 12x12 14x14 16x16 18x18 20x20 22x22 24x24

Temporary cycle rate (%)

Figure 6.8: Simulation results of (a) convergence time, (b) communication cost, and (c) tem-porary cycle rate under perfect channels.

convergence time of different schemes. In all cases, our scheme performs better than DD and PEQ. In PEQ, it takes long for a child of a failed node to broadcast SEARCH and to wait for responses to determine a new path. In DD, its negative reinforcements may go several hops to arrive at the children of failed nodes, thus causing long latency. Fig. 6.8(b) compares that the communication costs required to reach convergence. Fig. 6.8(c) shows the rates that temporary cycles are generated during our simulations under perfect channels. PEQ may cause cycles when sensors simultaneously change routes and DD may easily cause cycles when sensors select new parents from their interest data caches regardless of their hop counts to the sink.

Our scheme causes no temporary cycles. Note that when HELLO packets may be lost, our scheme may cause temporary cycles.

Simulation Experiment Pkt. Count Sim./Exp.

128

106

25/26

36/40

40/44 1

2

3

No Simulation Pkt. Count

Sim./Exp.

No

39/47

38/44

36/40 4

5