1 / 14

Towards a Flexible Global Sensing Infrastructure

Towards a Flexible Global Sensing Infrastructure. Chien-Liang Fok, Gruia-Catalin Roman, and Chenyang Lu. Problem Statement. SensorNets are evolving: Current software architecture does not easily facilitate Integration of new technology Application flexibility

lola
Download Presentation

Towards a Flexible Global Sensing Infrastructure

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Towards a Flexible Global Sensing Infrastructure Chien-Liang Fok, Gruia-Catalin Roman, and Chenyang Lu

  2. Problem Statement • 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 Large-scale,Heterogeneous, General Purpose evolving into Existing SensorNets Future global sensinginfrastructure (GSI)

  3. Global Sensing Infrastructure • A collection of sensors, microservers, base stations, and the Internet • Heterogeneous and continuously evolving • Shared by many users

  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 language <type = sensor> <name = temperature><units = Celsius> <error = ±0.05> 1 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);8boolean isFire = invoke(serv) onError err();9 }10 }

  13. Current Status: System • 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

More Related