Close
About
FAQ
Home
Collections
Login
USC Login
Register
0
Selected
Invert selection
Deselect all
Deselect all
Click here to refresh results
Click here to refresh results
USC
/
Digital Library
/
University of Southern California Dissertations and Theses
/
Adaptive routing services in ad-hoc and sensor networks
(USC Thesis Other)
Adaptive routing services in ad-hoc and sensor networks
PDF
Download
Share
Open document
Flip pages
Contact Us
Contact Us
Copy asset link
Request this asset
Transcript (if available)
Content
ADAPTIVE ROUTING SERVICES IN AD-HOC AND SENSOR NETWORKS
by
Yu He
A Dissertation Presented to the
FACULTY OF THE GRADUATE SCHOOL
UNIVERSITY OF SOUTHERN CALIFORNIA
In Partial Fulfillment of the
Requirements of the Degree
DOCTOR OF PHILOSOPHY
(COMPUTER SCIENCE)
December 2005
Copyright 2005 Yu He
Reproduced with permission of the copyright owner. Further reproduction prohibited without permission.
UMI Number: 3220109
Copyright 2005 by
He, Yu
All rights reserved.
INFORMATION TO USERS
The quality of this reproduction is dependent upon the quality of the copy
submitted. Broken or indistinct print, colored or poor quality illustrations and
photographs, print bleed-through, substandard margins, and improper
alignment can adversely affect reproduction.
In the unlikely event that the author did not send a complete manuscript
and there are missing pages, these will be noted. Also, if unauthorized
copyright material had to be removed, a note will indicate the deletion.
®
UMI
UMI Microform 3220109
Copyright 2006 by ProQuest Information and Learning Company.
All rights reserved. This microform edition is protected against
unauthorized copying under Title 17, United States Code.
ProQuest Information and Learning Company
300 North Zeeb Road
P.O. Box 1346
Ann Arbor, Ml 48106-1346
Reproduced with permission of the copyright owner. Further reproduction prohibited without permission.
Dedication
Dedicated to my family
Reproduced with permission of the copyright owner. Further reproduction prohibited without permission.
Acknowledgements
I want to thank my advisor, Dr. Cauligi S. Raghavendra. Without his patient guidance
and inspiring comments, this dissertation would not have been possible. In addition he
always encourages and supports me to explore what I am interested in, for which I will
be eternally grateful to him.
I would also like to express my sincere gratitude to Dr. Ahmed Helmy for his generous
help on some technical details of this dissertation. A special thanks goes to Dr. Bhaskar
Krishnamachari for his insightful and constructive comments on my research.
Finally I thank Dr. Ramesh Govindan, Dr. John Heidemann, Dr. Steven Berson, and
Mr. Robert Braden for their valuable comments on some early work of this dissertation.
Reproduced with permission of the copyright owner. Further reproduction prohibited without permission.
Table of Contents
Dedication ii
Acknowledgements iii
List of Tables vii
List of Figures ix
Abstract xi
1 Introduction 1
1.1 Routing in Wireless N e tw o rk s..................................................................... 4
1.2 A Conservative Approach to Ad-hoc Network Routing Services ............ 6
1.3 A Proactive Approach to Sensor Network Routing Services..................... 8
1.4 Dissertation Organization.............................................................................. 10
2 Ad-hoc Network Routing Services 13
2.1 O verview ....................................................................................................... 13
2.2 On-demand Routing Services........................................................................ 15
2.3 Paths in Route S tate........................................................................................ 16
3 Active Ad-hoc Network Routing 21
3.1 Active H elp er................................................................................................. 21
3.2 One Implementation - Active D S R .............................................................. 22
3.3 Routing and Energy-consumption Improvement........................................ 25
3.4 TCP Performance Im provem ent.................................................................. 30
3.4.1 Single TCP connection with CBR background tra ffic.................... 30
3.4.2 Multiple TCP connections with CBR background tra ffic 39
3.4.3 TCP connections with congestion................................................... 39
3.5 Related W o rk ................................................................................................. 44
3.6 S u m m ary ....................................................................................................... 46
iv
Reproduced with permission of the copyright owner. Further reproduction prohibited without permission.
4 Sensor Network Routing Services 47
4.1 Wireless Sensor N e tw o rk s............................................................................ 47
4.2 Existing Routing Services................................................................................ 48
4.3 Motivation for Routing Changes in Sensor N e tw o rk s................................ 50
4.4 Routing Change Requirements for Sensor Networks................................... 52
5 XVR - X Visiting-pattem Routing 54
5.1 Visiting-pattems of Packets........................................................................... 54
5.2 Architecture.................................................................................................... 59
5.3 One Implementation .................................................................................... 60
5.3.1 Visiting-pattems in the X V R ............................................................. 61
5.3.2 State Maintained by the X V R .......................................................... 64
5.3.3 A lgorithm s......................................................................................... 65
5.3.4 Programmable Visiting-pattems...................................................... 71
5.4 Using X V R .................................................................................................... 72
5.4.1 Existing Routing S erv ic es................................................................ 72
5.4.2 New Routing S erv ices...................................................................... 75
5.5 Evaluations.................................................................................................... 77
5.5.1 Code Size of the X V R ...................................................................... 78
5.5.2 Communication Metrics and Methodology .................................... 78
5.5.3 The XVR vs. Directed-diflfusions................................................... 79
5.5.4 Exploring New Routing Services...................................................... 84
5.6 Related W o rk ................................................................................................. 88
5.6.1 Related Routing Services................................................................... 90
5.6.2 Related Programmable Architectures ............................................. 91
5.7 S um m ary....................................................................................................... 93
6 Automatic Visiting-pattern Routing 94
6.1 Architecture.................................................................................................... 95
6.1.1 Properties-based Visiting-pattem S electio n .................................... 97
6.1.2 Feedback-based Visiting-pattem C hanges....................................... 99
6.1.3 Enforcing Chosen Visiting-pattem...................................................... 103
6.2 Automatic Visiting-pattem Change between Pull and P u s h ........................ 105
6.2.1 O verview ............................................................................................... 105
6.2.2 Leader Election and M aintenance...................................................... 108
6.2.3 Collecting Number Inform ation..........................................................I ll
6.2.4 Avoiding Premature F lo o d in g ............................................................ 114
6.2.5 Changing Visiting-pattems...................................................................115
6.2.6 Decision M ak in g ...................................................................................117
6.3 Simulation R e s u lts .......................................................................................... 118
6.3.1 Single Ratio Changes............................................................................ 119
6.3.2 Two Consecutive Ratio C hanges......................................................... 123
v
Reproduced with permission of the copyright owner. Further reproduction prohibited without permission.
6.3.3 Multiple Ratio Changes .....................................................................124
6.4 Related W o rk ..................................................................................................... 125
6.5 S u m m ary............................................................................................................128
7 Conclusions and Future Work 129
Bibliography 131
vi
Reproduced with permission of the copyright owner. Further reproduction prohibited without permission.
List of Tables
5.1 Visiting-pattems of Data packets in Sensor Network Routing Services . . 55
5.2 Supported Visiting-pattems for Each Packet Type in the X V R ............. 63
5.3 Visiting-pattems of the XVR to Emulate Existing Routing Services . . . . 72
5.4 Code Size and Ratio.................................................................................. 77
6.1 Visiting-pattems for Pull and Push routing in the X V R .........................105
6.2 Number Info Collectible via Existing Packets in PULL-XVR.......................107
6.3 Number Info Collectible via Existing Packets in PUSH-XVR.......................107
6.4 Ratio Changes for Figure 6 . 6 a .........................................................................124
6.5 Ratio Changes for Figure 6 . 6 b .........................................................................124
vii
Reproduced with permission of the copyright owner. Further reproduction prohibited without permission.
List of Figures
2.1 Route miss rates (percent) and routing packet numbers (per data packet)
for networks with 20, 50, and 100 n o d e s .................................................. 19
3.1 Miss rates and route packet numbers (per data packet) from ADSR for
the 50-node network .................................................................................. 26
3.2 Miss rates and route packet numbers (per data packet) from ADSR for
the 100-node netw ork.................................................................................. 27
3.3 Dissipated Energy (per data packet) for networks with 50 and 100 nodes 29
3.4 TCP throughput and Routing packet overhead for 50-nodes network
with 6 different pause tim es........................................................................ 31
3.5 TCP throughput and Routing packet overhead for 100-nodes network
with 6 different pause tim es........................................................................ 32
3.6 TCP throughput standard deviations for the 100-node networks & Three
typical traffic for the 100-node networks with pause-time of 50 seconds 35
3.7 TCP sequence number traces for the three typical traffic: low through
put, medium throughput and high throughput ......................................... 36
3.8 TCP throughput and Routing packet overhead for 2, 5, 10 and 20 TCP
connections................................................................................................. 38
3.9 TCP throughput under congestion situations for the 100-node networks . 40
3.10 TCP sequence number traces for one congested case with 1 TCP con
nection: DSR, ADSR, and ADSR with Congestion C o n tro l................... 41
3.11 TCP sequence number traces for one congested case with 2 TCP con
nections: DSR, ADSR, and ADSR with Congestion Control ................ 42
5.1 Visiting Patterns of Control Packets for Publication/Subscription-based
Routing S e rv ic e s........................................................................................ 56
5.2 Routing Architecture Change with X V R ................................................... 58
5.3 Algorithm flow chart for the asymmetric c a s e .......................................... 68
5.4 Algorithm flow chart for the symmetric c a s e ............................................. 69
5.5 Geographic Visiting-pattem to Emulate TTDD.......................................... 75
5.6 The XVR vs. Two-phase-pull Directed-diffusion....................................... 80
5.7 The XVR vs. Push Directed-diffusion....................................................... 82
5.8 The XVR vs. One-phase-pull Directed-diffusion....................................... 83
5.9 The XVR with Both Flooding and XVR with Both Restricted-flooding . 85
viii
Reproduced with permission of the copyright owner. Further reproduction prohibited without permission.
5.10 The XVR with Probable Visiting-pattem s................................................ 87
5.11 The XVR with Geographic Visiting-pattems............................................. 89
6.1 Architecture of the Autonomic Visiting-pattem Routing (A V R )............. 96
6.2 Collaborative Visiting-pattem Example.........................................................102
6.3 Change sink number, and change source number, with the initial Source
x Sink = 1 x 1 .................................................................................................120
6.4 Change sink number, and change source number, with the initial Source
x Sink =1 5 x 1 5 ..............................................................................................122
6.5 Change sink number after Source x Sink = 8 x 1 5 ...................................... 123
6.6 Sink number x source number: lx l - 1x4 - 7x4 - 7x10 - 13x10 - 13x16,
and lx l - 4x1 - 4x7 - 10x7 - 10x13 - 16x13 ...............................................126
ix
Reproduced with permission of the copyright owner. Further reproduction prohibited without permission.
Abstract
In this dissertation, two different approaches are proposed to improve adaptability of
routing services for mobile ad-hoc and sensor networks.
For mobile ad-hoc networks, we propose a general approach called active ad-hoc net
work routing that uses a helper module to improve existing routing algorithms without
changing their inner mechanisms. This helper module issues probing packets that roam
around an ad-hoc network to collect information which then is used to update routing
state. By collecting different state information, adaptability of existing ad-hoc network
routing algorithms can be improved in multiple aspects. As a case study, we apply this
general approach to the Dynamic Source Routing algorithm in ad-hoc networks. The
resulting algorithm, called Active DSR, collects topology and queue-length information
to update route cache in DSR. Discussions and extensive simulations show that routing
cache miss rates are reduced by using the topology information, and network congestion
is improved by using the queue-length information. We also show energy consumption
and TCP performance improvement under ADSR.
For sensor networks, we propose a new routing paradigm called X Visiting-pattem
Routing (XVR) to promote routing flexibility. Visiting-pattems indicate where to for
ward packets as next hops in a network and are essential to any routing service. Unlike
any existing routing service in which each packet handler is integrated with its visiting-
pattem, XVR deliberately decouples visiting-pattems of packets from their correspond
ing packet handlers. The separated packet handlers consist of a routing core that calls the
visiting-pattem module when issuing or forwarding packets. This separation has several
important implications for building flexible routing services in sensor networks. First, a
x
Reproduced with permission of the copyright owner. Further reproduction prohibited without permission.
routing service can be changed by simply using different visiting-pattems with low en
ergy cost. Second, extensive simulations show that existing and new routing services can
be brought together for comprehensive experiments in a unified environment. Third, au
tomatic and concurrent routing services can be built on top of XVR without changing the
routing core. As a case study, we show how to conduct automatic routing changes be
tween two known routing services, push and pull, with XVR, and evaluate performance
gains.
Reproduced with permission of the copyright owner. Further reproduction prohibited without permission.
Chapter 1
Introduction
In recent years, wireless networks have experienced an extraordinary growth and usage in
popularity. The continuing miniaturization of wireless computing devices and the remark
able increase in processing power are combined to put more and better computer-based
applications into the hands of a rapidly growing part of the population. As wireless net
works multiply, and as applications using the traditional Internet become accustomed to a
larger portion of customers, these customers will expect to get networking services even
in situations where the Internet is not available [57]. Such networking applications are
possible with ad-hoc networks. An ad-hoc network is a wireless network where commu
nications among nodes are realized without the aid of a pre-existing infrastructure.
Wireless ad-hoc networks are useful in a variety of applications and scenarios. For
example, people using laptop computers at a conference in a hotel might wish to commu
nicate in a variety of ways, without the mediation of routing across the global Internet.
As another example, people still need to be able to talk to one another during disaster
emergencies that might have impaired the existing communication infrastructure. An
other class of applications arise from the emergence of new wireless devices, such as
1
Reproduced with permission of the copyright owner. Further reproduction prohibited without permission.
“wearable” computing devices and embedded miniature devices. These new wireless de
vices can work together to form an ad-hoc network, making possible a large group of
applications. For example, wireless components built in automobiles can work together
to generate instant and accurate traffic reports. Furthermore, wireless devices embedded
in home appliances can form an ad-hoc home network to complete a chore of house
keeping tasks without human intervention. Ad-hoc networks have become an essential
part to realize the goal of “ubiquitous computing”, where network applications can be
used “anytime and anywhere”.
An important aspect of ad-hoc networks is communication among nodes. There has
been extensive research on routing protocols for ad-hoc networks and their uses in many
real applications. Several unicast routing protocols, such as DSDV [58], AODV [59],
and DSR [51], have been proposed to realize data delivery between a pair of mobile
nodes. Multicast that realizes one-to-many communications has also been under study
[12]. Quality of Service (QoS) in ad-hoc networks is studied to provide service guarantees
and differentiations in mobile environments [67]. Management protocols for resources
and mobile nodes have been proposed to maximize the utilizations of bandwidth and
energy resources ([80] and [81]) in ad-hoc networks. Finally, service security in ad-
hoc networks [56] is studied to provide protections among different applications in the
presence of vulnerable wireless communication and node mobility.
Recently, a new category of devices, called sensor nodes, have emerged that integrate
micro-sensing with on-board processing and wireless communication capabilities ([36],
[61], and [63]). A typical sensor node has one or more types of sensors to collect data,
an embedded processor and limited memory, and the ability to communicate wirelessly
2
Reproduced with permission of the copyright owner. Further reproduction prohibited without permission.
with other sensor nodes and devices. Sensor nodes can collect audio, seismic, pressure,
temperature, and other types of data. Each sensor node can operate autonomously with no
central point of control and can make decisions based on the information it currently has.
Sensor nodes operate with battery power and wireless communications which make their
deployment easier. These sensors can be deployed in a large scale and deeply embed
ded within the physical environment. Networks composed of sensor nodes, called sensor
networks, can support a large range of applications, including physiological monitoring,
environmental monitoring (air, water, soil, chemistry), precision agriculture, target detec
tion, factory instrumentation and inventory tracking, condition based maintenance, smart
spaces, and military surveillance ([16], [15], [40], [9], [17], and [23]).
Sensor networks can be regarded as a special form of ad-hoc networks when sensor
nodes work together to complete data communications without the aid of a fixed infras
tructure. One distinction between sensor networks and general ad-hoc networks is that
sensor nodes are deeply embedded with their target sensing environment and are often
unattended. This deployment property urges the need for low-cost sensor nodes that carry
batteries as power sources. Therefore energy in sensor nodes is often a scarce resource
and is a key factor to determine the life time and quality of a sensor network. Protocols
designed for sensor networks, therefore must be energy-efficient and should be tailored
for specific applications and network attributes.
There has been extensive research in sensor networks to design new protocols and
services to better suit their intended applications. New areas of investigation, such as,
collaborative signal processing, localization [8], target detection and actuation, and sensor
fusion [38] have emerged. At the medium access layer, many new MAC protocols, such
3
Reproduced with permission of the copyright owner. Further reproduction prohibited without permission.
as SMAC [84] have been proposed. At the network layer, topology control protocols
(such as SPAN [11] and GAF [79]), and routing protocols (such as Directed-diffusion
[39] and TTDD [83]) have been developed. At the transport layer, reliable transmission
protocols to deal with error-prone wireless transmissions (such as RMST [73]) have been
proposed. At the application layer, novel query processing [82] and application-specific
aggregation [49] are being investigated. Also, there are significant efforts to work on
security mechanisms in wireless sensor networks (e.g., SPINS [60]).
1.1 Routing in Wireless Networks
In the absence of a static infrastructure, nodes themselves take on missing functions in
an ad-hoc network. It is often the case that some nodes are not within the radio range of
one another. Thus a routing protocol that realizes peer-to-peer multihop data delivery is
essential in ad-hoc networks to support large networks and interesting applications. Ad-
hoc network routing should be able to adapt to changes in network topology because of
node mobility and the nature of wireless transmissions. In this dissertation, we focus on
adaptive routing in wireless ad-hoc networks.
In ad-hoc networks, the routing layer realizes node-to-node communication in a dy
namic environment where network topology keeps changing due to node mobility, error-
prone communications, and deployment environment. There have been many routing
protocols proposed for wireless ad-hoc networks, which include but are not limited to,
DSDV (Destination-Sequenced Distance Vector [58]), DSR (Dynamic Source Routing
[51]), AODV (Ad-hoc On-Demand Distance-Vector [59]), and ZRP (Zone Routing Proto
col [22]). The main research objectives in ad-hoc network routing services are to achieve
4
Reproduced with permission of the copyright owner. Further reproduction prohibited without permission.
low average delay and a low overhead mechanism for routing packets between peer pro
cesses in presence of node mobility.
In sensor networks, one goal is to collect, process, and forward sensed data to other
sensor nodes and/or base stations. Therefore, a routing service is essential to sensor net
work applications. Many routing services have been proposed for sensor networks, such
as Greedy Perimeter Stateless Routing (GPSR) [41], Trajectory Based Routing (TBF)
([55]), Directed-diffusion [39], and Rumor-routing [7]. These routing services have dis
tinct properties than those in ad-hoc networks. First, flooding is conducted more carefully
in sensor networks since flooding is very energy expensive. These routing services take
additional measures to control the scope and frequency of flooding. Second, data are
generally forwarded in sensor networks without explicitly addressing individual nodes.
For example, GPSR takes locations instead of IP addresses as routing destinations. TBF
uses a trajectory instead of a node-path as its routing unit. Further, data-centric paradigm
is often used in sensor networks where data attributes are actively used to direct routing
activities.
The common issues of both ad-hoc and sensor network routing services are lack of
flexibility and adaptability to suit the dynamics of applications and networks. For exam
ple, ad-hoc network routing services (such as DSR and AODV) suffer form stale routes
when node mobility is high. Sensor network routing services are often designed for spe
cific applications and networks, and may not perform well when the network or applica
tion change. For example, Rumor-routing performs well in a dense sensor network, but
performs poorly in a sparse network. This dissertation studies approaches to improve the
adaptability of ad-hoc and sensor network routing services. We take different approaches
5
Reproduced with permission of the copyright owner. Further reproduction prohibited without permission.
to improve adaptability for ad-hoc and sensor network routing services, which are out
lined in the following sections.
1.2 A Conservative Approach to Ad-hoc Network Rout
ing Services
Among many routing services, on-demand routing algorithms such as DSR (Dynamic
Source Routing [51]), and AODV (Ad-hoc On-Demand Distance-Vector [59]) are well-
studied in which routes are acquired only when needed by applications. Currently, these
two routing services have been in the phase of standardization by the IETF group.
The main advantage of on-demand routing algorithms is that their route maintenance
overhead can be small since unnecessary routes are not acquired and kept. On-demand
routing protocols generally flood route requests to find a route. To reduce the cost of
flooding, they use route tables to keep obtained routes. But a route table in an ad-hoc
network has two potential problems. First, if a route request is for a new route, the route
table can not avoid flooding to a new destination since the route can not be found from
the table. Second, paths kept in the route table can quickly become inefficient or even
invalid when node mobility is high. When an inefficient route is used, data packets suffer
unnecessary delays; when an invalid route is followed, route failures will trigger flooding,
creating additional routing overhead and latency for data packets.
There have been multiple approaches proposed to tackle the stale route problem in
on-demand ad-hoc network routing ([18], [37], [52], and [21]). For example, in [37], a
Reproduced with permission of the copyright owner. Further reproduction prohibited without permission.
different data structure is used for route state so that it can induce more path informa
tion. Another example is in [21], where previous path-length information is maintained
per flow to shorten the current route paths. The main idea behind these approaches is
to collect useful information from passing-by packets to improve the route state. The
advantage of this passive information-collecting is small cost for data collection. How
ever, the degree of usefulness of the information passively collected is limited since the
information is opportunistic and mainly includes only local views in an ad-hoc network.
In this dissertation, we propose an active information-collecting method. In this method,
probing packets are issued to actively collect information from nodes they visit. These
probing packets can collect various information from a network and this information is
often more complete than locally available. By using such actively-collected information,
route state can be updated more effectively, an ad-hoc network routing service can be
improved in multiple aspects, and the resulting savings in routing overhead can offset the
cost of information collection.
Further, issuing probing packets is independent from the operation of a target ad-hoc
network routing service. There is a separate active helper module sitting besides a tar
get service that issues probing packets. This separation implies that one legacy ad-hoc
network routing service can be improved without modifying the service itself. Thus our
proposed approach has great advantage in case of deployment. Because of this property,
the proposed approach is called conservative by which we mean that it does not attempt
to change the inner mechanism of the target service. This conservative approach is appli
cable to improve adaptability of legacy systems.
Reproduced with permission of the copyright owner. Further reproduction prohibited without permission.
As a case study, this conservative approach is applied to DSR and the resulting ser
vice is called Active DSR (ADSR). In ADSR, various information, such as topology
and queue-length is collected from network to update routing cache in DSR. Discussions
and extensive simulations show that routing cache miss rates are improved by using the
topology information, and network congestion is improved by using the queue-length in
formation. We will also show energy-savings and TCP performance improvement under
ADSR.
1.3 A Proactive Approach to Sensor Network Routing
Services
Compared to mobile ad-hoc networks, sensor networks are an emerging new area where
research about routing services has been focused on how to realize energy-efficient data
dissemination for specific networks and applications. These routing services are signifi
cantly different from one another, and are designed to meet requirements of different net
work conditions and/or applications. For example, GPSR is applicable to sensor networks
with a location service that can provide locations of destination nodes, rumor-routing can
work well in a highly dense sensor network, and TTDD is designed to disseminate data
from stationary sources to mobile sinks. A sensor network application, and therefore, its
network and traffic conditions may change from time to time. One can observe that there
is no single fixed routing service that performs well under all applications and/or network
conditions [33], It is desirable to adapt sensor network routing services when applications
8
Reproduced with permission of the copyright owner. Further reproduction prohibited without permission.
and/or network conditions change. Currently, a sensor network is generally statically con
figured with a particular type of routing service that is difficult to be changed.
There have been several research efforts to improve service flexibility for sensor net
works (such as Diffusion filters [31], Mate [44], and Impala [48]). These approaches
provide programmable interfaces from which different routing services can be written. In
the Impala framework, whole routing service can be replaced when certain traffic patterns
are detected. In the Mate approach, a concise set of general instructions are provided so
that services including routing can be written with small code size. In the architecture of
Diffusion filters, a routing service can be developed by writing specific packet filters. All
these approaches can be used to change routing services for sensor networks. However,
the changing granularity can be large. For example, Mate and Impala do not provide ar
chitectural support to change only parts of a service; an entire routing service needs to be
replaced when changing routing. In the case of Diffusion filters, routing changes can be
done in terms of packet filters, which still can be significantly large in terms of code size.
Transmitting a large amount of binary code can be very energy expensive because of the
reliability requirement for the code transmission. There is a need to change routing in
sensor networks with fine granularities. Ideally, sensor network routing services should
be easily changed significantly with small energy overhead.
To meet this goal, we take a proactive approach to re-examine the routing architecture
for sensor networks, and propose a flexible open architecture in the first place. By proac
tive we mean that a service is designed with architectural support for potential service
evolutions. This approach is applicable to newly emerging services.
Reproduced with permission of the copyright owner. Further reproduction prohibited without permission.
In this dissertation, a new routing architecture called X Visiting-pattem Routing (XVR)
is proposed for sensor networks. Visiting-pattems indicate where to forward packets as
next hops in a network and are essential to any routing service. Unlike any existing routing
service in which each packet handler is integrated with its visiting-pattem, XVR delib
erately decouples visiting-pattems of packets from their corresponding packet handlers.
The separated packet handlers consist of the routing core that calls the visiting-pattem
modules when issuing or forwarding packets. This separation has several important im
plications for building flexible routing services in sensor networks. First, the visiting-
pattems modules are essential routing components and can be small by parameterizations.
Therefore a routing service can be changed significantly but with small energy cost. Sec
ond, different routing services can be obtained by simply changing visiting-pattem param
eters, and various routing services can be brought together for comprehensive experiments
in a unified environment. Third, automatic and concurrent routing services can be built on
top of XVR without changing the routing core. We describe how to use XVR to study ex
isting and new routing algorithms, and how to build automatic routing services on top of
XVR. As a case study, we show how to conduct automatic routing changes between two
known routing services, push and pull, with XVR, and evaluate the performance gains.
1.4 Dissertation Organization
We first give an overview of routing services in mobile ad-hoc networks in Chapter 2
where we discuss and classify different routing algorithms for ad-hoc networks. Then we
10
Reproduced with permission of the copyright owner. Further reproduction prohibited without permission.
present details of the routing state problems of on-demand routing services. By simula
tions, we quantitatively show that the stale state problem is very common in high mobility
cases.
Based on the analysis of Chapter 2, Chapter 3 presents our approach to improve the
on-demand ad-hoc network routing services. This approach contains an active helper that
periodically issues probing packets to collect network state, and then use the collected
information to progressively update the route state. For proof of concept, we use DSR
as a target service for our conservative approach. The resulting service, called ADSR,
collects topology, queue-length, and residual energy readings from ad-hoc networks. The
topology information can be used to improve routing performance when node mobility is
high, the queue-length information can be used to conduct congestion prevention, and the
energy information can be used to realize energy-saving routing. Extensive simulations
of ADSR show that the routing performance is improved up to 47%, and the TCP perfor
mance is improved up to 70%, and the energy consumption per transmitted data is saved
up to 25%.
From Chapter 4 onwards, we discuss routing issues in sensor networks. Chapter 4
gives an overview of sensor network routing services, and then discusses extensively the
motivation for routing changes. We show that different routing services are generally
required for different sensor network systems, different applications in a given sensor
network may ask for different routing services, and a given application and network often
needs to adapt routing when application and network properties change.
In Chapter 5, we propose a new routing architecture for sensor networks called XVR
(X Visiting-pattem Routing) to support routing changes. In this routing paradigm, packet
11
Reproduced with permission of the copyright owner. Further reproduction prohibited without permission.
handlers are separated from their corresponding visiting-pattem components. This sepa
ration enables independent visiting-pattem changes. XVR further parameterizes common
operations of routing services so that routing behavior can be represented with simple
parameters. In the evaluation of XVR, we first show that the code sizes of visiting-pattem
components are an order of magnitude smaller than the size of an entire service. Then we
describe how to use XVR to study existing routing services and explore optimized rout
ing algorithms. Extensive simulations show that XVR can obtain significant changes in
routing behavior by simply changing its visiting-pattem parameters, and different param
eters can lead to comprehensive experiments to find optimal algorithms. As a side effect,
we also show that compared with one-phase pull Directed-diffusion, the corresponding
version of XVR obtains scalable energy consumption while improving delivery ratio by
70%.
As a further step, Chapter 6 discusses one approach to automatic routing based on
XVR. This approach promotes new collaborations among nodes to estimate routing cost,
to decide and to enforce visiting-pattems. As an example, this chapter also describes
how to conduct automatic changes between two known visiting-pattems, pull and push,
without introducing any additional cost. Extensive simulations show that the resulting
automatic service can save energy unlimitedly compared to any single version of pull and
push.
Finally Chapter 7 concludes this dissertation and points out some future work.
12
Reproduced with permission of the copyright owner. Further reproduction prohibited without permission.
Chapter 2
Ad-hoc Network Routing Services
2.1 Overview
A wireless ad-hoc network is a group of mobile nodes that communicate among them
selves using radio, without the aid of a fixed networking infrastructure. Since the topology
of an ad-hoc network changes when mobile nodes go in or out of radio ranges, efficient
routing is an important area of research. There have been a plethora of routing proto
cols proposed for mobile ad-hoc networks. Among them representative routing schemes
include DSDV (Destination-Sequenced Distance Vector [58]), DSR (Dynamic Source
Routing [51]), AODV (Ad-hoc On-Demand Distance-Vector [59]), and ZRP (Zone Rout
ing Protocol [22]).
These routing protocols can be roughly classified into three categories. The first is
called proactive routing where routes to all destinations are maintained. DSDV belongs
to this category. In this protocol, each node in an ad-hoc network periodically adver
tises its view of the interconnection topology with other nodes within the network. The
13
Reproduced with permission of the copyright owner. Further reproduction prohibited without permission.
advantage of proactive protocols is that communications with arbitrary destinations expe
rience minimal initial delay from the perspective of the application. But they suffer the
disadvantage of additional routing traffic that is needed to continually update stale route
entries.
The second category of ad-hoc network routing protocols is called reactive protocols
where a route is acquired only when it is actually needed (on demand). DSR and AODV
belong to this category. The advantage of reactive protocols is that route maintenance
overhead is often less than proactive protocols. But most applications are likely to suffer
a long initial delay since a route discovery phase is needed to obtain routes. This category
of routing protocols have been studied heavily because of their low overhead nature, and
are in the process of standardization.
The third category is in the middle of proactive and reactive protocols, thus is called
hybrid protocols. ZRP belongs to this category. In this protocol, an ad-hoc network is
divided into multiple zones that are defined by a specific zone radius with hop numbers.
In each zone, proactive routing is carried out to maintain destinations within the zone. For
any destination outside the zone of a source, a reactive protocol is used to discover the
route. The hybrid schemes may strike a balance between routing maintenance overhead
and the discovery overhead. As we shall see later, routing protocols proposed in this
dissertation provide a different hybrid approach.
14
Reproduced with permission of the copyright owner. Further reproduction prohibited without permission.
2.2 On-demand Routing Services
On-demand routing services are well-known algorithms in ad-hoc networks because of
their expected low routing overhead. AODV [59] and DSR [51] are representative on-
demand routing algorithms. These two algorithms are currently going through standard
ization by the IETF working groups. This dissertation will focus on adding flexibility to
on-demand routing services. We first give a brief description to each of these two routing
services, and then discuss the problems with their routing state.
Both AODV and DSR flood route requests to discover routes to destinations when
they are needed by applications. However AODV maintains next-hop routes while DSR
maintains complete source routes. AODV is a distance vector routing scheme developed
from DSDV [58], But unlike DSDV which issues broadcasts every time there is a change
in overall connectivity of a network, AODV triggers a broadcast only if a new link status
affects ongoing communications. There is a lifetime associated with each route table
entry that is updated whenever a route is used. If a route is not used within its lifetime, it
is expired and consequently discarded.
In DSR, each data packet that is sent carries in its header a complete ordered list of
nodes, a source route, through which the packet must pass. To reduce the route discov
ery cost, DSR maintains route caches to store routes that have been found via flooding,
passing packets, or through promiscuous overhearing. Each source route in route caches
is also associated with a timestamp enabling dynamic maintenance of the route state.
15
Reproduced with permission of the copyright owner. Further reproduction prohibited without permission.
2.3 Paths in Route State
There are several problems with route state in on-demand routing services for ad-hoc
networks. First, these routing algorithms take no measures to avoid flooding for a route to
a “new” destination, which has not been obtained yet. They have to flood route requests
to get the route and save it in route state. Second, entries in route tables quickly become
invalid or inefficient when node mobility is high. When an inefficient route is used, data
packets suffer unnecessary delays; when an invalid route is followed, route failures will
trigger flooding, creating additional routing overhead and latency for data packets.
It is known that TCP does not work well in ad-hoc networks because of high bit
error rate (BER) in wireless channels, and high frequency of route failures and changes.
High BERs and route failures result in continuous loss of TCP data segments or ACKs. In
addition, route failures cause routes to be re-discovered. If route re-discovery takes longer
than the TCP retransmission timeout (RTO), retransmission is triggered and RTO backs
off exponentially. The consequence is severe reduction in throughput even when there is
no congestion. Furthermore, if the new route is significantly different from the previous
route (e.g., with different route length), it is possible to have out-of-order packets arriving
at the receiver, which could mistakenly trigger congestion control, further degrading TCP
performance.
These on-demand routing services leave the TCP performance issues to upper layer
protocols. There have been several transport layer approaches to deal with the TCP per
formance issues (such as ATCP [46]) that make TCP not overreact to lost packets or out-
of-order packets. Besides these upper layer approaches, we have observed that network-
layer approaches are also important to solve the TCP problems since nodes have the best
16
Reproduced with permission of the copyright owner. Further reproduction prohibited without permission.
knowledge about invalid or inefficient routes. If the network layer can reduce those in
valid and inefficient paths, the upper layer end to end protocol can be relieved much of the
burden to maintain TCP performance. Based on this observation, there have been several
network layer approaches proposed to directly reduce invalid routes ([3] and [18]). The
general approach presented in this dissertation is also a network layer one. The distinction
of our approach is to actively collect state information from a network and progressively
use the information to update route tables. The comparisons of our approach with other
network layer ones will be discussed in detail in Chapter 3.
Another issue with these on-demand routing algorithms is that they do not address
some other routing concerns that are important in ad-hoc networks. For example, they
do not address the energy consumption for routing algorithms. Energy-aware routing
is important in ad-hoc networks since it is often difficult for mobile nodes to find stable
energy source during the life time of the networks [70]. Thus they often operate on energy
provided by batteries. We will show in the next Chapter that energy-aware routing can be
realized by manipulating paths in routing tables via our general approach for on-demand
routing services.
In this dissertation, we use DSR as an example service to apply our proposed general
approach. To show the routing path problem in DSR, we first define that a route cache
miss happens not only when a needed route is not present in caches, but also when a
previous hit has turned out to be incorrect. Both cases trigger route request flooding.
Thus the miss rate quantity gives the degree of flooding. The routing packet number
counts all routing-related packets injected by all nodes in an ad-hoc network in order to
17
Reproduced with permission of the copyright owner. Further reproduction prohibited without permission.
send a certain number of data packets. This quantity reflects overhead of the routing
protocol.
We use ns-2 [76] simulations to measure these quantities. We simulated different
sizes and mobilities of ad-hoc networks to see how miss rates and routing packet numbers
change in different scenarios. In each network, the moving patterns of nodes follow the
Random Waypoint Motion Model [50]. In this model, each node chooses a destination
with a uniformly random distribution over the network area, moves there at a speed uni
formly between 0 and the maximum allowable velocity, stays there for a specified pause
time, and then repeats the behavior. During each simulated session, nodes are uniformly
randomly chosen to be the senders or receivers, and carry out CBR communications for
a uniformly randomly chosen time. The number of CBR connections in each session is
proportional to the number of nodes.
We simulated networks with three different sizes and five different pause times. The
first case is 20 nodes within a 670 m x 670 m area, the second 50 nodes within a 1500 m x
700 m area, and the third 100 nodes within 2000 m x 1000 m area. The tested pause times
are 300 second, 100 second, 50 second, 20 second and 0 second. For the 20 node network,
the maximum connection number that could be built during the simulation session is 40,
that number is 100 for the 50 node network, and 200 for the 100 node network. The
maximum moving speed is 20 m/s. The CBR rate is 4 packets per second. The simulation
time is 500 s. The results shown in Figure 2.1 are averages of 100 simulation runs.
As shown in Figure 2.1, in each network the miss rates and routing packet numbers
generally increase with increasing mobility (pause times changed from 300 ms to 0 ms).
DSR performs well in small-size networks. However, when the network size gets large
18
Reproduced with permission of the copyright owner. Further reproduction prohibited without permission.
(a) miss rates (percent)
3 5
(b) routing packet numbers (per data packet)
Figure 2.1: Route miss rates (percent) and routing packet numbers (per data packet) for
networks with 20, 50, and 100 nodes
19
Reproduced with permission of the copyright owner. Further reproduction prohibited without permission.
(about 100 nodes within 2000 m x 1000 m area), the average route path becomes longer
(the nominal transmission range is 250 m). Since a longer path is more likely to get
invalid than a shorter one, the miss rates go up significantly, and so does flooding. As a
result, the routing packet numbers also increases. Note that the increase in routing packet
numbers is more significant than the increase in miss rates. For example, the miss rate
goes up from 14% to 21% when the network size changes from 50 to 100 with a pause
time of 20 ms, but the routing packet number (per data packet) increases dramatically
from 9 to 30. The reason is flooding goes much further in a large network than in a small
network. Thus the same miss rate entails much higher overhead in a larger network.
20
Reproduced with permission of the copyright owner. Further reproduction prohibited without permission.
Chapter 3
Active Ad-hoc Network Routing
This chapter first describes a general approach to increase the adaptability of ad-hoc net
work routing services and does not change the inner activity of existing algorithms. The
resulting service is called Active Ad-hoc network Routing (AAR). AAR can be used to
improve ad-hoc network routing in multiple aspects, depending on what state information
is collected to update the route table. As one implementation, AAR is applied to DSR.
The resulting service, called ADSR, shows improvement in high mobility case, energy
consumption, and congestion case. Extensive simulation results are also presented to
quantify the route cache performance and TCP performance with ADSR.
3.1 Active Helper
The basic idea of AAR is to use a helper module to work beside the ad-hoc network
routing module. The role of a helper module is to collect state information from an ad-
hoc network, and to update route table with the collected state information. Different state
information can lead to route cache updating from different perspectives, and therefore
can improve performance in different aspects.
21
Reproduced with permission of the copyright owner. Further reproduction prohibited without permission.
One scheme of helper modules is to periodically issue probing packets to collect state
information. Time is divided into intervals. At the beginning of each interval, one ran
dom node’s helper module is chosen to issue a probing packet whose payload contains
the network state. The probing packet roams around the network to collect state informa
tion. Upon receiving a probing packet, the helper module consults the node’s neighbor
information and updates the state information related to each of its neighbors. The helper
module also checks the node’s route table against the packet content; invalid routes are
removed, inefficient routes are improved, and new routes are added. This way, adaptabil
ity of an ad-hoc network routing is improved. AAR provides a hybrid scheme to realize
ad-hoc network routing since the helper module actively obtains and updates route in
formation while existing routing module reactively acquires routes when being asked by
applications.
The interval value for each visit period is an important parameter to tune the perfor
mance of the AAR. The shorter the interval, the more frequent the updates, and more
recent the route table entries. However, a shorter interval also means that there are more
probing packets roaming around the network. The interval value should be chosen to keep
data rate high and routing overhead low.
3.2 One Implementation - Active DSR
As an implementation, we apply the AAR approach to DSR, obtaining a service called
ADSR. The ADSR implementation is specified by a visiting-pattem of probing packets,
state to be collected, and a routing cache updating algorithm. In our implementation,
22
Reproduced with permission of the copyright owner. Further reproduction prohibited without permission.
we use a depth-first traversal for visiting each node in an ad-hoc network. The col
lected state includes network topology information [26], queue-length information [28],
and remaining-energy readings of each visited node. Note that there are other possible
visiting-pattems and other possible state. For example, location information can be used
to conduct geographic-aware exploration. Also, statistics state can be collected to conduct
QoS-aware routing.
Due to the depth-first property of a probing packet, next node to be visited is generally
a neighbor of a node that is currently being visited, except when backtracking happens. In
this occasion, the next node is a neighbor of some previously visited node. A mechanism
is needed to have the probing packet go back to the previous node of already visited node
so that the visit can continue. Our method is to let the helper module compute a route on
the fly from the current node to the previous one according to the topology information
that has already been collected. The topology information is indeed in place because the
previous node has already been visited when the computation is needed.
Besides the topology information, a probing packet also collects queue-length infor
mation. The queue-length information may reflect the congestion degree of the queue.
A queue-length larger than a predefined threshold indicates that the node needs to be
relieved burden of packet forwarding. With the collected topology and queue-length in
formation, route cache can be updated to reduce route failures and avoid those nodes that
are likely congested. First, each routing entry is checked against the collected topology
information and those that disagree are removed. This way, the flooding coming from
route failures is reduced. Second, the helper module adds routes learned from the topol
ogy information. Thus better routes can be obtained and flooding from “new” routes are
23
Reproduced with permission of the copyright owner. Further reproduction prohibited without permission.
reduced. The route changes caused by mobility are captured by ADSR. This also means
that TCP packets are less likely to be dropped because of route failures or changes, and
unnecessary retransmissions are reduced.
Further, the helper module computes an alternate path for each existing route that
passes the congested node. An alternative path must be computed with care so that it
has the same length as the old path to reduce reordering packets caused by path-length
changes. To find an alternate path to avoid a bottleneck node, the immediate predecessor
and successor of such a node are first checked to see if they have common neighbors that
have a safe queue length. To avoid overloading such alternate nodes, ADSR randomly
chooses one from all candidates. If there are no such common neighbors, the second
immediate predecessor and successor are checked to see if there are any two nodes that
have a safe queue length and connect the predecessor and the successor together. In this
way, ADSR always looks for an alternate route with the same length. If ADSR can’t find
an alternate route after several tests, ADSR just simply uses the old route, with a hope
that the congested node will have a shorter queue length after a while. In our extensive
simulations, alternate routes are found in most cases during the first attempt. With the
queue-length information, TCP performance can be further improved under congestion
cases. Note that the queue-length threshold must be chosen carefully; its value should
approximate the maximum since otherwise there would be unnecessary route changes
that would degrade the system performance.
In addition, an active helper can conduct energy-aware routing by monitoring the
remaining energy reading in each node passed by probing packets. When probing packets
detect that a node has remaining-energy smaller than a threshold, that node is marked.
24
Reproduced with permission of the copyright owner. Further reproduction prohibited without permission.
During a routing-cache updating phase, alternative routes are computed to avoid energy
scarce nodes. The computed routes take measures similar to the congested case so that
alternative paths with the same length as the old ones are found. This way, alternative path
will not increase the delay of data packets. By circumventing the energy-scarce nodes,
significant amount of energy can be saved to transfer a given amount of data.
To ensure visiting efficiency of probing packets in ADSR, they are assigned a priority
higher than DSR and data packets in each network interface queue. This way, waiting
time of probing packets in the queue is minimized and they can go furthest through the
network among all kinds of packets. Besides, this priority order helps reduce route re
quest flooding. When probing packets reach a node before DSR packets, routes requested
by DSR packets may have been added by the probing packets, thus preventing further
flooding of DSR packets.
3.3 Routing and Energy-consumption Improvement
We used ns-2 [76] simulations with CMU’s wireless extensions [20] to test the perfor
mance of ADSR. The random waypoint motion model with a maximum speed of 20
m/s was used for the mobility pattern. We simulated networks with five different pause
times. The network sizes were 50 nodes within a 1500 m x 700 m area, and 100 nodes
within 2000 m x 1000 m area. The tested pause times were 300 seconds, 100 seconds, 50
seconds, 20 seconds and 0 second. For the 50 node network, the maximum connection
number that could be built during the simulation session was 100 for the 50 node net
work, and the number was 200 for the 100 node network. The CBR rate was 4 packets
per second. The simulation time was 500 seconds. The interval value for visiting periods
25
Reproduced with permission of the copyright owner. Further reproduction prohibited without permission.
(a) miss rate (percent)
1 4
— 1 2
£
n 3
Q
S 10
a
C D
rQ
g
s
O
n 3
• B
O
P i
i ;
I !
K
ID S R
fADSR
3 0 0 s 1 0 0 s 5 0 s 2 0 s 0 s
(b) route packet numbers (per data packet)
Figure 3.1: Miss rates and route packet numbers (per data packet) from ADSR for the
50-node network
26
Reproduced with permission of the copyright owner. Further reproduction prohibited without permission.
2 5
■ DSR
Hi AD SR
3 0 0 s 100 5 0 s 2 0 s 0 s
(a) miss rate (percent)
3 5
J S
( 0
Q
U
a
&
4 — >
< d
B
O
p a
3 0
2 5
2 0
1 5
1 0
ID S R
IA D S R
3 0 0 s 1 0 0 s 5 0 s 2 0 s 0 s
(b) route packet numbers (per data packet)
Figure 3.2: Miss rates and route packet numbers (per data packet) from ADSR for the
100-node network
27
Reproduced with permission of the copyright owner. Further reproduction prohibited without permission.
was set as 10 seconds. The results in Figure 3.1 through Figure 3.3 are averages over 100
simulation runs.
Figure 3.1 and Figure 3.2 show simulation results we obtained for route cache miss
rates and overhead. As shown in Figure 3.1 and Figure 3.2, ADSR performs much bet
ter than DSR since miss rates from both stale routes and new routes are reduced. For
small and medium networks, the reduced miss rates are more impressive, while for larger
networks, the savings for routing overhead are more impressive. The reason is that it is
more difficult to have cache entries remain valid with increase in network size. One link
change in a large network leads to lot more route changes. The same value of reduction
in flooding rate has more apparent effects in a large network than in a small network. In
the simulations, the largest improvement for the miss rate is in the scenario of 50-node
network with pause time 0 s, which is 60%. The largest improvement for the routing
packet number comes from the scenario of 100-node network with pause time 0 s, which
is 47%.
We also tested energy savings from the energy-aware method described above. This
set of tests took the same configurations as the ones for other routing tests. The results
are shown in Figure 3.3. In all simulations, all scenarios used the same traffic pattern to
transfer a fixed amount of data. But in each simulation run, different sets of sinks, sources,
and mobility patterns were chosen. As shown in Figure 3.3, 100-node networks consume
a lot more energy to transmit the given amount of data than 50-node networks. Consistent
with the results in routing overhead, energy savings are bigger in large networks than
those in small networks. The largest energy savings is obtained from 100-node networks
with pause time 0 second, which is 25%.
28
Reproduced with permission of the copyright owner. Further reproduction prohibited without permission.
(a) dissipated energy (per data packet) for 50-node networks
0 .4
0 .3 5
0 .2 5
0 .1 5
0 .0 5
3 0 0 s 1 0 0 s 5 0 s 2 0 s 0 s
■ DSR
■ ADSR
(b) dissipated energy (per data packet) for 100-node networks
Figure 3.3: Dissipated Energy (per data packet) for networks with 50 and 100 nodes
29
Reproduced with permission of the copyright owner. Further reproduction prohibited without permission.
3.4 TCP Performance Improvement
For evaluating TCP performance, we simulated both non-congestion and congestion cases.
Various network and traffic scenarios were considered in our simulations. There were two
network sizes: 50 nodes in 1200 m x 600 m area and 100 nodes in 1200 m x 1200 m area.
In each network size, 6 different mobilities were considered, with pause times ranging
from 0 s to 5 s, 20 s, 50 s, 100s, and 200 s. Node movements also followed the random
waypoint model with a maximum speed of 20 m/s. For traffic scenarios, single and mul
tiple TCP connections with CBR background traffic were considered. To produce CBR
background traffic for TCP connections, 25 random CBR connections were introduced
into the 50-node networks, and 50 random CBR connections were put into the 100-node
networks. The CBR packet sizes were 512 bytes. After a warm-up time of 100 sec
onds, TCP connections were established over which FTP transfers were conducted for
the rest of a simulation session. TCP packet sizes were 1268 bytes. TCP Reno was used.
Whether there was congestion or not was controlled by adjusting the CBR sending rate
and the queue length limit. In the non-congestion case, we set CBR sending rate to 40
Kbps and set the queue length limit to 30. Then we increased the CBR sending rate and
shortened the queue length limit to produce congestion scenarios. Each simulation lasted
500 seconds.
3.4.1 Single TCP connection with CBR background traffic
In this set of simulations, in each of network scenarios (totally 12 with different network
sizes and pause times), a single TCP connection was built. The results in Figure 3.4 and
Figure 3.5 were averages over 100 single TCP connections.
30
Reproduced with permission of the copyright owner. Further reproduction prohibited without permission.
=s D U U
- t 500
| 400
— 300
o 200
i —
100
5 2 0 5 0 1 0 0 2 0 0
Pause Time (second)
ADSR
(a) TCP throughput
50
45
5 T 4 0
0.35
a > 30
% 25
^ 2 0
a
15
o
o£ 10
2 0 5 0 1 0 0 2 0 0
PauseTime (second)
(b) routing packet overhead
Figure 3.4: TCP throughput and Routing packet overhead for 50-nodes network with 6
different pause times
31
Reproduced with permission of the copyright owner. Further reproduction prohibited without permission.
Routing Packet (pkt/s) TCP throughput (Kbps)
450
400
350
300
250
200
150
100
50
0
5 20 5 0 1 0 0 2 0 0 O
Pause Time (second)
(a) TCP throughput
200
180
160
140
120
100
80
60
40
20
I
20 5 0 1 0 0 2 0 0
DSR
ADSR
PauseTime (second)
(b) routing packet overhead
Figure 3.5: TCP throughput and Routing packet overhead for 100-nodes network with 6
different pause times
32
Reproduced with permission of the copyright owner. Further reproduction prohibited without permission.
From Figure 3.4 and Figure 3.5, DSR performs better in 50-node networks than 100-
node networks with the same background CBR data rate. DSR has higher TCP throughput
with less routing overhead in small-size networks. This is because routes generally have
very few hops in small networks (with a standard nominal transmission range of 250 m).
A longer path is more likely to fail because of link changes. Thus a TCP connection is
more likely to be interrupted in larger networks. Also a route request in a larger network
floods further than in a smaller network, causing more routing overhead.
Since DSR performs poorly in large networks, ADSR gets more opportunity to im
prove TCP performance. In our simulations, ADSR obtains the largest TCP performance
improvements for high mobility cases in 100-node networks, ranging from 50% to more
than 72% (Figure 3.5). Its improvements are noticeable when mobility is high in 50-node
networks as well, up to 35% (Figure 3.4). When mobility is not high, ADSR still ob
tains improvements, with more improvement in 100-node networks than that in 50-node
networks.
Note that routing packet overhead in ADSR (Figure 3.4 and Figure 3.5) is not as low
as that with pure UDP traffic [26]. Controlling the routing overhead under TCP traffic
is not as easy as under pure UDP traffic. This is because TCP provides a conforming
traffic, with throughput changing with network conditions. When TCP throughput is high,
there are many TCP packets traveling through a network. Thus more routing packets are
triggered off, increasing routing overhead. ADSR uses the interval value of the initial
timer to control route updating frequency and routing overhead. In our simulations on
TCP connection(s) with CBR background traffic, ADSR obtains good TCP performance
33
Reproduced with permission of the copyright owner. Further reproduction prohibited without permission.
when the interval parameter is set as 10 seconds for 50-node networks and 5 seconds for
100-node networks.
We observe that TCP performance under DSR is not stable when node mobility is high
and network is large. The upper part of Figure 3.6 shows the standard deviations of TCP
throughput for 100-node networks under DSR and ADSR respectively. We can see that
ADSR reduces the instability of DSR considerably. To see further, we notice that there are
typically three kinds of TCP traffic under DSR: low throughput, medium throughput, and
high throughput. Low throughput traffic generally occurs when routes between sources
and destinations are changed highly frequently. High throughput traffic is from cases
where routes between sources and destinations rarely change. Medium throughput traffic
is somewhere in between. There are extremely low throughput traffic from DSR where
few data segments are transmitted for the whole simulation session. In this case, DSR is
seldom able to find routes before TCP timeouts occur.
ADSR improves performance for all these three kinds of traffic. For low throughput
traffic, ADSR usually obtains dramatic improvement but with higher routing overhead
because of the reasons mentioned above. In the case of extremely low throughput, it
is not unusual for ADSR to improve TCP throughput by more than a factor of 20. For
medium throughput traffic, ADSR generally improves both the throughput and the over
head with a reasonable amount. For high throughput traffic, ADSR obtains comparable
throughput with high improvement for routing packet overhead. The lower part of Figure
3.6 shows three typical TCP traffic for 100-node networks with 50 seconds pause time. In
Figure 3.6, ADSR improves low throughput traffic by 84% with routing overhead about
15% higher. ADSR improves medium throughput traffic by 17% with smaller overhead.
34
Reproduced with permission of the copyright owner. Further reproduction prohibited without permission.
4 5 0
'c/T 400
§ 350
Q 300
to
- 3 250
-&200
2 150
o_ 100
O
I- 50
5 0 1 0 0 2 0 0 20
P au se Time (second)
(a) TCP throughput standard deviations
Traffic typ e
T h rou ghp ut
(K b p s)
R outing
(pk1
p a c k e ts
ts/s)
D S R A D S R D S R A D S R
Low throughput 2 3 5 .2 4 4 3 1 .7 9 1 1 9 .5 1 3 5 .1 8
M edium throughput 2 6 5 .7 8 3 2 0 .9 1 100.1 9 7 .2 3
High throughput 4 8 0 .7 8 4 8 1 .7 5 1 4 4 .5 8 1 1 3 .8 2
(b) three typical traffic
Figure 3.6: TCP throughput standard deviations for the 100-node networks & Three typ
ical traffic for the 100-node networks with pause-time of 50 seconds
35
Reproduced with permission of the copyright owner. Further reproduction prohibited without permission.
2 0 0 0 0
18000
16000
14000
to 1 2 0 0 0
5 10000
% 8000
B- 6000
4000
ADSR
DSR
2000
150 250 300 350 400 450 500 100 200
Tim e (seconds)
(a) trace of low throughput traffic
14000
1 2 0 0 0
10000
8000
ADSR
- DSR
g 6000
5
4000
f
2000
100 150 200 250 300 350 400 450 500
Tim e (seconds)
(b) trace of medium throughput traffic
22000
20000
18000
16000
14000
12000 ♦ A D S R j
« D S R j
g 1 D O O O
c
§ . 8000
a >
0 0 6000
4000
2000
150 200 250 300 350 400 450 500 100
T im e ( s e c o n d s )
(c) trace of high throughput traffic
Figure 3.7: TCP sequence number traces for the three typical traffic: low throughput,
medium throughput and high throughput
36
Reproduced with permission of the copyright owner. Further reproduction prohibited without permission.
ADSR obtains a comparable throughput for high throughput traffic but with 22% lower
overhead. Figure 3.7 shows sequence number traces for three connections.
Note that in low throughput case of Figure 3.7, timeouts between 100 second to 175
second are not removed by ADSR. There are two reasons why ADSR sometimes cannot
keep connections alive. The reason is that in high mobility networks routes provided by
ADSR are likely to become invalid soon after an ADSR packet visit. If TCP packets
happen to arrive after the routes become invalid but before the next visit, these packets
cannot go through and some of TCP RTO backoffs are not stopped. In Section 3.4.3 we
will discuss the second reason for not keeping connections and a corresponding solution.
Since it is unlikely to remove all packet losses in high mobility ad-hoc networks, ADSR
focuses on significantly reducing unnecessary RTO backoffs. As shown in Figure 3.7,
ADSR removes timeouts between 175 second and 315 second for low throughput traf
fic, and completely removes timeouts for medium throughput traffic. As a result, TCP
throughput is significantly improved.
In high throughput traffic case, there are new temporary timeouts introduced by ADSR
between 340 second and 360 second, which do not happen with DSR. This is because
some temporary route changes are captured by periodic ADSR packets. These route
changes disappear soon after one visit but well before the next visit, which causes TCP
packets cannot go through for a short while. These timeouts last only for a short while
because subsequent ADSR packets soon restore routes. TCP throughput is not affected
by this phenomenon as shown in Figure 3.7.
37
Reproduced with permission of the copyright owner. Further reproduction prohibited without permission.
rr 700
J - 600
§ * 500
o
|= 400
£ 300
O
I- 200
100
0
2 5 10 20
Number of TCP connections
-♦ — DSR
• —ADSR
(a) TCP throughput
300
270
S ' 240
o_ 210
180 CD
H 150
^ 1 2 0
--§ 90
J 60
30
5 10
Number of TCP connections
20
-♦— DSR
• — ADSR
(b) routing packet overhead
Figure 3.8: TCP throughput and Routing packet overhead for 2, 5, 10 and 20 TCP con
nections
38
Reproduced with permission of the copyright owner. Further reproduction prohibited without permission.
3.4.2 Multiple TCP connections with CBR background traffic
We simulated 2, 5, 10, and 20 simultaneous TCP connections in 100-node networks with
0 s for pause time. Results in Figure 3.8 were averages over 100 simulations.
From Figure 3.8, ADSR’s improvements in multiple TCP connections are noticeable
(up to more than 30%), but not as high as in single TCP connections. Also, the improve
ment decreases with increase in the connection number. This is because with multiple
TCP connections, nodes may obtain routes needed by one connection from other connec
tions when they have multiple flows passing by. Thus route failures are reduced and TCP
throughput is improved. In this set of simulations, we also use a value of 5 seconds as the
interval parameter. With this parameter, the savings of routing packet overhead are larger
than for the single TCP case.
3.4.3 TCP connections with congestion
We introduced congestion scenarios by doubling the CBR data rate and reducing the
queue size limit from 30 to 10. During this set of simulations, we observed that the queue
size limit was reached, which implied congestion. We tested both single and multiple TCP
connections with 100-node networks with 0 s for pause time. After monitoring queue-size
changes during simulations, we chose the congestion control threshold for the queue size
as 8. This value fits our simulation cases since there are some but not many nodes with
queue sizes larger than 8.
The results in Figure 3.9 are averages of TCP throughput over 100 simulations. Since
routing packet overhead is similar to Section 3.4.2, the results for the routing packet
overhead are not shown here.
39
Reproduced with permission of the copyright owner. Further reproduction prohibited without permission.
960
880
' T n 800
§ 720
640
K 560
" § ) 480
I 400
~ 320
O 240
160
80
0
Figure 3.9: TCP throughput under congestion situations for the 100-node networks
Comparing Figure 3.9 with Figure 3.5 and Figure 3.8, we can see that TCP throughput
in DSR is reduced significantly because of congestion. When the congestion prediction
and prevention is provided, there are noticeable improvements (up to more than 25% com
pared to ADSR without congestion detection). This is because potentially busy nodes are
avoided for a while, which allows the busy nodes to process and free enqueued packets.
To see further how ADSR responds to congestion, Figure 3.10 shows a typical case
for a single TCP connection. In Figure 3.10, DSR performs poorly because TCP RTO
backoffs happen at the time around 350 second. TCP sender does not successfully send
any data segments from that time till the end of the simulation session. ADSR without
congestion detection improves over DSR by restoring the connection at around 450 sec
ond. However, TCP still keeps timeouts at the time from 350 second to 450 second. This
is because intermediate nodes along the routes become congested and drop packets. Lost
40
♦
-D S R
— ■ —
-A D SR
— A — -A D SR with CC
1 2 5 10 20
Number of TCP connections
Reproduced with permission of the copyright owner. Further reproduction prohibited without permission.
7000
6000
5000
= 4000
U 3000
c
| 2000
1000
0
2 0 0 250 300 350 400 450 500 1 0 0 150
Time (seconds)
* DSR
(a) trace with DSR
8000
7000
6000
C D
f 5000
^ 4000
5 3000
2000
1000
200 250 300 400 450 500 100 150 350
Time (seconds)
(b) trace with ADSR
. ADSR with CC
(c) trace with ADSR Congestion Control
Figure 3.10: TCP sequence number traces for one congested case with 1 TCP connection:
DSR, ADSR, and ADSR with Congestion Control
41
Reproduced with permission of the copyright owner. Further reproduction prohibited without permission.
5500
5000
4500
i 5 4 0 0 0
f 3500
z 3000
U 2500
§ 2000
£ 1500
1000
500
1 0 0 150 200 300 350 400 450 500 250
Time (seconds)
« Second Sender
« First Sender
(a) trace with DSR
8000
7500
7000
6500
. 6000
a J 5500
| 5000
^ 4500
t 4000
“ 3500
5 3000
§ ■ 2500
S 2000
1500
1000
500
0
1 0 0 150 200 250 300 350 400 450
Time (seconds)
♦ Second Sender
• First Sender
(b) trace with ADSR
5500
E 5000
5 5 3000
1 3
5- 2500
■ < n 2000
150 200 250 300 350 400 450
Time (seconds)
, Second Sender
* First Sender
(c) trace with ADSR Congestion Control
Figure 3.11: TCP sequence number traces for one congested case with 2 TCP connec
tions: DSR, ADSR, and ADSR with Congestion Control
42
Reproduced with permission of the copyright owner. Further reproduction prohibited without permission.
packets trigger the exponential backoffs of TCP RTO. Note that there are new temporary
timeouts introduced by ADSR between 220 second and 240 second. Due to reasons men
tioned in Section 3.4.1, these temporary timeouts do not adversely affect TCP throughput.
ADSR with congestion detection mechanism gets rid of the timeouts from 350 second to
450 second by providing alternate routes to the congested nodes. The TCP connection is
thus kept and throughput increases significantly.
Figure 3.11 shows a typical case for the 2-connections. We can see that connections
for both the first sender and the second sender are improved in ADSR without congestion
control. For the second sender, the ADSR improves the connection at the time from 370
second to the end of the simulation. For the first connection, the plain ADSR improves
the connection between 125 second and 140 second and at the last 30 seconds of the
session. But there are some timeouts that cannot be avoided by ADSR, especially in the
first connection.
We have explained in Section 3.4.1 one reason why ADSR cannot keep connections
all the time: ADSR sometimes cannot provide accurate routes to new arrivals of TCP
packets in high mobility networks. Some timeouts in the first connection are due to this
reason. The other reason is that congested nodes drop packets from flows passing by.
ADSR with congestion detection does provide help in this case. For example, at the time
slot between 220 second and 280 second for the second connection, route changes from
alternate paths do reduce timeouts. Especially, at the time slot between 225 second and
310 second for the first connection, alternate routes significantly improve TCP connection
and throughput.
43
Reproduced with permission of the copyright owner. Further reproduction prohibited without permission.
3.5 Related Work
ADSR is implemented in ns-2 [76], which integrates a DSR implementation from the
Monarch project. The DSR implementation in ns-2 conforms to the latest IETF version
of DSR (written in 2004 [51]); most standardizing features have been integrated into the
ns-2 implementation. Some of these features are directly related to ADSR. For example,
the automatic route shortening feature can obtain shorter source routes if one or more
intermediate nodes become unnecessary. The effect of this feature is similar to ADSR that
also attempts to find shorter routes. In DSR the shortening is done based on node’s local
information. However in ADSR the shortening is done based on topology state collected
by probing packets, which may include more information than that locally available. Thus
ADSR can complement this feature by providing more state information. Other features
in DSR are orthogonal to the ADSR approach. One such example is the flow state feature
in which implicit source routes are used to reduce the size of routing packets. This feature
also have effect in ADSR since ADSR is implemented without changing DSR. Simulation
results have shown that ADSR can improve the implemented DSR.
There are other variants of DSR that are not detailed in the IETF version. One in
teresting question is whether the ADSR approach can improve these variants. In [37]
a link-based cache structure is proposed that encodes more topology information than a
traditional path-based cache structure. The ADSR implementation uses the path-based
cache structure provided by the basic DSR module. However the route cache in ADSR
also contains more topology information than the one in DSR because of the proactive
44
Reproduced with permission of the copyright owner. Further reproduction prohibited without permission.
state-collection by probing packets. On the other hand, the ADSR approach is indepen
dent from the data structure of route caches. ADSR can further improve the link-based
cache by providing more topology information.
In [18], a mechanism is proposed to detect broken links before their uses, therefore
reducing route failures. In [52], the route failure notification mechanism of DSR is ex
tended so that all nodes having related broken link are informed to remove them. [52]
also introduces negative caches to avoid using broken paths. Removing broken links is
similar to the validation phase of ADSR in which all paths in route caches are checked
against collected state information and those that do not agree with the state are removed.
But these two variants do not include any mechanism, as in ADSR, to find better routes.
Thus ADSR can work with these two variants and reduce their route cache miss rates for
new routes.
In [21], a node records hop counts for each flow it passes packets on and shortens
the route for the current flow when detecting that there is a shorter path from recorded
flows. This variant can be regarded as a generalization of the automatic route shortening
feature in DSR. Similar to this feature, the variant uses only local information to make
shortening decisions. In ADSR, more topology information can be collected and utilized
to shorten existing paths. In addition, ADSR can validate each path in route cache, which
is not done in this DSR variant. Thus ADSR can further improve the performance of this
variant of DSR.
Besides collecting topology information, ADSR can collect other state information
to improve DSR routing. In particular, the ADSR implementation collects queue-length
45
Reproduced with permission of the copyright owner. Further reproduction prohibited without permission.
information from an ad-hoc network to improve the DSR performance in congested con
ditions. To the best of our knowledge, there has been no other DSR variants that achieves
this improvement.
3.6 Summary
AAR is a general approach in which a helper module works independently to collect
network information and update routing state. By collecting different network informa
tion, different aspects of target routing services can be improved. This general approach
therefore can increase adaptability of target routing services in multiple perspectives.
With the ADSR implementation, not only existing routes can be validated, but also
new routes can be obtained using collected topology information. Thus both route re
quest flooding for the stale routes and new routes are reduced. Because ADSR generally
captures route changes before TCP timeouts, TCP RTO backoffs are reduced and TCP
throughput is improved significantly. In congestion cases, ADSR collects queue-length
information in a network and computes alternate routes to circumvent those nodes that
are prone to be congested points. This further improves TCP performance by congestion
prevention.
46
Reproduced with permission of the copyright owner. Further reproduction prohibited without permission.
Chapter 4
Sensor Network Routing Services
4.1 Wireless Sensor Networks
Technological advances have led to the emergence of small, low-cost, and low-power
devices that integrate micro-sensing with on-board processing and wireless communica
tion capabilities ([36], [61], and [63]). These sensors can be deployed in large scale and
deeply embedded with a physical environment. They can obtain high-quality data about
the physical environment by collaborating with one another. Besides, each sensor node
can operate autonomously with no central point of control and can make decisions based
on the information it currently has, and the knowledge of its computing, communication
and energy resources. Sensor networks find applications spanning many domains includ
ing military, medical, industry, and home networks.
Similar to ad-hoc networks, sensor networks accommodate communications among
nodes without a fixed networking infrastructure. However sensor networks are signifi
cantly different from traditional ad-hoc networks due to the resource-constrained nature
and the deployment environment of sensor nodes [2], They have small size, operate with
47
Reproduced with permission of the copyright owner. Further reproduction prohibited without permission.
battery, and are prone to failures. In a sensor network, communication is very energy-
expensive compared to computing. Thus, a key challenge is to realize energy-efficient
communication that should be investigated from the physical layer up to the application
layer. Another challenge is to design self-configuring protocols among unattended sensor
nodes [16]. These properties and challenges distinguish sensor networks from traditional
ad-hoc networks, and suggest the development of a different suite of networking protocols
for sensor networks.
4.2 Existing Routing Services
The goal of a sensor network is to collect, process, and forward sensed data to other sensor
nodes and/or base stations. Therefore, a routing service is essential to sensor network
applications. Many routing services have been proposed for sensor networks. Some
of them include Greedy Perimeter Stateless Routing (GPSR) [41], Geographical Energy
Aware Routing (GEAR) [85], Trajectory Based Routing (TBF) ([55]), Directed-diffusion
[39], Two-Tier Data-Dissemination (TTDD) [83], and Rumor-routing [7]. Other routing
services, which this dissertation will not address but can be supported by our general
approach, include LEACH [34], SAR [71], SPIN [35], CBM [87], and CBGR [64]
These routing services have distinct properties than those traditional routing such as
OSPF [53], RIP [30], DSR [51], and AODV [59] because of the resource-limited property
of sensor networks. First, flooding is conducted more carefully in sensor networks since
flooding is very energy expensive. These routing services take additional measures to
control the scope and frequency of flooding. Second, data are generally forwarded in
sensor networks without explicitly addressing individual nodes. For example, GPSR takes
48
Reproduced with permission of the copyright owner. Further reproduction prohibited without permission.
locations instead of IP addresses as routing destinations. TBF uses a trajectory instead of
a node-path as its routing unit. Further, data-centric paradigm is often used in sensor
networks where data attributes are actively used to direct routing activities.
In the following, we describe several data-centric routing services for sensor networks
(such as Directed-diffusion, TTDD, and Rumor-routing) as we will apply a general ap
proach to these routing algorithms. In the main version of the Directed-diffusion scheme
[39], sinks flood interest packets into networks. These interest packets build state along
their paths that indicate which neighbors have interest in certain data. When these inter
est packets meet with sources, the sources issue available packets that indicate they have
matched data. These available packets follow reverse paths of the interest packets to reach
sinks. When sinks receive the available packets from sources, the sinks choose paths of
certain available packets to reinforce as the routes between sources and sinks.
TTDD [83] is designed for disseminating data from static sources to mobile sinks in
sensor networks. In this algorithm, there is a grid structure built by a source when data
becomes available. Each grid node builds state that indicates from which neighbor the
data is available. Sinks issue interest packets to search for local grid nodes. When a grid
node is found, the interest packet follows the paths indicated by the state of grid nodes to
reach the source. This way, a route between a pair of sink and source is built. In Rumor-
routing [7], a sink randomly chooses one neighbor to forward its interest packet, while a
source randomly chooses one neighbor to forward its available packet. Each of these two
categories of packets build state along the way that points toward the packet originators.
When an interest or available packet passes a node with matched state, a route between a
sink and a source is built.
49
Reproduced with permission of the copyright owner. Further reproduction prohibited without permission.
4.3 Motivation for Routing Changes in Sensor Networks
Sensor networks can support many new applications such as habitat monitoring ([9] and
[74]), animal migration monitoring (Zebra Net [47]), environmental monitoring [15],
structural monitoring [78], target identification and tracking ([45], [62], and [86]), surveil
lance systems ([23] and [1]), biomedical sensing [66], terrorism countering [69], and
smart surroundings ([42] and [72]).
Each of these sensor network systems is built for a set of specific applications. To
meet the application requirements and network properties, it is often necessary to use a
routing service specific to a given sensor network system. For example, in a habitat mon
itoring sensor network [9], directed-diffusion [39] is used to build a routing tree between
static sinks and sources in different geographical areas. Another example is a structural
monitoring sensor network [78], where reliable delivery of structural-response data is re
quired. Thus the routing service in this system builds a dynamic tree between sources
and the base station with good-connectivity links [77]. In a video sensor network pro
posed by Sensorium to collect and understand video data [1], for transferring streamlined
video data in this network, a disperse routing scheme is proposed to enable multiple-path
transmission.
Given a certain data type collected by a sensor network, there often be multiple appli
cations that can use the data. These applications may have different properties and QoS
requirements. As an example, consider a military surveillance system described in [23].
In this sensor network, each sensor node is equipped with a magnetic sensor that can de
tect signals triggered by hostile objects (such as enemy tanks). One supported application
is a monitoring system that continuously collects surveillance data from these sensors. In
50
Reproduced with permission of the copyright owner. Further reproduction prohibited without permission.
this monitoring case, a diffusion-like protocol provides an energy-efficient routing scheme
[39]. Another application may need these real time surveillance data, but with a different
requirement. Suppose a set of soldiers need to explore the surveillance area and need to
be informed, in real time, of any hostile object in the field. As one solution, a monitoring
base station could broadcast collected data continuously to each soldier. However this is
not an energy-efficient routing solution to accommodate mobile soldiers. A better rout
ing scheme can be the one in which sources directly send sensed data to mobile soldiers
(TTDD - Two Tier Data Dissemination [83]). As another example, each soldier may not
need to know all hostile objects in the field, and only needs to know the hostile objects
that may impose a danger. In this case, each soldier only needs to obtain sensed data in
a subregion of the monitoring field that is determined by the properties of hostile objects
and direction of that soldier’s movement (CBM - Content-Based Multicast [87]).
Further, given an application in a specific sensor network, the application and network
dynamics may necessitate routing service changes to save overall energy consumption
while meeting the application requirements. For example, during lifetime of an applica
tion, sinks or sources may change (say, in terms of numbers or physical locations), and
network topology can change frequently due to dynamic nature of sensor networks. In a
routing service in which sinks or sources issue control packets along geographical curves
to discover or announce available data [55], location and topology changes may suggest
different geographical curves to save energy. As another example, Rumor-routing [7]
works well in a highly dense sensor network since a random query packet is likely to
meet a matched source. But when a network becomes sparse due to accumulated com
munication failures or energy exhaustion in nodes, randomly issuing a query packet may
51
Reproduced with permission of the copyright owner. Further reproduction prohibited without permission.
not work. Changing routing to another scheme that is feasible in a sparse network (such
as diffusion [39]) will solve this problem. Another example is pull and push versions of
Directed-diffusion that perform differently when sink/source numbers change ([33] and
[43]). A better routing scheme can be obtained by always choosing the least-cost version
among these algorithms depending on the conditions.
In summary, supporting specific applications in energy-constrained and dynamic sen
sor networks urges the need to change underlying routing service depending on network
and application properties. In our vision, application development for sensor networks
can be greatly simplified if there is a flexible routing service that can adapt to different
application and network properties. Equipped with this flexible routing service, sensor
nodes can meet different data collection requirements under different network situations
by simply tuning routing service themselves. This way, application developers for sensor
networks need not carry the burden of deciding routing services and can concentrate on
the specific application domain issues. Consequently, product deployment time can be
significantly reduced.
4.4 Routing Change Requirements for Sensor Networks
Given the necessity to change routing services in sensor networks, this section discusses
requirements to conduct efficient routing changes. First, the changes can be significant.
That is, routing services can be changed not only in terms of simple performance parame
ters such as control packet intervals, but also in terms of routing behaviors. For example,
routing algorithms should be able to change from TTDD to Rumor-routing.
52
Reproduced with permission of the copyright owner. Further reproduction prohibited without permission.
Second, routing changes should be done with little additional energy consumption.
This requirement may conflict with the first requirement since significant changes may
need significant code changes. Existing routing services for sensor networks are generally
statically configured into each sensor node that is often unattended. Without re-collecting
sensor nodes, one approach to change routing is to transmit new routing code to each
node. Transmitting binary routing code can be very energy-expensive because of signifi
cant code size and reliable transmission requirement. It will be desirable if the significant
changes can be realized with small code components or with specific parameters.
Third, routing changes can be done automatically. With this property, adapting routing
services can be done with least human intervention. This dissertation will describe a
general approach to meet the first and second requirements in Chapter 5, and will discuss
a collaborative approach to address the third requirement in Chapter 6.
53
Reproduced with permission of the copyright owner. Further reproduction prohibited without permission.
Chapter 5
XVR - X Visiting-pattern Routing
In this chapter, we propose a new routing architecture for sensor networks to support
flexible routing with low energy overhead [25].
5.1 Visiting-patterns of Packets
To describe our general approach to routing changes in sensor networks, we first intro
duce a visiting-pattern concept. Visiting-patterns of packets indicate where packets go
as next hop(s) in a network. For a specific packet, concatenation of its visiting-patterns
from its source (where that packet was originated) to its destination(s) (where it is con
sumed or dropped) constitutes a path (or paths) in the network. A routing service for
sensor networks generally includes several types of packets, each of which has specific
visiting-pattern. These packets can be roughly classified as routing control packets and
data packets. The former category of packets are issued to help build routes between
sources and destinations and the latter packets include some data and may follow the built
routes. For routing control packets, their visiting-patterns are associated with routing
54
Reproduced with permission of the copyright owner. Further reproduction prohibited without permission.
Next-hop Selection function
GPSR Closest or perimeter neighbor to destina
tion
GEAR Closest to destination areas or multiple
neighbor(s)
TBF Neighbor(s) along trajectory
Directed-diffusion Interested neighbor(s)
TTDD Interested grid cross-point neighbor(s)
Rumor-routing Next hop in routing state
Table 5.1: Visiting-patterns of Data packets in Sensor Network Routing Services
overhead since the set of paths they follow are directly related to routing communica
tion cost. For data packets, their visiting-patterns are related to routing efficiency since
the paths they take reflect how efficient are the paths produced by an underlying routing
service. Note that there are cases when data packets are used to build routes, such as in
Directed-diffusion, where data packets are periodically marked as control packets to take
part in route building. In these cases, the data packets follow visiting-patterns of routing
control packets.
Visiting-patterns involve choosing among neighbors to decide next hops. This process
sometimes needs to check state information and forwarded packet before making a deci
sion. The state may include neighbor information, statistical information, and application
specific information. Packets can be checked for their headers or even contents. Here,
neighbors can be defined as nodes within one hop or multiple hops from a node’s radio
nominal range. Visiting-patterns can be fixed, especially when there is no available state
information. Visiting-patterns are dynamic when state information and packet should be
examined before forwarding.
55
Reproduced with permission of the copyright owner. Further reproduction prohibited without permission.
TTDD Rumor-routing
source node
sink node
intermediate node
Directed-diffusion
Figure 5.1: Visiting Patterns of Control Packets for Publication/Subscription-based Rout
ing Services
Figure 5.1 shows three example visiting patterns of control packets, and Table 5.1 lists
visiting-patterns of data packets for existing routing services. Before describing visiting-
patterns for each example service, we would like to classify routing services roughly into
two categories: publication and subscription based and forwarding-based. In publication
and subscription based services, sources act as publishing nodes and sinks as subscribing
nodes. Sources issue publishing control packets while sinks issue subscribing packets.
When these two kinds of control packets meet together, routes between sources and sinks
are built. For forwarding-based routing services, there is no need for sources and sinks to
publish or subscribe. Instead, packets are directly forwarded based on state information
and/or packet.
56
Reproduced with permission of the copyright owner. Further reproduction prohibited without permission.
For routing services listed in Table 5.1, GPSR, GEAR, and TBF are forwarding-based
routing services. They issue control packets to collect neighbor information. The visiting-
patterns of their control packets are simple; one-hop flooding is often enough. For other
packets, GPSR [41] checks packet header to obtain destination location and then choose
from neighbors the closest one to the destination as next hop. When no such neighbor can
be found (a hole exists), a neighbor along the perimeter of that hole is chosen as the next
hop. GEAR [85] is extended from GPSR, allowing the destination to be a geographic
area. Remaining-energy readings of neighbors are also considered to choose energy-
efficient routes. When a packet reaches the destination area, a local flooding is conducted
to disseminate the packet to every node in that area. TBF ([54] and [55]) forward packets
based on certain trajectory that is carried in packet headers. Its visiting pattern is to choose
neighbors along that specific trajectory.
For other routing services in Table 5.1, they are publication/subscription-based ser
vices. Their control packets involve significant visiting patterns as shown in Figure 5.1.
There have been multiple versions of Directed-diffusion [33], and the one shown in Fig
ure 5.1 is the classic two-phase pull version [39], In this case, sinks issue subscription
packets toward sources via flooding. Upon receiving subscription packets, sources issue
publication packets along paths of the subscription packets toward sinks. When publi
cation packets reach sinks, paths from sources to sinks are then built. In TTDD [83],
sources issue publication packets along a geographic grid structure throughout a network.
Sinks issue subscription packets via local flooding. When subscription packets meet any
grid cross-point node, packets are forwarded toward sources to build routes. In Rumor-
routing [7], both sources and sinks send unicast control packets with some probability
57
Reproduced with permission of the copyright owner. Further reproduction prohibited without permission.
Handler + VP 1
Handler + VP 2
Handler + VP n
State
Traditional Routing
VPl
Handler 1
VP 2
Handler 2
=>
Handler n VPn
State
XVR
Figure 5.2: Routing Architecture Change with XVR
toward each other. When a subscription packet reaches a node with publication state,
a route is built. As shown in Table 5.1, the visiting-patterns of data packets for these
publication/subscription-based services are simple, mostly along path state built by con
trol packets.
In summary, visiting patterns are a key difference among routing services; many rout
ing algorithms share state-collecting properties but with different visiting-patterns. If
visiting-patterns can be separated and independent from these properties, the resulting
routing service will become a flexible one that has an extensive routing behavior space by
allowing individual specifications for visiting-patterns.
58
Reproduced with permission of the copyright owner. Further reproduction prohibited without permission.
5.2 Architecture
Figure 5.2 shows a new routing architecture proposed for XVR. In traditional routing ser
vices, each packet handler is combined together with the corresponding visiting-pattern.
In XVR, each visiting-pattern module is decoupled from its associated packet handler.
These separated packet handlers consist of a routing core whose function is to main
tain state information. The routing core calls visiting-pattern modules to obtain next-hop
information when issuing or forwarding packets. During the process of deciding next
hop(s), visiting-pattern modules may check the state information. “X” in the name of
XVR represents the fact that visiting-patterns are unknown to routing core; the routing
core just simply follows whatever next-hop information is given by visiting-pattern mod
ules.
The benefits of decoupling visiting-patterns from the routing core are threefold. First,
routing behavior of XVR can be changed without modifying the routing core. Thus pro
gramming effort and energy consumption of changing routing algorithms is significantly
reduced ([27] and [24]). Second, independent visiting-pattern modules can facilitate a
dedicated study about implications of various visiting-patterns. By checking all possible
visiting-pattern parameters, different routing services can be compared in a unified envi
ronment and visiting-pattern heuristics to applications can be identified. Third, separate
visiting-patterns allow changes from other entities than the routing service itself. Allow
ing changes from other entities is necessary since the routing module itself often cannot
collect all information needed to make a change decision. These entities can be system
59
Reproduced with permission of the copyright owner. Further reproduction prohibited without permission.
administrators who statically deploy suitable visiting-patterns according to their experi
ence, or some automatic modules that detect application and network dynamics and make
the change decisions.
Note that there can be multiple ways to implement the XVR architecture, and in the
rest of this section, we describes one implementation that defines certain packet types and
does certain visiting-pattern parameterizations.
5.3 One Implementation
This section presents a basic implementation that parameterizes visiting-patterns of the
publication and subscription based routing services. The XVR takes an attribute-based
naming scheme [31]. For forwarding-based routing services, this naming system is not
necessary, but XVR still uses it to keep packet formats consistent across all represented
routing services. The XVR is designed to meet general situations in a large class of sensor
networks, but does take advantage of specific situations if they do exist. For example, the
XVR does not assume symmetric paths in networks; a path does not need to have the same
latency with its reverse path. But XVR does assume reversible links as required by link
protocols such as 802.11 [13]. Besides, XVR can make use of symmetric paths to realize
routing if such situation is required in a network. As another example, XVR does not
assume that nodes are location-aware, but can make use of location knowledge if sensor
nodes have such capability. Further, XVR does not assume that sensor nodes, including
sources and sinks, are not mobile. These loose assumptions enable XVR implementation
to be deploy ed/adapted in a large set of sensor networks.
60
Reproduced with permission of the copyright owner. Further reproduction prohibited without permission.
This implementation includes a set of visiting-pattern specifications and associated
packet types, a collection of state information, and basic algorithms for the routing core
and visiting-pattern modules.
5.3.1 Visiting-patterns in the XVR
The XVR is a visiting-pattem triggered routing service; first, visiting-patterns of individ
ual packet types are specified, then the XVR loads corresponding packet handlers that
issue or forward packets according to their visiting-patterns. The current XVR imple
mentation supports following five packet types:
• subscription
• publication
• enforcement
• hello
• data
Among them, subscription packets are issued by sinks to express their interest in some
specific data. Publication packets are issued by sources to announce data availability.
Enforcement packets are issued from either sinks or sources to build paths between them.
Hello messages are advertisements issued by each node to collect neighbor information
such as neighbor ids, locations, and energy-readings. Data packets are issued by sources
that include the actual sensed data. The XVR has a packet handler for each of these packet
types. A specific routing service only needs to choose certain subset of these packet types
and those packet handlers that haven’t been chosen are not loaded.
For each chosen packet type, the corresponding visiting pattern can choose from the
following six categories in the current implementation of XVR:
61
Reproduced with permission of the copyright owner. Further reproduction prohibited without permission.
• local
• flooding
• restricted-flooding
• probable-forwarding
• geographic-forwarding
• programmable-forwarding
Among them, the first five categories of visiting-patterns are static parameters while
programmable-forwarding visiting-patterns are dynamic ones. Local visiting-pattem in
dicates that a packet is sent but not out of an originator. The main purpose of a local
visiting-pattem is to build state at originating nodes. Flooding indicates a visiting pattern
from one originator to all nodes in a network. Restricted-flooding is flooding with a TTL
value. Probable-forwarding is to decide if one neighbor will become a next hop with
certain probability value. Geographic-forwarding is a visiting pattern that chooses next
hop(s) along predefined geographic curves. Programmable-forwarding reflects a dynamic
visiting-pattem that can only be decided by consulting certain state information and/or
packets at service runtime. For the first five categories of visiting-patterns, there is also
an associated interval value that specifies the frequency for an originator to issue pack
ets. For probable-forwarding and geographic-forwarding visiting-patterns, a TTL value is
also needed to decide how far packets can go in a network. For the geographic-forwarding
visiting-pattem, a curve parameter also needs to be specified. Probable-forwarding and
geographic-forwarding can be used together to allow probable forwarding along certain
curves.
Note that not all visiting-patterns can be chosen for any packet type in this XVR
implementation. For subscription and publication packets, their visiting patterns can be
62
Reproduced with permission of the copyright owner. Further reproduction prohibited without permission.
Subscription Publication Enforcement Hello Data
Local X X
Flooding X X
Restricted-
flooding
X X X
Probable-
forwarding
X X
Geographic-
forwarding
X X
Program-
forwarding
In code In code In code In code
or Pro
grammable
Table 5.2: Supported Visiting-patterns for Each Packet Type in the XVR
determined either statically or dynamically according to state and thus can follow any of
the six categories. For hello packets, the XVR only allows restricted-flooding for them
that is enough for collecting neighbor information. For enforcement and data packets,
they seldom follow any static visiting-patterns, thus the XVR only allows programmable-
forwarding for them.
To relieve programming burden to indicate dynamic visiting-patterns, the XVR ex
tracts common dynamic visiting-patterns and writes them in the service code. For ex
ample, visiting patterns of enforcement data packets in publication/subscription-based
services can be the same (as shown in subsequent algorithm section). Thus their visiting-
patterns are written into the XVR code. As for visiting patterns of data packets in
forwarding-based services, they are dynamic and different for each service. These visiting-
patterns should still belong to the programmable-forwarding category.
Table 5.2 summarizes visiting-patterns supported by our XVR implementation. As
shown in Table 5.2, the dynamic visiting-patterns of subscription and publication packets
63
Reproduced with permission of the copyright owner. Further reproduction prohibited without permission.
are also written into the XVR code (the reason will be explained in subsequent algorithm
section). Table 5.2 shows a rough parameter space for the proposed XVR implementation.
5.3.2 State Maintained by the XVR
Three packet types in this XVR implementation generate state: hello, subscription, and
publication. The hello packets produce neighbor information state. Neighbor information
state is indexed by neighbor id, each of which includes the latest timestamp of receiving
a hello packet from a neighbor. The XVR dynamically decides what information to be
collected from neighbors by checking visiting pattern parameters. For example, if only
local, flooding, or restricted-flooding are used, the XVR does not issue hello packets
since neighbor information is not needed. If probable-forwarding visiting-pattem is spec
ified, neighbor ids and energy-readings may be included in hello packets. If geographic-
forwarding is used, location information should also be included.
Subscription packets can generate interest state that is indexed by subscribed attributes
and express interest from neighbors about this specified data. Each interest state entry
includes interested neighbors, each of which includes the latest timestamp of receiving
subscription from a neighbor, and an enforced flag that indicates if that neighbor is on
routes from sources to sinks.
Publication packets can generate available state that is indexed by published attributes
and express the availability from neighbors about published data. Each available state en
try includes available neighbors, each of which includes the latest timestamp of receiving
a publication from that neighbor. As an option, each available state entry can record
the latest publication packet received from each source. This information can be used
64
Reproduced with permission of the copyright owner. Further reproduction prohibited without permission.
when nodes receive matched subscription packets (which will be shown in the algorithm
subsection).
All state information is maintained as softstate; an entry will be deleted if its the
corresponding timestamp has expired. These timeout values are determined by interval
values of visiting-pattems of packets that generate the corresponding state. Softstate not
only enables the XVR to react on network and application dynamics, but also provides a
clean transition from one routing service to another one.
5.3.3 Algorithms
The algorithms in current XVR implementation are mostly about publication and sub
scription based routing services. These algorithms can be classified into three categories.
The first one is applicable before publication(subscription) packets pass node with inter
est state(available state)- before-meeting algorithms. The second category is used when
such meetings happen - meeting algorithms. The third category is used after meetings -
after-meeting algorithms.
Before a publication packet reaches a node with matched interest state, it is forwarded
according to its visiting-pattem parameter which can be any ones listed in Table 5.2. In
the meantime, passed nodes build or update available state that constitutes paths from
sources to the nodes. Similarly, before a subscription packet reaches a node with matched
available state, it is forwarded according to its visiting-pattem parameter and passed nodes
build or update interest state that constitute paths from sinks to nodes.
When a publication (subscription) packet passes a node with matched interest state
(available state), packet processing depends on whether the XVR is configured with the
65
Reproduced with permission of the copyright owner. Further reproduction prohibited without permission.
symmetric-path support. Since asymmetric paths are the cases in most wireless networks,
the XVR is configured with this option by default. In case of asymmetric configuration,
each node matches a publication packet with its interest state, and one copy of matched
publication packet is generated and marked as an after-meeting packet. The original publi
cation packet is continuously processed as a before-meeting packet. In case of symmetric
configuration, each node matches a subscription packet with its available state, and one
copy of matched subscription packet is generated and marked as an after-meeting packet.
The original subscription packet is continuously processed as a before-meeting packet.
Note that it is important to keep forwarding the original control packet after a meeting,
because this way every node within the range of a corresponding visiting-pattem can keep
being informed of publication or subscription.
After-meeting packets do not follow the specified visiting-pattem parameters. Instead,
their visiting-pattems are dynamic and are written into the XVR code (Table 5.2). If asym
metric paths are configured, then marked publication packets follow paths in interest state
to reach sinks. When these publication packets arrive at sinks, enforcement packets are
issued from sinks and follow paths of publication packets to reach sources. During trans
mission of enforcement packets, passed nodes update enforced flag in the corresponding
interest state to indicate the nodes that are in the routes. When enforcement packets reach
sources, routes from sources to sinks have been built that are paths of publication packets.
If symmetric configuration is the case, then marked subscription packets follows paths in
available state to reach sources. When subscription packets arrive at sources, enforcement
packets are issued from sources and follow paths of subscription packets to sinks. When
66
Reproduced with permission of the copyright owner. Further reproduction prohibited without permission.
enforcement packets reach sinks, symmetric routes from sources to sinks have been built
that are reverse paths of subscription packets.
Figure 5.3 and Figure 5.4 show flow charts for the before-meeting, meeting, and after
meeting algorithms. Figure 5.3 is for the asymmetric case, while Figure 5.4 is for the
symmetric case. In the asymmetric case, we can see that control packets (publication)
from sources play an active role in finding routes. Therefore this case is also called
sources-active algorithms. Similarly, the symmetric case in Figure 5.4 is also called sinks-
active algorithms.
Note that a duplicate-packet detection mechanism is needed to avoid loops among
paths in interest and available state. This is realized by using a random id and a se
quence number in each packet header. Each sensor node generates its random id when it
is booted up. The random id is chosen within a huge id space to guarantee uniqueness.
The sequence number of a node starts from zero and increments every time the node
produces a packet. Since a packet only needs to be kept for a while, typically not more
than the round trip time along the network diameter, the sequence number space can be
relatively small. With this identification scheme, at any given time, a random id and a se
quence number are enough to identify each single packet in a network. This identification
scheme was originally proposed in the Directed-diffusion implementation [68]. As an
extension, the loop detection mechanism discriminates between before-meeting packets
and after-meeting packets and handle them separately. This way, before-meeting packets
and their after-meeting copies are not treated as duplicate packets of each other. As a re
sult, before-meeting packets can reach every node within their visiting-pattem range, and
67
Reproduced with permission of the copyright owner. Further reproduction prohibited without permission.
Publication
Generate an after-
meeting publication
Build interest state Build available state
Receive a packet
Send it following
interest state
Send the original
publication follow ing the
specified visiting-pattem
Send the subscription
follow ing the specified
visiting-pattem
Figure 5.3: Algorithm flow chart for the asymmetric case
Reproduced with permission of the copyright owner. Further reproduction prohibited without permission.
Subscription
Generate an after-
meeting subscription
Build available state
Receive a packet
Build interest state
Send it following
available state
Send the publication
follow ing the specified
visiting-pattem
Send the original
subscription follow ing the
specified visiting-pattem
Figure 5.4: Algorithm flow chart for the symmetric case
Reproduced with permission of the copyright owner. Further reproduction prohibited without permission.
after-meeting packets can reach every sink/source whose control packets have reached a
matched node.
One optimization is that a matched node in the asymmetric case does not need to con
tinue to forward original publication packets when subscription packets follow “flooding”
visiting-pattem. In the symmetric case, a matched node does not need to continue to for
ward original subscription packets when publication packets follow “flooding” visiting-
pattem. For simplicity, the following explanation is only given for the asymmetric case,
and the symmetric case can be similarly reasoned. When subscription packets take “flood
ing” visiting-pattem, a matched node already has interest state information from all sinks
by the moment meeting happens. Thus forwarding the original publication packet af
ter the meeting does not help for reaching more sinks. The matched node only needs
to generate an after-meeting publication packet to trigger path enforcement. This way,
the energy consumption for transmitting original publication packets after the meeting is
saved.
If the XVR takes the option in which available state records the latest publication
packet received from each source, then meeting algorithms in the asymmetric case can
take an alternative. Instead of having publication packets match with interest state as
shown in Figure 5.3, meeting algorithms match subscription packets with the available
state. Upon a match, the matched node restores recorded publication packets and handles
them as after-meeting packets. Matched subscription packets are stilled processed as
before-meeting packets. There is an optimization in this case; a subscription packet does
not have to continue after meeting with a matched node when publication packets follow
the “flooding” visiting-pattem. This is because whenever a node issues a subscription
70
Reproduced with permission of the copyright owner. Further reproduction prohibited without permission.
packet, its available state has kept publication packet information from all sources before
that moment. A subscribed node only needs to send enforcement packets to respond to the
available state. This way, subscription packets are seldom sent out of subscribed nodes
and the routing overhead is reduced.
Note that since publication packet information recorded in available state makes the
size of state increase with the number of matched sources, this option is not recommended
for building scalable routing services with this XVR implementation. Section 5.5 will
show quantitative results from this option.
5.3.4 Programmable Visiting-patterns
In the XVR, a dynamic visiting-pattem can be added as a programmable component. The
XVR implementation has defined a basic class of programmable component and every
dynamic visiting-pattem needs to be realized by deriving from the basic class [24], The
basic class is a friend class of packet handlers so that the routing state can be read by
programmable visiting-pattems. The basic method a programmable visiting-pattem needs
to instantiate is a selecting function whose inputs are state and a packet to be forwarded.
The output of the selecting function is the next hop information. The programmable
components can indicate any visiting-pattem that is allowed by routing state. Since state-
collecting task has been done by packet handlers, the selecting function can be small
compared to entire routing service. Section 5.5 will show code sizes for some example
programmable visiting-pattems.
71
Reproduced with permission of the copyright owner. Further reproduction prohibited without permission.
Subscription Publication Hello Data Symmetric
GPSR Restricted-
flooding
Program-
forwarding
GEAR Restricted-
flooding
Program-
forwarding
TBF Restricted-
flooding
Program-
forwarding
2pp-
Diffusion
Flooding Local
Push-
Diffusion
Local Flooding
lpp-
Diffusion
Flooding Local X
TTDD Restricted-
flooding
Geographic-
forwarding
Restricted-
flooding
X
Rumor-
routing
Probable-
forwarding
Probable-
forwarding
Restricted-
flooding
X
Table 5.3: Visiting-pattems of the XVR to Emulate Existing Routing Services
5.4 Using XVR
Visiting-pattems open a significant space for XVR to change routing behavior; different
routing algorithms can be obtained by simply changing the visiting-pattems. The visiting-
pattem parameters also enable XVR to provide a unified environment to study various
routing algorithms. This section first describes how XVR helps study existing routing
services, then discusses new algorithms that can be obtained from or built upon XVR.
5.4.1 Existing Routing Services
Table 5.3 lists visiting-pattems the implemented XVR takes to emulate some existing
sensor network routing services. As shown in Table 5.3, there is a need for programming
in the XVR to emulate the forwarding-based routing services. We have implemented two
72
Reproduced with permission of the copyright owner. Further reproduction prohibited without permission.
programmable visiting-pattems to emulate GPSR and TBF respectively. For GPSR, a
simple greedy selection function is implemented which either chooses the neighbor that
is closest to a given destination, or conducts a limited flooding within specified scope.
For TBF, the selection function chooses the neighbor that is closest to the straight line
between a given source and forwarding node itself. By plugging in these programmable
components, XVR can emulate forwarding-based routing services.
The publication/subscription-based routing services shown in Table 5.3 can be ob
tained by using only static visiting-pattem parameters in the implemented XVR. For 2pp-
Diffusion (two-phase-pull version of Directed-diffusion [39]), the emulation of XVR is
straightforward according to the previous description. For push-Diffusion (push version
of Directed-diffusion [32]), XVR emulates it using “flooding” as publication visiting-
pattem and “local” as subscription visiting-pattem; subscription packets never leave sinks
and thus publication packets do not meet interest state until they reach sinks. When em
ulating 2pp-Diffusion and push-Diffusion, XVR also makes use of data packets as publi
cation ones by adding an identifying attribute in chosen data packets. For lpp-Diffusion
(one-phase-pull version of Directed-diffusion [33]), XVR emulates it using the same set
of visiting-pattems as 2pp-Diffusion, but with symmetric processing. In this case, pub
lication packets never leave sources, even after meeting with subscription packets. After
subscription packets reach sources, enforcement packets are issued to build routes. There
are several different points between emulating XVR and lpp-Diffusion. First, data in
XVR do not include flow-ids as in lpp-Diffusion. This way, sizes of data packets do not
increase with the number of sinks and the routing overhead of data packets is reduced.
73
Reproduced with permission of the copyright owner. Further reproduction prohibited without permission.
On the other hand, XVR does issue enforcement packets in symmetric cases but lpp-
Diffusion does not. The enforcement packets add routing overhead in emulating XVR. It
is interesting to see if the overall performance will be affected by these two differences.
The GEAR versions of Directed-diffusion [33] (not shown in Table 5.3) include a
GEAR procedure to process subscription and publication packets before they are sent out.
These services can be emulated by XVR via programmable-forwarding visiting-pattems
for these two packet types.
For TTDD, XVR emulates it using “restricted-flooding” as subscription visiting-pattem
and a specific “geographic-forwarding” as publication visiting-pattems. The publication
packets in TTDD build grid structures throughout a network which can be emulated by
a specific curve in geographic-forwarding visiting-pattem. Current implementation of
XVR supports a curve that includes any number of straight lines in any direction. The
grids can be represented by the following curve parameter:
• starting-angle = 0
• step-angle = 90
• number = 4
• distance = cell-size
The above curve parameters indicate a geographic visiting-pattem shown in Figure
5.5. When all nodes at grid cross-points follow these curve parameters, grid structures
are built throughout a network. A key difference between XVR and TTDD is that TTDD
needs to build per-source grids [83], where grids from different sources cannot overlap.
This requirement may not easily be met in sensor networks and TTDD does not handle
cases when two grids overlap. As described in Section 5.3, XVR allows overlapping grids
74
Reproduced with permission of the copyright owner. Further reproduction prohibited without permission.
Cell size
Figure 5.5: Geographic Visiting-pattem to Emulate TTDD
by ensuring that after-meeting subscription packets can finally reach all matched sources
whose publication packets have reached overlapping nodes. Another benefit of allowing
overlapping grids is to aggregate the after-meeting traffic and thus to save transmission
energy.
For Rumor-routing, XVR emulates it by using “probable-forwarding” as visiting-
pattems for both subscription and publication packets. This specific probable-forwarding
chooses a random neighbor as next hop.
5.4.2 New Routing Services
As mentioned in Section 5.3, new routing services can be obtained in two directions with
XVR. First, new routing algorithms can be obtained by using visiting-pattems different
from existing algorithms. Different visiting-pattems can be tested to find out best ones
75
Reproduced with permission of the copyright owner. Further reproduction prohibited without permission.
for certain applications or networks. For example, probable and geographic visiting-
pattems are good candidates for resource-discovery oriented applications. Although these
visiting-pattems alone cannot ensure all sinks to find routes to every source, they involve
less routing overhead than flooding visiting pattern. Even for applications that need to
obtain sensor readings from all sources, flooding is not the only choice that can be made
with the implemented XVR. For example, publication packets can take restricted-flooding
visiting-pattem, while subscription packets can take some geographic visiting-pattem. By
choosing a proper TTL value for restricted-flooding pattern and a proper step-angle and
a line number for curve parameters, XVR can ensure that at least one sink subscription
reaches each matched source. Another category of applications include mobile sinks or
sources. These applications can be supported by XVR via limiting the scope of control
packets and increasing frequency of control packets. Softstate left by these control packets
are automatically updated more frequently in this way.
The second direction for new routing algorithms is to use XVR as a building base and
to allow other entities to change visiting-pattems. This direction provides a new approach
to realize concurrent routing and automatic routing. Concurrent routing is needed when
multiple applications with different QoS requirements are supported or in the context
of heterogeneous sensor networks. A single XVR service can be deployed in a sensor
network, but with different visiting-pattems for different applications or different subnets.
The mapping between visiting-pattems and application/network properties can be built
statically by system administrators, or dynamically by some automatic modules.
There are two categories of automatic routing services that can be built upon XVR.
The first category is to conduct intra-changes in a specific visiting-pattem. For example,
76
Reproduced with permission of the copyright owner. Further reproduction prohibited without permission.
Code Size Code Ratio
The XVR Service (5 han
dlers)
52606 bytes 1
Average size of packet
handlers of XVR
10521 bytes 0.20
Selecting function for
emulated GPSR
2756 bytes 0.05
Selecting function for
emulated TBF
2821 bytes 0.05
Table 5.4: Code Size and Ratio
the TTL values of restricted-flooding patterns can be learned by sinks and sources from
previous runs, and the probabilities or curve parameters of geographic visiting-pattems
can be adjusted according to collected statistical information. The second category is
to conduct inter-changes among different visiting-pattems. This category of changes in
volve more routing behavior adaptations and may need state information other than that
collected via passing routing packets. Section 5.5 will use XVR to show results of an
intra-change algorithm that adjusts the TTL values of restricted-flooding patterns. An
inter-change service will be described in the next chapter.
5.5 Evaluations
We have completed the XVR implementation in ns-2 [76]. This section presents perfor
mance evaluations of this implementation. Both code size and communication-related
metrics are shown.
77
Reproduced with permission of the copyright owner. Further reproduction prohibited without permission.
5.5.1 Code Size of the XVR
Table 5.4 lists sizes of the compiled XVR implementation. Note that the size for each
packet handler also counts the code of the corresponding dynamic visiting-pattem. Table
5.4 shows a hierarchical relationship among different components of the XVR service.
For example, if size of the whole service is 1, then the average size of packet handlers
only accounts for one fifth part of the service, while each visiting pattern component only
accounts for one twentieth of the entire service. This hierarchy suggests that the amortized
cost of changing routing in XVR is low.
5.5.2 Communication Metrics and Methodology
In this section, we first describe simulation metrics and methodology, then compare dif
ferent versions of Directed-diffusion with corresponding XVRs, and finally explore the
performance of some new routing algorithms obtained from XVR. We choose Directed-
diffusion schemes for comparison because XVR implementation and Directed-diffusion
share the attribute-based naming scheme and take the same packet format.
These simulations use an energy model under MAC 802.11 provided by ns-2; a sensor
node’s sending, receiving, and idling power consumption rates are 0.66W, 0.395W, and
0.035W respectively. Note that the idle power is not calculated into energy consumption
of the XVR since it is not related to routing overhead.
The communication performance of XVR is evaluated under three metrics: dissipated
energy, delay, and delivery ratio. The dissipated energy measures the ratio of total dissi
pated energy in a network to the number of data packets received by sinks. This metric
computes the average work done by a network in delivering useful data to sinks. The
78
Reproduced with permission of the copyright owner. Further reproduction prohibited without permission.
delay measures the average latency between the moment of originating a data packet and
the moment of receiving that packet. This metric indicates freshness of data packets. The
delivery ratio measures the average ratio of the number of data packets received to the
number of data packets originated. This metric shows the effectiveness of data delivery.
We consider a network scenario that is a randomly generated sensor network com
posed of 100 nodes in a 1500m x 1500m field that does not contain partitions. In this net
work, random but certain numbers of nodes are chosen as sources and sinks. The source
and sink numbers can be chosen as 1, 3, or 6 to expose the impact of different numbers
of sources and sinks. Five combinations of source and sink numbers are tested in the
simulations: 1 source 1 sink, 3 sources 3 sinks, 3 sources 6 sinks, 6 sources 3 sinks, and
6 sources 6 sinks. Each source sends one data packet every two seconds. Each simulation
lasts 200 seconds. The sizes of both publication and subscription packets are 88 bytes,
the size of enforcement packets is 104 bytes, and the size of data packets is 106 bytes.
Hello packets have different sizes; their size is 36 bytes in case of probable-forwarding
visiting-pattems, and 60 bytes if geographic-forwarding is used. The intervals for sub
scription, publication, and hello packets are set as 30, 60, and 80 seconds respectively for
all compared algorithms. Each metric is obtained by averaging over 100 simulations.
5.5.3 The XVR vs. Directed-diffusions
Figure 5.6 shows performance comparisons between emulating XVR and 2pp-Diffiision.
X-axis shows different combinations of source and sink numbers. The configuration of
the XVR (Table 5.3) produces virtually the same visiting-pattems as 2pp-Diffusion. Their
performance metrics are comparable. The dissipated energy by emulating XVR is slightly
79
Reproduced with permission of the copyright owner. Further reproduction prohibited without permission.
w
1 3
0.6
0.4
0.2
3x6 6x3 6x6 lx l 3x3
Source x Sink
XVR Diffusion
(a) dissipated energy
o.i
.08
0.06
0.04
0.02
0
lx l 3x3 3x6 6x3 6x6
Source x Sink
XVR Diffusion
o i
(b) delay
3x6
Source x Sink
XVR Diffusion
(c) delivery ratio
Figure 5.6: The XVR vs. Two-phase-pull Directed-diffusion
Reproduced with permission of the copyright owner. Further reproduction prohibited without permission.
higher than 2pp-Diffusion when source numbers increase because the publication packets
in XVR have an additional identifying attribute compared with normal data packets.
Figure 5.7 shows performance comparisons between emulating XVR and push-Diffusion.
Both cases of XVRs with and without packet state are shown in these figures. When XVR
takes the same visiting pattern as push-Diffusion and does not build packet state, their per
formance metrics are similar to each other with slightly additional energy consumption
for the XVR. When XVR builds packet state with the same visiting-pattem, previous
publications are kept. Without keeping the packet state, sinks can only respond to those
publications issued after they subscribe; previous matched source data are thus missed
until those sources issue publication packets again in their next intervals. Figure 5.7 con
firms the improvement of delivery ratio by keeping the packet state. The routing overhead
with packet state is a little higher than without packet state because additional enforce
ment packets are sent for previously matched sources. Note that keeping packet state
in the 2pp-diffusion emulation does not help since the subscription packets are flooded
anyway.
Figure 5.8 shows performance comparisons between lpp-diffusion and emulating
XVR. Note that available state is not built in a network when emulating lpp-diffusion
since publication packets never leave source nodes. These two algorithms turn out to
perform very differently due to their difference in enforcement and data packets (as de
scribed in Section 5.4). The energy consumption and delay of lpp-diffusion appear to
be less than emulating XVR in the test cases, but its energy consumption increases with
the number of sinks because its data packet size increases with the number of sinks. The
delivery ratios of lpp-diffusion become very low when sink numbers increase due to the
81
Reproduced with permission of the copyright owner. Further reproduction prohibited without permission.
0.8
0.6
0.4
0.2
0
lx l 3x3 3x6 6x3 6x6
Source x Sink
XVR with Packet State —
XVR without Packet State - -
Diffusion ...
(a) dissipated energy
o.i
.08
0.06
0.04
0.02
0
lx l 3x3 3x6 6x3 6x6
Source x Sink
XVR with Packet State
XVR without Packet State
Diffusion
o £ .
(b) delay
i
0.9
0.8
0.7
0.6
0.5
0.4
0.3
0.2
0.1
lx l 3x3 3x6 6x3 6x6
Source x Sink
XVR with Packet State
XVR without Packet State
Diffusion
(c) delivery ratio
Figure 5.7: The XVR vs. Push Directed-diffusion
Reproduced with permission of the copyright owner. Further reproduction prohibited without permission.
w
-a
0.6
0.4
0.2
lx l 3x3 3x6 6x3 6x6
Source x Sink
XVR Diffusion — «
(a) dissipated energy
o.i
0.08
0.06
0.04
0.02
0
lx l 6x3 3x3 3x6 6x6
Source x Sink
XVR Diffusion
04
£ ■
(b) delay
0.9
0.7
0.6
0.5
0.4
0.3
0.2
lx l 3x3 3x6 6x3 6x6
Source x Sink
XVR Diffusion
(c) delivery ratio
Figure 5.8: The XVR vs. One-phase-pull Directed-diffusion
Reproduced with permission of the copyright owner. Further reproduction prohibited without permission.
increasing collisions among larger data packets. With emulating XVR, the energy con
sumption is shown to be scalable with the numbers of sinks and sources because the data
packet size in XVR is kept the same, and delivery ratios are much higher (up to 70%) due
to less collisions.
5.5.4 Exploring New Routing Services
This subsection explores the effect of other visiting-pattems of XVR. First flooding and
restricted-flooding visiting-pattems are tested. Then probable and geographic visiting-
pattems are experimented.
Figure 5.9 compares the 2pp-diffusion with two versions of the XVR; one is that
both sources and sinks flood control packets, and the other is that both sources and sinks
restrictedly flood control packets. The purpose of this set of simulations is to explore the
XVR’s performance under the condition of ensured delivery ratios. The push-diffusion is
not compared partly because it does not ensure delivery ratios as 2pp-diffusion, and partly
because its control packet interval is larger than those in other algorithms.
In both-flooding versions of XVR, the optimization described in Section 5.3 can be
used since publication packets are flooded. In this case, subscription packets only need to
flood before meeting nodes with matched available state. Thus the energy consumption
from subscription packets is reduced significantly (from 30% to 75%). The delay is re
duced as well because of less interference among control packets. At the same time, its
delivery ratios remain comparable to 2pp-diffusion.
Figure 5.9 also shows the performance for a both-restricted-flooding version of XVR.
In this case, sources and sinks are equipped with TTL values obtained by emulating an
84
Reproduced with permission of the copyright owner. Further reproduction prohibited without permission.
Q
T 3
w
1
0.8
0.6
0.4
0.2
0
3x3 3x6 6x3 6x6 lx l
Source x Sink
Diffusion
XVR with Both Flooding
XVR with Both R-flooding
(a) dissipated energy
0.06
0.04
0.02
3x3 3x6 6x3 6x6 lx l
Source x Sink
Diffusion
XVR with Both Flooding
XVR with Both R-flooding
(b) delay
B i
3x6
Source x Sink
Diffusion
XVR with Both Flooding
XVR with Both R-flooding
(c) delivery ratio
Figure 5.9: The XVR with Both Flooding and XVR with Both Restricted-flooding
Reproduced with permission of the copyright owner. Further reproduction prohibited without permission.
intra-change visiting-pattem algorithm. In this algorithm, first rough distances between a
source(sink) and all other sinks(sources) are estimated to get initial TTL values (which are
half of the estimated values). Then these initial TTL value are adjusted to make sure every
sink(source) can send to(receive from) the source(sink). All the adjusted TTL values are
then used for simulations. The obtained TTL values for this set of simulations range from
2 to 7. As shown in Figure 5.9, the energy consumption becomes stable among all sets of
source/sink numbers (below 0.2 joules in most cases), and is significantly lower than both
2pp-diffusion and both-flooding version of XVR. The delay is also reduced significantly.
This performance improvement is due to subscriptions and publications are only flooded
half way between them. Upon a meeting, a subscription packet is stopped and publication
packets are forwarded only among limited neighbors. This set of simulations justify the
feasibility of the adaptive algorithm.
Figure 5.10 and Figure 5.11 show performance metrics when delivery ratio is not the
main concern of applications. Figure 5.10 shows a set of simulations with probable-
forwarding visiting patterns. In these simulations, sources randomly choose 50% of
neighbors as next hops to forward publication packets, while sinks uses restricted-flooding
with a TTL of 5 to issue subscriptions. The TTL values for source probable-forwarding
are set as 5 and 6 respectively. These XVR versions are applicable where sources are
actively involved to determine how many data packets can be obtained by sinks. Com
paring with the both-flooding version of XVR, the probable-forwarding visiting-pattems
save energy significantly because only a subset of neighbors are chosen. Figure 5.10 also
shows the effect of changing TTL values of probable-forwarding. The lower the value,
the less chance for data packets to reach sinks. The energy consumption with TTL of 5 is
86
Reproduced with permission of the copyright owner. Further reproduction prohibited without permission.
0.8
0.6
0.4
0.2
0
6x3 lx l 3x3 3x6 6x6
Source x Sink
XVR with Both Flooding — ' —
XVR Prob with TTL = 6 «
XVR Prob with TTL = 5 -
(a) dissipated energy
0.08
0.06
0.04
0.02
6x3 6x6 lx l 3x3 3x6
Source x Sink
XVR with Both Flooding — 1 —
XVR Prob with TTL = 6 —
XVR Prob with TTL = 5
(b) delay
b
3x6
Source x Sink
XVR with Both Flooding
XVR Prob with TTL = 6
XVR Prob with TTL = 5
(c) delivery ratio
Figure 5.10: The XVR with Probable Visiting-pattems
87
Reproduced with permission of the copyright owner. Further reproduction prohibited without permission.
significantly lower than the case with TTL of 6. But the delivery ratios are much lower.
The case with TTL of 6 shows that the delivery ratios of probable-forwarding may be
improved significantly with an adequate TTL value.
Figure 5.11 shows a set of simulations with geographic-forwarding visiting-pattems.
In these simulations, sources restrictedly flood publication packets with TTL of 5, while
sinks send subscription in 4 straight lines along certain angle with TTL of 6. Two starting-
angles, 0 degree and 45 degree, are used, and step-angles are 90 degrees. These versions
of XVR can be used in resource-discovery oriented applications. As shown in Figure
5.11, geographic visiting patterns perform well for resource-discovery purposes; energy
consumption is less than the probable visiting-pattems. Figure 5.11 also shows differ
ent geographic visiting-pattems can perform very differently; the version with start-angle
of 0 degree discovers much more sources than the version of 45 degree with compara
ble energy consumption and delay. This suggests a need to adapt the search angles with
geographic-forwarding visiting-pattems. Another possibility is to have sources send sub
scriptions along certain directions with higher probabilities.
5.6 Related Work
XVR is different from existing routing services by enabling any visiting-pattems of pack
ets to be specified. This section discusses only most-related works. We first compare
XVR with other routing services, then compare the programmable aspect of XVR with
other representative programmable architectures.
88
Reproduced with permission of the copyright owner. Further reproduction prohibited without permission.
0.8
0.6
0.4
0.2
0
3x3 3x6 6x3 6x6 lx l
Source x Sink
XVR with Both Flooding
XVR Geo with Start-angle = 0
XVR Geo with Start-angle = 45
(a) dissipated energy
0.08
0.06
0.04
0.02
3x3 3x6 6x3 6x6 lx l
Source x Sink
XVR with Both Flooding
XVR Geo with Start-angle = 0
XVR Geo with Start-angle = 45
C 4
(b) delay
i
0.9
0.8
0.7
0.6
0.5
0.4
0.3
0.2
0.1
lx l 3x3 3x6 6x3 6x6
Source x Sink
XVR with Both Flooding
XVR Geo with Start-angle = 0
XVR Geo with Start-angle = 45
(c) delivery ratio
Figure 5.11: The XVR with Geographic Visiting-pattems
89
Reproduced with permission of the copyright owner. Further reproduction prohibited without permission.
5.6.1 Related Routing Services
TBF (Trajectory-based Forwarding [54] and [55]) proposes to use trajectories to direct
packets in networks. Current implementation of XVR makes use of a simplified version
of TBF for geographic-forwarding visiting-pattems that are able to represent a large set of
trajectory patterns (as shown in Section 5.4 and Section 5.5). Since TBF has potential ap
plications for broadcast and resource discovery [55], the corresponding curve parameters
can be added into the XVR implementation to enrich geographic-forwarding patterns.
To the best of our knowledge, Directed-diffusion ([39] and [33]) is the first publication
and subscription based routing service in sensor networks. The XVR implementation
is heavily influenced by Directed-diffusion. For example, enforcement packets in the
implemented XVR are a generalization of reinforcement messages in Directed-diffusion
in the sense that they can also be issued from sources to build routes. A fundamental
difference between the XVR implementation and Directed-diffusion is that XVR enables
control packets to meet with each other in a network, while Directed-diffusion does not
provide such rendezvous approaches; either publication or subscription packets need to
be kept local. The implemented XVR provides a systematic method to explore the effect
of various rendezvous approaches on routing and application performance.
Rendezvous approaches to disseminate data were first described in the context of
wired multicast protocols such as P1M-SM [14]. Unlike this prior work, placement of
rendezvous nodes and packet visiting-pattems are important to ensure energy-efficient
routing in sensor networks.
GHT (Geographic Hash Table [65]) is another rendezvous approach to disseminate
data in sensor networks. GHT is also data-centric; a set of requested attributes is mapped
90
Reproduced with permission of the copyright owner. Further reproduction prohibited without permission.
to a geographic location. Data dissemination with GHT is completed by two separate
steps; sources send data to mapped location according to data attributes via GPSR (put()
operations of the hash table), and sinks issue queries that include requested attributes and
are directed to the same location via GPSR (get() operations of the hash table). Thus the
mapped locations are rendezvous points in GHT. This rendezvous approach can be ac
commodated with programmable-forwarding components similar to GPSR in XVR im
plementation. The implemented XVR is more publication/subscription-oriented in which
sources and sinks work more collaboratively to finish data dissemination, while in GHT
sources and sinks work independently from one another. Current XVR implementation
may be more suitable to applications where continuous and sequential data flows are re
quired, while GHT may be suitable to occasional and transient query tasks.
5.6.2 Related Programmable Architectures
XVR provides a programmable architecture specific to routing services in sensor net
works. The main distinction of the XVR architecture is to identify visiting-pattems as
programmable units. Programmable components in the XVR architecture are realized
by implementing specific selecting functions. This programmable specification is unique
and is efficient to conduct routing changes with small energy cost.
Diffusion filter architecture ([31] and [32]) is a software structure that accommodates
a list of filters, each of which specifies a set of attributes. A packet entering a node triggers
a filter to execute if the filter’s attributes match the attributes of the packet. This filter
architecture provides a flexible way to add application-specific code into sensor nodes
that mn in a network and assist directed-diffusion and data processing [68], The key
91
Reproduced with permission of the copyright owner. Further reproduction prohibited without permission.
supporting mechanism in this filter architecture is the matching scheme [31]. Compared
with XVR that is specific to routing, this filter architecture is more application-oriented.
XVR changes routing by changing visiting-pattems, which are more fine-grained than
packet filters. The programmable components in XVR are visiting-pattems, not packet
filters. The visiting-pattem components are implemented by selecting functions for next
hops. The selecting functions do not concern about packet attributes and matching, thus
do not correspond to any filters. The filter matching mechanism is not needed in XVR.
Filter-based architecture is an efficient programming model to add application-specific in-
network processing code, while XVR provides an energy-efficient way to conduct specific
routing changes.
Mate is a programmable interface for a virtual machine built on top of TinyOS [44].
A small instruction set is provided by the virtual machine that abstracts some high-level
functions. Services constructed via Mate are expected to have small size and can be
loaded in a memory-and-energy-saving manner. Compared with Mate, XVR is not a
general architecture that attempts to accommodate all services. Instead, XVR is a specific
architecture to reduce cost of routing changes. One can imagine to realize the XVR
paradigm on top of Mate so that XVR can make use of the concise instruction set to
reduce size of routing services.
Sensorware ([5] and [4]) is another programmable environment that provides a virtual
machine. But Sensorware targets to support a specific kind of application called localized
distributed computation such as a collaborative signal processing task. Since the aim of
XVR is routing services, the XVR architecture is orthogonal to Sensorware.
92
Reproduced with permission of the copyright owner. Further reproduction prohibited without permission.
Impala [48] is a middleware architecture to support service adaptation in the Zebra Net
[47]. When certain situation-changing patterns are detected, entire service is replaced.
The XVR architecture supports fine-grained routing changes; only visiting-pattem pa
rameters or components need to be replaced. The XVR architecture does not involve the
issue of how to detect the need for a change, which will be discussed in the next chapter.
5.7 Summary
XVR is a general routing service for sensor networks that allows arbitrary visiting-pattems
to be specified independently from the routing core. With parameterizations on visiting-
pattems, XVR enables significant routing changes with low energy cost. Further, XVR
provides a unified and comprehensive environment to study the effects of various visiting-
pattems on routing and application performance. In the next chapter, an automatic routing
service will be shown to conduct visiting-pattem changes on top of the XVR.
93
Reproduced with permission of the copyright owner. Further reproduction prohibited without permission.
Chapter 6
Automatic Visiting-pattern Routing
This chapter describes an approach to automatically choose and change visiting-pattem
parameters, and the resulting service is called AVR (Automatic Visiting-pattem Routing).
In AVR, a separate adapter module is introduced, on top of XVR, to make routing deci
sions and enforce chosen visiting-pattems. The adapter module takes two steps to adapt
routing visiting-pattems to a given application in a sensor network. First, a properties-
based function, which defines a set of selection policies according to application and
network properties, is used to choose an initial visiting-pattem. Then a feedback-based
scheme is applied to refine or change the chosen visiting-pattem. This feedback-based
scheme contains a general model that estimates routing and data transmission cost. This
general model provides a quantitative means to evaluate different visiting-pattems and
forms a basis for making visiting-pattem decisions.
AVR explores collaborations among sensor nodes to evaluate, decide, and enforce
visiting-pattems. Different types of collaborations are discussed for the purpose of sav
ing energy and meeting application requirements. These collaborations shed insight on a
94
Reproduced with permission of the copyright owner. Further reproduction prohibited without permission.
novel approach to support applications in sensor networks. As an example, this disserta
tion describes how to conduct automatic changes between two known visiting-pattems,
pull and push, without introducing any additional cost. In this automatic service, a suite of
protocols are proposed to enable different sinks/sources to collaborate with one another,
in order to obtain least overall routing cost, to make non-conflicting visiting-pattem de
cisions, to avoid premature flooding of control packets, and to ensure smooth transitions
when enforcing chosen visiting-pattems. Further, this automatic service maintains mini
mum state information and thus is highly scalable.
In this chapter, we first present the architecture of AVR and describe approaches to
change and enforce visiting-pattems. Then AVR service is presented that applies the
collaborative feedback-based scheme to change visiting-pattems between pull and push.
6.1 Architecture
To support automatic decisions of visiting-pattems, an adapter module is introduced to
work on top of XVR [25], as shown in Figure 6.1. The architecture is an instantiation of
proposed autonomic routing framework for sensor networks [29].
All packets from/to the routing core must go through the adapter module so that it
can collect state information from passing-by packets and can manipulate them (such as
marking them or piggybacking some information). The adapter can also issue its own
packets to collect information or indicate routing changes. The adapter makes change
decisions about visiting-pattems based on its own state and/or routing state. The network
I/O module is used to conduct all network I/O operations for the adapter module. It also
95
Reproduced with permission of the copyright owner. Further reproduction prohibited without permission.
Network I/O
Handler 1
VP 1
Handler 2
VP 2
Adapter
Handler n
VP n
State
State
XVR
Figure 6.1: Architecture of the Autonomic Visiting-pattem Routing (AVR)
serves to detect and eliminate duplicating packets by checking random id and sequence
number of each packet.
The goal of AVR is to choose among supported visiting-pattems in the XVR so that
application requirements can be met with reduced energy consumption in a dynamic sen
sor network. The approach AVR takes is to first choose an initial visiting-pattem by
considering application and network properties, and then refine or change the chosen
visiting-pattem according to obtained feedback information about routing and data deliv
ery. The rest of this section describes these two steps in detail.
96
Reproduced with permission of the copyright owner. Further reproduction prohibited without permission.
6.1.1 Properties-based Visiting-pattern Selection
AVR uses base stations in a sensor network to carry out properties-based visiting-pattem
selection because a base station is both a starting point to deploy an application and an
administration point for a sensor network. Base stations also have enough computing
and energy power to reason about application and network properties. There is a built-in
selection policy function in adapter modules of base stations to choose among different
visiting-pattems. This selection step is justified by static natures of many application and
network properties.
The current property space in AVR is described below. Note that this space will be
enriched as more understanding for sensor networks and their applications is developed.
In application side, first sink mobility indicates if sinks are roaming in a sensor network;
static sinks often favor different routing algorithms than mobile sinks. Second, delivery
ratio indicates the ratio of found sources to all existing sources. This property gives
important hints for desirable visiting-pattems; different ratio requirements can be met
with different visiting-pattems. Third, data delay indicates how long an application can
wait for arrival of data after requesting data. Short delays may need more active visiting-
pattems than long delay. Fourth, data rate indicates interval between two consecutive data
units. On the one hand, data rate requirement has important implications to the control
interval of routing packets. For example, low data rate does not suggest the need to
frequently issue control packets. On the other hand, if an application asks for a high data
rate, it may be necessary to carry out multiple-path routing to speed up data transmission.
Fifth, reliable delivery indicates if an application needs reliable data. To realize reliable
delivery, it may be necessary to build routes that consist of only good links.
97
Reproduced with permission of the copyright owner. Further reproduction prohibited without permission.
The network property space currently includes whether a network has location knowl
edge or not, network density, and mobility of sensor nodes. The location knowledge de
termines if geographical patterns can be applicable. The density property can determine
if probable patterns are applicable, and can help estimate routing cost and effectiveness.
The mobility property can help determine the refreshing intervals of routing state.
Based on properties discussed above, multiple selection policies can be built for the
adapter module. The following is a sample policy function to choose visiting-pattems
using some of the above properties:
If the delivery ratio requirement is high
use the pull visiting-pattern
Otherwise
if the network is dense
use probable visiting-pattern
if the location knowledge is available
use geographical visiting-pattern
if neither location-aware nor dense
use restricted-flooding pattern
The pull visiting-pattem can ensure high delivery ratio because of its flooding nature.
When the delivery ratio requirement of an application is not high, there can be multiple
visiting-pattem choices to explore a sensor network depending on network properties.
When neither location knowledge is available, nor a network is dense, the sample function
chooses restricted-flooding as an initial visiting-pattem.
98
Reproduced with permission of the copyright owner. Further reproduction prohibited without permission.
Note that while many application and network properties are static, some of the prop
erties are dynamic. For example, sink and source numbers/locations can keep changing
during the lifetime of an application. Other examples include network topology and den
sity. AVR uses a feedback-based scheme to detect such dynamics and makes visiting-
pattem changing decisions, which will be discussed in the next subsection.
6.1.2 Feedback-based Visiting-pattern Changes
After an initial visiting-pattem is chosen via the properties-based approach, the adapter
modules in sinks and sources use a feedback-based scheme to check if application re
quirements are met or if energy consumption can be reduced. When detecting a need to
change visiting-pattem, the adapter modules indicate and enforce such changes.
One key element in the feedback-based approach is a general model to estimate the
routing cost with current visiting-pattem and data transmission cost as the result of current
routing. This general model makes use of existing routing packets to estimate the cost,
adds the minimal packet overhead to routing, and requires only lightweight computations
in the network. In this model, the cost is mainly determined by path lengths of routing
and data packets (since packet sizes are known). In XVR, routing traffic consists of
subscription packets, publication packets, and enforcement packets. Data traffic consists
of data packets. The following estimation protocol uses sinks-active XVR algorithms as
an example to simplify the description.
In sinks-active case, a sink estimates the cost of its subscription packets, the cost of
enforcement packets that are sent to it, and the cost of data packets it receives; while
a source estimates the cost of its publication packets. Sinks and sources can estimate
99
Reproduced with permission of the copyright owner. Further reproduction prohibited without permission.
the cost of their control packets (subscriptions and publications) conveniently since they
know the visiting-pattems of those packets. For example, by knowing the TTL value of
the probable visiting-pattem, the cost of control packets can be obtained. For geograph
ical visiting-pattems, the cost can be computed by sinks and sources since they know
the curve parameters. For the flooding visiting-pattem, the cost can be estimated as the
number of sensor nodes in a network since a flooding can be modeled as sending a packet
along a path to reach all nodes. In the case of restricted flooding, the cost can be roughly
estimated if the diameter of network is known. To estimate the cost of enforcement pack
ets, the adapter modules in source nodes add a hop-number field, called source-to-sink
hop number, into the generated enforcement packets. As the name suggests, the hop-
number fields keep the hop numbers of enforcement packets from sources to sinks. Sinks
obtain the cost of enforcement packets by checking the hop-number fields. Data trans
mission cost can be obtained by checking the hop-number fields of enforcement packets
and observing data arrival rates at sinks.
With this general model, AVR can detect application and network dynamics by moni
toring routing and data delivery cost with current visiting-pattems. A significant increase
in the cost is often an indication of sink/source or topology changes and suggests a need
for adjusting the existing visiting-pattem. Section 6.2 will show an example service that
uses the general estimation model to guide visiting-pattem changes.
Further, this feedback-based scheme explores collaborations among sensor nodes to
evaluate the effectiveness of routing control packets and to make visiting-pattem deci
sions. For example, when a subscription packet meets with a matched available state,
an adapter module can add a hop-number field, called matching-to-source hop number,
100
Reproduced with permission of the copyright owner. Further reproduction prohibited without permission.
into the after-meeting copy of a subscription packet. Incremented when passing toward
sources, the hop-number field keeps the path length between a meeting node to sources.
When a source node receives all these after-meeting packets, it will know the effective
ness of its publication packets by checking the hop-number fields of these packets. For
example, the largest hop-number can be used as a guideline to adjust the TTL values
of its next subscription packets. The hop-number field can also be copied to the corre
sponding enforcement packet issued by a source. This way, when an enforcement packet
reaches one sink, the sink can also know the effectiveness of its subscription packets by
subtracting the matching-to-source hop number from the source-to-sink one. In this ex
ample, sinks and sources collaborate with intermediate nodes to evaluate and adjust their
visiting-pattems.
Sometimes collaborations make it possible and beneficial to change visiting-pattems
among different categories. For example, for a high delivery ratio application, both pull
and push will work because of the flooding nature of these two visiting-pattems. However,
the overall energy consumption of pull and push can be very different when numbers
of sinks and sources change during the lifetime of an application. It will be energy-
efficient to change the visiting-pattem to the least-cost one when detecting a performance
difference. Section 6.2 will present a detailed approach to realize this automatic visiting-
pattem change in which all sinks or sources collaborate to estimate the overall cost, and
to make and enforce a visiting-pattem decision.
As another example, consider an application that does not need high data-delivery ra
tio in a sensor network that is both location-aware and dense. According to the sample
selection function discussed in the previous section, both the geographical and probable
101
Reproduced with permission of the copyright owner. Further reproduction prohibited without permission.
00 00
o N ode 3
•• o
N ode 2 0 N o d e 2 0
Step 1 Step 2
source node oo
0 o N o d e 3
0 N o d e 2 o
sink node
other node
Step 3
Figure 6.2: Collaborative Visiting-pattem Example
visiting-pattems can be used for sinks while assuming sources use a default restricted-
flooding visiting-pattem. One research question is to choose an adequate visiting-pattem
for sinks. To answer this question, we first compare probable visiting-pattems with ge
ographical visiting-pattems. The main property of a geographical visiting-pattem is de
terministic; the exploring field of a geographical curve is determined by its curve pa
rameters. On the contrary, the main property of a probable visiting-pattem is that it is
non-deterministic; a probable visiting-pattem can lead to any curve. Thus the exploring
power of a probable visiting-pattem is strong in a dense network, while a geographical
visiting-pattem is most likely to obtain anticipated routes. With this observation, sinks
can first use a probable visiting-pattem, and then try geographical patterns if the probable
visiting-pattem is not successful. The advantage of this approach is that when multiple
102
Reproduced with permission of the copyright owner. Further reproduction prohibited without permission.
sinks are exploring a sensor network at the same time, they can make use of each other to
quickly find a source. As shown in Figure 6.2, Node 1 and Node 2 use a geographical line
to find sources after unsuccessful probable visiting-pattems. The routing state built from
the sources to Node 1 and Node 2 increases the chance to successfully find sources for
subsequent sinks. The probable visiting-pattem by subsequent nodes (Node 3 in Figure
6.2) is more likely to succeed. Of course, the visiting-pattem of Node 3 can be changed to
geographical visiting-pattem to reduce the path length after obtaining locations of sources
(say, via piggybacking a source location on an enforcement packet).
In summary, this general model provides a lightweight approach to estimate rout
ing and data transmission cost. The collaborative aspect of this feedback-based scheme
sheds lights on a novel way to support sensor network applications where sensor nodes
coordinate with each other and choose suitable visiting-pattems to save energy and meet
application requirements.
6.1.3 Enforcing Chosen Visiting-pattern
AVR assumes that there is only one application running at any given time in a sensor
network. For each application that can run in the network, a designated base station
chooses an initial visiting-pattem using the properties-based approach and floods the de
cision to all nodes in that network. Then sinks and sources dynamically decide if they
need to change visiting-pattem for their control packets using the feedback-based ap
proach. Each sink/source needs not take the same visiting-pattem parameters as other
sinks/sources since they may obtain different feedback information and make different
103
Reproduced with permission of the copyright owner. Further reproduction prohibited without permission.
decisions. For example, different sources may find different TTL values for their re
stricted visiting-pattem parameters because of the difference in their physical positions in
a network. Another example is that different sinks may take different geographical curves
or probabilities to find matched sources. It is even possible that multiple categories of
visiting-pattems exist at the same time (for example, as the result of collaborative ap
proaches described in the previous section).
Sinks and sources add these visiting-pattem decisions into their routing control pack
ets to enforce their choices throughout a network. For example, probable visiting-pattems
are distinguished by a probable attribute, geographical visiting-pattems are recognized
by a geographical attribute, restricted-flooding is distinguished by a TTL attribute, and
flooding visiting-pattems are recognized by no specific attribute. This scheme attempts
to minimize cost to propagate visiting-pattems in a network. Since flooding is the most
expensive visiting-pattem, its propagation does not involve any additional cost. For each
sensor node that receives/forwards these control packets, its adapter module extracts the
specific visiting-pattem attribute from packets, installs/overwrites visiting-pattem param
eters into visiting-pattem modules, and then forwards the rest of packets to routing core
for normal operations.
In this way, for any given application in a sensor network, sinks and sources actively
choose visiting-pattem based on feedback information and a network carries out such
decisions on the fly. As a result, an application requirement is met in an energy-efficient
manner.
104
Reproduced with permission of the copyright owner. Further reproduction prohibited without permission.
Subscription Publication Enforcement Data
Pull-XVR FLOODING LOCAL In-code In-code
Push-XVR LOCAL FLOODING In-code In-code
Table 6.1: Visiting-pattems for Pull and Push routing in the XVR
6.2 Automatic Visiting-pattern Change between Pull and
Push
This section presents a concrete collaborative approach that conducts automatic visiting-
pattem between pull and push.
6.2.1 Overview
Table 6.1 shows visiting-pattem parameters for pull and push routing in XVR. The pull
routing is a service in which sinks flood subscription packets while sources send publica
tion packets only locally. When subscription packets reach sources, enforcement packets
are issued from sources toward sinks to build routes. The push routing is a service in
which sources flood publication packets while sinks send subscription packets only lo
cally. When publication packets reach sinks, enforcement packets are issued from sinks
toward sources to build routes. In pull routing, an enforcement packet takes the reverse
path of a subscription, while in push routing, it takes the reverse path of a publication
packet.
In this automatic service, adapter modules keep monitoring overall routing cost with
current visiting-pattem (either pull or push), compare its cost with the other visiting-
pattem, and change the visiting-pattem if the current visiting-pattem entails more cost.
105
Reproduced with permission of the copyright owner. Further reproduction prohibited without permission.
A suite of protocols are proposed to conduct collaborative evaluation, decision, and en
forcement of the chosen visiting-pattem.
First, we describe assumptions these protocols take. To simplify explanation, we
assume that there is only one routing service, either pull or push, running in a sensor net
work at any given time except when a transition between them happens. In the transition
phase, these two routing services can co-exist temporarily. In addition, we assume that
the control intervals to issue subscriptions/publications are the same for both pull and
push services. Having the same control intervals for pull and push is reasonable because
they all work for the same application under the same network context. To simplify the
computation of routing cost, we further assume that every flooding has the same cost
and a unicast cost in negligible compared with a flooding cost. With this assumption,
the cost of enforcement packets can be regarded zero compared with the cost of flooding
subscriptions or publications. Thus the routing cost of pull can be roughly estimated by
the number of sinks, while the cost of push can be roughly estimated by the number of
sources. This assumption is verified by the results reported in [43],
One key design decision is to make use of existing packets for the XVR both to obtain
routing performance information, and to exchange the routing-changing decisions. The
adapter module does not issue its own packets for state collecting, and manipulates ex
isting packets only by using their marker fields. The marker field is used in the XVR to
mark after-meeting packets [25]. This way, the overhead of changing routing is kept to
the minimum. As another example, AVR makes use of the random ids in packet headers
to obtain source and sink number information. Alternatively, the mac ids of sensor nodes
can be used.
106
Reproduced with permission of the copyright owner. Further reproduction prohibited without permission.
Sink number Source number
Sinks Yes Yes
Other nodes Yes Partially
Table 6.2: Number Info Collectible via Existing Packets in PULL-XVR
Sink number Source number
Sources Yes Yes
Other nodes Partially Yes
Table 6.3: Number Info Collectible via Existing Packets in PUSH-XVR
Different entities in a sensor network have different capabilities to obtain source and
sink number information. Table 6.2 and Table 6.3 lists what number information can be
obtained by each entity via existing-packets in pull-xvr and push-xvr respectively. As
shown in Table 6.2, in pull-xvr, all nodes can obtain the sink number information since
sinks flood subscription through the network. However, only sinks can obtain the source
number by receiving the enforcement packets from sources. Other nodes cannot obtain
the information about the source number unless an enforcement packet passes the nodes.
Thus only sinks have the capability to completely obtain both number information in case
of pull-xvr. Similarly, as shown in Table 6.3, only sources can obtain both the number
information in case of push-xvr.
Based on the above observation, AVR chooses one sink to collect number information
and make routing-change decisions in case of pull-xvr, and chooses one source to collect
the information and make the decisions in case of push-xvr. Once the chosen node makes
a decision to change routing, the routing decision is broadcast to every node via a normal
control packet and the whole network will use the new routing service in which a new
node will be chosen to monitor the numbers and to make decisions.
107
Reproduced with permission of the copyright owner. Further reproduction prohibited without permission.
The algorithms can be divided into several parts. First, a sensor node is dynamically
chosen as the leader to make routing-changing decision. Electing a leader avoids conflict
decisions. Second, at the moment when nodes become sinks or sources, there are cases
that a leader cannot detect them immediately. One protocol is proposed to obtain the
latest number information. Third, before a leader can make a decision, other control
nodes (sinks in case of pull-xvr, and sources in case of push-xvr) may issue flooding
packets prematurely. One algorithm is proposed to avoid this premature flooding. Finally,
the transition phase between two visiting-pattems and the decision-making strategy are
described.
6.2.2 Leader Election and Maintenance
The leader election is done by making use of flooding packets in pull-xvr and push-xvr.
In case of pull-xvr, subscription packets are used to elect and maintain a leader among
sinks. In case of push-xvr, publication packets are used to elect and maintain a leader
among sources. The leader election process can be divided into four subsequent steps;
election preparation, election, maintaining, and re-election.
Each node maintains a leader list, indexed by subscription attributes. Each leader
entry in the list includes a leader id and a timestamp. The leader id is the random id
of a potential leader, and the timestamp keeps the last time heard from the leader. The
following paragraphs uses the pull-xvr case to simplify the description for the election
process. The push case can be reasoned similarly.
When a sink sends out a subscription packet, its adapter module holds the packet
for a while to avoid broadcast collisions among neighbors. The sink enters into election
108
Reproduced with permission of the copyright owner. Further reproduction prohibited without permission.
preparation phase. The holding time is determined by the remaining energy of the sensor
node as shown in the following equation:
HoldingTime(i) = (1 — Ei + R i) x N x T (6.1)
E{ is the ratio of the remaining energy of Node i, and Ri is a random number between
0 and 1. T is the round trip time for a small packet over a wireless link. N is a rough
estimate of the average neighbor numbers in a network. Equation (6.1) is borrowed from
the calculation in SPAN [11]. This computation increases the chance to first time out and
then become a leader for a sensor node that has the most remaining energy. AVR chooses
a leader among energy-rich nodes because the leader is likely to receive more packets
than other sinks, as shown in Section 6.2.3.
During holding time, if a sink receives a leader claim message, then its leader entry
is filled. If there are multiple leader claim messages received during a holding time, the
one that comes from a sink with the minimum random id is used to fill the leader entry.
After that holding time, a sink checks if its leader entry has been filled. If so, the sink then
sends out the held message as a normal subscription packet, knowing that some other sink
will take the leadership. If the leader id is still not filled, then that sink marks the held
packet as a leader claim message, sends it out, and officially takes part in the election.
Nodes other than sinks do not take part in an election, but actively obtain the election
results by receiving leader claim messages. All nodes begin to involve in an election
by starting off an election timer. For sinks, timers are started immediately after they
send their subscription packets; for other nodes, timers are started immediately after they
109
Reproduced with permission of the copyright owner. Further reproduction prohibited without permission.
receive the first subscription packet. The timeout value of an election timer is determined
by the following equation:
ElectionTime = 2 x T j (6.2)
Th is the time needed to broadcast a packet to every node in a sensor network, and
its value largely depend on network diameter. During an ElectionTime, all nodes keep
the minimum random id from all received leader claim messages as the leader id. The
election phase is finished after the election timer expires.
Let Tc(i) be the time when node % issues its control packet (subscription in case of
pull-xvr, and publication in case of push-xvr). Then node i takes part in an election if and
only if it has not received any leader claim message before Tc(i). Every node obtains a
unique leader id after its election phase that is the minimum random id among all electing
nodes.
After an election process, every node has a unique leader information. The leader
sink node maintains its leadership by periodically sending a leader confirmation message.
This message is still marked from subsequent subscription packets to avoid introducing
additional packet overhead. These confirmation messages refresh timestamps and set a
confirmation flag for leader entry in each node. When a leader sink leaves (for example,
because of application termination or because of node failure), leader entries will timeout
and other sinks will start another election to choose a new leader. Another case for re-
election is when leader sink makes a routing-change decision. The decision message is
also sent by marking a subscription message. Since routing service will be changed to
110
Reproduced with permission of the copyright owner. Further reproduction prohibited without permission.
push-xvr, election will be re-done among source nodes. To enable a re-election, each
node clears its leader entry upon receiving a decision message.
6.2.3 Collecting Number Information
There are two options in AVR to collect sink and source numbers. The first option is to
only detect number information during control intervals. With this option, leader entries
in each node only maintain a sink number and a source number. The second option is to
keep more details for sinks and sources. With this option, a leader entry maintains a sink
list and a source list. Each entry of these two lists includes random id of a sink or source
and a timestamp that indicates the last time heard from that node. With the first option,
size of a leader entry does not increase with sink and source numbers, but a leader will
need to make routing change decisions solely based on the number information. With
the second option, size of a leader entry increases with sink and source numbers, but
more information can be used to help make decisions. To simplify the description, rest of
this section assumes the case of pull-xvr unless stated otherwise. A similar reasoning is
applicable to the case of push-xvr.
With the option of only keeping sink and source numbers, every node keeps updating
these numbers until a leader sends a next subscription packet (can be either a leader con
firmation or a decision message). A sink node increments sink number when receiving
a subscription packet, and increments source number when receiving a destined enforce
ment packet that is destined to that sink. Other nodes use the same method to update sink
numbers, but does not update their source numbers since multiple enforcement packets
may come from the same source. This updating phase ends when a leader sends its next
111
Reproduced with permission of the copyright owner. Further reproduction prohibited without permission.
subscription packet. The leader resets the numbers to zero when sending a subscription
packet, and other nodes reset the numbers when receiving a subscription packet. The next
round of updating begins immediately after the resetting.
Initially, the time interval for number updating phase starts from the moment when
the first sink sends out a leader claim message during an election and ends when the
chosen leader sends out its next subscription message. After this phase, the time interval
of number updating is equal to the control interval. When an updating interval value is
equal to the control interval, any one of received subscription packets during that interval
cannot be from the same sink, and any one of the counted enforcement packets cannot
be from the same source. Thus the collected numbers by sinks do not count duplicate
nodes in this case. However, when a leader election is involved in an updating phase,
the updating interval is slightly larger than the control interval and it is possible that a
sink sends subscription packet twice during that updating interval. AVR uses a technique
that will be described in Section 6.2.4 to ensure that all sinks send their next subscription
packets after a leader sink. This way, AVR ensures that no duplicate numbers are counted
during any updating phase.
So far AVR has ensured that every active sink is counted by every node exactly once
during an updating phase. One research problem is how to detect number changes when
a sink/source joins or leaves. When a node becomes a sink, its presence can be detected
immediately by a leader sink node since it will send out a subscription. When a sink
is leaving, it will stop sending subscription packets. Its absence will be detected after
next leader subscription packet. When a source leaves, it will stop sending enforcement
packets. Its absence will be detected after next leader subscription packet. When a node
112
Reproduced with permission of the copyright owner. Further reproduction prohibited without permission.
becomes a source, it will send out an enforcement packet when receiving a subscription
message. Thus, its presence can also be detected by leader sink node after leader sends
next subscription packet.
AVR takes a measure to detect a source immediately after it joins. When a node
becomes a source, it will send a local publication packet. Upon obtaining a publication
packet, the adapter module in a node checks if a leader has been determined. If a leader
has been chosen, the adapter module will send out an enforcement packet toward that
leader sink node. Otherwise, sending of an enforcement packet is delayed until a leader
is determined. This enforcement packet will be processed by the network just as a normal
packet. When it reaches the leader sink node, the leader detects the presence of the new
source. In this way, the leader collects latest number information when a sink or source
joins and can detect left sinks and sources in a while that is no more than a control interval.
In case a leader itself leaves, it will not send next subscription packet, thus counting on
other nodes will not stop and duplicate sinks and sources may be counted. Note that this
miscounting will not bring harm to the operation of AVR since these wrong numbers will
never be used (since the leader has gone). Eventually, leader entries on sensor nodes will
expire and be cleaned. And another round of leader election will begin and the number
counting will back to normal as the result.
For the option of keeping source and sink lists, sensor nodes also keep random ids
and last-heard timestamps from each source and sink. This information may be helpful to
routing-changing decisions, as shown in Section 6.2.6.
113
Reproduced with permission of the copyright owner. Further reproduction prohibited without permission.
6.2.4 Avoiding Premature Flooding
After a leader sink node is chosen, it collects source and sink numbers during its con
trol interval, and makes a decision if there is a need to change routing at the end of that
interval. If the decision is to change routing service, the decision will be sent via a sub
scription packet. As discussed in Section 6.2.3, the number-collecting phase may last a
while larger than the control interval when a leader election is involved. Thus it is possi
ble for some sink nodes to send their second subscription packets before the leader sink
node sends its routing-change decision. The flooding packets from those sinks are un
necessary because routing will be changed to push-xvr in which case sinks do not need
to flood subscription packets. Besides, as discussed in Section 6.2.3, these subscription
packets mislead the number collection process. To avoid this premature flooding, AVR
delays sending the next subscription packets for certain sinks so that all sinks will send
their next subscription packets later than the leader sink node.
Two categories of sinks are chosen to delay their next subscription packets. First, for
those sinks that send their first subscription at the beginning of an election phase, each of
them checks if the scheduled sending time of the packet meets the following equation at
the end of the election phase:
Tp{i) < (Ti(i) + N x T + Tb ) (6.3)
Tp(i) is the scheduled time for first subscription packet of Node i. Note that Tp(i) is
not the actual sending time for the first subscription packet since it is held for a while to
avoid neighbor collision and for the election preparation. T[(i) is the time when a sink
receives the leader claim message.
114
Reproduced with permission of the copyright owner. Further reproduction prohibited without permission.
If a sink meets Equation (6.3), it will delay next subscription packets. The second
category of sinks that need to delay next subscription packets are chosen from those that
send their first subscription packets after the election phase. Each of those sinks verifies
if the leader has been confirmed or not by checking confirmation flags of its leader entry.
If a sink has a confirmed leader entry, it sends its first subscription after the leader sends
the second subscription and thus has no need to delay its next subscriptions. Those sinks
without a set confirmation flag check the Equation (6.3). If the equation can be met, the
sinks delay next subscription packets.
The above two categories of sinks delay their next sending timers by a value deter
mined in the following equation:
BackupTime(i) = (TJ(i) + N x T + T^) — Tp(i) (6.4)
This backup algorithm ensures that all sinks do not send their next subscription pack
ets before receiving next subscription packet from the leader sink node. A similar reason
ing exists for the push case.
6.2.5 Changing Visiting-patterns
When a leader sink node makes a routing change decision, this decision is sent via the
current subscription packet. Upon receiving the decision message, the adapter module
in every node first hands it to the routing core that processes it as a normal subscription
packet, then sends it out, and finally changes the visiting-pattem to push-xvr. Note that
115
Reproduced with permission of the copyright owner. Further reproduction prohibited without permission.
visiting-pattem cannot be changed before sending the decision message out because oth
erwise the decision packet would not come out of the node since its visiting-pattem has
been changed to the local pattern.
A transition phase can be defined to begin at the moment when a leader sink node
sends out the decision message and to end at the moment when the first source broadcasts
its publication packet. During the transition interval, pull-xvr and push-xvr can co-exist
in a network. For all sinks, because of the backup algorithm in Section 6.2.4, they do
not flood their next subscription packets before receiving the decision message. However,
their current subscription packets may still be in the network during a transition phase.
Those subscription packets may reach some sources that will then issue a correspond
ing enforcement packet. Note that processing of these enforcement packets will not be
affected by a routing change since their processing is written into the code of the XVR
service and is consistent between pull-xvr and push-xvr. On the other hand, those sub
scription packets may fail to reach every node since they may pass some nodes that have
changed their visiting-pattems and then do not forward these subscription packets. Those
interrupted subscription packets will not affect proper routing operation of AVR because
those sending sinks will be found by subsequent publication packets in push-xvr.
For those sources that have received a decision message and want to broadcast their
publication packets before that decision message reaches every node, we have the follow
ing observation:
Let node i be any one of those sources and has changed its visiting-pattem to push-xvr
at time T^(z'), and is scheduled to flood its publication packets at Ts(i). Node i first checks
the following equation:
116
Reproduced with permission of the copyright owner. Further reproduction prohibited without permission.
Ts{i) >= (Td(i)+ T b ) (6.5)
If this equation is met, node i sends a publication packet as a normal packet in the
leader election process. Otherwise, node i waits for a while before sending it. The waiting
time is determined by the following equation:
Then a publication packet sent by node i will reach every node in the network.
This algorithm also avoids wasting energy for those otherwise interrupted publication
packets and ensures that the next round of leader election can be done properly. A similar
theorem holds for the push case.
6.2.6 Decision Making
After a leader sink node is chosen, it will check the sink and source numbers at the mo
ment of sending the next subscription. The leader sink node will make a routing-change
decision if the following equation can be met:
N$ource is the collected number for sources, and Nsv n ^ is the number for sinks. Since
a decision is sent via a subscription packet which is flooding through the network, the
leader is also considered as a “source” at this moment in terms of flooding cost. Section
W aitingT ime{i) = (Td{i) + Tb) — Ts(i) (6.6)
( ^ V s o u r c e f 1 ) ^ s i n k s o u r c e
(6.7)
117
Reproduced with permission of the copyright owner. Further reproduction prohibited without permission.
6.3 will use simulations to show the effect of routing thrashing when Equation (6.7) is
met.
If AVR uses the option described in Section 6.2.3 that has its leader entry to keep a
sink list and a source list, a refined decision-making process can be obtained. Instead of
Equation (6.7), the following equation can be used to decide if AVR needs to change the
routing to push-xvr:
' P s o u r c e ^ S ) “ f i d - C s o u r c e ) < C ' P s i n k j 0 “ F C s i n k ) ( 6 . 8 )
Psourcei'1 ) is the probability for source i in the source list by which it will be alive
during the next updating phase. Psink(i) is the probability for sink i in the sink list by
which it will be alive during the next updating phase. Csource is an estimated count of
new sources that will join the group during the next updating phase. Csmk is an estimated
count of new sinks that will join the group during the next updating phase. PS O U rce{i) and
Psink{i) are related to the time during which node i has been alive. Generally, the longer a
node stays, the less likely it will continue to be alive. These probabilities can be obtained
by extensive experiments. C V m /t and Csource can be obtained via a learning algorithm that
makes a predication based on historic data.
Similar decision equations exist for the push case.
6.3 Simulation Results
We have implemented AVR in ns-2 [76], This section presents performance evaluations
on AVR. The main metric of our evaluation is dissipated energy, which measures the ratio
118
Reproduced with permission of the copyright owner. Further reproduction prohibited without permission.
of total dissipated energy in a network to the number of data packets received by sinks.
The network scenario is randomly generated sensor networks composed of 100 nodes in a
1500m x 1500m field that does not contain partitions. In our network scenario, a random
but certain number of nodes are chosen as sources and sinks. Each source sends one data
packet every five seconds. All results are obtained by averaging over 100 simulations.
The interval for issuing the publication and subscription packets is 50 seconds.
We have tested the impact of AVR under different traffic patterns. Each node can
become a source or sink or stop being involved at any time during simulations. To see
the effect of the ratio between source and sink numbers, simulations begin with the same
numbers of sources and sinks during warm-up phase. After this warm-up, the ratios are
changed to some specified patterns that are carefully chosen to be complete.
Three categories of traffic patterns are tested. First, we test the effect of AVR under
a single ratio change. Second, we test the effect of two consecutive ratio changes. The
purpose of this set of tests is to see the performance of AVR under routing thrashing.
Third, multiple ratio changes are tested and compared with long simulation sessions. To
the best of our knowledge, our work is the first to evaluate the routing performance under
different joining and leaving cases in sensor networks.
6.3.1 Single Ratio Changes
Traffic patterns for this set of tests is to first maintain the same numbers of sources and
sinks for a while during the first control interval. Then during the second control interval,
the ratios are changed. Four different cases are designed for and tested. The first two
119
Reproduced with permission of the copyright owner. Further reproduction prohibited without permission.
Dissipated Energy (Joules/Received Data) Dissipated Energy (Joules/Received Data)
0.8
Pull-XVR
Push-XVR
AVR
0 .7
0.6
0 .5
0 .4
0.3
0.2
0.1
"x----
-x ----------
6 7 8 9 10 11 12 13 14 15 1 2 3 4 5
N um ber of Sinks (Source Num ber = 1)
( a ) change sink numbers
0.8
Pull-XVR — i —
Push-XVR — x—
AVR -
0.7
0.6
0.5
0.4
0.3
0.2
0.1
0
4 6 7 8 9 10 11 12 13 14 15 1 2 3 5
Num ber of Sources (Sink Num ber = 1)
(b) change source numbers
Figure 6.3: Change sink number, and change source number, with the initial Source x
Sink = 1 x 1
120
Reproduced with permission of the copyright owner. Further reproduction prohibited without permission.
cases are to increase numbers of sinks and sources, while the last two cases are to decrease
numbers of sinks and sources. All these tests run for 300 seconds.
For the first two cases, we choose the initial numbers of sinks and sources to be one.
Figure 6.3 shows the results. The Figure 6.3a is for increasing sink numbers while keeping
source number as one. Figure 6.3b is for increasing source number while keeping sink
number as one. In both cases, as shown in Figure 6.3, AVR is able to change to the routing
that entails less overhead. The saved energy increases with the differences in source and
sink numbers. Note that the initial visiting-pattem of AVR is the pull pattern. So when
AVR changes to push pattern (Figure 6.3a), its energy consumption is slightly higher
than push-XVR because it uses the pull pattern during the initial control intervals. This
additional energy cost increases slowly with the ratio difference. In Figure 6.3b, AVR
never changes its visiting-pattem, so its energy cost is very close to the pull-XVR case.
Figure 6.4 shows the cases when decreasing the source or sink numbers. In these
tests, we choose the initial source and sink number as 15, and then change sink or source
numbers during next control interval. Figure 6.4 is the case to decrease the sink numbers.
In this case, AVR does not change its visiting-pattem, thus the energy cost is very close
to the XVR-pull routing. When the sink number becomes one, energy saved from XVR-
push is in excess one hundred percent. In the case of decreasing source numbers, when
source number is 14 and 15, AVR still uses the pull pattern. When source number is less
then 14, AVR changes its visiting-pattem to push, thus energy consumption become close
to XVR-push. There is also additional energy because of overhead from the initial pull
pattern. The additional energy is more noticeable than that in Figure 6.3a because more
sinks flood during the initial control intervals than those sinks in Figure 6.3a.
121
Reproduced with permission of the copyright owner. Further reproduction prohibited without permission.
Dissipated Energy (Joules/Received Data) Dissipated Energy (Joules/Received Data)
0.8
Pull-XVR
Push-XVR
AVR -—
0 .7
0.6
0.5
0 .4
0 .3
0.2
0.1
8 10 11 13 14 15 1 2 3 4 5 6 7 9 12
Num ber of Sinks (Source Number = 1 5 )
( a ) change sink numbers
0.8
Pull-XVR
Push-XVR
AVR
0.7
0.5
0.4
0.3
0.2
0.1
4 8 10 13 15 1 2 3 5 6 7 9 11 12 14
Num ber of Sources (Sink Num ber = 1 5 )
(b) change source numbers
Figure 6.4: Change sink number, and change source number, with the initial Source x
Sink = 15x15
122
Reproduced with permission of the copyright owner. Further reproduction prohibited without permission.
0.8
Pull-XVR 1 —
Push-XVR — x—
A VR
0.7
0.6
•o
CD
>
CD
O
CD
c c
'< 5 5
_CD
0.5
3
O
“ 5
0.4
o>
CD
C
L U 0.3
X -
0.2
0.1
1 2 3 4 5 6 7 8
N um ber of Sinks (Source N um ber = 8)
Figure 6.5: Change sink number after Source x Sink = 8 x 1 5
6.3.2 Two Consecutive Ratio Changes
This set of tests study the effects of AVR when two consecutive ratio changes happen.
In this case, it is possible that AVR changes its visiting-pattem twice. Thus the effect
of routing trashing can be observed. To generate these traffic patterns, we first choose
source and sink numbers as 8, then conduct two ratio changes in two consecutive control
intervals. Our simulations ran for 300 seconds.
Figure 6.5 shows cases in which the first ratio of source to sink numbers is set as 8/15,
and then we change sink numbers from 1 to 8 while keeping the source number as 8. In
these cases, when the sink number is less than 7, AVR changes its visiting-pattem for
both ratio changes and the resulting routing after these two changes is still the XVR-pull.
When the sink number is 7 and 8, AVR changes its visiting-pattem only once with the
123
Reproduced with permission of the copyright owner. Further reproduction prohibited without permission.
Number of Ratio Changes Source x Sink Details
0 lxl
1 lx l - 1x4
2 lx l - 1x4 - 7x4
3 lx l - 1x4-7x4-7x10
4 lx l - 1x4-7x4-7x10-13x10
5 lx l - 1x4 - 7x4 - 7x10 - 13x10 - 13x16
Table 6.4: Ratio Changes for Figure 6.6a
Number of Ratio Changes Source x Sink Details
0 lx l
1 lx l -4x1
2 lx l - 4x1 - 4x7
3 lx l -4x1-4x7-10x7
4 lx l -4x1 -4x7- 10x7-10x13
5 lx l - 4x1 - 4x7 - 10x7 - 10x13 - 16x13
Table 6.5: Ratio Changes for Figure 6.6b
XVR-push as the resulting service. From Figure 6.5, we can see that the energy cost for
AVR is closer to the XVR-push in case when the sink number is 7 or 8, and the AVR
performance is closer to the XVR-pull in other cases of sink numbers. In all cases, the
energy cost for AVR is generally less than any single instance of the pull-XVR and push-
XVR, because the energy consumption is saved from routing changes. Figure 6.5 shows
that changing routing in two consecutive intervals is often still beneficial.
6.3.3 Multiple Ratio Changes
This set of tests is to observe the effects of different numbers of ratio changes. The initial
numbers for sources and sinks are one, then after every three control interval the ratio
124
Reproduced with permission of the copyright owner. Further reproduction prohibited without permission.
is changed until a specified number of changes is reached. We test for six ratio change
numbers, as shown in Table 6.4 and Table 6.5. The simulations ran for 1000 seconds.
Figure 6.6 show results of the different numbers of ratio changes. In Figure 6.6a, even
numbers of ratio changes lead to the pull pattern, while odd numbers lead to the push
pattern. When odd number increases, energy saved from XVR-push increases. When
even number increases, energy saved from XVR-pull increases. This is because before
the final visiting-pattem is chosen, AVR obtains gains from visiting-pattem changes.
In Figure 6.6b, even numbers of ratio changes lead to the push pattern, while odd
numbers lead to the pull pattern. When odd number increases, energy saved from XVR-
pull increases. When even number increases, energy saved from XVR-push increases.
The reason is similar to Figure 6.6a.
Comparing Figure 6.5 and Figure 6.6, we can see that the AVR savings increase with
the number of ratio changes and also increase when the interval for one change increases.
For example, when the ratio change number is 2, the routing changes in Figure 6.6 lasts
for three control intervals, while the routing changes in Figure 6.5 lasts for only one
control interval. The savings from the Figure 6.6 cases are significantly larger than the
cases in Figure 6.5.
6.4 Related Work
To the best of our knowledge, the first work that conducts automatic service changes
in sensor networks is Impala [48]. Impala [48] is a middleware architecture to sup
port service adaptation in the Zebra Net. There is an adapting module that monitors
the service/device status and performance and makes a changing decision when certain
125
Reproduced with permission of the copyright owner. Further reproduction prohibited without permission.
Dissipated Energy (Joules/Received Data) Dissipated Energy (Joules/Received Data)
0.8
Pull-XVR i—
Push-XVR — x—
A VR -
0.7
0.6
0.5
0.4
0.3
x
0.2
0.1
2 3 4 5 1 0
Number of Ratio Changes
(a) sink number x source number: lx l - 1x4 - 7x4 - 7x10 - 13x10 - 13x16
0.8
Pull-XVR -----1 —
Push-XVR —- x ~
A VR
0.7
0.6
0.5
0.4
0.3
0.2
0.1
3 4 5 1 2 0
Num ber of Ratio Changes
(b) sink number x source number: lx l - 4x1 - 4x7 - 10x7 - 10x13 - 16x13
Figure 6.6: Sink number x source number: lx l - 1x4 - 7x4 - 7x10 - 13x10 - 13x16, and
lxl - 4x1 - 4x7 - 10x7 - 10x13 - 16x13
126
Reproduced with permission of the copyright owner. Further reproduction prohibited without permission.
situation-changing patterns are detected, The changing decision causes the whole ser
vice to be replaced. AVR proposes a general approach in any sensor network to conduct
routing visiting-pattem changes. Since visiting-pattems are essential parts of a routing
service, changing them does not need to change an entire routing service module, but also
leads to significant routing behavior change.
There is a scheme based on active networks [75] for concurrent routing in ad-hoc
networks [19]. In this scheme, mobility level is used as a criterion to choose between DSR
and AODV for an ad hoc network. AODV is chosen when mobility level is low, while
DSR is chosen when mobility becomes high. Similar to Impala, entire service is changed
when needed. With this scheme, these two routing protocols can co-exist in different
areas of a network. In contrast to this scheme, AVR does not rely on an active network
architecture, and conducts fine-grained routing changes suitable for resource-constrained
sensor networks.
There are several other self-adapting routing services that suit themselves for differ
ent network situations. In Q-routing [6], an online reinforcement learning algorithm is
proposed to balance minimizing route length with the possibility of congestion on pop
ular paths. In [10], the Q-routing is extended to learn a movement policy in mobile
ad-hoc networks so that routing performance can be optimized. All these adaptive rout
ing services can be regarded as conducting adaptations in certain visiting-pattems (intra
changes). Besides the intra-changes, AVR is designed to conduct adaptations among dif
ferent categories of visiting-pattems (inter-changes), such as those probability-based, and
geography-based visiting-pattems defined in the XVR [25], The visiting-pattem adapta
tions between pull and push presented in this paper establish an inter-change example.
127
Reproduced with permission of the copyright owner. Further reproduction prohibited without permission.
6.5 Summary
We have presented AVR (Automatic Visiting-pattem Routing) for sensor networks that
changes visiting-pattems under application and network dynamics. As an example, AVR
changes routing between pull and push according to current ratio between sink and source
numbers. A set of algorithms have been proposed to dynamically choose a leader node
for removing decision conflicts, to avoid premature flooding before a routing-change de
cision, and to provide smooth service transitions. The algorithms are light-weight by
making use of existing routing control packets in the XVR, and are scalable by keeping
the minimum state information.
128
Reproduced with permission of the copyright owner. Further reproduction prohibited without permission.
Chapter 7
Conclusions and Future Work
This dissertation has discussed two different approaches to improve adaptability of rout
ing services. In ad-hoc networks, a conservative approach is proposed to work with known
routing services. In sensor networks, a proactive approach is proposed to provide a novel
open routing architecture. The advantage of the conservative approach lies in its deploy
ment capability. With the flexible Active Dynamic Source Routing (ADSR), this disserta
tion has shown the feasibility to increase adaptability without changing a legacy system.
Proactive approach gives an example of how to design a service with great flexibility. The
key to this proactive approach is to identify, separate, and explore the essential functions
of a target service. This approach is applicable to new and emerging services. Combining
these two approaches, this dissertation sheds insight into designing adaptive services for
both legacy and new systems.
There are multiple future research directions that this can take for both ADSR and
XVR. For ADSR, the design space for visiting-pattems of probing packets can be ex
plored. Such examples include those visiting-pattems defined in XVR (i.e., probable and
geographical forwarding). Another design space is other state information to be collected
129
Reproduced with permission of the copyright owner. Further reproduction prohibited without permission.
by probing packets. Some examples include QoS statistics in some nodes. The infor
mation can be used to realize QoS-aware routing for ad-hoc networks. Further, other
on-demand ad hoc network routing services can use this general approach to actively
collect state information to improve performance.
In terms of future work of XVR, associations between different visiting-pattems and
application and network performance are important to realize automatic mapping. The
feedback-based mechanism can be extended to include general changes among visiting-
pattems. Further, nodes in a sensor network (especially with a tiered architecture) play
different roles in automatic routing configuration and optimization. The interaction and
coordination among different categories of nodes can be identified to reduce the routing
adaptation overhead.
Concurrent routing with XVR is also a promising field for sensor networks. With
the support of XVR, multiple routing services with different visiting-pattems can run
simultaneously in a sensor network. These routing services share a fixed routing core and
routing state information. This sharing implies scalable state and low overhead routing.
The routing state will not increase with the number of routing services. In addition,
collaborations among different routing services can be developed via sharing the routing
state. As a result, different application requirements can be met with significantly smaller
energy cost than using a single routing service.
130
Reproduced with permission of the copyright owner. Further reproduction prohibited without permission.
Bibliography
[1] Research infrastructure for managing spatio-temporal objects in video sensor net
works. http://www. cs. bu. edu/groups/sensorium/.
[2] I. F. Akyildiz, W. Su, and et. al. Wireless sensor networks: A survey. Computer
Networks, December 2002.
[3] R. Boppana and S. Konduru. An adaptive distance vector routing algorithm for
mobile, ad hoc networks. Infocom, March 2001.
[4] Athanassios Boulis, Chih-Chieh Han, and et. al. Design and implementation of a
framework for efficient and programmable sensor networks. MobiSys, May 2003.
[5] Athanassios Boulis and Mani B. Srivastava. A framework for efficient and pro
grammable sensor networks. OPENARCH, July 2002.
[6] J. Boyan and M. L. Littman. Packet routing in dynamically changing networks: A
reinforcement learning approach. Advances in NIPS, 1994.
[7] David Braginsky and Deborah Estrin. Rumor routing algorithm for sensor networks.
WSNA, September 2002.
[8] Nirupama Bulusu, John Heidemann, and et. al. Self-configuring localization sys
tems: Design and experiment evaluation. Submitted to ACM TECS Special Issue on
Networked Embedded Computing, August 2002.
[9] J. Cerpa, D. Estrin, and et. al. Habitat monitoring: application driver for wireless
communications technology. ACM SIGCOMM Workshop on Data Communications
in Latin America and the Caribbean, April 2001.
[10] Yu-Han Chang, Tracey Ho, and et. al. Mobilized ad-hoc networks: A reinforcement
learning approach. ICAC, 2004.
[11] Benjie Chen, Kyle Jamieson, and et. al. Span: An energy-efficient coordination
algorithm for topology maintenance in ad hoc wireless networks. Mobicom, 2001.
131
Reproduced with permission of the copyright owner. Further reproduction prohibited without permission.
[12] Kai Chen and Klara Nahrstedt. Effective location-guided overlay multicast in mo
bile ad hoc networks. International Journal o f Wireless and Mobile Computing
(1JWMC), 3B, 2005.
[13] IEEE Computer Society LAN/WAN Standards Committee. Wireless lan medium
access control (mac) and physical layer (phy) specifications. IEEE Std. 802.11,
1997.
[14] Stephen Deering, Deborah Estrin, and et. al. The pirn architecture for wide-area
multicast routing. ACM/IEEE Transactions on Networks, April 1996.
[15] D. Estrin, L. Girod, and et. al. Instrumenting the world with wireless sensor net
works. ICASSP, May 2001.
[16] D. Estrin, R. Govindan, and et. al. Next century challenges: scalable coordination
in sensor networks. Mobicom, August 1999.
[17] L. Girod, D. Estrin, and et. al. Robust range estimation using acoustic and multi
modal sensing. IEEE Conference on Intelligent Robots and Systems, 2001.
[18] T. Goff, N. B. Abu-Ghazaleh, and et.al. Preemptive maintenance routing in ad-hoc
networks. Mobicom, July 2001.
[19] Richard Gold and Dan Tidhar. Concurrent routing protocols for an active ad hoc
network. AISB Symposium on Software Mobility and Adaptive Behavior, 2001.
[20] CMU Monarch Group. Cmu monarch extensions to ns-2 simulatr.
http: //monarch, cs. cmu. edu/cmu-ns. html, 1998.
[21] Cao Gui and Prasant Mohapatra. Short: Self-healing and optimizing techniques for
mobile ad-hoc networks. Mobihoc, 2003.
[22] Z. J. Hass and M. R. Pearlman. The performance of query control schemes for the
zone routing protocol. Sigcomm, 1998.
[23] Tian He, Sudha Krishnamurthy, and et. al. An energy-efficient surveillance system
using wireless sensor networks. MobiSys, June 2004.
[24] Yu He and C. S. Raghavendra. Building programmable routing services for sen
sor networks. Computer Communications, Special Issue on Activated and Pro
grammable Internet, 28(6):664-675, April 2005.
[25] Yu He and C. S. Raghavendra. Xvr: X visiting-pattem routing for sensor networks.
IEEE Infocom, 2005.
[26] Yu He, C. S. Raghavendra, and et. al. Active packets improve dynamic source
routing for ad-hoc networks. IEEE OPENARCH, June 2002.
132
Reproduced with permission of the copyright owner. Further reproduction prohibited without permission.
[27] Yu He, C. S. Raghavendra, and et. al. A programmable routing framework for
autonomic sensor networks. Active Middleware Service (AMS), June 2003.
[28] Yu He, C. S. Raghavendra, and et. al. Tcp performance with active dynamic source
routing for ad hoc networks. ANTA, May 2003.
[29] Yu He, C. S. Raghavendra, and et. al. An autonomic routing framework for sensor
networks. Cluster Computing, Special Issue on Autonomic Computing, to appear.
[30] C. Hedrick. Rfc 1058 - routing information protocol. Request for Comments, June
1988.
[31 ] John Heidemann, Fabio Silva, and et. al. Building efficient wireless sensor networks
with low-level naming. SOSP, October 2001.
[32] John Heidemann, Fabio Silva, and et. al. Diffusion filters as a flexible architecture
for event notification in wireless sensor networks. USC/ISI Tech. Report, April 2002.
[33] John Heidemann, Fabio Silva, and et. al. Matching data dissemination algorithm to
application requirements. SenSys, November 2003.
[34] W. Heinzelman, Anantha Chandrakasan, and et. al. Energy-efficient communication
protocols for wireless microsensor networks. Hawaaian International Conference
on Systems Science, January 2000.
[35] W. Heinzelman, J. Kulik, and et. al. Adaptive protocols for information dissemina
tion in wireless sensor networks. Mobicom, August 1999.
[36] Jason Hill, Robert Szewczyk, and et. al. System architecture directions for net
worked sensors. ASPLOS, November 2000.
[37] Y.-C. Hu and D. Johnson. Caching strategies in on-demand routing protocols for
wireless ad hoc networks. Mobicom, 2000.
[38] John Fisher III and Trevor Darrell. Informative subspaces for audio-visual process
ing: high-level function from low-level fusion. ICASSP, 2002.
[39] Chalermek Intanagonwiwat, Ramesh Govindan, and et. al. Directed diffusion: A
scalabel and robust communication paradigm for sensor networks. Mobicom, 2000.
[40] J. M. Kahn, Howard Katz, and et. al. Mobile networking for smart dust. Mobicom,
August 1999.
[41] Brad Karp and H. T. Kung. Gpsr: Greedy perimeter stateless routing for wireless
networks. Mobicom, 2000.
133
Reproduced with permission of the copyright owner. Further reproduction prohibited without permission.
[42] Cory Kidd, Robert Orr, and et. al. The aware home: A living laboratory for ubiqui
tous computing research. Cobuild, 1999.
[43] Bhaskar Krishnamachari and John Heidemann. Application-specifc modelling of
information routing in wireless sensor networks. ICCC, April 2004.
[44] Philip Levis and David Culler. Mate: A tiny virtual machine for sensor networks.
ASPLOSX, October 2002.
[45] D. Li, K. Wong, and et. al. Detection, classification and tracking of targets. IEEE
Signal Processing Magazine, March 2002.
[46] Jian Liu and Suresh Singh. Atcp: Tcp for mobile ad hoc networks. IEEE J-SAC,
2001.
[47] T. Liu, C. Sadler, and et. al. Implementing software on resource-constrained mobile
sensors: Experiences with impala and zebranet. MobiSys, June 2004.
[48] Ting Liu and Margaret Martonosi. Impala: A middleware system for managing
autonomic, parallel sensor systems. PPoPP, 2003.
[49] Samuel R. Madden, Robert Szewczyk, and et. al. Supporting aggregate queries over
ad-hoc wireless sensor networks. WMCSA, June 2002.
[50] D. A. Maltz, J. Broch, and et. al. The effects of on-demand behavior in routing
protocols for multi-hop wireless ad hoc networks. IEEE J-SAC, August 1999.
[51] D. B. Johnson D. A. Maltz and et. al. The dynamic source routing protocol for mo
bile ad-hoc networks. IETFInternat Draft http://www.ietf.org/internet-drafts/draft-
ietf-manet-dsr-10.txt, 2004.
[52] M. Marina and S. Das. Performance of route caching strategies in dynamic source
routing. Proceedings o f the 2nd Wireless Networking and Mobile Computing Work
shop, 2001.
[53] J. Moy. Rfc 2328 - ospf version 2. Request for Comments, April 1998.
[54] Badri Nath and Dragos Niculescu. Routing on a curve. Hotnets I, October 2002.
[55] Dragos Niculescu and Badri Nath. Trajectory based forwarding and its applications.
Mobicom, September 2003.
[56] J. Parker Patwardhan, A. Joshi, and et. al. Secure routing and intrusion detection
in ad hoc networks. IEEE International Conference on Pervasive Computing and
Communications (PerCom), 2005.
[57] C. E. Perkins. Ad hoc networking. Addison Wesley Pub Co Inc, 2000.
134
Reproduced with permission of the copyright owner. Further reproduction prohibited without permission.
[58] C. E. Perkins and P. Bhagwat. Highly dynamic destination-sequeced distance vector
(dsdv) for mobile computers. Sigcomm, 1994.
[59] C. E. Perkins, E. M. Royer, and et. al. Ad hoc on-demand distance vector (aodv)
routing, http://www.ietf.org/rfc/rfc3561.txt, 2003.
[60] Adrian Perrig, Robert Szewczyk, and et. al. Spins: Security protocols for sensor
networks. Wireless Networks Journal (WINE), September 2002.
[61] K. Pister, J. Kahn, and et. al. Smart dust: wireless networks of milimeter-scale
sensor nodes. Highlight Article in 1999 Electronics Research Laboratory Research
Summary, 1999.
[62] Kurt Plarre and P. R. Kumar. Object tracking by scattered directional sensors.
Preprint, available at http://black.csl.uiuc.edu/prkumar/, November 2004.
[63] G. Pottie. Wireless sensor networks. Communications o f the ACM, 2000.
[64] Ananth Rao, Sylvia Ratnasamy, and et. al. Geographic routing without location
information. Mobicom, September 2003.
[65] S. Ratnasamy, Brad Karp, and et. al. Ght: A geographic hash table for datat-centric
storage. WSNA, September 2002.
[66] Loren Schwiebert, Sandeep Gupta, and et. al. Research challenges in wireless net
works of biomedical sensors. Mobicom, July 2001.
[67] Samarth H. Shah and Klara Nahrstedt. Predictive location-based qos routing in
mobile ad hoc networks. IEEE International Conference on Communications (ICC),
2002.
[68] Fabio Silva, John Heidemann, and et. al. Network routing application programmer’s
interface (api) and walk through 9.0.1. http://www.isi.edu/scadds/papers/, Decem
ber 2002.
[69] Gyula Simon, Akos Ledeczi, and et. al. Sensor network-based countersniper system.
SenSys, November 2004.
[70] Suresh Singh and Cauligi S. Raghavendra. Power-aware routing in mobile ad hoc
networks. Mobicom, October 1998.
[71] Katayoun Sohrabi, Jay Gao, and et. al. Protocols for self-organization of a wireless
sensor network. IEEE Personal Communications, October 2000.
[72] Mani Srivastava, Richard Muntz, and et. al. Smart kindergarten: Sensor-based wire
less networks for smart developmental problem-solving environments. Mobicom,
July 2001.
135
Reproduced with permission of the copyright owner. Further reproduction prohibited without permission.
[73] Fred Stann and John Heidemann. Rmst: Relaible data transport in sensor networks.
SNPA, May 2003.
[74] Robert Szewczyk, Alan Mainwaring, and et. al. An analysis of a large scale habitat
monitoring application. SenSys, November 2004.
[75] D. L. Tenenhouse, J. M. Smith, and et. al. A survey of active network research.
IEEE Communication Magazine, January 1997.
[76] USC/ISI. Network simulator, http://www.isi.edu/nsnam/ns/.
[77] A. Woo and D. Culler. A transmission control scheme for media access in sensor
networks. SenSys, November 2003.
[78] Ning Xu, Sumit Rangwala, and et. al. A wireless sensor network for structural
monitoring. SenSys, November 2004.
[79] Ya Xu, John Heidemann, and et. al. Geography-informed energy conservation for
ad hoc routing. Mobicom, 2001.
[80] Yuan Xue, Baochun Li, and et. al. A scalable location management scheme in
mobile ad-hoc networks. IEEE Annual Conference on Local Computer Networks
(LCN), 2001.
[81] Yuan Xue, Baochun Li, and et. al. Optimal resource allocation in wireless ad hoc
networks: A price-based approach. IEEE Transactions on Mobile Computing, to
appear.
[82] Yong Yao and Johannes Gehrke. The cougar approach to in-network query process
ing in sensor networks. Sigmod Record, 31(3), September 2002.
[83] Fan Ye, Haiyun Luo, and et. al. A two-tier data dissemination model for large-scale
wireless sensor networks. Mobicom, September 2002.
[84] Wei Ye, John Heidemann, and et. al. An energy-efficient mac protocol for wireless
sensor networks. Infocom, June 2002.
[85] Yan Yu, Ramesh Govindan, and et. al. Geographical and energy aware routing: a
recursive data dissmination protocol for wireless sensor networks. UCLA CS Tech.
Report, 2001.
[86] Feng Zhao, Jaewon Shin, and et. al. Information-driven dynamic sensor collabora
tion for tracking applications. IEEE Singal Processing Magazine, March 2002.
[87] Hu Zhou and Suresh Singh. Content-based multicast for mobile ad hoc networks.
Mobihoc, August 2000.
136
Reproduced with permission of the copyright owner. Further reproduction prohibited without permission.
Linked assets
University of Southern California Dissertations and Theses
Conceptually similar
PDF
Energy latency tradeoffs for medium access and sleep scheduling in wireless sensor networks
PDF
Adaptive energy conservation protocols for wireless ad hoc routing
PDF
Distributed resource allocation in networks for multiple concave objectives
PDF
Diagnosis and localization of interdomain routing anomalies
PDF
Applying aggregate-level traffic control algorithms to improve network robustness
PDF
Grid workflow: A flexible framework for fault tolerance in the grid
PDF
Boundary estimation and tracking of spatially diffuse phenomena in sensor networks
PDF
Energy -efficient information processing and routing in wireless sensor networks: Cross -layer optimization and tradeoffs
PDF
Compression, correlation and detection for energy efficient wireless sensor networks
PDF
Architecture -independent programming and software synthesis for networked sensor systems
PDF
Hyperbolic geometry of networks
PDF
Call admission control and resource allocation for quality of service support in wireless multimedia networks
PDF
Analysis of wired short cuts in wireless sensor networks
PDF
Improving memory hierarchy performance using data reorganization
PDF
A unified mapping framework for heterogeneous computing systems and computational grids
PDF
Design issues in large-scale application -level routing
PDF
Bioscope: Actuated sensor network for biological science
PDF
Design of wireless sensor network based structural health monitoring systems
PDF
Energy and time efficient designs for digital signal processing kernels on FPGAs
PDF
Characterizing Internet topology, routing and hierarchy
Asset Metadata
Creator
He, Yu
(author)
Core Title
Adaptive routing services in ad-hoc and sensor networks
School
Graduate School
Degree
Doctor of Philosophy
Degree Program
Computer Science
Publisher
University of Southern California
(original),
University of Southern California. Libraries
(digital)
Tag
Computer Science,OAI-PMH Harvest
Language
English
Contributor
Digitized by ProQuest
(provenance)
Advisor
Raghavendra, Cauligi S. (
committee chair
), Helmy, Ahmed Abdel-Ghaffar (
committee member
), Khrishnamachari, Bhaskar (
committee member
)
Permanent Link (DOI)
https://doi.org/10.25549/usctheses-c16-612709
Unique identifier
UC11341053
Identifier
3220109.pdf (filename),usctheses-c16-612709 (legacy record id)
Legacy Identifier
3220109.pdf
Dmrecord
612709
Document Type
Dissertation
Rights
He, Yu
Type
texts
Source
University of Southern California
(contributing entity),
University of Southern California Dissertations and Theses
(collection)
Access Conditions
The author retains rights to his/her dissertation, thesis or other graduate work according to U.S. copyright law. Electronic access is being provided by the USC Libraries in agreement with the au...
Repository Name
University of Southern California Digital Library
Repository Location
USC Digital Library, University of Southern California, University Park Campus, Los Angeles, California 90089, USA