Energy Efficient Routing

1. LAMAR UNIVERISTY Computer Science Department Energy Efficient Routing By Rui Luo Supervisor: Dr. Lawrence J. Osborne Committee Member: Dr. Chung-Chih Li Committee Member: Dr. Bo Sun Fall 2005

2. Agenda • Background • Sensor, WSNs, TinyOS, Applications • Current Routing Protocols In WSNs • Reviews, Compare • Algorithm Design • Target Model, Principle, Algorithm • Implementation • Platform, Issues, Architecture • Testing • Methodology, Simulator, Chat • Conclusion and Future Work

3. Sensor and WSNs • Poor powered • Battery, Ambient Energy (solar cell) • Constrained computing resource • Memory space • CPU • Limited Communication abilities • Low bandwidth • Transmission range Agenda

4. Applications • Habitat Monitoring • (Event-driven, Randomized Deployment) • Environment Observation and Forecasting (EOFS) • (Time-driven, Query-driven) • Health Applications • (Event-driven, Time-driven) • Structure Health Monitoring (SHM) • (Deterministic Deployment) • Home, Office Applications, and Other Agenda

5. WSNs vs. MANETs Application Dependent Routing is known Low Bandwidth Weak Nodes Usually Stationary WSNs Limited Transmission Range MANETs Powerful Nodes, High Bandwidth, Application Independent, Routing created on Demand, Nodes come and go Agenda

6. WSNs Design Issues • Challenges • Global address scheme • Data need to be routed to a particular BS • Constrained abilities of nodes • Stationary & Mobility • Application dependent • Position awareness • Redundancy data Agenda

7. Tiny OS • Component Based • Rapid development, Small size binary • Event Driven • Save more energy • Multi-Hardware platform • Berkeley/Crossbow mica2: 3rd generation, wireless reprogramming Agenda

8. Routing Protocol Review • By network structure • Flat Network, Hierarchical Networks, Geographic Information Based • By protocol operation • Negotiation based, Multi-Path based, QoS based, Coherent based Agenda

9. Routing Protocol Comparison • Small Minimum Energy Communication Network (MECN) • GPS, has to compute relay region • Our protocol • GPS free, no relay region computation Agenda

10. Target Model • Over densed deployment • Stationary • Nodes send data to the root node • Battery changing is reasonable • Demand lifetime of the whole network is much longer than a single life time of each sensor. Agenda

11. Principle • Radio Propagation Model • Near field zone • Signal strength is strong, but very short • Free space path loss zone • 20 dB/decade, radio travel through the air • Excess path loss zone. • 20-50 dB/decade, affected by the ground Agenda

12. Principle Cont. • Friis equation: • GTx = transmitter antenna gain • GRx = receiver antenna gain • λ = wavelength (same units as d) • d = distance separating Tx and Rx antennas • L = system loss factor (≥ 1) Agenda

13. Principle Cont. • Key idea: • To reach the distance two times far away, we need four times transmission power. • Note: • In read world, the index is not constant and usually between 2 to 4. Agenda

14. Principle Cont. • Shown by graph • Two ways to get D from S • Send to D directly • Less transmission delay • Use more energy • More chance collision • Hop by R • More transmission delay • Use less energy • Less chance collision D R S Agenda

15. Principle Cont. • Most Energy Efficient Region (MEER) • Definition: A region in which a relay node is preferred if total energy is the concerned metric. • Shape: Draw the shape according to the definition in Matlab • Note: Not necessary to be in 2-D space. Agenda

16. Algorithm: Principle Cont. • Shape of MEER for attenuation rate index equal to 3 Agenda

17. Algorithm • Problem: • Limited transmission range • GPS is expensive. • In real world, space is twisted. Agenda

18. Protocol • Approximate by considering one hop Agenda

19. Implementation: Platform • Red Hat Linux 9.0 • Tiny OS 1.1.0 • ncc 1.1.1 (source) • 1.1.2 is not compatible with gcc-3.2.2 • gcc 3.2.2 • IBM-JDK 1.3 for Linux • Tiny OS cannot be installed normally for 1.4 • Atemu 0.4 (source) Agenda

20. Implementation Issues • Memory Constrain • Mica2: 4k RAM, 512K ROM • Ram usage (byte): • TinyDB: less than 3100, Moté: 849 • Our program: about 1k ram, most of them are used for outgoing buffer • Transmission Power • Network density is controllable • Max=150, reaches 100m in Atemu • PM start=1, increment=10 Agenda

21. Implementation Issues Cont. • Packet loss • Causes: exposed node, Outgoing buffer full • Solution • Avoid packet loss by a big buffer in test • In real application, the buffer can be small • Dynamic memory management? • Advantages: more adaptive, flexible • Disadvantages: more CPU load • Choose: Static memory allocation Agenda

22. Implementation Issues Cont. • AM message or Low level Comm.? • Goal • Make the program easy to be used • Allow other protocols run in one application • Choose • AM message with direct control to radio mode. Agenda

23. SimpleApp EnergyEfficiencyRoutingC LoggerC CC1000Control GenericComm TimerC LedsC UARTM Other Tiny OS Components Needed by SimpleApp Implementation: Architecture Agenda

24. Logger UART ATEMU port I/O simulator I/O sniffer Log File Implementation: Debugging • Problem: • Atemu logs the low level events • Good for simple program debugging • Not good for a distributed protocol debugging Agenda

25. Implementation: Log File • Sample • 000 -- system timer: 0 4 • 000 <pmack> to 7 • 006 <pmack> to 1 • 007 parent ETOR power 0 21 21 • 001 parent ETOR power 6 32 21 • 006 <pmack> to 7 • 007 drop pmack from 6 • 008 <pm> 31 • 007 <pm> 31 Agenda

26. Implementation: Log File Analysis • Unix text tool • Example: Show final topology • #!/bin/bash • for i in `cut -b1-3 $1 | sort -u` • do • grep ^$i $1 | grep parent | tail -n 1 • done • Eegraph • Will be told later Agenda

27. Implementation: Auto ID • Problem • Node ID is hard coded into programs • TOSSIM does substitution automatically • Atemu does not. • Solution • Modify the source code of Tiny OS • Modify the default Makefile • A bash script is used to iterate the node id Agenda

28. Testing: Methodology • Simulator • TOSSIM • Simple, no high fidelity • Ns2 • Classical, not feasible for low level simulation • Atemu: • High fidelity, slow, no future support • Avrora • New, high fidelity, fast • Current not support IBM-JAVA Agenda

29. Testing: Methodology Cont. • Visual tool: eegraph • Functionalities • Visualize the log file • Output data for chart Agenda

30. Testing: Metrics • Topology • Total ETOR • Cost for data transmission • Number of the node in the network (N) • Total energy consumption (TEC) • Cost for this protocol Agenda

31. Testing: Topology – Starting Power • Node 14,2,6 • Rough detection of 2,6 • Node 15,13,17 • Direct reachable to 17 • Conclusion • Height of the tree • Transmission delay S=1 S=40 Agenda

32. Testing: Constructing – Starting Po... • Conclusion • No obvious relationship between constructing time and starting power Agenda

33. Testing: total ETOR-Starting Power • Conclusion • Higher starting power results in higher total ETOR Agenda

34. Testing: TEC – Starting power • Conclusion • A higher starting power results in less total energy consumption. However, this effect is not obvious at the beginning. Agenda

35. Testing: Topology - Increment • Conclusion • Height of the tree • Transmission delay i=10 i=60 Agenda

36. Testing: Constructing – Increment • Conclusion • Higher increment results in fast network constructing. Agenda

37. Testing: Total ETOR-Increment • Conclusion • A higher increment results in higher total ETOR Agenda

38. Testing: TEC - Increment • Conclusion • Higher increment results in lower TEC Agenda

39. Testing: Topology - Fixed • Fixed transmission power is equal to the view of network density • Topology for different densities Agenda

40. Testing: Constructing - Fix • Conclusion • Higher transmission power results in fast network construction. • Network density is one of the most important factors. Agenda

41. Testing: total ETOR - fix • Conclusion • Either blue or green is not good • Yellow is preferred • Network density is one of the most important factors Agenda

42. Testing: TEC - Fix • Conclusion • Higher trans. power results in higher TEC • A modified protocol can be used to stop using energy after the network setting up, hence trans. power has less relationship with TEC. Agenda

43. Future Work • How to use the protocol in a hierarchical network • Adaptive TPC period • More testing in real world applications Agenda

44. Conclusion • The algorithm is quite applicable in an over-densed network. • The algorithm can behave differently to meet the transmission delay metric. • Compare with the shortest path algorithm, the new algorithm saves more energy and introduces more transmission delay.

45. References • Mica2 Mote Datasheet • Jamal N. Al-Karaki, Ahmed E. Kamal. ”Routing Techniques in Wireless Sensor Networks: A Survey” • Ning Xu, “A Survey of Sensor Network Applications” • H.T. Friis, “Introduction to radio and radio antennas” • Jonathan Polley, Dionysys Blazakis, Jonathan McGee, Dan Rusk, John S. Baras, “ATEMU: A Fine-grained Sensor Network Simulator” • V. Rodoplu and T. H. Meng, “Minimum Energy Mobile Wireless Networks" Agenda

46. Questions? Agenda