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.