Wireless Sensor Networks for Habitat Monitoring: Architecture, Sensors, Energy Management, Study notes of Computer Science

Download Wireless Sensor Networks for Habitat Monitoring: Architecture, Sensors, Energy Management and more Study notes Computer Science in PDF only on Docsity! CMSC 828K: Wireless Sensor Networks Amol Deshpande University of Maryland, College Park September 4, 2007 Administrivia Introductions Summaries Text only List three questions you would have liked answers to How far are the technologies ? The assumptions don’t make sense I wish they had compared against that approach.. .. Assignments, projects 2 guest lectures end September Habitat Monitoring: System Architecture 2.2.3 Sensor network longevity Sensor networks that run for 9 months from non-rechargeable power sources would have significant audiences today. Al- though ecological studies at GDI span multiple field seasons, individual field seasons typically vary from 9 to 12 months. Seasonal changes as well as the plants and animals of interest determine their durations. 2.2.4 Operating off-the-grid Every level of the network must operate with bounded en- ergy supplies. Although renewable energy, for example solar power, may be available at some locations, disconnected op- eration remains a possibility. GDI has sufficient solar power to run many elements of the application 24x7 with low prob- abilities of service interruptions due to power loss. 2.2.5 Management at-a-distance The remoteness of the field sites requires the ability to monitor and manage sensor networks over the Internet. Al- though personnel may be on site for a few months each sum- mer, the goal is zero on-site presence for maintenance and administration during the field season, except for installa- tion and removal of nodes. 2.2.6 Inconspicuous operation Habitat monitoring infrastructure must be inconspicuous. It should not disrupt the natural processes or behaviors un- der study. Removing human presence from the study areas both eliminates a source of error and variation in data col- lection, as well as a significant source of disturbance. 2.2.7 System behavior From both a systems and end-user perspective, it is criti- cal that sensor networks exhibit stable, predictable, and re- peatable behavior whenever possible. An unpredictable sys- tem is difficult to debug and maintain. More importantly, predictability is essential in developing trust in these new technologies for life scientists. 2.2.8 In-situ interactions Although the majority of interactions with the sensor net- works are expected to be via the Internet, local interactions are required during initial deployment, during maintenance tasks, as well as during on-site visits. PDAs serve an impor- tant role in assisting with these tasks. They may directly query a sensor, adjust operational parameters, or simply as- sist in locating devices. 2.2.9 Sensors and sampling For our particular applications, the ability to sense light, temperature, infrared, relative humidity, and barometric pres- sure provide an essential set of useful measurements. The ability to sense additional phenomena, such as accelera- tion/vibration, weight, chemical vapors, gas concentrations, pH, and noise levels would augment them. 2.2.10 Data archiving Archiving sensor readings for off-line data mining and analysis is essential. The reliable offloading of sensor logs to databases in the wired, powered infrastructure is an essential capability. The desire to interactively “drill-down” and ex- plore individual sensors, or a subset of sensors, in near real- time complement log-based studies. In this mode of opera- Figure 1: System architecture for habitat monitor- ing tion, the timely delivery of fresh sensor data is key. Lastly, nodal data summaries and periodic health-and-status mon- itoring requires timely delivery. 3. SYSTEM ARCHITECTURE We now describe the system architecture, functionality of individual components and how they operate together. We explain how they address the requirements set forth in Section 2. We developed a tiered architecture. The lowest level con- sists of the sensor nodes that perform general purpose com- puting and networking in addition to application-specific sensing. The sensor nodes may be deployed in dense patches that are widely separated. The sensor nodes transmit their data through the sensor network to the sensor network gate- way. The gateway is responsible for transmitting sensor data from the sensor patch through a local transit network to the remote base station that provides WAN connectivity and data logging. The base station connects to database replicas across the internet. Finally, the data is displayed to scientists through a user interface. Mobile devices, which we refer to as the gizmo, may interact with any of the net- works – whether it is used in the field or across the world connected to a database replica. The full architecture is depicted in Figure 1. The lowest level of the sensing application is provided by autonomous sensor nodes. These small, battery-powered devices are placed in areas of interest. Each sensor node collects environmental data primarily about its immediate surroundings. Because it is placed close to the phenomenon of interest, the sensors can often be built using small and in- expensive individual sensors. High spatial resolution can be achieved through dense deployment of sensor nodes. Com- pared with traditional approaches, which use a few high quality sensors with sophisticated signal processing, this ar- chitecture provides higher robustness against occlusions and component failures. The computational module is a programmable unit that provides computation, storage, and bidirectional communi- cation with other nodes in the system. The computational module interfaces with the analog and digital sensors on the sensor module, performs basic signal processing (e.g., simple Habitat Monitoring: System Architecture Tiered Architecture sensor nodes: general purpose nodes equipped with application specific sensors Battery powered Can be retasked gateway: transmitting data from sensor patches to the base station base station: WAN connectivity and data logging Habitat Monitoring: Sensor Nodes UC Berkeley motes: Mica Single channel 916 MHz radio at 40kbps Atmel Atmega 103 microcontroller 4MHz Nonvolatile storage: 512 KB 2 AA Batteries 2.0 * 1.5 * 0.5 inches translations based on calibration data or threshold filters), and dispatches the data according to the application’s needs. Compared with traditional data logging systems, networked sensors o!er two major advantages: they can be retasked in the field and they can easily communicate with the rest of the system. In-situ retasking allows the scientists to refocus their observations based on the analysis of the initial results. Suppose that initially we want to collect the absolute tem- perature readings; however after the initial interpretation of the data we might realize that significant temperature changes exceeding a defined threshold are most interesting. Individual sensor nodes communicate and coordinate with one another. The sensors will typically form a multihop net- work by forwarding each other’s messages, which vastly ex- tends connectivity options. If appropriate, the network can perform in-network aggregation (e.g., reporting the average temperature across a region). This flexible communication structure allows us to produce a network that delivers the required data while meeting the energy requirements. We expand on energy e"cient communication protocols in Sec- tion 6. Ultimately, data from each sensor needs to be propagated to the Internet. The propagated data may be raw, filtered, or processed data. Bringing direct wide area connectivity to each sensor path is not feasible – the equipment is too costly, it requires too much power and the installation of all required equipment is quite intrusive to the habitat. In- stead, the wide area connectivity is brought to a base station, adequate power and housing for the equipment is provided. The base station may communicate with the sensor patch using a wireless local area network. Wireless networks are particularly advantageous since often each habitat involves monitoring several particularly interesting areas, each with its own dedicated sensor patch. Each sensor patch is equipped with a gateway which can communicate with the sensor network and provides connec- tivity to the transit network. The transit network may con- sist of a single hop link or a series of networked wireless nodes, perhaps in a path from the gateway to base sta- tion. Each transit network design has di!erent characteris- tics with respect to expected robustness, bandwidth, energy e"ciency, cost, and manageability. To provide data to remote end-users, the base station in- cludes WAN connectivity and persistent data storage for the collection of sensor patches. Since many habitats of interest are quite remote, we expect that the WAN connection will be wireless (e.g., two-way satellite). The components must be reliable, enclosed in environmentally protected housing, and provided with adequate power. In many environments such conditions can be provided relatively easily at a ranger station. The architecture needs to address the possibility of dis- connection at every level. Each layer (sensor nodes, gate- ways, base stations) has some persistent storage which pro- tects against data loss in case of power outage. Each layer also provides data management services. At the sensor level, these will be quite primitive, taking the form of data logging. The base station may o!er a full-fledged relational database service. The data management at the gateways will fall somewhere in between; they may o!er some database ser- vices, but perhaps over limited window of data. While many types of communication can be unreliable, when it comes to data collection, long-latency is preferable to data loss. For Figure 2: Mica Hardware Platform: The Mica sen- sor node (left) with the Mica Weather Board devel- oped for environmental monitoring applications this kind of communication, a “custody transfer” model, similar to SMTP messages or bundles [10], may be applica- ble. Users interact with the sensor network data in two ways. Remote users access the replica of the base station database (in the degenerate case they interact with the database di- rectly). This approach allows for easy integration with data analysis and mining tools, while masking the potential wide area disconnections with the base stations. Remote control of the network is also provided through the database inter- face. Although this control interface is su"cient for remote users, on-site users may often require a more direct interac- tion with the network. A small, PDA-sized device, referred to as gizmo, enables such interaction. The gizmo can di- rectly communicate with the sensor patch, provide the user with a fresh set of readings about the environment and mon- itors the network. While the gizmo will typically not take custody of any data, it allows the user to interactively con- trol the network parameters by adjusting the sampling rates, power management parameters and other network parame- ters. The connectivity between any sensor node and the gizmo does not have to rely on functioning multihop sensor network routing, instead the user will often communicate with the mote network directly, relying on single hop prox- imity. We expect that this device will be extremely useful during the initial deployment and during retasking of the network. 4. IMPLEMENTATION STRATEGIES 4.1 Sensor Network Node In our deployment, we are using UC Berkeley motes as the sensor nodes. The latest member of the mote family, called Mica [11] (shown in Figure 2), uses a single channel, 916MHz radio from RF Monolithics to provide bidirectional commu- nication at 40kbps, an Atmel Atmega 103 microcontroller running at 4MHz, and considerable amount of nonvolatile storage (512 KB). A pair of conventional AA batteries and a DC boost converter provide a stable voltage source, though other renewable energy sources can be easily used. Small size (approximately 2.0 x 1.5 x 0.5 inches). Platforms enabling the WSNs Architecture will typically be dictated by the application Expect a 4-tier architecture in many cases 42 June 2004/Vol. 47, No. 6 COMMUNICATIONS OF THE ACM sensor-network hardware, extrapolating future capa- bilities in future devices. Platform Classes Initial deployment experience has shown that sensor network systems require a hierarchy of nodes start- ing at low-level sensors and continuing up through high-level data aggregation, analysis, and storage nodes (see Figure 1). This tiered architecture is com- mon in virtually all sensor networks and is best illus- trated by example. Consider a sensor network for an advanced security sys- tem in which a majority of the sensors cover window breakage, contact closure, and motion detection. The quantity and range of locations for these simple sensors require that they be battery powered. They are complemented by a hand- ful of more advanced sensors, including cameras and acoustic and chemical detectors, placed in key loca- tions. Both simple and complex sensor data is routed over a mesh network into a building-monitoring-and- control facility that provides a continuious monitor- ing capability. The sensors placed on windows and doors for intrusion detection are examples of generic sensing devices. Their function is simple and specific and requires long-term battery operation. Moreover, their on-board processing and communication rates are minimal. In contrast, acoustic, video, and chemical sensors are examples of high-bandwidth nodes requir- ing more computational resources and communica- tion. They may, in some cases, require battery power but often need to be plugged into the public power system for long-term operation. In addition to traditional security applications, wireless sensor networks are being designed to track mobile assets, as well as personnel, through attached tiny, low-cost security tags (mini-motes). These spe- cial-purpose sensor nodes are synonymous with Smart Dust [8], or cubic-millimeter-scale devices sup- ported by extremely limited energy resources. They could trigger an alarm when an asset leaves a facility without authorization. Moreover, they must be highly integrated and very inexpensive. In security systems, the mesh network of sensors is likely to have one or more end points containing a database or other aggregation software designed to process and store individual sensor readings. These head, or gateway, nodes provide an interface into many existing types of networks. Table 1 outlines typical operat- ing characteristics of the four classes of nodes—specialized sens- ing platform, generic sensing plat- form, high-bandwidth sensing, and gateway—implemented with state-of-the-art technology. The Spec node the author Hill designed at the University of Cali- fornia, Berkeley, is representative of the special-pur- pose sensor class. It is a single-chip node designed specifically for ultra-low-cost production and low- power operation. Requiring just 2.5 mm ! 2.5 mm of silicon, it includes data RAM, processing, and communication capabilities. In order to reduce size and complexity, the Spec node was built so it would interface only with simple sensors and communicate only over short distances. The prototype versions (produced February 2003) contained only a transmit- ter (without a receiver); future versions will contain a full transceiver. The Spec node is an ideal asset tag; combined with a tiny battery, it is capable of periodi- cally reporting its presence for years to come. The Berkeley Motes are a notable example of a general-sensing-class device, used today by more than 100 research organizations. The Mica2 is the most recently developed commercially available version, constructed from off-the-shelf components to pro- vide the greatest possible flexibility (see Figure 2). It includes a large interface connector allowing its attachment to an array of sensors. By providing a large number of I/O pins and expansion options, the Web interfaces, databases Cameras, microphones Dozens of high-bandwidth sensors Door, window, motion sensors Asset tags A few gateway nodes The Internet Hundreds of generic sensor nodes Thousands of special-purpose sensors Figure 1. Hierarchical deployment of a wireless sensor network. Each platform class handles different types of sensing. Platforms enabling the WSNs Mica2 is a perfect sensor node option for any applica- tion where size and cost are not absolutely critical. It is, for example, easily connected to motion detectors and door-and-window sensors as the foundation of a building security system. Moreover, the Mica2 is capable of receiving messages from Spec nodes attached to high-value assets, including personal com- puters and laptops, at risk of being stolen. The mem- ory and processing power available on the Mica2 node easily handles the computa- tion required to keep track of several dozen Spec-based asset tags. While the Mica2 node is easily interfaced by hard- ware engineers to an array of sensors, it cannot handle the high bandwidth of data coming from complex sensors. When attempting to process video or high- bandwidth audio, the Mica2 node falls short. The iMote, developed by Intel Research (first produced in May 2003), is designed to be a high-bandwidth sensor platform, including signifi- cantly more on-chip RAM and processing power, as well as a Bluetooth-based radio capable of communi- cation rates in excess of 500Kbps. The Stargate platform developed by Intel and sold by Crossbow Technology is representative of gateway- class devices and includes a 400MHz X-scale architec- ture-based processor (also developed by Intel) with several megabytes of RAM and up to gigabytes of per- sistent storage. It is capable of interfacing directly to Mica2- and iMote-based devices and bridging the data from low-power mesh networks to traditional networks, including 802.11, Ethernet, and wide-area varieties. Moreover, the processing and memory pro- visions on the Stargate node allow it to act as a Web front-end to sensor networks where users access its data via a Web browser. The operating system running on a particular plat- form must be matched to the plat- form’s underlying hardware capabilities. For special-purpose and generic-sensor-class devices, a special operating system called TinyOS (developed at the Univer- sity of California, Berkeley) is designed to run on platforms with limited CPU power and memory space. Unlike many embedded operating systems, it provides tight integration between wireless con- nectivity and networking func- tions. However, as platform capabilities improve with, for example, the Stargate platform, more advanced operating system support is required to meet the demands of more complex applications. Multiprocessing, preemptive task switching, and even virtual memory support become desirable when managing multiple system functions. The Stargate node runs an embedded ver- sion of the Linux operating system. In addition to providing a range of system capabilities, Linux pro- vides a suite of device dri- vers for enabling gateway nodes to bridge to legacy networks. Drivers for Ethernet cards and 802.11 wireless network- ing cards are essential for allowing the gateway nodes to bridge to a range of wide-area net- working systems. Architectural Differences The overall architectures of the four sensor-network platform classes are remarkably similar despite sig- nificant differences in device capabilities. The archi- tectural similarity follows from the requirement that they seamlessly integrate wireless networking. Net- work support must be transparent and self-configur- ing to allow sensor networks to scale in size and complexity. In contrast, their core differences come COMMUNICATIONS OF THE ACM June 2004/Vol. 47, No. 6 43 Node Type Sample “Name” and Size Typical Application Sensors Radio Bandwidth (Kbps) MIPS Flash RAM Typical Active Energy (mW) Typical Sleep Energy (uW) Typical Duty Cycle (%) Specialized sensing platform Generic sensing platform High- bandwidth sensing Gateway Spec mm3 Mote 1-10cm3 Imote 1-10cm3 Stargate >10cm3 Specialized low- bandwidth sensor or advanced RF tag General-purpose sensing and communications relay High-bandwidth sensing (video, acoustic, and vibration) High-bandwidth sensing and communications aggregation Gateway node <50Kbps <100Kbps ~500Kbps >500Kbs– 10 Mbps < 5 < 0.1Mb < 4Kb < 10 < 0.5Mb < 10Kb < 50 < 10Mb < 128Kb < 100 < 32Mb < 512Kb 1.8V*10– 15mA 3V*10– 15mA 3V*60mA 3V*200mA 1.8V *1uA 3V *10uA 3V *100uA 3V *10mA 0.1– 0.5% 1–2% 5–10% >50% Table 1. Typical operating characteristics of the four classes of sensor-network nodes. External Power Connector Power Switch (Radio on back) AA Batteries External RF Connector Antenna Expansion Connector CPU Figure 2. The Mica2 node is the most popular sensor-net- work research platform. The large expansion connector allows it to be connected to a wide range of sensors. Major Challenges Hardware platforms Started with the vision of “smart dust” Cubic cm; light enough to be stay in air etc.. Power consumption still an issue Not cheap enough yet Reliability Deployments in extreme conditions Need to deal with failures/message losses etc How do these affect: Routing ? Data analysis ? Major challenges Battery power Everything comes down to it Doesn’t obey Moore’s law Alternative energy sources work only in some cases Radio communication typically most costly Though some sensors can be very expensive too Hard to measure these things In-network processing useful Push the processing close to the sensors CPU much less expensive Data Management Challenges. . . Links WSN Tutorial Glucotel Pressure sensors in the eye WSN Blog Bridge RFID