Ultra-Low Power Data Storage For Sensor Networks

3y ago
32 Views
3 Downloads
699.30 KB
31 Pages
Last View : 1m ago
Last Download : 3m ago
Upload by : Ellie Forte
Transcription

Ultra-Low Power Data Storage for Sensor NetworksGAURAV MATHURGoogle, Inc.andPETER DESNOYERSNortheastern UniversityandPAUL CHUKIU, DEEPAK GANESAN and PRASHANT SHENOYUniversity of MassachusettsLocal storage is required in many sensor network applications, both for archival of detailed eventinformation, as well as to overcome sensor platform memory constraints. Recent gains in energyefficiency of new-generation NAND flash storage have strengthened the case for in-network storageby data-centric sensor network applications. We argue that current storage solutions offering asimple file system abstraction are inadequate for sensor applications to exploit storage. Instead, wepropose Capsule – a rich, flexible and portable object storage abstraction that offers stream, file,array, queue and index storage objects for data storage and retrieval. Further, Capsule supportscheckpointing and rollback of object state for fault tolerance. Our experiments demonstrate thatCapsule provides platform independence, greater functionality and greater energy-efficiency thanexisting storage solutions.Categories and Subject Descriptors: B.7.1 [Integrated Circuits]: Hardware—Types and Design Styles – Memory Technologies; B.8.2 [Hardware]: Performance and Reliability—Performance Analysis; D.4.2 [Software]:Operating Systems—Storage ManagementGeneral Terms: Design, Measurement, Performance, ExperimentationAdditional Key Words and Phrases: storage system, flash memory, energy efficiency, objects, filesystem, sensors, embedded systems1.INTRODUCTIONStorage is an essential ingredient of any data-centric sensor network application. Commonuses of storage in sensor applications include archival storage [Li et al. 2006], temporarydata storage [Hellerstein et al. 2003], storage of sensor calibration tables [Madden et al.2005], in-network indexing [Ratnasamy et al. 2002], in-network querying [Ratnasamyet al. 2001] and code storage for network reprogramming [Hui and Culler 2004], amongPreliminary versions of this work appear in proceedings of the ACM Conference on Embedded NetworkedSensor Systems (SenSys 2006), Boulder, CO, November 2006, and the IEEE/ACM Conference on InformationProcessing in Sensor Networks (IPSN/SPOTS), Nashville TN, April 2006.Permission to make digital/hard copy of all or part of this material without fee for personal or classroom useprovided that the copies are not made or distributed for profit or commercial advantage, the ACM copyright/servernotice, the title of the publication, and its date appear, and notice is given that copying is by permission of theACM, Inc. To copy otherwise, to republish, to post on servers, or to redistribute to lists requires prior specificpermission and/or a fee.c 2000 ACM 0000-0000/2000/0000-0001 5.00ACM Transactions on Sensor Networks, Vol. 0, No. 0, 0 2000, Pages 1–31.

·2Gaurav Mathur et al.Table I. Comparison of Capsule to related elingNoCheckpointingNoAbstractionUsage systemObjectFile storage; Calibration TablesStream Storage andIndexingSame as MatchboxPortable ry Arraysothers. A primary consideration in these applications is the problem of energy efficiency,which has been addressed by a significant fraction of the research in this area. Due tothe high relative energy cost of network communication in wireless sensor networks—transmitting a single bit may require as much energy as hundreds of instructions [Hill et al.2000]—this work has often focused on in-network aggregation and data fusion to reduceradio traffic. This computation vs communication trade-off [Pottie and Kaiser 2000] hashad a tremendous influence on the design of both algorithms and platforms for sensor networks. However, the emergence of a new generation of NAND flash storage has added anew variable to this design equation, as sufficient amounts of storage may be used to reduce network traffic by updating the application lazily, deferring transmission of a datumuntil we are confident that it will be needed by the application. At least one recent studyhas shown that certain forms of flash storage have combined (write read) per-byte energycosts two orders of magnitude less than total per-byte energy costs (transmit receive) forlow-power radio transmission [Mathur et al. 2006b]. This development challenges existingsensor network design principles, motivating a new set of principles based on trading offnot only local computation but local storage as well in order to reduce radio usage andthereby optimize system performance and lifetime.The emergence of low-cost high-capacity flash storage prompts us to ask: How can asensor network storage system be designed to minimize total energy costs for varied sensorapplications? To do this we require a storage system which can provide services tailoredto the application, so as to minimize redundant or unnecessary work performed by theapplication or storage system. This in turn requires a flexible and tunable storage system,which may be adapted to the needs of varied applications for archiving, indexing, andquerying.1.1Limitations of Existing Flash Storage SystemsOur survey of existing storage solutions (Table I) shows a mismatch between the featuresthey offer and the requirements of sensor applications. We describe in more detail belowthe limitations we find in these existing sensor storage solutions; to overcome the limitations of these solutions, we develop a new object-based storage system, Capsule, offeringrich functionality and flexibility without compromising energy efficiency.Mismatch between storage abstraction and application needs: Many flash-based storagesystems, such as YAFFS, YAFFS2 [Manning 2002], Matchbox [Gay 2003] and ELF [Daiet al. 2004], provide a byte-structured file system abstraction to the application. While theACM Transactions on Sensor Networks, Vol. 0, No. 0, 0 2000.

Ultra-Low Power Data Storage for Sensor Networks·3traditional rewritable file has come to dominate traditional computing, it often lacks features needed by some sensor applications, or incurs extra operations to implement properties not needed by others. For instance, a common use of local storage is to store a timeseries of sensor observations and maintain a index on these readings to support queries. Ifimplemented over a byte-structured rewritable file, any overhead needed to provide rewritecapabilities would be wasted, while each application would need to to independently implement both log and index structures. An integrated indexed data stream abstraction,however, would allow multiple applications to take advantage of a single implementation,while that implementation could be carefully tailored to the system storage characteristics.At least one existing system, MicroHash [Zeinalipour-Yazti et al. 2005], provides suchan abstraction. Yet just as a file abstraction is poorly suited to some sensor applications,an indexed stream is poorly suited to others. Examples include “live” application data,where storage is being used as an extension of device memory, calibration tables, andconfiguration data, to name a few. In these cases, yet other storage abstractions may be bestsuited to the application’s requirements. Rather than advocate a single storage abstractionfor all of these cases, we argue that the storage substrate should support a “rich” objectstorage abstraction with the ability to create, store and retrieve data objects of varioustypes such as files, streams, lists, arrays, and queues, enabling effective use of flash storageby the widest range of applications.Lack of Portability: Most existing storage solutions have been designed to operate onlyon a specific type of flash memory – for example, both Matchbox and ELF require capabilities found only in NOR flash but not in NAND. Further, sensor applications written forthe same flash memory type do not seamlessly work across different hardware platforms;for example, Matchbox relies on features of a specific flash device, which are not availablein most other devices. Capsule, on the other hand, supports portability across both NORand NAND flash memories, as its design was based on the subset of features common toboth these types of flash memories. It organizes the flash as a log and employs a flashabstraction layer to hide the details of the specific flash being used, allowing the higherCapsule layers to be used without any modification on virtually any flash memory.Lack of Support for Use as a Backing Store: Current flash-based storage systems useflash as a persistent data storage medium. However, memory is often a scarce commodityon small sensor platforms, with Telos and Mica motes containing 10KB and 4KB of RAM,respectively. With empirical studies showing the energy cost of accessing data in flashbecoming nearly as low as for data in RAM, it is now possible for applications to usehigher-capacity flash for storing live application data and manipulating it in an energyefficient manner. For instance, tasks can use flash as a form of backing store to storelarge data structures, as well as intermediate results for data processing tasks, enabling theimplementation of local data processing algorithms that manipulate data sets larger thanthe size of RAM.Files, however, typically do not provide the appropriate storage abstraction for this purpose. It may be nearly impossible to map the data structures of some applications ontoappend-only streams as provided by e.g. Matchbox, while mapping to rewritable bytestructured files may still be difficult and inefficient. Instead we argue that a richer storageabstraction will allow computational structures to map more easily onto storage, resultingin decreased complexity and increases in efficiency.Incompatibility with Energy and Memory Constraints: Energy efficiency and the smallACM Transactions on Sensor Networks, Vol. 0, No. 0, 0 2000.

4·Gaurav Mathur et al.Atmel NOR – 0.5MBHitachi MMC – 128MBTelos NOR – 1 MBMicron NAND – 128MBPer-byte storage cost a2Operations measuredwrite readerase write readwrite readerase write readTable II. Total (device platform) amortized per-byte energy consumption of selected flash memories. Dataapproximates the average energy needed by the system to store a single byte of data to flash and retrieve it once.amount of available memory are key constraints of tetherless sensor platforms – consequently, the storage subsystem for sensor platforms must optimize both constraints. Incontrast, traditional non-sensor storage systems have been optimized for bandwidth andaccess latency, with little regard for memory usage or energy. NAND-flash based file systems such as YAFFS [Manning 2002] are difficult to use on sensor platforms, due to theirlarge RAM footprint. And even in explicitly energy-aware non-sensor file systems, suchas BlueFS [Nightingale and Flinn 2004], the target energy usage is far higher than can besustained by long-lived sensor platforms.Among existing approaches designed specifically for sensor devices, only MicroHash[Zeinalipour-Yazti et al. 2005] makes claims about energy efficiency. MicroHash, however,requires more memory than is feasible on the sensor platforms which we target, as well asbeing restricted to a subset of the Capsule functionality.1.2Case for In-network Storage and ArchivalSemiconductor-based flash memory is now widely used in applications ranging from BIOScode on motherboards to image storage in digital cameras, and volume production is driving costs down while capacities rise. The emergence of new generations of flash memorieshas dramatically altered the capacities and energy efficiency of local flash storage. It ispossible today to equip sensor devices with several gigabytes of low-power flash storage,while available capacities continue to grow even further.Further, Table II presents a summary of the results of our detailed measurement studyof flash memories [Mathur et al. 2006b]. We notice that new generations of flash memories not only offer higher capacity, but do so at decreasing energy costs per byte stored.Equipping the MicaZ platform with NAND flash memory allows storage to be two orders of magnitude cheaper than communication, and comparable in cost to computation.(i.e. only several times more expensive than copying data in RAM.) Figure 1 comparesthe per-byte energy cost of computation, communication and storage for various sensorplatforms, and shows that the cost of storage has fallen drastically with the emergence ofefficient NAND flash memories. This observation fundamentally alters the relative costs ofcommunication versus computation and storage, making local archival on sensor platformsattractive as an alternative to communication, where it was not in the past.Based on these trends, we argue that the design of sensor network architectures shouldinclude consideration of the 3-way trade-off between computation, communication, andstorage, rather than ignoring storage as is often done today. This in turn results in the following recommendations: (i) Emphasis should be placed on in-network storage at sensors,and in particular most nodes should be equipped with high-capacity, energy-efficient localflash storage. (ii) Algorithms design should take into account the potential for cheap storage to reduce expensive communication. (iii) There is a need for an energy-efficient storagesolution that allows sensors to maximally exploit storage for in-network data storage andACM Transactions on Sensor Networks, Vol. 0, No. 0, 0 2000.

Ultra-Low Power Data Storage for Sensor Networks·5Fig. 1. Energy cost of storage compared to most energy-efficient radio (CC2420 radio) used on Mote platforms.Note that values include energy used by the CPU during device driver execution.archival; Capsule is an example of such a system.1.3Research ContributionsIn this paper we survey existing storage systems for sensor network systems, describetheir shortcomings for sensor applications, and propose Capsule, which overcomes thesedrawbacks. We then present the design of the Capsule system, and give analysis and experimental results demonstrating its advantages. Our design and implementation providesthe following contributions over prior approaches:Object-based abstraction: Capsule provides the abstraction of typed storage objectsto applications; supported object types include streams, indexes, stacks and queues. Anovel aspect of Capsule is that it allows composition of objects—for instance, a streamand index object can be composed to construct a sensor database, while a file object canbe composed using buffers and a multi-level index object. In addition to allowing readsand writes, objects expose a data structure-like interface, allowing applications to easilymanipulate them. Storing objects on flash enables flexible use of storage resources: forinstance, data-centric indexing using indices, temporary buffers using arrays, buffering ofoutgoing network packets using queues and storing time-series sensor observation usingstreams. Furthermore, the supported objects can also be used by applications to store livedata and thereby use flash as an extension of RAM.Portability across Flash Devices: Capsule has been designed assuming only the common characteristics of both NAND and NOR flash memories. It employs a flash abstractionlayer that uses a log-structured design to hide the low-level details of flash hardware fromapplications, allowing Capsule to function on any flash memory.Energy-efficient and memory-efficient design: While traditional storage systems are optimized for throughput and latency, Capsule is explicitly designed for energy- and memoryconstrained platforms. Capsule achieves a combination of very high energy-efficiency anda low memory footprint using three techniques: (a) a log-structured design along withwrite caching for efficiency, (b) optimizing the organization of storage objects to the typeof access methods, and (c) efficient memory compaction techniques for objects. While itslog-structured design makes Capsule easy to support on virtually any flash storage media,this paper focuses on exploiting the energy efficiency of NAND flash memories.ACM Transactions on Sensor Networks, Vol. 0, No. 0, 0 2000.

6·Gaurav Mathur et or DBCalibrationDebuggingStream-IndexStack QueueStreamIndexFileCheckpointObject Storage LayerCompactionLog-structuredFlash Abstraction LayerNORFlashNAND flashNAND SD CardFlash storage devicesFig. 2.Object Storage architectureHandling Failures using Checkpointing: Sensor devices are notoriously prone to failuresdue to software bugs, system crashes, as well as hardware faults due to harsh deploymentconditions. Capsule simplifies failure recovery in sensor applications by supporting checkpoints and rollback—it provides energy-efficient support for checkpointing the state ofstorage objects and the ability to rollback to a previous checkpoint in case of a softwarefault or a crash.To evaluate the effectiveness of the Capsule design, we have augmented Mica2 Moteswith a custom-built board allowing the use of external NAND flash, and have implementedCapsule in TinyOS with an option to use either the Mica2 NOR flash memory or ourcustom NAND flash board. We perform a detailed experimental evaluation of Capsuleon our storage-centric camera sensor network to demonstrate its energy efficiency. Ourresults show that even after extensively using Capsule to store and process camera images,Capsule consumed only 5.2% of the total energy consumed by the system. In addition,we have compared our file system implementation against Matchbox, and conclude thatnot only does Capsule provide a significantly more useful set of features, but does so withbetter performance and a better overall energy profile as well.The remainder of this paper presents an overview of the Capsule architecture in Section 2, discusses its design in Sections 3 and 4, and presents Capsule implementation andevaluation in Sections 5 and 6. Section 7 shows the use of Capsule in a storage-centriccamera sensor network, while we discuss related work in Section 8 and conclude in andSection 9.2.CAPSULE ARCHITECTURECapsule employs a three layer architecture consisting of a flash abstraction layer (FAL),an object layer, and an application layer (see Figure 2). The FAL hides the low-level flashhardware details from the rest of the object store. It provides an explicitly log-structuredstore of variable length records or chunks. Chunks are buffered as they are received fromACM Transactions on Sensor Networks, Vol. 0, No. 0, 0 2000.

Ultra-Low Power Data Storage for Sensor Networks·7the object layer and written in batches, possibly interleaving chunks from multiple objects.At read time, however, chunks may be addressed and retrieved individually. Writes donot over-write old data, but rather allocate new storage; when storage runs low, the FALtriggers a reclamation or cleaning process which explicitly garbage-collects stale data.The object layer resides above the FAL. This layer provides native and flash-optimizedimplementation of basic objects such as streams, queues, stack and static indices, and composite objects such as stream-index and file. Each of these structures is a named, persistentobject in the storage layer. Applications or higher layers of the stack can transparentlycreate, access, and manipulate any supported object without dealing with the underlyingstorage device.In addition to storage and retrieval methods for use by the application, each object classin Capsule supports efficient compaction methods that are invoked by the FAL when acleaning operation is triggered. Finally, the object layer supports a checkpointing and rollback mechanism to

Ultra-Low Power Data Storage for Sensor Networks 3 traditional rewritable file has come to dominate traditional computing, it often lacks fea-tures needed by some sensor applications, or incurs extra operations to implement proper-ties not needed by others. For instance, a common use of local storage is to store a time series of sensor observations and maintain a index on these readings to .

Related Documents:

behringer ultra-curve pro dsp 24 a/d- d/a dsp ultra-curve pro ultra- curve pro 1.1 behringer ultra-curve pro 24 ad/da 24 dsp ultra-curve pro dsp8024 smd (surface mounted device) iso9000 ultra-curve pro 1.2 ultra-curve pro ultra-curve pro 19 2u 10 ultra-curve pro ultra-curve pro iec . 7 ultra-curve pro dsp8024 .

47 117493 SCREW, mach, hex washer hd 2 48 BOX, control 276868 Ultra 395/495 1 15D313 Ultra 595 1 49 CONTROL, board, 110V 1 246379 Ultra 395/495 1 248179 Ultra 595 1 50 276882 COVER, control 1 51 15K393 LABEL, control, Graco 1 56 CORD, power 1 15J743 Ultra 395/495, Stand 1 15D029 Ultra 595, L

ample is Koala, an ultra-low power system for reliable data retrieval. Koala uses FCP to establish reliable network paths for downloading sensor data. To achieve ultra-low duty cy-cles Koala couples FCP with Low Power Probing (LPP), a novel mechanism for waking up the network. Unlike Low Power Listening (LPL), in which receivers periodically poll the channel for long preambles from senders .

Cost Transparency Storage Storage Average Cost The cost per storage Cost Transparency Storage Storage Average Cost per GB The cost per GB of storage Cost Transparency Storage Storage Devices Count The quantity of storage devices Cost Transparency Storage Storage Tier Designates the level of the storage, such as for a level of service. Apptio .

Table 3 summarizes these limitations and their implications on the behavior of the STM32L1xxxx ultra-low-power devices. Table 3. Cortex 1.1 Cortex -M3 limitation description for the STM32L1xxxx ultra-low-power devices Only the limitations described below have an impact, even though minor, on the implementation of STM32L1xxxx ultra-low-power .

TABLE OF CONTENTS: XPRESS ULTRA FIELD TERMINATION CONNECTORS SC Xpress Ultra Fiber Connectors Page 2 LC Xpress Ultra Fiber Connectors Page 3 ST Xpress Ultra Fiber Connectors Page 3 CLEANING & INSPECTION Optical Connector Contamination Pages 5 - 6 Xpress Ultra Cleaner Pages 7 - 8 Xpress Ultra Cleaner Replaceable Cartridge Page 8 Xpress Ultra

Ultra-low-power Arm Cortex -M4 32-bit MCU FPU, 100DMIPS, up to 1MB Flash, 128 KB SRAM, USB OTG FS, LCD, ext. SMPS Datasheet -production data Features Ultra-low-power with FlexPowerControl – 1.71 V to 3.6 V power supply – -40 C to 85/105/125 C temperature range – 300 nA in VBAT mode: supply for RTC and 32x32-bit backup registers – 30 nA Shutdown mode (5 wakeup pins) – 120 .

Ultra-low-power 32-bit MCU Arm -based Cortex -M0 , up to 192KB Flash, 20KB SRAM, 6KB EEPROM, USB, ADC, DACs Datasheet -production data Features Ultra-low-power platform – 1.65 V to 3.6 V power supply – -40 to 125 C temperature range – 0.29 µA Standby mode (3 wakeup pins) – 0.43 µA Stop mode (16 wakeup lines)