Middleware for Sensor networks

By
Salma Ahmed
Student No. 5836385
 Outline
 Introduction to Wireless Sensor networks
 Applications of Wireless Sensor networks
 Middleware for WSN
 Middleware Challenges for WSN
 Middleware Approaches for WSN
 Comparison between Middleware Approaches
 Mires- A Message oriented Middleware approach
 Conclusion
 References
 Proposed questions
 Introduction of Wireless Sensor Network

Wireless Sensor Network is a form of ad-hoc network

consisting of large number of heterogeneous tiny sensors
with communication, processing and storage capabilities
to monitor physical or environmental conditions such as
temperature, sound, vibration & pressure.
 WSN architecture

 A network is formed by hundred to thousand of sensor nodes.

 Sensor nodes are responsible for collecting environmental
information and sending it towards a sink node, which
receives the information gathered by the network and delivers
it to the end-user.
 Applications of Wireless Sensor Networks
 Area Monitoring
- Air pollution monitoring, greenhouse monitoring, landslide
monitoring
 Industrial monitoring
- Machine health monitoring
 Military applications
- battlefield surveillance, target detection, biological & nuclear
attack detection
 Environmental Surveillance
- forest fire detection, flood detection
 Medical monitoring
- drug administration, monitor human physiological data
 Structural monitoring
Medical Monitoring
 Middleware for WSN
What is it?
It is a software infrastructure that glues together the networking
hardware, operating system, network stacks and applications. It
sits between the operating system and the application domain.
Purpose
 Supports the development, maintenance, deployment and
execution of sensing based applications.
 Facilitates scalability, interoperability, deployment &
development of applications.
Middleware Provides
 Standardized system services to diverse applications.
 A runtime environment that can support and coordinate multiple
applications.
 Mechanisms to achieve adaptive and efficient utilization of
system resources.
 Middleware Challenges for WSN
Challenges of middleware arises due to changing environments,
wireless access & energy limitations.
 Limited power and resources
- Due to the advent of microelectronics, miniaturized devices are
increasing which possesses limited energy & memory (e.g. CPU &
memory).
- Middleware should provide mechanisms for efficient processor &
memory use while enabling lower-power communication and
prolong sensor node lifetime(e.g. Cougar)
 Heterogeneity
- Middleware should provide low-level programming models to
bridge the gap between hardware technology’s raw potentials and
necessary board activities such as reconfiguration, execution &
communication.
- Middleware has to support system mechanisms interfacing various
types of hardware & networks (e.g. TinyDB, Mires)
 Scalability, mobility & dynamic network topology
- Middleware for sensor networks must be scalable enough in terms of
no. of nodes, no. of users etc. to operate over long period of time.
- Middleware should maintain performance and robust operation while
network changes dynamically.
 Real world integration
- WSN applications are real time oriented where the environment is
always changing including time and space.
- Middleware should provide real time services to adapt to the changes
and provide consistent data.
 Application knowledge
- WSN middleware have limited resource availability and therefore it
cannot support variety of applications across the network.
- Middleware should integrate application knowledge into the services
provided.
 Adaptability
- Middleware for sensor networks must support algorithms that have
adaptive performance.
 Data centricity
- In WSN, the user application is not interested in the identity of the node
but the data it produces. In a case where a set of nodes is deployed to
produce the same kind of data, the application is not concerned which
node of the set has supplied the data, but the data itself is the center of
attention in data-centric networking.
- Middleware should support data-centricity by providing data-centric
routing and querying within the network.
 Configuration and Maintainability
- Sensor nodes are initially deployed for long periods of time, application
might have to reconfigure them or assign them a new task.
- Hence middleware should be able to make simple and low-cost software
updates and maintenance necessary to sensor nodes.
 QoS Support
- WSN middleware should support various QoS features- response
time, bandwidth allocation for ensuring reliability, detecting/reporting
events, coverage and deployment, information and tracking accuracy.
 Data Aggregation
- Network generates data redundancy which leads to communication cost
being higher than computational cost.
- Middleware should be able to aggregate data to eliminate redundancy &
minimize the no. of transmission to sink.
 Security
- Middleware should concentrate on integrating security aspects to the
application from the very first stage of development in order to achieve
security requirements such as confidentiality, authentication, integrity,
freshness & availability.
 Abstraction Support
- Sensors have different hardware platforms, hiding this information to
offer a homogeneous and holistic view of the network is a challenge for
middleware for WSN.
 Data Fusion
- Data collected by various sensor nodes have to be merged to form
easily understandable format or report . Now communicating this
information to task issuer( i.e. PDA, Laptop, Cell phone etc.) is another
major challenge.
 Middleware Approaches for WSN

 Database Approach
In this approach the entire sensor network is viewed as a
database, giving a chance to the applications to query the
network using SQL languages for extracting the data.
Pros:
It provides a way for simple and easy communication
scheme between users & network.
Cons:
It lacks time space relations between events. Real time
applications are not supported, only approximate results
are provided.
Example:
SINA (System Information Networking Architecture)
 SINA allows sensor applications to query the network, get
the results back from & eventually monitor changes in the
network.
 SINA constitutes three functional components:
1. Hierarchical clustering: Grouping nodes into clusters.
2. Attribute-based naming: it replaces the standard id-
based naming .
3. Location awareness: GPS is used to know the physical
location of the nodes.
 In SINA, network is a collection of datasheets, containing
attributes for each sensor node.
 SQTL & SQL-like language can be used to query the
database.
 Modular Approach
Application is decomposed into tiny modules.
Pros: Simple software updates are needed which saves a lot of energy
since more energy is consumed in sending data than processing it.
Cons: It possess increased overhead.
Example: Impala
 Impala supports modularity of sensor applications, application
correctness & adaptability. Adaptability is achieved using parameter-
based adaptation and device-based adaptation.
 Impala can handle issues like adaptability, software updates, energy
efficiency & security but it lacks behind in hardware heterogeneity &
QoS issues.
 Impala is designed for ZebraNet where wildlife monitoring can be done.
 Application driven Approach
In this approach the application is given more power in
controlling the network by the use of an architecture which
reaches the network protocol stack; therefore the
programmers can tune the network according to the
application’s need.
Pros:
- Application is scalable.
- Application will control network operations
management thus providing QoS advantage.
Cons:
- Lacks support for OS & hardware heterogeneity.
- Doesn’t address mobility issues.
Example: MiLAN

 In order to maximize application lifetime MiLAN

receives a description of application requirements,
monitors network conditions & optimizes sensor and
network configurations.

 To fulfill these requirements applications represent their

requirements to MiLAN through specialized graphs which
contains state-based changes in application needs.

 By using this information MiLAN can control the

network and also the sensors too for meeting the
application QoS, energy efficiency & also the lifetime of
the application.
 Virtual Machine Approach
The system contains Virtual machine, interpreters and mobile
agents. It allows programmers to write applications in separate,
small modules.
Pros: Energy consumption & resource use are minimized.
Cons: Experiences high overhead that the instructions introduce.
Example:
Mate
 Mate is built upon TinyOS
 Its programs are broken up into capsules of upto 24 instructions
which benefits large programs to be easily injected into the network.
 It mainly focuses on how to overcome the constraints such as
limited bandwidth & other network parameters.
 Mate avoids message buffering & large storage.
 Tuple Space Approach
This approach is similar to database approach, in that it
provides a similar form of “shared memory” model, in which
queries can be submitted to the sensor network as if the data
was stored in a centralized repository.
Example: TinyLIME
 Built over TinyOS, based on LIME.
 It follows an abstraction model based on shared tuple space
which supports data aggregation.
 It has three main components:
1. Lime Integration component
2. Mote interface
3. Mote-level subsystem
 No built in security support & does not support adaptability or
scalability either.
 Message oriented Approach
The asynchronous model provided by this approach and
the decoupling between consumers & producers made it
suitable for networks where node failures are common.
Example: Mires
 It implements publish/subscribe paradigm in WSN.
 Built upon TinyOS.
 Implements data aggregation.
 By implementing publish/subscribe & data aggregation,
Mires proved its energy- efficiency for sensor applications.
 Does not support Security & QoS.
Comparison between Middleware approaches

Table 1 . Comparison of middleware designed for WSN

[ Masri et al, 2007]
The table shows different challenges met by the
middleware approaches

where Y denotes supported

Y- denotes partially supported
N denotes not supported
 Challenges met SINA Mires MiLAN TinyLIME Impala Mate
Data-Centricity Comparison
Y ofY middleware
Y designed
Y for WSN
N N

Energy & Resource Y Y Y Y Y Y

Management
In-Network Y Y N N N N
Processing
(Data Aggregation)
QoS Support N N Y N N N
Application N N Y N N N
Knowledge
Scalability Y Y Y N Y Y
Dynamic Net. Y N N Y Y Y
Topology &
Robustness
Adaptability N N Y N Y N
Configurability & N N N N Y Y
Maintainability
Real World Y N Y Y Y Y
Integration
Security N N N N Y Y
Heterogeneity N Y- Y- Y- Y- Y-
 Mires – Message oriented Middleware

 Mires middleware addresses the implementation of

publish/subscribe communication for wireless sensor
network applications.

 Traditional request/response approach is not suitable for

event-driven communication model. Publish/subscribe
approach is used to query and extract data from the
network.
 Figure 1: Mire’s Architecture [Souto et al, 2004]
Starting from bottom to top,
o Hardware of sensor network
- micro controller unit
- sensors
- radio transceiver
o Operating System
o Mires
- Publish/ subscribe service
- Routing component
- Additional services
o Node or User Application
The main component in Mires architecture is the
 publish /subscribe
- intermediates the communication between middleware
services.
- Advertising the topics provided by the local application.
- Maintaining the list of topics subscribed by the node
application.
- Publishing messages.
 Routing component
Multi- hop routing algorithm is used in order to transmit
messages received from the network towards the sink
node.
Types of notification events:
i. topicArrival :
This event signals that the node application has
submitted data collected from sensors.
ii. stateArrival:
Signals that the data is collected from the network
instead of sensors.
iii. topicSetupArrival:
is the subscribed message broadcasted from the
user application. It contains both a list of subscribed
topics and configuration information for the
services.
Publish/subscribe service

Figure 2 : Publish/subscribe class diagram [Souto et al,2004]

 PublishSubscribe component provides both the Advertise
and Publish interfaces to node application. And also
PublishState and Notifier interfaces to ServiceX.
 PublishState interface defines the command used by
ServiceX to publish their processing results.

 PublishSubscribe service uses three interfaces (Send,

Receive, Intercept) that are implemented by the Bcast
and MultiHopRouter communication components.

 The MultiHopRouter component is responsible for

establishing routing heirarchy towards the sink node.

 The Bcast component is responsible to broadcast

setup information across the network.
Advertisement Phase
 Node application advertises to the
PublishSubscribe service its
capability of sensing data.
 PublishSubscribe service sends the
advertised message to the network
via Multihop router.
 Interactions are shown in the
bottom part of the figure where a
advertiseMsg arrives at the node
- Intercept
- Update
- Forward

Figure 3: Topic advertisement sequence diagram[ Souto et al,2004]

Subscribe phase
 User application sends
subscribeMsg to all nodes in
the network.
 Each node that receives
subscribeMsg, the Bcast
component signals a receive
event.
 Finally PublishSubscribe
component extracts the
information from the message
& signals the topicSetupArrival
event to notify the ServiceX
component.

Figure 4: Topic Subscription Sequence Diagram[Souto et al,2004]

Publish & Process data
 Node application collects
data from the node’s sensors
& sends it to the
PublishSubscribe component.
 PublishSubscribe component
notifies other services
through topicArrival event.
 Next, the service invokes the
publishState command to
PublishSubscribe component,
by providing its processing
results.
[cont.]

Figure5: Data publishing sequence diagram [Souto et al,2004]

 PublishSubscribe sends the publishMsg to the
network using MultiHopRouter component.

 Finally, the MultiHopRouter intercepts publishMsg

and sends it to PublishSubscribe.

 PublishSubscribe extracts information & notifies

other services by signalling the stateArrival event.
An Environment Monitoring Application

Figure 6: Sensor nodes distributed in rooms[ Souto et al,2004]

 Sensor nodes are capable of monitoring variables such as temperature,
humidity, sound & luminosity.
 The sensors are grouped in rooms forming clusters.
 Each room has a cluster head which communicates with the sink node.
 Each node inside a cluster integrates the information by using some
aggregation technique & reports the results to the cluster head.
 Sink receives the data from cluster heads and spreads it to the network.
Aggregation Service
 Data aggregation is needed in environment monitoring
applications to reduce the no. of message transmissions,
latency and power consumption in the network.
 Aggregation is performed in each sensor node.
 Aggregation service uses aggregation function and stop
criteria as the configuration parameters.
 Aggregation function includes
- suppression
- min
- max
-average
Application Example

Figure 7: Graphical User Interface Example[Souto et al,2004]

 Figure shows user application & its interaction with

middleware architecture.
 In this example the user is interested in receiving data
about temperature every four minutes & luminosity every
six minutes.

 The user application needs to inform Mires only which

topics( temperature, luminosity or humidity) it is
interested in.

 The middleware receives this configuration message

(topics, function and aggregation policies) and sends the
requested data back to the user application.

 In this way Mires makes the control and communication

of the sensors readings.
 Conclusion
 WSN technology will enhance our daily lives in future.
They are too complicated to be handled directly by end-
users hence middleware approach is used.
 Since WSN present some peculiarities not found in
traditional networks, middleware have then to obey to
certain design principles to be suitable for the sensor
networks environment.
 The comparison between middleware approaches shows
that most of the approaches have dealt with the energy
consumption, limited resources issue and the scalability
issues, but didn’t support QoS and Security issues.
 Work is needed to be done in middleware especially in the
QoS support issue.
 References
• Hadim, S. and Mohamed, N., “Middleware: Middleware Challenges and
Approaches for Wireless Sensor Networks”. IEEE Computer Society Vol.7,
No.3; March 2006.
• Masri, W. and Mammeri, Z., “Middleware for Wireless Sensor Networks: A
Comparative Analysis ”. In the proceedings of IFIP International Conference
on Network and Parallel Computing, 2007.
• Molla, M.M and Ahamed S.I ., “ A Survey of Middleware for Sensor
Network and Challenges”. In the proceedings of International Conference on
Parallel Processing Workshops, 2006.
• Masri, W. and Mammeri, Z., “ Middleware for Wireless Sensor Networks:
Approaches, Challenges and Projects”. In the proceedings of International
Conference on Signal Processing and Communications, pp 24-27, November
2007.
• Rahman, A., “ Middleware for wireless sensor networks: Challenges and
Approaches”. In Seminar on Internetworking, April 2009.
• Souto, E., Guimaraes, G., “ A Message-Oriented Middleware for Sensor
Networks”. In the proceedings of 2nd International Workshop on Middleware
for Pervasive and Adhoc Computing, October 2004.
Thank You!!!
Questions
Q1. Compare two middleware approaches Impala & Mires
with respect to what challenges they meet.
Ans. Impala based on Modular middleware approach
supports Energy & resource management, scalability,
Dynamic Network topology & Robustness, Adaptability,
configurability & maintainability, real world integration
and security.
Mires a message oriented approach supports Data
centricity, Energy & Resource Management, In-network
processing, Scalability.
They both partially supports Heterogeneity.But none of
them supports QoS & Application knowledge issues.
Hence we can conclude that Impala is better than Mires.
Q2.. Describe the role of each component in
Publish/subscribe class diagram.

Figure: Publish/subscribe class diagram [Souto et al,2004]

Ans.
Roles:
Node Application: Node application advertises to the
PublishSubscribe service its capability of sending data related to
a certain topic.
PublishSubscribe: It intermediates the communication between
middleware services, maintains a list of topics provided by node
application & it is also responsible for publishing messages.
ServiceX: By using the two interfaces ( Notifier & ServiceX), this
component allows the addition of services to Mires.
Bcast: It is responsible to broadcast setup information across the
network.
MultiHoprouter: It is responsible for establishing routing hierarchy
towards the sink node.
Q3. Describe how publish & process data scheme in a network works?

Figure: Data publishing sequence diagram [Souto et al,2004]

Ans.
• The node application periodically collects readings from
node’s sensors and sends it to the PublishSubscribe
component via publish command.
• PublishSubscribe component uses topicArrival event to
notify other services.
• In the next phase, service invokes publishState command
to PublishSubscribe component by passing its processing
results. Then, PublishSubscribe sends PublishMsg to the
network using MultiHopRouter component.
• Finally, in the third phase, the MultiHopRouter signals an
intercept event containing the PublishMsg to
PublishSubscribe component. The publishSubscribe
component extracts the information from message &
notifies other services by signalling the stateArrival event.