Protocols For Wireless Sensor Networks

1. Protocols For Wireless Sensor Networks PURDUE UNIVERSITY Sunil Suresh Kulkarni School of Electrical and Computer EngineeringPurdue University Part of this work has been done jointly with Aravind Iyer and Prof. Catherine Rosenberg. @ DAIICT, Gandhinagar

2. Motivation for Studying Protocols in Wireless Sensor Networks • Why and where sensor networks? • Wireless Sensor Network Characteristics • Large number of sensor nodes  dense networks • Sensor networks have an objective to perform, no node specific objective • Application specific design and deployment of nodes and networks @ DAIICT, Gandhinagar

3. Why sensor networks are different? • Sensor networks are neither Ad-Hoc networks nor cellular networks. • Nodes have some sensing coverage and can do data aggregation • Random or predetermined deployment • Nodes limited with energy, computational capabilities, communication range etc. • Failure prone nodes @ DAIICT, Gandhinagar

4. Application Taxonomy • Broad spectrum of sensor network applications • Unique requirements for each application class • Application classes include • Event detection • Continuous monitoring • Sink-initiated data gathering • Object tracking • Hybrid of the above • Classification enables a focused design to cater to a particular application class @ DAIICT, Gandhinagar

5. Protocol Issues for WSNs • Addressing • For MAC, routing, data tagging • Is it necessary? Should it be unique? How to distribute addresses? • High node density • Sensor Networks are application specific • What should be the comparison criterion? Energy Efficiency? Lifetime? Throughput? Percentage of missed detections? • Many-to-few communication pattern • Other issues – data aggregation, reliability. • Protocol overheads and complexity @ DAIICT, Gandhinagar

6. Related Work • Medium Access Control (MAC) • Random Access • Aloha, Slotted Aloha, 802.11, S-MAC • Controlled Access • TDMA, CDMA, Hybrid • Routing protocols such as DSR, AODV, DSDV (mainly for Ad-hoc networks) and Directed Diffusion • Application/Node Specific Architectures • LEACH, STEM, SPAN etc. @ DAIICT, Gandhinagar

7. Event Detection • Examples of applications • Intruder detection, Breach of security, Fire detection, etc. • Model of application class • Network inactive unless event detected • Events are rare (with some apriori frequency 1/T) • Only one node detects an event • Event reports are latency-constrained (delay < t) • Should contain some location information about event (beyond our scope) • No previous work on MAC and routing for event detection and integration of these layers @ DAIICT, Gandhinagar

8. AIMRP: Key Features • AIMRP is an Address-light Integrated MAC and Routing Protocol • Address-light protocol design • Short random address for MAC identifiers • Tier based addresses for routing instead of per-node addresses • Integrated MAC and routing • Minimize protocol overheads using many-to-one communication pattern • Power saving mode • Nodes sleep when their radio modules are not in use. • Probabilistic latency guarantees are satisfied. • Energy consumption analysis and comparison with SMAC • Validation by simulation @ DAIICT, Gandhinagar

9. AIMRP: Assumptions • Simple network geometry • A circular region of interest with radius L • Base station at the center of the region • N number of nodes are distributed in the region (node density of λ nodes/unit area) • Each node has a communication radius of R. • AIMRP works best for event reporting applications • Events are assumed to be rare, with an apriori frequency of one event per T units of time (approximately) • We assume that only one node detects the event @ DAIICT, Gandhinagar

10. Message Type Source MAC-Id Source Tier-Id Optional Fields Message Type Source MAC-Id Source Tier-Id Destn MAC-Id Optional Fields AIMRP in a nutshell AIMRP: Active Phase AIMRP: Configuration Phase RTR: anycastmsg R A CTR: unicast msg R L S aR 2aR DATAmsg ACKmsg @ DAIICT, Gandhinagar

11. Configuration Phase: Schematic of TIER structure • Nodes organize themselves into annular tiers. • The base station sends TIER message with a comm. radius of nαR. N = 1,… • The TIER_ID for TIER id message is n. • α is a design parameter @ DAIICT, Gandhinagar

12. Active Phase • Assume that a node S in tier n has some data to be sent to the base station. • The node sends a Request_To_Relay (RTR) message to neighboring nodes. • RTR message contains • RSD - Random Source iDentifier • STD – Source Tier iDentifier (i.e. Tier_Id=n) • This node then waits for a Clear_To_Send (CTR) message from some next-hop node. @ DAIICT, Gandhinagar

13. Active Phase • Assume that a node R receives this RTR message. Let RTD (Receiver TIER_ID). • If STD > RTD then node R can act as next-hop node for node S; otherwise not. • Assume STD > RTD. Then node R waits for some random time (0 to Tb) before sending the CTR message indicating its willingness to act as next-hop node for the current data from node S. • If it hears another CTR message (or DATA message from node S) from another receiver then node R does not reply with CTR. @ DAIICT, Gandhinagar

14. Tier-Based Routing • Routing is done on a tier-by-tier basis • Each node in tier n forwards its own data or data forwarded by upper tiers (>n) to lower tiers (<n). • This forwarding is done without specific addressing and without specific route set-up. Thus the per-node addressing is replaced by tier-ids. @ DAIICT, Gandhinagar

15. Protocol State Diagram and Message Formats • RTR: Request To Relay • CTR: Clear To Relay • DATA: Data Packet • ACK: Ack to DATA • TIER: Initial Tier formation messages @ DAIICT, Gandhinagar

16. Parameters Functions • tg: Guard time to reliably estimate the (busy/idle) channel state (50 µS) • tl: Time to listen to prevent collisions of packets from multiple nodes waking up due to a single event (500 µS) • tb: Back-off timer to avoid collision of CTR messages (500 µS) • tw: Waiting time to infer either unavailability of next-hop node or erroneous RTR transmission (600 µS) • td: Waiting time to infer erroneous DATA transmission (50 µS) • ta: Waiting time to infer erroneous ACK message (50 µS) • RTR, CTR: To avoid hidden terminal problem • ACK: Ensure reliable delivery of DATA packet @ DAIICT, Gandhinagar

17. Protocol Details In Listener State If a node hears RTR If from TIER > n Choose t_b and back-off (remain in listener state) If a node hears CTR or DATA before back-off expiry be silent (listener state) Else On back-off expiry send CTR Wait for DATA (receiver state) for time t_d on expiry of t_d timer go to listener state If a node hears any other message than CTR be silent (be in listener state) If a node has outstanding data Do carrier sensing for t_g+t_l On free channel send RTR Wait for CTR for time t_w On expiry of t_w timer return to listener state @ DAIICT, Gandhinagar

18. Protocol Details In a requesting state If a node hears RTR Go back to Listen State Act as if you have received RTR in a listener state If a node hears CTR If this is destined for this node send data Wait For ACK for time t_a On expiry of t_a timer return to listener state Else go back to listener state If you hear DATA or ACK go back to listener state @ DAIICT, Gandhinagar

19. Protocol Details In a sending state If a node hears ACK and no outstanding data go to listener state If a node hears any message other than ACK, wait for t_a timer to expire and remain in sending state In receiving state If you hear DATA receive and return to listener state Else wait for timer t_d to expire and return to listener state @ DAIICT, Gandhinagar

20. Power-Saving Mode • Idle listening is the major part sensor node energy consumption. • We propose a power saving state • Nodes in Listener state decide to sleep asynchronously. • Sleep times are (mean σ) exponentially distributed • Nodes remain awake for some predetermined time (ton=1100µS). @ DAIICT, Gandhinagar

21. Latency Constraint • The sleep time is chosen so that latency constraints of event reports is guaranteed. • Let k denote the delay encountered in the kth hop, out of H hops. Let HA = ceil (L/αR). • In worst case any packets must not experience a delay greater than  with probability greater than Φ. • i.e., the probabilistic latency constraint is given asP{∑k=1…HAk ) 1-Φ @ DAIICT, Gandhinagar

22. Latency at Each Hop • k includes • tl+tg the time node S waits before sending an RTR packet, • tb the time node S waits before receiving CTR packet. • tp the total time for transmission of the RTR, CTR, DATA and ACK packets • tsleep the time node S has to wait till one of its next-hop node wakes up from sleep state. • k = tg+tl+tb+tp+tsleeptsleep @ DAIICT, Gandhinagar

23. Choosing Proper σ • Minimum area of overlap = R2(A+2B-2sinA) where • cosA=(32+1)/4 • cosB=(52-1)/42 • Waiting time (till next hop node wakes up) for node S  exponential RV with mean R2(A+2B-2sinA) @ DAIICT, Gandhinagar

24. Choosing Proper σ • Let sleep=∑k=1…HA tsleep(k). Then sleep is an Erlang distributed RV. • Latency Constraint  P{sleep)  1-Φ • The above equation can be solved numerically, but we also give an approximate closed form solution as follows. • Similar calculations can be done for S-MAC and sleep/wake cycle length can be found (Tsw) @ DAIICT, Gandhinagar

25. AIMRP: Energy Consumption Model • Model borrowed from MIT µamps • Eup = Pontup – energy to bring radio transceiver up from sleep • Edw = Pontdw – energy to put radio to sleep • Pon – power consumed when radio is on • Ptr – additional power when radio is transmitting @ DAIICT, Gandhinagar

26. AIMRP: Notation @ DAIICT, Gandhinagar

27. AIMRP: Performance • Average Power Consumption • Energy per event report • Energy per hop • Average number of hops @ DAIICT, Gandhinagar

28. AIMRP: Performance (contd.) • Table of values used for comparison (with a = 0.5) • Results • AIMRP: • S-MAC: @ DAIICT, Gandhinagar

29. AIMRP: Performance (contd.) • Is there an optimum value for a? • Pavg is a complicated function of a • Minimum (numerically calculated) around 0.4-0.5 @ DAIICT, Gandhinagar

30. AIMRP: Performance (contd.) • Average power consumption versus various parameters: l, T and t • Independent of l; decreases with T and t @ DAIICT, Gandhinagar

31. Conclusions and Extensions • Simple model for event detection • Events equally likely in region of interest • Some apriori frequency • Protocol based on some assumptions • Only one node detects each event • Energy calculations based on assumption • Events are rare • No bursts of many events • Protocol would survive with perhaps a degraded performance @ DAIICT, Gandhinagar

32. Thank you! • Questions? • Comments? @ DAIICT, Gandhinagar