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

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

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

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 Device Hardware Device Software Impala Applications AdaptUpdate Middleware adapts and updates apps, protocols dynamically New protocols can be plugged in at any time Switches between protocols can be performed at will External Updates

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

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

Terminate System Architecture and Programming Model Application AApplication BApplication C Application Updater Application Adapter Application D Send Done Event Filter Device Event Send Done Event Packet Event Timer Event Data Event Timer Data PacketInitializeQuery

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

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

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 Adapter App B TerminateInitiate

D B Impala: Repairability High Node Mobility Constrained Bandwidth Wide Range of Updates Incomplete Updates Updates vs. Execution Out of order Updates ZebraNet CharacteristicsDesign Implications Updater Update AC Node On a single sensor node Full network

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

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

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

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

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

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

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

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

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

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

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