**4.5. Calculation of total time it takes a sink to complete one loop across the mobile path**

### *4.5.1. Sink stop-start movement with non-uniform velocity*

Initially the sink will have to move from a state of rest or initial velocity of zero to a constant, specified velocity. The time it takes a mobile sink to accelerate to a constant velocity can be calculated using the following equation:

$$a = \frac{v\_f - v\_l}{t\_{av}}$$

The initial and final speed as well as the acceleration of the mobile sink is known. Thus, the time it takes the mobile sink to accelerate from zero and reach constant velocity is:

$$t\_{av} = \frac{v\_f - v\_l}{a} \tag{13}$$

$$s\_{av} = \frac{1}{2}at\_{av}^2\tag{14}$$

$$t\_{dv} = \frac{v\_{xro} - v\_f}{d\_{stop}}\tag{15}$$

$$s\_{dv} = \frac{1}{2}at\_{dv}^2\tag{16}$$

$$s\_{cv} = d - (s\_{av} + s\_{dv}) = ut + \frac{1}{2}at\_{cv}^2$$

$$t\_{c\nu} = \frac{s\_{c\nu}}{v\_f} \tag{17}$$

$$T\_{total} = N\_{hello} \* (t\_{stop} + t\_{av} + t\_{cv} + t\_{dv}) \tag{18}$$

the above calculations is to assume that the mobile sink moves at constant velocity without stopping. When the mobile sink reaches a "hello" broadcast point it will transmit a "hello" type message to all nodes and continue moving at constant velocity. Because electromagnetic waves travel much faster than the mobile sink, the mobile sink should be able to send and receive all responses from surrounding nodes before it moves out of radio range. Then Equation [18] becomes:

$$T\_{total} = \frac{2 \ast (X\_{\text{g}} - X\_{\text{b}}) + 2 \ast (Y\_{\text{g}} - Y\_{\text{b}})}{v\_f} \tag{19}$$

Of course the mobile node will have to decelerate when it approaches a corner to turn, but within the experimental simulation it is assumed that this time to turn is negligible.

### **5. Experimental simulation**

60 Wireless Sensor Networks – Technology and Protocols

sink reaches the required constant velocity is:

Since at constant velocity, a=0,

calculated path is given by the following formula:

*4.5.2. Sink movement with uniform velocity* 

��� <sup>=</sup> �����

The distance the mobile sink has to traverse after accelerating from zero velocity to when the

The sink will have to decelerate to stop before it broadcasts another "hello" type message.

��� <sup>=</sup> �������� �����

The distance the mobile sink has to traverse after decelerating from constant velocity to zero

Now, the time the mobile sink will spend at constant velocity can be calculated based on the

� ���� �

������ = ������ � (����� � ��� � ��� � ���) (18)

��� <sup>=</sup> � � ����

��� = � � (��� � ���) = �� � �

��� <sup>=</sup> ��� ��

If ����� is the time a mobile sink will stop, broadcast a "hello" type message and wait for responses from surrounding nodes, the total time for a node to complete one loop along the

Each node within communication range of the mobile sink's path must be able to perform the above calculations. When one of these nodes receives an event message that it has to retransmit to the mobile sink, it can calculate the time delay before the sink will again pass by, based on the above equations. The node can then determine, based on the message status and urgency, whether to wait for the mobile sink to pass within communication range or whether to route the message to a node closer to the mobile sink. The sink path information contained in the previous "hello" message is used to determine which node to request to forward the message to the sink. As electromagnetic waves travel much faster than the

The previous calculations are based on the mobile sink stopping before it broadcasts a "hello" type message. The stopping and re-starting by the mobile sink will increase the time it takes a mobile sink to complete a loop around the calculated mobile path. A variation on

mobile sink, this will ensure that the event message reaches the sink in real-time.

 ��� <sup>=</sup> � � ����

The time it takes a mobile sink to decelerate to a stop is similar to equation [13], i.e.

velocity, i.e. to when the sink comes to a standstill, can be calculated as follows:

distance between each time the sink node broadcasts a "hello" type message:

� (13)

� (14)

(15)

� (16)

(17)

The experimental setup used the Network Simulator (NS-2). In NS-2 the mobile nodes move at constant velocity. As this was a simulation environment, the mobile node did not require time to accelerate to a constant final velocity or to decelerate when turning a corner. Therefore, the time calculations are based on the node moving at constant velocity around a square path.

Changes were made to certain C++ programs in the NS-2.3.5 version to enable the node to move along the specified path and periodically send "hello" type messages. A Tcl script defined the parameters of the path the node travelled on and stored the event messages received by nodes along the mobile node's path. When a mobile node passed by a node with stored event messages, the node would pass these messages onto the mobile sink.

Experiments were run to determine the time it takes to complete one loop around the calculated path as shown in Figure 1. This time was verified with the calculated time, using Equation (15). Thereafter an event message was broadcast from a node on the perimeter of the application area, and the effect on surrounding nodes was analysed. The velocity of the mobile sink was set at 10 m/s. The range of the nodes was assumed to be 30m.

Using Equation [3], the number of hops was calculated to be:

$$H\_{Sr} = \left(\frac{300}{(4\*30)}\right) + \left(\frac{300}{(4\*30)}\right)$$

$$= \frac{20}{4}$$

$$= 5 \text{ hops}$$

Using Equations [5], [6], [7] and [8] the path can be calculated as follows:

$$\begin{aligned} Y\_b &= \, X\_b = R \, \* \left( \frac{H\_{sr}}{2} \right) \\ &= 30 \, \* \left( \frac{5}{2} \right) \end{aligned}$$

(use the integer value, i.e. floor()) = 30 ∗ ��

 = 60

�

$$\begin{aligned} Y\_e &= \, X\_e = 300 - \langle R \ast \left(\frac{H\_{sr}}{2}\right) \rangle \\\\ \text{(b)} &= 300 - \langle 30 \ast \left(\frac{5}{2}\right) \rangle \\\\ &= 240 \end{aligned}$$

### **6. Results and analysis**

62 Wireless Sensor Networks – Technology and Protocols

(use the integer value, i.e floor()) �= �00 � ��0 � ��

application area with a node range of approximately 30m.

**Figure 4.** Experimental Setup with node 1 moved slightly into the application area.

= 240

�� =��� = �00 � �� � ����

The corner node (node 1 from Figure 1) is moved slightly into the application area (i.e. x = 10 and y = 10) to enable a message from node 1 to reach a node with at least 4 neighbours (in this case node 13). Figure 4 shows the experimental network topology for a 300 by 300

<sup>2</sup> ��

� �� Using Equation [19] the time it will take a mobile node moving at a constant velocity of 10m/s to complete one loop along the calculated path is calculated.

$$T\_{total} = \frac{2 \ast \{240 - 60\} + 2 \ast \{240 - 60\}}{10}$$

$$T\_{total} = 72 \text{ seconds}$$

The NS-2 Tcl script was run and the time taken for the mobile node to complete one loop around the calculated path as shown in Figure 1 is **72 seconds**.

An analysis of the number of messages received by nodes neighbouring the mobile node's path is shown in Figure 5. As can be seen, certain nodes receive more than one message. These nodes are on the perimeter of two intersecting "hello" type messages sent from the mobile sink as shown in Figure 1. Thus nodes 36, 37, 26, 27 etc. receive a "hello" message from the mobile node twice. To prevent this duplication of received messages from the mobile node, the researcher suggests that the neighbouring nodes go into sleep mode for a specified time period after receiving the first "hello" type message from the mobile node. This should ensure that all nodes neighbouring the mobile node's path only receive one message per complete loop of the circuit.

**Figure 5.** Number of messages received by nodes neighbouring mobile node's path

To conserve energy further, the number of times a mobile node will circumvent the path can be application-specific. For example, if sensor nodes are required to send updates to a sink periodically, the mobile node can traverse the path only during this time period. However, if the application requires the mobile node to monitor the area continuously for events and respond in real-time, the mobile sink has to move along the path and send "hello" type messages continuously.

However, the continuous sending of "hello" type messages at periodic intervals by the mobile node, does incur a cost. To reduce the number of messages transmitted within the application area further, (depending on the type of WSN application); a "hello" type message can be sent once at initialisation when the mobile sink first completes a loop along the path. All nodes along the perimeter will be able to calculate when the sink will pass by again and ensure that the node is awake during that time, if the node has event messages to relay. At the calculated time the perimeter node can proactively send a message to the mobile node informing it that it will begin transmitting event messages.

To determine the effect of the mobile node on reducing the total number of messages within the application area and received per individual node a series of tests were run for a message destined to the mobile node 0 (Figure 4) for both flooding and the mobile algorithms with various hop counts.

The effect of sending a message from a node on the perimeter of the application area to one of the nodes on the perimeter of the mobile node's path is analysed. For example, a message is sent from node *1* to nodes *14* and *24* (refer to Figure 4). As can be seen in Figure 6, only those nodes used to pass the event message receive more messages than those shown in Figure 5.

To further reduce the total number of messages sent and received when reporting an event message, the mobile node algorithm only allows nodes with four or more neighbours to rebroadcast the received event message. When a node that is within range of a mobile node receives a message (in this experiment, node 14 and node 24), it stores the message for collection by the mobile node 0. For flooding all nodes re-broadcast the message. The event message was sent at 3 seconds and the TCL script was set to end at 10 seconds, i.e., before the mobile node completes one full cycle around its predetermined path. The experiment was to compare flooding and using the mobile route algorithm in terms of the time to reach the destination and the total number of messages transmitted within the network as well as the number of messages received per node. Thus, the worst case scenario of assuming that the mobile node has just left the range of node 24 and node 14 and started on the path and will only return in approximately the time it takes to complete one full circumnavigation of the specified path is considered.

Figure 7 shows the number of messages received by node 14 and node 24 for the mobile algorithm and flooding. Node 14 and node 24 receive the same number of messages (2) for the mobile algorithm. In flooding the number of messages per node varies widely but node 14 tracks node 24 in terms of the number of messages received per hop count. In the mobile algorithm, node 14 and node 24 receive **two** messages, one from node 13 and one from the mobile node 0. As can be seen even for low hop counts, the number of messages when using flooding exceeds the number of messages for the mobile algorithm.

messages continuously.

algorithms with various hop counts.

the specified path is considered.

To conserve energy further, the number of times a mobile node will circumvent the path can be application-specific. For example, if sensor nodes are required to send updates to a sink periodically, the mobile node can traverse the path only during this time period. However, if the application requires the mobile node to monitor the area continuously for events and respond in real-time, the mobile sink has to move along the path and send "hello" type

However, the continuous sending of "hello" type messages at periodic intervals by the mobile node, does incur a cost. To reduce the number of messages transmitted within the application area further, (depending on the type of WSN application); a "hello" type message can be sent once at initialisation when the mobile sink first completes a loop along the path. All nodes along the perimeter will be able to calculate when the sink will pass by again and ensure that the node is awake during that time, if the node has event messages to relay. At the calculated time the perimeter node can proactively send a message to the

To determine the effect of the mobile node on reducing the total number of messages within the application area and received per individual node a series of tests were run for a message destined to the mobile node 0 (Figure 4) for both flooding and the mobile

The effect of sending a message from a node on the perimeter of the application area to one of the nodes on the perimeter of the mobile node's path is analysed. For example, a message is sent from node *1* to nodes *14* and *24* (refer to Figure 4). As can be seen in Figure 6, only those nodes used to pass the event message receive more messages than those shown in Figure 5.

To further reduce the total number of messages sent and received when reporting an event message, the mobile node algorithm only allows nodes with four or more neighbours to rebroadcast the received event message. When a node that is within range of a mobile node receives a message (in this experiment, node 14 and node 24), it stores the message for collection by the mobile node 0. For flooding all nodes re-broadcast the message. The event message was sent at 3 seconds and the TCL script was set to end at 10 seconds, i.e., before the mobile node completes one full cycle around its predetermined path. The experiment was to compare flooding and using the mobile route algorithm in terms of the time to reach the destination and the total number of messages transmitted within the network as well as the number of messages received per node. Thus, the worst case scenario of assuming that the mobile node has just left the range of node 24 and node 14 and started on the path and will only return in approximately the time it takes to complete one full circumnavigation of

Figure 7 shows the number of messages received by node 14 and node 24 for the mobile algorithm and flooding. Node 14 and node 24 receive the same number of messages (2) for the mobile algorithm. In flooding the number of messages per node varies widely but node 14 tracks node 24 in terms of the number of messages received per hop count. In the mobile algorithm, node 14 and node 24 receive **two** messages, one from node 13 and one from the mobile node 0. As can be seen even for low hop counts, the number of messages when using

flooding exceeds the number of messages for the mobile algorithm.

mobile node informing it that it will begin transmitting event messages.

**Figure 6.** Number of messages per node when event message sent to node on mobile nodes perimeter

**Figure 7.** Number of messages for node 14 and node 24 for varying hop count

Figure 8 shows the number of messages per individual node when only nodes whose neighbours are equal to or greater than 4 re-transmit an event message. When compared to the number of messages received per node in Figure 6, it is obvious that by restricting which nodes re-transmit an event message, there is a significant decrease in the number of messages received or re-transmitted amongst individual nodes. Once the event message reaches a node that can convey the event message directly to the mobile node (in this case node 14 and node 24), the algorithm stops retransmitting the event message.

**Figure 8.** Restricting re-transmission of event messages to nodes with 4 or more neighbours

In Figure 6, the TCL script is run for 72 seconds whereas in Figure 8 the TCL script is only run for 10 seconds. Thus, not all the nodes along the perimeter of the mobile nodes path are shown receiving messages from the mobile sink in Figure 8. The number of messages for node 13 and node 24 are reduced by half when the number of neighbour nodes restriction rule applies.

Figure 9 shows the number of messages per individual node if a typical flooding message is sent from node 1 to a static node 0 located at the same X,Y coordinates as node 25. Flooding a message to the sink is the worst case scenario as more nodes receive (and possibly have to re-transmit) messages which depletes an individual node's limited energy and reduces node and network lifetime.

rule applies.

and network lifetime.

Figure 8 shows the number of messages per individual node when only nodes whose neighbours are equal to or greater than 4 re-transmit an event message. When compared to the number of messages received per node in Figure 6, it is obvious that by restricting which nodes re-transmit an event message, there is a significant decrease in the number of messages received or re-transmitted amongst individual nodes. Once the event message reaches a node that can convey the event message directly to the mobile node (in this case

node 14 and node 24), the algorithm stops retransmitting the event message.

**Figure 8.** Restricting re-transmission of event messages to nodes with 4 or more neighbours

In Figure 6, the TCL script is run for 72 seconds whereas in Figure 8 the TCL script is only run for 10 seconds. Thus, not all the nodes along the perimeter of the mobile nodes path are shown receiving messages from the mobile sink in Figure 8. The number of messages for node 13 and node 24 are reduced by half when the number of neighbour nodes restriction

Figure 9 shows the number of messages per individual node if a typical flooding message is sent from node 1 to a static node 0 located at the same X,Y coordinates as node 25. Flooding a message to the sink is the worst case scenario as more nodes receive (and possibly have to re-transmit) messages which depletes an individual node's limited energy and reduces node

**Figure 9.** Number of messages per node for a flooding message sent to a static node 0 located at node 25.

**Figure 10.** Time it takes for an event message sent from node 1 to reach node 14 or node 24

The time it takes for an event message to reach node 14 and node 24 using the mobile algorithm with re-transmissions of event messages restricted to nodes with four or more neighbours is shown in Figure 10. If the mobile node has just passed out of range of node 24 and node 14, then these nodes must wait for approximately 72 seconds before the mobile node is within range again. Alternatively, depending on the real-time requirement of the application, the perimeter nodes can retransmit the event message as electromagnetic waves travel faster than the mobile sink and the message should reach the sink in less than 72 seconds.
