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