KSN Radio Stack: Sun SPOT Symposium 2009 London.

Transcription

1 Andreas Leppert pp Stephan Kessler Sven Meisinger g : Reliable Wireless Communication for Dataintensive Applications in Sensor Networks Sun SPOT Symposium 2009 London

2 Application in WSN? Targets Wireless Sensor Network (WSN) Large number of battery powered devices energy is valuable! Exchanging data using wireless communication User can access network through base station Su Countless Applications Medical Care, Environment Monitoring, Object Tracking What is data-intensive application in WSN? 2 variations: Nodes generate Data Data must be transported to user / base station Amount of data accumulates on the way Base station has to distribute data to the whole network 2 examples follow Sun SPOT Slide 2

3 Example 1: Data Gathering Targets Data Gathering Applications A large number of nodes Generating / Measuring data (continously) Sending measured data back to base station More Sensor Nodes Base Station Despite Compression/Aggregation: Messages of several KB have to transmitted reliably Large part of result is lost if 1 message is lost! Slide 3

4 Example 2: Over-the-Air Deployment Testbeds Evaluate your software Test and debug software Targets 1. Connect SPOT to USB 2. Put SPOTs into positiono 3. Start testing / evaluation 1. Errors in software? 2. Find error, fix code 4. Collect SPOTs and start with step 1 Problem: Testing-Cycle very cumbersome Solution: Fixed infrastructure connected to nodes Not possible/feasible or all deployments Distribute software over-the-air (OTA) Slide 4

5 Example 2: Over-the-air Deployment (cont d) Targets Requires large files / messages to be transmitted Query Processor suite file ~500 KB Libraries ~700 KB Large Number of Hops In our testbed of 30 SPOTs max. 9 Hops Any testbed requires transmission of large messages over multiple hops Slide 5

6 Requirements of data-intensive Applications Communication software (stack) must Deliver messages reliably Cope with relatively large messages Targets Multiple Hops between sender and receiver node Particularly l hard in sensor networks Expect nodes to fail during transmission React to topology changes due to external influences, e.g., Weather Closing/Opening of doors SPOTs are shipped with a communication stack Why not use this stack? Slide 6

7 Testing the (1) Targets Setup for evaluation 2-5 nodes in a line, i.e., 1-4 hops 1 specified node sends a message of varying size RadioStream was used After sending, node computes a hash value of the message 1 specified node receives message When receiving completes, receiver computes hash value over received message Transmission successful, if both hash values are equal Code can be obtained from our homepage: i h d / Sender Receiver Slide 7

8 Testing the (2) Targets Evaluation was conducted with the Blue release (current) Slide 8

9 Motivation for a new stack Sun stack is reliable and fast for small messages Almost no errors for message sizes below 1KB Unreliable for large messages or high number of hops Targets Main reason: Goals for the Low Power Efficient usage of low bandwidth available not aimed at data-intensive applications Messages are transmitted reliably over 1h hop layer works Errors must occur above new stack above MAC Slide 9

10 Agenda Motivation: Why do we need another stack? What does data-intensive in sensor networks mean and reliability evaluation data Targets targets & additional i features The core of the Stack Optional stack layers Possibilities for Optimization / Improvements Reliability evaluation and of the stack : vs. Stack The Projects Agenda Slide 10

11 Targets - Reliability Transmission of large messages over multiple hops must work reliably Problems encountered during transmission must be fixed inside the communication stack if possible Handling of errors should not be mixed with application code Expect nodes to fail during transmission External influences change communication behaviour of nodes Weather Closing doors Sender must know if transmission failed on intermediate nodes End-to-End ACK ACK Sender Receiver Slide 11

12 Targets - Extendability Different applications have different demands Run Multiple Stacks parallely on one SPOT Adding / implementing new layers Network Management might require another stack than Query Processing Stack with less complex interfaces for student experiments, more sophisticated stack to gather the result of their experiments Slide 12

13 Further Targets Compatibility with Interface-Compatibility to Users have written applications using the Migrating to our stack should not require rewriting the application Link-Quality-awareness Probability for failures increases, as link quality decreases Communication hardware on SPOTs allows estimations about link quality Example: Quality-Aware Layer Slide 13

14 Optimization is not a Target Communication stacks for sensor nodes are usually optimized regarding g energy usage Nodes are usually battery-powered Reliability is the most important step towards efficiency Users query a sensor network to gain information demand for information has to be satisfied (efficiently) If failures prevent delivery of information Energy used to acquire information until failure occured is wasted! Users might retry Failure likely to occur again more waste! Optimization is the step after functionality is ensured We should forget about small efficiencies, say about 97% of the time: premature optimization i is the root of all evil. (Donald Knuth) Slide 14

15 Foundation for Reliable Communication Basic Operation of : Sending a packet of 127 byte Receiver is a node within the radio range of the sender Two variants of the Basic Operation: Broadcast: Receiver address is blank No acknowledgement Unicast: Receiver address identifies node If transmission of 127 byte was successful, acknowledgement is sent If there was a failure, no acknowledgement is received and a timeout expires. Reliable communication is based on this basic operation First Step: communication protocol for messages larger than 127 byte Slide 15

16 Single Hop Protocol Single Hop Protocol () Layer provides interface for Unicast of messages of arbitrary size Broadcast of messages of arbitrary size Preparation for sending (unicast or broadcast) M Let Message M have a size of b bytes Decompose M into f fragments Assign a sequence number s={1 p} to each fragment C Compute checksum C from M Sending process for unicast and broadcast different starting with broadcast 4 Slide 16

17 Single Hop Protocol - Broadcast Two types of packets BroadcastData: Contains fragments of 104 Byte, used for first f-1 fragments BroadcastEnd: Contains last fragment with sequence number s=f Possible failures: Unexpected sequence number Timeout while waiting for next/last fragment Limitations (current implementation) Sequence Number is 16-bit long max. Broadcast ~ 6 MB sufficient for SPOTs Slide 17

18 Possible Broadcast Improvement Problem: Broadcast still inherently unreliable Sender broadcasts f fragments to surrounding nodes Some receivers only receive k<f fragments Receiver has spent energy, but message is incomplete receiver discards all received fragments, energy wasted! Possible improvement (not yet implemented): Each receiver uses sequence numbers to determine, which k fragments are missing If k is sufficiently small compared to f, ask sender to resend missing fragments with unicast Open questions: Caching mechanisms for broadcast messages on sender What is sufficiently small? Slide 18

19 Single Hop Protocol - Unicast - Unicast Protocol 1. Send UnicastRequest to receiver Contains Checksum C Size b of Message M in bytes receiver can abort transfer 2. Send f fragments to receiver Receiver has to acknowledge each fragment Unacknowledged fragments are retransmitted after a timeout 3. Receiver checks if data is not disrupted using checksum C Slide 19

20 Unicast Improvements Evaluation has shown: Data rates with Sun stack higher than with stack Comparable only for small messages due to reliability Reason for lower data rate: Ak Acknowledgment ld for each hfragment congestion Less payload due to larger sequence numbers Ideas for improvements: TCP/IP-like ACK Aggregate ackowledgements and send 1 packet to acknowledge several received fragments Increase number of packets between ackowledgements depending on link quality Slide 20

21 Summary Single Hop Protocol offers reliable delivery to 1-hop neighbors Broadcast Unicast Message size Bounded d to 6 MB for broadcast SPOT has Theoretically unbounded for unicast 512KB of VM defines boundaries for max. array length RAM Layer still not fine-tuned large room for improvements! targets so far? Extendability not yet compatiblity done Reliability only 1 hop Slide 21

22 Extendability Multiple Stacks, 1 SPOT All communication is based on reliable 1-hop communication usable as a foundation Idea to allow multiple stacks Each Stack is assigned a globally unique ID we used a simple byte value max. 256 different stacks Special byte indicates stack ID Each node uses a Dispatcher to Pass incoming data to correct stack depending on stack ID Pass outgoing data to Layer Dispatcher has 4 functions Register / unregister new stack Broadcast / unicast data using Slide 22

23 Extendability More Stack-Layers All new layers must implement LayerInterface Methods for broadcast / unicast of data from upper layers Method, which takes incoming data from lower layers or the Level Dispatcher Abstract Layer implementation is provided with our software New Layers can be implemented with very few lines of code Example of a AODV Layer follows now Slide 23

24 Example Layer Multi-Hop Up to this point, only 1-hop communication covered Example for a new Layer: Layer Used Mechanism: Ad-Hoc On Demand Distance Vector (AODV) [2] also includes AODV implementation, but No (working) End-to-End ACKs for Multi-Hop Unicasts Only 1 entry per Receiver no backup routes Both problems affect reliability will be addressed in the following Slide 24

25 AODV Mechanism Basics of AODV: Sender S wants to send message to Receiver R S broadcasts Route Request (RREQ) Nodes receiving RREQs rebroadcast if RREQ has not been broadcasted before Node already has a route to R stored in routing table Receiver R receives the RREQ Route Report (RREP) is sent back to S Message is sent through shortest / fastest-available route RREQ RREQ RREQ RREQ RREP Sender ACK ACK ACK Receiver Slide 25

26 AODV Table Format Table without backup entries 1 entry for each receiver R If transfer fails, new RREQ is broadcast by sender S Problem: RREQ very small message (1 packet) might be transmitted reliably, but larger messages fail same Route will be returned transfer might fail again for larger message energy wasted! Solution: Several entries for 1 receiver R Use depth-first search to transmit larger message to R Can be adapted to use quality information! Slide 26

27 AODV End-to-End ACK sends ACK if message is transmitted correctly Problem: Intermediate node fails while sending Intermediate node has sent ACK already, but message is lost! Solution: Receiver sends End-to-End ACK to sender Sender waits for End-to-End ACK Length of timeout determined e ed using hop count of routing table -ACK Sender targets so far? Extendability g g End-to-End ACK done compatiblity done Reliability done Receiver Slide 27

28 Reducing Data Size Compression layer Can be used with abitrary compression algorithm We use a modified ZIP algorithm Should be used above routing layer Avoids decompression on every hop Protocol Dispatcher Applications can use different protocols on top of single stack! Examples: PC-like with ports LowPan Slide 28

29 Message Size: 50 KB Tested up to 1 MB with more than 10 hops 4 Hops Output Power -30 Difference to demo before Simulation of node failures by removing/exchanging nodes Simulated failure will cause delay Message delivered despite topology changes Application has not been changed Sender Receiver Slide 29

30 of both Stacks Very fast and efficient for small messages use for experiments where every second counts Unreliable if Messages become large Messages must be transmitted over a large number of hops Other transmissions from other SPOTs run parallely Was not shown here IPv6 compatible Reliable for large message sizes and large number of hops Up to 1 MB And 15 hops tested without losing messages More overhead slower Use for experiments where counting bytes is sufficient Currently not IPv6 compatible Slide 30

31 Agenda Motivation: Why do we need another stack? What does data-intensive in sensor networks mean and reliability evaluation data targets & additional i features The core of the Stack Optional stack layers Possibilities for Optimization / Improvements Reliability evaluation and of the stack : vs. Stack The Projects Agenda Slide 31

32 Who is Stephan Kessler Student Assistant Serialization & Stack Andreas Leppert Student Assistant Stack, Query Dissemination Sven Meisinger Student Assistant Serialization, Simulator PhD student Project Head Slide 32

33 Other Projects Management Application Controlling large testbeds of SPOTs Software deployment uses Stack Support for experiments, e.g., collect data Serialization for SPOTs Serialization used in JDK to store/send objects not supported by Squawk VM Pure Java serialization Testbed 30+ nodes deployed at the IPD Real network for experiments Many more Homepage: Slide 33

34 Sensor Databases Topic: Sensor Databases Problem: Every new application for WSN requires complete development process & implement new hardware & implement new software very costly Idea: Provide database-like interface for WSN Advantage: Use same software for new WSN application, only change query Example: SPOT 1 SPOT 2 Temp: 25.3 C Temp: 23.4 C Hum.: 78% Hum.: 77% Light: 124 Light: 120 Measurement stored distributedly in tables Use SQL to query data, e.g., SELECT nodeid, temp FROM Sensors Size of result depends on query data-intensive! Slide 34

35 Current Topics Approximate Query Processing Reduce result quality to save energy Different quality parameters possible Precision of result Security Consistency Query Distribution Broadcast of query very energy consuming Use structure of query to choose distribution strategy try to reach all relevant nodes, but not all nodes! Spatio-Temporal query processing in WSN Moving object DBs provide operators to query object movement Only for historical data stored in a DB server Idea: Try to provide these operators for object tracking in WSN Slide 35

36 Thank you for your attention! Questions? References No. Reference [1] MICA2 Sensor Node, [2] Perkins, Royer: Ad-hoc on-demand d distance vector routing; Mbil Mobile Computing Systems and Applications, 1999 Slide 36