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

SHORT < RANGE > LONG LOW < DATA RATE > HIGH The Wireless Market TEXT GRAPHICS INTERNET HI-FI AUDIO STREAMING VIDEO DIGITAL MULTI-CHANNEL LAN 802.11b 802.11a/HL2 & 802.11g SHORT < RANGE > LONG Bluetooth 2 ZigBee PAN Bluetooth1 LOW < DATA RATE > HIGH

LIGHT COMMERCIAL CONTROL Applications BUILDING AUTOMATION CONSUMER ELECTRONICS security HVAC AMR lighting control access control TV VCR DVD/CD remote patient monitoring fitness monitoring PERSONAL HEALTH CARE PC & PERIPHERALS ZigBee Wireless Control that Simply Works mouse keyboard joystick Future applications include Toys and Games, like consoles controllers, portable game pads (like gameboys), educational toys like leap frog stuff, and fun toys like RC (remote control) toys, etc. INDUSTRIAL CONTROL RESIDENTIAL/ LIGHT COMMERCIAL CONTROL asset mgt process control environmental energy mgt security HVAC lighting control access control lawn & garden irrigation

Development of the Standard 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 APPLICATION Customer 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

ZigBee Application Framework 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 Low complexity: 26 service primitives versus 131 service primitives for 802.15.1 (Bluetooth) ZigBee Application Framework Networking App Layer (NWK) Channel scan for beacon is included, but it is left to the network layer to implement dynamic channel selection Data Link Controller (DLC) IEEE 802.15.4 LLC IEEE 802.2 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 and Bluetooth Optimized for different applications 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 protocol is optimized for timing critical 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 Request driven 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 Users specify 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: 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

Summary of the protocol

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

Design Considerations

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 Average delay 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 Average Dissipated Energy (Joules/Node/Received Event) 0.008 Omniscient Multicast 0.006 Diffusion 0.004 0.002 50 100 150 200 250 300 Network Size

Impact of In-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 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 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 50 100 150 200 250 300 Network Size Standard 802.11 is dominated by idle energy

Failures Dynamic failures Each source sends different signals 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 thorough performance evaluation is required

Extensions Push diffusion One-phase pull 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?

Geographic Routing for Sensor Networks

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

Geographic Routing: Greedy Routing Closest to D A 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 GF fails If the network is dense enough that each interior node has a neighbor in every 2/3 angular sector, GF will always succeed

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.

Haiyun Luo Fan Ye, Jerry Cheng Songwu Lu, Lixia Zhang UCLA CS Dept. TTDD: A Two-tier Data Dissemination Model for Large-scale Wireless Sensor Networks Haiyun Luo Fan Ye, Jerry Cheng Songwu Lu, Lixia Zhang UCLA CS Dept.

Sensor Network Model Sink Stimulus Source

Mobile Sink Excessive Power Consumption Increased Wireless Transmission Collisions State Maintenance Overhead

TTDD Basics Dissemination Node Data Announcement Source Data Sink Query Immediate Dissemination Node

TTDD Mobile Sinks Dissemination Node Trajectory Data Announcement Forwarding Data Announcement Source Immediate Dissemination Node Data Sink Immediate Dissemination Node Trajectory Forwarding

TTDD Multiple Mobile Sinks Source Dissemination Node Trajectory Forwarding Data Announcement Source Immediate Dissemination Node Data

Conclusion TTDD: two-tier data dissemination Model Proactive sources Exploit sensor nodes being stationary and location-aware Construct & maintain a grid structure with low overhead Proactive sources Localize sink mobility impact Infrastructure-approach in stationary sensor networks Efficiency & effectiveness in supporting mobile sinks