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