Presentation is loading. Please wait.

Presentation is loading. Please wait.

Implementing Software on Resource- Constrained Mobile Sensors: Experience with Impala and ZebraNet Ting Liu Christopher M. Sadler Pei Zhang Margaret Martonosi.

Similar presentations


Presentation on theme: "Implementing Software on Resource- Constrained Mobile Sensors: Experience with Impala and ZebraNet Ting Liu Christopher M. Sadler Pei Zhang Margaret Martonosi."— Presentation transcript:

1 Implementing Software on Resource- Constrained Mobile Sensors: Experience with Impala and ZebraNet Ting Liu Christopher M. Sadler Pei Zhang Margaret Martonosi Depts. Of Electrical Engineering and Computer Science Princeton University

2 ZebraNet: Fusing Mobile Computing and Sensor Systems Data Base station (car or plane) Data Store-and-forward communications Data Tracking node with CPU, FLASH, radio and GPS Sensor Network AttributesZebraNetOther Sensor Networks Node mobilityHighly mobileStatic or moderate mobile Communication rangeMilesMeters Sensing frequencyConstant sensingSporadic sensing Sensing device powerHundreds of mWTens of mW

3 Software Design Rationales Layer 1 Layer 2 Layer 3 Layer 4 Layer 5 Layer 6 Layered approach: Question One: System Layering Single Software System Monolithic approach: Software modularityLayering overhead Hardware Impala Applications Middle ground

4 Software Design Rationales Limited services:Overloaded services: Question Two: Middleware Weight application simplicityMiddleware overhead Hardware Impala Applications Middle ground Hardware Mini-Middleware Applications Hardware Super-middleware Applications

5 Impala Overview AdapterUpdater Network Support Operation Scheduler Event Filter Application modularity, simplicity, adaptivity and repairability Software adaptation for sensor network performance Software update for sensor network deployment Operation scheduling for regular operations Event handling for irregular events Network support for sensor network communications

6 This Paper AdapterUpdater Network Support Operation Scheduler Event Filter Application modularity, simplicity, adaptivity and repairability Prototyped on iPAQs PPoPP 2003: Operation, event, network This Paper: Adaptation and update Implemented on ZebraNet node

7 Roadmap Hardware design and constraints Problem 1: Complex hardware realities Solution: Layers and interfaces Problem 2: Miscellaneous system activities Solution: Operation scheduling and event handling Problem 3: Special communication needs Solution: Messages models Problem 4: Limited communication resources Solution: Networking strategies Conclusions

8 Memory constraint Energy constraint Device access constraint Radio packet size constraint GPS sensing time constraint FLASH storage constraint Microcontroller TI MSP430F149 16-bit RISC 2KB RAM 60KB ROM 8MHz/32KHz dual clockFLASH ATMEL AT45DB041B 4Mbit 78 days data capacity GPS µ-blox GPS-MS1E 10-20s position fix time Radio MaxStream 9Xstream 902-928MHz 19.2Kbps over-the-air 0.5-1mile transmit range Power supplies SPI 667Kbps USART 38.4Kbps USART 38.4Kbps Solar modules 5V3.3V Charging circuits Hardware Design and Constraints System Mode Power CPU at 32KHz9.6 mW CPU at 8MHz19.32 mW 8MHz w/ GPS568 mW 8MHz w/ radio transmit780 mW 8MHz w/ radio receive312.4 mW Power Measurement (4.0V applied)

9 Problem 1: Complex Hardware Realities Solution: Layers and Interfaces RadioGPSFLASHTimerCPUWDT Access and Control to All Devices Application 1Application 2Application 3Application 4 GPS Data Event Radio Packet Event Timer Event Asynchronous Network Transmission Protected FLASH Access Application Timer Control GPS Data Event Handler Application Timer Event Handler Network Packet Event Handler Network Send Done Event Handler System Clock Time Read AdapterUpdater Network Support Operation Scheduler Event Filter

10 Memory Footprint of Impala Layers

11 Problem 2: Misc System Activities Solution: Regular Operation Scheduling 45 12 3 78 6 Networking Period GPS Sensing Period Sleep Period 1 CPU wake up/Radio, FLASH power on 2 Radio transmitting / receiving start 3 Network communication time 4 Radio power off/FLASH power off 5 GPS power on 6 GPS sensing time 7 GPS power off / FLASH power on 8 CPU sleep / FLASH power off GPS-aided operation synchronization Prohibited simultaneous device operations Non-trivial radio wake-up time Potentially long GPS sensing time Stringent energy budget

12 Operation Scheduling Overhead Scheduling TypeImpala Activity Time (cycles) CPU Scheduling To put CPU on the full-speed clock3127 To put CPU on the slow clock38 Radio and FLASH Scheduling To set up the first transmission time and turn on radio and FLASH50 ms To set up the next transmission time260 To set up the network cleanup time265 To clean up incomplete network messages, power off radio and FLASH, and set up the next networking period 11 ms GPS Scheduling To initiate GPS sensing and set up its finish time1247 To format GPS data, power off GPS, signal an GPS data event, and set up the next GPS sensing period 2550

13 Problem 2: Misc System Activities Solution (cont.): Handling Irregular Events Impala Abstract Application Events Miscellaneous Hardware Interrupts Issue One: Event Abstraction Short / atomic hardware interrupts Long / preemptive software events Idle Issue Two: Concurrency High Priority Events Low Priority Events EventSignalerEventHandler Issue Three: Event Prioritization

14 Problem 3: Special Communication Needs Solution: Message Models and Sessions Peer discovery or data 1 to 32KB One, more or unlimited destinations Data from FLASH or RAM Acknowledgment or not Connectionless Asynchronous data Sensor data Reliable Unicast Reliable Multicast ACK data Unreliable Broadcast Sensor ACK

15 Problem 4: Limited Comm Resources Solution: Unified MAC &Transport Control A sends packet 1-8 ABCDABCDABCD MAC: round-robin timeslots (w/ GPS-aided time synchronization) Transport control: detect packet loss and retransmit Unified: reduce data copy and overhead across protocol layers A sends packet 1-8 to B, C, and D B acks packet 1-8 C acks packet 1-4 D silent B acks packet 1-8 C acks packet 1-4 D acks packet 1-8 A gives up C and sends packet 9-16 B acks packet 9-16 C acks packet 1-4 D acks packet 9-16

16 ZebraNet Status and Next Steps Status  January, 2004: 7 test collars deployed on zebras in Kenya. First data received: 1/19/2004 Next Steps  Refine collar design; switch to lower-energy GPS, merge Impala software update code into final collars

17 Conclusions Propose and implement Impala middleware model Solutions for hardware constraints and app req Concrete experience with real system and application Hardware Impala Applications Simple layering and rich services


Download ppt "Implementing Software on Resource- Constrained Mobile Sensors: Experience with Impala and ZebraNet Ting Liu Christopher M. Sadler Pei Zhang Margaret Martonosi."

Similar presentations


Ads by Google