Event Processing Middleware for Wireless Sensor Networks

Event Processing Middleware

for Wireless Sensor

Networks

Selvakennedy Selvadurai

School of Information Technologies University of Sydney

Outline

• Introduction

• System Assumptions

• EPM Architecture

• Group Management and Centre

Localisation Components

• Results

WSN Background

• This technology is evolving rather rapidly

– E.g., the Mica2 sensor has roughly 8x the memory and bandwidth as its predecessor, the Rene sensor for the same power budget

• Some apps: earthquake monitoring, target

tracking and surveillance, structural monitoring

and precision agriculture

• Typically, these apps entail simple sensing and

relaying to the sink(s) for processing and storage

In-Network Processing

• Now, need more intelligence into the network

itself

– inline with the hardware advance

• Moreover, in many control apps, latency

constraints call for more in-network processing

• A number of efforts being undertaken

– These efforts may be classified either as statistical

processing or semantics processing

• Most fall under the former class

– data processing purely involves statistical treatments informed by any temporal/spatial correlation structure in the data

Semantic Processing

• In semantics processing, data processing is informed by the application semantics

• Sensor readings of high significance are tracked reflecting the readings of phenomena of interest

• Sensor nodes will need to collaboratively process their

data

– Enables rapid reactive mechanism towards events through appropriate actuators.

– For instance, some nodes may detect a fire event, and then

collaboratively process and activate the relevant water sprinklers – Would complete the sense-control-actuate loop.

Collaborative Processing

• Phenomena may span an area

– Collaborative processing is needed

• We might be interested to capture its area

coverage, its boundary and its centre

• Various algorithms have been proposed

independently to process specific event properties

• It may be more beneficial to provide event

Event Processing M’ware

(EPM)

• Advantageous to provide them as middleware services • Middleware has often been useful for bridging the gap

between the lower-level components and the application

– Eases development of distributed applications

• A WSN middleware, termed MiLAN [3], allows apps to specify their quality needs and proactively adjusts the network characteristics

• DSWare middleware [4] provides real-time event

detection services that sits between the application layer and the network layer.

• Our proposed middleware could logically complement

EPM

• It masks the collaborative processing required for some services

• As concrete examples, we implement the event boundary, event area and event centre processing services

– The edge detection component will form the core component – Other services uses the above to estimate both event centre and

area.

• This is the first such attempt.

• The middleware also exploits the existence of

clusterheads in certain data gathering protocols, like LEACH, HEED and T-ANT

• Using this approach, significant overhead reduction is achieved while maintaining up to 95% accuracy of event information

System Assumptions

• Each node knows its location

• Nodes know interesting sensor readings

(app-defined)

• Nodes within event are termed

affected

nodes

– Otherwise, unaffected nodes.

• The

edge

of a phenomenon is the imaginary

boundary between these sets

EPM Architecture

EPM Components

• Event Notification allows a node to discover its neighbourhood related to certain events

• Event Data Storage: Some information are kept at the nodes and cluster info at CHs

• Group Management: This component controls the collaboration among sensor nodes

• Edge Detection: It tests whether the current node is on the event edge (based on T-Fit [9])

• Higher-Level Processing: event centre localization and area computation

Group Management

• An

overlay tree

is formed among CHs

• When an event transpires, sensors in disjoint

clusters might detect it

– CHs collect from their clusters

• To choose the root, a natural choice would be a

CH close to the event region

• Data are aggregated and finally processed at the

root

• Any subscribed higher-level services is pushed to

the sink from root

Event Centre Localisation

• A x-coord sorted list of edge points becomes available at

the tree root

• For center localization, we need to find the furthest

distance between any pair of edge nodes • Since the diameter of a circle can

be approximated by the longest possible pair-wise distance, the

centre is the midpoint

• An exhaustive search over the edge nodes can be

performed but results in O(n2₎

C A B D I II III IV

Event Centre Localisation

• The nodes are organised into

k subgroups

• Two node pointers are used for traversing, and

they are initialized at opposite ends of the edge

node list

• Then, line segments involving nodes in subgroup 1

and

k are checked, followed by nodes in

subgroups 2 and

k-1 and so on.

x_start x_end

2 k-1 k

C

A B

Simulation Scenario

• Sensor nodes are randomly distributed in a

square

MxM region with M = 100 m

• The data message size is fixed at 30B.

• Node radio range is fixed at 20m

CL Estimation Error

Num ber of Nodes

E s ti m a ti o n A ccu ra cy ( % )

CL Estimation Error

Communications Overhead

Event Area Radius (m)

To ta l Co mm un ic at io n O v e r h e a d ( B y t e )

Mean Value with EPM Mean Value without EPM

0 5 10 15 20 25 30 35 40 45 50 15 20 25 30 35 40 45 50 Radio Range (m) Total Energ y Consumption

Mean Value with EPM Mean Value without EPM

Conclusions

• EPM is proposed

• The edge detection module forms the core

component.

– it supports higher-level event processing services.

• The in-network service is found to achieve up to

95% accuracy in its estimation of event center as

well as area

• It also has significant lower communication

overhead and energy usage

• These middleware services may be subscribed by

the sinks and the actuators