Security Overview

1
ImpalaA Middleware System for Managing
Autonomic, Parallel Sensor Systems
Ting Liu and Margaret Martonosi Princeton
University
2
Sensor Networks An Emerging Style of Parallel
Computing
Base Station
data
query
data
data
query
Sensor

• Comprised of many distributed sensor nodes
• Long-running distributed environments
• Data aggregation
• Distributed queries

Need for loosely-coordinated parallelism on
low-capability nodes
3
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
Motivation Middleware Support for
Application/Protocol Modularity
Individual Protocols
A
C
B
B
A
D
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
Packet
Initialize
Query
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 Bs peer discovery message
Receive As 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 As data packet
Send Done Event
Be notified previous packet is sent
Send another data packet to B
Packet Event
Receive As 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
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 Bs peer discovery message
Receive As 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 As data packet
Send Done Event
Be notified previous packet is sent
Send another data packet to B
Packet Event
Receive As 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
Impala Repairability
D
B
A
C
Node
Update
Updater
On a single sensor node
Full network
12
Software Modules
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

• Each application is divided into several modules
• Module version number vs. app version number
• Allows selective software transmission

13
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 queryswitch
Install update
Send software info
18
Efficient Network Reprogramming

• Probabilistic broadcasting broadcasts to all
  neighbors with a probability
• Impalas 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