Leveraging IP for Sensor Network Deployment Simon Duquennoy, Niklas Wirstr¨ om, Nicolas Tsiftes, Adam Dunkels IP+SN Workshop, Chicago, IL April 11th 2011
Incremental Sensornet Deployment Target deployments • Heterogeneous networks (applications, hardware) • Need for individual configuration (location, settings) • Need for individual programming (application) Usual deployment techniques • Network-wide programming • Based on dedicated, inflexible, error-prone solutions • Many failures in practice IP+SN Workshop 2011 1/ 10
Incremental Sensornet Deployment Target deployments • Heterogeneous networks (applications, hardware) • Need for individual configuration (location, settings) • Need for individual programming (application) Usual deployment techniques • Network-wide programming • Based on dedicated, inflexible, error-prone solutions • Many failures in practice What about using low-power IP? IP+SN Workshop 2011 1/ 10
IP-Based Deployment Leveraging standards for robustness • Addressing with IPv6 • Routing with RPL • Transport with CoAP/UDP or TCP Network layer interoperability • All nodes able to route IPv6 traffic • Applications built on top of IP • Configuration built on top of IP • Deployment built on top of IP IP+SN Workshop 2011 2/ 10
Methodology Steps • Implementation • Simulation (based on motes emulation) • Feasibility study: RPL, CoAP , . . . • Optimizations Implementation in Contiki • uIPv6 • ContikiRPL • CoAP and TCP-based deployment Typical deployment 1 The node integrates the RPL network 2 The node is configured (location, task, settings) 3 The node downloads a program from a server IP+SN Workshop 2011 3/ 10
Deployment with RPL 300 sink-last 2 random sink-first 1 . 5 duty cycle (%) 200 time (s) 1 100 0 . 5 sink-last random sink-first 0 0 0 2 4 6 8 0 2 4 6 8 node id node id Impact of the deployment order • Time dominated by installation interval (30 s) • Little impact on energy IP+SN Workshop 2011 4/ 10
Deployment with RPL 300 sink-last 2 random sink-first 1 . 5 duty cycle (%) 200 time (s) 1 100 0 . 5 sink-last random sink-first 0 0 0 2 4 6 8 0 2 4 6 8 node id node id Impact of the deployment order • Time dominated by installation interval (30 s) • Little impact on energy RPL is suitable for incremental deployment IP+SN Workshop 2011 4/ 10
Adapting the MAC for faster download Principle • Radio duty-cycling slows down the transfer • Using a more aggressive MAC during download Streaming • Keep radio on 1 second after last traffic • No more wake-up needed Snooping • Increase duty-cycle for 1 second after last traffic • Shortened synchro time IP+SN Workshop 2011 5/ 10
Streaming and Snooping – Results 50 6 Streaming Default Snooping Snooping Default Streaming 40 radio on-time (s) 4 time (s) 30 20 2 10 0 0 0 2 4 6 8 0 2 4 6 8 number of hops number of hops Results • Streaming is the fastest, Default the most energy-efficient • Snooping is a near-perfect trade-off! IP+SN Workshop 2011 6/ 10
Streaming and Snooping – Results 50 6 Streaming Default Snooping Snooping Default Streaming 40 radio on-time (s) 4 time (s) 30 20 2 10 0 0 0 2 4 6 8 0 2 4 6 8 number of hops number of hops Results • Streaming is the fastest, Default the most energy-efficient • Snooping is a near-perfect trade-off! Simple MAC tuning provide substantial improvements IP+SN Workshop 2011 6/ 10
TCP vs CoAP/UDP CoAP CoAP TCP TCP 20 radio on-time (s) 4 15 time (s) 10 2 5 0 0 Default Snooping Streaming Default Snooping Streaming duty cycling mode duty cycling mode Results • Implemented in simple packet-per-packet mode • Both solution provide comparable results IP+SN Workshop 2011 7/ 10
TCP vs CoAP/UDP CoAP CoAP TCP TCP 20 radio on-time (s) 4 15 time (s) 10 2 5 0 0 Default Snooping Streaming Default Snooping Streaming duty cycling mode duty cycling mode Results • Implemented in simple packet-per-packet mode • Both solution provide comparable results Existing transport layers are suitable IP+SN Workshop 2011 7/ 10
Avoiding Unicast-Based Flooding Problem • What if many nodes need the same app.? • This is targeted by Deluge-like solutions • Centralized IP-based would waste energy Idea: In-network Caching • Nodes keep a cache of downloaded apps. • Nodes can act as servers • Download from nearest instead of sink • Based on IP! IP+SN Workshop 2011 8/ 10
In-Network Caching – Results 50 no caching, sink-first no caching, sink-last 500 no caching, sink-last caching, sink-last caching, sink-last 40 no caching, sink-first 400 radio on-time (s) caching, sink-first caching, sink-first 30 time (s) 300 20 200 10 100 0 0 0 2 4 6 8 0 2 4 6 8 node id node id Results • Substantial time and energy improvements IP+SN Workshop 2011 9/ 10
In-Network Caching – Results 50 no caching, sink-first no caching, sink-last 500 no caching, sink-last caching, sink-last caching, sink-last 40 no caching, sink-first 400 radio on-time (s) caching, sink-first caching, sink-first 30 time (s) 300 20 200 10 100 0 0 0 2 4 6 8 0 2 4 6 8 node id node id Results • Substantial time and energy improvements All-IP facilitates rich node behavior IP+SN Workshop 2011 9/ 10
Conclusion & Future Work Towards IP-based deployment • Well-suited for heterogeneous networks • Based on well-known/well-tested standards Results • IPv6, RPL, CoAP , TCP are suitable • Simple MAC optims provide substantial improvements • IP level optimizations (apps caching) help a lot Towards an IP-based deployment tool • Full scale deployment tool • Need tesbed evaluation IP+SN Workshop 2011 10/ 10
Recommend
More recommend
