Gossip Scheduling for Periodic Streams in Adhoc WSNs

1
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
http//dprg.cs.uiuc.edu
2
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

3
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 gt
  0.7
• Saves energy
• Has latency that is comparable

4
Canonical Gossip HHL06

• GOSSIP (per stream)
• p gossip probability
• loop
• for each new message m do
• r random number between 0.0 and 1.0
• if (r lt p) then
• broadcast message m
• sleep gossip period

5
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 doesnt work!
• Treats each stream individually
• ? Overhead grows as sum of number of streams
• First-cut Idea For periodic streams, combine
  gossips

6
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

7
Piggyback Gossip

• PIGGYBACK GOSSIP
• p gossip probability
• loop
• for each constituent stream s
• for each new message m in s do
• r random number between 0.0 and 1.0
• if (r lt p) then
• add m to piggyback gossip message b
• broadcast message b
• sleep gossip period

8
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

9
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

10
Stream Groups k constraint

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

11
Relatedness Metric

• For two streams with similar stream periods,
  combining them maximizes the utilization of
  piggyback

Gossip message containing Pub3 and Pub4 sent
every 6 sec
(k2)

• Relatedness metric among each pair of streams i,j
  with periods ti and tj
• R(i,j) min(ti,tj)/max(ti,tj)
• (note that 0 lt R(i,j) lt 1.0)
• Two streams are related if they have a high R
  value

12
Scheduling using Relatedness

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

13
Semblance Graph

• Each gossip stream is a vertex in complete graph
• Edge weights represent relatedness R(i,j) between
  streams

14
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
• Prim-like
• Kruskal-like

15
I. Prim-like Algorithm

• Scheduled set of groups S F
• 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 lt k, then add v into group g
• Otherwise, create new group g in S, containing
  single vertex v
• Time Complexity O(V2.log(V))

16
II. Kruskal-like Algorithm

• Each node initially in its own group (size1)
• 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(V2.log(V))

17
Comparison of Heuristics

• 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)

18
Network Simulation

• Canonical Gossip vs. Piggybacked Gossip
• TinyOS simulator

19
Evaluation

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

20
Energy Savings

• Power consumption based on mote datasheet
• Gossip scheduling reduces energy consumption by
  40

Flood Canonical Gossip PgFlood
Piggybacked Gossip-Scheduled Gossip
21
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
22
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
23
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
http//dprg.cs.uiuc.edu