Protocols in Wireless Sensor Networks From Vision to Reality
ZigBee and 802.15.4 The MAC Layer
The ZigBee Alliance Solution • Targeted at home and building automation and controls, consumer electronics, toys etc. • Industry standard (IEEE 802.15.4 radios) • Primary drivers are simplicity, long battery life, networking capabilities, reliability, and cost • Short range and low data rate
TEXT GRAPHICS INTERNET HI-FI AUDIO STREAMING VIDEO DIGITAL VIDEO MULTI-CHANNEL VIDEO The Wireless Market LAN 802.11b 802.11a/HL2 & 802.11g SHORT < RANGE > LONG Bluetooth 2 ZigBee PAN Bluetooth1 LOW < DATA RATE > HIGH
Applications BUILDING AUTOMATION CONSUMER ELECTRONICS security HVAC AMR lighting control accesscontrol TV VCR DVD/CD remote PC & PERIPHERALS patient monitoring fitness monitoring PERSONAL HEALTH CARE ZigBee Wireless Control that Simply Works mouse keyboard joystick INDUSTRIAL CONTROL RESIDENTIAL/ LIGHT COMMERCIAL CONTROL asset mgt process control environmental energy mgt security HVAC lighting control access control lawn & garden irrigation
ZigBee Alliance 50+ companies Defining upper layers of protocol stack: from network to application, including application profiles IEEE 802.15.4 Working Group Defining lower layers : MAC and PHY Development of the Standard Customer APPLICATION ZIGBEE STACK ZigBee Alliance SILICON IEEE 802.15.4
IEEE 802.15.4 Basics • 802.15.4 is a simple packet data protocol: • CSMA/CA - Carrier Sense Multiple Access with collision avoidance • Optional time slotting and beacon structure • Three bands, 27 channels specified • 2.4 GHz: 16 channels, 250 kbps • 868.3 MHz : 1 channel, 20 kbps • 902-928 MHz: 10 channels, 40 kbps • Works well for: • Long battery life, selectable latency for controllers, sensors, remote monitoring and portable electronics
IEEE 802.15.4 standard • Includes layers up to and including Link Layer Control • LLC is standardized in 802.1 • Supports multiple network topologies including Star, Cluster Tree and Mesh ZigBee Application Framework • Low complexity: • 26 service primitives • versus • 131 service primitives • for 802.15.1 • (Bluetooth) Networking App Layer (NWK) Data Link Controller (DLC) IEEE 802.2 IEEE 802.15.4 LLC LLC, Type I IEEE 802.15.4 MAC IEEE 802.15.4 IEEE 802.15.4 868/915 MHz PHY 2400 MHz PHY
ZigBee Topology Models Mesh Star ZigBee coordinator Cluster Tree ZigBee Routers ZigBee End Devices
IEEE 802.15.4 Device Types • Three device types • Network Coordinator • Maintains overall network knowledge; most memory and computing power • Full Function Device • Carries full 802.15.4 functionality and all features specified by the standard; ideal for a network router function • Reduced Function Device • Carriers limited functionality; used for network edge devices • All of these devices can be no more complicated than the transceiver, a simple 8-bit MCU and a pair of AAA batteries!
ZigBee Smaller packets over large network Mostly Static networks with many, infrequently used devices Home automation, toys remote controls Energy saver!!! Bluetooth Larger packets over small network Ad-hoc networks File transfer; streaming Cable replacement for items like screen graphics, pictures, hands-free audio, Mobile phones, headsets, PDAs, etc. ZigBee and Bluetooth Optimized for different applications
ZigBee and Bluetooth Timing Considerations • ZigBee: • Network join time = 30ms typically • Sleeping slave changing to active = 15ms typically • Active slave channel access time = 15ms typically • Bluetooth: • Network join time = >3s • Sleeping slave changing to active = 3s typically • Active slave channel access time = 2ms typically ZigBee protocol is optimized for timing critical applications
Directed Diffusion:A Scalable and Robust Communication Paradigm for Sensor Networks
Motivation • Properties of Sensor Networks • Data centric • No central authority • Resource constrained • Nodes are tied to physical locations • Nodes may not know the topology • Nodes are generally stationary • How can we get data from the sensors?
Directed Diffusion • Data centric • Individual nodes are unimportant • Request driven • Sinks place requests as interests • Sources satisfying the interest can be found • Intermediate nodes route data toward sinks • Localized repair and reinforcement • Multi-path delivery for multiple sources, sinks, and queries
Motivating Example • Sensor nodes are monitoring animals • Users are interested in receiving data for all 4-legged creatures seen in a rectangle • Usersspecify the data rate
Interest and Event Naming • Query/interest: • Type=four-legged animal • Interval=20ms (event data rate) • Duration=10 seconds (time to cache) • Rect=[-100, 100, 200, 400] • Reply: • Type=four-legged animal • Instance = elephant • Location = [125, 220] • Intensity = 0.6 • Confidence = 0.85 • Timestamp = 01:20:40 • Attribute-Value pairs, no advanced naming scheme
Directed Diffusion • Sinks broadcast interest to neighbors • Initially specify a low data rate just to find sources for minimal energy consumptions • Interests are cached by neighbors • Gradients are set up pointing back to where interests came from • Once a source receives an interest, it routes measurements along gradients
Interest Propagation • Flood interest • Constrained or Directional flooding based on location is possible • Directional propagation based on previously cached data Gradient Source Interest Sink
Data Propagation • Multipath routing • Consider each gradient’s link quality Gradient Source Data Sink
Reinforcement • Reinforce one of the neighbor after receiving initial data. • Neighbor who consistently performs better than others • Neighbor from whom most events received Gradient Source Data Reinforcement Sink
Negative Reinforcement • Explicitly degrade the path by re-sending interest with lower data rate. • Time out: Without periodic reinforcement, a gradient will be torn down Gradient Source Data Reinforcement Sink
Sampling & forwarding • Sensors match signature waveforms from codebook against observations • Sensors match data against interest cache, compute highest event rate request from all gradients, and (re) sample events at this rate • Receiving node: • Find matching entry in interest cache • If no match, silently drop • Check and update data cache (loop prevention, aggregation) • Resend message along all the active gradients, adjusting the frequency if necessary
Evaluation • ns2 simulation • Modified 802.11 MAC for energy use calculation • Idle time: 35mW • Receive: 395mw • Transmit: 660mw • Baselines • Flooding • Omniscient multicast: A source multicast its event to all sources using the shortest path multicast tree • Do not consider the tree construction cost
Simulate node failures • No overload • Random node placement • 50 to 250 nodes (increment by 50) • 50 nodes are deployed in 160m * 160m • Increase the sensor field size to keep the density constant for a larger number of nodes • 40m radio range
Metrics • Average dissipated energy • Ratio of total energy expended per node to number of distinct events received at sink • Measures average work budget • Average delay • Average one-way latency between event transmission and reception at sink • Measures temporal accuracy of location estimates • Both measured as functions of network size
Average Dissipated Energy They claim diffusion can outperform omniscient multicast due to in-network processing & suppression. For example, multiple sources can detect a four-legged animal in one area. 0.018 0.016 Flooding 0.014 0.012 0.01 0.008 Omniscient Multicast (Joules/Node/Received Event) Average Dissipated Energy 0.006 Diffusion 0.004 0.002 0 0 50 100 150 200 250 300 Network Size
Impact ofIn-network Processing 0.025 Diffusion Without Suppression 0.02 0.015 (Joules/Node/Received Event) Average Dissipated Energy 0.01 Diffusion With Suppression 0.005 0 0 50 100 150 200 250 300 Network Size
Impact of Negative Reinforcement 0.012 0.01 Diffusion Without Negative Reinforcement 0.008 Average Dissipated Energy (Joules/Node/Received Event) 0.006 0.004 Diffusion With Negative Reinforcement 0.002 0 0 50 100 150 200 250 300 Network Size Reducing high-rate paths in steady state is critical
Average Dissipated Energy (802.11 energy model) 0.14 Diffusion 0.12 Flooding Omniscient Multicast 0.1 0.08 Average Dissipated Energy (Joules/Node/Received Event) 0.06 0.04 0.02 0 0 50 100 150 200 250 300 Network Size • Standard 802.11 is dominated by idle energy
Failures • Dynamic failures • 10-20% failure at any time • Each source sends different signals • <20% delay increase, fairly robust • Energy efficiency improves: • Reinforcement maintains adequate number of high quality paths • Shouldn’t it be done in the first place?
Analysis • Energy gains are dependent on 802.11 energy assumptions • Can the network always deliver at the interest’s requested rate? • Can diffusion handle overloads? • Does reinforcement actually work?
Conclusions • Data-centric communication between sources and sinks • Aggregation and duplicate suppression • More thoroughperformance evaluation is required
Extensions • Push diffusion • Sink does not flood interest • Source detecting events disseminate exploratory data across the network • Sink having corresponding interest reinforces one of the paths • One-phase pull • Propagate interest • A receiving node pick the link that delivered the interest first • Assumes the link bidirectionality
TEEN (Threshold-sensitive Energy Efficient sensor Network protocol) • Push-based data centric protocol • Nodes immediately transmit a sensed value exceeding the threshold to its cluster head that forwards the data to the sink
LEACH [HICSS00] • Proposed for continuous data gathering protocol • Divide the network into clusters • Cluster head periodically collect & aggregate/compress the data in the cluster using TDMA • Periodically rotate cluster heads for load balancing
Discussions • Criteria to evaluate data-centric routing protocols? • Or, what do we need to try to optimize? Energy consumption? Data timeliness? Resilience? Confidence of event detection? Too many objectives already? Can we pick just one or two?
Motivation • A sensor net consists of hundreds or thousands of nodes • Scalability is the issue • Existing ad hoc net protocols, e.g., DSR, AODV, ZRP, require nodes to cache e2e route information • Dynamic topology changes • Mobility • Reduce caching overhead • Hierarchical routing is usually based on well defined, rarely changing administrative boundaries • Geographic routing • Use location for routing • Assumptions • Every node knows its location • Positioning devices like GPS • Localization • A source can get the location of the destination
Closest to D A Geographic Routing: Greedy Routing S D • Find neighbors who are the closer to the destination • Forward the packet to the neighbor closest to the destination
Greedy Forwarding does NOT always work • If the network is dense enough that each interior node has a neighbor in every 2/3 angular sector, GF will always succeed GF fails
Dealing with Void • Apply the right-hand rule to traverse the edges of a void • Pick the next anticlockwise edge • Traditionally used to get out of a maze
Impact of Sensing Coverage on Greedy Geographic Routing Algorithms Guoliang Xing, Chenyang Lu, Robert Pless, Qingfeng Huang IEEE Trans. Parallel Distributed System
Metrics b v u c a
Theorem. • Definition: A network is sensing-covered if any point in the deployment region of the network is covered by at least one node. • In a sensing-covered network, GF can always find a routing path between any two nodes. Furthermore, in each step (other than the last step arriving at the destination), a node can always find a next-hop node that is more than Rc-2Rs closer (in terms of both Euclidean and projected distance) to the destination than itself.
GF always finds a next-hop node • Since Rc >> 2Rs, point a must be outside of the sensing circle of si. • Since a is covered, there must be at least one node, say w, inside the circle C(a, Rs).
Theorem • In a sensing-covered network, GF can always find a routing path between source u and destination v no longer than hops.