470 likes | 555 Views
uCast Unified Connectionless Multicast for Energy Efficient Content Distribution in Sensor Networks. Qing Tao, Tian He, Tarek Abdelzaher Presented By Andrew Connors. Introduction. This paper introduces uCast: Connection-less protocol Does not keep state in any intermediate node
E N D
uCastUnified Connectionless Multicast for Energy Efficient Content Distribution in Sensor Networks Qing Tao, Tian He, Tarek Abdelzaher Presented By Andrew Connors
Introduction • This paper introduces uCast: • Connection-less protocol Does not keep state in any intermediate node Keeps list of destination addresses in message headers Forwarding decisions made at each node • Uses underlying unicast protocols Defines simple interface to use “distance” embedded in unicast protocol • And demonstrates performance improvements
Sensor Challenges • Extremely Energy Constrained • Short battery life • Use conservation protocols • Limited Memory • 4K bytes on Mica2/MicaZ • Dynamic • For this paper this means topology changes due to nodes entering sleep states • Not changes due to sensor movement
Unicast • Used to send packets to single destination
Unicast • Multiple addressing schemes: • Identifier • Geographical location • Network Encoding
Unicast • Identifier • No topology information • Requires routing tables • Uses flooding to establish routes • Examples for ad-hoc networks include • Dynamic Source Routing (DSR) • Ad-Hoc, On Demand Distance Vector Routing (AODV)
Unicast • Geographical location • Each node is location aware using GPS or localization • Location approximate relative topology • Do not need flooding as only local information is used for routing • Examples include • Greedy Perimeter Stateless Routing (GPSR) • GEographical DIstance Routing (GEDIR) • GEDIR + FACE-2 + GEDIR (GFG) • Location Aided Routing (LAR)
Unicast • Network Encoding • Topology information encoded in identifier • Identifiers directly used for routing • No flooding needed • Examples include • Virtual location-based geographical routing • Logical coordinate-based routing (LCR) • Graph embedded-based routing (GEM)
Multicast • Used to send packets to multiple destinations
Multicast • Three types of multicast: • Sensor Networks • Ad-Hoc Networks • Internet
Multicast • Sensor Network Multicast Protocols • Geocast Destinations located within geographical region • Mobicast Spatiotemporal multicast where destinations are in a moving zone and the goal is to deliver packets just in time to zone for tracking purposes • Data Caching & Placement Uses multicast for asynchronous data updates • Two-Tier Data Dissemination (TTDD) Optimized for mobile sinks and uses a grid structure combined with localized flooding to track sinks (users that collects these data reports from the sensor network)
Multicast • Ad-Hoc Network Multicast Protocols • Tree-Based For example Ad-hoc On-Demand Distance Vector Routing (AODV), that builds multicast trees on-demand to connect members • Mesh-Based For example, core-assisted mesh protocol (CAMP) forms multicast meshes (higher connectivity graphs than trees) for each multicast group • Group-Based For example, On-Demand Multicast Routing Protocol (ODMRP) also mesh based but also uses forwarding groups
Multicast • Internet Multicast Protocols • Internet Group Management Protocol (IGMP) Used to maintain groups of multicast members by IP and routes through existing routers to optimize delivery through network • Distance Vector Multicast Routing Protocol (DVMRP) Used to share information between routers to transport multicast packets, and each router generates a router table for multicast group • Explicit Multi-Unicast (Xcast) Does not use multicast addresses but places IP addresses of destinations into headers, but still relies on routing tables and a single unicast protocol
Related Work • Existing protocols for sensor, ad-hoc or IP networks are not suitable for dynamic sensor networks • Either do not use unicast or only one specific unicast protocol – and difficult to maintain multiple protocols in small memory footprint • Construction of overlays expensive – uses flooding to maintain topology – uses too much energy • Designed more for laptops not sensors • Rely on routing tables and/or connection state – again difficult to implement in small memory
Connection-Less Threshold • When to use a connection-less protocol versus connection based Cost per Member Cost Threshold (Conceptual) Application Domain of uCast Connection-based Multicast Fewer Members/Light Traffic per Session More Members/Heavy Traffic per Session
uCast Design • Uses underlying unicast protocol through single interface to facilitate a pair-wise comparison to obtain “closest” to destination • Implements a scoreboard algorithm executed at intermediate nodes using destination list and current node neighbors and generates a multicast task allocation of a list of next hop nodes that should receive multicast packet
Unicast Interface • Defines only one method: compare (Node N1, Node N2, Node Dest) • Which returns the selected “nearest” Node to the Destination node
Scoreboard Algorithm INPUT Destination Set (DS), Neighbor Set NS, and Current Node (S) FOR EACH node in NS that are in DS, set selected in NS and move from DS into Covered Set (CS) FOR EACH node in DS, if only one neighbor in NS closer than S, set that node in NS to selected, and move from DS into CS FOR EACH node is DS, if no neighbor in NS closer than S move from DS to Local Maximum Set (LS) FOR EACH node in SN, find all destinations for which it closer compared to S, move those from DS to CS
Scoreboard Algorithm WHILE DS is NOT EMPTY FOR EACH node in DS, find all unselected nodes in NS, set each node with a score of 0, assign one more score to node closer to S to node in DS FIND unselected node K in NS with highest score, break ties randomly or using node ID, set K to selected FOR EACH node is DS, find nodes for which K is closer than current node S and move them from DS to CS FOR EACH node in SN, find all destinations for which it closer compared to S, move those from DS to CS
Scoreboard Algorithm FINALLY PERFORM OPTIMIZATION FOR EACH node in NS that are selected insert into SN FOR EACH destination in CS choose the best node, snode, among nodes in SN (i.e. “closest” to that CS node) add destination to SD set of snode FOR EACH node is NS, remove nodes with empty SD, for other nodes form individual delivery tasks based on SD IF LS is not empty, switch to underlying unicast protocol and corresponding local maximum handling approach to deliver packets to destination in LS
51 52 52 53 54 54 55 55 51 42 43 43 53 44 45 41 35 31 32 33 34 23 33 22 22 24 24 25 21 11 12 13 14 15 15 11 Detailed Example S = N53 DS { N51,N55 } NS { N52,N54,N43 } Score { 1 1 0} CS { N51} DS { N55} NS { N52,N54,N43 } Score { _ 1 0} CS { N51,,N55} SN { N52,N54 } { N51} => N52 { N55} => N54 S = N53 DS { N51,N55 } NS { N52,N54,N43 } S = N22 DS { N51,N15,N55 } NS { N21,N31,N32,N33,N23,N13,N12 Score { 1 1 2 3 2 1 1} CS { N51,N15,N55 } SN { N33 } { N51,N15,N55 } => N33 S = N22 DS { N51,N15,N55 } NS { N21,N31,N32,N33,N23,N13,N12 } S = N33 DS {N51,N15,N55} NS{N32,N42,N43,N44,N34,N24,N23,N22} Score {1 1 2 1 2 1 1 0} CS { N51,N55 } DS {N15} NS{N32,N42,N43,N44,N34,N24,N23,N22} Score {0 0 _ 0 0 1 0 0} CS { N51,N55,N15 } SN { N43,N24 } { N51,N55 } => N43 { N15} => N24 S = N33 DS {N51,N15,N55} NS {N32,N42,N43,N44,N34,N24,N23,N22} S = N11 DS {} NS { N21,N22,N12 } Score { 2 3 2 } CS { N51,N15,N55 } SN { N22 } { N51,N15,N55 } => N22 S = N11 DS { N51,N15,N55 } NS { N21,N22,N12 }
Handling Local Minima 51 52 53 54 55 55 51 42 43 43 44 45 41 35 31 32 33 34 23 22 33 22 24 24 25 21 11 12 13 14 15 15 11 42 44 32 34
Design Tradeoffs • Uses greedy algorithm – may not be globally optimal • Limit to maximum number of destinations due to packet header size limitations • However, is at least as good as the NP-Complete Set Cover problem • To be globally optimal would need another NP-Complete problem - Steiner tree generation – but cannot be generated in reasonable time due to large number of nodes
Optimality Analysis • Use simulation • With nodes having range of 50m • In 500m x 500m region • Source node placed an (250, 250) • 6 destination nodes in 60 degree region • At least six hops in each route • Each scenario tested for 100 rounds • Same topology used for minimum cover selection, scoreboard, and plain unicast
Destination Encodings • Imposes limit to size of multicast destinations • Three possible trade-offs to mitigate: • With longer packets – such as used in video streams – size not an issue • Compress destination header – trading space for computational time • In network aggregation – use train of packets that share destination list – but need synchronization and retransmission mechanisms • In any case uCast is designed for small-group multicast
Performance Evaluation • Compare with connection-based protocols: • Shortest Path Tree (SPT) Source node sends packets along shortest paths to destinations and aggregates common paths to form tree structure • Greedy Incremental Tree (GIT) Centralized construction and requires full knowledge of topology and is computationally intensive • Plain unicast • Uses geographical forwarding with the GPSR traversing technique to handle local minimum set
Destination Placement • Uses four parameters: • Polar angle of dispersion (AOD) • Radius – which is furthest destination node • Density – number of nodes within communication range • Number of destination nodes
Default Parameters • Communication range = 50m • Area = 500m x 500m • Density = 20 nodes per communication range • AOD = 900 • Number of destinations = 10 • Radius = 250m • Total nodes = 636 • Data rate = 6 packets / minute • Use PicaZ nodes with CC2420 radio
Energy Efficiency Impact of AOD GIT is best but impractical uCast performs better than SPT & Unicast
Energy Efficiency Impact of # Destinations GIT is best but impractical uCast performs better than SPT & Unicast
Energy Efficiency Impact of Range GIT is best but impractical uCast performs better than SPT & Unicast
Energy Efficiency Impact of Density GIT is best but impractical uCast has longer path length then SPT due to GPSR – but in reality voids are not common
Average Path Length Impact of AOD uCast & GIT have longer path lengths due to path aggregation leading to higher end-to-end delay SPT & Unicast find near optimal paths But trading energy consumption for longer path lengths
Average Path Length Impact of Density uCast & GIT have longer path lengths due to path aggregation leading to higher end-to-end delay SPT & Unicast find near optimal paths But trading energy consumption for longer path lengths
Topological Changes • Introduce topological changes by using energy saving protocols • Using parameters: • Toggle cycle – time interval between sleep state transitions • Scale – size of multicast area – larger the area then cost of reconstruction greater • Packet Delivery Rate – use 6 and 12 packets per minute
Topological Changes Impact of Toggle Period (Rate = 10ppm) Shows stateless multicast is superior with node state transitions As toggle periods shorten SPT degrades considerably, but uCast achieves 96% delivery ratio
Topological Changes Impact of Scale Connection based multicast is less scalable than uCast as range increased there is higher probability of state loss
Topological Changes Impact of Toggle Cycle & Range = 250m On SPT Shows 1000s of control packets are needed to rebuild tree
Topological Changes Impact of Toggle Cycle & Range = 500m On SPT Shows 1000s of control packets are needed to rebuild tree
Topological Changes Increasing Data Rate to 12 ppm Shows effect of increased data rate – which decreases delivery ratio
Unicast Protocols Geo forwarding and logical coordinates-based routing similar in their performances. However, uCast based on GEM shows quite different performance characteristics due to convoluted delivery paths and polar coordinates
Running System • Used actual sensor platform with • 25 MICA2 motes • Code Size of 992 bytes • 3V supplies • 19.2 kbps • 12 byte payload
System Evaluation uCast significantly reduces energy consumption
uCast & unicast uCast significantly reduces data load Recorded data load at each node
Conclusions • uCast is generally as efficient as connection-based protocols even with static networks • uCast is more robust in a dynamic network due to its connectionless nature • uCast can be implemented on different unicast routing protocols • A real implementation supports these conclusions