Middleware for WSN

1
Middleware for WSN

• Danny Hughes
• Middleware Reading Group

2
Introduction

• Discussing the paper Geoff mentioned Middleware
  Challenges and Approaches for Wireless Sensor
  Networks
• Discusses and evaluates a range of middleware for
  WSN (in a somewhat superficial way).
• How would GridKit fair in this evaluation?

3
Applications of WSN

• Military
• Environmental Monitoring
• Industrial Processes
• Transportation
• Smart objects/homes/offices

4
Challenges for Middleware in WSN

• Power Constraints
• Must run for long periods.
• Potentially variable power supply (e.g. Solar).
• Demands file-grained control of CPU, network and
  activation of on-board devices.
• Heterogeneity
• CPU-power Original PC (8088) to
  Pentium-equivalent.
• Networking Zigbee 802.11x.
• Memory and Storage
• Operating Systems Tiny OS Linux.

5
Challenges for Middleware in WSN

• Why Ad-Hoc Networking?
• Client/Server approach impossible.
• Infrastructure often unavailable.
• Ad-Hoc Networking Challenges
• Node failure.
• Heterogeneous capabilities.
• Variable resource availability.
• Resource discovery.
• Security.

6
Challenges for Middleware in WSN

• Requirements from the application-domains
• Real-time nature of monitoring.
• Need to adapt to changing conditions.
• Trade-off between application specificity and
  generality.
• Long-term, autonomous operation.
• Scalability.

7
Classification Scheme
8
Classification Scheme
Conceptual models.
9
Classification Scheme
Systems, services and run-time mechanisms.
10
Virtual Machines

• Benefits
• Common abstraction
• Sand-boxing
• Distribution of code
• Drawbacks
• High overhead
• Difficult to exploit heterogeneity

11
Virtual Machine Approaches

• MATE
• Power-centric abstraction.
• Tied to TinyOS.
• MATE programs are broken up into small capsules.
• Capsules form a unit of distribution.
• Communication in synchronous.
• No support for message buffering / large storage.

12
Virtual Machine Approaches

• MAGNET
• Power-aware, adaptive OS.
• The whole network appears as a single JVM.
• Standard Java programs are re-written by MAGNET
  as network components.
• Components may then be injected into the
  network using a power-optimized scheme.

13
Virtual Machine Approaches

• Critique
• Targeted at highly embedded nodes.
• Assumes sensors are dumb.
• Very simple, fixed network abstraction.
• Impossible to exploit heterogeneity.
• Power is important, but is it always critical.

14
Mobile Agents

• Benefits
• Code updates propagate efficiently as only parts
  of the program need be updated.
• Potential for dynamic evolution of programs.
• Drawbacks
• High overhead, unsuitable for highly embedded
  devices.

15
Mobile Agent Approaches

• IMPALA
• Focus is on efficiency of updates, to support
  dynamic applications.
• Efficient updates are achieved at the expense of
  heterogeneity (updates are compiled to binary
  units).
• Different profiles possible (not just energy
  efficiency).

16
Mobile Agent Approaches

• Critique
• Allows more scope for node autonomy than
  virtual-machine approaches.
• Tied to a single hardware platform.
• Does not deal with networking issues outside of
  code updates.

17
Databases

• Benefits
• Entire sensor network is abstracted as a virtual
  relational database.
• Very easy to interoperate with existing systems.
• Drawbacks
• Not real time.
• Does not allow steering of sensing.

18
Database Approaches

• COUGAR
• Represents all sensors and sensor data in a
  relational database.
• Control of sensors and extracting data occurs
  through special SQL-like queries.
• Allows the scheduling of ongoing queries that
  provide incremental results.
• Decetralized Implementation, message passing
  based on controlled flooding.

19
Database Approaches

• SINA
• Based on a spreadsheet database, wherein network
  is a collection of data-sheets and cells are
  attributes.
• Queries again performed in an SQL-like language.
• Decentralised Implementation based on clustering.

20
Database Approaches

• Critique
• Allow for very little node autonomy.
• Impossible to exploit heterogeneity.
• Does not tie in well with monitoring which is
  largely event-driven.

21
Message-oriented Middleware

• Benefits
• Publish-subscribe communications model.
• Allows direct communication between nodes.
• Event model closely ties to monitoring role.
• Drawbacks
• Overhead.

22
Message Oriented Middleware

• MIRES
• Seperated into
• Core (publish-subscribe)
• Multi-Hop Routing
• Additional services (e.g. data aggregation)
• Sense Advertise over P/S Route to Sink.

23
Database Approaches

• Critique
• Allows for more autonomy than previously seen.
• Still assumes somewhat dumb nodes, e.g. data is
  always routed direct to sink, with no scope for
  in-network processing.
• Networking abstraction is better than some of
  those discussed, but still primitive.

24
General Thoughts

• Generally little thought is given to node
  autonomy.
• Networking support is basic and tends to be
  optimized for fixed factors.
• Heterogeneity is poorly supported.
• Various models have advantages in different
  situations, yet none seem significantly
  configurable.
• Clearly this highlights the benefits of
  Lancasters GridKit approach

25
Evaluation Framework
26
How Would GridKit Do?

• Write my next related work section
• Power Awareness.. ?
• Openness. ?
• Scalability. ?
• Mobility.. ?
• Heterogeneity.. ?
• Ease of Use. ?