Gossip Scheduling for Periodic Streams in Ad-hoc WSNs Ercan Ucan, Nathanael Thompson, Indranil Gupta Department of Computer Science University of Illinois at Urbana-Champaign Distributed Protocols Research Group:

Gossip in Ad-hoc WSNs Useful for broadcast applications: Broadcast of queries [TinyDB] Routing information spread [HHL06] Failure Detection, Topology Discovery and Membership [LAHS05] Code propagation/Sensor reprogramming [Trickle]

Canonical Gossip Gossip (or epidemic) = probabilistic forwarding of broadcasts [BHOXBY99,DHGIL87] In sensor networks: forward broadcast to neighbors with a probability p [HHL06] Compared to flooding, gossip: Reliability is high (but probabilistic) if p > 0.7 Saves energy Has latency that is comparable

Canonical Gossip [HHL06] GOSSIP (per stream) 1. p = gossip probability 2. loop: 3. for each new message m do 4. r = random number between 0.0 and if (r < p) then 6. broadcast message m 7. sleep gossip period

Target Setting Our target setting Multiple broadcast streams, each initiated by a separate publisher node Each stream has a fixed stream period: source initiates updates/broadcasts periodically Different streams can have different period Canonical gossip doesn’t work! Treats each stream individually  Overhead grows as sum of number of streams First-cut Idea: For periodic streams, combine gossips

Piggybacking Combine multiple streams into one Piggybacking: Create gossip message containing latest updates from multiple streams Basically, each node gossips a “combined” stream Generates fewer messages and allows longer idle/sleep periods

Piggyback Gossip PIGGYBACK GOSSIP 1. p = gossip probability 2. loop: 3. for each constituent stream s 4. for each new message m in s do 5. r = random number between 0.0 and if (r < p) then 7. add m to piggyback gossip message b 8. broadcast message b 9. sleep gossip period

Gossip Scheduling  Basic piggybacking does not work if Streams have different periods Network packet payload size is finite  Solution: create a gossip schedule Determines which streams are piggybacked/packed into which gossip messages Runs asynchronously at each node

Static Scheduling Problem Solved centrally, and then followed by all nodes Given a set of periodic streams, satisfy two requirements: I. New piggyback message must not exceed maximum network payload size II. Maintain reliability, scalability and latency of canonical gossiping on individual streams  create groups of streams: k constraint  for each stream group, send gossip with period = min(all streams in that group)  gossip contains latest updates from each stream in group

Stream Groups: k constraint Each stream group contains <= k streams Due to: 1. Limit on size of network packet payload For TinyOS, 28 B 2. Update message sizes from streams Assume same for all streams E.g., for 28 B payload and 5 B update message, k=5 k constraint specifies maximum number of streams in one piggyback gossip

Relatedness Metric Relatedness metric among each pair of streams i,j with periods t i and t j : R(i,j) = min(t i,t j )/max(t i,t j ) (note that 0 < R(i,j) <= 1.0) Two streams are related if they have a high R value For two streams with similar stream periods, combining them maximizes the utilization of piggyback Gossip message containing Pub3 and Pub4 sent every 6 sec (k=2)

Scheduling using Relatedness In gossip schedule, highly related streams should be combined Yet satisfy k-constraint Express relatedness between streams in semblance graph

Semblance Graph Each gossip stream is a vertex in complete graph Edge weights represent relatedness R(i,j) between streams Example Stream Workload Semblance Graph

Semblance Graph Sub-problem Formally: partition semblance graph into groups Each Group has size no larger than k Minimize sum of inter-group edge weights i.e., maximize sum of intra-group edge weights Greedy construction heuristics: based on classical minimum spanning tree algorithms I. Prim-like II. Kruskal-like

I. Prim-like Algorithm Scheduled set of groups S = Φ Initialize S with a single group consisting of one randomly selected vertex Iteratively: Among all edges from S to V-S, select maximum weight edge e Suppose e goes from a vertex in group g (in S) to some vertex v (in V-S) Bring v into S If |g| < k, then add v into group g Otherwise, create new group g’ in S, containing single vertex v Time Complexity = O(V 2.log(V))

II. Kruskal-like Algorithm Each node initially in its own group (size=1) Sort edges in decreasing order of weight Iteratively consider edges in that order Try to add edge May combine two existing groups into one group May be an edge within an existing group If adding the edge causes a group to go beyond k, drop edge Time complexity: O(E.log(E) + E) = O(V 2.log(V))

Simulated algorithms on 5000 semblance graphs Stream periods selected from interval within [0,1] of size (1-homogeneity) Kruskal-like better on majority of inputs For any number of streams, homogeneity (and k) Comparison of Heuristics

Network Simulation Canonical Gossip vs. Piggybacked Gossip TinyOS simulator Network size225 nodes Publishers24 k constraint7 Gossip probability70%

Evaluation Total messages sent will decrease What are the effects on Energy consumption? Reliability? Latency?

Energy Savings Power consumption based on mote datasheet Gossip scheduling reduces energy consumption by 40% “Flood” = Canonical Gossip “PgFlood”= Piggybacked Gossip-Scheduled Gossip

Reliability Reliability reasonable up to 10% failures, and then degrades gracefully Slightly worse than canonical gossip due to update buffering at nodes “Flood” = Canonical Gossip “PgFlood”= Piggybacked Gossip-Scheduled Gossip

Latency Gossiping scheduling delays delivery at some nodes But it has lower latency for most cases, and a lower median and average latency Gossip scheduling pushes some updates quickly “Flood” = Canonical Gossip “PgFlood”= Piggybacked Gossip-Scheduled Gossip

Conclusion and Open Directions Canonical gossip inefficient under multiple publishers sending out periodic broadcast streams Use Gossip scheduling to efficiently piggyback different streams at nodes satisfies network packet size constraints retains reliability (compared to canonical gossip) improves latency lowers energy consumption Open directions: Dynamic version: adding/deleting streams, varying periods Distributed scheduling Distributed Protocols Research Group: