A Metadata Encoding for Memory-Constrained ... - Semantic Scholar

A Metadata Encoding for Memory-Constrained Devices Farha Ali, Yvon Feaster, Sally K. Wahba, Jason O. Hallstrom School of Computing, Clemson University, Clemson, SC 29634-0974

{fali, yfeaste, sallyw, jasonoh}@cs.clemson.edu

ABSTRACT With the broad applicability of wireless sensor networks across fields, it is desirable to develop self-describing sensor nodes that can operate in a plug-n-play manner. In this paper, we present MoteML, a metadata encoding suitable for storage on memory-constrained devices, designed in support of this goal. MoteML is consistent with Sensor Web Enablement’s [23] Sensor Model Language (SensorML). More specifically, while MoteML does not conform to the SensorML schema, it can be translated into SensorML and vice-versa. This paper explores the available solutions for storing self-describing information on memory-constrained sensor nodes and presents the design of MoteML. MoteML is a text-based encoding that captures a subset of SensorML in a template-based structure. This text data is then compressed using available text compression techniques. The resulting file is small enough to be stored on a memoryconstrained embedded device.

Categories and Subject Descriptors C.2.0 [Computer-Communication Networks]: Data communications; E.2 [Data Storage Representation]: Composite Structures; E.4 [Coding and Information Theory]: Data compaction and compression

General Terms Design, Standardization, Wireless Communication

Keywords Embedded networks, sensor networks, metadata, SensorML, MoteML

1.

INTRODUCTION

A wireless sensor network (WSN) is a computer network that monitors and records sensed data. WSNs are used in monitoring civil infrastructure [1], aiding in disaster response [10], monitoring water resources [8], and monitoring

Permission to make digital or hard copies of all or part of this work for personal or classroom use is granted without fee provided that copies are not made or distributed for profit or commercial advantage and that copies bear this notice and the full citation on the first page. To copy otherwise, to republish, to post on servers or to redistribute to lists, requires prior specific permission and/or a fee. 49th ACM Southeast Conference, March 24– 26, 2011, Kennesaw, GA, USA. Copyright 2011 ACM 978-1-4503-06867/11/03 ...$10.00.

health conditions, such as Parkinson’s disease and strokes [15]. A WSN typically consists of a set of deployed sensor nodes, middleware to collect data from the nodes, and a database to store the data [17, 25, 31]. For the data to be meaningful across application layers, potentially developed by different vendors, it is beneficial to represent the data in a standard format. Moreover, to fully understand the data collected from a WSN, metadata information is necessary. This includes information about where the data was collected, any constraints, and the units of measurement. This too, should be stored in a standard format. In this paper, we focus on the Sensor Web Enablement (SWE) [23] standards introduced by the Open Geospatial Consortium (OGC) [19] and used to support in-network discovery of sensor nodes and decoding the data they collect. Sensor Model Language (SensorML) [21] is SWE’s standard for describing sensor systems. SensorML is encoded using XML and its schema provides a rich collection of elements that can be used to represent both data and metadata. The natural question that arises when using SensorML is where to store the SensorML file for each node. One solution is to store the file in an external repository. When a data packet is received from a node, the corresponding file is fetched and used to interpret the data. Adopting this solution, a number of new questions arise: When should the file be stored in the repository? How is the repository kept consistent with the deployed network? One solution is to develop a way to store SensorML files within each node. But this is difficult: On the one hand, a typical sensor node relies on a microcontroller that offers 64K of ROM, 4K of RAM, and 2K of EEPROM storage [2]. On the other hand, SensorML files are expressed using XML and are commonly on the order of 10K – 30K in size — too large to be stored on a sensor node. There are two possible solutions to consider: SensorML files may be (i) saved in the Transducer Electronic Data Sheet (TEDS) format [12] or (ii) compressed using XML compression techniques. The first solution approach presents problems. First, TEDS stores sensor information in fixedsized binary blocks. SensorML is a text-based standard; data cannot be stored in fixed-size blocks. Second, TEDS stores sensor data in templates, the structure of which varies according to sensor type. In contrast, SensorML uses one general element for storing information about a sensor. Hence, it is difficult to map all different types of TEDS sensor templates to a single SensorML element. The second method, too, has problems. SensorML files compressed using this method are still too large to be stored within a typical sen-

sor node. For example, using available XML compression utilities, a 10K-30K SensorML file can be compressed to a size range of 1K to 3K, which is potentially too large to be stored on a sensor node’s EEPROM of size 2K. In this paper, we describe a metadata encoding approach that combines the capabilities of both solution candidates. We present MoteML, a text-based encoding technique for storing self-describing sensor data on memory-constrained sensor nodes. The text encoding can be compressed using standard compression techniques, and the resulting files are small enough to be stored on a sensor node’s EEPROM and still be translated into SensorML. The remainder of the paper is organized as follows: Section 2 presents background information on SensorML, TEDS, and XML compression techniques. Section 3 describes MoteML. Section 4 details the implementation of tools to support MoteML. Section 5 provides an evaluation of MoteML. Section 6 discusses elements of related work. Finally, Section 7 concludes with a discussion of future work.

2.

BACKGROUND

MoteML is designed to capture a key subset of SensorML using ideas adapted from TEDS and available XML compression schemes. Subsection 2.1 introduces SensorML. Subsection 2.2 presents TEDS, a standard for storing information about a sensor’s observational capabilities. Subsection 2.3 presents an overview of some standard XML compression techniques.

2.1

SensorML

The Open Geospatial Consortium (OGC) [19] is an international organization that develops standards for geospatial and location-based services. Sensor Web Enablement (SWE) [23] is one of many suites of standards developed by the OGC. SWE consists of a group of encoding and webservice standards for locating sensor nodes, as well as accessing and understanding the data they collect. The Sensor Model Language (SensorML) [21] is the SWE encoding standard for describing a process of measurement. SensorML defines a sensor system using several different encoding standards present in the SWE suite. For example, the location of a sensor system is defined using SWE’s Geography Markup Language (GML) [18], and sensor data is encoded using the SWE’s Common Data Model [22]. When using SensorML to describe a sensor platform, the System tag refers to the node platform and includes information about its identity, geographical location, and valid time frame for observation gathering. Multiple sensors can be mounted on a sensor platform, described in a ComponentList nested within the System tag. ComponentList may contain one or more Component tags, each used to describe an individual sensor hosted by the platform. The sensor description in a Component tag includes a list of inputs, outputs, and parameters. InputList contains information about the physical phenomena being measured, and OutputList contains the name of the outputs and their units of measure. Parameters are defined in SWE’s Common Data Model to specify output constraints, such as the accuracy and range of a given sensor. The Common Data Model provides a rich collection of elements for describing numerical data values. Example elements include: (i) DataRecord – multiple numerical values grouped together, (ii) Quantity – a single numerical value, and (iii) QuantityRange – a numerical range.

This is only a partial treatment of SensorML. We are using only the elements essential to describing the location and observational properties of a sensor system.

2.2

Transducer Electronic Data Sheets

IEEE 1451 specifies the Transducer Electronic Data Sheets (TEDS) standards for analog sensors. A TEDS document is used to store information about a sensor’s observational capabilities. The specification of a sensor is stored as a chain of binary blocks, each structured according to a given template. These blocks are separated by a 10-bit section that identifies the next template that should be used for decoding the proceeding data. TEDS data can be stored in EEPROM or referenced externally. To decode TEDS data, templates are referenced from external resources. There are three main types of TEDS templates: basic templates, standard transducer templates, and calibration templates. A TEDS sensor specification begins with a basic template — a block of 64 bits. It stores sensor information, such as the manufacturer ID, the model number, the version letter, the version number, and the serial number. Typically, the second template is a standard transducer type template. The structure of these templates varies according to sensor type, and they are identified using a numeric identifier. Optionally, the transducer type template can be followed by a calibration template, which is used to specify information about the data provided by the transducer. Calibration templates also vary according to the type of calibration data they store. Finally, a user data section may be included to store custom information about the sensor.

2.3

XML Compression

SensorML is encoded using XML and the resulting files are compressed using XML compression utilities. XML compression techniques are classified into two categories: textbased compression and XML-aware compression. Standard text compression techniques are used to compress SensorML. They do not, however, make use of a document’s XML structure. Here we briefly discuss two common utilities for text compression: Gzip and Bzip2 Gzip [9] is based on the DEFLATE [6] algorithm, a combination of Lempel-Ziv77 (LZ77) [7] and Huffman coding. LZ77 is a lossless, dictionary-based compression algorithm. More concretely, strings of characters are mapped to a single numeric code. These codes are written in a manner that allows the program to continuously build the dictionary, both during compression and decompression. Huffman coding is an encoding algorithm that uses variable length code tables to encode source data. DEFLATE uses LZ77 to find repetitive strings of characters and then builds a coding table using Huffman coding. Bzip2 [4] is the most recent version of the Bzip utility. It uses the Burrows-Wheeler Transform (BWT) [16], also known as block sort. BWT permutes input text strings such that the frequently appearing strings are grouped together in a block. Bzip2 uses move-to-front [26] and Huffman coding. Although both text compression techniques are promising, the average size of a SensorML file describing a sensor node and the sensors mounted on it is on the range of 10K-30K, and their text compressed versions (not using XML-aware compression) are on the range of 1K to 3K – still too large for EEPROM storage. Accordingly, these techniques alone are not sufficient.

SS1234 , 2005−11−21T20 : 0 0 : 0 0 Z , 2011−11−21T20 : 0 0 : 0 0 Z , 4 5 . 4 5 , −89.12# Listing 1:

Platform

Template for Example Sensor System

XML-aware compression techniques are the next option to consider. These techniques are classified on the basis of how they make use of the document structure. Popular techniques/software include XMill [14], XGrind [29], XComp [13], XWRT [28] and XMLPPM [5]. XMill separates the structure of an XML document from the data it contains. Structure and data are saved separately and then compressed using the most suitable text compression algorithm. XGrind does not separate data from structure. Instead, it saves XML tags and data using a dictionary-based encoding scheme. Character data is compressed using semiadaptive Huffman coding. XComp parses an XML document, reorganizes its contents, and then sends it to a compression tool. XWRT is similar to XMill; it prepares a dictionary of frequently appearing strings (e.g., XML tags) and replaces them with a reference in the dictionary. Character data is then passed to a general text compressor. XMLPPM uses prediction by partial match method (PPM). PPM uses the previous symbols in the symbol stream to predict the next symbol. Although the above mentioned algorithms are suitable for XML files in general, further compression can be achieved by exploiting the fact that the structure of a SensorML document need not be saved during compression.

3.

3 Temp Sensor , T123 , t e m p e r a t u r e , realTemp , measuredTemp , F /& d c a l i b r a t i o n , l i n e a r C a l i b r a t i o n , s t e a d y S t a t e , 3 /& measurementRange , F , −5.0 3 5 . 0 /& g a i n , , 1 . 0 /& o f f s e t , , 0 . 0 /& p a c c u r a c y /& a c c u r a c y , Cel , 0.002#

MOTEML

MoteML uses a text-based encoding, where a sensor node’s information is represented in fields and arranged in a predefined structure – templates. These templates can be directly related to SensorML elements. The information is then compressed using common text compression techniques. Generating a MoteML file consists of the following steps: First, sensor data is acquired using either an input file or a user interface. Second, the acquired data is saved using the template structure shown in Listings 1 and 2 (and discussed below). Finally, the resulting byte stream is compressed using text compression methods. In MoteML, templates have been designed only for the fundamental elements of SensorML. With the exception of the Platform template, each template begins with a numeric ID. All MoteML templates end with ‘#’. The Platform template defines the properties of the sensor node on which one or more sensors are mounted. It is expressed as a commaseparated list of fields. As an example, consider a sensor node geographically located at latitude and longitude coordinates of 45.45, -89.12, respectively. The sensor node’s ID is SS1234, assigned by the network administrator. Data is collected between the timestamps 2005-11-21T20:00:00Z and 2011-11-21T20:00:00Z1 . This sensor node has one temperature sensor mounted on it. The sensor’s ID is T123 and its name is Temp Sensor. The sensor measures temperature in ◦ F, with an error tolerance of +/0.002. The acceptable measured temperature values should be within the range -5 to +35 ◦ F. A gain of 1.0 and an offset 1 These timestamps are defined using Coordinated Universal Time using a structure. The date is represented using a YYYY-MM-DD format; T indicates that the next entry is time. Time is represented using a HH:MM:SS format; Z indicates zero offset from local time.

Listing 2:

Sensor

Template for Example System

of 0.0 should be used when these values are used in an application. The range, gain, and offset used for calibration of sensor outputs are stored as a group of fields, while accuracy is stored as a single field. The grouping of parameters is decided by the WSN administrator and is usually specific to a WSN application layer. Listing 1 depicts how the above sensor node’s information is stored using the Platform template. The template stores the following information: (i) the sensor node’s ID, (ii) the data collection start timestamp, (iii) the data collection end timestamp, (iv) the latitude position, and (v) the longitude position. Fields are separated by commas, and the template ends with the ‘#’ marker. The Platform template can be followed by other MoteML templates, each corresponding to an element from SensorML. For example, the Sensor template is used to represent properties of an individual sensor. Listing 2 shows the Sensor template for the above example system. The start of the Sensor template is marked with the template identifier 3. The template consists of multiple records and sub-records, separated using ‘/&’. The first record provides the following information about the sensor: (i) sensor name, (ii) sensor ID, (iii) input to the sensor, (iv) observable property2 , (v) sensor output, and (vi) the output’s unit of measure. The second record specifies output parameters. This record starts with a ‘d’, indicating a parameter comprised of a group of constraints, or a ‘p’, indicating a single constraint parameter, or a ‘#’, meaning there are no constraints. In Listing 2, the second record starts with a ‘d’ and specifies all constraints used for calibration of the sensor’s output. This record consists of multiple sub-records. The first sub-record contains the following information: (i) the purpose of the parameter, (ii) the parameter definition3 , (iii) the name of the parameter and (iv) the number of constraints in the group. This record is followed by sub-records describing the constraints in the group. Each constraint is defined using three fields: (i) the name of the constraint, (ii) its unit of measure (can be left empty), and (iii) the numerical value of the constraint. Fields are separated using commas. A single constraint parameter starts with a ‘p’, followed by the name of the parameter and a sub-record specifying the constraint, as above. In Listing 2, the accuracy parameter is specified as a single parameter. The Sensor template ends with the ‘#’ marker. This example describes a simple node with only one temperature sensor. For sensor nodes with multiple sensors, the sensor template can be repeated for each sensor. The same is true for parameters. The sensor node ID, as well as the 2

The observable property can be appended to the URI to form a link to a persistent internet resource that contains definitions for all observable phenomena, as defined by the Open Geospatial Consortium. 3 The parameter definition can be appended to the URI urn:ogc:def:sensor to form a link to a persistent internet resource that contains definitions for sensor parameters, as defined by the Open Geospatial Consortium. urn:ogc:def:phenomenon:OGC

1400 MoteML

User Interface

File

1200

SensorML Data File Size (byte)

MoteML Writer

1000

800

MoteML Byte Stream

600

Text Compressor

400

Compressed MoteML File

200 2000

4000

6000

8000

10000

12000

14000

16000

18000

20000

18000

20000

SensorML File Size (bytes)

Figure 1: MoteML Coding Module

4.

IMPLEMENTATION

We have implemented software to support MoteML in Java using standard libraries for processing XML. The software is divided into two logical modules: (i) the MoteML Coding Module and (ii) the MoteML Decoding Module. We use Gzip libraries for compressing MoteML files.

4.1

MoteML Coding Module

Figure 1 shows the basic components of the MoteML coding module. The module consists of three main components. The first component gathers SensorML data either by parsing an input SensorML file or from a user through a user interface. The data is then passed to the MoteML Writer to be stored in a text-based template file. The resulting file is then compressed using Gzip. We use Gzip because it generates smaller files than those generated by Bzip2, on average. The compressed file size averages approximately 350 bytes in the test cases we considered.

4.2

MoteML Decoding Module

The main function of the Decoding Module is to generate a SensorML file from a compressed MoteML file. Decoding is performed in two steps. First, the compressed file is decompressed into a byte stream. Second, the byte stream is decoded into a SensorML file following the template structure. The decoder uses a state machine to recognize templates, records within a template, and sub-records within a record.

3500

3000

MoteML-Bzip2 MoteML-Gzip Xmill-Bzip2 Xmill-PPM Xmill-Gzip XWRT

2500

File Size (byte)

name and ID of each sensor are assigned by the WSN administrator. Other fields, such as observable phenomenon (input), output, unit of measure, and the names and definitions of parameters should be explained in easily-accessible documents. These documents should be developed according to the format specified by SWE schemas in [20]. Some commonly used terms are defined by the OGC, but new fields can be added according to the specific needs of a WSN. The Platform template can be related to SensorML’s System element, and it includes the valid time and location tags within the element. The Sensor template can be translated into Component tags and placed inside the ComponentList within the System tag. Parameters of the Sensor templates can be translated into SWE’s Common Data Model elements. At present, we can only translate our parameters to DataRecord, Quantity, and QuantityRange data elements.

Figure 2: MoteML vs. SensorML File Size

2000

1500

1000

500

0 2000

4000

6000

8000

10000

12000

14000

16000

SensorML File Size (bytes)

Figure 3: Text-based vs. XML-aware Compression

5.

EVALUATION

We evaluated MoteML’s performance using a virtual system. There are some SenorML elements that are not yet supported in MoteML. Hence, not all SensorML files can be translated into MoteML files. Consequently, we were not able to locate a “live” repository of SensorML files that could be used to support our evaluation. We evaluate the performance of MoteML on a virtual testbed of 20 sensor nodes. The number of sensors on each sensor node varies from one to five, and each sensor has one input, one output, and one to three parameters. We specified the sensor nodes using both SensorML and MoteML encodings. We first compare the sizes of the resulting MoteML and SensorML files. Figure 2 summarizes the results of the comparison. The values on the x-axis represent the size of the SensorML file for each sensor node and the corresponding y-axis values represent the size of the same description in MoteML, both in bytes. Notice from the figure that MoteML text files are significantly smaller than the corresponding SensorML files. The average size of a SensorML file is almost 9K bytes with a standard deviation of 5K bytes, whereas the average size of a MoteML file is only 650 bytes with a standard deviation of 315 bytes. We next compare XML-aware compression techniques applied on SensorML files to text compression techniques applied on MoteML files. We applied XMill-Bzip2, XMillPPM, XMill-Gzip, and XWRT techniques on SensorML, and Bzip2 and Gzip on MoteML files. (We did not apply XMLaware compression on MoteML as MoteML documents are

1600

1400

6.

MoteML-Bzip2 MoteML-Gzip SensorML-Gzip SensorML-Bzip2

1200

File Size (byte)

1000

800

600

400

200

0 2000

4000

6000

8000

10000

12000

14000

16000

18000

20000

SensorML File Size (bytes)

Figure 4: MoteML vs. SensorML Text Compression

Description SensorML MoteML-text MoteML-Gzip MoteML-Bzip2 SensorML-XMill-Bzip2 SensorML-XMill-PPM SensorML-XMill-Gzip SensorML-XWRT SensorML-Gzip SensorML-Bzip2

Mean File Size (Bytes) 9379 650 265 321 1216 951 996 2483 1168 1211

Std. Dev. of File Size (Bytes) 4921 317 51 72 82 59 59 238 212 173

Table 1: Compressed SensorML vs. MoteML Files

not structured using XML.) Figure 3 shows how XML-aware compression treats SensorML files and how the resulting files compare with MoteML compressed using standard text compression. The x-axis represents the size of each SensorML file, and the y-axis represents the size of the compressed document, both in bytes. Notice from the figure that applying Bzip2 and Gzip compression techniques on MoteML files generated the smallest files. Our next step was to compare text-based compression techniques when applied on SensorML and MoteML files. Figure 4 illustrates the results of our evaluation. The x-axis represents the size of each SensorML file, and the y-axis represents the size of the corresponding compressed file, both in bytes. Notice from the figure that applying Gzip compression techniques on MoteML files resulted in the smallest compressed files. Finally, we compared the mean and standard deviation of compressed SensorML and MoteML files with the corresponding input SensorML file. Our comparisons are shown in Table 1. From this table, we notice that the MoteMLGzip and MoteML-Bzip2 mean file sizes are at most a third of the mean SensorML compressed file sizes (text-based or XML-aware). XMill-PPM provided the best XML-aware compression of SensorML and produced a compressed file of size 951 bytes. This is still larger than the mean uncompressed MoteML text file of size 650 bytes. Hence, we can summarize that using MoteML to store self-describing data on memory-constrained devices is more efficient than using compressed SensorML files. In summary, our evaluation results confirm that compressed MoteML files are significantly smaller than both simple SensorML and compressed SensorML encodings.

RELATED WORK

Prior research related to our work can be divided into three categories: (i) mapping electronic datasheets into SensorML files, (ii) compressing SensorML files to make them small enough to be stored in EEPROM, and (iii) potential uses of self-describing data available on a sensor node. The work of Hu et al. [11] falls into the first category. The authors describe the process of mapping TEDS basic template fields to SensorML and discuss the problem of mapping SensorML elements to the varying standard transducer templates. This work differs from ours, as we store SensorML data in a compressed form, using templates to save SensorML structure without imposing a size limit on the data. The work of Priyantha et al. [24] and Augeri et al. [3] falls into the second category. The authors in [24] compare XML compression schemes using methods such as XMLPPM, LZW algorithms, and XML-specific compression methods. Further, the authors consider two XML format optimizations. The first optimization involves replacing method names and argument names with compact tags. In conjunction, the second involves replacing common strings, such as namespace URLs, with compact tags. They found the second approach to be more efficient. Additional efforts to analyze XML compression efficiency are discussed in [27, 28, 32]. Augeri et al. [3] discuss the use of a binary XML format to decrease file size for use with wireless sensor networks. However, the authors found that using the binary format nullified a key benefit of using XML — interoperability. Just as we have, the authors also discuss schema-aware XML compressors such as XMLPPM and XMill. The third category of related work involves the applications of self-describing data on sensor nodes. The concept of hosting tiny web-services on sensor nodes is presented in [24]. A web-service is effectively a remote procedure call, with inputs and outputs specified using an XML-based Web Service Description Language (WSDL) [30] document. A sensor can be thought of as a measuring procedure, and its self-describing information can be used exactly as would a WSDL for a web-service. Any interested third party application can inquire about a sensor node’s capabilities and communicate directly with the sensor node, thus eliminating the need for intermediate gateways.

7.

CONCLUSION

We described the design and implementation of MoteML, a text-based encoding for sensor metadata suitable for storage on memory-constrained devices. We showed that by using the template style of MoteML, it is possible to translate sensor data into SensorML and vice-versa. Further, we compared sensor descriptions encoded in both MoteML and SensorML. Our results show that MoteML encoded files are smaller than their corresponding SensorML files. The compressed MoteML files for our test network are on the range of 200 to 390 bytes, whereas the corresponding SensorML files for the same sensor nodes are on the range of 3K to 18K. Compressed MoteML files are small enough to be stored on a typical sensor node’s EEPROM with a 2K capacity. Storing self-describing data on sensor nodes will not only enable them to identify and describe themselves to their host network, this information can be used by third party applications to obtain metadata describing sensor nodes producing data of interest.

Our future work will focus on extending MoteML by developing templates for other elements of SensorML. We are also investigating the possibility of developing a compression algorithm for MoteML which can generate compressed MoteML files that can be queried. This will in turn enable sensor nodes to respond to queries from third party systems.

Acknowledgments This work is supported by the National Science Foundation (NSF) through awards CNS-0745846 and DUE-1022941. Yvon Feaster is an NSF Graduate Research Fellow.

8.

REFERENCES

[1] S.W. Arms et al. Remotely reprogrammable wireless sensor networks for structural health monitoring applications. In Proceedings of the 11th International Conference on Computational and Experimental Engineering and Sciences, page 10pp., Irvine CA, USA, July 2004. ICCES. [2] Atmel. 8-bit microcontroller with 64k bytes in-system programmable flash. www.atmel.com/dyn/resources/ prod documents/doc2593.pdf, January 2011. (last access). [3] C. Augeri et al. An analysis of XML compression efficiency. In Proceedings of 2007 Workshop on Experimental Computer Science, pages 1–12, New York, NY, USA, 2007. ACM. [4] Bzip. bzip2 and libbzip2. http://bzip.org/, January 2011. (last access). [5] J. Cheney. XMLPPM: XML-conscious PPM compression. http://www.cs.cornell.edu/People/ jcheney/xmlppm/xmlppm.html, January 2011. (last access). [6] P. Deutsch. DEFLATE compressed data format specification version 1.3. http://www.ietf.org/ rfc/rfc1951.txt, January 2011. (last access). [7] W.L. Eastman et al. Apparatus and method for compressing data signals and restoring the compressed data signals. United States Patent 4464650, August 1984. [8] G.W. Eidson et al. The South Carolina digital watershed: End-to-end support for realtime management of water resources. In Proceedings of the 4th International Symposium on Innovations and Real-time Applications of Distributed Sensor Networks, pages 9–16, Los Alamitos CA, USA, May 2009. IEEE. [9] Gzip. The Gzip home page. http://www.gzip.org/, January 2011. (last access). [10] M. Hefeeda and M. Bagheri. Wireless sensor networks for early detection of forest fires. In Proceedings of the IEEE International Conference on Mobile Adhoc and Sensor Systems Conference, pages 1–6, Los Alamitos CA, USA, October 2007. IEEE Computer Society. [11] P. Hu. Sensor standards: Overview and experiences. In Proceedings of the 3rd International Conference on Intelligent Sensors, Sensor Networks and Information Processing, page 6pp., Los Alamitos CA, USA, December 2007. IEEE. [12] IEEE Standards Association. An overview of IEEE 1451.4 transducer electronic data sheets. http:// standards.ieee.org/develop/regauth/tut/teds.pdf, December 2010. (last access). [13] W. Li. XComp, an XML compression tool. Master’s thesis, University of Waterloo, Ontario, Canada, 2003. [14] H. Liefke and D. Suciu. XMill: an efficient compressor for XML data. In Proceedings of the 2000 ACM SIGMOD International Conference on Management of Data, pages 153–164, New York, NY, USA, May 2000. ACM.

[15] K. Lorincz et al. Mercury: a wearable sensor network platform for high-fidelity motion analysis. In Proceedings of the 7th ACM Conference on Embedded Networked Sensor Systems, pages 183–196, New York, NY, USA, November 2009. ACM. [16] G. Manzini. An analysis of the Burrows-Wheeler transform. Journal of the ACM, 48(3):407–430, May 2001. [17] R. Murty et al. CitySense: An urban-scale wireless sensor network and testbed. In Proceedings of the 2008 IEEE International Conference on Technologies for Homeland Security, pages 583–588, Washington DC, USA, May 2008. IEEE. [18] OGC Inc. Georgraphy markup language. http://www. opengeospatial.org/standards, December 2010. (last access). [19] OGC Inc. Open Geospacial Consortium. http://www. opengeospatial.org/, December 2010. (last access). [20] OGC Inc. Open GIS. http://schemas.opengis.net/, December 2010. (last access). [21] OGC Inc. Sensor Model Language. http://www. opengeospatial.org/standards/sensorml, December 2010. (last access). [22] OGC Inc. SWE common status. http://www. ogcnetwork.net/SWE Common Status, December 2010. (last access). [23] OGC Network. Sensor Web Enablement. http://www. ogcnetwork.net/SWE, December 2010. (last access). [24] B. Priyantha et al. Tiny web services for sensor device interoperability. In Proceedings of the 7th International Conference on Information Processing in Sensor Networks, pages 567–568, Washington, DC, USA, April 2008. IEEE Computer Society. [25] F. Reiss et al. Enabling real-time querying of live and historical stream data. In Proceedings of the 19th International Conference on Scientific and Statistical Database Management, pages 28–37, Washington, DC, USA, July 2007. IEEE Computer Society. [26] B.Y. Ryabko. Data compression by means of a book stack. Problems of Information Transmission, 16(4):265–269, 1980. [27] WS. Sakr. XML compression techniques: A survey and comparison. Journal of Computer and System Sciences, 75:303–322, August 2009. [28] P. Skibinski et al. Fast transform for effective XML compression. In Proceedings of 9th International Conference on the Experience of Designing and Application of CAD Systems in Microelectronics, pages 323–326, Lviv-Polyana, Ukraine, February 2007. Lviv Publishing House of Lviv Polytechnic National University. [29] P. Tolani and J. Haritsa. XGRIND: A query-friendly XML compressor. In Proceedings of the 18th International Conference on Data Engineering, pages 225–234, Washington DC, USA, February–March 2002. IEEE Computer Society. [30] W3C. Web Services Description Language (WSDL) 1.1. http://www.w3.org/TR/wsdl, December 2010. (last access). [31] G. Werner-Allen et al. Deploying a wireless sensor network on an active volcano. IEEE Internet Computing, 10:18–25, March 2006. [32] S. Zhang et al. CGT code-based XML data compression method. In Proceedings of the 2nd International Symposium on Electronic Commerce and Security, pages 456–459, Washington DC, USA, May 2009. IEEE Computer Society.