PURDUE UNIVERSITY Protocols For Wireless Sensor Networks Sunil

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

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

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

Application Taxonomy Broad spectrum of sensor network applications l Unique requirements for each application class l Application classes include l l l l 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 August 4, 2004 @ DAIICT, Gandhinagar 4

Protocol Issues for WSNs l Addressing l l Sensor Networks are application specific l l For MAC, routing, data tagging Is it necessary? Should it be unique? How to distribute addresses? High node density 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 August 4, 2004 @ DAIICT, Gandhinagar 5

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

Event Detection l Examples of applications l l Intruder detection, Breach of security, Fire detection, etc. Model of application class l l Network inactive unless event detected Events are rare (with some apriori frequency 1/T) l l Only one node detects an event Event reports are latency-constrained (delay < ) 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 August 4, 2004 @ DAIICT, Gandhinagar 7

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

AIMRP: Assumptions l Simple network geometry l l 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) l Each node has a communication radius of R. l AIMRP works best for event reporting applications l l l 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 August 4, 2004 @ DAIICT, Gandhinagar 9

AIMRP in a nutshell AIMRP: Active Configuration Phase RTR: anycast msg Message Source Optional Type MAC-Id Tier-Id Fields R CTR: unicast msg Message Source Destn Optional Type MAC-Id Tier-Id MAC-Id Fields R S DATA msg ACK msg August 4, 2004 @ DAIICT, Gandhinagar A L 2 R R 10

Configuration Phase: Schematic of TIER structure l Nodes organize themselves into annular tiers. l l l 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 August 4, 2004 @ DAIICT, Gandhinagar 11

Active Phase l 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. l RTR message contains l RSD - Random Source i. Dentifier l STD – Source Tier i. Dentifier (i. e. Tier_Id=n) l l This node then waits for a Clear_To_Send (CTR) message from some next-hop node. August 4, 2004 @ DAIICT, Gandhinagar 12

Active Phase l Assume that a node R receives this RTR message. Let RTD (Receiver TIER_ID). l l l 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 nexthop 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. August 4, 2004 @ DAIICT, Gandhinagar 13

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

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

Parameters Functions l 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) l l RTR, CTR: To avoid hidden terminal problem ACK: Ensure reliable delivery of DATA packet l l l August 4, 2004 @ DAIICT, Gandhinagar 16

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 August 4, 2004 @ DAIICT, Gandhinagar 17

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 August 4, 2004 @ DAIICT, Gandhinagar 18

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 August 4, 2004 @ DAIICT, Gandhinagar 19

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

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

Latency at Each Hop l k includes l tl+tg l l k 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 nexthop node wakes up from sleep state. = tg+tl+tb+tp+tsleep August 4, 2004 @ DAIICT, Gandhinagar 22

Choosing Proper σ l Minimum area of overlap = R 2(A+ 2 B-2 sin. A) where l l l cos. A=(3 2+1)/4 cos. B=(5 2 -1)/4 2 Waiting time (till next hop node wakes up) for node S exponential RV with mean R 2(A+ 2 B 2 sin. A) August 4, 2004 @ DAIICT, Gandhinagar 23

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

AIMRP: Energy Consumption Model l l 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 August 4, 2004 @ DAIICT, Gandhinagar 25

AIMRP: Notation August 4, 2004 N mean number of nodes ton “on time” in power-saving mode 1/ is mean sleeping interval T mean duration between sensor events tp transmission time for all packets tg guard time for listening (like DIFS) Tl, Tb RTR and CTR backoff windows resp. I mean of t(k)sleep t. RTR transmission time for RTR tw timeout for reattemting RTR L radius of region R communication range width to tier is R @ DAIICT, Gandhinagar 26

AIMRP: Performance Average Power Consumption l Energy per event report l Energy per hop l l Average number of hops August 4, 2004 @ DAIICT, Gandhinagar 27

AIMRP: Performance (contd. ) l Table of values used for comparison (with = 0. 5) l Results l AIMRP: l S-MAC: August 4, 2004 @ DAIICT, Gandhinagar 28

AIMRP: Performance (contd. ) Is there an optimum value for ? l Pavg is a complicated function of l Minimum (numerically calculated) around 0. 40. 5 l August 4, 2004 @ DAIICT, Gandhinagar 29

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

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

l Thank you! l Questions? l Comments? August 4, 2004 @ DAIICT, Gandhinagar 32