Impala: Impala: A Middleware System for Managing A Middleware System for Managing Autonomic, Parallel Sensor Autonomic, Parallel Sensor Systems Systems Ting Liu and Margaret Martonosi Princeton University
Impala: A Middleware System for Managing Autonomic, Parallel Sensor Systems
Dec 30, 2015
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 - PowerPoint PPT Presentation
Welcome message from author
This document is posted to help you gain knowledge. Please leave a comment to let me know what you think about it! Share it to your friends and learn new things together.
Transcript
Impala:Impala:A Middleware System for Managing A Middleware System for Managing Autonomic, Parallel Sensor SystemsAutonomic, Parallel Sensor Systems
Ting Liu and Margaret MartonosiPrinceton University
Sensor Networks: An Emerging Style Sensor Networks: An Emerging Style of Parallel Computingof 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
querydata data
ZebraNet Wireless Sensor NetworkZebraNet Wireless Sensor Network
Data Base Station (car or plane)
Data
Data
Peer-to-Peer communication Protocol
CPU, Memory, Wireless Transceiver GPS
Current applications = protocols Future applications more complex
Long-Term Sensor Deployment: Long-Term Sensor Deployment: Needs Effective MiddlewareNeeds 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
Adapt Update
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
RoadmapRoadmap
Middleware Architecture Overview: Modularity Application Adapter: Adaptivity Application Updater: Repairability Evaluation Conclusions
CBB
C
Motivation: Middleware Support for Motivation: Middleware Support for Application/Protocol ModularityApplication/Protocol Modularity
A D
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 System Architecture and Programming ModelProgramming Model
Application A Application B Application C
Application Updater
Application Adapter
Application D
Send Done
Event Filter
Device Event
Send Done Event
Packet Event
Timer Event
Data Event
Timer
DataPacketInitialize Query
Timeline Example of Event-based Timeline Example of Event-based Application Programming ModelApplication Programming Model
Node A: Data Sender Node B: Data ReceiverTime
Application Impala Impala ApplicationTimer EventSend a peer discovery message Timer Event Send a peer discovery message
Packet EventReceive B’s peer discovery message Packet Event Receive A’s peer discovery message
Send Done Event Send Done Event
Timer EventSend 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 EventApplication query
Timer EventCheck status
Timer EventSend a peer discovery message Timer Event Send a peer discovery message
Send Done EventBe notified previous packet is sent
Application queryApplication terminateApplication 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
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
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 Sender Node B: Data ReceiverTime
Application Impala Impala ApplicationTimer EventSend a peer discovery message Timer Event Send a peer discovery message
Packet EventReceive B’s peer discovery message Packet Event Receive A’s peer discovery message
Send Done Event Send Done Event
Timer EventSend 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 EventApplication query
Timer EventCheck status
Timer EventSend a peer discovery message Timer Event Send a peer discovery message
Send Done EventBe notified previous packet is sent
Application queryApplication terminateApplication 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
Timer Event: Send a peer discovery message
Impala: AdaptivityImpala: 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
Terminate Initiate
DB
Impala: RepairabilityImpala: Repairability
High Node Mobility Constrained Bandwidth Wide Range of Updates
Incomplete Updates Updates vs. Execution Out of order Updates
ZebraNet Characteristics Design Implications
Updater
Update
A C Node
On a single sensor node Full network
Software ModulesSoftware 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 On-demand Software Transmission for Remote Software Updatefor Remote Software Update
Node ANode AComplete Version: 3.0Complete Version: 3.0
Incomplete Version:Incomplete Version:Node BNode B Complete Version: 1.0Complete Version: 1.0
Incomplete Version: 2.0Incomplete Version: 2.0
I have Version 3.0I have Version 3.0
I have Version 1.0I have Version 1.0
Stage 1Stage 1
Node ANode AComplete Version: 3.0Complete Version: 3.0
Incomplete Version:Incomplete Version:Node BNode B
Complete Version: 1.0Complete Version: 1.0
Incomplete Version: Incomplete Version: 2.0 and 3.02.0 and 3.0
Stage 2Stage 2I want Module 5 I want Module 5 from Version 3.0from Version 3.0
Node ANode AComplete Version: 3.0Complete Version: 3.0
Incomplete Version:Incomplete Version:Node BNode B
Complete Version: 3.0Complete Version: 3.0
Incomplete Version:Incomplete Version:
Stage 3Stage 3 Module 5 from Module 5 from Version 3.0Version 3.0
Repeat as needed …Repeat as needed …
Repeat interval backs off if frequent updates not neededRepeat interval backs off if frequent updates not needed
RoadmapRoadmap
Middleware Architecture Overview: Modularity Application Adapter: Adaptivity Application Updater: Repairability Evaluation Conclusions
Impala Prototype ImplementationImpala 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: Prototype Implementation: Application ProtocolsApplication Protocols
Flooding: Send to all neighbors found History-based: Send only to neighbor with
best “score” at delivering data to base
0
2000
4000
6000
8000
History-baseProtocol
Flooding Protocol
Inst
ruct
ion
Siz
e (b
ytes
)
Data Handler
Timer Handler
Packet Handler
Send Done Handler
Application Initialize
Application Terminate
Application Query
0
2000
4000
6000
8000
10000
12000
14000
Ev
en
t P
roc
es
sin
g T
ime
(u
s)
Event Processing Time Event Processing Time MeasurementsMeasurements
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 in
fo
Send software re
q
Send code pkt
Receive code pkt
Install update
Application Events
Adaptation Event
Update Events
Efficient Network ReprogrammingEfficient Network Reprogramming
Probabilistic broadcasting broadcasts to all neighbors with a probability
Impala’s on-demand transmission retains infection rate of high-probability broadcast
0
20
40
60
80
100
0 10 20 30 40 50 60 70 80 90 100 110
Time (hours)
Net
wo
rk In
fect
ion
Rat
e (%
)
Probabilistic Broadcasting(Probability=1)Probabilistic Broadcasting(Probability=0.1)Impala's On-demandTransmission
Efficient Network ReprogrammingEfficient Network Reprogramming
Probabilistic broadcast continues to send useless updates
On-demand transmission caps transmissions to number of nodes
0
50
100
150
200
250
300
0 10 20 30 40 50 60 70 80 90 100 110
Time (hours)
# o
f S
oft
wa
re
Tra
ns
mis
sio
ns
Probabilistic Broadcasting(Probability=0.1)Impala's On-demandTransmission
Adaptation Example: Improving Adaptation Example: Improving Routing PerformanceRouting Performance
Impala adaptation achieves equal/better data homing success rate at any given radio range
0
20
40
60
80
100
100 1100 2100 3100 4100 5100 6100 7100 8100 9100
Radio Range (m)
Dat
a H
om
ing
Su
cces
s R
ate
(%)
History-Based Only
Flooding OnlySwitching
Adaptation Example: Improving Adaptation Example: Improving Routing PerformanceRouting Performance
Adaptation switches are infrequent even in intermediate ranges where adaptation has highest payoff
0
0.4
0.8
1.2
1.6
2
100 1100 2100 3100 4100 5100 6100 7100 8100 9100
Radio Range (m)
# o
f S
wit
ches
per
Day
p
er N
od
e
ConclusionsConclusions
Impala: A middleware architecture for application …… Modularity Adaptivity Repairability
Prototype implementation and simulations demonstrate: Low overhead Efficient network reprogramming System Improvements
Related Documents
