Content

Heterogeneous wireless z Introduction

z Routingand data gathering in
sensor networks
Heterogeneous wireless sensor
networks
Yinying Yang
z Hyper
z Tenet
z Mote herding: CentRoute

z Reference

Introduction

z Heterogeneous wireless sensor network z Architecture

z The wireless sensor network, which
consists of devices with different hardware
capabilities.
z Tenet
z lower tier: consists of motes, which enable
flexible deployment of dense instrumentation
z Upper tier: contains fewer, relatively less
constrained 32-bit nodes with higher-bandwidth
radios, which called masters

Routing and data gathering

protocols
z Benefit z Hyper
z Energy efficient z Tenet
z Decrease end to end delay
z Mote herding: CentRoute

1
 Ideal routing scheme
Hyper

z microserver is equipped with two radios
z CC1000
z standard 802.11 radio
z Challenging situations:
z A technician tasked with deploying a new sensor
node must verify that the new node has end-to-end
connectivity to a collection sink.
z the scientist goes to the field to make observations.
z a scientist might bring new sensors to the field
z Allow new nodes to join a network quickly
z support multiple independent routing trees
simultaneously for networks with concurrent fixed and
mobile users
z Opportunistically use 802.11 to connect application
scientists to the backend for retrieval of current and
historical data
z allow application scientists to go into the field, get
quick access to sensor data services, deploy new
sensors and get results from them quickly, and even
perform calibration experiments in real time
z burden the network as little as possible

Routing Trees for Mobile Users

Fast neighborhood evaluation

z connection via 802.11 z Two techniques for link assessment

z standard techniques such DHCP z direct measurement
z indirect inference of successful transmission
z Link quality indicator field
z Connect by mote radio
z fast neighborhood evaluation z Problem:
z fast tree formation z a user that arrives at a site and wants access to
sensor data services must wait several minutes to
z routing support for multiple sinks
establish a connection because of the periodically
sent beacon messages

Solution Fast link assessment protocol

z Cost metric: an expected number of z Periodically, each node transmits a Beacon

Packet (BP) containing an array of the
transmissions (etx) measured ingress link qualities of its neighbors.
Nodes exchange BPs to establish bidirectional
link quality.
z The mobile user sends out a Fast Beacon
Packet (FastBP), which is identical (except for
z Here, is the probability that a packet the content of its type field) to a BP; the
sent by a will be correctly received by b difference is that any node that hears a
FastBP is expected to respond with a BP
z For CC1000 immediately. Initially the sink’s FastBP is
empty since it has no ingress quality estimates.

2

Fast link assessment protocol
z The mobile user sends out a total of N FastBPs and
waits for S seconds between each FastBP in order to
receive responses. Neighbors each respond with N
BPs. N and S are parameters that should be tuned;
increasing N improves accuracy; increasing S
provides extra time to alleviate contention in dense
neighborhoods. BPs and FastBPs serve a dual role;
they may be used for estimating ingress quality and for
advertising it.
z Once neighborhood connectivity is assessed, the link
layer alerts the routing software that the fast link
convergence stage has completed.
Neighborhood Evaluation and Tree Construction
z Receiver: waits to evaluate it for an amount of
time proportional to the cost of the link over
which the update came
z wait timer
z If before the wait timer expires another update
arrives, then the two are compared in terms of the
path qualities they offer; the update message
containing the better path is retained.
z Once the wait timer expires, a node broadcasts its
own update message containing its best path cost
to the sink.
Multi-Tree Support
z Multiple concurrent sinks
z Expanding the management state for a
single tree into an array of state.
z The state structure contains:
z ID of the root node
z Next hop
z Route cost
z An Indication of whether the route is active
Neighborhood Evaluation and Tree Construction
z tree update message
z the transmitter’s address (the parent in the routing
tree)
z the address of the root
z the path cost (sum of the individual link costs that
make up a path)
z an epoch number to distinguish new updates from
old ones)
z a TTL used to limit the depth of the tree
z a time indicating when to expect the next update.
Neighborhood Evaluation and Tree Construction
z In the event that no update packets are
lost, and each node’s link estimates are
accurate then the tree that is built will be
a minimum spanning tree, and each
node will only send out one update
message.
Ad hoc sensor deployment and
node rebirth
z Issues:
z Augment a sensor
z Change batteries in the existing nodes
z Fast join mechanism
z The fast link convergence protocol – which of its
neighbors it is best connected
z Route Graft message / route reply (roots ID,
timeout for each root)
z New node adds the information and regard the
replying node as its parent
z Send message to sinks to indicate it is alive
z A full tree reformation if necessary
3
Efficient data collection Opportunistic Use of a Backchannel

z OpportunisticUse of a Backchannel z Use Wifi when available

z 802.11 connectivity may simplify the process of
z Disconnection Assessment
data acquisition for the mobile node
z Supporting Lonely Clouds of Motes z Historical data may be available only by 802.11
z an established sink may already be collecting the
data a mobile node needs
z Build a new tree or use an 802.11
backchannel to an established sink?

Opportunistic Use of a Backchannel Disconnection Assessment

z Form a collection tree when z Disconnection Assessment
z MN: mobile node
z retransmission several times without
z S: sink acknowledge
z mi, i =1, ..., k: the set of sensors that produce data z the packet will be queued for later
that MN needs
z cost(mi, X) be the energy expended in routing a transmission when conditions improve
data packet directly from mote mi to microserver X
z t: the number of data packets that need to be
collected each route formation epoch
z RouteCtrlMN: the cost to maintain a routing tree
rooted at MN for one epoch

Supporting lonely clouds of motes Tenet

z Support for collections of motes that are z Globally unique Identifiers

intentionally disconnected from IP- z Motes: 16 bit TinyOS node identifier
capable infrastructure is critical z Masters: the lower 16 bits of IP address

z Lonely motes experience long-term z Routing system

disconnections, during which data is z Master tier routing: IP routing
z Mote-to-master routing: tiered routing
stored to flash, followed by brief periods
mechanism
of connection when data is z a mote's response is routed to its nearest master
communicated in bulk z routed on the master tier using an overlay

4
Tiered routing mechanism Tiered routing mechanism

z discover the nearest master z IP overlay

z master periodically sends beacons
z mote updates a path metric reflecting the
quality of the path from itself to the
corresponding master, then relays it to its
neighbors
z the mote selects the neighbor which
advertised the best path to a master as its
parent
z When the receiver get a packet, it translates
that to an IP address by pre-pending its own
16-bit subnet mask to that address
z determines the next hop towards the
destination using the IP routing table
z encapsulates the packet in a UDP packet,
and sends that to the next hop

Tiered task dissemination Tiered task dissemination

z Task z Observation
z Any and all communication from a master to z tasking is a relative infrequent event
a mote takes the form of a task z Task most if not all the motes
z Any and all communication from a mote is a
z Predicate tasklet
response to a task
z select a subset of motes
z motes cannot initiate tasks themselves
z Function of static attributes of a node

Tiered task dissemination Mote herding: CentRoute

z TRD (Tiered reliable task dissemination) z Flock:mote

z master M wishes to transmit a task packet
z TRD locally caches a copy of the packet on M, z Shepherd: micro server
assigns a sequence number to the packet, and z Herd: network
broadcasts the packet to its neighbors
z Motes also cache received packets, and
rebroadcast previously unseen packets to their
neighbors.
z In case of transmission errors, each node
occasionally transmits a concise summary (k
sequence numbers received from a master) of all
the packets it has in its cache.

5
Design principle
CentRoute tree forming operation

z Shift system complexity from motes to

microservers for those operations that
require distributed decision making on
the motes

Reference
z T. Stathopoulos, L. Girod, J. Heidemann, and D. Estrin,
Mote Herding for Tiered Wireless Sensor Networks, in
CENS Technical Report #58, Dec. 2005
z O. Gnawali, B. Greenstein, K.-Y. Jang, A. Joki, J. Paek,
M. Vieira, D. Estrin, R. Govindan, and E. Kohler, The
Tenet Architecture for Tiered Sensor Networks, ACM
SenSys, Nov. 1-3, 2006
z T. Schoellhammer, B. Greenstein, D. Estrin, Hyper: A
Routing Protocol to Support Mobile Users of Sensor
Networks, in CENS Technical Report #63, Jan. 2006