Impala: A Middleware System for Managing Autonomic, Parallel Sensor Systems

1. Impala:A Middleware System for Managing Autonomic, Parallel Sensor Systems Ting Liu and Margaret Martonosi Princeton University

2. Sensor Networks: An Emerging Style of Parallel Computing • Comprised of many distributed sensor nodes • Long-running distributed environments • Data aggregation • Distributed queries Base Station data query data data query Sensor Need for loosely-coordinated parallelism on low-capability nodes

3. CPU, Memory, Wireless Transceiver GPS Data Peer-to-Peer communication Protocol Data Base Station (car or plane) Data ZebraNet Wireless Sensor Network Current applications = protocols Future applications more complex

4. Long-Term Sensor Deployment: Needs Effective Middleware • Adaptive application software • To handle parameters • To handle device failures • Automatic software updates • Software updates inevitable • Manual updates impractical Applications Adapt Update Impala Device Software • Middleware adapts and updates apps, protocols dynamically • New protocols can be plugged in at any time • Switches between protocols can be performed at will Device Hardware External Updates

5. Roadmap • Middleware Architecture Overview: Modularity • Application Adapter: Adaptivity • Application Updater: Repairability • Evaluation • Conclusions

6. D A B D Motivation: Middleware Support for Application/Protocol Modularity Individual Protocols A A B C D B B Aggregate Protocol C Impala Layer Layered Approach Monolithic Approach • Modularity: applications independent, specialized • Correctness: individual apps vs. super-application • Ease of Updates: local changes vs. global changes • Energy Efficiency: transmit smaller program modules

7. System Architecture and Programming Model Application A Application B Application C Application D Initialize Query Packet Data Terminate Send Done Timer Application Updater Application Adapter Event Filter Device Event Packet Event Data Event Send Done Event Timer Event

8. Timeline Example of Event-based Application Programming Model Node A: Data Sender Node B: Data Receiver Time Application Impala Impala Application Timer Event Timer Event Send a peer discovery message Send a peer discovery message Packet Event Packet Event Receive B’s peer discovery message Receive A’s peer discovery message Send Done Event Send Done Event Be notified previous message is sent Be notified previous message is sent Timer Event Timer Event Send a data packet to B No data packet should send Packet Event Receive A’s data packet Send Done Event Be notified previous packet is sent Send another data packet to B Packet Event Receive A’s data packet Send Done Event Be notified previous packet is sent Timer Event Timer Event Check status Check status/switch Application query Application query Application terminate Application initialize Timer Event Timer Event Send a peer discovery message Send a peer discovery message

9. Timer Event: Send a peer discovery message Timer Event: Send a peer discovery message Packet Event: Receive B’s peer discovery message Send Done Event: Be notified previous message is sent Timer Event: Check status and switch Timer Event: Send a data packet to B Timer Event: Send a peer discovery message Timer Event: Check status but no switch Timer Event: Send a peer discovery message Send Done Event: Be notified previous message is sent Timer Event: No data packet should send Packet Event: Receive A’s peer discovery message Node A: Data Sender Node B: Data Receiver Time Application Impala Impala Application Timer Event Timer Event Send a peer discovery message Send a peer discovery message Packet Event Packet Event Receive B’s peer discovery message Receive A’s peer discovery message Send Done Event Send Done Event Be notified previous message is sent Be notified previous message is sent Timer Event Timer Event Send a data packet to B No data packet should send Packet Event Receive A’s data packet Send Done Event Be notified previous packet is sent Send another data packet to B Packet Event Receive A’s data packet Send Done Event Be notified previous packet is sent Timer Event Timer Event Check status Check status/switch Application query Application query Application terminate Application initialize Timer Event Timer Event Send a peer discovery message Send a peer discovery message

10. Impala: Adaptivity • Adaptation scenarios • Adapt to sensitive changes in parameter values • Adapt to device failures • Adaptation mechanisms • Parameter tracking • Device failure detection • Event-based adaptation • Timer event triggers parameter query • Device event triggers failure check • Both can eventually cause application switch App A App B Terminate Initiate Adapter

11. ZebraNet Characteristics Design Implications • High Node Mobility • Constrained Bandwidth • Wide Range of Updates • Incomplete Updates • Updates vs. Execution • Out of order Updates Impala: Repairability A C D B Node Update Updater On a single sensor node Full network

12. Software Modules • Each application is divided into several modules • Module version number vs. app version number • Allows selective software transmission Application A: Version 1 Application A: Version 2 Module 1: Version 1 Module 2: Version 1 Module 1: Version 1 Module 2: Version 1 Upgrade Module 3: Version 1 Module 4: Version 1 Module 3: Version 2 Module 4: Version 1 Module 5: Version 1 Module 6: Version 1 Module 5: Version 1 Module 6: Version 2

13. Stage 2 I want Module 5 from Version 3.0 Node A Node B Complete Version: 3.0 Incomplete Version: Complete Version: 1.0 Incomplete Version: 2.0 and 3.0 Stage 3 Module 5 from Version 3.0 Node A Node B Complete Version: 3.0 Incomplete Version: Complete Version: 3.0 Incomplete Version: On-demand Software Transmission for Remote Software Update Stage 1 I have Version 3.0 Node A Node B Complete Version: 3.0 Incomplete Version: Complete Version: 1.0 Incomplete Version: 2.0 I have Version 1.0 Repeat as needed … Repeat interval backs off if frequent updates not needed

14. Roadmap • Middleware Architecture Overview: Modularity • Application Adapter: Adaptivity • Application Updater: Repairability • Evaluation • Conclusions

15. Impala Prototype Implementation • Prototyped on HP/Compaq iPAQ Pocket PC Handhelds • System configuration • 206MHz CPU, 32MB flash RAM, 16MB flash ROM • Linux Familiar 5.3 and Xipaq GUI • Implementation includes • Impala layer: Adapter, Updater, Event Filter • Application layer: two application protocols

16. Prototype Implementation: Application Protocols • Flooding: Send to all neighbors found • History-based: Send only to neighbor with best “score” at delivering data to base

17. Event Processing Time Measurements • Impala events require less time than app events except for receiving a code packet Application Events Adaptation Event Update Events Send data pkt Send peer msg Send code pkt Send software req Receive code pkt App query&switch Install update Send software info

18. Efficient Network Reprogramming • Probabilistic broadcasting broadcasts to all neighbors with a probability • Impala’s on-demand transmission retains infection rate of high-probability broadcast

19. Efficient Network Reprogramming • Probabilistic broadcast continues to send useless updates • On-demand transmission caps transmissions to number of nodes

20. Adaptation Example: Improving Routing Performance • Impala adaptation achieves equal/better data homing success rate at any given radio range

21. Adaptation Example: Improving Routing Performance • Adaptation switches are infrequent even in intermediate ranges where adaptation has highest payoff

22. Conclusions • Impala: A middleware architecture for application …… • Modularity • Adaptivity • Repairability • Prototype implementation and simulations demonstrate: • Low overhead • Efficient network reprogramming • System Improvements