Download Deployment of a Rational Swarm Routing Algorithm in Ad Hoc

Proceedings of the 2008 IEEE Systems and Information
Engineering Design Symposium, University of Virginia,
Charlottesville, VA, USA, April 25, 2008
FPM2Opt.1
Deployment of a Rational Swarm Routing Algorithm in Ad Hoc
Networks of Mobile Hosts
Jonathan H. Bao
Abstract—Mobile ad hoc networks are characterized by
many small processors that work together to perform complex
tasks with no outside help. These systems are rapidly
deployable and can be used to create wireless sensor networks.
The challenge lies in developing a protocol that allows the
processors to automatically set up multi-hop communication
paths among themselves. If the nodes are mobile then the
network topology changes when nodes move out of wireless
range and nodes may have to reestablish broken paths. The
rational swarm protocol developed at the University of Virginia
attempts to discover several paths between a source and
destination by tracking the quality of each path to minimize the
expensive need to perform route discovery when a path breaks.
This thesis project deployed rational swarm onto a real system
of small Sun SPOTs to serve as a proof of implementation. A
graphical user interface allows a user to control and display the
system to demonstrate its capabilities to a large audience.
M
I. INTRODUCTION
OBILE ad hoc networks (MANET) are made up of
hundreds of small processors that rely on each other
for wireless communication. Instead of using large
infrastructure to transmit messages long distances, the
processors forward messages amongst themselves until the
packets reach their destinations. Such networks have
applications that range from military surveillance to
biomedical monitoring and are characterized by rapidly
deployable and flexible applications. The major research
problem provided by MANETs stems from developing a
routing protocol that automatically enables the processors to
set up multihop communication paths. The protocol must
establish paths quickly, not use too much battery power or
wireless bandwidth, and handle path failure. The problem
may be divided into two parts: route discovery and route
maintenance [1].
When a node needs to send a message to another
destination node and does not know how to route its
message through the network, it must perform route
discovery. The source node has to broadcast probing
messages to find a path to the destination node. Upon
hearing the probe, the destination sends a reply message
back to the source. The source receives the reply message
and knows how to transmit messages to the destination.
Manuscript received April 7, 2008. This work was supported in part by
NanoVision Technologies Inc and the University of Virginia’s Wireless
Internet Center for Advanced Technology.
Jonathan Bao is with the Systems Engineering Department, University of
Virginia, Charlottesville, VA 22904 USA (mobile: 703-629-8647;
email:[email protected]).
1-4244-2366-8/©2008 IEEE
Route discovery is a sophisticated algorithm that requires
messages to propagate through the network, which costs
precious resources in terms of battery power and wireless
bandwidth. The best routing protocols seek to reduce the
number of route requests required and the number of
messages that need to be sent to determine routes.
Route maintenance methods must be able to recognize
when a path between the source and the destination becomes
invalid when a link in the path breaks. In some protocols,
each node in the path must broadcast “hello” messages to its
neighbors to inform them that a link exists between the node
and its neighbors [2]. When a node ceases to receive “hello”
messages from its neighbor, it knows that the link has
broken, and it has to let everyone using the path between
itself and its neighbor know that the path is no longer valid.
It sends route error messages to each node depending on the
path, and every node must update itself with the new
information. Note that this requires nodes to periodically
send “hello” messages, which uses resources by clogging
the system with packets.
The Wireless Internet Center for Advanced Technology
(WICAT) at the University of Virginia has defined the
major mechanisms of the new rational swarm routing
protocol and are currently testing some of the finer details to
gain the best performance out of the protocol. Tests were
conducted in a simulated environment of dozens of nodes
using The Network Simulator (NS-2). This thesis project
serves as a proof of implementation that the protocol can
work in a real system of wireless mobile processors.
Rational swarm was implemented on Sun SPOTs, which are
small wireless processors built by Sun Microsystems. In
addition to implementation, the project uses a graphical user
interface that projects the system of Sun SPOTs onto a
computer monitor in real time so users can control and
watch the protocol.
II. AODV
Rational swarm uses many of the mechanisms found in
the Ad Hoc On-Demand Distance Vector (AODV) routing
protocol; in fact, rational swarm is almost a pure extension
of AODV. Perkins and Royer created AODV at the
University of California Santa Barbara in 1999 [3]. AODV
has several characteristics that make it desirable to use as the
basis for a new protocol. AODV was one of the first routing
protocols created for MANETs, so it is relatively simple yet
completely functional. Many of its characteristics make it
attractive over other basic protocols, namely that it is an ondemand protocol and it is a distance vector protocol.
329
A. On-Demand vs. Proactive Protocols
On-demand protocols benefit over proactive protocols by
reducing overhead and eliminating wasted resources.
Overhead in these terms may be defined as any information
sent between two nodes that is not actual data used by the
applications running on the nodes. Messages used by a
protocol that do not contain any application data are the
most important source of overhead. It is impossible to
entirely eliminate overhead from a protocol; instead we
attempt to minimize it.
The goal of proactive protocols is to establish paths
before they need to be used. Ideally, when a node needs to
send a message, it will already know the path to the
destination. In order to find paths, a node must broadcast
messages throughout the network. In other words, work
must be done to find paths. If a node does not use a path that
it worked to establish, then it has wasted resources finding a
path that it will never use.
On-demand protocols such as AODV reduce overhead by
never finding paths between nodes that do not need to
communicate. A node only tries to find a path to another
node when it needs to send data to the other node. Although
a node will not waste precious network bandwidth and
battery life, the tradeoff is a node may have to wait a long
time to allow the route discovery mechanism to find a path
before it can send data. In our high-mobility and lowresource application, we prefer to reduce waste and accept
delays incurred with an on-demand protocol.
node may have to remember long paths and each message
will have to contain a lengthy list.
Distance vector protocols do not rely on the source
knowing the entire path. After route discovery finishes in
AODV, each node on a path is responsible for knowing
which neighbor to forward a message to in order to reach the
destination. For example, in Fig. 2 the source knows it needs
to send its message to node 2 to reach the destination.
B. Source Routing vs. Distance Vector Protocols
The easiest way to describe distance vector protocols is to
show how it works and compare it to a protocol that does
not use distance vector routing. The Dynamic Source
Routing (DSR) protocol uses source routing instead of
distance vector routing and offers benefits and drawbacks
compared to AODV [4]. After a node performs route
discovery to find a route to a destination node using DSR,
the source node knows the entire path that must be taken to
reach the destination. As an example, the source will know a
message must travel from itself to node 2, then on to node 7,
and so forth until the destination receives the message, as
shown in Fig. 1.
III. RATIONAL SWARM ROUTING PROTOCOL
Fig. 1. Example of source routing. The source node is responsible for
keeping track of the entire path.
When the source sends a message to the destination, it
will attach the entire path to the message, so when node 2
receives the message from the source it can look at the path
and see that it needs to forward the message to node 7. An
advantage of this method is that the source can keep track of
multiple paths to the destination. However, paths could get
very long if there are many nodes in the network. The source
1-4244-2366-8/©2008 IEEE
Fig. 2. Example of distance vector routing. Each node is responsible
for knowing the next node in the path.
However, the source does not know that node 2 has to in
turn forward it to node 7. Node 2 is in charge of knowing
that all messages for the destination have to go through node
7. Distance vector routing eliminates the need for the source
to remember lengthy paths and for messages to contain
paths. However, a negative of AODV is it will only establish
one path between the source and the destination. If that path
breaks, the source will have to initiate route discovery to
find a different path. The simple reason for AODV’s
inability to remember multiple paths is that if the source had
multiple paths to the destination, it would not be able to
compare the paths to determine which the best one is.
The fundamental difference between AODV and rational
swarm is that swarm maintains several metrics to gauge the
quality of each path. AODV is restricted to only creating
one path between a source and destination because there is
no way to determine which path is the best. If the nodes
keep track of metrics for a path, then they can make
decisions about which path to use. The benefit of
remembering multiple paths is that a node is able to switch
to a different path if the current path breaks instead of
having to perform route discovery to find a new path.
Rational swarm measures the quality of paths using two
metrics: success rate, which is the percent of packets
successfully transmitted between two nodes, and delay,
which is the time it takes for a packet to reach its
destination.
A. Multiple-Path Distance Vector Routing
Enabling a distance vector protocol to remember multiple
paths creates an advantage over other protocols. To
demonstrate the point, we will compare rational swarm to
DSR, which uses source routing to maintain multiple paths.
Recall in source routing that the source node must keep
track of the entire path from the source to the destination. As
an example, consider the two-path system shown in Fig. 3.
The source knows a message can travel from 1 to 2 to 4, or
alternatively a message can travel on the different path 1 to 3
to 4. If the source node discovers that the path it is using
breaks, it will decide to switch to the other path.
330
Fig. 3. A two-path system. Messages may either
travel along the top path or the bottom path.
In distance vector routing, a given node only knows
which neighbor to give a message to; it doesn’t know what
the path looks like between the neighbor and the destination.
After receiving a message, a node may only decide which
neighbor to forward the message to, so the maximum
number of paths it knows about is the number of neighbors
it has. To illustrate, in Fig. 3 the source can only send a
message to node 1, so it thinks there is only one path to the
destination when in reality there are two. Node 1 is the only
one that knows the existence of the two paths because it can
either send a message to node 2 or node 3.
This characteristic of distance vector routing is very
beneficial in route maintenance. Consider that node 1 has
chosen to send messages to node 2 and therefore uses the
path from the source to 1 to 2 to 4. If node 2 becomes
inactive by either turning off or moving out of the network,
then the path will break. Node 1 will realize that it can no
longer send messages to node 2. Then it can make the
decision to use node 3 without having to let any other nodes
know. The network automatically adapts to node failure or
mobility at the point where the break occurred. Only if node
1 had no paths to the destination (for instance if node 3 then
shut off) will it have to send a route error (RERR) message
backwards to the source. Even then, if a node receives the
RERR message and it has another path to the destination, it
will switch to the other path without having to inform any
other nodes.
B. Success Rate Metric
Sometimes messages will not successfully travel between
two neighboring nodes even if they are within wireless
distance. Failed transmissions may be caused by several
factors, such as interference in the radio waves or an excess
load on the node receiving the message. Generally, the
farther apart two nodes are, the less likely a message will
successfully make it from one to the other. Link failure can
be extrapolated to an entire path such that there is a
probability that a message will not be able to travel between
a source and destination even if the path physically exists.
For each path, nodes keep track of how often messages are
successfully transmitted and stores the knowledge as the
path’s success rate. If the success rate of a path drops below
a threshold value, then the node will decide the path is too
unreliable and it will remove the path from its memory,
provided it has another path to the destination. If the
unreliable path is the only available path, then the node will
resign to continue using it.
1-4244-2366-8/©2008 IEEE
When a node X sends a data packet to its neighboring
node Y, it expects to receive an acknowledgment, or ACK,
from Y stating it has successfully received the packet. If an
ACK is not heard after a certain amount of time, node X
assumes the message was lost. Let p be a variable with a
value of 1 if the message was successfully transmitted and 0
if it was lost. Also, let w be a weight variable that
determines how important new information is compared to
already known information. After each successful or failed
message, node X updates its knowledge of the success rate
of the link according to (3).
s X ,Y = s X ,Y * (1 − w) + w * p
(1)
When node Y sends an ACK to node X, it includes its
knowledge of the success rate from node Y to the
destination node D. We treat the probability of a successful
transmission over a link as independent from the other links,
so to find the total success rate between X and D we
multiply the probabilities. Equation (2) demonstrates this
relationship.
s X , D = s X ,Y * sY , D
(2)
C. Delay Metric
For each path, a node also keeps track of how long it takes
a message to reach the destination. Nodes store the delay
times for every path into memory. If a node has multiple
paths to reach the same destination, it will use the path with
the lowest delay because it is interested in the fastest path
possible. Every time a node learns new information about
the delay of a path, it will look at all available paths and
choose the fastest. This is in contrast to the success rate
metric, which only looks at an individual path to determine
if it should be removed from memory. In short, nodes use
the delay metric to choose the best path, while the success
rate metric is used to eliminate bad paths.
When a node X sends a data packet to a neighbor Y, it
expects to receive an ACK from the neighbor that the
message was received. The sending node keeps track of how
long it took to receive the ACK after sending the data packet
and stores the information as the delay time for the link. As
part of the ACK, the neighbor sends how long it takes a
message to travel from the neighbor to the destination node
D. Thus, the time it takes for a message to travel from X to
D is simply a sum of the measurements, shown in (3).
d X , D = d X ,Y + d Y , D
(3)
IV. IMPLEMENTATION
This section describes how rational swarm was
implemented onto the Sun SPOTs. Rational swarm had been
written in the programming language C to run on the agentbased simulator NS-2 by Fernan Pedraza, a graduate student
at the University of Virginia, so a large part of the
development was simply to translate the program into Java.
It was not a blind translation because intimate knowledge of
every line of the C code was needed to ensure it needed to
be in the Java implementation. There was no documentation
on how rational swarm worked, so the C code was used as
331
the main description of the protocol. This section begins
with a brief description of the capabilities of Sun SPOTs and
then covers the major steps in writing swarm onto the Sun
SPOTs.
A. Sun SPOTs
Sun Small Programmable Object Technologies, or Sun
SPOTs, are small processors created by Sun Microsystems
[5]. They are specially built to run Java programs and come
with a 180 MHz processor and 512K RAM, so they can run
any Java program meeting these constraints. A radio and
antenna allows each Sun SPOT to wirelessly transmit data
using the IEEE 802.15.4 standard for wireless
communication. This standard is intended to require little
battery power at the cost of slower transmission compared to
the 802.11 standard used by computers [6].
Sun SPOTs come in two varieties. The first is a
standard Sun SPOT, which is designed to run by itself. In
contrast, the second type is a base station, which only
operates when connected to a computer. A Sun SPOT uses a
battery for power and comes with an LED display that
provides output signals while it runs a program. Base
stations do not run programs and use the computer for
energy. Programs are run on the computer and the base
station is used as a radio that allows the computer to send
and receive messages to and from the Sun SPOTs. The test
system is made up of Sun SPOTs while the graphical user
interface uses a base station.
B. Routing Table Structure
The backbone of any routing protocol is the routing table.
The table is responsible for remembering how to get a
message from the current node to the destination. The table
has an entry for each destination node. Each entry contains
all of the information needed about how to send a message
to the corresponding destination. For example, a node would
look up the entry for destination X to find out how to route a
message to X. Each entry has information for each neighbor
that the node can send a message to that will be able to
forward the message towards X. Recall that each neighbor
represents a potential path to the destination. In turn, each
path has information about the success rate and delay
expected when transmitting data across the path. A visual
representation of the layout of the routing table is shown in
Fig. 4.
Fig. 4. Illustration of the routing table. Nodes look up which neighbor
to forward a message to in order to reach a destination.
1-4244-2366-8/©2008 IEEE
C. Handling Swarm Messages
The most complicated part of the implementation was
writing the logic for each node to handle incoming swarm
messages. This portion was also implemented in the
simulation code. However, a real mastery and understanding
of the code was needed as opposed to a simple conversion
from C to Java. This section of the program did all of the
processing and work, and when the program did not work as
intended it was necessary to know how the entire protocol
operated in order to fix the problem. In addition, any
changes in the structure of the routing table or other
structures required wholesale updates of this section. There
was a strong desire to simply start from scratch instead of
attempting to understand all of the code, but in the end the
code was used with many modifications.
D. Application Layer Adaptations
Up to this point, all of the programming code was adapted
from Pedraza’s C code written for NS-2. After that was
translated, additional code had to be written to enable the
protocol to work on the Sun SPOTs. Rational swarm on the
Sun SPOTs is implemented in the highest application layer
of the OSI protocol model instead of the lower network
layer (please see [7] for more information on OSI). As such,
many modifications had to be made from the C code, a few
of which are very briefly discussed here.
Every Sun SPOT was given an application layer
identification number to use as its name. In a real system, a
processor would use either its IP address or MAC address as
identification. This change allows a user to easily identify
Sun SPOTs, which facilitates testing. However, it is
important to note that Sun SPOTs automatically use
standard IP headers when sending packets to determine the
source and destination of a packet. IP headers use IP
addresses to identify nodes, so it was necessary to create a
custom IP header that use the application layer ID number.
The true definition of rational swarm calls for messages to
only reach the network layer instead of the application layer.
Lower layer protocols transmit one packet at a time and
store other outgoing messages in a queue. However, in
rational swarm it is necessary to wait for path discovery to
complete before sending data because a node cannot send
data without a path. An application layer queue stored
messages waiting to be sent when a path was being built.
Similarly, an outbound queue stored packets while a node
waited for an ACK on a previous packet sent to a neighbor.
In addition, all timing used to determine path delay times in
rational swarm use built-in clocks found in the MAC layer.
However, this project uses a custom timer mechanism to
make the development simple and eliminate the need to
discover how the Sun SPOT built-in timers work.
In the simulation code, NS-2 simulated messages
traveling from one node to the next. In a real system,
messages actually have to be transmitted wirelessly to the
destination. Sun SPOTs come with a mechanism that allows
programs to transmit messages using broadcast (one source
to all neighbors) or unicast (one source to one neighbor).
Packets, which are comprised of a IP header, swarm header,
332
and data, had to be converted into a single byte array and
then sent to the Sun SPOT functions that transmit them.
E. Simulated Test Environment
As described in Section III, there is a probability that a
message will not successfully travel between two nodes due
to interference in the wireless channel or excessive load on
the receiver. In order to test how rational swarm reacts to
these and other exogenous variables, the chance of a failed
transmission is simulated. The user setting up or running the
system defines the chance a message will be dropped across
a link, and the receiving node randomly decides to ignore
messages based upon the probability. In terms of technical
implementation, each node stores a success rate number for
links between it and every other node. If a link does not
exist between two nodes, then the success rate is zero.
icons on the display representing each Sun SPOT and the
physical layout of the icons must match the Sun SPOTs.
When a message travels between two Sun SPOTs, a line
should move between the appropriate icons on the display.
The display panel begins by displaying an icon for each
Sun SPOT. The user may then click and drag the icons so
they match the physical layout of the SPOTs. A base station
Sun SPOT is connected to the computer and listens to the
messages of the system. When a message is heard, it is
drawn traveling between the corresponding two icons on the
screen. An image of the display panel is shown in Fig. 6.
F. Results
The project was allocated seven Sun SPOTs to test, which
was determined to be enough to show many of the
capabilities of rational swarm. Fig. 5. shows one
configuration of the seven nodes. The source node on the
left needs to send messages to the node on the far right.
There are two paths, so when one path deteriorates or breaks
the node at the fork can switch to the other path. If both
paths break, a route error message will be sent back to the
source.
Fig. 6. The GUI’s display panel.
Fig. 5. Test bed of Sun SPOTs running rational swarm.
V. GRAPHICAL USER INTERFACE
The test system consisted of seven small Sun SPOTs
running the rational swarm algorithm to communicate. Small
lights on each Sun SPOT were the only means of watching
the routing process. Although the system is impressive and
interesting to view, a better display had to be made to easily
reach a large audience. The next task was to create a
graphical user interface (GUI) that runs on a standard
computer that provides more information than blinking
lights and can easily be viewed by many people. The GUI
built for this project is made up of two parts: the display
panel and the control panel. It is based upon a GUI provided
by Evan Tschannen of at the University of Virginia used for
a similar purpose.
The purpose of the display panel of the GUI is to project
what is happening on the Sun SPOTs to a computer screen.
The rudimentary requirements are simple. There must be
1-4244-2366-8/©2008 IEEE
A meaningful presentation would allow the presenter to
change the state of the system to demonstrate how the
protocol reacts. The control panel allows a user to create
scenarios as the system runs. The control panel shows icons
for each node and can be arranged into the correct physical
layout. It initializes with predetermined links between nodes
that can communicate directly with each other, i.e. when the
probability of successful transmission between the nodes is
greater than zero. In addition, the links are color-coded to
represent the quality of the path. A link with a high success
rate is green, medium is yellow, and poor is red.
At the bottom of the panel is a form that allows the user
to change the success rate of a link. The user types in the
identification number of each node on either side of the link
and the link’s new success rate. When the Update Link
Quality button is pushed, the base station connected to the
computer will send a message to all of the Sun SPOTs to
update their link quality table. Links may deteriorate or
increase in reliability when the quality changes. Nodes may
become neighbors if the new quality is made positive, or a
link may break entirely if the quality is set to zero. Users
may easily simulate interference in an area or completely
change the layout of the system. The control panel is shown
in Figure 5.2.
333
[5]
[6]
[7]
Fig. 7. The GUI’s control panel.
VI. CONCLUSION
This project has shown rational swarm can work on real
devices, while Fernan Pedraza’s simulation shows that the
protocol has merit in certain situations and performs better
than other standard MANET protocols. The implementation
should be moved to a more scalable test bed where the
number of physical processors is not a constraint. After a
suitable platform is chose, the protocol should be optimized
to run on the network layer as designed. This will create a
very close relationship between rational swarm and the
platform, so the test system should be chosen wisely. In
addition, the graphical user interface should be improved to
easily allow extensive changes to the network topology and
to show state information for paths maintained by each
node.
ACKNOWLEDGMENT
Jonathan H. Bao thanks his technical advisor Barry
Horowitz for providing the motivation and resources to
complete this project. He also thanks graduate students
Fernan Pedraza and Evan Tschannen for providing
substantial amounts of programming code and expertise.
REFERENCES
[1]
Johnson, David B. “Routing in Ad Hoc Networks of Mobile Hosts.”
Proceedings of the Workshop on Mobile Computing Systems and
Applications, IEEE Computer Society. Dec 1994: 158-163
[2] Perkins, C. “RFC 3561: Ad hoc On-Demand Distance Vector
Routing.” Jul 2003. Internet Engineering Task Force (IETF). 9 Oct
2007. Available: http://www.ietf.org/rfc/rfc3561.txt
[3] Perkins, C.E.; Royer, E.M., "Ad-hoc on-demand distance vector
routing," Mobile Computing Systems and Applications, 1999.
Proceedings. WMCSA '99. Second IEEE Workshop on , vol., no.,
pp.90-100, 25-26 Feb 1999
[4] Johnson, David. “RFC 4728: The Dynamic Source Routing Protocol
(DSR) for Mobile Ad Hoc Networks for IPv4.” Feb 2007. Internet
Engineering Task Force (IETF). 9 Oct 2007. Available:
http://www.ietf.org/rfc/rfc4728.txt
1-4244-2366-8/©2008 IEEE
334
Sun Microsystems. Home of Project Sun SPOT. Available:
http://www.sunspotworld.com/. Accessed March 20, 2008.
De Nardis, L.; Di Benedetto, M.-G., "Overview of the IEEE
802.15.4/4a standards for low data rate Wireless Personal Data
Networks," Positioning, Navigation and
Communication, 2007. WPNC '07. 4th Workshop on , vol., no.,
pp.285-289, 22-22 March 2007
Zimmermann, Hubert. “OSI Reference Model – The ISO Model of
Architecture for Open Systems Interconnection.” IEEE Transactions
of Communications, Vol. COM-28, No. 4, April 1980.