Gobierno Móvil

Most of the optimized flooding research has been based on simulations. How- ever, it is also important to verify the performance in real networks due to the complex characteristics of wireless networks that cannot be captured in a simulator. In fact, the inaccuracy of wireless networks simulations has been known for some time now [29]. Multi-path fading, noise, interference, and hidden terminals are examples of factors that are hard to accurately reproduce in a simulator. Consequently, most simulations use a perfect cir- cular transmission area. However, links are frequently somewhere in between good and bad or experience strong asymmetric behavior [45]. Unfortunately, many flooding protocols are designed without considering these characteris- tics. They perform very well in the simulator environment, but the question remains; how do they perform under realistic circumstances?

These are all reasons to evaluate PFS in more realistic circumstances, such as in a real wireless multi-hop network. To properly test the performance of PFS, we compared it to Blind Flooding and CBB. In Section 5.6, we also compare these test bed measurements with the results obtained in a simulator. However, first we introduce the test bed that we used to compare these protocols.

5.4.1

The hardware and software platform

For our validation, we used t-mote Sky (based on Telos Revision B) [152] from Moteiv Corporation, which is a sensor mote platform for extremely low power, high data-rate, wireless sensor network applications. The reasons to use sensor motes were cost efficiency and ease of large scale deployment compared

5.4. THE TEST BED ENVIRONMENT 97

Figure 5.6: The t-mote Sky sensor mote

to if we would have used laptops or PDAs equipped with WLAN. The wireless technology used by t-mote Sky is 2.4 GHz IEEE 802.15.4 [87], which is a wide- band technology not very different from most wireless technologies of today, including IEEE 802.11. 2.4 GHz IEEE 802.15.4 uses direct sequence spread spectrum (DSSS) RF modulation with a data rate of 250 kbps.

A photo of the t-mote sky sensor mote is shown in Figure 5.6 while its specification is given in detail in [152]. In short, it uses a CC2420 Chipcon Wireless Transceiver [221], which is connected to an integrated onboard an- tenna. The microcontroller is an 8 MHz Texas Instruments MSP430 that can run TinyOS [222] and is equipped with 10 kB RAM and 48 kB flash memory. Further, the t-mote has a USB interface that can be used to up- load program code, experiment configuration parameters, and to download collected experiment data.

The IEEE 802.15.4 frame format begins with a 5 bytes synchronization header (SHR), followed by 7 bits (one bit is reserved) defining the number of bytes in the MAC Protocol Data Unit (MPDU). In our experiments, the MPDU consisted of a 9 bytes header that contained frame type, packet se- quence number, addressing information, etc. At the end of the packet, there is a 2 bytes CRC field. All in all, this means that a packet consisted of a payload plus 17 bytes of headers.

We used the default MAC protocol provided by Boomerang 2.0.4. Boo- merang is a software package developed by Moteiv that is based on TinyOS and tailored for the t-mote platform. The default MAC in Boomerang in- structs the radio to continuously listen for transmissions. When transmitting, a mote uses the clear channel assessment (CCA) function defined in [182] to determine whether the channel is idle or not. If there is an ongoing trans-

Figure 5.7: Photo from the experiment setup

mission, the mote waits a random time (uniform between 8 and 1024 µs) and tries again. After 8 unsuccessful attempts, it gives up and drops the packet.

5.4.2

Experiment setup

To avoid interference of external systems, we monitored the spectrum and chose a non-occupied channel. Then, we placed 50 motes in a matrix topol- ogy with 10 motes lined up in 5 rows. The distance between neighboring motes were the same, but varied between 0.3 m and 2.0 m for the different experiments. Each node was elevated about 20 cm above the floor using blocks of polystyrene foam in order to avoid the worst kind of multi-path interference. To avoid the need of a very large hall, we reduced the transmis- sion power to almost minimum (−24 dBm). A photo of an example scenario is shown in Figure 5.7. One of the motes in the center was connected to a laptop with a USB cable. The laptop was used to control the experiment by instructing the USB-connected mote to transmit instructions to the other motes using full power. With full power from a centrally located mote, all motes could be reached in one hop. The same technique was also used to collect the measurement data.

Since a larger distance between neighboring motes meant a sparser net- work, we defined a measure for the network density. It is basically the average node degree (number of direct neighbors), but also considers the packet de- livery ratio of the links. If a particular link experienced a packet delivery ratio of 40 %, we counted that as 0.4 links. We did this because a flooding protocol should be able to exploit the fact that packets can be sent on this link with a probability of 40 %. For unicast protocols, such links would prob- ably be useless and should be avoided, but for flooding, they are still useful.

5.4. THE TEST BED ENVIRONMENT 99

Therefore, we used the following definition as a measurement of the network density:

Avg. Node Degree = 1 N N X x=1 N X y=1 Rx,y (5.2)

where N is the number motes, Rx,yis the packet delivery ratio from mote x to

mote y and Rx,x= 0. A higher value means a denser network with 49 as the

maximum in our 50 motes networks. For each network scenario, we measured the average node degree by letting each mote transmit 500 packets. At the same time, each mote listened for packets from other nodes so that the packet delivery ratio for all node pairs could be estimated. The CCA functionality in combination with a sufficiently long packet generation interval was enough to practically eliminate collisions.

Each measurement started with the laptop instructing the USB-connected mote to send a configuration and start of experiment packet with full power to all the nodes in the network. Upon receiving this message, every node lowered their transmission power to the configured level and started to exchange some few hello messages. Depending on the configuration, each node generated one or three hello messages with a hello interval uniformly distributed between 0.9 s and 1.0 s. These hello messages only contained the mote’s address and were used to detect one-hop neighbors. For PFS, the hello protocol is a crucial part that may affect its performance. Therefore, we tested three different approaches to determine a mote’s neighbors:

1. A lenient method, where it is sufficient to receive one out of the last three hello messages to accept a mote as a neighbor. Hence, some included neighbors are difficult to reach.

2. A standard method, where the reception (or non-reception) of the last hello message is used to determine if a mote is considered a neighbor. 3. A strict method, where all the last three hello messages must be received

to accept a neighbor. This method creates the smallest neighbor set.

After the hello messages, a small waiting time of 0.5 s followed in order to avoid collisions between hello and flooding messages. Then, one mote, ran- domly selected, initiated a flooding. Every node in the network responded to this according to the chosen flooding protocol and configuration. Whenever a mote received the flooding message for the first time or retransmitted the flooding message, the time was stored in the mote’s memory.

When the flooding finished, we collected the data. On behalf of the lap- top, the USB-connected mote queried each mote for their measurement data, such as when and if it received the flooding message and when and if it re- transmitted it. All this data was compiled at the laptop to calculate the

Table 5.1: Network scenario connectivities Network scenario Avg. node degree

Fully connected 48.1 Very Dense (0.3 m) 44.4 Dense (0.6 m) 32.3 - 37.52 1.0 m 19.3 1.5 m 11.0 Sparse (2.0 m) 6.0

reachability, retransmissions, and delay of this single flooding. The mea- surement was then repeated until a sufficient number of floodings had been conducted to make statistically significant conclusions.