Field Test Experience of an Underwater Wireless

Network in the Atlantic Ocean

Zheng Peng*, Son Le*, Michael Zuba*, Haining Mo*, Hao Zhout, Jun-Hong Cui*, Shengli Zhout,
Zaihan Jiang+, Jeffrey A. SchindaU+

*Department of Computer Science and Engineering, University of Connecticut, Storrs, CT, USA
t Department of Electrical and Computer Engineering, University of Connecticut, Storrs, CT, USA
+U.S. Naval Research Lab, Washington D.C., USA

Abstract-Underwater Wireless Networks (UWNs) have gained

significant attention in recent years given their ability to expand
underwater monitoring and detection applications. In this paper,

the underwater communication instrument (i.e. a Teledyne

Benthos underwater acoustic modem [6]).

we share our experience from a recent field experiment in the

Atlantic Ocean, in which we have deployed an 11 node UWN. We
discuss the system architecture, both hardware and software, and
evaluate two new network protocols and one existing network
protocol for real-world performance. Additionally, we provide
insight on how the physical environment and surroundings
impact the performance of the networked system. This work
will share our practical issues in real systems and inspire new
advances in the area of UWN research.

I.

IN T RO D UCTION

An underwater wireless network (UWN) is a wireless com

munication system that can facilitate a range of underwater
applications such as environmental monitoring, oceanographic
data collecting, marine surveillance and pollution detection
[1]-[4]. However, due to the unique characteristics of the en
vironment, UWNs face challenges in almost every component
of the system [5].
Despite a big wave of research thrusts in recent years for
UWNs in both academia and industry, a majority of the work
remains in the stage of computer simulations due to many
technical and non-technical issues and challenges. Very limited
empirical and experimental efforts in real world scenarios with
practical equipment can be found in the current literature on
UWNs.
In the Underwater Sensor Network (UWSN) Lab at the
University of Connecticut (UConn), we focus on the research
of fundamental issues in UWNs, not only by the means of
theoretical analysis but also by real implementations and field
experiments. Collaborating with the U.S. Naval Research Lab
(NRL), we have conducted several sea tests in the past 3 years.
In a recent sea test in September of 2012, we spent 7 days
and deployed an underwater wireless network on the Atlantic
Ocean, as shown in Fig. l. Each network node consists
of a surface component and an underwater component. The
surface component has a buoy to carry a micro-controller,
an RF modem, an antenna, a GPS unit and a battery pack.
The RF modem is used for remote monitoring and control,
while the GPS facilitates localization and synchronization
for the nodes. The node's underwater component is mainly
the mooring system (i.e. anchor and sub-surface float) and

978-1-4799-0002-2/13/$31.00 2013 IEEE

Fig. l.

Deployment area

On the software side, we use Aqua-Net [7] as the soft

ware platform to implement network protocols designed for
underwater networks. This field experiment has a focus on
the performance of various medium access control (MAC)
protocols. Three MAC protocols are implemented and tested
during the trip. Each protocol represents a distinct type of
MAC protocol, including random access based, handshaking
based and scheduling based approaches.
In the experiment, we measured the network performance
in terms of end-to-end throughput, packet loss ratio and
delay. Based on our data analysis, besides a much higher
loss rate than that in typical terrestrial wireless networks,
the underwater wireless network demonstrates significant link
asymmetry. In the sea test, we have also observed temporal and
spatial dynamics of the underwater wireless channel. More
over, we have learned from our first hand experience that the
underwater communication range is greatly affected by many
factors, including geometry, packet length, modulation scheme
and transmission power. In other words, channel dynamics

significantly affect the network topology and performance.

These findings will pose new challenges on network protocol
designs.
The goals of this paper are threefold: 1) to document and
summarize our field experiment; 2) to share our experience and
findings; 3) to inspire new research to address some issues
we identified from the sea tests. The rest of the paper is
organized as follows. In the next section, we briefly introduce
related work of underwater medium access control and field
testbeds. We then present the system hardware and software
in Section III and Section IV, respectively. In Section V, we
provide some statistics of the experiment and describe the
deployment procedure. Experiment results are elaborated in
Section VI, followed by discussions in Section VII. Finally,
we conclude in Section VIII.
II.

REL ATED

WORK

A. Scheduling Based MAC

There have been a number of scheduling based MAC

protocols for underwater acoustic networks. R-MAC [8] is
one such protocol which requires a node to make a channel
reservation with the receiver before data transmission. The
issue with this protocol is schedule mismatch: if a node is
not aware of its neighbors' reception schedule, it may send
reservations while the channel is occupied by others, which in
turn, results in interference. From this point of view, slotted
FAMA [9] can also be considered as a reservation based
protocol. ST-MAC [10] is based on a scheduling scheme, in
which signals from different sources do not arrive at a receiver
at the same time. This way, the performance is improved by
avoiding collisions and allowing parallel transmissions. ST
MAC is a slot-based protocol, and slots are assigned with a
graph coloring algorithm. Guan et al. [11] propose a similar
idea for one hop networks, but their protocol is not slot-based.
Both of these protocols require global topology information,
and thus are hard to implement in practice.
Pipelined Transmission MAC (PTMAC) [12] is specifically
designed for string networks. Its operations are also slot based,
but unlike Slotted FAMA, it addresses the schedule mismatch
by assigning each node with a sending token. A node sends
data in time slots that matches its sending token, and multiple
nodes which do not interfere with each other, are allowed to
send in the same slot. Moreover, after the sending scheduling
is established, for a particular packet, one does not need extra
control messages. However, a node needs to wait for two time
slots before it can occupy the channel again.
B. Handshaking Based MAC

In coordination based MAC protocols, different methods

have been explored to compete for the channel and establish
the connection. In [9], the authors used RTS/CTS based hand
shaking to compete for the communication channel. In [13],
the authors proposed an improved handshaking mechanism.
The proposed APCAP protocol carefully delays transmissions
of CTS and data packets and utilizes the propagation delay
gap. By doing this, it is able to improve the overall data

transmission efficiency. Besides the conventional handshaking

mechanism, the authors in [14] used a tone-based mechanism
for channel contention among multiple nodes. When a node is
ready for packet transmission, a tone signal is sent out in order
to detect and count the contenders within its communication
range.
Only handshaking itself sometimes is insufficient to com
pletely eliminate collisions [15]. Therefore other mechanisms
have been explored to avoid collisions and improve data trans
mission efficiency in underwater networks. The authors in [9]
pointed out that by time slotting, collision avoidance can work
with handshaking to guarantee zero collision. Additionally,
a packet train mechanism was used to reduce handshaking
overhead and improve data transmission throughput. In [14],
the authors employed a random back-off scheme to reduce
collision and improve fairness among multiple nodes within a
network. Through extensive analysis and simulations, these
aforementioned schemes have been proved to significantly
improve the performance of underwater MAC protocols.
C.

Previous Field Test Experiences

As researchers increasingly draw attentions to the area of

underwater wireless networks, a number of testbeds has been
introduced. Peng et al. proposed a lab testbed called Aqua
Lab [16] in 2007. Chen et al. introduced a lab testbed [17]
for underwater gliders in 2010. In the same year, a near-shore
testbed [4] that had remote access was developed in Marina
del Rey, California. Aqua-TUNE [18], a lake testbed, was later
proposed for researchers to conduct short-term underwater
network experiments. Also in 2010, a low cost testbed of
underwater mobile sensing network was developed in [19].
In 2012, UW-Buffalo [20], a lab testbed, was introduced to
the research community to enable experimental evaluation of
underwater communications and network protocols. Another
lake testbed for underwater communication was developed by
Alves et al. [21]. It was deployed with five nodes in a harbor
of the Gulf of La Spezia. Recently, Ocean-TUNE [22], a
long-term sea testbed system for underwater wireless networks
is being constructed at four geographic locations across the
United States.
Despite high costs associated with field experiments, there
have been significant efforts in conducting acoustic communi
cation and network tests. Among these efforts, Seaweb from
the U.S. Navy is probably the pathbreaker with the first
deployment in 1998 [23], [24]. Seaweb provides a compre
hensive solution for underwater networking in terms of both
hardware and software. Recent deployments of Seaweb have
demonstrated its interoperability with gliders and submarines
in [25]. Besides Seaweb, Telesonar testbed [26] targeted
to help underwater data acquisition and modem design. A
one-day sea trial was conducted in San Diego Bay on June
14, 1998. In 1999, Woods Hole Oceanographic Institution
(W HOI) did an experiment of acoustic communication with a
REMUS AUV near Gulfport, Mississippi, in order to study the
reliability and throughput in very shallow water [27]. WHOI
is now developing an underwater acoustic network testbed to

provide an infrastructure for evaluating the performance of

underwater networks [28]. In 2012, The UWSN Group from
the University of Rome La Sapienza implemented a protocol
stack called SUNSET [29] based on NS-2, which permits
simulation code to run in real-life testing. Toso et al. then
launched an experiment using SUNSET for dynamic source
routing with 6 nodes [30] in a recent lake test. In the same
year, Caiti et al. reported experiment results from their 2011's
sea trial in Trondheim, Norway [31] which ran the TCPIIP
stack on top of acoustic modems.
Among all these field test efforts, our 2012's experiment
in the Atlantic Ocean was different in several ways. Except
for Seaweb, our test had more network nodes and longer
deployment time than others. Compared with Seaweb, our test
features the state of art in terms of both hardware and software,
as will be discussed in details in later sections.
III.

Fig. 2.

Internal view of electronics compartment

SYSTEM HARDWARE

The buoy system for our hardware can be seen in Fig. 8.

Except for the acoustic modem, all other devices are placed
inside a yellow water-tight Pelican case on top of the buoy,
which can be seen in Fig. 2. Inside the case, there are a micro
computer, an RF modem, an RS-422 to RS-232 converter, a
GPS receiver, a power divider circuit and an attached series
of lithium batteries.
We have customized the Pelican case to allow for two
external connections. The first one is for the RF modem
antenna, which is placed on top of the surface buoy, and
the second one is for the attached acoustic modem which is
submerged under the water. In the following subsections we
will expand upon the included hardware.
1) Micro-Computer: The micro-computer is the heart of
each network node, connecting the various devices and hosting
the networking protocol stack. For this test, we use the Verdex
XM board from Gumstix. The board is based on a Marvel
PXA270 microprocessor running at 400 MHz, with 64 MB
RAM, which is sufficient for the tested protocols. All our
software packages, including the operating system are loaded
on a 2 GB SD card.
2) RF Modem: Network nodes are controlled and moni
tored from our boat through radio links. We equip each buoy
with a Nano n920s-ENC modem from Microhard Systems Inc.
There is also an RF modem on the boat to communicate with
those on the buoys in a point-to-point fashion, which means
that at most one node can be controlled from the boat at a
time. Although inconvenient, this is the best option we had
at the time of experiment for there was no cellular coverage
over the test site. The modem on a buoy is connected to the
micro-computer through a USB port.
3) Acoustic Modem: Each of our buoys is equipped with a
medium frequency ATM-885 acoustic modem from Benthos.
The modem is powered with its internal battery, so if the
battery is depleted, we have to recover the buoy to replace
it. From the user manual, the Benthos modem can transmit
data at up to 2400 bps and at a maximum communication
range of 6 km. However, in practice, the effective values are

determined by the channel conditions and are usually much

lower than these ideal ones. The acoustic modem is connected
to an RS-232 port on the micro-computer through a converter.
4) Miscellaneous Devices: On this each buoy, we also have
some other supporting, yet important, devices:
A Garmin GPS used to track the position of each buoy
and to synchronize the time on the micro-computer
because the Verdex XM board does not have a real-time
clock. When the board is restarted, its time is reset.
An RS-422 to RS-232 converter lying in between the
micro-computer and the acoustic modem to accomodate
the modem cable, which was up to 100 m in length.

Three lithium batteries which can power the micro

computer and peripherals for at least 3 days, depending
on the system workload.
A custom power divider circuit which powers all devices.
Fig. 3 provides an interface and connection diagram for all
of the devices. The yellow square represents the electronics
compartment and everything is contained in it except for two
connectors on top of the box which go to the RF antenna and
acoustic modem.
RF Antenna

Fig. 3.

Acoustic Modem

Hardware interface diagram

IV. SYSTEM SO FTWARE

This section elaborates on the software used in the ex
periment, including data link layer protocols and a network

Fig. 4.

An example string network

protocol stack designed for underwater networks.

A. UW-Aloha

UW-Aloha is based on the classic Aloha protocol, with

new features that are needed for underwater acoustic chan
nels, specifically, effective back-off schemes and an automatic
repeat-request (ARQ) method.
Traditional, or pure, Aloha works as follows: if any node
has a packet to send, "just do it"; if the packet suffers from
collisions, the sender tries later. It, however, does not address
a practical issue in underwater wireless networks: how to
detect collisions? It also has the tendency of overwhelming
underlying physical layer, causing performance loss. This is
because pure Aloha does not restrict user traffic and provides
no means of flow control. The half duplex nature and low
effective transmission rate of actual acoustic modems only
make things worse.
To address these issues, UW-Aloha incorporates acknowl
edgement (ACK), which is a feedback from the receiver to the
sender and explicitly informs the sender if a packet has been
received or not. It serves two purposes: detecting collisions
and controlling the traffic. UW-Aloha has minimal number of
parameters to config, adapts well in various network scenarios
and delivers decent overall performance. Detailed design and
analysis can be found in [7].
B. Pipelined Transmission MAC

PTMAC (Pipelined Transmission MAC) [12] is specifically

designed for string networks. It works by parallelizing data
transmissions with the assumption that nodes that are at least
2 hops apart are not able to communicate. Take Fig. 4 for
example. Since Node 4 is unable to send data to Node 2 and
neither is Node 1 to Node 5, we can schedule two parallel
transmissions: Node 1 to Node 2 and Node 4 to Node 5.
Another valid arrangement is Node 1 to Node 2 and Node
4 to Node 3.
1) Data Transmission: One of the design objectives of PT
MAC is to guarantee end-to-end transmission reliability. In this
protocol, we combine three mechanism: collision avoidance,
acknowledgment and retransmission to achieve this goal.
While carrier sensing is not very efficient in underwater
networks due to the long propagation delay of acoustic signals,
collision avoidance is a more promising option. In PTMAC,
we avoid collisions by scheduling packet transmissions in
a slot-based fashion as illustrated in Fig. 5. Following this
scheme, time is divided into equal slots, and in each slot, nodes
that are 3 hops apart are allowed to transmit simultaneously.
For example, in Fig. 5, Node 1 and Node 4 send in Slot 1,
Node 2 and Node 5 in Slot 2, and Node 3 and Node 6 in Slot
3. With this organization, a node needs 3 time slots to regain
access to the channel.

51014

........... .......... ........... ..... 1.

Fig. 5.

An example scheduling in PTMAC

With the development of TCP, explicitly acknowledging

every packet has been proved to be inefficient. In PTMAC, we
use implicit acknowledgment as a main technique to improve
the performance. For example, in Fig. 5, we assume Node 2 is
forwarding a packet received from Node 1. By overhearing the
forwarded packet, Node 1 can take it as an acknowledgment
and proceed to the next packet.
However, we also do not exclude the use of explicit ac
knowledgment. This scenario is also depicted in Fig. 5: when
a packet is sent from Node 1 to Node 6, since Node 6 is the
last node on the string, it will not forward the packet, but will
send back an explicit acknowledgment, which is much shorter
than an implicit one.
In order to have a network operating as described above,
two prerequisites have to be satisfied: start times of slot
operations on every node are synchronous and slot length
is determined. Given the former condition, the latter is a
matter of message exchanging. However, since we have not
implemented a synchronization protocol, PTMAC addresses
this issue into account through two initialization phases: slot
length estimation and timeline alignment.
2) Slot Length Estimation: Slot length estimation is carried
out from one end of the string to the other. Node 1 first sends
Node 2 a PROBE message whose size is identical to that of a
data packet, and records the time of this event. Node 2, upon
receiving this packet, replies with an ACK_PROBE message of
the same size. By Node 2 including time gap from when the
PROBE is received to when the ACK_PROBE is sent, Node 1
can calculate the time it takes to transfer a data packet which
will be referred as transfer latency. This PROBE - ACK_PROBE
message exchange is repeated multiple times on every hop to
improve estimation accuracy.
After this estimation is finished, Node 1 sends a TRIGGER
message, which includes the estimated transfer latency, to
Node 2 so that Node 2 can initiate the same procedure to
Node 3. Node 1 keeps sending the TRIGGER until it receives
an ACK_TRIGGER message or a PROBE message from Node
2. Most of the time, this TRIGGER - ACK_TRIGGER message
exchange is completed in one round, because the size of these
messages is small.
Node 2 after estimating the tranfer latency to Node 3
compares the values estimated by Node 1 and itself, and sends
the greater of the two to Node 3 in the TRIGGER message. At

Sender

the end of this phase, Node n has the greatest per-hop transfer
latency, which will be used as the uniform slot length in the
network.
3) Timeline Alignment: Timeline alignment is conducted in
the reverse direction of slot length estimation.
After Node n acknowledges the TRIGGER message from the
previous node, it picks a start time for its timeline and sends
a TIME_ALIGN message to Node (n - 1), which includes the
sending token, network slot length, and the time gap between
the pipeline start time and when the packet is sent. This packet
is zero-padded to have the same size as a data packet. Based on
the slot length estimated on the hop between Node (n -1) and
Node n, Node (n - 1) can translate the start time of Node n
into its own. A node needs to acknowledge every TIME_ALIGN
with an ACK_TIME_ALIGN. The ACK_TIME_ALIGN is not used
for time estimation, and is therefore small.
The sending token indicates the time slot in which a node
is sending. As the first node to start the timeline estimation
phase, Node n is free to pick its sending token. Node (n - 1)
derives it sending token from that of Node n using base-3
inverse circular progression.
This start-time estimation is repeated for several rounds to
improve its accuracy. After the timeline on Node (n - 1) is
aligned with Node n, it begins to count its time slots using
base-3 circular progression. This node runs the same process
as above to Node (n - 2) so that Node (n - 2) can align its
timeline.
C.

SASHA

SASHA (Selective ARQ with Slotted and Handshaking

based Access) is a coordination based MAC protocol for
underwater networks, which incorporates handshaking, time
slotting, selective ARQ and collision avoidance to improve
data transmission efficiency. The overall work flow of SASHA
is shown in Fig. 6. Node i is trying to send DATA packets to
node i + 1 while node i -I and i + 2 are two bystanders.
A RTS/CTS based handshaking procedure which lasts two
time slots is initiated between node i and i + 1. Node i -I
overhearing the RTS and node i + 2 overhearing the CTS,
will back off. In the beginning of the next time slot, in this
example, node i sends out an HDR (details below), followed
by a DATA packet train composed of 3 packets. Node i -I,
upon overhearing the HDR, also backs off. Only 2 DATA
packets are received at node i + 1 due to packet loss. This
causes node i + 1 to reply with a NACK, rendering node i + 2
to remain silent for a certain period of time indicated by the
NACK. With the reception of the NACK, node i sends out an
HDR in the beginning of the next time slot, followed by the
retransmitted DATA packet 2. The retransmission continues
until an ACK is received at node i.
Besides the well known RTC/CTS/ACKINACK packets,
SASHA introduces a new type of control packet HDR, which
is for both selective-ARQ and collision avoidance. On the
one hand, it notifies the destined receiver of the expected
number of coming DATA packets and therefore the receiver is
able to build a NACK or ACK packet. On the other hand, a

Receiver

.........

......
... ......

_RTS
_CTS
_HDR
_ DATA
_ NACK

.........

.........

.........

.........

Fig. 6.

......

_ACK

......

SASHA overall work flow

bystander overhearing an HDR is able to estimate the duration

of the coming data transmission session and therefore it can
determine an appropriate back-off period.
1) Handshaking and Time Slotting: In underwater net
works, handshaking alone is not enough to eliminate colli
sions, which is pointed out in [9]. Therefore the authors in [9]
coupled time slotting with handshaking to address this issue.
RTS/CTS is required to be sent out at the beginning of a time
slot. The length of a time slot is set to be the maximum packet
propagation delay plus the CTS transmission duration.
2) Selective ARQ: In coordination based MAC protocols,
to improve data transmission throughput, a packet train con
sisting of multiple DATA packets is usually transmitted after
a successful handshaking. Most current underwater MAC
protocols have not incorporated selective ARQ into the packet
train scheme. Consequentially after a successful handshaking,
only one DATA transmission session is followed. This leads
to the fact that lostiunACKed DATA packets will not be
retransmitted immediately; instead, the sender-receiver pair
has to re-compete for the usage of the communication channel.
Therefore, without selective ARQ, an ACK loss will lead to
a re-competition. If ACK loss happens frequently, significant
overhead from handshaking will be imposed, which leads to
severe degradation in data transmission throughput. We may
assume that the probability of ACK loss is negligible compared
with that of DATA packets since an ACK is much shorter.
However, it may not be the case in real underwater networks
due to the channel asymmetry, as observed in [32].
Motivated by the above discussion, SASHA implemented
selective ARQ. After a successful handshaking, multiple
DATA transmissions are allowed until an ACK is received
which indicates that all the DATA packets in the packet
train have been received. In this way, one handshaking can
guarantee that all the DATA packets are received successfully
and therefore the handshaking overhead is significantly re
duced, especially on channels with bad link qualities. Selective
ARQ effectively tackles the ACK loss issue and reduces the
overhead brought by handshaking.
3) Collision Avoidance: The purpose of collision avoidance
in SASHA is to eliminate collisions with ongoing DATA
transmission sessions in the neighborhood, which is achieved
with the help of RTS, CTS, HDR and NACK packets. These

four types of control packets carry the number of DATA

packets to be transmitted next and therefore a node overhearing
one of them can choose an appropriate back-off period to avoid
colliding with the coming data transmission session.
For instance, upon overhearing an RTS, a node needs to re
main silent until the transmissions of the incoming CTS, HDR,
DATA and ACK are completed. Based on this conclusion, the
number of time slots to back-off is:

inclement weather, we made our departure on September 10th

and returned to Lewes, Delaware on September 11th, 2012.

(1)
The first 3 time slots account for the transmission of CTS,
HDR and ACK. The second part of the equation accounts for
the transmission delay plus the propagation delay of DATA
packets. Dt is the transmission delay of a DATA packet and
Dp is the propagation delay of the DATA packet. T is the time
slot length in SASHA, which is set to be the maximum packet
propagation delay plus the transmission duration of CTS.
D. Aqua-Net

The software system is based on a Linux implementation

of Aqua-Net [7]. It is a generic architecture for underwater
sensor networks aiming at delivering a powerful networking
solution kit for underwater network researchers. It provides
user-friendly interfaces to protocol and application developers.
The design also allows cross-layer protocol optimization while
offering great flexibility for application engineers.
Over the years, significant efforts have been put into the
Linux implementation of Aqua-Net. Many modules and pro
tocols have been implemented to extend the capabilities of the
network protocol stack. It has also been tested in several field
experiment in actual underwater wireless networks from the
Atlantic Ocean to the Pacific Ocean.
V.

Fig. 7.

Surface buoys

Each of our network nodes consists of a surface buoy

and a subsurface unit. The surface buoy has a diameter of
1.5 meters and weights approximately 110 lbs, as shown in
Fig. 7. It features a center well that can be used for extra
batteries, a steel mast with an attached flasher, RF antenna
and radar reflector, and a Pelican case for electronic devices.
The subsurface unit is an acoustic modem connected to several
sub-surface floatation devices, lead weights, and an anchor, as
illustrated in Fig. 8.

FIEL D EXPE RI MEN TS

After months of preparation, UConn and NRL scientists

met at University of Delaware, College of Marine Studies
in Lewes, Delaware on August 30th, 2012. We spent 5 days
in the Marine Operations Building by the sea port to finish
network node assembly and final tests on both hardware and
software. We mobilized the ship on September 4th, set sail in
the morning of September 5th, and the 7 days field experiment
began.
In the experiment, we spent 127 hours at sea, among which
27 hours were used in transit to the experiment area. The
target area was in the Atlantic Ocean 100 miles offshore, as
shown in Fig. 1. The average water depth was 80 meters. We
managed to construct an II-node underwater wireless network
in a string topology with a maximum end-to-end distance of 10
kilometers. During the experiment, we made 20 deployments
and 20 recoveries. Each deployment took 60 minutes while
recovery took 30 minutes on average. The sea conditions
were rated from moderate to rough during the experiment
with maximum wave height up to 12 feet. After overcom
ing numerous physical, mechanical and technical issues, we
managed to collect over 15 hours of meaningful data. Due to

Fig. 8.

Mooring configuration

To deploy each network node, the surface buoy has to be

lowered into the water first, followed by sub-surface floats,
lead weights and the acoustic modem. Deployment is best from
a large vessel with ample deck space and a 1200 lb crane
capacity. The ship is then slowing down and dragging the node
by an anchor line to the pre-selected location. When the node
reaches its destination, its anchor will be dropped, and thus
concludes the deployment of a single node.
Recovery of a network node starts from the surface unit.
The buoy is first picked up by a sailor or technician with a
long pole, then hoisted up by crane, and later lowered on to the
deck. After the buoy is disconnected from the mooring line and
the deck is cleared, the crane continues to lift up subsurface
floats, lead weights and the acoustic modem. The greatest

TABLE II
EXPERIMENT RESULTS FOR PTMAC

safety concerns are that of proper rigging and ensuring that

everything is placed onto the deck without rolling or tipping
onto the limbs of deck hands. The anchor is then retrieved and
placed on deck.
VI.

EXPE RI MEN TS RES ULTS AN D DATA ANALYSIS

In the sea trial, we conducted a series of experiments includ

ing three MAC protocols: UW-Aloha, PTMAC and SASHA.
In this section, we will present and analyze experiment data
collected from the sea test.
A. Experiment 1: PipeZined Transmission MAC

In this experiment, we ran 5 sets of PTMAC whose param

eters are listed in Table I. The reader can notice a smaller
packet size and data rate in Set 2, 4 and 5. In Set 2, we
lowered these parameters to compare with SASHA, while in
the last two tests, the environment became unfavorable and
sending less data at slower rate allows the transmission to
become reliable enough to collect data. The topology is listed
in the second column where each number represents a node
index, the left most node is the data source and the right most
is the data sink. In our experiment, packets are generated in
such a way that the time gap between two packets follows
the Poisson distribution, and the parameter of the distribution,
packet generation rate is listed in the last column. Experiment
lengths in seconds are listed in the last column of Table I.
TABLE I
EXPERIMENT PARAMETERS FOR PTMAC

Topology
Set
Set
Set
Set
Set

1
2
3
4
5

8-4-7-6-5
8-4-7-6-5
8-4-7-6-5
5-10-7-4-3-1
5-10-7-4-8-2-9-3-1

Packet
size
(bytes)

500
200
500
200
200

Acoustic
rate
(bps)

600
300
600
300
300

Traffic
rate
(pkts/s)

0.015
0.015
0.02
0.005
0.005

Length
(s)

3048
3142
8602
2978
10827

From the protocol log files, the following metrics are

collected and compiled in Table II:
1) End-to-End Goodput is the total non-duplicated data
received at the sink divided by the time from when the
first packet is sent to when the last packet is received.
2) Average End-to-End Delay is the expected value of the
time needed to transmit a packet from the source to the
sink.
3) Efficiency is the number of distinct packets received at
the sink divided by the maximum number of retransmis
sions made by a node in the network. The node which
retransmits the most is the bottle neck of the network.
The first three sets were conducted under favorable envi
ronmental conditions on September 7th and 8th, in comparison
to the other two sets. In the first set, since the packet rate
was 0.015 packets/s, and the packet size was 500 bytes, on
average, 60 bits of data were generated every second, which
is close to the goodput of 50.90 bps. We also observed the
similar phenomenon in the second set where the goodput

End-to-end
goodput
(bps)
Set
Set
Set
Set
Set

1
2
3
4
5

50.90
23.32
43.86
10.37
6.69

Average
e2e delay
(s)

222.16
94.83
519.30
192.25
2658.25

Stddev
e2e delay
(s)

92.69
31.08
250.43
93.35
1078.92

Efficiency

38/79
45/87
95/211
18/70
48/334

is 23.32 bps versus 24 bits of data generated every second.

This fact indicates that the network was not saturated or in
other words, the sending rate was lower than what could have
been delivered by the network in the favorable condition. The
situation is changed in the third test where all parameters
are same as those of the first one except for the sending
rate. At this rate, on average, 80 bits of data is generated
every second, however the goodput is reduced to 43.83 bps.
Since PTMAC has an automatic mechanism to control the
sending rate, one reason for this decrease could be that the
sea conditions became rougher.
In the afternoon of September 9th, all nine nodes were
deployed, forming a string network consisting of nodes 1, 3,
9, 2, 8, 4, 7, lO and 5. The segment including nodes 4, 7, lO
and 5 was stable while communication on nodes 2, 8 and 9
suffered severely from CRC errors. Therefore we skipped these
nodes and ran Set 4 on six nodes 1, 3, 4, 7, lO and 5. This
day was right before an approaching storm and the weather
was bad, which is reflected by the low efficiency 18/70. Set
5 was carried out after Set 4 in spite of this weather. What
we noticed was that the links 8-2 and lO-7 were unstable and
they limited the network performance.
B. Experiment 2: SASHA

In this section, we will discuss hop-by-hop performance of

SASHA, followed by a description of its overall end-to-end
performance. We managed to conduct 3 successful sea tests
for SASHA, with different settings, including modem power
level, modem acoustic rate, node count, packet length, packet
train length and traffic generation rate. The settings of these
three sea tests are detailed in Table III.
All the three tests lasted roughly one hour. We formed a 5node, 8-node and 9-node (correspondingly 4-hop, 7-hop and
8-hop) network respectively. we chose the lowest transmission
power level of Benthos modems to guarantee that a node
was able to reach only its immediate neighbors. The packet
length and packet train length were both selected to be small.
This is due to the consideration of reliability. The selection of
the modem acoustic rates was a tradeoff between reliability
and efficiency. A too high acoustic rate would lead to severe
packet loss while a too low one would largely increase the
packet transmission duration. Considering the significantly
long end-to-end delays we observed during the tests, a high
traffic generation rate could easily overwhelm the network.
Therefore, we chose relatively low traffic generation rates in
the three tests.

1) Hop-by-Hop Performance: For the hop-by-hop perfor

mance of SASHA, we mainly focus on the packet delivery
delay on a single hop, which is composed of the transmission
delay and queuing delay. On one hand, if a node senses no
conflict and succeeds in completing a handshaking, a packet
train will be transmitted and the delay during this procedure
is counted as transmission delay. In Fig. 6, transmission delay
refers to the duration between when an RTS is sent out and
when an ACK is received. On the other hand, if a node is
notified of a potential collision by collision avoidance or fails
to complete a handshaking due to an RTS/CTS loss, the node
backs-off and the packets are queued at the node. The delay
related to this type of action is accounted as queuing delay.
Queuing delay of a DATA packet is defined to be the time
from when the packet is received at a node to when the last
RTS is sent out leading to the successful reception of that very
DATA packet.

Set 1
Set 2
Set 3

1
1
1

Acoustic
rate
(bps)

Packet
size
(bytes)

Node
count

300
600
300

100
200
200

5
8
9

Train
length
(pkts)

2
2
2

3000

>
..

0.015
0.005
0.005

,;__---;;--4__;c-_;c____.;

Fig. 9.

Hop 10

7-hop transmission delay

0,

Fig. 10.

4
Hop ID

7-hop queuing delay

As an example, the transmission and queuing delay of the

7-hop test (test 2 in Table III) are shown in Fig. 9 and
Fig. 10. We can observe that the transmission delays over
different hops in the 7-hop test were consistent, except that
there was a significant growth on the 5th hop. The reason is
that except for the 5th hop, DATA packet loss rarely happened
and therefore few retransmissions were involved. This led to
stable transmission delays on all the other 6 hops. However,
on the 5th hop, DATA packet loss occurred a lot due to the
bad link quality and triggered selective ARQ procedure and
therefore a much larger transmission delay was observed.
Compared with the transmission delay, queuing delay on
one hop was much more significant and accounted as the
major part of the overall per-hop delivery delay, as shown in
Fig. lO. The three hops in the middle, namely hop 3, 4 and 5
experienced larger queuing as well as delivery delays than the
other hops relatively on the edge. There are two major reasons
for this fact. First, the middle nodes had more immediate

e 7

1-_------

1000

UJ

50
4

Fig. 11.

1500

C.

20

':

'"

2000
Traffic
rate
(pkts/s)

10,-------,____-_-

3500 ,------,

2500

TABLE III
THREE SUCCESSFUL TESTS OF SASHA

Power
level

neighbors than the edge nodes. Therefore, they were more

inclined to overhear ongoing activities from neighbors, which
imposes larger back-off periods. Second, hop 5 experienced
more handshaking failures than other hops due to the bad
channel quality. This led to a significant growth in queuing
delay since after a handshaking failure, back-off and re
competition were incurred.
2) End-to-End Performance: The end-to-end delivery de
lays of the three tests are shown in Fig. 11. As the network
size grows larger, the end-to-end delivery delay also increases.
The significant growth in the delay for the 8-hop test stemmed
from the large amount of handshaking failures. The end-to-end
throughput decreases with the increase of the network size, as
shown in Fig. 12.

-g
UJ

6
Network Size

End-to-end delivery delay

5
4

;----6--
Network Size

Fig. 12.

End-to-end throughput

Experiment 3: UW-Aloha

UW-Aloha was used as a baseline for comparison in the

field test. Due to an incoming hurricane, our experiment
time was cut short. With this time constraint, the UW-Aloha
experiment only got one shot and lasted for a little over one
hour (about 4600 seconds), after which we had to recover all
nodes and made our departure. The experiment topology was
the same as in Fig. 1. Other settings are the same as PTMAC
(Table I, Set 5): the packet size is 200 bytes, the acoustic rate
is 300 bps and the traffic rate is 0.005 pkt/sec.

300 ,--------;=======:::;]
Traffic load
I -Throughput
250
200
!150

100
5O

005001O0 0
'
Experiment time (seconds)

Fig. 13. UW-Aloha throughput of the

first hop

Fig. 14. UW-Aloha throughput of

the network

Fig. 13 illustrates a time series of the network traffic and

throughput at the first hop. The blue line is the traffic injected
into the acoustic channel, while the red line corresponds to
achieved throughput. Only the first 1500 seconds is plotted in
the figure as the effective application layer throughput stays
at around 8 bps for the rest of the experiment time. Fig. 14
demonstrates the end-to-end traffic and throughput measured

at each hop. It shows a much higher traffic at the fifth hop

than the other hops. From our experiment data, we observe
a higher packet error rate at the link between node 5 and 6,
which results in a larger number of re-transmission attempts.
This link turns out to be the network bottleneck and limits the
effective throughput from the fifth hop on. Consequently, the
overall end-to-end throughput is only 2. 5 bps, which is less
than the other two protocols we tested. The results indicate
that UW-Aloha does not perform very well in a lossy channel
compared to PTMAC and SASHA.
VII.

DISCUSSIONS

This section starts by comparing and discussing the strength

and weakness of three MAC protocols based on experiment
results. We then present some interesting issues we found in
the field test. These issues are either new discoveries or not
well studied in existing literature. We hope these new findings
can inspire new research to address some of the problems we
encountered in our field experiment more efficiently.
In Section. VI, the performance of three MAC protocols
in a real underwater environment are studied. Among them,
UW-Aloha is based on random access and does not have any
collision avoidance mechanism. In a multi-hop network, as the
one in Fig. 1, it suffers from severe collisions and therefore
achieves the lowest end-to-end throughput. SASHA, on the
other hand, employs handshaking and collision avoidance to
tackle collisions and improve end-to-end throughput. How
ever, the overhead from handshaking and collision avoidance
degrades its performance, especially when packet loss rate
is high. By contrast, PTMAC has low overhead in control
messages and therefore its throughput grows with the increas
ing packet rate before the network traffic becomes saturated.
This is why in this sea test, PTMAC achieved a much higher
throughput than SASHA. However, PTMAC is particularly
tailored for a string topology networks and cannot be directly
applied to any arbitrary network topologies. Unlike PTMAC,
SASHA is applicable to different network topologies due to
the handshaking and collision avoidance schemes. Therefore,
in real world applications, if the targeted network has a string
topology, PTMAC is obviously the optimal choice. For a
network with other types of topologies or with a dynamic
topology, SASHA is a more appropriate candidate.
In our experiments, we observed link asymmetry in terms of
packet loss rate. By asymmetry, we mean significant difference
in packet loss rates when packets travel in different directions.
Fig. 15 shows the packet loss ratios among the first 7 nodes
of the network in Fig. 1. In this figure, a forward link refers
to a directional communication link from a node to the direct
neighbor closer to the data sink, while a backward link means
the reverse link, i.e., a directional link from the direct neighbor
closer to the data sink. In Fig. 15, at link 7 between Node 6
and Node 7, the forward link had better reliability than the
reverse link. However, the forward link suffered 8",5 times
higher packet loss rates than the backward link at link 2. This
channel asyrmnetry means that packets travelling in different
directions can suffer from dramatically different packet loss

rates, and therefore brings trouble to MAC protocols that rely

on explicit acknowledgment or two way handshaking as both
mechanisms assume homogenous channel quality across the
network.
In the experiment, we also witnessed acoustic channel
dynamics (i.e., the quality of acoustic communication changing
over time). This made the outcome of our network test unpre
dictable by changing the effective network topology in our
experiments. In other words, maintaining a planned network
topology can be a challenge in a real world field test. After
the deployment, the physical location of each network node is
fixed. However, the effective network topology could change
during the course of the experiment. Sometimes, a node may
not be able to reach its neighbor for a while, making the
corresponding link disconnected. Other times, the same node
may reach a node that is not its direct neighbor. This poses
new challenges on (1) how to effectively control the network
topology during sea tests; and (2) how to design protocols
that work efficiently in a changing network. We believe that
the key of solving these problems lies in the cross-layer design
of network protocols.
0.9

1_

Forward Link
c=J Backward Link

0.8
0.7
0.6
.

.3

Channel Estimation (CP)

0.5

0.2

0.4

0.15

0.3

0.1

0.2
0.1

4
Link 10

Fig. 15.
Packet loss rates among
different links

0.05
0

20

40
Delay [msj

'"

'"

Fig. 16.
A typical impulse re
sponse of the multipath channel in
this experiment

Another issue we identified in the field test is long and

strong multi-path effects in the open sea. The mUlti-path spread
recorded in this experiment is longer than we previously
observed in the sea. Fig. 16 plots an estimated channel of the
acoustic communication link. The spikes correspond to signals
travelling through different paths. Different from data collected
in lakes and near shore environments, the signal strength from
different paths do not decrease over propagation time and
distance. The result is also different from data collected a
few years ago in nearby areas where the multipath spread
was generally less than 50 ms. In our 2012 experiment, we
observed that the channel could be longer than 80 ms. This
new finding indicates that the design of acoustic modem needs
to handle more difficult multipath effects to achieve good
communication performance.
Furthermore, environmental effects played a significant role
in the field test. Several factors affected acoustic communi
cation in our experiments. For example, we noticed that the
communication of ship-mounted modems is adversely affected
by the ship hull, air bubbles around the ship and noises from
engine and other acoustic instruments such as sonar and fish

finders. This requires new techniques to address these issues

and may require a brand new way of handling underwater
wireless networks (i.e., cognitive acoustics).
VIII.

CONCL USIONS

In this paper, we share our experience from a recent

field experiment of an underwater wireless network in the
Atlantic Ocean. We deployed 11 network nodes across 10
kilometers in an open sea area. Several network protocols
designed for underwater wireless networks were tested. Hours
of experiment data were collected. Real world underwater
network performance was evaluated and analyzed. Practical
issues in real systems are identified and studied. We hope our
experience and findings would inspire new research and be
valuable to the research community for future advances of
underwater wireless network research.
ACKNOWLE DGMENT

The authors would like to thank Ms. Lina Pu, Mr. Yu Luo
and Mr. Yibo Zhu for their efforts in experiment preparation
and data analysis. We would also like to express our sincere
gratitude to the crew of R.Y. Hugh R. Sharp without whom our
field experiment would not be possible. Michael Zuba would
like to acknowledge support from the ASEE Naval Research
Enterprise Internship Program (NREIP) 2012.
REFE RENCES
[ I ] J. Partan, J. Kurose, and B . N. L evine, "A Survey of Practical Issues in
Underwater Networks," in Proc. ACM WUWNet, 2006.
[2] J. Kong, J.-H. Cui, D. Wu, and M. Gerla, "B uilding Underwater Ad
hoc Networks and Sensor Networks for L arge Scale Real-time Aquatic
Application," in Proc. IEEE MIL COM, 2005.
[3] J. L i, S. Jang, M. Zuba, J.-H. Cui, and Y. Zhu, "Feasibility of Underwater
Sensor Networks for L ifetime Assessment of O ffshore Structures," in
Proc. MTSIIEEE O CEANS, 2012.
[4] A. Goodney, Y. H. Cho, J. Heidemann, and J. Wroclawski, "An
Underwater Communication and Sensing Testbed in Marina Del Rey,"
in Proc. ACM WUWNet, 2010.
[5] J.-H. Cui, J. Kong, M. Gerla, and S. Zhou, "ChaUenges: B uilding
Scalable Mobile Underwater Wireless Sensor Networks for Aquatic
Applications," IEEE Network, vol. 20, no. 3, pp. 12-18, 2006.
[6] Teledyne-B enthos, "Acoustic Modem Specifications," 1999.
[7] Z. Peng, Z. Zhou, 1.-H. Cui, and Z. Shi, "Aqua-Net: An Underwater
Sensor Network Architecture: Design, I mplementation, and Initial Test
ing," in Proc. IEEEIMTS O CEANS, 2009.
[8] P. Xie and J.-H. Cui, "R-MAC: an Energy-Efficient MAC Protocol for
Underwater Sensor Networks," in Proc. IEEE WASA, 2007, pp. 187-198.
[9] M. Molins and M. Stojanovic, "Slotted FAMA: A MAC Protocol for
Underwater Acoustic Networks," in Proc. IEEE O CEANS, 2006.
[10] c.-C. Hsu, K.-F. L ai, c.-F. Chou, and K. c.-J. L in, "ST-MAC: Spatial
Temporal MAC Scheduling for Underwater Sensor Networks," in Proc.
IEEE INFO COM, 2009.
[11] Y. Guan, c.-c. Shen, and J. Yackoski, "MAC Scheduling for High
Throughput Underwater Acoustic Networks," in Proc. IEEE WCNC,
2011.
[12] S. Le, Y. Zhu, J.-H. Cui, and Z. Jiang, "Pipelined Transmission MAC
for String Underwater Acoustic Networks," UCONN CSE, Tech. Rep.
UbiNet-TR \ 3-01, 2013.
[13] X. Guo, M. R. Frater, and M. J. Ryan, "Design of a Propagation-delay
tolerant MAC Protocol for Underwater Acoustic Sensor Networks," in
IEEE Journal of Oceanic Engineering, 2009.
[14] A. A. Syed, W. Ye, and J. Heidemann, "T-L ohi: A new class of MAC
protocols for underwater acoustic sensor networks," in Proc. IEEE
INFO COM, Apr. 2008.

[15] c. L. FuUmer and 1. J. Garcia-L una-Aceves, "Floor Acquisition Multiple

Access (FAMA) in Single-channel Wireless Networks," in Journal of
Mobile Networks and Applications, O ct. 1999.
[16] Z. Peng, J.-H. Cui, B . Wang, K. B all, and L. Freitag, "An Underwater
Sensor Network Testbed: Design, I mplementation, and Measurement,"
in Proc. WUWNet, 2007.
[17] B . Chen and D. Pompili, "A Testbed for Performance Evaluation of
Underwater Vehicle Team Formation and Steering Algorithms," in Proc.
IEEE SECON, 2010.
[18] Z. Peng, S. L e, M. Zuba, H. Mo, Y. Zhu, L. Pu, J. L iu, and J.-H. Cui.,
"Aqua-T UNE: a Testbed for Underwater Networks," in Proc. MTSIIEEE
O CEANS, 2011.
[19] Z. Feng, G. Shang, and L . L ian, "A L ow-cost Testbed of Underwater
Mobile Sensing Network," in Proc. O CEANS, 2010.
[20] T. Melodia, S. B atalama, D. Pados, W. Su, and 1. Atkinson, "UW
B uffalo: An Underwater Acoustic Testbed at the University at B uffalo,"
2012.
[21] J. Alves, J. Potter, G. Zappa, P. Guerrini, and R. B een, "A Testbed
for Collaborative Development of Underwater Communications and
Networking," in Proc. IEEE MILCOM, 2012.
[22] J.-H. Cui, S. Zhou, Z. Shi, J. O ' DonneU, Z. Peng, M. Gerla, B . B aschek,
S. Roy, P. Arabshahi, and X. Zhang, "O cean-T UNE: A Community
O cean Testbed for Underwater Wireless Networks," in Proc. ACM
WUWNet, Nov 2012.
[23] J. Rice, B . Creber, C. Fletcher, P. B axley, K. Rogers, K. McDonald,
D. Rees, M. Wolf, S. Merriam, R. Mehio, J. Proakis, K. Scussel,
D. Porta, J. B aker, J. Hardiman, and D. Green, "Evolution of Seaweb
Underwater Acoustic Networking," in Proc. MTSIIEEE O CEANS, 2000.
[24] J. Rice, "Enabling Undersea FO RCE net with Seaweb Acoustic Net
works," SSC San Diego TD 3115, pp. 174-180, dec 2003.
[25] G. l. Hartfield, "L ink-layer and Networ-layer Performance of an Under
sea Acoustic Network at Fleet B attle Experiment-India," Master's thesis,
Naval Postgraduate School, 2003.
[26] V. K. McDonald, J. A. Rice, and C. L . Fletcher, "An Underwater Com
munication Testbed for Telesonar RDT &E," in Proc. IEEE O CEANS,
1998, pp. 639-643.
[27] L . Freitag, M. Grund, S. Singh, and M. Johnson, "Acoustic Communi
cation in Very ShaUow Water: Results From the 1999 AUV Fest," in
Proc. MTSIIEEE O CEANS, ser. 3, 2000.
[28] L . Freitag, K. B aU, J. Partan, E. Gallimore, S. Singh, and P. Koski,
"Underwater Acoustic Network Testbed," ACM International Workshop
on UnderWater Networks (WUWNet), 2011.
[29] c. Petrioli and R. Petroccia, "SUNSET : Simulation, Emulation and Real
life Testing of Underwater Wireless Sensor Networks," in Proc. IEEE
UComms, 20 1 2.

[30] G. Toso, R. Masiero, P. Casari, O. Kebkal, M. Komar, and M. Zorzi,

"Field Experiments for Dynamic Source Routing: S2C EvoL ogics
Modems Run the SUN Protocol Using the DESERT Underwater L i
braries," in Proc MTSIIEEE O CEANS, 2012, pp. 1-10.
[31] A. Caiti, V. Calabro, L . Fusini, A. Munafo, K. Grythe, J. M. Hovem,
and A. L . T. A. Reinen, "Underwater Acoustic Network Performance:
Results from the UAN I I Sea Trial," in Proc. MTSIIEEE O CEANS,
O ctober 2012.
[32] L . Pu, Y. L uo, H. Mo, J.-H. Cui, and Z. Jiang, "Comparing Underwater
MAC Protocols in Real Sea Experiment," UCONN CSE, Tech. Rep.
UbiNet-TR13-03, 2013.