## 7 SMEP Algorithms
### AuxDataQueue Compression Algorithm
There may be the lost sensor data between the last partner selected from _ZoneCompHistory_ and the first ground sensor data in the first 0 valued zone. Accordingly, this recovery process appears from the procedure line 32 to 37. This process is not necessary in the cases that the last zero-valued zone is the first zone 0 or the last partner selected from _ZoneCompHistory_ is the greatest absolute positioned sensor data covered by the last target zone for decompression and recovery. The processes about these cases are reflected on the procedure lines 32 and 34, respectively. Meanwhile, if the last target zone is the last zone \(m-1\) of _DataQueue_, there exists in _AuxDataQueue_ a next new partner of the last partner selected from _ZoneCompHistory_, because the new partner does not exist in the next zone any more. If not, however, the new partner exists in _DataQueue_. Each of recovery processes on these cases is reflected on procedure lines 34 and 35 and procedure lines 32, and 33. Furthermore, each case is involved in the next process for ground sensor data in the zero valued zones and _AuxDataQueue_. In other words, in the case that the last target is not the last zone of _DataQueue_, the procedure just outputs each remaining sensor data in _DataQueue_ with its absolute position (from the procedure line 38 to 42) since all of ground sensor data remain in _DataQueue_, Otherwise, the procedure outputs each remaining sensor data in _AuxDataQueue_ with its absolute position (from procedure line 38 to 42). Because ground sensor data do not exist in _DataQueue_, any more. ## 9 Performance Comparisons and Analysis

Until now, we have focused on minimizing error for the lost sensor data in compression intervals rather than on minimizing energy consumption, as have most of the current research works. Therefore, our performance evaluation focuses on the average error rate per recovered sensor data as one of performance factors. This section shows average error rates by experimental results based on real-field sensor data sets. ### Experimental Environments and Evaluation Measure

#### 9.1.1 Experimental Sensor Data Sets and Samples

Samples extracted from each of four real-field sensor data sets: underwater pH in the ocean, underwater temperature in the ocean, relative humidity in a city, and air temperature in a city. The underwater pH and underwater temperature sets were collected through a wireless sensor network developed by us from a real field: a littoral sea near Yokjido, which is a small island at Tongyeong-Si, Gyeongsangnam-do, Korea. The other sets, relative humidity and air temperature, were collected in Seoul, Korea, by the Meteorological Administration. Each sensor data in each of these four sets is a data collected every alternative hour. In fact, before choosing these four sensor data sets, we had considered two types of sensor data sets as experimental sensor data sets: one is the type of sensor data set in which changes in the difference among sensor data values are frequent and high. The other is the type of sensor data set in which changes in the difference among sensor data values are infrequent and low. The reason for our consideration is that we had predicted higher error rates in sets with frequent and high value changes than in sets with infrequent and low value changes. Moreover, another reason was to ensure the validity of the average error rate of the SMEP method in sets with frequent and high value changes. Specifically, our main concerns are whether the average error rate in the SMEP method is valid in sets with frequent and high value changes, and until how many times compression is generally reasonable. Two sensor data sets, the relative humidity set and air temperature set, have more frequent and higher value changes than the two remaining sets, the underwater pH set and underwater temperature set. We chose different samples from these four sensor data sets, as shown in Table 2, depending on various experiments. How and why to choose them is described in detail in Sections 9.2.1 and 9.2.2.