tinyDSM: A Highly Reliable Cooperative Data Storage For Wireless Sensor Networks Krzysztof Piotrowski, Peter Langendörfer, Steffen Peter IHP Im Technologiepark 25 15236 Frankfurt (Oder) Germany IHP Im.

Download Report

Transcript tinyDSM: A Highly Reliable Cooperative Data Storage For Wireless Sensor Networks Krzysztof Piotrowski, Peter Langendörfer, Steffen Peter IHP Im Technologiepark 25 15236 Frankfurt (Oder) Germany IHP Im.

tinyDSM: A Highly Reliable Cooperative Data
Storage For Wireless Sensor Networks
Krzysztof Piotrowski, Peter Langendörfer, Steffen Peter
IHP
Im Technologiepark 25
15236 Frankfurt (Oder)
Germany
IHP Im Technologiepark 25 15236 Frankfurt (Oder) Germany
www.ihp-microelectronics.com
© 2009 - All rights reserved
Outline
•
Motivation
•
Goals
•
Our solution
•
Future work
•
Conclusions
IHP Im Technologiepark 25 15236 Frankfurt (Oder) Germany
www.ihp-microelectronics.com
© 2009 - All rights reserved
Motivation
Wireless Sensor Network is a loosely coupled multiprocessor system
•
limitations
- energy – trade-off between activity and lifetime
- network – transmission losses, delays, network dynamics
- computational power – adds to both above mentioned
•
great number of nodes
Cooperation in WSN is the way to success!
Cooperation is data exchange!
IHP Im Technologiepark 25 15236 Frankfurt (Oder) Germany
www.ihp-microelectronics.com
© 2009 - All rights reserved
Motivation, cont.
The Environment
•
The size of the network is not limited
- The data is locality bound
•
Nodes appear and disappear
- Nodes represent a medium for the data
Cooperation based on data exchange in a common storage
- Replication increases the reliability
- Historical data increases the usability
Need for mechanisms to exchange and store the data in a reliable way!
IHP Im Technologiepark 25 15236 Frankfurt (Oder) Germany
www.ihp-microelectronics.com
© 2009 - All rights reserved
Motivation, cont.
•
•
•
Loosely coupled multiprocessors
- not easy to program
- memory consistency problems
Distributed Shared Memory
Introduces an additional layer to
loosely coupled multiprocessors
+ hides the complexity
+ cares about memory consistency
MEMORY
MEMORY
MEMORY
CPU
CPU
CPU
MEMORY
MEMORY
MEMORY
CPU
CPU
CPU
Consistency / performance trade-off
COMMON MEMORY
IHP Im Technologiepark 25 15236 Frankfurt (Oder) Germany
www.ihp-microelectronics.com
© 2009 - All rights reserved
Goals
A reliable data storage middleware
•
Distributing the data items
- availability
- cooperative access
- consistency of the replicas
- historical data
- event detection
•
Security
•
Configurable
IHP Im Technologiepark 25 15236 Frankfurt (Oder) Germany
www.ihp-microelectronics.com
© 2009 - All rights reserved
The solution – the idea
•
•
•
•
•
At start-up each node announces own shared variables
The neighbours decide on a random basis to replicate it
Changes to a shared variable are sent to the neighbours
On update the new value is checked if any event occurred
Every node having a replica can provide the data
IHP Im Technologiepark 25 15236 Frankfurt (Oder) Germany
www.ihp-microelectronics.com
© 2009 - All rights reserved
The solution – addressing
•
There is one global set of variables per application
defines the shared part of the memory
•
Each node has an address
represented either by Id or location
•
Each variable has its type
defines the granularity
•
The timestamp allows the versioning of the values
allows creating history
•
Each instance of a variable is a tuple
<source_node_address, variable_ID, timestamp, value>
IHP Im Technologiepark 25 15236 Frankfurt (Oder) Germany
www.ihp-microelectronics.com
© 2009 - All rights reserved
The solution – messages
There are three types of request messages
• GET – request for reading a specific variable
• SET – request for writing a specific variable
• UPDATE – request for updating the replicas of a specific variable
With or without acknowledgement (verification)
Each of them is completed with an acknowledgement message
• ANSWER – the results for the GET request
• SET_ACK – indicates that the SET request was fulfilled
• UPDATE_ACK – indicates that an UPDATE request was fulfilled
The GET and UPDATE messages are usually broadcast, all other
messages are usually unicast.
IHP Im Technologiepark 25 15236 Frankfurt (Oder) Germany
www.ihp-microelectronics.com
© 2009 - All rights reserved
The solution – architecture
•
•
•
•
•
Application logic defines the sources
of data and actions in case of events.
Event & Replication Logic takes the
decision on the replication of data,
storage of new data and controls data
locating. It is also responsible for
detecting the events for the new data.
Query Logic is responsible for
interpreting incoming messages
(queries) and building results into
answer messages.
Memory Manager controls the
physical data storage on the node.
Communication Interface allows
communication with other nodes.
IHP Im Technologiepark 25 15236 Frankfurt (Oder) Germany
www.ihp-microelectronics.com
© 2009 - All rights reserved
The solution – customization
•
Policies control the behaviour of the system
•
Policies chosen while defining a variable define the handling of all
instances of that variable in the system
- the requested consistency
- the replication strategy
- the used storage space, size of the history, etc.
•
Policies can control the behaviour in case of an event
- diverse strategies to avoid false positives and false negatives
•
Policies allow for tuning the application
- exchanging the policy file allows to create several versions of the
application with different requirements using the same source code
IHP Im Technologiepark 25 15236 Frankfurt (Oder) Germany
www.ihp-microelectronics.com
© 2009 - All rights reserved
The solution – preliminary evaluation
•
•
•
•
20 x 20 nodes network (regular grid)
Several combinations of network parameters
One defined variable
Variable set once every five seconds
•
•
Ten updates + up to five verifications (quality parameter)
25% replication probability (quantity parameter)
Network
name
Replication
range (hops)
Radio range
Number of
replicas
Network1
1
1
2
Network2
1
2
6
Network3
2
1
6
IHP Im Technologiepark 25 15236 Frankfurt (Oder) Germany
www.ihp-microelectronics.com
© 2009 - All rights reserved
The solution – preliminary evaluation, cont.
0,6
0,5
avg
max
Delay [s]
0,4
0,3
0,2
0,1
0
Network 1
IHP Im Technologiepark 25 15236 Frankfurt (Oder) Germany
Network 2
www.ihp-microelectronics.com
Network 3
© 2009 - All rights reserved
The solution – preliminary evaluation, cont.
Amount of packets sent per update
30
25
avg
max
20
15
10
5
0
Network 1
IHP Im Technologiepark 25 15236 Frankfurt (Oder) Germany
Network 2
www.ihp-microelectronics.com
Network 3
© 2009 - All rights reserved
Number of replicas/acknowledgments
The solution – preliminary evaluation, cont.
Defined copies
Up-to-date copies
10
Acknowledge
Total copies
9
8
7
6
5
4
3
2
1
0
1
11
21
31
41
51
61
71
update sequence number
IHP Im Technologiepark 25 15236 Frankfurt (Oder) Germany
www.ihp-microelectronics.com
© 2009 - All rights reserved
Number of replicas/acknowledgments
The solution – preliminary evaluation, cont.
Defined copies
Up-to-date copies
16
Acknowledge
Total copies
14
12
10
8
6
4
2
0
1
11
21
31
41
51
61
71
81
91
update sequence number
IHP Im Technologiepark 25 15236 Frankfurt (Oder) Germany
www.ihp-microelectronics.com
101
111
121
131
© 2009 - All rights reserved
Future work
•
Definition of deployment scenarios for simulations
additional simulations have to be done for several scenarios
•
Definition and simulation
the system parameters and mechanisms have to be defined and
evaluated regarding the introduced costs and performance features
•
Application programming tools
have to be developed in order to make the use of the approach easier
•
Moving the model to real Wireless Sensor Network
verification of the model on real nodes
potential hardware-software functionality shifts
IHP Im Technologiepark 25 15236 Frankfurt (Oder) Germany
www.ihp-microelectronics.com
© 2009 - All rights reserved
Future improvements
•
Database abstraction layer
allows accessing the data stored in the WSN like a database
•
Distributed Event processing
in case an event is detected it can be validated within the network
•
Single system image version
in smaller networks complete replication may be possible
•
Global variables and ownership migration
global variables are defined per network not per node
to avoid access problems in case the owning node is lost the
ownership can be transferred to another node
IHP Im Technologiepark 25 15236 Frankfurt (Oder) Germany
www.ihp-microelectronics.com
© 2009 - All rights reserved
Conclusions
•
The presented reliable distributed data storage that adapts the
number of replicas to the defined number is the first step towards
providing the Distributed Shared Memory to the WSN
•
Concept of DSM was primarily used to enable parallel distributed
computing on powerful devices connected via powerful network
interfaces
•
The idea fits perfectly to the WSN application area as well
•
Providing the concept to the WSN together with its features and tools
that ease its use enables many new applications in that area
•
It allows the nodes to operate more active and autonomous from a
base station by injecting more intelligence into the network.
IHP Im Technologiepark 25 15236 Frankfurt (Oder) Germany
www.ihp-microelectronics.com
© 2009 - All rights reserved
Thank you
Questions?
IHP Im Technologiepark 25 15236 Frankfurt (Oder) Germany
www.ihp-microelectronics.com
© 2009 - All rights reserved