4.1 Light Readings (lux) Vs Time (mins) with e = 2 lux . .... Micro nodes collect low-bandwidth data and perform simple pro- ..... lowest point of the segment. 5.
Environmental Monitoring Using Sensor Networks A thesis submitted in partial fulfillment of the requirements for the degree of Bachelor of Technology and Master of Technology in Computer Science and Engineering by
Atish Dipankar 2001417
under the guidance of Prof. B.N.Jain
Department of Computer Science and Engineering Indian Institute of Technology Delhi May, 2006
Certificate This is to certify that the dissertation titled Environmental Monitoring Using Sensor Networks being submitted by Atish Dipankar for the award of Bachelor of Technology and Master of Technology in Computer Science and Engineering is a record of bona fide work carried out by him under my guidance and supervision at the Department of Computer Science and Engineering, Indian Institute of Technology Delhi. The work presented in this thesis has not been submitted elsewhere, either in part or full, for the award of any other degree or diploma.
Prof. B.N.Jain Department of Computer Science and Engineering Indian Institute of Technology Delhi
1
Acknowledgements I take this opportunity to express my sincere gratitude to my guide Prof. B.N.Jain for being supportive of my work. Without his encouragement and guidance, this project would not have taken its present shape. I would like to thank Prof. Huzur Saran for his suggestions on making the report better during the earlier presentations. I would also take this opportunity to thank Ms. Vaishali P. Sadaphal for helping me out whenever I approached her. Lastly, I would like to thank Mr. Surendra Negi who was always there to help out with all the resources.
Atish Dipankar
2
Abstract Environmental monitoring is an area of significant research in the field of Wireless Sensor Networks. It has the potential to reveal fine grained, dynamic changes in monitored variables of an outdoor landscape. A network of sensor nodes spread across a field has the capacity to provide temporal and spatial data regarding the properties of the environment. For example, sensor networks could provide precise information about crops with respect to the soil quality and water content, enabling better irrigation schedules, pesticide usage and enhancing environment protection. This project aims at incorporating data compression and aggregation techniques to a sensor network which can be deployed to monitor vital properties like temperature, relative humidity and soil moisture and then report them through a routing tree to a base station for further analysis. The fact that environmental data generally do not show rapid changes and can be approximated by linear graphs over certain periods of time has been exploited. As with all other sensor networks, the pressing issue would be to minimize communication between the nodes. For nodes belonging to a cluster with one cluster head or collator, a probabilistic scheme has been implemented for sensor nodes to send data to the collator with a given probability in less than a certain number of attempts. This would reduce the time for which the radio of the nodes is awake which in turn would prolong the network lifetime.
Contents 1 Introduction 1.1 Motivation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.2 Objective . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.3 Report Layout . . . . . . . . . . . . . . . . . . . . . . . . . . .
5 5 6 7
2 Preliminaries 2.1 Related Work . . . . . . . . . . . . . . . . . . . . . . . . . . 2.1.1 Great Duck Island Project (UCB) . . . . . . . . . . . 2.1.2 Habitat Sensing at James Reserve (UCLA) . . . . . . 2.1.3 Impact of Dryland Salinity in saline and waterlogged land (UWA and CWR) . . . . . . . . . . . . . . . . . 2.2 Key Concepts . . . . . . . . . . . . . . . . . . . . . . . . . . 2.2.1 Reactivity . . . . . . . . . . . . . . . . . . . . . . . . 2.2.2 S-MAC . . . . . . . . . . . . . . . . . . . . . . . . . 2.2.3 Hardware Used . . . . . . . . . . . . . . . . . . . . . 2.2.4 Software Used . . . . . . . . . . . . . . . . . . . . . . 2.2.5 TinyOS Message Structure . . . . . . . . . . . . . . . 2.2.6 Data Aggregation and Compression . . . . . . . . . .
. . .
8 8 8 9
. . . . . . . .
10 10 10 11 13 13 15 16
3 Design and Implementation 19 3.1 Network Architecture . . . . . . . . . . . . . . . . . . . . . . . 19 3.2 Software Architecture . . . . . . . . . . . . . . . . . . . . . . . 20
1
CONTENTS 3.3 3.4
InterNode Communication . . . . . . . . . . . . . . . . . . . . 24 Lightweight Temporal Compression . . . . . . . . . . . . . . . 28
4 Results 31 4.1 Data Sensing . . . . . . . . . . . . . . . . . . . . . . . . . . . 31 4.2 Compression and Aggregation . . . . . . . . . . . . . . . . . . 31 4.3 Sleep-Wake schedule between collator and sensor node . . . . 35 5 Conclusion 38 5.1 Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38 5.2 Future Work . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
2
List of Figures 3.1 3.2 3.3 3.4 3.5 3.6
Network Architecture . . . . . . . . . . . . . . Wiring of Components for Collator/Base Node Wiring of Components for Sensor Node . . . . Timing Diagram . . . . . . . . . . . . . . . . Graph of k Vs p for different P [5] . . . . . . Lightweight Temporal Compression [6] . . . .
4.1 4.2
Light Readings (lux) Vs Time (mins) with e = 2 lux . . . . . 33 Test network with 1 Base, 2 Collators and 5 Sensor Nodes . . 36
3
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
20 22 23 24 27 29
List of Tables 2.1 2.2 2.3
Power consumption for sensor node operations . . . . . . . . . 12 Sensor Specifications of MTS400CA Sensor Board . . . . . . . 14 Message Structure . . . . . . . . . . . . . . . . . . . . . . . . 15
4.1 4.2 4.3 4.4
Sensing Data displayed on the PC . . . . . . . . . . . . . . Collator sending aggregated readings after 30 min intervals No. of attempts of each Sensor Node . . . . . . . . . . . . No. of attempts of each Sensor Node . . . . . . . . . . . .
4
. . . .
. . . .
32 34 35 36
Chapter 1 Introduction A Wireless Sensor Network (WSN) consists of group of nodes called sensor nodes or motes. Each one of these has an embedded processor, a non volatile memory, a radio and one or more sensors. Data gathered by these sensor nodes can be utilized by a top level application like habitat monitoring, surveillance systems and systems monitoring various natural phenomenon. The use of these sensor networks has provided scientists and end users with the means to extract more detailed data, in terms of time and space, from field studies.
1.1
Motivation
Traditional efforts at monitoring environmental parameters such as soil moisture, temperature and humidity have seen remote sensing (from aircraft and satellites) and personnel using hand-held instrumentation as the main methods of data collecting. Deploying a WSN to replace these methods will improve current data acquisition techniques by providing considerably more localised measurements, thus overcoming the limitations in scope, detail and frequency of monitoring with previous sensing technologies. This will also reduce the monetary and ecological cost of personnel in monitoring areas. 5
1.2. OBJECTIVE Sensor nodes have limited battery life and in most applications are placed in remote areas which make manual intervention to replace batteries etc. very difficult. Coming years could see the cost of such nodes go down to such a level so that they would be treated as disposable, to be used only till their battery drains off. Such power constraints require any application that is built to cut down on redundant transmission and employ power saving techniques.
1.2
Objective
The objective of this project is to develop a reactive sensor network application which can be used to monitor spatial and temporal variation in environmental parameters like soil moisture, temperature and relative humidity over time. Reactivity is the ability of the network to detect changes in its environment and react accordingly. For example a rainfall should lead to increased sampling rates while on the other hand long dry periods should decrease the sampling rates of the nodes so as to conserve power. A data compression technique, namely Lightweight Temporal Compression has been incorporated to cut down on transmission costs by sending less number of data samples but at the same time maintaining a minimum level of accuracy. Furthermore, simple aggregation schemes like Sum, Average, Min and Max have been implemented on collators so as to sieve out useless or redundant data as per the needs of the particular application. The network itself would consist of clusters with collators as the cluster heads. So, there would be motes with different functionalities. Some would be leaf nodes, simply engaged at data acquisition and transferring them to the nearest gatherer, others would act as collators of such data which can double up as routers to transfer the data to the base station to be centrally analyzed and stored. To conserve power, all nodes in the network undergo 6
1.3. REPORT LAYOUT sleep-wake schedules. A probabilistic sensor node - collator communication protocol has been implemented which guarantees an expected delay in finding the collator awake when the sensor node wants to send data.
1.3
Report Layout
The rest of the report is organised as follows: Section 2 deals with similar environmental monitoring work that has been done in other universities. It also discusses the key concepts like S-MAC, Hardware, Software etc. that have been used in the project gnd gives an overview of two Data Compression techniques. The 3rd Section mentions the design and implementation of the compression algorithm and the inter node communication protocol. It also describes the network and the software architecture. Section 4 enumerates the results of the project. It shows the graphs, outputs and analysis of the programs implemented on the motes as well as the simulations done. Finally Section 5 concludes the report and gives suggestion for future work.
7
Chapter 2 Preliminaries 2.1 2.1.1
Related Work Great Duck Island Project (UCB)
A Wireless Sensor Network was designed for Great Duck Island[10] to provide a long-term, non-intrusive, habitat sustaining study of the microclimate in and around nesting burrows of the Leach Storm Petrel. The initial deployment of 32 sensor nodes using UC Berkeley’s Mica motes concentrated on sensor sampling, data collection and communication. Sensors were chosen based on functionality, high interchangeability, accuracy and start-up time. Initial results showed the choice of sensors (temperature, barometric pressure, humidity and infrared) provided the necessary end-user data. A simple communication scheme was employed where sensor nodes broadcasted data to a gateway during scheduled communication periods. This proved efficient for the small-scale network. The motes self-organize into an ad hoc wireless network and pass their data from one to another, bucket-brigade style, until the information reaches a gateway sensor above ground. Eventually, all the data makes its way to a laptop computer tucked inside the lighthouse where it is relayed to a Web site via satellite. Currently there are about 150 nodes
8
2.1. RELATED WORK and 25 weather station nodes with different functionalities forming a multi hop network.
2.1.2
Habitat Sensing at James Reserve (UCLA)
The Centre for Embedded Networked Sensing (CENS)[11] has been developing both the hardware and software for Embedded Networked Sensing Systems as well as designing projects to apply this technology. The Extensible Sensing System (EES) at the University of California’s James Reserve in the San Jacinto Mountains of southern California continuously monitors ambient microclimate below and above ground, avian nest-box interior microclimates, and animal presence in more than 100 locations within a 25-hectare study area. Individual nodes, each with up to eight sensors, are deployed along a straight line along which ecological measurements are taken, and in dense patches, crossing all major ecosystems and environments on the Reserve. Sensor data includes temperature, humidity, photo synthetically active radiation (PAR), and infrared thermopiles for detecting animal proximity. ESS is built on a Tiny Diffusion routing substrate running across the hierarchy of nodes. Micro nodes collect low-bandwidth data and perform simple processing. Macro sensors organize the patches, initiate tasking, and further process the sensor-patch data. They usually perform functions of both cluster heads and patch gateways. In case of a macro sensor failure, the routing layer automatically associates macro sensors with the nearest available cluster head. The entire system is time-synchronized and uses S-MAC medium access control for low-power operation. Data and timestamps are normalized and forwarded to an Internet publish-and-subscribe middleware subsystem called the subject server bus (SSB), through which data is multicast to a heterogeneous set of clients (such as Oracle, MatLab, and LabVIEW) for processing and analyzing both historical and live data streams.
9
2.2. KEY CONCEPTS
2.1.3
Impact of Dryland Salinity in saline and waterlogged land (UWA and CWR)
University of Western Australia (UWA) has been collaborating with the Centre for Water Research (CWR) to prototype the use of Wireless Sensor Networks in the measurement of soil moisture for research on dry land salinity[1, 3] and its management in remote areas. Such networks will be used for monitoring the effectiveness of salinity management strategies, irrigated crops, urban irrigation, and water movement in forest soils. They have deployed a prototype sensor network for soil moisture monitoring at Pinjar, just north of Perth. The network is based on Mica2 motes and MDA300CA sensor boards and uses the following components: soil moisture sampling motes, each attached to 2 x echo-20 soil moisture sensors; a rainfall monitoring mote using Decagon Echo-20 ECRN tipping bucket rain gauge; a data delivery mote, linked to a Superlite E IT GSM gateway; routing and gathering nodes for transporting soil moisture readings from the sampling nodes to the data delivery point, and rainfall information to the sampling nodes.
2.2 2.2.1
Key Concepts Reactivity
In an application such as this there would be times when changes in the environmental parameters would be negligible. Then again there might be periods of hectic activities like a heavy rainfall which can drastically change temperature, humidity and soil moisture values. The network can be made more efficient if it can react to such occurrences and increase / decrease its sampling rates depending on the conditions. There are two ways in which to implement such a scheme. The centralised approach is to have the Base station send out signals (rate message) to the sampling nodes either on an individual or on a collective 10
2.2. KEY CONCEPTS basis, to increase their sampling rates in the event of (say) a rainfall and continue doing so till the occurrence lasts. This method however would not only add to the network traffic but will also be prone to delay especially for sensor nodes far off from the Base in terms of number of hops. The distributed or local approach is the one I have used in this project. This causes sensor nodes to change their sampling rate if successive readings show a variation more than some predefined threshold and revert back to their normal rates once the event ceases to occur. This would add no extra traffic to the network and is easy to implement.
2.2.2
S-MAC
S-MAC[2] is a MAC protocol designed to address the issue of energy efficient, coordinated sleeping and so is well suitable for this application. S-MAC tries to reduce power consumption in a sensor network by cutting down on the following things:Collision, which causes retransmission. Overhearing, meaning nodes pick up packets destined for other nodes. Control packet overhead. Idle listening, that is listening to receive possible traffic that is not sent. The protocol includes four major components: periodic listen and sleep, collision avoidance by using RTS/CTS, overhearing avoidance by switching off radio and message passing to reduce control overhead. Some per hop fairness is sacrificed in turn. The power management approach designed for Berkeley mote hardware is for motes to alternate between activity and sleep states and synchronize their cycle with their neighbors. Power draw during the active period will be typically from 5 to 20 milliamps and during sleep the draw is 5 micro 11
2.2. KEY CONCEPTS amps. But since the S-MAC does not put the CPU to sleep (only the radio is put to sleep) therefore the actual power consumption during sleep state is around 8 milliamps. As far as transmission is concerned, it is not feasible to acknowledge every packet that a sensor node sends, as it would effectively double the transmission. However, if no ACK’s are used, or nodes always transmit multiple times, then significant energy may be wasted in useless transmissions. So there is a need to find a trade off like sending one feedback for (say) five packets. This ACK could contain information about the number of packets received so that on receiving the ACK the sensor node can decide on the quality of transmission and whether to send more packets in the same time slot or not. Operation Power(mV) Sensing 0.5 CPU 1 Transmitting 15 Receiving 12 Listening(Idle) 12 Sleeping 0.5 Table 2.1: Power consumption for sensor node operations Transmitting a packet requires approximately 5 times more energy than taking a sensor reading and storing it locally. Thus, minimizing the number of transmissions required is a critical step for extending the lifetime of battery powered nodes. All nodes in the network go through sleep-wake cycles in order to conserve energy. Sensing nodes wake each cycle and listen for a synchronization signal from the base. At the beginning of each waking cycle, any node which has sufficient data to report contends for a transmission path to the base station. After a few packet times, any nodes not required for data delivery return to sleep until the next global reporting round. If more than one node tries to 12
2.2. KEY CONCEPTS transmit in the same slot, the first requestor is chosen and the rest defer to one of the following slots. A duration field in each transmitted packet indicates how long the remaining transmission will be. So if a node receives a packet destined to another node, it knows how long it has to keep silent. The node records this value in network allocation vector (NAV) and sets a timer. In this way it avoids overhearing. S-MAC thus is a protocol suited for sensor network applications and parts of it have been integrated into this project to allow application development on top of it.
2.2.3
Hardware Used
The motes used for this project are the Crossbow[14, 15] MICA2 Motes along with the MTS400 data acquisition board and MIB510 programming board. MICA2 Mote (MPR410CB): It has a 7 MHz ATmega 128L microprocessor with a 10 bit ADC, 128KByte Flash Memory and a CC1000 transceiver operating at 433 MHz and a maximum data rate of 38.4 Kbps. It is powered by 2 AA batteries of 1850mAh each. MTS400CA: It is fitted with temperature, humidity, barometric pressure, light sensor and a dual axis accelerometer. Additionally the MTS420CA has a GPS module attached to it. MIB510: It is provided with a RS-232 serial cable interface and a voltage regulator capable of accepting 5-7 Volt DC and supplying 3V DC to the motes.
2.2.4
Software Used
TinyOS[13] and NesC form the core all the applications developed for the motes. The TinyOS operating system, libraries, and applications are all 13
2.2. KEY CONCEPTS Sensor Range Dual Axis Accelerometer -2g to +2g Ambient Light 0 to 1000 lux Relative Humidity 0 to 100% Temperature -40 to 125 Barometric Pressure 300 to 1100 mbar
Accuracy/Resolution 2mg at 60Hz Similar to Human Eye 3.5RH 0.5 at 25 1.5% at 25
Table 2.2: Sensor Specifications of MTS400CA Sensor Board written in NesC, a structured component-based language which is an extension of C. TinyOS is an event driven operating system designed specifically for the mica mote platform. It architecture is component based and provides a library as a set of reusable system software components which are organized in to layers, with lower layers closer to hardware and higher layers closer to the application. NesC applications are built of components with well defined interfaces. A component could be either a module or a configuration. A module implements interfaces and the configuration wires them together. Thus a TinyOS application is implemented by wiring the reusable components and also the newer ones implemented, together, as specified in a top level configuration file. TinyOS has no file system, its supports only static memory allocation, and has simple FIFO based task model. The main programs that were looked into and modified were the TOSBase, Surge and XSensorMTS400 applications. Specifically speaking TOSBase is an application that acts as a simple bridge between the serial and wireless channel, receiving packets from nodes and transmitting them through the UART to the PC. The XSensorMTS400 is a data acquisition module that periodically collects sensor data and sends them through the UART or the radio. The Surge is a self configuring multi hop network application which is supported by a set of java front end tools called Surge-View. TOSSIM[12] is a discrete event simulator for TinyOS sensor networks. It allows TinyOS applications to be compiled, run and debugged in a PC
14
2.2. KEY CONCEPTS environment which allows introducing breakpoints and running the code as many times as needed without fear of hardware damage. Besides the default debug modes like clock, route, packet, radio, adc, uart, time etc which print out a lot of information when the code is run, TOSSIM also provides 3 user defined modes, usr1, usr2 and usr3 which can be used like normal cout statements as in C++. A typical TOSSIM application is run as follows: ./build/pc/main.exe [options] num-nodes Where num-nodes is the number of nodes for which the simulation is being done and the options typically deal with running the code for a particular time, at a particular speed, introducing errors between links, radio models etc. TOSSIM can run only one code at a time. So in my simulations of sensor nodes and a collator, the entire code had to be written as one and based on the Local Address of the motes, which is assigned by TOSSIM, they were either designated as sensor nodes or collators and then appropriate tasks were executed.
2.2.5
TinyOS Message Structure
The basic message structure of a TinyOS packet(Table 2.3) is 36 bytes by default. This includes 7 bytes of generic Active Message (AM) fields and a maximum of 29 bytes for the payload. The payload is determined by the application. The complete message structure is as shown below: 2 Dest Address
1 1 1 2 Handler Group Message Source ID ID Length Address
2 2 Counter ADC Channel
Table 2.3: Message Structure msg->data[0] : sensor id, MTS400 = 0x85,MTS420 = 0x86 15
10*2 2 Sensor CRC Reading
2.2. KEY CONCEPTS msg->data[1] : packet id = 1 msg->data[2] : node id msg->data[3] : reserved msg->data[4,5] : battery ADC data msg->data[6,7] : humidity data msg->data[8,9] : temperature data msg->data[10,11] : calword1 msg->data[12,13] : calword2 msg->data[14,15] : calword3 msg->data[16,17] : calword4 msg->data[18,19] : intersematemp msg->data[20,21] : pressure msg->data[22,23] : taosch0 msg->data[24,25] : taosch1 msg->data[26,27] : accelx msg->data[28,29] : accely Where calword1-calword4 are used for callibration of the temperature and pressure sensors, taosch0 and taosch1 are the 2 channels for the light(taos) sensor and accelx and accely are the accelerometers.
2.2.6
Data Aggregation and Compression
In-Network and In-Node data processing can significantly reduce radio communication between nodes in a sensor network in which communication is the overriding consumer of energy. There are 3 methods which reduce data sets in-network: in-network aggregation to extract important data, compression by spatial correlation, and compression by temporal correlation. Therefore, data reduction before transmission, either by compression or feature extraction, will directly and significantly increase network lifetime. Sending every bit of data up the routing tree is not a practical solution in a bandwidth 16
2.2. KEY CONCEPTS and energy constrained sensor network and is also not scalable as the number of nodes increase. Any compression algorithm that can be implemented on MICA motes must be simple, consume little CPU and require very little storage. Piecewise Linear Representation and Haar Wavelets are 2 such approaches that can successfully operate within the given constraints. Haar Wavelets are superior to other wavelets techniques in this scenario due to their low computational complexity. Haar Wavelet Compression Wavelet based compression algorithms are commonly used in image processing. Chen, Li and Mohapatra[7] employ a Haar Wavelet transformation whereby, given a sequence of readings, neighbouring elements are averaged and stored along with their differences in an array. The resulting array is called the wavelet coefficient matrix, which can be reconstructed to form the original time series. The Haar Wavelet technique, unlike the Piecewise Linear Representaion Algorithm discussed below is not a greedy one. It requires all or some set of the data series before it can begin computation. More precisely, it requires 2n readings for processing. It begins by taking every pair of neighbouring readings and calculating their average. This value is stored along with the pair’s second reading and the average. This continues for the subsequently formed arrays. The process ends when only one average remains. Example: A series (2,6,5,11) transforms to (4,8,-2,-3) Neighbouring Readings: (2,6) and (5,11) The second iteration: (4,8,-2,-3) transforms to (6,-2,-2,-3) The final array (6,-2,-2,-3) is called the wavelet coefficient matrix. From here we create the Gradient Error Tree which represents the difference between the actual readings and the computed averages. The number in each leaf 17
2.2. KEY CONCEPTS of the error tree represents the greatest error between the average and the readings it approximates. Using this tree we can eliminate elements of the coefficient matrix if its corresponding error gradient is less than some threshold value.
Lightweight Temporal Compression Lightweight Temporal Compression (LTC)[6] is a Piecewise Linear Representaion algorithm which can be easily implemented on the mote hardware as is also not very computationally exhaustive. Essentially a Sliding Window algorithm, it makes use of the observation that over a small enough window of time, samples of microclimate data are linear. It finds such windows and generates a series of line segments that accurately represent the data. So it approximates the entire dataset by piecewise linear representations. It can compress data up to 20-to-1 while introducing error on the order of the sensor hardware’s specified margin of error. Being a Greedy Algorithm, it can begin computation as soon as it receives data from the sensor. Environmental data such as temperature and humidity have the nice property that they are usually continuous in the temporal dimension and at small enough time windows are approximately linear. Hence this algorithm is particularly suited for use in such a scenario.
18
Chapter 3 Design and Implementation 3.1
Network Architecture
The architecture for this application comprises of the following:1. Sensor Nodes capable of sensing soil moisture, relative humidity and temperature 2. Routing and Gathering nodes for transporting sensor readings from the sensor nodes to the base node, and rainfall information to the sampling nodes 3. A Base node linked to a GSM Gateway / PC The entire network(Fig 3.1) has a hierarchical model formed of clusters[9] with the routers being the cluster heads responsible for dissemination of data from the cluster to the network. The leaf nodes are the ones responsible for the basic sensing operations. A cluster head exchanges its schedule with all other 1 hop neighbors (sensor nodes) by broadcasting. As shown in the next section, this minimises the awake time of the Sensor Node radios. If multiple neighbors want to talk to a node, they need to contend for the medium when the head node is listening. The contention mechanism uses RTS and CTS 19
3.2. SOFTWARE ARCHITECTURE
Figure 3.1: Network Architecture packets. The node who first sends out the RTS packet wins the medium, and the receiver will reply with a CTS packet. After they start data transmission, they do not follow their sleep schedules until they finish transmission.
3.2
Software Architecture
TinyOS[13] and NesC allows a very modular, interface based development of the application which supports a high degree of interaction between its components. NesC applications are built out of components with well-defined, bidirectional interfaces. Accordingly this application could be divided into the following three components:Sensing Activities – Light, Temperature and Relative Humidity 20
3.2. SOFTWARE ARCHITECTURE Timing Activities – Time Stamping – Timer Setting and Triggering Communication Activities – All node-node and node-serial port communication Shown below are the component graphs of the programs. The components which can either be modules or configurations are represented as elliptical figures in this section. Interfaces among the components are represented as solid arrows. Component at the arrow’s tail uses the interface and the one at the head provides it. The programs are formed by linking or wiring together several modules so that code once created can be effectively reused. As can be seen in Fig 3.2 , the main component TOSBaseM, which is a module, is wired to the TimerC component which provides it with two timers, one to turn On the Radio periodically and the other to switch it Off after sometime. In a similar way, its also wired to FramerM which takes care of all receive and send functions through the Radio as well as the UART by forming frames. The wiring for the Sensor Node in Fig 3.3 shows the TestMTS400M which is the main module, wired to the sensing components like TaosPhoto (Light Sensor), SensironHumidity (Humidity Sensor), IntersemmaPressure (Pressure Sensor), Accel and Voltage through the ADC as well as others like Leds and TimerC. It has 3 timers. One for periodically awakening the sensors to sense data and the other two for awakening the radio and turning it off after some time.
21
3.2. SOFTWARE ARCHITECTURE
Figure 3.2: Wiring of Components for Collator/Base Node
22
3.2. SOFTWARE ARCHITECTURE
Figure 3.3: Wiring of Components for Sensor Node 23
3.3. INTERNODE COMMUNICATION
3.3
InterNode Communication
Within a cluster, the sensor or the leaf nodes gather data and turn on their radio only when they need to transmit data after compression.
Figure 3.4: Timing Diagram SN: Sensor Node T1: Time after which sensor node radio is switched off if it doesn’t hear from the collator. Typically this would be about 5 seconds. T2: Mean Time after which sensor tries again to sense the channel. Ran24
3.3. INTERNODE COMMUNICATION domly distributed between T2min and T2max . T3: Time for which Collator awakens. T4: Time after which the sensor node awakens. This could vary widely depending on the conditions that are being monitored because the node awakens only when it has data to send after compression. In the simulation this was modelled as a random number between T4min and T4max . T5: Time after which Collator awakens periodically. There are 2 ways in which a sensor node S can exchange data with its nearest collator C : S stays awake and keeps on sending periodic Beacons till it finds C awake. This guarantees minimum possible latency at the cost of expending power. Both follow their respective sleep-wake schedules till they coincide. This saves power (battery) at the cost of increased latency. Since the principal aim of this application is to be used in a field monitoring scenario, in which we can allow some latency, so the primary concern is to prolong the battery and hence network lifetime. So the 2nd scheme was implemented. In this particular scheme, which is similar to the one suggested in [5] for target tracking, the sensor node sends a Sync packet whenever it is ready to send data. The probability p that the Collator is detected (is awake) when the Sensor Node senses the channel is: p=
T3 T5
(3.1)
So, the probability of failure, q = 1 - p The probability that exactly k attempts are required is pq k−1 25
3.3. INTERNODE COMMUNICATION The probability that k or fewer attempts are required is P=
k−1 X
pq i
(3.2)
i=0
Therefore, P = 1 − qk So, if P is fixed, k can be found out using the following equation: k=
log(1 − P) log(1 − p)
(3.3)
It can be seen that k is not dependent on the Sensor Node parameters, namely T1, T2 and T4. Hence, the expected maximum delay, before a Sensor Node is able to send its data to the Collator with probability P is Tmaxdelay = kT 2 On the other hand if the collator had to send Sync packet to signal its awakening, then the probability of detection by the sensor node would be very less since it would have to be awake on the particular instant the Sync is sent. Sending multiple Sync packets was also an option but the energy constraint on both the type of nodes, namely Collators and Sensor nodes lead to choosing this scheme. Pseudo-code running on the Sensor Node: event timeElapsed() { call stopSleeping(); call sampleSensor(); call storeReading(); call CompressData(); if(ready_to_send){ 26
3.3. INTERNODE COMMUNICATION
call turnRadioOn(); call sendSYNC(); if (RTS received) { call SendPacket(dest); } call turnRadioOff(); } call startSleeping(); }
Figure 3.5: Graph of k Vs p for different P [5] Pseudo code running on the Collator: Broadcast(schedule); 27
3.4. LIGHTWEIGHT TEMPORAL COMPRESSION
event timeElapsed() { call turnradioOn(); while(!listen_time_over) { if(SYNC_received) { send(CTS); receive(DataPacket); send(ACK); } } call turnradioOff(); }
3.4
Lightweight Temporal Compression
Lightweight Temporal Compression was implemented as it has the following advantages: It can begin computation as soon as it receives data from the sensors unlike the Haar Wavelet approach. Environmental data such as temperature and humidity tend to follow linear pattern over small intervals. It has O(1) memory requirements. It runs in O(n) time for n data points. The algorithm is as follows:1. Get the first data point, store into z. Get next data point (t2, v2), use it to initialize limits UL(t2, v2+e) and LL (t2, v2-e). 2. Calculate the highLine to be the line connecting z and UL. 28
3.4. LIGHTWEIGHT TEMPORAL COMPRESSION
Figure 3.6: Lightweight Temporal Compression [6] 3. Calculate the lowLine to be the line connecting z and LL. 4. Get next data point. Transform the point to a vertical segment using the margin e. Let ul be the highest point of the segment. Let ll be the lowest point of the segment. 5. If highLine is below the ll or if the lowLine is above the ul then goto 9, else continue onto the next step 6. If highLine goes above ul then set UL to be ul. 7. If lowLine goes below ll then set LL to be ll. 8. Goto 2. 9. Cap off: output z to the output data stream. 10. Set z to be the point midway between UL and LL. 11. Set UL to be ul. 12. Set LL to be ll. 13. Goto 2 29
3.4. LIGHTWEIGHT TEMPORAL COMPRESSION Because the algorithm only needs to keep track of the starting point, the upper limit, the lower limit, and the new data segment’s limits, its memory requirements are constant i.e. O(1). In addition, the amount of work needed to process a single new point is bounded by some constant number of steps. Therefore, to examine n points takes O(n) time. The storage and computational complexity of LTC is equivalent to linear least squares. In the worst case the number of points that are outputted is no more than n and occurs when no line can be fit between more than two successive points.
30
Chapter 4 Results 4.1
Data Sensing
The first part of the project was to get the sensor nodes working along with the sensor boards. So a single hop network was created with 1 Base node connected to the PC through the UART and 4 nodes as sensor nodes. There was no sleep scheduling or MAC and all the nodes stayed ON all the time. The data gathered was sent to the Base node which in turn transfered it over the UART to be displayed on the PC. The sensor nodes were also programmed to change their sampling rates if successive readings showed a difference greater than some predefined threshold. The normal sampling rate was once every 15 mins which changed to once every 5 mins if the light readings changed by more than 20 lux.
4.2
Compression and Aggregation
The next step was to implement the LTC Algorithm as explained earlier making use of light readings from the sensors and varying them to test the algorithm and its performance. I chose to use light readings because they could be easily varied unlike temperature or humidity values. Light readings 31
4.2. COMPRESSION AND AGGREGATION MTS400 Health: node id Battery: Humidity: Temperature: Pressure: Light: Health: node id Battery: Humidity: Temperature: Pressure: Light:
Sensor Data =1 = 2658 mv = 30 % = 27 = 984 mbar = 477.940002 lux =2 = 2898 mv = 30 % = 27 = 983 mbar = 426.420013 lux
Table 4.1: Sensing Data displayed on the PC are calculated in Lux and can vary from 0 to 1000. I carried out the test with one sensor node for about 2-3 hours and varied the light conditions a little bit. I kept the margin of error as 5 Lux and then 2 Lux and as expected the former achieved more data compression than the latter but at the cost of lesser accuracy. From the graph (Fig 4.1) it can be seen that whereas the original data set had 40 points, the compressed one has only 14. When the variation is minimal (as is between 5 to 40 mins) it can be approximated with a single line (2 points). The algorithm also efficiently captures regions of high activity and frequent variations (as in between 110 to 145 mins) without any loss. I have kept the error margin at 2 lux which can be changed depending on the type of data we are measuring and the accuracy we require in our application. Most of the sensors come with a predefined error margin which can be used to decide the accuracy of measurement. I then conducted further tests using both light and temperature as the varying parameters. For both, sensor nodes were placed in the lab for about a 12 hour period from 9 A.M to 9 P.M. For the temperature, the error margin was kept at 1 . For light it was 5 lux. Experimentation in the open was 32
4.2. COMPRESSION AND AGGREGATION
Figure 4.1: Light Readings (lux) Vs Time (mins) with e = 2 lux not possible because the maximum range of the light sensor was 1000 lux while full daylight or even indirect sunlight is about 10,000 - 20,000 lux. The temperature was largely constant during the entire period showing a maximum of 28 and a minimum of 23 . Sampling was done every 5 mins. In this case the compression achieved was of the factor of 15-1 largely due to the stable nature of the data set. In the case of light, the compression was less, about 6-1. This was mainly due to the fact that light readings changed abruptly at times due to human intervention and the switching on of lights at times. Having implemented the local compression scheme, the next thing done was 33
4.2. COMPRESSION AND AGGREGATION Node Id 1 2 3 1 2 3
Average Light 456.32 lux 432.97 lux 486.64 lux 477.87 lux 430.32 lux 467.71 lux
Max Light
Min Light 375.47
523.86 lux 490.05 lux 375.47
Table 4.2: Collator sending aggregated readings after 30 min intervals to assimilate and filter out some data at the collator level. This could be done by applying any one of the operators like Average, Sum, Maximum or Minimum on the data which was coming to the collator. So depending on the latency we could allow our application, the collator would gather and store data till that time and then send out an aggregated result instead of sending the entire data stream thus saving on energy. For this particular application, I allowed the collator to receive data for 30 minutes and then Average out the various readings like Light, Temperature etc. for each of the nodes and then send only 1 data packet per node. Since Light readings were the easiest to manipulate, I have shown only the light readings. The packet sent by the Collator after 30 minutes would contain 3 fields: The Average reading The Maximum reading The Minimun reading The minimum or the maximum field would be valid for a node only if amongst its peers (sensor nodes reporting to the same collator) it had the minimum or the maximum reading in the given time interval.
34
4.3. SLEEP-WAKE SCHEDULE BETWEEN COLLATOR AND SENSOR NODE Node ID Average Maximum Minimum S1 4 12 1 S2 4 13 2 S3 4 10 1 S4 4 9 1 S5 3 10 1 Table 4.3: No. of attempts of each Sensor Node
4.3
Sleep-Wake schedule between collator and sensor node
Simulation was done for a test network as shown in Fig 4.2. The various simulation parameters are as follows:C1: Switched On every 44 secs and stays On for 10 secs. C2: Switched On every 50 secs and stays On for 10 secs. S1, S2, S3: Randomly awaken between 10 and 30 secs to sense channel for 5 secs and send data to C1 if awake. S4, S5: Randomly awaken between 10 and 30 secs to sense channel for 5 secs and send data to C2 if awake. The simulation was run for 1 hour and the results are as follows: For both C1 and C2, the probability p, to find it awake is about 0.20. Theoretically, this puts the maximum number of attempts at around 18 for P = 0.99 and around 7 for P = 0.50 So, since the average attempts = 4 (Table 4.3) and mean time between successive attempts is 20 seconds (random number between 10 and 30), we can say that the expected delay in transmitting a packet = 4*20 = 80 seconds. Next, the simulation parameters were changed to reflect a more realistic 35
4.3. SLEEP-WAKE SCHEDULE BETWEEN COLLATOR AND SENSOR NODE
Figure 4.2: Test network with 1 Base, 2 Collators and 5 Sensor Nodes
Node ID Average Maximum Minimum S1 6 15 2 S2 6 12 2 S3 5 14 1 S4 4 10 2 S5 4 8 1 Table 4.4: No. of attempts of each Sensor Node
36
4.3. SLEEP-WAKE SCHEDULE BETWEEN COLLATOR AND SENSOR NODE field monitoring scenario and it was run for about 12 hours. (Table 4.4 ) C1: Switched On every 8 mins and stays On for 2 mins. C2: Switched On every 10 mins and stays On for 3 mins. S1, S2, S3: Randomly awaken between 10 and 30 mins to send data. Sense channel for 5 secs and send data to C1 if awake. If C1 is not awake then switch off radio for a random time between 1 and 5 mins and keep repeating till C1 is detected. S4, S5: Same as above. Only they do it for C2 and not C1. Here, for C1, p = 0.25 and for C2, p = 0.33. So theoretically, the maximum number of attempts for P = 0.99 is about 17 and 12 respectively. Once again the maximum number of attempts were found to be just below the theoretical limit whereas the average attempts showed a slight increase from the earlier case even though the p had increased. For S1, S2 and S3 the mean expected delay is 6*3 (random number between 1 and 5) = 18 mins and for S4 and S5 it is 4*3 = 12 mins. Further experimentation by changing the parameters revealed that for the same value of p = T3/T5 (Fig 3.4), the average number of attempts tend to go up even if T3 and T5 increase in the same proportion. So it’s better to have the Collator wake up after short intervals and remain awake for some time rather than waking up after long intervals (say hours) and remaining awake for a proportionately longer period of time. Similarly, since the average delay in sending a packet is a product of the average number of attempts and the mean time between successive attempts, it’s a better ploy for the sensor nodes to frequently check for the collator being awake, rather than wait for a long period of time before sending another Sync packet.
37
Chapter 5 Conclusion 5.1
Summary
In this project, I have implemented a data compression algorithm, Lightweight Temporal Compression on the MICA2 motes which is especially suited for climatic data. This reduces the amount of data that the sensor node has to send during periods of little or no change, considerably and at the same time ensures that all significant changes are reported. The tests were carried out in the Ernet Lab and Light and Temperature were chosen as the parameter to be varied. Results of several tests showed that on an average, compression of about 15-1 was achieved with temperature and that of 6-1 was achieved with light. At the Collator level, 3 operators, Average, Max and Min were applied to data coming in every 30 minutes and an aggregated packet was sent out. This filtered out information redundant to the application. Lastly, a probabilistic sensor node - collator scheme was analysed and simulated which allows nodes to follow their individual sleep-wake cycles and detect each other’s presence with a certain probability P in k or fewer attempts. All of these introduce some latency in data transmission from the sensor node 38
5.2. FUTURE WORK to the collator and with increasing number of hops this would increase. But the primary concern in such applications as environmental monitoring is to prolong the network lifetime and not so much develop a real time or near real time application. So decreasing the amount of data transmitted and the time for which the radio of the nodes is awake was my primary motive.
5.2
Future Work
The application could be field tested in an open field using soil moisture and humidity sensors to analyse the efficiency of LTC in real life conditions and the amount of compression it achieves for different kind of data sets which vary differently over time. For instance, it would be interesting to see with soil moisture sensors, if the algorithm can capture events of high activity like watering or rainfall and how much compression it achieves during dry periods. The inter node communication scheme could be implemented on the motes and tested to see how it behaves and its impact on increasing network lifetime.
39
Bibliography [1] Rachel Cardell-Oliver, Keith Smettem, Mark Kranz, and Kevin Mayer, Field testing a wireless sensor network for reactive environmental monitoring, International Conference on Intelligent Sensors, Sensor Networks and Information Processing, Melbourne, (December 2004), IEEE [2] Wei Ye, John Heidemann, and Deborah Estrin. Medium Access Control with Coordinated Adaptive Sleeping for Wireless Sensor Networks, IEEE/ACM Trans. Netw., vol. 12, no. 3, pp. 493–506, 2004. [3] Rachel Cardell-Oliver. ROPE: A Reactive, Opportunistic Protocol for Environment Monitoring Sensor Networks, In The Second IEEE Workshop on Embedded Networked Sensors, 2005. EmNetS-II. (May 2005), IEEE. [4] Robert Szewczyk, Eric Osterweil, Joseph Polastre, Michael Hamilton, Alan Mainwaring, Deborah Estrin. Habitat Monitoring With Sensor Networks, Communications of the ACM, Volume 47,Issue 6 (June 2004). [5] Vaishali Sadaphal, Bijendra Jain. Target Aware Sleep Schedules in Sensor Networks, The 17th Annual IEEE International Symposium on Personal, Indoor and Mobile Radio Communications (PIMRC ’06) [6] T. Schoellhammer, B. Greenstein, E. Osterweil, M. Wimbrow, and D. Estrin.Lightweight temporal compression of microclimate datasets wire-
40
BIBLIOGRAPHY less sensor networks, Proceedings of 29th Annual IEEE International Conference on Local Computer Networks, pages 516-524. IEEE, 2004 [7] Chen H., Li J., and Mohapatra. P.Race: Time series compression with rate adaptivity and error bound for sensor networks., Proceedings of the 2004 IEEE International Conference on Mobile Ad-hoc and Sensor Systems (2004), IEEE, pp. 124- 133. [8] Mark Moss, School of Computer Science and Software Engineering, The University of Western Australia. Evaluation of Event-Aware Environmental Data Compression Schemes for Wireless Sensor Networks [9] Feng Zhao, Leonidas J. Guibas. Wireless Sensor Networks: An Information Processing Approach, Morgan Kaufman Publishers. [10] GreatDuck Island, www.greatduckisland.net [11] Habitat Sensing at James Reserve (CENS), www.cens.ucla.edu/Research/Applications/habitatsensing.htm [12] Philip Levis and Nelson Lee. TOSSIM: A Simulator for TinyOS Networks. [13] TinyOS tutorial, www.tinyos.net/tinyos-1.x/doc/tutorial [14] Xbow MPR-MIB Series Manual, www.xbow.com [15] Crossbow Wireless Sensor Networks Getting Started Guide. Crossbow Technology Inc., 1 edition, 2004.
41
