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 ReportTranscript 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