Aqua-TUNE: A Testbed for Underwater Networks

Transcription

Aqua-TUNE: A Testbed for Underwater Networks
Aqua-TUNE: A Testbed for Underwater Networks
Zheng Peng, Son Le, Michael Zuba, Haining Mo, Yibo Zhu, Lina Pu, Jun Liu and Jun-Hong Cui
Department of Computer Science and Engineering, University of Connecticut, Storrs, Connecticut 06269
Email: {zhengpeng, sonle, michael.zuba, haining.mo, yibo.zhu, lina.pu, jul08003, jcui}@engr.uconn.edu
Abstract—In recent years, new challenges and emerging applications have inspired increasing research interests in the area of
underwater networks. However, field experiments are expensive
and not all the research work can be evaluated in real world
scenarios in a timely fashion. This motivates our interest on
developing an affordable, accessible and user friendly platform
for conducting field experiments. Aqua-TUNE, the Testbed for
Underwater NEtworks, is presented in this paper. It can be
used to experimentally evaluate the algorithms and protocols
developed for underwater networks in real world scenarios. Our
experience with the testbed shows that it could be a valuable tool
to encourage rapid progress in underwater networks.
I. I NTRODUCTION
Underwater networks are wireless communication systems
that are generally characterized by expensive equipment, high
mobillity rates, sparse deployment and various energy requirements [1]. The devices, which are often battery powered,
can consist of autonomous underwater vehicles (AUVs) like
vessles, sensors, network nodes and a variety of other devices
ranging from computational to communication purposes. The
fundamental differences between underwater networks and
terrestrial networks are within the communication channel and
signal characteristics. Unlike in ground-based networks, high
frequency electromagnetic waves do not work well in the water
due to high absorption. For this reason, acoustic communication becomes the most commonly used method. However, due
to the unique characteristics of acoustic channels, underwater
networks face challenges at almost every layer of the protocol
stack [2].
In the past few years, the area of underwater networks
has spurred a big wave of research efforts in both academia
and industry. Many algorithms and network protocols have
been introduced. However, a majority of the work remains
in the stage of computer simulation due to many technical
and non-technical issues and challenges. In order to effectively
evaluate the performance of underwater networks, experiments
are expected to be done in real world scenarios. Constructing
a user friendly infrastructure is also critical for those who
wish to efficiently develop, deploy and debug applications in
realistic underwater environments.
In this paper we will discuss our field testbed system, AquaTUNE, a Testbed for Underwater NEtworks, that is developed
for deployment and operation in lake based environments.
Our system consists of both hardware and software modules
that are easy to install and assemble while providing a lot of
freedom for developers and engineers.
The testbed has a set of ready-to-deploy network nodes and
a hybrid wireless network system to connect them together.
In terms of hardware, each network node consists of a surface platform, an electronic compartment and communication
devices. The surface platform includes a small kayak, an
anchor and a homemade system for easy deployment. The
electronic compartment hosts most of the electronic devices
such as a micro-controller, a radio frequency (RF) modem,
a GPS receiver and batteries. The communication devices
include an acoustic modem, a transducer and an antenna. The
network system is a hybrid of a multiple frequency shift keying
(MFSK) underwater acoustic network, a frequency hopping
spread spectrum (FHSS) network and a direct sequence spread
spectrum (DSSS) network. The underwater data communication is done via the underwater acoustic link while the abilities
of online remote control and monitoring are conveniently
provided by the other two networks. Additionally, depending
on the configurations and workload, the entire system can
operate from 70 hours to 7 days in a row without recharging
the batteries.
The software system is based on a Linux implementation
of Aqua-Net [3]. It is a generic architecture for underwater
sensor networks aiming at delivering a powerful networking
solution kit for underwater network researchers. It is designed
in a way that provides robustness for users and easiness for
protocol or application developers.
Various algorithms and protocols are constantly being developed in the laboratory environment and analysis often ends at
the simulation step. However, simulations can never fully consider the special characteristics of an environment, especially
the aquatic world. The development of an underwater network
testbed is a costly, time consuming, and a labor intensive
process. It is often the case that most researchers do not have
the resources to effectively develop their own field testbed. The
goal of Aqua-TUNE is to provide this affordable, accessible,
and standardized platform to bridge the gap between modeling
and simulation and the field experience.
The rest of the paper is organized as follows. Related
work in the development of underwater testbed systems is
introduced in Section II. The motivation of Aqua-TUNE, its
components, and its capabilities are presented in Section III,
Section IV and Section V, respectively. Preliminary experimental results are presented in Section VI. Conclusions are
drawn and future work is presented in Section VII.
II. R ELATED W ORK
There has been limited progress in developing underwater
network testbeds. Researchers that have been developing these
systems are mostly still in preliminary stages instead of a
final complete system. In this section we will introduce a few
testbed systems that we are aware of in the field.
Goodney et al. [4] have made some progress on developing a
flexible, configurable underwater sensing and communication
testbed in Marina del Rey, California. The current system consists of two prototype testbed nodes which are designed based
upon existing underwater modems developed by WHOI [5].
Future plans for this work are to address communication
limitations while creating a more flexible node design. This
includes developing a software-based acoustic signal generator
to support a wide array of signal processing algorithms and
communication protocols and to allow easy user integration
and testing of new algorithms.
Feng et al. [6] recently started work on an underwater
mobile sensing network (UMSN) testbed. This testbed consists
of a surface station laptop computer, three AUVs and an RF
modem-based communication system to mimic underwater
acoustic communication. The surface computer provides a
graphical user interface (GUI) for human operators to easily
and remotely control each AUV via a wireless local area
network (WLAN). However, the pitfall of this work is the
fact that no real acoustic communication is used; it is merely
simulated by RF modems.
B. Chen et al. [7] provide an out-of-water testbed that
emulates underwater acoustic communications using various
hardware modules. Their testbed consists of WHOI MicroModems, an audio interface to process audio signals, a gumstix
motherboard, and two desktop PCs. The main goal of this
testbed is to provide an emulator environment to evaluate
the performance of underwater vehicle formation and steering
algorithms.
Aqua-Lab [8] is an underwater acoustic sensor network
lab testbed developed by the Underwater Sensor Networks
(UWSN) lab at the University of Connecticut. The goal of
Aqua-Lab is to bridge the gap between real system implementation and modeling/simulation environments. The design of
Aqua-Lab is based around being able to appropriately mimic
real-world environments and hardware testing while providing
an easy method for researchers to implement and use their
own protocols and tests. A web-based GUI is also provided
for easy access and configuration. This testbed provides researchers the ability to test, evaluate, and compare various
network algorithms and protocols in a less-expensive lab based
environment while providing results that have been proven to
be consistent with real-world testing.
A good testbed system requires a good and user friendly
software developing platform. Aqua-Net [3] is an efficient,
extendable, user friendly, and upgradable architecture framework for underwater sensor networks. It provides a layered
structure while allowing for cross-layer optimization. This
layered structure approach allows for easy integration of
new solutions or protocols from multiple research groups or
industry companies. Additionally, the cross-layer design in
Aqua-Net is enabled by a translucent vertical layer that is
accessible for all protocols and applications. Aqua-Net has
proven itself to be a valuable networking solution kit that helps
to facilitate UWSN research and application development.
Our literature review suggests that developing underwater
testbeds is still in its infancy. Existing technology may not be
suitable to appropriately develop these underwater systems.
We hope to provide new insight and progression in the development process by introducing Aqua-TUNE, our underwater
lake testbed system.
III. M OTIVATIONS AND G OALS
Recent years have witnessed a rapid growth in the area
of underwater networks. Building a cheap and efficient field
testbed for underwater networks is imperative. This is due
to the the difficulties in accurately modeling the special
characteristics of the water environment and underwater networks in the lab. Without the help of field experiments, pure
theoretical analysis and simulation face limitations. Moreover,
new research topics are emerging from problems identified
during field experiment. A constraint posed by these problems
is that they can only be observed in real world environments.
Furthermore, in academic studies, there are inconsistencies in
the different assumptions that researchers make due to their
perceptions of the underwater environment. This makes it
difficult to fairly compare and evaluate the performance of
algorithms and protocols. This problem calls for the ability
to provide a standard field testbed platform to evaluate these
protocols fairly.
Unfortunately, much research work in this area is still done
in the lab and is rarely tested in the field. This is the result
of the high cost in conducting full scale field tests. With a
large scale network, node deployment and recovery can be
time consuming and labor intensive. The costs of renting or
using a boat for deployment is also expensive. These issues
provide motivation to develop an affordable, accessible and
convenient testbed for the research of underwater networks.
The purpose of Aqua-TUNE is to provide a standardized
platform for testing and to bridge the gap between modeling
and simulation and the real world field experience.
Our current network testbed is designed for research purposes. The major goal is to build a platform in a real
environment that can demonstrate the capacity of our underwater network. Our testbed design targets on low cost,
simple to build modules and parts that are largely available
and convenient to deploy. The testbed should be small for
easy transportation, assembly and deployment. Since network
experiments often involve a number of network nodes, each
individual node should be of low cost to fit into an average
budget. The components should also be easy to obtain for
quick replacement.
Since our lab does experiments frequently, we focused on
lakes and reservoir environments in our local area. Although
the shallow water adversely affects the acoustic communication, lakes are very accessible with no interruption from
maritime activity. The lakes are usually calm and provide a less
harsh environment, making it perfect for our water operations.
IV. T ESTBED OVERVIEW AND C OMPONENTS
Aqua-TUNE consists of a number of network nodes. Each
network node has a buoy, an electronic device compartment,
an acoustic modem, a RF modem with an antenna and a GPS
receiver. The surface buoy can be used to carry the electronic
system. This setup avoids the cost of waterproofing electronics
when we deploy the acoustic modem devices underwater.
The device compartment has a micro-controller which is used
for computation and decision making. It also hosts the RF
modem and antenna in order to monitor the system status
and perform remote control operations. The GPS receiver
is mainly used to provide the applications with geographic
information which could be helpful in some scenarios. The
acoustic modem and its transducer are submerged in the
water to conduct underwater communications. Fig 1 shows a
complete node of Aqua-TUNE deployed in Mansfield Hollow
Lake, Connecticut, USA. Each network node of Aqua-TUNE
costs less than 1,000 US dollars. In this section, we will
discuss the system components in details.
Another factor that affects design choice is how long the
system is supposed to be deployed in the field. For long
term operations, people typically select moored buoys which
are anchored at fix location. Some buoys are even equipped
with solar panels to power their electronic devices. Many of
these buoys also have special paint or coating that provide
chemical bonds with the buoy for high durability. Short term
deployments typically don’t need these sophisticated designs.
The ease of handling would be preferable in these cases
because it allows the system to be more quickly deployed or
re-deployed when needed.
We compared various buoys from different manufactures
and concluded that many do not meet our requirements as
described in Section III. The cost of these buoys were too
expensive or their size was too small. Additionally, many
of them take a long time to build. In the end, instead of
using expensive buoys, we decided to use small scale kayaks.
These kayaks can be purchased off the shelf and allow for
easy transportation. The particular model we chose is made
of plastic. This light-weight kayak can support up to 140 lbs
of equipment. It has plenty of open space that can be used
for storage of electronic devices. There are holes and hooks
on the sides of the kayak such that we can easily attach ropes
and an anchor to it. We can conveniently deploy the network
nodes by towing the kayaks to the locations of our choice. In
this way, we can further reduce costs.
B. Micro-controllers
Fig. 1.
A Testbed Node in Operation
A. Buoys
In order to design a testbed for field experiments, several
things need to be taken into consideration. The first is where
the testbed will be deployed. The location of deployment will
decide the size of each individual node in the testbed. Larger
buoys are more stable and better suit the open seas where the
wind and waves could be strong. However, they are not only
much more expensive to build but also more difficult to deploy
than smaller buoys. Smaller buoys are easy to handle, saving
costs on heavy duty lifting equipment and ship time. They are
a better choice for lake tests launched by a smaller group of
people.
One of the goals of our research is to build a smart
autonomous network system. Users only need to focus on
applications, and different network protocols can provide the
services needed by them. Each network node in the system
should be able to make decisions based on available information and its own capacity to achieve the desirable goals
defined by the researchers and developers. This is why microcontrollers are introduced into the testbed. They are the brains
in most of the decision making process. In order have a better
testbed, a better brain is preferable.
Underwater sensor network is a challenging area. Advanced
algorithms are proposed to reduce energy consumption but
require more computation power from processors and support
from advanced operating systems. When designing the testbed,
we try to keep these broader perspectives in mind and support
any potential application that could benefit by our design
choice. The micro-controller we used is based on Marvell
PXA270 with XScale microprocessor core. It is the fifth
generation of the ARM architecture. Our system board has
64 MB RAM, 16 MB flash memory and is running at 400
MHz main frequency. It is capable of doing computational
extensive tasks such as data encryption and decryption. With
relatively small form factor, the micro-controller offers a wide
range of functions including microSD, Bluetooth and 802.11g
wireless interfaces, USB, 10/100 Ethernet and RS232. As a
result, the testbed can host a variety of user applications. Our
measurements present that the peak power consumption is
about 1.5 W. We consider this to be affordable when the peak
power consumption of a typical acoustic modem can reach tens
of watts [9], [5]. With techniques such as frequency scaling
and duty cycle, this number can be further reduced to around
50 mW.
Our system is running Embedded Linux, which is the
operating system designed and optimized for devices that
have limited resources, such as battery life, computational
power and storage capacity. It is an open source platform
that could be customized by users to suit the need of a
specific application. Having an operating system can be costly.
However, we argue that the introduction of an operating system
can greatly reduce the overheads in research and development.
As a variant of Linux, embedded Linux provides similar, if not
the same, features and has abundant resources. Researchers do
not need to invent every wheel they need. Instead, there are a
lot of programming libraries and tools available to use right
out of the box. In short, with Embedded Linux, our testbed
becomes an advanced, customizable, developer friendly and
ever-developing platform that is ideal for developing underwater network applications.
C. Acoustic Modems
The current underwater communication method is mainly
acoustic communication. There are several commercial and
non-commercial acoustic modems available from different
manufactures or institutions [9], [10], [11], [12]. The de facto
hardware interface between the acoustic modem and the host
machine is an RS-232 serial port. With the same hardware
interface, different acoustic modems communicate with the
micro-controller in different ways. In the Aqua-Net network
architecture, different drivers could be developed for different
acoustic modems. The physical layer details are, by AquaNet design, transparent to various protocols such that network
protocol researchers do not need to understand the details of
the physical layer. On the other hand, some hardware specific
features are available to support cross-layer optimization for
better system performance.
For our testbed, we use the underwater acoustic modem
from a company located in Massachusetts, USA. This company has years of experience in acoustic communication and
their modems are used in worldwide subsea applications. Each
of the testbed nodes are equipped with an acoustic modem
which is a completely self contained 2000-meter depth rated
subsea modem with a built-in omnidirectional transducer. The
specifications show an acoustic bit rate up to 2, 400 bps using
multiple frequency shift keying (MFSK). Depending on the
channel condition, the communication range can reach 6 km
at some baud rates. In general, our experience shows that with
lower acoustic bit rates, the modem works better in adverse
channel conditions.
D. Radio Frequency Modems
Radio Frequency (RF) modem is a key component within
the testbed, which helps build a monitoring and remote control
subsystem and allows users to interact with the protocols
running on the micro-controllers conveniently.
1) RF Modem Selection: The RF link quality heavily
depends on the performances of the RF modems and the RF
antennas. In our testbed, we used a long range 900 MHz
industrial Ethernet RF modem. The first reason for choosing
this modem is that it works at 900 MHz, which is a stable
and free public frequency in the US. The second reason
is that it uses frequency hopping spread spectrum (FHSS)
modulation which is considered reliable. Another reason is
that this modem has a dependable built-in ethernet protocol
stack. This makes it possible to use a large number of existing
software or protocols such as SSH and FTP.
2) Antenna Selection: For antenna selection, We use Friis
Transmission Equation to estimate the appropriate antenna
gain we need in the field test.
2
λ
Pr
= Gt Gr
(1)
Pt
4πR
In Eq. 1, λ is the wave length, Pt is the transmission power
of the RF modem and Pr is its receive sensitivity. Then, given
the transmit and receive antenna gain, Gt and Gr , we can
calculate the transmission range R.
Fig. 2.
RF Modem Tests
According to our calculation, we picked a fiberglass omnidirectional wireless antenna with a 6 db gain. Theoretically,
it can reach a transmission range of 80 km. We tested it in
the town of Vernon, Connecticut, USA, as demonstrated in
Fig. 2, where the RF link is further challenged by obstacles
and interferences. Our test results showed that this antenna can
work reliably over 3.57 km while download speed can reach
100 KB/s and the packet loss rate was almost 0. Additionally,
in all the tests, power consumption was always stable at 0.96
W, which means that the batteries can support our RF modems
for almost a week without recharging. Though winds, hills and
radio interference are degrading its performance, it still offers
satisfactory communication range. Taking all the above factors
into consideration, the antenna we select should be reliable
enough for our lake experiments.
Wi-Fi
Router
RF Link
(900 MHZ)
Radio
Frequency
Antenna
RF Modem
(Subscriber)
E. Batteries
In the field experiments, all the electronic devices are
powered by batteries. If the micro-controllers are the brains
of the testbed, then the batteries are the heart of the system.
Careful study on the power consumptions of the testbed and
the provision of a good power supply solution are the keys to
successful field experiments.
We first measured the power consumption of the microcontroller. During the test, all peripheral devices, e.g. a
Ethernet card, are connected and a program is developed
to keep the micro-controller busy for testing purposes. Our
measurements indicate that the micro-controller’s maximal
power consumption is about 1.6 W. We also measured the
power consumption of the RF modem. As mentioned in a
previous section, at a distance of 3.57 km and a download
speed of 100 KB/s, the power consumption is about 0.96 W.
Among all electronic devices, the acoustic modem has the
highest power consumption. According to the user manual, the
peak sending power is 20 W, almost an order of magnitude
higher than the total of all other equipment. Since the modem
carries its own battery pack which is stated to provide weeks
of operating life time, we do not consider it when designing
the power supply solution.
In Aqua-TUNE, we use two sealed lead-acid rechargeable
batteries to power the whole system. Sealed lead-acid batteries
are popular because it has a mature and robust design. These
batteries can also work reliably in tough environments. This is
not the case for more expensive Lithium batteries that could
explode in some conditions. Sealed lead-acid batteries are
a dependable and low cost solution for our field testbed of
underwater networks. The total energy the two batteries can
offer is 184 WHr. This is enough for the whole system to run at
peak speed (i.e. 100% CPU usage) for 71 hours, almost three
days. Under normal system workload, the system can work
for 92 hours. We consider this to be sufficient for a lake test.
With some simple frequency scaling or duty cycle techniques,
the overall system life time can easily get much higher. Since
the kayak has plenty of space for electronic devices, we do
not see any limitation on doubling or tripling the number of
batteries on each network node. The power supply solution of
Aqua-TUNE can meet most of the experiment requirements
easily.
V. T ESTBED C APABILITIES
Aqua-TUNE provides various capabilities to the testbed
users. These capabilities, including networking modules, synchronization, localization, link control and power control, are
essential to our research. With all these capabilities, AquaTUNE becomes an ideal platform for conducting experiments
of underwater networks.
RF Modem
(Access Point)
Wi-Fi Link
(2.4 GHZ)
MicroController
Acoustic
Modem
Fig. 3.
Monitoring and Remote Control Subsystem
A. Monitoring and Remote Control
Via monitoring and remote control, users can monitor the
output of the running protocols in real time, change settings
such as protocol parameters, upload new versions of protocols
onto the micro-controllers and download log files with the
procedures and results of all the tests reported in details.
As shown in Fig. 3, the monitoring and remote control
subsystem is composed of two wireless networks, namely a 2.4
GHz direct sequence spread spectrum (DSSS) Wi-Fi wireless
network and a 900 MHz FHSS network. The former one is
used by experiment operators, while the latter one is used by
the network nodes. The Wi-Fi network consists of multiple
laptops serving as monitoring and remote control terminals
as well as a Wi-Fi wireless router. An RF modem with an
attached antenna, serves as an Access Point that is connected
to a Wi-Fi router via an ethernet port. All the other RF modems
function as subscribers, which are connected to the microcontrollers via ethernet ports. Similar to the Access Point, a
RF antenna is attached to each subscriber. All the RF modems
including the Access Point and the subscribers form a RF
wireless network. In this system, the Wi-Fi router and the
Access Point work as the corresponding gateway for each of
these two wireless networks and therefore all the nodes in
these two networks can talk to each other. In this way, the
terminal laptops can freely interact with the micro-controllers.
Compared to other systems, the biggest advantages of
our monitoring and remote control system is that multiple
laptops can talk to one micro-controllers at the same time
and that a single laptop can simultaneously communicate with
multiple micro-controllers. This feature is perfectly suitable for
real time program monitoring, control and even debugging.
Additionally, since the Wi-Fi network is already mature and
robust, as long as we can guarantee a stable and fast RF link,
the communication between laptops and micro-controllers can
be reliable and efficient.
The monitoring and remote control subsystem has been
proven to be working reliably and efficiently in our field test
and has provided great support for our program monitoring,
online debugging and data analysis.
B. Network Modules
The unique characteristics of underwater sensor networks
such as long propagation delay, limited bandwidth and high
error probability have posed significant challenges in designing
a reliable and efficient network structure. First, how to allow
multiple devices to effectively and fairly share a common
channel is a big issue. Schedule based methods may not work
well due to the high uncertainty in the underwater environment. Carrier sensing based approaches also lack efficiency
since propagation delay can be close to or even larger than
the packet duration in underwater networks. Second, routing
methods must adapt swiftly to the dynamic topology changes
in the network and cannot incur too much communication
overhead. Finally, the error prone underwater acoustic channel
makes reliable data transfer a desirable feature in a lot of
application scenarios.
To address the above challenges, we have implemented
some compelling protocols at each layer of the underwater
sensor networks. For the Medium Access Control (MAC)
layer, we implemented handshake based Slotted-FAMA [13]
and random access based UW-Aloha [3], which is an Alohalike approach. Both of these two approaches are specifically
designed for the underwater environment and have taken
underwater communication characteristics into consideration.
On the routing layer, we implemented static routing and a
distance vector based dynamic routing method, which can
quickly respond to the topology changes in the network.
We have also implemented a reliable data transfer scheme
UW-RDT using sliding window and selective repeat on the
transport layer, upon which we further built a reliable file
transfer program for the application layer.
All the protocols mentioned above are implemented using
Aqua-Net [3], a layered underwater network protocol stack
including physical layer, MAC layer, routing layer, transport
layer and application layer. Aqua-Net provides a set of sockets
based user-friendly APIs serving as programming interfaces.
Using Aqua-Net, a protocol developer can easily and seamlessly plug in one protocol running as a single layer or
multiple protocols running on different layers. In this way, one
can efficiently test the performance of an individual protocol
or a combination of multiple protocols. Besides, Aqua-Net
provides APIs or configuration interfaces which allows users
to dynamically configure network topology and transmission
power on the fly. Furthermore, Aqua-Net has implemented
drivers for a couple of popular acoustic modems and provides
well formatted APIs, which saves developers from the trouble
of digging into hardware details on the physical layer.
C. Localization
Our experience shows that knowing where our network
nodes are is important. In some extreme weather, when
deployed in the sea, a buoy could drift miles away from
the original location. If the buoy can provide its geographic
location, it would be much easier to recover the buoy. Location
information is also requested by a range of applications, such
as estuary monitoring and pollutant tracking. For underwater
networks, geographic routing protocols, such as VBVA [14],
require location information to efficiently route the network
traffic to the destination for multi-hop networks.
Our testbed provides geographic information using the
Global Positioning System (GPS). Each of the network nodes
connects to a GPS receiver via a USB connection. The GPS
receiver is small, cheap, USB powered and easily replaceable. We have made a customized USB driver for the GPS
receiver for our testbed system. By using the GPS receiver,
an open source software GPSd [15] and a software module
we developed, the geographic information can be shared by
all applications. With a more advanced GPS receiver, such as
a Garmin 18x LVC [16], not only location information can
be obtained, but also the system time of our network nodes,
which can also be synchronized to the satellites to obtain better
accuracy.
D. Synchronization
Time synchronization is another important service which
many applications benefit from or require. For example, in
order to calculate the end to end delay of a particular protocol
for underwater networks, the system time on both the source
and the destination should be synchronized. Moreover, many
localization and MAC protocols , such as [17], [13] assume
the availability of the time synchronization service.
In our testbed, we provide different methods of synchronization services. Since we have constructed an 802.11 wireless
network for our testbed, the most straight forward and accurate way is to use the Network Time Protocol (NTP) [18].
Nowadays, most of our computers are synchronized to Internet
time servers. We can arbitrarily elect any computer that is
connected to the testbed wireless network to be the time server.
All network nodes in our testbed can then adjust their time
periodically according to the time server via NTP.
The second method is to utilize the GPS. Most GPS
receivers use NMEA (National Marine Electronics Association) sentences which also report time information. Many
simplified commercial GPS receivers can only reach second
level accuracy. However, with some GPS models described in
later part of Section V-C, millisecond level accuracy can also
be achieved.
When the previous two methods fail, it does not mean
our testbed loses time synchronization. We have developed
a software module to provide synchronization service in this
situation. A random network node will be selected as the time
server and all other nodes will adjust their time according
to the server time. However, if the time on the server is not
accurate, the time of the whole testbed will suffer from the
same error. Fortunately, with the current electrical system,
the time offset and skew is small. In our experiments, we
also find the time to be accurate enough for our performance
measurements, e.g. calculating end to end delay.
E. Link Control
In field experiments, it is usually desirable to test a protocol
in multiple topologies with a single deployment. Otherwise,
one has to redeploy the network nodes which is often costly
and involves a lot of labor work. According to our experience,
redeploying a network of 6 nodes in open sea may take half a
day to complete because of the time spent on lifting the nodes
off the water, navigating to the new positions and putting them
back to the water. In other words, this choice should only be
consider when there are sufficient resources (i.e. time, man
and money).
To better understand how the link control works, one
needs to differentiate the physical topology and the network
topology. The physical topology is determined by the actual
deployment, which is not easy to chance due to the reasons
just mentioned. Once the deployment is finished and the transmitting power of the acoustic modem is decided, the actual
network topology is fixed. However, with limited resources,
it is often desirable to have multiple network topology for
protocol tests. We then come up with the idea of emulating
network topologies by a link control module.
Taking this issue into account, an essential part of AquaTUNE is the capability of configuring various topologies
without redeployment. Different network topologies can be
emulated by our link control module. In our testbed, this
module is implemented by having a component in the physical
layer, which takes in a given topology according to configurations and filters packets based on that topology. This
component also provides APIs such that users can change the
topology on the fly, which makes it possible to emulating link
failure.
An important point to make regarding the link control
module is that it is different from a static routing protocol. It
works more like a firewall by placing a packet filter between
the acoustic modem and Aqua-Net. The packet filter on a node
is given the list of direct neighbors that it is configured to
communicate with by the people who design the experiments.
It then checks every incoming packets and only pass the ones
that are from a neighbor in the list; otherwise, it will drop the
packets. This means that the packet filter is not part of AquaNet and only serves experiments because it knows about the
topology beforehand.
its power level and triggers its neighbor in the spanning tree
one after another. When a node has finished this process, it
triggered its parent node to continue with another neighbor.
A node chooses its power level in a binary search principle.
The available power levels are divided into halves, with the
middle power level as the pivot. The node first uses the middle
power level and sends probing packets to neighbor nodes. If
all these nodes can be reached, this node will try finding a
lower power level in the lower half. Otherwise, it tries with
the upper half of power levels. In this way, a node needs at
most dlog2 ne tries to determine the appropriate power level,
where n is the number of power levels.
VI. P RELIMINARY E XPERIMENTS AND R ESULTS
In a recent field experiment, we deployed four nodes in the
Mansfield Hollow Lake, Connecticut, USA. Fig. 4 illustrates
the actual location of the network nodes based on the GPS
information collected during the experiment. The distances
from node 5 to node 2, 3, 6 are 198, 169 and 356 meters
respectively. As a case study, we will present the results of
UW-Aloha, Slotted FAMA and a dynamic routing protocol
we have implemented.
In all these tests, a Poisson traffic generator ran at the application layer which sent out data packets in such a way that the
inter-departure time between two consecutive packets follows
the Poisson distribution. The parameter of the distribution (λ)
is called the sending rate of the data generator.
F. Power Control
Along with the above feature, the testbed also includes a
module which can choose the optimal transmitting power for
each node based on a given topology. This module is needed
to minimize power consumption and collisions in the network.
For example, if a node is configured to talk with its two nearest
neighbors, it may not need to use the highest power level.
In this way, it can prevent the acoustic signal from reaching
undesired nodes and causing collisions.
An important issue relating to this module is to prevent
collisions introduced by this module because probing packets
need to travel among network nodes to determine the appropriate power level. In the power control module, this issue is
dealt with by a classical term: spanning tree. First, each node
constructs a spanning tree of the given topology whose root is
always the node with the smallest ID. This node then selects
Fig. 4.
Field Test Deployment
A. UW-Aloha and Slotted FAMA
UW-Aloha was tested with both static routing and dynamic
routing in the network layer. Two tests were conducted with
static routing, in which the Poisson traffic generator sent out
data at 0.1 and 0.2 packets/s, respectively. Three nodes, 3, 5
and 6, were involved in these tests, in which the latter two
nodes were configured as traffic sources sending data to the
remaining one. In the test with dynamic routing, four nodes 2,
3, 5 and 6 were involved, in which data was sent from node
2 to node 3 at 0.05 packets/s and node 5 and 6 served as the
relays.
It is clear from Fig. 5 that the throughput of UW-Aloha with
dynamic routing is, in general, lower than with static routing.
This is because part of the bandwidth must be allocated to
routing packets. When the sending rate is high, it is likely
that data packets collide with routing packets or with one
another, as a result, negatively affecting the performance of
UW-Aloha. However, also from Fig. 5, we can observe that
a higher sending rate can improve the performance of UWAloha. Nevertheless, since acoustic modems cannot send data
arbitrarily fast and higher sending rate causes more collisions,
the throughput of UW-Aloha is actually bounded.
Slotted FAMA was tested with static routing in a similar
setting. Two 40-minute long tests were carried out with the
sending rate of 0.1 and 0.2 packets/s, respectively. The results
are also shown in Fig. 5.
600
UW-Aloha+dynamic
Slotted FAMA+static
Slotted FAMA+static
UW-Aloha+static
UW-Aloha+static
Throughput (bps)
500
routing
routing
routing
routing
routing
(λ=0.05pkt/s)
(λ=0.10pkt/s)
(λ=0.20pkt/s)
(λ=0.10pkt/s)
(λ=0.20pkt/s)
400
300
200
100
0
0
200
Fig. 5.
400
600
800
1000
1200
Experiment time (seconds)
1400
1600
Throughput of Different Protocols
From Fig. 5, one can obverve that the throughputs yielded
by two different sending rates are very close. Indeed, these
sending rates far exceeds the capacity of the acoustic modem,
and therefore many packets are queued in the MAC layer. In
other words, the MAC layer is always working with a nonempty packet queue.
In addition, Fig. 5 showed that the throughput in the first few
minutes was very high. This fact is rooted from our selection
of time point 0 as the time that the first packets was received.
As more data was received, the effect of this choice becomes
faded, the throughput converges to a constant value.
B. Dynamic Routing
A dynamic routing protocol was also implemented and
tested on the testbed. As shown in Fig. 4, four nodes are
deployed in the lake. They are configured to form a diamondshaped topology. In this two-hop network, node 2 is elected
to be the data source and node 3 is the destination node. We
assume that the obstacles between node 2 and node 3 block the
signals such that they can not reach each other directly. In this
case, intermediate nodes 5 and 6 served as relays forwarding
packets to their final destination. Two possible routes from the
sender to the receiver are 2 - 6 - 3 and 2 - 5 - 3. When the
network faces unpredictable failures, e.g. either node 5 or 6
stops working, the dynamic routing protocol will automatically
adapt to this change by delivering data packets through the
alternative route.
A node using dynamic routing periodically broadcasts its
routing table to neighbors to inform that it is still alive. In our
experiment, this period, called update period, was 10 minutes
long.
The test for dynamic routing ran for 30 minutes and the
sending rate was 0.05 packets/s. The result showed that it
took 134 seconds for all the routing tables to get stable.
Additionally, at this sending rate, totally 62 routing packets
was transmitted to maintain the routing tables of all network
nodes. There are 65 packets can be transferred successfully
from node 2 to node 3. On average, each node needs 16
routing packets to detect the routes through the network. Our
experience shows that this sending rate is not high especially
for a two-hop network; in fact, appropriate higher sending rate
will reduce the number of routing packets needed per each data
packet.
In the middle of the test, we turned off one of the relay
nodes to test if the other route can be detected. Since in our
deployment node 2 is slightly closer to node 6 than node 5, it
selected node 6 as the next hop to node 3, the destination node.
We deliberately disabled node 6 to break this route. Node 2
then has to find out another way to reach node 6. In this
experiment, it took 98 seconds for node 2 to find the alternative
route. Only a few packets are lost due to the “failure” of node
6 and therefore the overall performance of the network is not
affected much, as shown in Fig. 5. The length of the routing
re-establish time depends on the update rate of the dynamic
routing protocol. When the update rate is too high, routing
packets dominate network traffic, although it provides more
timely updates of the network dynamics. This fact poses a
question on choosing the appropriate update period. Generally,
a more dynamic environment needs a shorter update period.
VII. F UTURE W ORK AND C ONCLUSIONS
In this paper, Aqua-TUNE, a field testbed for underwater
sensor networks, is presented. The testbed has a network of
acoustically connected nodes. Each node contains a floating
platform for electronic devices, an acoustic modem, a RF
based monitor and remote control system and the software
platform that accommodates the protocols building an underwater network. Aqua-TUNE offers a variety of services
that open many potentials to the researchers and application
developers. The testbed is designed to be affordable, accessible
and easy to handle. Aqua-TUNE can be used to experimentally
evaluate algorithms and protocols designed for underwater
networks in real world scenarios. It will be a valuable tool
for future advances of underwater network research.
While working with the University of Connecticut’s Marine
Science Department, we will plan to set up a testbed in Long
Island Sound, an estuary of the Atlantic Ocean between the
state of Connecticut and Long Island. This will present a
challenge as there is much more maritime activity in this
area and the underwater acoustic channel could change drastically. The goal will be to bring Aqua-TUNE into a tougher
environment and observe if the current system is robust
enough to handle the new challenges. We want to test our
algorithms and protocols for underwater networks and evaluate
their performance in the sea. During this process, it is also
possible to identify new problems that are worth studying. The
basic design of Aqua-TUNE will not be changed. Therefore,
testbed users do not have to change their protocols from the
lake testbed environment. In other words, the same software
developed by the researchers can be used in the new platform
without any modification. We will focus on replacing the
current kayaks with bigger and more robust buoys, load the
system with more batteries for longer system life time and
consider waterproofing alternatives for the electronic device
compartment. The enhanced Aqua-TUNE will not only benefit
the research of underwater networks but also help marine
scientists in various applications.
ACKNOWLEDGMENT
This work is supported in part by the US National Science
Foundation under CAREER Grant No. 0644190, Grant No.
0709005, Grant No. 0721834, Grant No. 0821597, Grant No.
1018422 and the US Office of Navy Research under YIP Grant
No. N000140810864.
R EFERENCES
[1] J. Partan, J. Kurose, and B. N. Levine, “A Survey of Practical Issues
in Underwater Networks,” in Proceedings of the 1st ACM international
workshop on Underwater networks, ser. WUWNet’06, 2006, pp. 11–24.
[2] J.-H. Cui, J. Kong, M. Gerla, and S. Zhou, “Challenges: Building
Scalable Mobile Underwater Wireless Sensor Networks for Aquatic
Applications,” IEEE Network, vol. 20, no. 3, pp. 12–18, 2006.
[3] Z. Peng, Z. Zhou, J.-H. Cui, and Z. Shi, “Aqua-Net: an
Underwater Sensor Network Architecture: Design, Implementation,
and Initial Testing,” in IEEE/MTS OCEANS’09, Biloxi, Mississippi,
2009. [Online]. Available: http://ubinet.engr.uconn.edu/zhengpeng/
publications/PID975859.pdf
[4] A. Goodney, Y. H. Cho, J. Heidemann, and J. Wroclawski, “An Underwater Communication and Sensing Testbed in Marina Del Rey,” in Fifth
ACM International Workshop on UnderWater Networks (WUWNet),
Woods Hole, Massachusetts, USA, 2010.
[5] WHOI, “Micro-modem Specifications,” 2009. [Online]. Available:
http://acomms.whoi.edu/umodem/
[6] Z. Feng, G. Shang, and L. Lian, “A Low-cost Testbed of Underwater
Mobile Sensing Network,” in OCEANS 2010 IEEE - Sydney, 2010.
[7] B. Chen and D. Pompili, “A Testbed for Performance Evaluation
of Underwater,” in IEEE SECON, 2010. [Online]. Available: http:
//ieeexplore.ieee.org/stamp/stamp.jsp?tp=&arnumber=5508226
[8] Z. Peng, J.-H. Cui, B. Wang, K. Ball, and L. Freitag, “An Underwater
Sensor Network Testbed: Design, Implementation, and Measurement,” in
In Proceedings of Second ACM International Workshop on UnderWater
Networks (WUWNet’07), Montreal, Canada, 2007. [Online]. Available:
http://wuwnet07.engr.uconn.edu/papers/p65.pdf
[9] Teledyne-Benthos,
“ACOUSTIC
MODEMS,”
1999.
[Online].
Available:
http://www.benthos.com/
acoustic-telesonar-modem-product-comparison.asp
[10] LinkQuest, “SoundLink High Speed Acoustic Modems,” 1998. [Online].
Available: http://www.link-quest.com/
[11] L. Freitag, M. Grund, S. Singh, J. Partan, P. Koski, and K. Ball, “The
WHOI Micro-Modem: An Acoustic Communications and Navigation
System for Multiple Platforms,” in IEEE Oceans Conference,
Washington DC, 2005, pp. 1086 – 1092. [Online]. Available:
http://www.cs.umass.edu/∼partan/papers/Micromodem 2005.pdf
[12] H. Yan, S. Zhou, Z. Shi, and B. Li, “A DSP Implementation of OFDM
Acoustic Modem,” in The ACM International Workshop on UnderWater
Networks (WUWNet), 2007.
[13] M. Molins and M. Stojanovic, “Slotted FAMA: a MAC Protocol
for Underwater Acoustic Networks,” in IEEE OCEANS’06, Sigapore,
2006, pp. 1–7. [Online]. Available: http://citeseerx.ist.psu.edu/viewdoc/
download?doi=10.1.1.120.677&rep=rep1&type=pdf
[14] P. Xie, Z. Zhou, Z. Peng, J.-H. Cui, and Z. Shi, “Void Avoidance
in Three-Dimensional Mobile Underwater Sensor Networks,” in
Proceedings of the 4th International Conference on Wireless
Algorithms, Systems, and Applications, ser. WASA 0́9. Berlin,
Heidelberg: Springer-Verlag, 2009, pp. 305–314. [Online]. Available:
http://ubinet.engr.uconn.edu/mediawiki/images/9/99/Voidance Avoid
in Three Dimensional Mobile Underwater Sensor Networks.pdf
[15] R. Treffkorn, “GPSd – a GPS Service Daemon,” 1995. [Online].
Available: http://gpsd.berlios.de
[16] Garmin, “GPS 18x TECHNICAL SPECIFICATIONS,” 2008.
[Online].
Available:
http://www8.garmin.com/manuals/GPS18x
TechnicalSpecifications.pdf
[17] Z. Zhou, Z. Peng, J.-H. Cui, Z. Shi, and A. C. Bagtzoglou,
“Scalable Localization with Mobility Prediction for Underwater Sensor
Network,” IEEE Transactions on Mobile Computing, vol. 10, no. 3,
pp. 335–348, 2011. [Online]. Available: http://ubinet.engr.uconn.edu/
zhengpeng/publications/TMC-2008-10-0432-2.pdf
[18] D. L. Mills, “Internet Time Synchronization: the Network Time
Protocol,” IEEE Transactions on Communications, vol. 39, no. 10,
pp. 1482–1493, 1991. [Online]. Available: http://www.eecis.udel.edu/
∼mills/database/papers/trans.pdf