In this section, we describe our system model. We start by describing our sensor network model and our motivating disaster management application. Then, we discuss the types of sensor devices that can be adopted by our sensor network to best serve the requirements of our motivating application.
3.1.1 Network Model and Motivating Application
Sensor network applications can be characterized into two types, namely search/discovery and investigation. Search/discovery sensor network applications consist of continuously itoring a service area for the sake of studying one or more phenomena, e.g., habitat mon-itoring applications [54],. These applications are generally characterized by the relatively long expected network lifetime. Due to this fact, the major challenge for these networks is to improve Quality of Service (QoS) as much as possible, even at the cost of providing a lower Quality of Data (QoD). One the other hand, investigation applications consist of sensor networks running for relatively short time periods in order to investigate one or more
events of concern, e.g., disaster management applications [7]. The expected network lifetime in these cases is fairly short, e.g., ranging from few hours to few days. Due to the importance and the urgency of the event being investigated by the sensor network, QoD is a major goal in these applications even at the cost of decreasing QoS.
We mainly focus on a sensor network for a disaster/emergency management application.
We consider a cluster of sensor devices spanning a limited geographic area, namely the service area, in the range of hundreds of meters. Sensor devices are assumed to be stationary and capable of wirelessly communicating among themselves (through the IEEE 802.5 standard communication protocol), as well as with other mobile computing devices such as cell phones, laptops, palms, and PDAs (possibly through one of the standard IEEE 802.11 protocols). At the start of the network operation, sensor devices organize themselves to start performing their given task, which is mainly monitoring and storing different types of information, e.g., temperature, pressure, etc. Sensors are battery-operated devices equipped with limited storage and communication capabilities (detailed device specifications presented in the next subsection). The existence of base stations, i.e., servers, is not mandatory in our sensor network.
The query load imposed to the sensor network is formed as follows. First responders to the disaster roam in the service area with their handheld computing devices. Using these devices, they issue ad-hoc queries which are mainly range queries. A range query usually queries the sensor network for readings whose values belong to a given attribute range [a, b] during a specific time period [t1, t2]. As most sensor nodes nowadays have the capacity to generate and store multi-dimensional readings, the query may be asking for readings satisfying a given attribute range for each of the reading dimensions, e.g., [a1, b1] for attribute 1 and [a2, b2] for attribute 2, etc. Furthermore, the query may not necessarily be asking for actual readings, it can ask for the sensor(s) that sensed these readings, the number of these readings, or any other aggregate function on these readings, such as their average value, their median value, their minimum value, their maximum value, etc. A simple example for such a query would be querying all sensors mounted in the service area for the IDs of sensors that sensed a temperature of between 50 and 60 degrees Fahrenheit and a pressure between 1000 and 1010 millibars during the last 10 minutes.
First responders may be using a variety of mobile computing devices to interact with our sensor network. Cell phones are currently the most widespread among these devices, especially after the current advances in the mobile phones technology. In addition to cell phones, other mobile devices that may possibly be querying the sensor network could be PDAs, laptops, car computers, etc. Mobile devices may also be operating independently from any human user such as the case in robots. The number of mobile users/devices is time-varying, and hardly predicted at any time of the network operation. Consequently, the query load imposed on the sensor network, represented by both the number and the distribution of the queries accessing the sensor devices, is also variable and hard to predict.
The sensor network is responsible for efficiently processing all queries it receives. As discussed in the previous chapters, Data-Centric Storage (DCS) is adopted as the storage paradigm for our sensor network model. In a DCS scheme, a sensor reading generated by any sensor is forwarded for storage to a possibly different sensor node, namely the storage sensor, determined by mapping the reading attribute values to the space of sensor addresses (or geographical coordinates). Specifically, whenever a sensor s1 measures a reading, it sends the reading tuple to be stored in another sensor s2 which is determined based on the mapping function of the specific DCS scheme applied. s2 only keeps this tuple for a limited amount of time due to memory limitations. A sensor can use a First-In-First-Out scheme (FIFO) to always keep the most recent readings in its cache. In the case that large reading histories need to be kept in the sensor caches, each cache can be split into two parts, one for storing the recent readings and the other to aggregate the elder readings in terms of window increments [20].
Before determining the appropriate device type to be used in our sensor network model, we first characterize disaster areas into two types, namely permanent and temporary. Per-manent disaster areas can be forests perPer-manently under fire risks, volcano locations, rivers frequently experiencing floods, and buildings located in areas under continuous risks of tor-nados or earthquakes. Possible temporary service areas are mainly areas experiencing a non-frequent emergency such as the world trade center location immediately after 9/11, the location of a fire or that of a plane crash, etc. Throughout our experimental evaluation, we mainly focus on temporary disaster areas.
3.1.2 Sensor Devices
Currently, wireless sensor network devices fall into two main categories; mote-class devices and microservers. Mote-class devices are tiny, inexpensive, resource-constrained devices that operate for long periods of time on battery power (originally designed at UC Berkeley in 2000 [27,26]). Mote-class devices are mainly characterized by their low power consumption achieved primarily through using a micro-controller (MCU) and a low-power radio (e.g., CC1000 or CC2420). The current generation of motes includes the Mica2 and MicaZ [1]
as well as the Telos [45]. Mica motes include an Atmel ATMega128L 8-bit micro-controller running at 8MHz that contains 4 KBytes of SRAM and 128 KBytes of Flash ROM. The Mica2 contains the CC1000 FM-based radio while the MicaZ has the 802.15.4-compliant CC2420 radio. On the other hand, the Telos uses a 16-bit MSP430 microcontroller with 10 KBytes of RAM and 60 KBytes of Flash ROM as well as a CC2420 802.15.4 radio. Some other mote-class devices include the Eyes node [55] and the Blue Mote [41].
The second category, microservers, is comprised of devices that mostly resemble an em-bedded PC platform. Microservers include a 32-bit CPU, megabytes of DRAM and up to several gigabytes of stable storage as well as a high-bandwidth 802.11 radio. Since mi-croservers are similar to a PC platform, they include support for sophisticated peripherals as well as high data rate sensors. One of the first microserver platforms specifically de-signed to support wireless sensor networks was the Intel Stargate [29]. The Stargate has a 400MHz 32-bit PXA55 XScale processor, 64 MB of SDRAM, 32 MB of internal Flash and a Compact-Flash slot that can extend its storage to 1 GB or more. An Ethernet port as well as an 802.11 PCMCIA card provide its networking support. The Stargate operates on rechargeable lithium battery. Since the Stargate is fairly powerful in terms of computational resources, it is able to run a conventional operating system. The current generation of Star-gates runs a Linux distribution (Familiar [24], based on a 2.4.19 kernel) and supports several file system types.
The choice of a specific category of sensor devices to be used in our disaster manage-ment application depends on different parameters. The first is the expected lifetime of the sensor network. In case the sensor network is intended to be deployed once and expected to
be operating for long times (such as the case for permanent disaster areas), the mote-class sensors will be more fitting for this scenario. However, this would mean that the DCS model that we adopt should be acting as a temporary storage for sensor readings rather than a permanent one due to the limited storage capability of the mote devices. Synopses of sensor readings may then be forwarded to base stations for permanent storage and processing. A second parameter determining the sensor device category can be the mobile devices des-ignated to be used with the sensor network and their networking capabilities. Assuming that the main mobile devices used to communicate with sensor devices are cell phones, the specific networking protocol used by these cell phones, e.g., 802.11g or 802.15.4, will a factor determining the sensor types adopted by the sensor network.
A third parameter determining the actual device category adopted by the sensor network would be the sophistication level of the individual tasks of sensor nodes in the network.
Generally speaking, mote-class devices are more suited for monitoring applications than microservers. This is mainly due to the simplicity of the task of each individual sensor in sensor networks used for monitoring applications. In our disaster management application, the main task of each sensor lies in monitoring and relaying information about the disaster area. In such a case, the capabilities of a sensor mote are sufficient for performing the required tasks. A fourth parameter is the expected cost for building and maintaining the sensor network. Again, the cost of microservers may be a constraint for using them in sensor network deployments, especially large-scale ones. A fifth parameter is the nature of the service area and whether the operation will be unattended or no. This implicitly affects the possibility of existence of a recharging mechanism for microservers or would totally avoid their usage in case of the unavailability of such a mechanism.
A sixth parameter would be the type of queries forming the query load and whether they contain predicates or joins that would require intensive computing to be processed. Complex queries may lead to choosing to add one or more microservers to the sensor network to be responsible for processing queries and delivering final results to the user. A final parameter can be the disaster type and the subsequent sensing rate. In general, emergencies would need much higher sensing rates than those needed for sensor networks deployed in permanent disaster areas where the sensor network can be considered as a long-term monitoring sensor
network. Therefore, microservers would be more fitting for these emergencies. The actual selection of the device category to be used by the sensor network would be a design choice taken by the network designers based on all the previously discussed parameters.
In general, the schemes and algorithms that we design in this dissertation are independent from the actual device category adopted by the sensor network. Our schemes continue to work well even for a sensor network composed of devices from both categories. For this scenario, storage loads may not be initially homogeneous among all sensors. Microservers may be the ones responsible for storing sensor readings. Other motes may temporarily store readings then relay them to microservers, or may simply not be responsible for storing any readings. A possibly different set, or a subset, of microservers, may act as gateways for communication with the mobile devices. Our schemes continue to be fitting for all these possible design options. Throughout the experimental evaluation of this thesis, we consider our network to be solely composed of motes.