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