Post on 02-Jan-2016
1
Towards a Flexible Global Sensing Infrastructure
Chien-Liang Fok, Gruia-Catalin Roman, and Chenyang Lu
2
• SensorNets are evolving:
• Current software architecture does not easily facilitate– Integration of new technology– Application flexibility– Evolving global sensing infrastructure
Small-scale,Homogeneous,
Application-specific
Problem Statement
Large-scale,Heterogeneous,General Purpose
Existing SensorNets Future global sensinginfrastructure (GSI)
evolving into
3
Global Sensing Infrastructure
• A collection of sensors, microservers, base stations, and the Internet
• Heterogeneous and continuously evolving• Shared by many users
QuickTime™ and aTIFF (LZW) decompressor
are needed to see this picture.
4
Two Example Applications
• Global supply chain monitoring– Sensors attached to products, cargo containers,
loading docks, ships, etc.– Many different users
• Regional disaster scenario coordination– Highly heterogeneous and dynamic network– Involves many organizations and networks – Re-program GSI to help victims and coordinate
responders
5
Our Proposed Solution
• Create a new software architecture based on service-oriented computing & mobile scripts– Web services: global interoperability– Reactive platform-independent mobile scripts:
dynamic application deployment in SensorNets– Efficient platform-dependent services: flexible
service binding
• Declarative service-oriented programming paradigm enables seamless integration
• Simplify application development on evolving & heterogeneous networks
6
Related Work• Arch Rock Corporation [Woo, Sensys’06]
– Expose SensorNet nodes to the external world as a web service using existing standards (WSDL)
– We support mobile scripts (dynamic deployment of apps) for programming inside SensorNets
• SenseWeb [Santanche et al, IPSN’06]– A web portal for integrating & viewing data
collected from a SensorNet
• IrisNet [Gibbons et al, IEEE Perv. Comp.’03]– A distributed database for WSN data
• Tenet [Gnawali et al, SenSys’06]– Support for tiered SensorNets– SensorNet has a fixed and uniform instruction set
7
More Related Work• Hourglass [Shneidman et al., Harvard TR’04]
– An infrastructure for connecting SensorNets with the Internet
– Focuses on data routing and processing
• ASVM [Levis et al, NSDI’05]– Create a VM with a custom instruction set– Does not provide dynamic service binding
• SOS + DVM [Balani et al, EmSoft’06]– A VM with dynamically loadable binary modules– Fixed binding between scripts and modules
• Melete [Yu et al, SenSys’06]– Multi-Application support within SensorNets– No quality of service provisions
8
Our Software Architecture
• Web services– Global interoperability
• Execution engine (VM for mobile scripts)– Deployment & execution of mobile scripts
• Service repository– Local or distributed
• Service management framework– Discovery– Binding– Invocation
9
Challenges: Programming
• Device Heterogeneity– Gracefully handle error conditions like when a
script invokes a service that is not available
• Service Description Language– Declarative– Compact, extensible– Spatiotemporal– Heterogeneous
• Identify the boundary between scripts and services
10
Challenges: Resource Management
• Quality of service for concurrent applications
• Varying resource availability– Processing capabilities– Memory– Network bandwidth– Sensors– Battery power
11
Challenges: Runtime
• Coordination– Inter & intra application
• Event Distribution– Scripts must react to changes in their context– Wide range of event types, sources, priorities, and
usage patterns
• Service Discovery– Limited resources prevent hosting every service
locally– Distributed service repositories– Remote/local persistent/transient binding
12
Current Status: Programming• Service Description language
• Scripting language1 require FireDetection2 service serv; // a handle to the service34 void main() {5 bind(EAGER | PERSISTENT, THREE_HOP, serv, FireDetection) onError err();6 while (true) {7 migrate(getRandomNeighbor(), STRONG);8 boolean isFire = invoke(serv) onError err();9 }10 }
<type = sensor><name = temperature><units = Celsius><error = ±0.05>
13
Current Status: System
QuickTime™ and aTIFF (LZW) decompressor
are needed to see this picture.
• Extended Agilla’s VM to support mobile scripts & service invocation
• Integrated a service provisioning framework
• Tested on Tmote Sky testbed
14
Conclusion
• Isolated SensorNets are evolving into a GSI• A new software architecture is required for
building flexible GSI applications• Our proposed three-tiered service-oriented
computing architecture:– Global web services– High-level platform-independent mobile scripts– Low-level platform-dependent services
• Many challenges remain