From underwater simulation to at-sea testing

using the ns-2 network simulator

Chiara Petrioli and Roberto Petroccia

Dipartimento di Informatica

Universita di Roma “la Sapienza”

Roma, Italy

E-mail: {petrioli,petroccia}@di.uniroma1.it

Jon Shusta and Lee Freitag

Woods Hole Oceanographic Institute

Woods Hole, MA, USA

E-mail: {jshusta,lfreitag}@whoi.edu

Abstract—Although several network protocols for un-derwater acoustic wireless sensor networks have beenproposed in the past, having a complete and accurateunderstanding of the performance of these protocols is notan easy task. The unique characteristics of the underwateracoustic communication channel, such as limited capacity,high and variable propagation delays, frequency-dependentattenuation and significant impact of highly variable envi-ronmental conditions, motivate the fact it is quite chal-lenging to identify simple but accurate channel models.Such models are instead needed to improve accuracy ofsimulation results and to be able to derive fundamentalresults on underwater communications performance. Tofacilitate the research in underwater sensor networks, itwould be really desirable to have a standard platform forsimulation, emulation and real-life testing in order to beable to compare and evaluate different network designs,algorithms and protocols in a variety of settings andapplication scenarios. With this objective in mind, we havedeveloped a framework to seamlessly simulate, emulate andtest at sea novel communication protocols, which is basedon the open source and well known network simulator ns-2 [1]. Using the proposed framework, anyone willing toimplement its solution for simulation experiments usingns-2 can use the same code in emulation mode, adoptingreal acoustic modem for data transmission. The frameworkcode has also successfully been ported on small portabledevices (Gumstix [2]), thus allowing us to embed it insidemodem or AUV housings. Therefore, it becomes easy for theresearch community to write code and evaluate protocolson a real testbed. Different drivers allowing ns-2 to operatewith commercial acoustic modems, such as FSK and PSKMicro-Modem [3], Evologics modem [4] and Kongsbergmodem [5], have already been implemented.

Index Terms—Underwater acoustic networks, simula-tion, emulation, ns-2, underwater wireless sensor networks,sea trial testing.

I. INTRODUCTION

Simulations are an important step towards deployment

of Underwater Sensor Networks (UWSN) because of

their ability to provide experiment repeatability, and

to assess UWSN protocol performance under a variety

of traffic patterns, network sizes and topologies, un-

derwater propagation environments, much beyond what

can be tested through real-life experiment. However,

even the most accurate available simulators using ray

tracing models combined with real environmental data

(bathymetry profile, sound speed profile, bottom sedi-

ment), cannot accurately capture acoustic channel be-

havior and variability, failing to correctly express what

would happen in practice, as also shown by recent papers

such as [6].

Moreover, simulation environments typically do not

reflect physical constraints of existing hardware which

can have significant impact on protocol performance in

practice [7]. For instance, experience gathered during sea

trial campaigns we have carried out in collaboration with

WHOI and NURC (Nato Undersea Research Centre) has

clearly shown the impact on protocol performance of

acoustic modem features such as control packets hand-

shakes required before each packet transmission (FSK

WHOI Micro-Modem [3]) or packets sizes different from

what has been shown optimum for a given class of

protocols [8].

To reduce the gap between simulations and real-life

experiments we have therefore developed a framework,

which is based on the network simulator ns-2 [1], for

simulating and testing at sea underwater communication

protocols. Our framework on one side explicitly includes

several commercial acoustic modems models and on the

other side allows to seamlessly port the simulator code

on real devices, thus allowing us to compare simulation

and experimental results without possible errors and

performance changes due to code rewriting. The great

advantage on using ns-2 is that it is open source, well

known and largely used by the research community. This

means that anyone willing to implement its solution for

performing ns-2 simulations can use the same code (with

very few changes to deal with real hardware delays,

if needed) for emulation and at sea testing using our

framework. Therefore, it becomes easy for the research

community to write code and evaluate protocols on a real

testbed. Moreover, several routing and MAC solutions

have already been implemented in ns-2 and they are basi-

cally ready for underwater tests. Different drivers allow-

ing ns-2 to operate with commercial acoustic modems,

such as FSK and PSK Micro-Modem [3], Evologics

978-1-61284-4577-0088-0/11/$26.00 ©2011 IEEE

modem [4] and Kongsberg modem [5], have already been

implemented. The framework code has also successfully

been ported on energy efficient, compact, high perfor-

mance and inexpensive embedded devices (Gumstix [2]),

thus allowing us to embed it inside modem or AUV

housings. The tests we have conducted have shown very

promising results. The proposed framework turned out

to be a very powerful tool to fast design, implement and

test protocols. The delays introduced by the framework

are of the order of millisecond and the extra overhead

due to framework operations is extremely limited, just

one extra bytes per packet is needed. The remainder of

the paper is organized as follows. Section II describes

the state of the art of testbeds and emulation frameworks

for underwater networks. The proposed framework is de-

scribed in Section III. In Section IV we report the results

of tests we have conducted to assess the effectiveness of

our approach. Finally, concluding remarks are given in

Section V.

II. RELATED WORK

Different underwater acoustic sensor network testbeds

have been proposed in the past [9]–[12]. In [9] the

Aqua-Lab testbed is introduced. It consists of a water

tank, a set of acoustic communication hardware (WHOI

Micro-Modem) and software Application Programming

Interfaces (APIs). Software APIs encapsulate all the

operations of the hardware and provide an abstract layer

for the users. Users can develop their own applications

without knowing the exact mechanisms of the underlying

acoustic physical layer. An emulator is also developed to

emulate different network topologies, propagation delay,

and attenuation. The authors use Aqua-Lab and Micro-

Modems and conduct a set of experiments in both field

and lab environments. In [10], the authors present an

underwater sensor network architecture called Aqua-

Net. It has a layered structure and supports cross-layer

optimization. In the physical layer, different physical

devices, such as Micro-Modem and Benthos modems,

can be supported with a physical layer wrapper via

NMEA-compliant serial communications. National Ma-

rine Electronics Association (NMEA) has a set of spec-

ifications that describe how marine electronic devices

should communicate with other instruments, such as

micro-controllers. Above the physical layer there is the

protocol stack that includes link layer, network layer

and application layer. Aqua-Net has been implemented

in a real system, which consists of both hardware

and software. For hardware, Micro-Modems are used

as communication devices and Gumstix computers [2]

are used as controllers. OpenEmbedded Linux [13] is

adopted as the operating system and Aqua-Net runs on

top of it. In [11] the authors propose a unified simulation

and implementation software framework for underwater

MAC protocol development. The same C code is used in

both the simulator and the modem to implement the logic

of the selected MAC protocol. The simulator captures the

essential behavior of the ARL OFDM modem selected

for the framework and uses the same software interfaces

as the modem. Since the same code is used with no

change, performance comparisons between simulations

and sea trials are possible.

All such testbeds are based on proprietary architec-

tures and software, which means that protocol code

usually needs to be rewritten to test it in different settings

and limits accessibility to testing facilities. The only

previous work we are aware of which is along the

lines of what we have done is [12]. Authors propose

UANT (Underwater Acoustic Networking platform), a

simulation/emulation/testing framework based on GNU

radio, a software defined radio framework, interfaced

with a PC running TinyOS (or TOSSIM in case of

simulation/emulation). The use of the well known GNU

radio concept allows testing the impact on performance

of a large library of supported modulation schemes

including GMSK, PSK, QAM, OFDM etc. The GNU

radio is connected to an acoustic transducer to transmit

the waveform on the acoustic channel. Underwater com-

munication protocols instead run on the PC. UANT is an

interesting concept developed to add flexibility in what

can be tested at the lower layers of the stack while allow-

ing researchers to interact with a well known simulation

and deployment tool (TOSSIM/TinyOS). The only limits

are that UANT runs on a PC which is unlikely to be

used in real-life experiments due to housings constraints

(the PC requirement is due to the fact GNU radio is

currently too computationally expensive to run on an

embedded device). Also, running solutions on TinyOS

means that protocol design has to follow rules which

reflect features of IEEE 802.15.4 type of devices and

which do not always match features of underwater nodes

and underwater communication devices. Also TOSSIM

is currently not able to support an underwater channel

model.

III. FRAMEWORK DESCRIPTION

Our approach uses a simulation/emulation/testing

framework based on open source well known software.

The same code has to be used to simulate a given

protocol and to execute it on small embedded devices,

which can be used during trials at sea. Another objective

of the proposed approach is that interfacing the software

communication modules with different hardware (differ-

ent computer boards, different nodes, both AUVs and

static underwater sensor nodes, and different acoustic

modems) must be possible and require very limited

effort. In this way the overall framework becomes a

very powerful tool which can be used by the scientific

(a) Simulation (b) Emulation

Figure 1. ns-2 framework architecture: Simulation and emulation modes.

community to validate, test and compare new ideas in a

variety of settings.

With all these objectives in mind, our approach has

been that of a) Extending the ns-2 [1] simulator, the

most commonly used open-source simulator so that it

accurately captures the features of underwater communi-

cation environment; b) Improving the real-time scheduler

supported by ns-2 so that a single instance of ns-

2 can emulate the behavior of a single node in the

network, receiving/transmitting packets and information

from/to the node, sensors and the acoustic modem upon

need; c) Interfacing the proposed software framework

with commercial hardware and modems available in the

market, and at the same time keeping an open archi-

tecture preparing for integration with different acoustic

modems, nodes and AUV vehicles. d) Porting the same

code used for simulation on energy efficient, compact,

high performance and inexpensive embedded devices

which can be easily included in real underwater nodes

in order to be able to test the proposed solutions in

real-life experiments (Gumstix computers [2] have been

selected.)

The challenges and ideas which we have developed

to perform each of these steps are described in the

following subsections.

A. Extending the Ns-2 simulator

Ns-2 is a discrete event network simulator which is

widely used by the communication networks research

community. In ns-2 the advance of time depends on the

timing of events which are maintained by a scheduler.

The scheduler keeps an ordered data structure with the

events to be executed and fires them one by one.

Each network node, as implemented in ns-2, is made

up of different components representing the different

protocol stack layers: Application, Routing, Link Layer

and MAC, and Physical (Figure 1(a)).

Ns-2 is commonly used to simulate an entire network

on a single computer. The user defines its network topol-

ogy, the different node components (e.g. what Routing,

MAC, propagation model or channel has to be used)

and then runs the simulation in order to obtain results.

Usually, the advance of the simulation time depends on

the timing of events in the scheduler. If the scheduler

has two events, one at time T and the other at time

T ′ > T , with no events to be scheduled between T and

T ′, it schedules the event at T and then instantaneously

changes the simulator time to T ′. It is also possible to

use a real time scheduler, where, instead ns-2 follows

a global timer and waits for the actual T ′ − T s before

scheduling the next event.

We have extended ns-2 in order to include key char-

acteristics of the underwater environment such as 3D

deployment, propagation at the speed of sound, and

acoustic path loss that depends on the distance and

frequency. Two new modules have been implemented

for the channel and the propagation delay, taking into

account the specific characteristics of the acoustic com-

munication in water based on Urick’s formulas [14].

B. Interfacing ns-2 to real world hardware

We have decided to re-use the ns-2 architecture for our

framework (Figure 1(b)) thus keeping the same network

components (all the different layers in the node protocol

stack) for both simulation, emulation and real-life tests.

In order to allow ns-2 to work correctly in an efficient

way with real devices, some of the ns-2 components had

to be extended and improved.

First of all we have introduced the use of multiple

threads, thus allowing the main thread to run the protocol

stack while secondary threads listen to communications

from external devices. We have then improved and

optimized the ns-2 real time scheduler to more accurately

capture the elapsed time, making it possible for sec-

ondary threads to interact with the ordered data structure

of the scheduler (used by the main thread) while the main

thread is waiting for the next event to be scheduled. In

order to correctly take into account the delays introduced

by the use of real devices (acoustic modems, Gumstix,

other external devices), which are usually ignored when

performing simulations, a timing module has been added

(see Figure 1). It is used by the different layers to get

information on the device delays when computing all the

timeouts used by the protocol stack. 1

- Acoustic modems

To allow the interaction between ns-2 and acoustic

modem, the protocol stack is connected to the modem

through a specific driver that implements the code used

by ns-2 to handle all the specific functionalities of the

particular modem. Different modems can have different

functionalities, including power control or sleep/awake

schemes. Different drivers for commercial modems have

therefore been implemented, including drivers for the

FSK and PSK Micro-Modem [3], the Evologics mo-

dem [4] and the Kongsberg modem [5]. 2

A “generic driver module” has been implemented

which takes care of the modem independent interactions

with ns-2. It translates each ns-2 packet into a buffer of

data, which is sent as the payload of the acoustic modem

packet, at the transmitter. At the receiver, instead, the

generic driver module converts back the data payload

into a proper ns-2 packet. In this way the ns-2 simulator

will always work with ns-2 packets and no modifications

are needed at the upper layers. Each modem driver

then extends the generic driver module: It receives the

payload from the generic driver module and performs

all the modem-specific operations to send it over the

acoustic channel. Again, once the modem specific driver

receives the data from the underwater channel, it will

extract the payload and provide the useful information

to the generic driver module which will then translate

the payload into an ns-2 packet and send it to the upper

layers.

The actual connection between the driver and the real

modem can be done in different ways depending on

the hardware used to run ns-2 and the specific acous-

tic modem which might support serial port, Bluetooth

connection, Ethernet, Ethernet over USB, etc.

- Measurement sensors and AUVs

The designed architecture is open enough to allow the

integration not only with real acoustic modems but also

with other different devices, such as sensors for under-

1The same estimated values are used for both simulation andemulation.

2Given the high flexibility of the proposed framework all modemswhich provide APIs to transmit and receive packets can be easilyinterfaced.

water measurements (CO2, pressure, temperature etc.)

and AUV navigation control systems. We have designed

a basic communication interface for data exchange with

these devices (see Figure 1(b)). As we did for the acous-

tic modems, once a driver for the specific device has

been implemented, which is needed to handle the device

functionalities, the selected device can be plugged to the

ns-2 architecture through the communication interface

and used by ns-2. In this way the application layer can

collect information from the sensors or the navigation

system of the AUV it is connected to and use such

information for several purposes. It could instruct the

AUV to perform some action or it could deliver data

to a central station. Moreover, it is possible to send

requests/commands to a remote static node or AUV

through the acoustic link. Once the application layer has

created its own packet containing its request, the request

will go through the protocol stack (each layer will add

its information header to it, if any) and the driver will

insert the payload into the acoustic packet. The received

acoustic packet will go through the protocol stack in

the opposite direction, the payload will first be extracted

and an ns-2 packet will be created and sent through

the different layers. Once at the application layer, the

receiving node will perform the corresponding action,

e.g. navigating to a given location, starting the detection

of some event, etc. Each request can go through multi-

hop paths based on the implemented routing protocol.

Having the entire protocol stack almost independent

from the communications devices (some constraints

maybe imposed by specific modems in terms of maximal

packet size for data or control packets) gives us the

possibility to implement new protocol solutions in an

easy and fast way. We can run tests changing either

the selected protocols (MAC, Routing, etc.) or some

protocol parameters without any changes in the external

devices code and at the same time we can change

the configuration parameters for the specific modem or

the communication hardware without any change in the

actual protocol stack. Everything we need is inside our

framework and with very few changes we are ready to

run a completely different test.

Using the proposed framework, the same code written

for performing simulations can be re-used for emulation

and at sea trials without rewriting. The only aspect a

programmer has to be careful about is that in simulation

experiments the computational delay, external devices

delay or delays related to the communication between

different hardware components on the same node are

usually ignored while they have to be kept into account

when tuning the protocols parameters before real-life

tests. If these delays are already accounted for when

computing protocol stack timeouts for simulation pur-

Figure 2. One single workstation running one single ns-2 applicationsimulates an entire network with an arbitrary number of devices.

poses (which means a specific modem model is used for

simulation and corresponding parameters are set in the

Timing module), no changes in the code are needed and

the code is seamlessly ported to real devices and used

for tests at sea or in a lab emulation environment.

The use of our framework for simulation and emu-

lation is depicted in Figures 1 to 3. When running in

simulation mode (Figure 1(a)), the event driven sched-

uler is used and the acoustic channel and propagation

model are simulated (by means of Urick’s formulas,

Bellhop [15] or other ray tracing models). In this case,

one PC runs a single instance of ns-2 to simulate an

entire network (Figure 2). While in emulation mode,

the real time scheduler is used. The simulated channel

propagation model is then replaced by the use of real

hardware (Figure 1(b)). When emulating the network,

each node is an instance of ns-2 which emulates its own

behavior, based on the defined protocol stack, and it has

to run on its own hardware (Figure 3). We can also have

more instances of ns-2 running on the same machine but

each of them has to be connected to its own acoustic

modem and to other node components, such as sensors

and AUV control system.

Figure 3. Different real devices, each of them running one ns-2application.

C. Moving to real life testing

When planning real life tests a smaller embedded

device – which is also energy efficient – should be used

to run our framework in order to reduce the energy

consumption and to include such device in the modem

housing (or AUV housing) thus reducing costs and

easing test preparation. We have selected the Gumstix

computers3 [2] for this purpose. Gumstix Motherboard is

based on Marvell PXA270 with XScale microprocessor

core. It is the fifth generation of the ARM architec-

ture. Different system boards are available with 16MB

to 128MB of RAM, 16MB to 32MB of flash, SD

card disk storage, and is running at 400 MHz up to

600MHz. The OS is OpenEmbedded Linux [13]. We

have successfully ported the ns-2 code, protocol stack

and driver implementations on the Gumstix device. This

makes possible to run our framework on a small and

efficient device and gives us the capability to integrate

our system inside an AUV thus making possible the

use of our framework to control the vehicle operations

through acoustic commands sent by other AUVs or by a

remote control center (possibly through multiple nodes

in the network).

IV. FRAMEWORK EVALUATION

A first set of tests on the feasibility of our approach

has been conducted at WHOI during July 2010 us-

ing four modems (WHOI gateway buoys - Figure 4 -

equipped with PSK Micro-Modems [3]) in the WHOI

laboratory and at open sea. We implemented a CSMA

MAC protocol [8] on our extended version of ns-2.

Gumstix and driver developed for PSK WHOI Micro-

Modems have been used during these tests. The objective

of our first set of tests was to evaluate overhead and

delays introduced by the framework operations, as well

as to accurately estimate the overhead and delays related

to the modem and to the Gumstix operations, thus being

able to appropriately set the values to be used in the

timing module.

A. Laboratory testing

Before going to sea, several tests have been performed

using the WHOI lab test-bed (Figure 5). It is composed

of following parts:

• Gumstix Motherboard: The system board has 64MB

RAM, 16MB flash, 1GB SD disk storage, and is

running at 400 MHz. The OS is OpenEmbedded

Linux that interacts with the modem via the serial

port and with the Emulator controller via USB.

• WHOI PSK Acoustic Micro-Modem [3]: It is a

low-power underwater acoustic modem developed

3We have run experiments using basix and verdex Gumstix boards,also connex and new over boards can be used.

Figure 4. WHOI gateway buoys used for our tests (we used 4 ofthem).

by WHOI. It can transmit different types of pack-

ets at 7 data rates in different bands from 3 to

30kHz. Control of the Modem is by NMEA com-

mands [16].

• Mixer: It is a board with multiple lines of input and

output (Figure 6). It receives an audio signal from

a modem on an input line and sends it in output to

the other modems.

• Emulator control: It is a PC connected to the

gumstix devices via USB.

Figure 5. Logical Architecture.

Each Gumstix controls the operation of one Micro-

Modem. The PC is used to interact with the Gumstix

devices, allowing to connect to such devices in order to

run the desired tests. The mixer is used as the acoustic

channel. No propagation delay or impairment for correct

signal reception is accounted for. When a packet is sent

by a node into the network, based on the mixer setting,

it is correctly received by all the other nodes or just by

a subset of them (depending on the selected topology).

We have considered as topologies a clique and a chain

of 4 nodes (which is the maximum number of nodes the

lab test-bed can emulate). The main purpose of our lab

tests is to test the interaction of the code running on the

Gumstix with the operation of the Micro-Modem with

an accurate understanding of the delays related to the

involved devices.

Figure 6 shows the actual hardware involved in the

lab test-bed.

Figure 6. Testbed components.

Table I presents an accurate estimation of the delays

we have measured. The additional delay introduced by

the Gumstix device to run the ns-2 software and to

interact with the modem was in the range 0.01 to

0.08 seconds, which is quite negligible compared to

the modem delays. When running sea testing each data

transmission takes longer as propagation delay must also

be kept into account. This makes the Gumstix/framework

delays negligible.

Table IOVERHEAD PER DATA PACKET (FOR 5000 CHIPS/SEC)

FM Sweep 0.01s

Coprocessor Turn on delay 0.25s

Training Sequence (510 symbols) 0.102s

Modulation Header (3x126 symbols) 0.0756s

Packet header length 0.078s

Gumstix-modem control information ex-changing before data transmission (it is dueto the modem)

0.04s

Serial line data transmission 0.04s

Data packet encoding by the modem beforestarting data transmission

0.5s

Total overhead 1.0956s

The overhead in terms of bytes added by our frame-

work to translate ns-2 packets into data modem payloads

is only one byte. Such extra byte is used to store the ns-2

packet type thus appropriately handling the packet once

received at the destination node.

B. Sea testing

Tests performed using the WHOI lab test-bed were

not considering the actual propagation delay for acoustic

underwater transmissions. Differently from radio terres-

trial networks, it is not negligible. In order to estimate

how the proposed framework is working with real sea

testing, keeping into account also the propagation delay,

we have performed three different tests at the sea using

fours WHOI gateway buoys (Figure 4). Tests have been

conducted in front of Quisset Harbour, which is located

off Buzzards Bay about one mile northeast of Woods

Hole. Different node locations (see Figure 7) have been

considered in order to have different distances among the

nodes. For each tests all nodes were able to hear from

each others and they were transmitting using Micro-

Modems packet type 2, whose size can be set equal

to 64, 128, 192Bytes and uses PSK modulation. During

each test we left the nodes out for two days, letting them

exchanging information. Nodes were first transmitting in

a round robin way: One node was acting as transmitter

for 30 minutes, transmitting a data packet every 25s,

while other nodes were listening to the channel and col-

lecting information thus estimating the actual quality of

the links among the nodes. Then nodes started contend-

ing for the channel. Node 1 was working as collecting

point (sink) and the other three nodes were trying to

reserve the channel, using the CSMA MAC protocol we

have implemented, to deliver data packets to the sink.

We have considered different traffic loads in order to

evaluate the system performance when increasing the

system overhead. Traffic was generated according to a

Poisson process with aggregate (network-wide) rate λ

packets per seconds. Considering the normalized packet

rate as λ = λTdata (Tdata is the transmission delay

related to the data packet), the considered values were

in the range 0.05 to 0.2 packets per packet time.

In all the considered cases, the delays added by our

framework to exchange information between the differ-

ent modems was really short, it was in the range 0.01

to 0.08 seconds as for the tests at the WHOI laboratory.

This make us to believe that the proposed framework is

lightweight enough to be used for both simulations and

real-life testing.

C. Other testing

Other tests have been conducted, in collaboration with

NURC in the past months, in order to explore the flex-

ibility of the proposed framework when using different

acoustic modems and mobile nodes. We have conducted

various tests during ACommsNet10 experiment in the

waters surrounding Pianosa island (September 2010) us-

ing FSK Micro-Modems [7]. During such sea trial, Gum-

stix devices running our framework were also embedded

inside Folaga AUVs (produced by Graaltech [17]). Our

tool was used to collect information from the AUVs

and to broadcast these information to other nodes in the

network thus monitoring AUV operations. In November

2010, Evologics modems have been considered and the

implemented driver has been tested in the swimming

pool available at NURC. Additionally, in March 2010

more tests with Folaga AUVs have been conducted. This

time we were using our framework to send commands to

the AUV via acoustic links thus instructing the vehicle to

perform the requested operations. All the conducted tests

have shown that, once APIs are provided to control the

operation of acoustic modems, mobile nodes, sensors,

etc., the time needed to design and implement the spe-

cific driver is very short and proportional to the complex-

ity of the operations required by the specific hardware.

The extra code required to interface a new modem or

hardware to the framework ranges from few hundreds to

thousands lines of code and can be implemented within

a week. Once the driver is ready, the external hardware

can be plugged and tested in lab and water without any

further code change. Therefore, with a really minimal

efforts we can use and test different protocol stacks

on different static and mobile nodes, assuming different

acoustic modems for communications.

V. CONCLUSIONS

In this paper, we presented a new generic architecture

to simulate, emulate and test new protocols for underwa-

ter sensor networks in real life experiments. Using the

proposed framework, the code written for simulation test

with ns-2 [1] can be reused to perform real tests in the

water. This will make easier for the networking com-

munity to design and test protocol stacks. Researchers

can first implement their solutions using a free and well

known simulator like ns-2, in order to perform prelim-

inary simulation tests to validate the protocols. They

can then port the code on real devices (we have used

Gumstix [2]), interfaced with real acoustic modems, thus

evaluating the protocol performance in a real testbed.

different acoustic modems can be used at the limited

cost of implementing new drivers for the interaction

between ns-2 and the modem. Preliminary tests have

been conducted in order to verify the feasibility of the

proposed architecture using PSK and FSK WHOI Micro-

Modems [3]. Other tests in the laboratory have already

been conducted using Evologics modems [4] and Folaga

AUVs [?]. The tests we have conducted have shown very

promising results. The proposed framework turned out to

be a very powerful tool quickly design, implement and

test protocols, allowing us to implement new protocols,

and interface the framework with new modems with very

limited effort. The delays introduced by the framework

are of the order of millisecond and the extra overhead

due to framework operations is extremely limited, just

(a) Test 1 (b) Test 2

(c) Test 3

Figure 7. Sea tests: The yellow squares represent the node locations.

one extra byte per packet.

ACKNOWLEDGMENTS

This work was supported in part by the EU FP 7

STREP project CLAM “CoLlAborative EMbedded Net-

works for Submarine Surveillance ”. The authors grate-

fully acknowledge the Nato Undersea Research Centre,

La Spezia, Italy, for the help and support provided during

the tests conducted at NURC.

REFERENCES

[1] The VINT Project, The ns Manual.http://www.isi.edu/nsnam/ns/, 2002.

[2] “Gumstix inc.” [Online]. Available: http://www.gumstix.com

[3] L. Freitag, M. Grund, S. Singh, J. Partan, P. Koski, andK. Ball, “The whoi micro-modem: An acoustic commu-nications and navigation system for multiple platforms,”http://www.whoi.edu/micromodem/, 2005.

[4] Evologics, “Evologics s2c acoustic modems.” [Online].Available: http://www.evologics.de/

[5] K. maritime, “Instruction manual cnodemaxi transponder.” [Online]. Available: http://www.km.kongsberg.com/ks/web/nokbg0397.nsf/AllWeb/4ADD212486A1B94EC125780000355234/

[6] B. Tomasi, G. Zappa, K. McCoy, P. Casari, and M. Zorzi,“Experimental study of the space-time properties of acousticchannels for underwater communications,” in Proceedings of

IEEE OCEANS 2010, Sydney, Australia, May, 24–27 2010.

[7] C. Petrioli, R. Petroccia, and J. Potter, “Performance evaluationof underwater mac protocols: From simulation to at-sea testing,”in Proceedings of IEEE OCEANS 2011, Santander, Spain, June,6–9 2011.

[8] S. Basagni, C. Petrioli, R. Petroccia, and M. Stojanovic, “Choos-ing the packet size in multi-hop underwater networks,” in Pro-

ceedings of IEEE OCEANS 2010, Sydney, Australia, May, 24–272010, pp. 1–9.

[9] Z. Peng, J.-H. Cui, B. Wang, K. Ball, and L. Freitag, “An un-derwater network testbed: Design, implementation and measure-ment,” in Proceedings of the third ACM International Workshop

on UnderWater Networks (WUWNet ’07), Montreal, Quebec,Canada, September 14 2007.

[10] Z. Peng, Z. Zhou, J.-H. Cui, and A. Shi, “Aqua-Net: Anunderwater sensor network architecture: Design,implementation,and initial testing,” in Proceedings of MTS/IEEE OCEANS 2009,Biloxi, Mississippi, USA, October, 26–29 2009.

[11] S. Shahabudeen, M. Chitre, M. Motani, and A. L. Y. Siah,

“Unified simulation and implementation software frameworkfor underwater MAC protocol development,” in Proceedings of

MTS/IEEE OCEANS 2009, Biloxi, Mississippi, USA, October,October,26–29 2009.

[12] D. Torres, J. Friedman, T. Schmid, and M. B. Srivastava,“Software-defined underwater acoustic networking platform,” inProceedings of the Fourth ACM International Workshop on Un-

derWater Networks (WUWNet ’09), Berkeley, California, USA,November 3 2009, pp. 7:1–7:8.

[13] Open Source Community, embedded Linux wiki - A wiki

for developers using Embedded Linux. [Online]. Available:

http://elinux.org/[14] R. Urick, Principles of Underwater Sound. McGraw-Hill, 1983.[15] M. Porter et al., “Bellhop code.” [Online]. Available: http:

//oalib.hlsresearch.com/Rays/index.html[16] WHOI, “Acoustic communications group, micro-

modem software interface guide (ver 3.02),.” [On-line]. Available: http://acomms.whoi.edu/documents/uModem\%20Software\%20Interface\%20Guide.pdf

[17] Graaltech, “Folaga.” [Online]. Available: http://www.graaltech.it/en/index.php