PLGossip: Area Hierarchy Maintenance in LargeScale Wireless Sensor Networks

1
PL-Gossip Area Hierarchy Maintenance in
Large-Scale Wireless Sensor Networks

• Konrad Iwanicki
• Vrije Universiteit Amsterdam
• http//www.few.vu.nl/iwanicki/

2
Introduction I

• Many wireless sensor network (sensornet)
  application proposals require large numbers of
  nodes.
• Deployment and maintenance of a sensornet are
  simplified if nodes self-organize into a desired
  logical structure.
• To ensure scalability, a growing number of
  applications adopts a recursive geometric network
  organization.
• Example uses include
• object tracking,
• in-network storage,
• reactive tasking,
• network health monitoring,
• various query engines multi-dimensional range
  queries, spatial range queries, and
  multi-resolution queries.

3
Introduction II

• The recursive geometric organization provides
  scalable recursive naming of nested network areas
  and point-to-point routing.
• One can name a network area, the subareas
  included in this area, and so.
• The naming and point-to-point routing enable
  scalable data aggregation and fusion.

4
Problem Formulation

• Maintaining such an organization in a large
• sensornet is challenging due to
• Scale and hardware constraints.
• Energy limitations and resulting
• traffic constraints.
• Network dynamics.
• Various deployment requirements
• (e.g., 2D vs. 3D).
• To the best of our knowledge, none of the
  existing
• solutions addresses all these issues.

5
PL-Gossip Overview I

• PL-Gossip is a protocol for maintaining an area
  hierarchy in large sensornets.
• The area hierarchy provides scalable naming and
  point-to-point routing (O(log N) state per node),
  necessary for large-scale data aggregation and
  fusion
• is feasible for hardware-constrained sensor
  nodes.
• It is also a practical instance of the recursive
  geometric network organization
• can be applied in many deployment scenarios.

6
PL-Gossip Overview II

• Area hierarchy nodes self-organize into a
  multi-level
• hierarchy of nested network areas.

I
M
D
H
J
P
A
O
N
E
L
F
R
B
G
Q
C
K
7
PL-Gossip Overview II

• Area hierarchy nodes self-organize into a
  multi-level
• hierarchy of nested network areas.

I.H
M.H
D.D
H.H
J.D
P.L
A.L
O.H
N.H
E.G
L.L
F.H
R.G
B.G
G.G
Q.G
C.G
K.G
8
PL-Gossip Overview II

• Area hierarchy nodes self-organize into a
  multi-level
• hierarchy of nested network areas.

I.H.G
M.H.G
D.D.G
H.H.G
J.D.G
P.L.G
A.L.G
O.H.G
N.H.G
E.G.G
L.L.G
F.H.G
R.G.G
B.G.G
G.G.G
Q.G.G
C.G.G
K.G.G
9
PL-Gossip Overview III

• To ensure
• energy conservation and
• adaptability to continuous network dynamics,
• PL-Gossip employs gossiping.

10
PL-Gossip Overview IV

• Gossiping
• Nodes operate in rounds.
• In every round, each node broadcasts its state
  and receives its neighbors state.

Tx
Rx
time
a round
11
PL-Gossip Problems

• Gossip-based traffic is
• well-defined precise control of node radio
  activity energy conservation,
• periodic adaptability to continuous network
  dynamics.
• However, gossiping is unsophisticated
• no explicit forwarding of messages,
• access to only local information,
• additional coordination on top is difficult to
  implement or often inefficient.

12
PL-Gossip Solutions

• To this end, PL-Gossip
• specifically customizes formal hierarchy
  properties
• provides gossip-based mechanisms for maintaining
  these properties
• nodes autonomously detect violations of the
  hierarchy properties,
• nodes collaboratively repair such violations in a
  way ensuring consistency and convergence.

13
Hierarchy Properties

• The formal properties customized for the
  hierarchy
• Property 1 Level 0 areas correspond to
  individual nodes.
• Property 2 There exists a single level H area
  that covers all the nodes.
• Property 3 Level i1 areas are composed out of
  level i areas, such that each level i area is in
  exactly one level i1 area.
• Property 4 Each level i1 area contains a level
  i subarea that is adjacent to all other level i
  subareas of this area.
• The goal of the protocol is to provide mechanisms
  for
• maintaining these properties with gossiping
• Property 1 always holds
• Property 3 is associated with consistency and
  update propagation
• Properties 2 4 are related to hierarchy
  construction and recovery.

14
Hierarchy Maintenance I

• The membership of a node in the hierarchy is
• reflected in the nodes label.

I.H.G
M.H.G
D.D.G
H.H.G
J.D.G
P.L.G
A.L.G
O.H.G
N.H.G
E.G.G
L.L.G
F.H.G
R.G.G
B.G.G
G.G.G
Q.G.G
C.G.G
K.G.G
15
Hierarchy Maintenance II

• The labels of all nodes form the membership tree.

G
L
G
D
H
A
L
P
B
C
E
G
K
Q
R
D
J
F
H
I
M
N
O
16
Hierarchy Maintenance III

• The membership tree is a data structure
• distributed across all nodes.

G
G
G
G
G
G
G
G
G
G
G
G
G
G
G
G
G
G
L
L
L
G
G
G
G
G
G
G
D
D
H
H
H
H
H
H
A
L
P
E
G
K
Q
B
C
R
D
J
F
H
I
M
N
O
A
L
P
B
C
E
G
K
Q
R
D
J
F
H
I
M
N
O
How to maintain the properties of this
distributed structure?
17
Construction Recovery

• Hierarchy construction and recovery corresponds
  to detecting and reacting to violations of
  Properties 2 4.
• They are both local operations.
• Hierarchy construction
• is based on some nodes spawning areas on
  subsequent levels and other nodes joining such
  areas
• a node locally and probabilistically decides
  whether to join or to spawn an area
• our decision mechanism guarantees probabilistic
  convergence and logarithmic hierarchy height.
• Hierarchy recovery
• is based on nodes dissolving no-longer existing
  groups and later using the hierarchy construction
  algorithm.
• Details in our technical report 1.

18
Update Propagation

• Since the construction and recovery are local
  operations, we have to consistently propagate the
  updates they introduce to the hierarchy across
  all affected nodes.
• We require eventual consistency
• when the system is quiescent,
• if two nodes are eventually members of a level i
  area,
• their labels eventually have equal elements
  starting from position i.
• Eventual consistency implies recursiveness
  (Property 3).
• To ensure eventual consistency, we
• designate responsibility for maintaining a nodes
  label using a single-master model on a per label
  element basis
• introduce an update propagation mechanism that,
  given two labels, is able to tell which of them
  is fresher and consequently, should be adopted.
• Details in our technical report 1.

19
Consequences

• With this approach, we make no simplifying
• assumptions on the number and scope of changes
• in the system that can happen in a round.
• In particular, the changes can
• occur simultaneously,
• depend on each other,
• be noticed in different order by different nodes.
• This way we guarantee robustness
• the system can heal the hierarchy after arbitrary
  massive failures or network partitions
• the system can also tolerate message loss.

20
Experimental Evaluation I

• We evaluated PL-Gossip
• simulations,
• experiments with a real
• embedded implementation.
• In all cases the results were consistent and
  confirmed that PL-Gossip is
• scalable,
• robust,
• practical.

21
Results Scalability I
22
Results Scalability II
23
Results Scalability III
24
Results Scalability IV
25
Results Robustness I
26
Results Robustness II
27
Results Robustness III
28
Results Statistics

• Some statistics for PL-Gossip
• the raw state of a node in a 1024-node network lt
  300 bytes
• the raw outgoing bandwidth (the round length 5
  minutes) lt 8 bits/s
• an abstract listing of the algorithm core
• 130 lines of code (including comments).

29
Summary

• PL-Gossip is a gossip-based algorithm for
  maintaining an area hierarchy a practical
  instance of a recursive geometric network
  organization.
• It addresses the following challenges
• scale and hardware constraints of sensor nodes,
• energy limitations and resulting traffic
  constraints,
• constant network dynamics during deployment,
• various deployment requirements (e.g., 2D vs.
  3D).
• The experimental results show that PL-Gossip
• is scalable,
• is robust,
• has little memory and bandwidth requirements.

30
Future Work

• We have implemented PL-Gossip in TinyOS and
  tested it on the real nodes.
• We are now integrating PL-Gossip with a
  large-scale system.
• We plan to deploy the whole system on a very
  large real-world network, MyriaNed
  (http//www.devlab.nl/myrianed/).

31
Thank You

• Further information can be found at the Lupa
  Project website
• http//www.few.vu.nl/iwanicki/lupa-web/
• and in
• 1 K. Iwanicki and M. van Steen
• The PL-Gossip Algorithm. Tech. Rep.
  IR-CS-034.
• Vrije Universiteit Amsterdam. March 2007.
• Any questions?