-
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 tDepartment 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, 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 communication
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 environment, 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
the underwater communication instrument (i.e. a Teledyne Benthos
underwater acoustic modem [6]).
Fig. l. Deployment area
On the software side, we use Aqua-Net [7] as the software
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. Moreover, 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. STMAC 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 handshaking 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 completely
eliminate collisions [15]. Therefore other mechanisms have been
explored to avoid collisions and improve data transmission
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 AquaLab [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 communication 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 comprehensive 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 (WHOI) 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. 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 microcomputer, 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 monitored 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
Fig. 2. Internal view of electronics compartment
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 microcomputer 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 Acoustic Modem
Fig. 3. Hardware interface diagram
IV. SYSTEM SO FTWARE
This section elaborates on the software used in the experiment,
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 channels,
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 acknowledgement
(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. Pipe lined Transmission MAC
PTMAC (Pipe lined 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 PTMAC 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
acknowledgment. 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
-
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
Sender Receiver
........................
........................
........................
_ RTS _CTS _HDR _ DATA _ NACK _ACK
Fig. 6. 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 networks,
handshaking alone is not enough to eliminate collisions, 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 consisting 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 reduced, 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 remain
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:
(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 protocols 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. FIEL D EXPERI 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
overcoming numerous physical, mechanical and technical issues, we
managed to collect over 15 hours of meaningful data. Due to
inclement weather, we made our departure on September 10th
and returned to Lewes, Delaware on September 11th, 2012.
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.
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
-
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. EXPERI MEN TS RES ULTS AN D DATA ANALYSIS
In the sea trial, we conducted a series of experiments including
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 parameters 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
Packet Acoustic Traffic Length Topology size rate rate (s)
(bytes) (bps) (pkts/s) Set 1 8-4-7-6-5 500 600 0.015 3048 Set 2
8-4-7-6-5 200 300 0.015 3142 Set 3 8-4-7-6-5 500 600 0.02 8602 Set
4 5-10-7-4-3-1 200 300 0.005 2978 Set 5 5-10-7 -4-8-2-9-3-1 200 300
0.005 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 retransmissions 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
environmental 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
TABLE II EXPERIMENT RESULTS FOR PTMAC
End-to-end Average Stddev goodput e2e delay e2e delay
Efficiency
(bps) (s) (s) Set 1 50.90 222.16 92.69 38/79 Set 2 23.32 94.83
31.08 45/87 Set 3 43.86 519.30 250.43 95/211 Set 4 10.37 192.25
93.35 18/70 Set 5 6.69 2658.25 1078.92 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 5-node,
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 performance 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.
TABLE III THREE SUCCESSFUL TESTS OF SASHA
Power Acoustic Node level rate count
(bps) Set 1 1 300 5 Set 2 1 600 8 Set 3 1 300 9
20,;__---;;---;;--4__;c-_;c______.; Hop 10
Packet Train size length
(bytes) (pkts) 100 2 200 2 200 2
0, 4 Hop ID
Traffic rate
(pkts/s) 0.015 0.005 0.005
Fig. 9. 7-hop transmission delay Fig. 10. 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
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 recompetition were
incurred.
2) End-to-End Performance: The end-to-end delivery delays 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.
3500,--------------, 3000 '" 2500 2000 > .. 1500
10001-_------UJ
504 6 Network Size
Fig. 11. End-to-end delivery delay
C. Experiment 3: UW-Aloha
10,-------,____-_-
': 9 e
i e 7 6 5 -g UJ 4
;----6-- Network Size
Fig. 12. End-to-end throughput
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,--------;=======:::;] I Traffic load -Throughput 250 200
!150 100
5O 005001O00' Experiment time (seconds)
Fig. 13. UW-Aloha throughput of the Fig. 14. UW-Aloha throughput
of first hop 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. However, 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 increasing
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 unpredictable 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
0.8
0.7
0.6
0.5 .3 0.4
0.3
0.2
0.1 l l
1_ Forward Link c=J Backward Link
4 Link 10
Channel Estimation (CP) 0.2
0.15
0.1
0.05 . 0 . 0 20 40 '" '"
Delay [msj
Fig. 15. Packet loss rates among Fig. 16. A typical impulse
redifferent links sponse of the multi path 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 communication 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.
ACKNOWLEDGMENT
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.
REFERENCES
[ 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 Adhoc 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 OCEANS, 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, Implementation, and Initial
Testing," in Proc. IEEEIMTS OCEANS, 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 OCEANS, 2006.
[10] c.-C. Hsu, K.-F. Lai, c.-F. Chou, and K. c.-J. L in,
"ST-MAC: SpatialTemporal 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. Ubi Net-TR \3-01, 2013.
[13] X. Guo, M. R. Frater, and M. J. Ryan, "Design of a
Propagation-delaytolerant 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, Oct.
1999.
[16] Z. Peng, J.-H. Cui, B . Wang, K. B all, and L. Freitag, "An
Underwater Sensor Network Testbed: Design, Implementation, 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-TUNE: a Testbed for Underwater Networks," in
Proc. MTSIIEEE OCEANS, 2011.
[19] Z. Feng, G. Shang, and L . L ian, "A Low-cost Testbed of
Underwater Mobile Sensing Network," in Proc. OCEANS, 2010.
[20] T. Melodia, S. B atalama, D. Pados, W. Su, and 1. Atkinson,
"UWB 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,
"Ocean-TUNE: A Community Ocean 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
OCEANS, 2000.
[24] J. Rice, "Enabling Undersea FORCE net with Seaweb Acoustic
Networks," SSC San Diego TD 3115, pp. 174-180, dec 2003.
[25] G. l. Hartfield, "L ink-layer and Networ-layer Performance
of an Undersea 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 Communication Testbed for Telesonar RDT&E," in Proc.
IEEE OCEANS, 1998, pp. 639-643.
[27] L . Freitag, M. Grund, S. Singh, and M. Johnson, "Acoustic
Communication in Very ShaUow Water: Results From the 1999 AUV
Fest," in Proc. MTSIIEEE OCEANS, 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 Reallife 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
Libraries," in Proc MTSIIEEE OCEANS, 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
OCEANS, October 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.