EASM : Energy-efficient Data Dissemination for Arbitrary Sink Mobility in Wireless Sensor Networks

1
EASM Energy-efficient Data Dissemination for
Arbitrary Sink Mobility in Wireless Sensor
Networks

• Aniruddha S. Gokhale (a.gokhale_at_vanderbilt.edu)
• (work done with Amogh Kavimandan)
• Institute for Software Integrated Systems
• Dept. of Electrical Eng Computer Sc
• Vanderbilt University
• Nashville, TN, USA

Presented at Veritas, Pune, India Honeywell,
Bangalore GE Research, Bangalore June 8, 10,
2005
2
Focus Wireless Sensor Networks (WSNs)
WSNs are significantly different from regular
wired wireless networks

• Salient features of WSNs
• Collection of wireless sensor nodes
• Signal processing, radio and sensing in one IC
• Nodes are constrained in radio, battery
  computational power, and storage capacity
• Most nodes are stationary, sinks may be mobile
• Potentially very large scale geographically
  dispersed deployment
• Designed for unattended operation gt need for
  autonomous behavior
• Communication costs outweigh computation costs
• Nodes configured usually once due to high cost
  in reconfiguration
• Frequent topological changes owing to node
  failures, battery depletion, etc
• Non trivial challenges in data dissemination
• Used in habitat monitoring, target tracking
  localization, etc.

3
WSN Node Architecture

• Physical Layer
• sensor hardware e.g., radio
• MAC Layer
• channel access e.g., TDMA, adaptive duty cycling
• Routing Layer
• packet routing e.g., flooding, GPSR
• Data Management Layer
• data aggregation and data dissemination
• Application/Services Layer
• target tracking, habitat monitoring

Services Layer
Data Management Layer
Routing Layer
MAC Layer
Physical Layer
Talk focuses on data dissemination issues in WSNs
4
Talk Outline

• Data Dissemination Challenges in WSNs
• Existing Work Shortcomings
• Our research - EASM
• Protocol Design
• Protocol Evaluation
• Application Support
• Model-driven Development Middleware for WSNs
• Concluding Remarks

IF YOU HAVE ANY QUESTIONS PLEASE FEEL FREE TO
INTERRUPT AT ANY TIME
5
Data Dissemination Challenges

• Energy efficiency
• support multihop paths
• Scalability
• support increased sink-source pairs
• Tolerance to topology changes
• successful packet delivery in the face of node
  mobility and failure
• Timely availability of data
• timeliness of data is important
• Data-centric routing
• attribute-based naming

6
Existing Work in Data Dissemination for WSNs

• Directed Diffusion (Intanagonwiwat 2000)
• Sinks periodically propagate (broadcast)
  interests
• One path is reinforced to be used for
  communication

• Two Tier Data Diffusion (Luo 2002)
• Localizes interest broadcast space by dividing
  sensing space into a virtual grid
• Each source propagates data periodically

7
Shortcomings of Current Approaches

• Increased Routing load
• broadcast of interests increases routing load
• Restricted sink mobility
• only localized movements supported
• Scalability issues
• e.g., in TTDD - as many grids as sources!
• Undesired energy consumption
• increases for higher sink speeds

Need for a data dissemination scheme that allows
sink mobility while conserving energy and
providing dependable data delivery
8
EASM A Novel Energy Efficient Data Dissemination
Scheme for supporting Arbitrary Sink Mobility
EASM handles two main issues not addressed by
previous schemes (1) Interest and data response
communication is by way of broadcast which is
costly (2) sinks either propagate their location
information throughout the network or can only
exhibit localized movement patterrns

• Basic Idea
• Sink initiated
• Rendezvous-based scheme
• Uses GPSR as underlying routing protocol
• Data request and response know their destination
  gt no broadcast
• Directed-response used to ensure data delivery
  for fast moving sinks
• Replication used to reduce hot-spot complexity

• Assumptions
• Nodes are stationary (except sinks)
• Nodes are aware of their own location (through
  schemes such as GPS)
• Data aggregation is not addressed, assumed that a
  single source node stores data of an event

9
EASM Rendezvous Nodes

• An event type maps to a location within sensing
  space, called the rendezvous point
• A rendezvous point is aware of the instantaneous
  source node location at any point
• Sink interested in an event uses hash function to
  find the location of rendezvous point for the
  event type and sends query using GPSR

• Use of hash function to determine GPS location of
  rendezvous point

source
(2) send (src locn)
(1) hash (event type)
Rendezvous point
(3) hash (event type)
(4) send (data req)
sink
10
EASM Response Propagation

• Directed response strategy
• Sensing space is considered as a virtual grid
• Sink sends grid center location with every
  request, which is the center of its home cell
• Source uses grid center as a hint to direct
  response to sink
• Handles localized sink movement patterns
• Sink polls grid center after a predetermined
  interval of time
• Grid center forwards response if sink moved out
  of its home cell

11
EASM Response Propagation
Grid center
Sink node
Sink node
Old grid center
New grid center
Data request
Sink node crosses out of its home cell
Response (with turn-around time (t) for last
request
Start timer set to expire after t seconds
Elect new GC
Timer expires
Timer expires
Query for data
Query for data
Query every k seconds
Query every k seconds
Query for data
Query for data
Localized movement pattern
Global movement pattern
12
EASM Hot-spot Complexity Management

• Replication to relieve rendezvous point or grid
  center hot-spot complexity
• A node replicates if it cannot perform forwarding
  functions
• Node initiates n depth election to determine
  nodes, which can be used for replication
• Nodes with high residual energies are chosen as
  forwarders (have source forwarding information)
• all other nodes in election are interceptors
  (have forwarder information)
• A packet is read by an interceptor/forwarder at
  depth n, forwarded to destination

13
EASM Hot-spot Complexity Management

• Replication (contd.)
• - Lease based, renewed every k seconds
  with the initial node
• - Fault tolerance by maintaining multiple
  forwarders with each interceptor
• - State required is small (source location at
  each forwarder, forwarder location(s) at each
  interceptor)
• - Employed at rendezvous points, grid centers

14
EASM Routing Protocol
GPSR

• Leverage the Greedy Perimeter Stateless Routing
  (GPSR) Karp 2000 for routing
• Two methods for forwarding packets
• Greedy Geographic forwarding Each forwarding
  node sends packet to a one-hop neighbor
  geographically closest to destination
• Perimeter Forwarding Packet is forwarded along
  the perimeter when geographical routing fails

15
Results and Comparison
Delay vs network size
Energy consumption vs network size

• Delay of EASM is comparable with DD and TTDD even
  with directed response
• Energy consumption similar to TTDD, however EASM
  scales better with sink speed

16
Results and Comparison
Routing load vs network size
Energy consumption vs sink speed

• Routing load significantly reduced
• Further reduction at high speeds

Packet delivery results indicate about 98
success rate in EASM
17
Additional Research Challenges

• Hash function properties
• Overload on rendezvous node due to collisions on
  data type
• Can hash function affect routing costs (proximity
  of rendezvous node to sink)
• Can hash function provide capability of load
  balancing
• Aggregation of requests
• Can rendezvous nodes aggregate requests from
  different sinks for the same data type that
  arrive close to each other
• Can source aggregate data to multiple sinks with
  same interest and which lie in the same cell
• Priority handling
• Is there a priority scheme that ranks sinks
• Effects of passage of time
• What if a source dies?
• What if a sink is no longer interested in a data
  type?
• How are internal data structures refreshed?
• What are additional energy costs to perform these
  optimizations?
• What are the effects on routing layer and MAC
  layer or vice versa?

18
Talk Outline

• Data Dissemination Challenges in WSNs
• Existing Work Shortcomings
• Our research - EASM
• Protocol Design
• Protocol Evaluation
• Application Support
• Model-driven Development Middleware for WSNs
• Concluding Remarks

19
WSN Infrastructure Challenges
Future sensor-based application product-lines
will require middleware infrastructure support
Services Layer

• Must address constraints on energy, battery
  computational power
• Must have small footprint be optimized for the
  product-line
• Provide interoperability portability
• Must maintain interlayer semantic compatibility

Data Management Layer
Routing Layer
MAC Layer
Physical Layer
Need for a reusable, composable (plug play)
multilayered sensor network middleware
20
WSN Middleware Configuration Challenges
Every layer of middleware building blocks will
need configuration to support product variants
e.g., Localization response time
Services Layer
e.g., EASM grid size, hash fn
Data Management Layer
e.g., GPSR forwarding strategy
Routing Layer
e.g., TDMA slot size
MAC Layer

• Need to satisfy semantic compatibility across
  layers while satisfying constraints

Physical Layer
Need for a tool that can perform design-time
analysis validation of deployment and
configuration, and that can automatically compose
synthesize infrastructure from building blocks
21
Opportunities for Tool-based Automation 1/2

• Identifying points of commonalities
  variabilities drives automation

• (1) Per Building Block Scope
• Incurred due to variations in implementations
  configurations for a specific patterns-based
  building block
• e.g., single threaded versus thread-pool based
  reactor implementation dimension that crosscuts
  the event demultiplexing strategy (e.g., select,
  poll, WaitForMultipleObjects)
• Product-line commonalities help reduce the
  configuration choices
• e.g., single threaded reactor configuration for
  iterative servers
• Product-specific variabilities identify other
  optimization opportunities
• e.g., Reactor specialization by removing
  indirection, i.e., remove all virtual methods
  from Reactor_Impl base class completely

22
Opportunities for Tool-based Automation 2/2

• Identifying points of commonalities
  variabilities drives automation

• (2) Building Block Composition Scope
• Incurred due to variations in the compositions of
  patterns-based building blocks
• Product-line commonalities decide applicable
  composition
• e.g., for iterative servers, composing
  Leader-Follower with single threaded Reactor is
  plain overhead and useless

• Product variabilities help identify fast paths
  through the compositions
• e.g., eliminate indirections in compositions
• e.g., eliminate unnecessary lookups

23
Applying Performance Analytical Models for
Design Validation
Applying design-time performance analysis
techniques to estimate the impact of variability
in middleware-based WSN systems

• Build and validate performance models for
  invariant parts of middleware building blocks
• Weaving of variability concerns manifested in a
  building block into the performance models
• Compose and validate performance models of
  building blocks mirroring the anticipated
  software design of complete systems
• Estimate end-to-end performance of composed
  system
• Iterate until design meets performance
  requirements

Composed System
Refined model of a pattern
Refined model of a pattern
Invariant model of a pattern
Refined model of a pattern
Refined model of a pattern
Refined model of a pattern
weave
weave
variability
variability
Refined model of a pattern
Refined model of a pattern
system
24
Case Study The Reactor Pattern
The Reactor architectural pattern allows
event-driven applications to demultiplex
dispatch service requests that are delivered to
an application from one or more clients.

• Many networked applications are developed as
  event-driven programs
• Common sources of events in these applications
  include activity on an IPC stream for I/O
  operations, POSIX signals, Windows handle
  signaling, timer expirations

• Reactor pattern decouples the detection,
  demultiplexing, dispatching of events from the
  handling of events
• Participants include the Reactor, Event handle,
  Event demultiplexer, abstract and concrete event
  handlers

25
Reactor Dynamics

• Registration Phase
• Event handlers register themselves with the
  Reactor for an event type (e.g., input, output,
  timeout, exception event types)
• Reactor returns a handle it maintains, which it
  uses to associate an event type with the
  registered handler
• Snapshot Phase
• Main program delegates thread of control to
  Reactor, which in turn takes a snapshot of the
  system to determine which events are enabled in
  that snapshot
• For each enabled event, the corresponding event
  handler is invoked, which services the event
• When all events in a snapshot are handled, the
  Reactor proceeds to the next snapshot

26
Characteristics of the Reactor Performance Model

• Single-threaded, select-based Reactor
  implementation
• Reactor accepts two types of input events, with
  one event handler registered for each event type
  with the Reactor
• Each event type has a separate queue to hold the
  incoming events. Buffer capacity for events of
  type one is N1 and of type two is N2.
• Event arrivals are Poisson for type one and type
  two events with rates l1 and l2.
• Event service time is exponential for type one
  and type two events with rates m1 and m2.
• In a snapshot, event of type one is serviced with
  a higher priority over event of type two.
• - Event handles corresponding to both types
  of events are enabled, event handle of type one
  event is serviced prior to event handle of type
  two event.

27
Performance Metrics for the Reactor

• Throughput
• -Number of events that can be processed
• -Applications such as telecommunications call
  processing.
• Queue length
• -Queuing for the event handler queues.
• -Appropriate scheduling policies for
  applications with real-time requirements.
• Total number of events
• -Total number of events in the system.
• -Scheduling decisions.
• -Resource provisioning required to sustain
  system demands.
• Probability of event loss
• -Events discarded due to lack of buffer
  space.
• -Safety-critical systems.
• -Levels of resource provisioning.
• Response time

28
Using Stochastic Reward Nets (SRNs) for
Performance Analysis

• Stochastic Reward Nets (SRNs) are an extension to
  Generalized Stochastic Petri Nets (GSPNs) which
  are an extension to Petri Nets.
• Extend the modeling power of GSPNs by allowing
• Guard functions
• Marking-dependent arc multiplicities
• General transition probabilities
• Reward rates at the net level
• Allow model specification at a level closer to
  intuition.
• Solved using tools such as SPNP (Stochastic Petri
  Net Package).

• Work done in collaboration with Dr. Swapna
  Gokhale of Univ of Connecticut

29
Modeling the Reactor using SRN

• Part A
• Models arrivals, queuing, and prioritized service
  of events.
• Transitions A1 and A2 Event arrivals.
• Places B1 and B2 Buffer/queues.
• Places S1 and S2 Service of the events.
• Transitions Sr1 and Sr2 Service completions.
• Inhibitor arcs Place B1and transition A1 with
  multiplicity N1 (B2, A2, N2)
• - Prevents firing of transition A1 when
  there are N1 tokens in place B1.
• Inhibitor arc from place S1 to transition Sr2
• - Offers prioritized service to an event
  of type one over event of type two.
• - Prevents firing of transition Sr2 when
  there is a token in place S1.

30
Reactor SRN Taking a Snapshot

• Part B
• Process of taking successive snapshots
• Sn1 enabled Token in StSnpSht Tokens in B1
  No Token in S1.
• Sn2 enabled Token in StSnpSht Tokens in B2
  No Token in S2.
• T_SrvSnpSht enabled Token in S1 or/and S2.
• T_EndSnpSht enabled No token in S1 and S2.
• Sn1 and Sn2 have same priority
• T_SrvSnpSht lower priority than Sn1 and Sn2

31
Reactor SRN Initial Marking
A1
A2
N2
N1
StSnpSht
B2
B1
Sn1
T_SrvSnpSht
Sn2
T_EndSnpSht
S2
S1
SnpShtInProg
Sr2
Sr1
(a)
(b)

• Initial marking
• StSnpSht 1, B1 2, B2 2, S1 0, S2 0
• Transitions enabled Sn1 and Sn2
• Sn1 fires.

32
Reactor SRN Firing a Transition (1/6)
A1
A2
N2
N1
StSnpSht
B2
B1
Sn1
T_SrvSnpSht
Sn2
T_EndSnpSht
S2
S1
SnpShtInProg
Sr2
Sr1
(a)
(b)

• Upon firing of Sn1
• StSnpSht 1, B1 1, B2 2, S1 1, S2 0
• Transitions enabled Sr1, Sn2, T_SrvSnpSht
• Sn2 and T_SrvSnhpSht are immediate transitions,
  have to fire before Sr1.
• T_SrvSnpSht has a lower priority over Sn2.
• Sn2 fires.

33
Reactor SRN Firing a Transition (2/6)
A1
A2
N2
N1
StSnpSht
B2
B1
Sn1
T_SrvSnpSht
Sn2
T_EndSnpSht
S2
S1
SnpShtInProg
Sr2
Sr1
(a)
(b)

• Upon firing of Sn2
• StSnpSht 1, B1 1, B2 1, S1 1, S2 1
• Transitions enabled Sr1, T_SrvSnpSht
• T_SrvSnhpSht is an immediate transition, has to
  fire before Sr1.
• T_SrvSnpSht fires.

34
Reactor SRN Firing a Transition (3/6)
A1
A2
N2
N1
StSnpSht
B2
B1
Sn1
T_SrvSnpSht
Sn2
T_EndSnpSht
S2
S1
SnpShtInProg
Sr2
Sr1
(a)
(b)

• Upon firing of T_SrvSnpSht
• TSnpShtInProg 1, B1 1, B2 1, S1 1, S2 1
• Transitions enabled Sr1
• Snapshot in progress.
• Sr1 fires.

35
Reactor SRN Firing a Transition (4/6)
A1
A2
N2
N1
StSnpSht
B2
B1
Sn1
T_SrvSnpSht
Sn2
T_EndSnpSht
S2
S1
SnpShtInProg
Sr2
Sr1
(a)
(b)

• Upon firing of Sr1
• TSnpShtInProg 1, B1 1, B2 1, S1 0, S2 1
• Transitions enabled Sr2
• Snapshot in progress
• Sr2 fires.

36
Reactor SRN Firing a Transition (5/6)
A1
A2
N2
N1
StSnpSht
B2
B1
Sn1
T_SrvSnpSht
Sn2
T_EndSnpSht
S2
S1
SnpShtInProg
Sr2
Sr1
(a)
(b)

• Upon firing of Sr2
• TSnpShtInProg 1, B1 1, B2 1, S1 0, S2 0
• Transitions enabled T_EndSnpSht
• End of snapshot
• T_EndSnpSht fires

37
Reactor SRN Firing a Transition (6/6)
A2
A1
N2
N1
StSnpSht
B1
B2
Sn1
Sn2
T_SrvSnpSht
T_EndSnpSht
S2
S1
SnpShtInProg
Sr2
Sr1
(a)
(b)

• Upon firing of T_EndSnpSht
• StSnpSht 1, B1 1, B2 1, S1 0, S2 0
• Transitions enabled Sn1 and Sn2
• Back to initial state

38
Reactor SRN Performance Measures
Reward rate assignments to compute performance
measures
A2
A1
N2
N1
StSnpSht
B1
B2
Sn1
Sn2
T_SrvSnpSht
T_EndSnpSht
S2
S1
SnpShtInProg
Sr2
Sr1
(a)
(b)

• Throughput Rate of firing of transitions Sr1
  (Sr2).
• Queue length Number of tokens in place B1 (B2).
• Total number of events Sum of the tokens in
  places B1 S1 (B2 S2)
• Probability of event loss Number of tokens in
  place B1 N1 (B2 N2)
• Response time Can be obtained using the tagged
  customer approach.
• SRN model solved using Stochastic Petri Net
  Package (SPNP) to obtain
• estimates of performance metrics.

39
Designing Complete Systems using SRNs
A2
A1
N2
N1
StSnpSht
B1
B2
Sn1
Sn2
T_SrvSnpSht
T_EndSnpSht
S2
S1
SnpShtInProg
Sr2
Sr1
(a)
(b)

• Initial Step
• Obtain performance measures for individual
  patterns-based building blocks
• Iterative Algorithm
• Compose systems vertically and horizontally to
  form a DPSS system
• Determine performance measures for specified
  workloads and service times
• Alter the configurations until DPSS performance
  meets specifications.

40
Current Research Model-driven Generative
Programming Toolsuite

• Used generative programming to weave synthesize
  optimal assembly deployment artifacts for
  application components
• Used to optimally configure middleware
• Used for validation

• Visual Modeling
• Collection of domain-specific modeling languages
  (DSMLs) to address DC concerns
• Based on OMG DC spec

• Correct-by-construction
• Strong typing constraint-checking

• Enhances OMG MDA Vision
• MDD enhances OMG Model Driven Architecture (MDA)
  approach via DSMLs to support QoS-sensitive
  distributed systems

• Addressing crosscutting DC concerns
• CoSMIC DSMLs enable untangling DC concerns

• Metamodeling
• Uses Generic Modeling Environment (GME)
  metamodeling capabilities

• Alleviates Accidental Complexities
• Generative tools to address low-level
  platform-specific details

www.dre.vanderbilt.edu/cosmic
41
Optimizations Capturing System Invariants (1/2)
Boeing BasicSP Product-line scenario
Representative rate-based application

• Identifying Optimizations
• Use early binding parameters to tailor middleware
  
• Techniques applied could range from
• Conditional compilation
• Optimized stub/skeleton generation
• Strategy pattern to handle alternatives

• Example System
• Basic Simple (BasicSP) four component Real-time
  Embedded (DRE) application Distributed scenario
• Timer Component triggers periodic refresh rates
  
• GPS Component generates periodic position
  updates
• Airframe Component processes input from the GPS
  component and feeds to Navigation display
• Navigation Display displays GPS position
  updates

• Program Specialization Invariants
• Must hold for all specializations
• output(porig) output (pspl)
• speed (pspl) gt speed(porig)

42
Optimizations Capturing System Invariants (2/2)
Observations about Component Interactions
Observations about Component Deployment
Same Endianess
Periodic Timer
Single method interfaces
Collocated Components

• Observation
• Periodic same event message
• Single method interfaces defined on the component

• Observation
• Homogeneous environment
• Collocated components

• Mapping Ahead of Time (AOT) System Properties to
  Specializations
• Periodicity ? Pre-create marshaled Request
• Single Interface Operations ? Pre-fetch POA,
  Servant, Skeleton servicing request
• Same Endianess ? Avoid de-marshaling (byte order
  swapping)
• Collocated Components ? Specialize for target
  location (remove remoting)
• Same operation invoked ? Cache CORBA Request
  header/update arguments only

43
Preliminary Results Handcrafted Middleware
Optimizations in TAO ORB

• Client Side Specialization
• Request header caching
• Pre-creating requests
• Avoid marshaling checks
• Target location

• Server Side Specialization
• Specialized request processing
• Avoid demarshaling checks

44
Concluding Remarks

• Proposed a new data dissemination approach
• Results indicate good scalability for higher sink
  speeds (energy, routing load)
• High redundancy increased fault tolerance with
  node replication
• High success rate in packet delivery even when
  sinks move out of their home cell
• Future work to focus on
• Middleware for sensor networks to support
  WSN-based product lines
• Model-driven generative programming to synthesize
  optimized middleware stacks for WSNs

• Our research group has to date worked on the
  following technologies
• www.dre.vanderbilt.edu/cosmic (generative
  model-driven development toolsuite)
• www.dre.vanderbilt.edu/CIAO (QoS-enabled CORBA
  component middleware)
• www.dre.vanderbilt.edu/TAO (CORBA real-time
  middleware)

45
Questions?
46
EXTRA
47
Directed Diffusion (1/2)
Directed Diffusion

• Sink broadcasts interest (data request) message
  to its one hop neighbors
• Neighbors in turn cache the interest and
  broadcast it to its one hop neighbors
  (exploratory message)
• When exploratory message reaches source, it
  propagates event in a similar fashion (diffusion
  message)
• A single path is reinforced by sink, which is
  used for further communications (unicast)
• Multiple paths for redundancy (failure, high
  quality)

48
Directed Diffusion (2/2)

• Mobile sinks frequent broadcasts of exploratory
  and diffusion messages
• Multiple reinforced paths high routing overload
• Flooding increased energy consumption

49
TTDD (1/2)

• Aimed at addressing sink mobility, while reducing
  energy consumption
• A source creates a virtual grid with itself as
  one of the crossing-points of grid
• A node on the crossing point is dissemination
  node, knows next hop node (req/resp)
• Sink broadcasts a data request to find the
  closest dissemination node
• DN forwards the request as shown until it
  reaches source, response follows same path

Grid forwarding
Cell-level forwarding
50
TTDD (2/2)

• Cell size parameter is static, can not be changed
  after initiation higher cell size means higher
  interest broadcast for every sink
• Suitable for localized sink mobility, in-progress
  requests can not be serviced if sink leaves its
  home cell
• One grid per source, grid maintenance are very
  costly and not scalable

51
EASM Operation

1. Sink sends request to rendezvous point
2. Interceptors intercept request and relay to
   forwarders
3. Forwarder redirects request to source
4. Directed response from source to grid center
5. Grid center relays response to sink

52
EASM A Novel Energy Efficient Data Dissemination
Scheme for supporting Arbitrary Sink Mobility
EASM handles two main issues not addressed by
previous schemes (1) Interest and data response
communication is by way of broadcast which is
costly (2) sinks either propagate their location
information throughout the network or can only
exhibit localized movement patterrns

• Salient Features
• Sink initiated
• Rendezvous-based scheme
• Uses GPSR as underlying routing protocol
• Data request and response know their destination
  gt no broadcast
• Directed-response used to ensure data delivery
  for fast moving sinks
• Replication used to reduce hot-spot complexity

• Assumptions
• Nodes are stationary (except sinks)
• Nodes are aware of their own location (through
  schemes such as GPS)
• Data aggregation is not addressed, assumed that a
  single source node stores data of an event

53
EASM Architecture

• Sensing space divided into a virtual grid
• Sink mobile node interested in data
• Source stationary node sensing a phenomenon
• Rendezvous point relay requests from sink to
  source
• Grid center center of a cell
• Interceptors forwarders used in managing
  hot-spot complexities