Towards Distributed Protocol Stacks for Wireless Sensor Networks
Upcoming SlideShare
Loading in...5
×
 

Towards Distributed Protocol Stacks for Wireless Sensor Networks

on

  • 6,929 views

Second presentation about DPS is available at http://de.slideshare.net/PeterRothenpieler/reliability-extensions-and-multi-hop-evaluation-of-distributed-protocol-stacks ...

Second presentation about DPS is available at http://de.slideshare.net/PeterRothenpieler/reliability-extensions-and-multi-hop-evaluation-of-distributed-protocol-stacks

Slides from my talk at the IEEE International Conference on Cyber, Physical and Social Computing 2012 (CPScom 2012)
November 20-23, 2012, Besançon, France

Statistics

Views

Total Views
6,929
Views on SlideShare
6,928
Embed Views
1

Actions

Likes
1
Downloads
10
Comments
0

1 Embed 1

https://www.itm.uni-luebeck.de 1

Accessibility

Categories

Upload Details

Uploaded via as Microsoft PowerPoint

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

Towards Distributed Protocol Stacks for Wireless Sensor Networks Presentation Transcript

  • 1. Dipl.-Inf. Peter Rothenpieler rothenpieler@itm.uni-luebeck.de http://www.itm.uni-luebeck.de/users/rothenpielerTowards Distributed Protocol Stacksfor Wireless Sensor NetworksIEEE International Conference on Cyber, Physical and Social ComputingNovember 20-23, 2012, Besançon, FrancePeter Rothenpieler, Dennis PfistererInstitute of Telematics, University of Lübeck
  • 2. Dipl.-Inf. Peter Rothenpieler rothenpieler@itm.uni-luebeck.de http://www.itm.uni-luebeck.de/users/rothenpielerContent Motivation Idea: Distributed Protocol Stacks (Short) Protocol Overview Design considerations & Limitations Evaluation  Code size  Round Trip Time  Goodput Summary and Conclusion 2
  • 3. Dipl.-Inf. Peter Rothenpieler rothenpieler@itm.uni-luebeck.de http://www.itm.uni-luebeck.de/users/rothenpielerMotivation: From WSNs to the Internet of ThingsWSN: problem specific, custom tailored solutions  standardized protocol stacks Application ApplicationAdvantages: Layered Protocols: Divide and Conquer UDP ICMP UDP ICMP Interoperability & Heterogeneity IPv6 IPv6 6LoWPAN 6LoWPANDisadvantages: IEEE 802.15.4 IEEE 802.15.4 MAC & PHY MAC & PHY Additional protocols/layers increase code size (+ adaptation layer?) 3
  • 4. Dipl.-Inf. Peter Rothenpieler rothenpieler@itm.uni-luebeck.de http://www.itm.uni-luebeck.de/users/rothenpielerMotivation: Code Size of 6LoWPAN & IPv6 Cheap / Small Expensive / Big OS Contiki Contiki iSense Contiki iSense Platform MSP430 JN5139 JN5139 JN5148 JN5148 Flash 48 KB 96 KB 96 KB 128 KB 128 KB 6LoWPAN 4.6 8.0 7.8 5.9 5.1 IPv6 7.4 12.3 31.6 8.7 18.3 ND 6.8 13.3 7.6 9.3 5.0 ICMP 0.8 1.3 2.1 1.0 1.2 UDP 0.7 0.3 2.1 0.2 1.1 Routing (RPL) 9.0 12.9 N/A 8.4 N/A Σ 29.3 48.1 51.2 33.5 30.6 % of Flash 61 % 50 % 53 % 26 % 24 %Source: Instant Contiki 2.6, Jennisense (07/2012), iSense SVN (04/2012) 4
  • 5. Dipl.-Inf. Peter Rothenpieler rothenpieler@itm.uni-luebeck.de http://www.itm.uni-luebeck.de/users/rothenpielerIdea: Distributed Protocol Stack Cooperation between layers  cooperation between nodes Share implementations of layers with neighboring nodes asynchronous RPC calls (“message passing”) Application Application Application Application UDP ICMP UDP ICMP UDP ICMP UDP ICMP DPS DPS IPv6 IPv6 IPv6 skeleton IPv6 stub 6LoWPAN 6LoWPAN 6LoWPAN IEEE 802.15.4 IEEE 802.15.4 IEEE 802.15.4 IEEE 802.15.4 MAC & PHY MAC & PHY MAC & PHY MAC & PHY RPC Server Client 5
  • 6. Dipl.-Inf. Peter Rothenpieler rothenpieler@itm.uni-luebeck.de http://www.itm.uni-luebeck.de/users/rothenpielerProtocol Overview Three phases  Discovery & Advertise  Three-way-Handshake Server Server  Exchange of RPC messages 1.Discovery RPCAdvertise 2. Handshake messages 2. Advertise Optionally supports the use of  Acknowledgements Client 6
  • 7. Dipl.-Inf. Peter Rothenpieler rothenpieler@itm.uni-luebeck.de http://www.itm.uni-luebeck.de/users/rothenpielerDesign considerations & Limitations DPS Covers only single-hop communication  Clients need at least one Server within radio range  Placement of nodes during deployment  Certain fraction of nodes need to be Servers (topology/deployment) Clients can not communicate directly (need Server in-between) 7
  • 8. Dipl.-Inf. Peter Rothenpieler rothenpieler@itm.uni-luebeck.de http://www.itm.uni-luebeck.de/users/rothenpielerEvaluation: Code Size Code size of native IPv6 implementation on JN5139 > 96 KB Flash Use of IPv6 on JN5139 now possible (26.5 KB reduction) Client Server Native IPv6 DPS Client Native IPv6 DPS Server JN5139 JN5139 JN5148 JN5148 Application 5.5 KB 3.8 KB Os 43.9 KB 36.4 KB IPv6 Stack 50.2 KB 10.1 KB 27.6 KB 27.6 KB DPS - 13.6 KB - 8.0 KB Σ 99.6 KB 73.1 KB 67.8 KB 75.8 KB 100 % -27 % 100 % + 12 % Relative -26.5 KB +8.0 KB 8
  • 9. Dipl.-Inf. Peter Rothenpieler rothenpieler@itm.uni-luebeck.de http://www.itm.uni-luebeck.de/users/rothenpielerEvaluation: Single-Hop Round Trip TimeData based upon 100 ICMP echo request/reply packets for each payload size Increase for additional fragments 6LoWPAN: 07 ms DPS: 07 ms DPS (ACK): 23 ms (Un-)compressed IPv6 header determines payload in first fragment x ms 1 byte Increase for additional payload 6LoWPAN: 0.068 ms/byte DPS: 0.075 ms/byte (+10%) DPS (ACK): 0.075 ms/byte (+10%) 9
  • 10. Dipl.-Inf. Peter Rothenpieler rothenpieler@itm.uni-luebeck.de http://www.itm.uni-luebeck.de/users/rothenpielerEvaluation: Single-Hop GoodputData based upon 1000 UDP packets for each payload size and output speed Decrease 1st Fragment: 32 % Following Fragments: 4.2 % - 5.7 % Native 6LoWPAN DPS 10
  • 11. Dipl.-Inf. Peter Rothenpieler rothenpieler@itm.uni-luebeck.de http://www.itm.uni-luebeck.de/users/rothenpielerSummary & Conclusion Motivation and Introduction: Distributed Protocol Stacks Code size reduced by 27.5 KB for the DPS Client  Increase of 8.0 KB for the DPS Server RTT increases by only 10 % (+ Offset of 6 ms) Goodput decreases only by 4.2 - 6.7 % (32% first fragment) Acknowledgements  Increase RTT by additional 16ms / fragment  Should be used for DPS calls that change the state of the Server or Client require reliability that is not offered by the protocol itself 11
  • 12. Dipl.-Inf. Peter Rothenpieler rothenpieler@itm.uni-luebeck.de http://www.itm.uni-luebeck.de/users/rothenpielerThank you for your attention!
  • 13. Dipl.-Inf. Peter Rothenpieler rothenpieler@itm.uni-luebeck.de http://www.itm.uni-luebeck.de/users/rothenpielerExample Exchange of IP Address & Sending of IP Packet Instead of receiving A, the Server will forward it using IPv6/6LoWPAN, if it is not the destination of the packet
  • 14. Dipl.-Inf. Peter Rothenpieler rothenpieler@itm.uni-luebeck.dehttp://www.itm.uni-luebeck.de/users/rothenpieler