Hotspot Generation

To study the performance of our schemes, we run the above simulator against different types of hotspot settings. Specifically, we synthetically generate storage and query loads to carefully form different hotspot scenarios. When designing our simulations, we model real-world hotspot scenarios possibly arising in our disaster management applications as much as possible. We mainly concentrate on three hotspot types, namely storage hotspots, query hotspots, and mixed hotspots (consisting of simultaneous storage and query hotspots). For each hotspot type, we study a variety of settings, including single hotspots, multiple hotspots, and moving hotspots. Recall that a single hotspot is a hotspot occurring in one sub-range of the possible attribute ranges. To understand these hotspot types and setting in light of our disaster scenario, let us assume a typical scenario for a fire that is about to develop in the disaster area. In such a case, a single storage hotspot can arise when a fire starts to take place in the disaster area and most of the temperature readings fall in the [500, 600] sub-range.

Similarly, a single query hotspot may occur when many responders simultaneously check for the existence of a fire, thus target the [500, 600] temperature sub-range. When both hotspot

types occur simultaneously, i.e., the fire takes place and a lot of responders are checking for it, this forms a mixed hotspot in the [500, 600] temperature sub-range. Multiple hotspots simultaneously occur in two or more different sub-ranges of the attribute ranges. An example of such a scenario is the existence of two fires in the disaster area, an already developed fire and another one in the process of being developed. This can create simultaneous storage (or mixed hotspots) in two different temperature sub-ranges, e.g. [400, 450] and [550, 600].

Moving hotspots are hotspots initially occurring in a given sub-range of the attribute ranges then moving to one or more neighboring sub-ranges (one at a time) as time progresses. An example of such a hotspot is a fire throughout its different development stages. The hotspot may start at [300, 350], then move on to [350, 400], then to [400, 450], etc. For each hotspot setting, we simulated different hotspot sizes. This corresponds to the different possible sizes of fires that can possibly arise in our network. We discuss the technique to generate storage and query loads for the different hotspot types/settings in the following paragraphs.

Using the storage load generation technique discussed in Section 3.2.4, forming storage hotspots can be either done in a controlled manner or through a skewed reading distribution.

In the first case, we determine the exact reading ranges of the hotspot. This subsequently determines the sensors falling in the hotspot, which are the sensors responsible for storing the pre-specified hot ranges according to the underlying DCS scheme. We also determine the percentage of readings (among all storage load readings) falling in the hotspot range.

An example for that is to say that a hotspot will be arising in a range equal to 10% of the overall attribute range. As for temperature with attribute range [50, 90], this range can be [60, 64] degrees. The size of this hotspot can be 60% of all readings to be generated. This means that each sensor would randomly pick a reading falling in the hotspot range with a probability of 0.6. This controlled hotspot generation technique has many advantages.

The first is that it allows us to accurately determine the effect of the hotspot including its location, sensors that it affects, its size, and its duration. This gives us the opportunity to test different hotspot settings which has the great effect of carefully studying the behavior of our schemes against each of these settings. A second advantage for this hotspot generation scheme is that it allows us to generate hotspot data in a way that closely simulates real-world scenarios. Note that the actual percentage of readings falling in the hotspot range can be

slightly larger than the predetermined hotspot size in case readings supposedly not falling within the hotspot range (i.e., with probability 0.4 in our example) are generated through a distribution over the whole attribute range, e.g., a uniform distribution.

A second technique of hotspot generation in our simulator is by adopting a given skewed distribution for the readings, e.g., a normal distribution for readings over each of the attribute value ranges (i.e., a multivariate Gaussian distribution). In this case, the generating sensor would be picking the reading values uniformly at random from all the attribute ranges. It is important to note that both techniques can considered almost identical. This is simply because it is usually possible to fit any data distribution generated from the first technique with a specific skewed distribution generated from the second one. In our simulations, we mainly use the controlled technique to generate storage hotspots.

The techniques for forming query hotspots are very similar to the storage hotspot for-mation techniques. Traffic can be generated either based on a given skewed distribution or through carefully selected distribution (i.e., a controlled manner). In the first case, the ranges of the queries arising in any sensor follow a specific skewed distribution over the attribute ranges. In the second case, queries originate at random sensors and ask for data falling in a given attribute value range with a large probability, otherwise, ask for data falling in any range picked uniformly at random from the attribute value ranges. Both techniques are valid ones for generating query hotspots in the sensor network. In our simulations, we mainly use the controlled technique for generating query hotspots.

The third type of hotspots that we are interested to model are mixed hotspots. A network facing a mixed hotspot actually faces both storage and query hotspots occurring simultaneously. We can classify mixed hotspots into two types: correlated and uncorrelated.

We define mixed correlated hotspots to be those where storage and query hotspots coincide, i.e., fall in the same attribute ranges. In contrast, uncorrelated mixed hotspots are those where the storage and query hotspots fall in different attribute ranges. We implement both of them in our simulator.

When modeling hotspots, we will be interested in both static hotspots and dynamic hotspots. Static hotspots are those that occur in a given location at some point in time without moving to another location. Dealing with the hotspot once is enough for such a

case. We will be interested in modeling single and multiple static hotspots arising in the sensor network (simultaneously or back-to-back). On the other hand, moving hotspots can be represented by a series of two or more hotspots that are logically dependent and that occur one after the other. The dependence can be in terms of occurring in neighboring range values, such as a 10% hotspot that starts at the [60, 64] temperature range, then moves to [64, 68] temperature range. This example represents a very realistic scenario that can happen in a network mounted in any open-air location as the temperature increases and decreases equivalently in the whole service area. Thus, the sensor readings tend to fall in the same value range during any given time period. This range may be slightly shifting across time, which forms a moving hotspot. It is important to test the behavior of our schemes against all these hotspot scenarios for completeness.

It is important to note that the main goal of our experimental evaluation is to study the QoD that any scheme achieves against different hotspots. Recall that hotspots can have a secondary effect on the QoS by increasing the energy consumption of the nodes falling in the hotspot area and eventually increasing node deaths. As this is considered a long-term effect for hotspots, we did not concentrate on building test cases that simulate such a case. All the hotspot scales that we generate are not intense to the extent of generate a traffic skewness that actually increases node deaths. Thus, we test the performance of our schemes in terms of the QoD improvement that they achieve and the energy consumption overhead that they impose as compared to the case where no load balancing mechanisms are implemented.