SUNSET: Simulation, Emulation and Real-life

Testing of Underwater Wireless Sensor

NetworksChiara Petrioli∗†, Roberto Petroccia∗†

∗ Dipartimento di Informatica

Universita di Roma “La Sapienza,” Roma, Italy

{petrioli,petroccia}@di.uniroma1.it† Consorzio Interuniversitario Nazionale per l’Informatica (CINI), Roma, Italy

Abstract—The emerging demand for pervasive underwa-ter monitoring and control systems has stimulated researchon network protocols for underwater acoustic sensor net-works. Several solutions have been proposed in the last fewyears at the different layers of the protocol stack. Howeverhaving a complete and accurate understanding of the per-formance of these protocols is not an easy task. The missingtool is a standard platform to easily simulate, emulate andtest in field novel protocol solutions. This platform shouldallow researchers and developers to be able to compareand evaluate different network designs, algorithms andprotocols in a variety of settings and application scenarios.It should also allow to validate and improve the simulationprocess itself according to the results obtained at-sea. Withthis objective in mind, we have developed a framework,named SUNSET, to seamlessly simulate, emulate and test(at-sea) a variety of communication protocols. SUNSETis based on the open source and well known networksimulator ns-2 [1] and its extension ns2-Miracle [2]. Itallows to easily implement novel solutions, to investigateprotocol performance through ns-2 simulations and to thenuse the same code for emulation and at sea testing withoutany code rewriting. SUNSET has been extensively validatedand evaluated during at sea experimental campaigns inthe past few years. Experiments have been performedwith SUNSET running on different platforms and work-ing with different external devices: off-the-shelf acousticmodems, environmental sensors, autonomous underwaterand surface vehicles. This paper describes SUNSET and itsextensions, recently released open source to the scientificcommunity [3], and describes the results of some of therecent experiments we have performed using it.

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

I. INTRODUCTION

Underwater sensor networks (UWSNs) have become

an important area of research with potential practical

impact on a host of different applications, including

monitoring and discovery of the marine environment,

remote control of submarine oil extraction, underwater

safe CO2 storage, coastline protection, and prediction of

underwater seismic and volcanic events [4]–[6].

Several solutions have been proposed in the past years

implementing and investigating new networking proto-

cols for UWSNs. The performance of these protocols

have been evaluated by means of simulations or real-

life tests using different simulation tools and framework

architectures, assuming different attenuation and prop-

agation models when simulating the acoustic channel,

making different assumptions when modeling the sys-

tem, etc. It is therefore really difficult to use previous

experiments and to compare the obtained results to get

a clear and fair opinion of the champion solutions.

Furthermore, when moving form simulation to real-life

tests, solutions have to be usually re-implemented and

improved to work with real hardware. Following such

approach simulation results can be really different from

what obtained through real-life testing.

Research and development of innovative solutions for

underwater networks would greatly benefit from a stan-

dard platform which can be used to test, evaluate, and

compare different protocols, providing also the possibil-

ity to use the same code when performing both sim-

ulation and real-life testing, thus avoiding any possible

errors in code rewriting. The presence of such a platform

is a key asset to speed up innovation in the field.

We have therefore proposed, implemented and exten-

sively evaluated in field a complete framework for

UWSN simulation, emulation and real-life testing. The

framework has been originally presented and tested

in [7], [8] and it has been significantly extended and

improved in the recent past leading to the creation of a

new framework, named SUNSET for Sapienza Univer-

sity Networking framework for underwater Simulation

2

Emulation and real-life Testing, which has been released

open source [3]. SUNSET is based on the open source

and well known network simulator ns-2 [1] (and its

extension ns2-Miracle [2]). Using SUNSET, researchers

and developers can first implement, evaluate and improve

their solutions using a well know network simulator.

They can then seamlessly use the same code in emulation

mode, adopting real hardware for data transmission and

additional external devices for sensing and navigation

operations.

SUNSET has been extensively validated and evaluated

at sea in the past years showing really promising results.

Several tests have been conducted to verify the feasibil-

ity of the proposed emulation framework: It has been

tested running on PC and on four different embedded

platforms; it currently supports five different acoustic

modems, several sensing devices and two underwater

mobile vehicles. Integration with an additional underwa-

ter vehicle and with a surface vehicle is currently under

test. All the collected results have shown that SUNSET

is a really powerful, reliable and flexible solution to be

used for both simulations and at sea tests.

The rest of this paper is organized as follows; Sec-

tion II describes the state of the art of testbeds and em-

ulation frameworks for underwater networks. A detailed

description of the proposed framework is presented in

Section III. In Section IV we report the results collected

to validate and evaluate SUNSET during in field testing

activities of the past years. Finally, concluding remarks

are given in Section V.

II. RELATED WORKS

Different underwater acoustic sensor network frame-

works have been proposed in the past as platforms to

evaluate new protocol solutions for UWSNs [9]–[11].

These frameworks allow to integrate the use of acoustic

modems with a software defined protocol stack. In [11],

the same C code implementation of the developed MAC

protocols is used in both the simulator and the modem,

avoiding any code rewriting. The limit of all these

solutions is that in order to use them to test new protocols

developers have to study proprietary architectures and

software. This is usually not trivial and it means that

protocol code usually needs to be rewritten to test it in

different settings, which in turn limits accessibility to

testing facilities.

A first work along the lines of our contribution is [12].

Authors investigate the use of an open source platform

to create a simulation/emulation tool for UWSNs. A

new platform, named UANT, is proposed which is based

on GNU radio, a software defined radio framework,

interfaced with a PC running TinyOS (or TOSSIM in

case of simulation/emulation). TinyOS or TOSSIM run

the underwater communication protocol stack while the

GNU radio transmits the waveform on the acoustic

channel using an acoustic transducer. The use of GNU

radio allows to test the impact on performance of a

large set of supported modulation schemes including

GMSK, PSK, QAM, OFDM etc. UANT is an interesting

concept. However, since it uses GNU radio which is

computationally expensive, it needs to run on a PC which

is unlikely to be used in real-life experiments due to

housings constraints. Moreover, to run on TinyOS, the

protocol design has to follow rules which reflect features

of IEEE 802.15.4 devices and which differ from features

and constraints of underwater nodes and underwater

communication devices.

In [7] we have presented and investigated, through lab

and at sea tests, the first simulation/emulation tool based

on ns-2. We have then improved this tool in [8], porting

it to work on ns2-Miracle, thus making use of a more

accurate model for the underwater acoustic channel.

In [8] we have also performed a first investigation on

the gap between actual at-sea and simulation networking

performance, showing how to reduce this gap improving

simulation accuracy.

Recently, a simulation/emulation tool based on the

same idea we have proposed in [7], [8] has been

proposed in [13], together with the implementation of

MAC and Routing solutions for UWSNs. With respect

to SUNSET, the solution proposed in [13] has not

been extensively tested in field and, according to our

understanding, still lacks the needed improvements to ns-

2 and ns2-Miracle to efficiently move from simulation to

real-life tests. It uses a less efficient real-time scheduler

which incurs in longer additional delays when running

in emulation mode. Moreover, a flexible and efficient

module to convert the ns-2 packet to a stream of bytes

for actual transmission in water is missing, introducing

a higher overhead when running in emulation mode.

III. SUNSET

The Sapienza University Networking framework for

underwater Simulation, Emulation and real-life Test-

ing (SUNSET) is a novel solution developed to seam-

lessly simulate, emulate and test at sea communication

protocols. It is based on the open source and well

known network simulator ns-2 [1] (and its extension

ns2-Miracle [2]), which is largely used by the research

community. SUNSET has been recently released open

source to the scientific community [3]. Using the pro-

posed framework, anyone willing to implement its so-

lution for simulation experiments using ns-2 can use

the same exact code in emulation mode, adopting real

3

acoustic modems for data transmission and additional

external devices for sensing and navigation operations.

Developers and researchers can run tests changing the

selected protocols (MAC, Routing, etc.) and the protocol

parameters without any change in the external devices

code. At the same time they can change the configura-

tion parameters of the selected communication hardware

without any change in the actual protocol stack.

The effort required by researchers and developers

using SUNSET to evaluate their protocol solutions is

really limited. The design and implementation of novel

solutions in SUNSET follows the same basic rules of

the well known ns-2 and ns2-Miracle simulators. New

functionalities are then provided by SUNSET to schedule

events, to compute protocol timeouts and packet sizes,

to log information either for debugging or statistical

purposes, to allocate and deallocate the used memory,

to convert data to the format used by real devices and to

control external device operations. These new function-

alities can be easily integrated in the implementation of

the protocol solutions and allow to move from simulation

to emulation and real-life tests in a transparent way.

When running simulations SUNSET can use different

underwater acoustic channel models, such as empirical

formulas [14] and Bellhop ray tracing [15] via the

WOSS [16] interface. Integration of new, more accurate

channel models through proper interfacing to SUNSET

is on going.

When running in emulation mode instead, SUNSET is

interfaced with real external hardware: Acoustic modems

for underwater communication; sensing platforms for

data collection; the navigation system of AUVs (Au-

tonomous Underwater Vehicles) and ASVs (Autonomous

Surface Vehicles) to control the vehicle; etc. The de-

signed architecture is flexible and open enough to allow

the integration of whatever external device once APIs are

provided to control its operations. Using these APIs, a

driver to properly handle the device functionalities, data

exchanges and interaction with the specific device can

be easily implemented. This driver allows to interface

the device to SUNSET and to use it once plugged to the

proposed architecture.

Drivers for different acoustic modems have al-

ready been implemented and tested: WHOI Micro-

Modems [17]; Evologics modem [18] and Kongsberg

modem [19]. A driver for the Teledyne Benthos mo-

dem [20] has also been implemented and it is currently

under testing. Moreover, different sensing platforms and

vehicles have already been interfaced to SUNSET: En-

vironmental underwater sensors for temperature, CO2

and methane concentrations [21]; MARES AUV and

ASV [22] (developed by the INESC TEC/University

of Porto), Folaga AUV [23] (developed by Graaltech).

For each of these devices, specifics drivers have been

implemented and tested in field.

SUNSET has also been successfully ported on small

portable devices (gumstix, PC104 or other ARM-based

systems), thus allowing the user to embed it inside

modem or AUV housings, making easier the deployment

at sea.

Using the acoustic communications and networking

capabilities provided by SUNSET, acoustic data packets

can be delivered to whatever device (sensor nodes,

mobile vehicles, buoys and gateways) in the network.

Data, requests and commands can be transmitted to a

remote static or mobile node thus allowing the control

of the device using acoustic links in a real-time, on-line

way. This approach provides the needed tool for the fast

development and testing of new solutions for a swarm

of (heterogeneous) vehicles dynamically behaving and

cooperating together to accomplish a given task [24].

In what follows we describe in detail the SUNSET ar-

chitecture, explaining and motivating the different solu-

tions we have considered to easily move from simulation

to emulation and at sea tests. We first introduce our ex-

tensions and improvements to the ns-2 and ns2-Miracle

simulators. We then explain the operations needed when

moving from running simulations to performing emula-

tion and at sea tests.

A. Extending the ns-2 and ns2-Miracle simulators

Ns-2 [1] is a well established and reliable discrete

event network simulator, which is widely used by the

academic networking research community for its exten-

sibility (due to its open source model) and rich online

documentation.

Figure 1: Network simulator architecture.

Figure 1 presents the main ns-2 components. It uses a

discrete event scheduler and Tcl as its scripting language.

OTcl, an object-oriented dialect of Tcl, is used to execute

command scripts, while Tclcl is used to link C++ and

OTcl classes. The user describes a network topology by

writing Tcl scripts, and then the main ns-2 program

4

(a) SUNSET modules in simulation mode. (b) SUNSET modules in emulation mode.

Figure 2: SUNSET architecture: Simulation and emulation mode.

simulates the operations of the network in the given

topology and with the specified parameters. Changes

in the network configuration and settings can occur

using Tcl code without the need to recompile the C

and C++ code. Each network node, as implemented in

ns-2, is made up of different components representing

the different protocol stack layers: Application, Routing,

Data Link and Physical. Using ns-2, the advance of time

in the simulation depends on the timing of events which

are maintained by the event driven scheduler (Figure 1).

The scheduler keeps an ordered data structure with the

events to be executed and an associated time when the

event should occur, and fires such events one by one.

If two events are in the scheduler, one scheduled for

execution at time T and the other at time T ′ > T ,

and there are no events to be scheduled between T

and T ′, after the scheduler executes the event at T , it

instantaneously changes the simulator time to T ′ and

executes the event at T ′. Ns-2 supports also the use of a

basic real-time scheduler which forces the system to wait

for the actual T ′−T seconds before scheduling the next

event. However, using the basic ns-2 real-time scheduler,

it is not possible to accept any new external event, such

as the reception of data from an external device, while

the system is waiting for the next event to be scheduled.

An extension of ns-2, named ns2-Miracle, has been

proposed in the recent past making use of the same event

driven scheduler and scripting languages. Ns2-Miracle

provides a set of libraries designed to enhance the ns-2

functionalities. It supports cross-layer messages for the

communication between different layers and allows the

coexistence of multiple solutions within each layer of

the protocol stack. The ns2-Miracle framework therefore

makes easier the implementation and the simulation of

modern communication systems in ns-2.

We have extended and improved ns-2 and ns2-Miracle

when running in simulation mode (Figure 2a) and we

have developed new modules to let SUNSET interact

properly with real devices when running in emulation

mode (Figure 2b). First of all, we have allowed the

use of multiple threads when running in emulation

mode, so that, the main thread runs the protocol stack

while secondary threads listen to communications from

external devices. We have then implemented a new real-

time scheduler to more accurately capture the elapsed

time, making it possible for secondary 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.

When multiple solutions are considered at a given

layer, a controller module for that layer has to be

implemented which selects the specific solution to run.

The selection can depend on upper layer information

(the upper layer identifies the specific solution to use) or

lower layer information. For instance if channel quality

and link reliability information are provided by the lower

layers the MAC controller can select the MAC protocol

which results in best performance in the current channel

conditions.

New modules have also been designed and imple-

mented to make the execution of simulation and em-

ulation easier and more transparent to the user. Some

of these modules are used for both simulation and em-

ulation (Timing, Utilities, Debug and Statistics); others

are only needed when using real hardware (Packet Con-

verter, Drivers). Moreover, when running in simulation

mode an improved version of the interference model

has been provided to more accurately capture packet

interference effects. A description of the improvements

and of the new modules is presented below.

- Interference model

In its original version, the ns2-Miracle framework

was assuming an over-simplistic packet interference

model, which impaired the correct computation of the

5

bit/symbol/packet error rates. When two or more packet

receptions were overlapping at a given node, the ns2-

Miracle network simulator was averaging the inter-

ference of the interfering packets throughout the en-

tire packet and assuming such interference constant

for SINR computation. In this way, a single under-

estimated interference value was considered over the

entire packet instead of different higher interference

values over the exact packet chunks where the packets

overlapping was occurring. We have implemented an

improved packet interference model (Figure 2a), within

the CLAM project [25], together with the SIGNET Lab

of the University of Padova, and made this improvement

available to the community in the latest version of ns2-

Miracle. In the improved packet interference model, if

the interference level varies throughout the duration of

a packet, the typically different error rates that result

are separately accounted for in the computation of the

overall packet error rate. Therefore, the error probability

is now computed over the separate chunks having the

same interference level. Chunk-per-chunk packet error

rate computation is more precise in the presence of

bursty interference (e.g., short signaling packets).

- Timing module

When running simulations, the delays related to the

use of real devices are usually ignored. These delays

include: 1) Computational delay; 2) Operational delay

related to internal operations of the considered device

(acoustic modems, embedded device used to run the

application, other external devices); 3) Delays related

to the communication between different hardware com-

ponents on the same node. These aspects have to be

kept into account when tuning the protocol parameters

before real-life tests. Moreover, it is not always true that

the message size sent by the external device exactly

corresponds to the original message size, because of

coding performed by the device, headers that are added

and constraints on the final packet size to be transmitted.

For instance, the packet length of FSK Micro-Modems

is fixed to32 Bytes, which means that if the length of

the message to be transmitted, let’s say k, is shorter

than 32 Bytes, a 32 Bytes message is transmitted in

water with (32 − k) Bytes filled with zero. This means

that also the transmission delay is strictly dependent

on the considered device. For this reasons, we have

implemented a timing module modeling external device

delays and overhead when running both in simulation

and emulation mode. The timing module is used by the

different layers to get information on the actual device

delays and packet transmission delay when computing all

the timeouts used by the protocol stack. Moreover, con-

sidering real hardware additional overheads and delays

when running simulations allows us to better evaluate the

protocol performance in a given scenario, significantly

reducing the gap between actual at-sea and simulation

results. If these overheads and delays are ignored the

gap is significantly larger [8].

- Utilities module

To make transparent to the users the use of the frame-

work in simulation and emulation mode a utilities mod-

ule has been implemented. It is responsible to schedule

events and update timing information according to the

used scheduler, i.e., event driven scheduler, if running in

simulation mode, and the real-time scheduler, if running

in emulation mode. Moreover, the utilities module is also

responsible to properly deallocate the memory allocated

for a ns-2 packet.

- Debug module

When developing and testing a novel solution, it is

always useful for both developers and users to log and

process debug information. We have therefore developed

and implemented a debug module which allows to assign

to each information to log a debug level. When the

user starts the experiment it can define the debug level

of the information it wants to log. If debug level k

is selected, it means that only the information with an

assigned debug level lower or equal to k are logged. This

module also allows to change the debug level on demand

thus increasing and reducing the logged information

according to the user needs.

- Statistics module

To allow the user to collect statistical information to

evaluate the protocol performance, a statistics module

has been designed. This module allows the user to collect

all the information about packet transmissions and re-

ceptions, energy consumption, additional delays (backoff

period, device delays, etc.) and others. The user can

then easily compute all the metrics (per node or in the

network) it is interested in: Packet delivery ratio, network

throughput, packet latency, energy consumption, etc.

Moreover, the developers can easily extend the provided

statistics module to include additional information of

interest. When running in simulation mode, the statistics

module collects the information from all the nodes in the

network and all the required metrics are available at the

end of the simulation. When running in emulation mode,

however, each node is an independent unit, storing its

own information. For this reason, these information have

to be merged together with a post processing analysis.

Additional tools for data post processing have already

been implemented and used.

6

- Packet converter module

Each ns-2 packet header is a data structure containing

all the information used by the specific protocol layer.

When simulating packet transmissions the exchanged

packet header size does not need to match the actual

size of the header according to the packet data structure.

This allows to add several information to the packet

header (e.g., for statistic or debugging purposes) without

affecting the simulated packet size and the protocol

performance. Moreover, no particular attention is usually

given in ns-2 to the specific sizes used to store the packet

header information. For instance, if a specific packet

header parameter has been defined equal to 4 bits, a

larger data type (int, long, etc.) can be used to store

that value, making easier the protocol implementation

without the need to handle bit shifting operations. When

running in emulation mode or testing solutions at sea

it is instead critical to compress the header as much as

possible. We have therefore designed a new module for

ns-2 packet conversion (Figure 2b), which convert ns-

2 packets into a stream of bytes and vice versa, com-

pressing the information in the header to the minimum

size. When defining a packet header also the methods

for conversion and reconversion have to be provided. In

this way the developer who designs the packet header

is also responsible for making decisions on the subsets

of information which should be converted, how and on

the final resulting size of the header. Our approach is

flexible enough to allow the user to decide through the

Tcl script what are the packet header information to be

considered or discarded in the conversion process and

what size has to be assumed for the different values. To

reduce as much as possible the information transmitted

in water and improve the channel utilization each field

of the packet is expressed with a precision to the bit.

- Generic Driver module

When running in emulation and testing mode com-

munication happens through real devices, i.e., acoustic

modems. A “generic driver module” has been imple-

mented to take care of the modem interactions with ns-2.

This module is a generic interface. Each driver for a spe-

cific device extends the generic device and implements

the different operations related to the specific driver

using a language known by the specific acoustic modem.

The generic driver module implements the connection to

the external device and the basic operations that have to

be performed when transmitting and receiving data. It

uses the packet converter functionalities to convert ns-

2 packets in streams of bytes for the specific device

and vice versa. The generic driver module computes

also the timing information specific to the used device

which have to be provided to the timing module for

correct timeout computation at the upper layers. Using

the generic driver module, together with the timing

module and the packet conversion module, the presence

of a simulated channel or of a real device is transparent to

the protocol stack and no change is needed when moving

from simulation to emulation mode.

- Application drivers

SUNSET architecture is flexible enough to allow fast

integration not only with real acoustic modems but

also with different types of devices, such as sensors

for underwater measurements and AUV (Autonomous

Underwater Vehicle) or ASV (Autonomous Surface Ve-

hicle) navigation control systems. As for the acoustic

modems, a driver is needed at the application layer to

properly manage the device functionalities, in order to

properly handle data exchanges and interactions with

the selected devices (see Figure 2b). The application

driver is a generic interface which provides the methods

to set and get parameters from the connected device

and to execute the desired actions. A device specific

customization of the application driver is needed in order

to translate the generic actions in a set of instructions

known by the specific device. Once a driver for the

given device has been implemented, the new hardware

can be plugged to the SUNSET architecture and it is

ready to be used. Using the acoustic communications and

networking capabilities provided by SUNSET, requests

and commands can be delivered to a remote node (via

single-hop or multi-hop transmissions), thus allowing

remote control of the device using acoustic links in a

real-time and on-line way.

B. From simulation to emulation and at sea tests

When running simulations, the user has the complete

control on the system and on the network. Using the

Tcl script, the user can design the network (number

of nodes and locations), can select the protocol stack

and protocol parameters (number of transmission retries,

packet sizes, queue length, etc.) and can configure the

simulated devices: Acoustic modem (frequency, band-

width, bit rate, energy consumption, additional delays

and overheads, etc.); platform running the system (ad-

ditional delays and overheads of the used PC, gumstix,

etc.); any other device (static or mobile) assumed to be in

the network. When running in emulation mode instead,

the simulated devices are replaced by the use of the real

hardware connected to the node. The simulated channel

is substituted by the driver for the used acoustic modem

and if sensor platforms or mobile devices are connected

to the node, the related drivers and additional modules

7

(a) Simulation: Event driven scheduler. (b) Emulation: Real-time scheduler.

Figure 3: SUNSET running in simulation and emulation mode.

have to be loaded and configured. The Tcl script this time

refers to a single node instead of the entire network. With

the exception of hardware dependent settings, the user

is able to perform the exact same node configurations

(protocol settings, additional delays and overheads due

to the use of real hardware when computing protocol

timeouts, etc.) also in emulation mode. If the constraints,

additional delays and overheads related to the use of real

hardware are properly modeled in simulation (using the

timing module and setting the proper packet sizes), the

only actions and changes in the Tcl script required by

the user when moving to emulation are: Loading the

specific drivers for the connected devices; providing the

proper values for packet conversion operations to have

real packets matching the size of simulated packets.

Figures 3a and 3b show the use of our framework

for simulation and emulation, respectively. When run-

ning in simulation mode (Figure 3a), the event driven

scheduler is used with a simulated acoustic channel

and propagation model (by means of Urick’s formulas,

ray tracing models or others). One single instance of

the SUNSET application simulates an entire network

with an arbitrary number of devices. While in emulation

or testing mode, the real-time scheduler is used and

real hardware replaces the simulated underwater channel

(Figure 3b). Each node in the network runs an instance

of SUNSET which emulates its own behavior, according

to the selected protocol stack, and has to run on its own

hardware. It is also possible to have more instances of

SUNSET running on the same device but each of them

has to be connected to its own acoustic modem and to

other node components, such as sensors and AUV or

ASV control system.

IV. SUNSET EVALUATION AND VALIDATION

SUNSET has been extensively validated and evaluated

during in field testing activities of the past years. Several

tests have been conducted to verify the feasibility of

the proposed emulation framework and its capability to

work with different external devices. Different proto-

col solutions have been considered at the MAC layer:

CSMA [26], T-Lohi [27], DACAP [28], TDMA; at the

routing layer: Flooding based solutions, an improved

version of the routing solution presented in [29]; a

new cross-layer solution (the Channel Aware Routing

protocol (CARP) [30]). Moreover, the use of differ-

ent hardware has been deeply investigated: Commercial

acoustic modems, mobile vehicles and sensing platforms.

The additional delays introduced by SUNSET are of the

order of milliseconds with an additional overhead per

packet of just few bits for proper packet coding and

decoding.

All the at sea tests have shown that using SUNSET

is extremely easy, once APIs are provided to control the

operation of devices (acoustic modems, mobile nodes,

sensors, etc.) The time needed to design and implement

the specific driver is very short and proportional to the

complexity 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 in water without any further code change. Therefore,

SUNSET allows to use and test different protocol stacks

on different static and mobile nodes, assuming differ-

ent acoustic modems for communications with a really

minimal effort.

SUNSET has been significantly improved over time,

according to what learned during in filed tests, to make

it a powerful and flexible solution to be used not only as

an improved simulation tool but especially as a complete

framework for real-life testing. In what follows we pro-

vide more details on the conducted testing activities in

chronological order to let the reader understand SUNSET

experimental validation over time and the investigated

improvements and extensions.

- Tests conducted during 2010

WHOI. First version of SUNSET has been tested at the

Woods Hole Oceanographic Institution (WHOI) in July

2010 to evaluate the feasibility of our approach. Four

modems have been used (WHOI gateway buoys - Fig-

ure 4 - equipped with PSK Micro-Modems [17]) in the

WHOI laboratory and at open sea, considering different

8

Figure 4: WHOI gateway buoys used for our tests (we

used 4 of them).

traffic loads and scenarios. A CSMA MAC protocol [26]

has been considered during these tests. Before going to

sea, several tests have been performed using the WHOI

lab test-bed (Figure 5), which combines gumstix moth-

erboard, WHOI PSK acoustic Micro-Modem, a mixer

(mimicking the acoustic channel) and a PC to control

the system. The objective of our first set of tests was

to evaluate overhead and delays introduced by SUNSET

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. The WHOI lab test-

bed, however, is not able to emulate the propagation

delay for acoustic underwater transmissions. Differently

from radio terrestrial networks, it is not negligible and

it has a strong impact on the MAC protocols design. In

order to estimate how SUNSET was working during real

sea testing, keeping into account also the propagation

delay, different tests at sea have been performed using

the fours WHOI gateway buoys. Different node locations

have been considered in order to have different distances

and propagation delays among the nodes.

Figure 5: WHOI lab test-bed.

In all the considered cases, the delays added by

SUNSET to exchange information between the different

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

0.08 seconds as for the tests at the WHOI laboratory,

with an additional overhead per packet of few bits for

packet coding and decoding. Additional details can be

found in [7].

CMRE ACommsNet10. Based on the obtained results

and the lessons learned during the WHOI tests, SUNSET

has been then improved and extended in September

2010 at the NATO Centre for Maritime Research and

Experimentation (CMRE) of La Spezia, Italy. New MAC

solutions have been implemented and tested (T-Lohi

and DACAP) using an improved version of the timing

module and of the packet converter module. Various tests

have been conducted in the waters surrounding Pianosa

island, part of a protected marine park on the west coast

of Italy, during the CMRE ACommsNet10 experiment

in September 2010. During these tests SUNSET has

been interfaced with different devices and platforms: 1)

Three WHOI FSK Micro-Modems installed on bottom-

mounted tripods (cabled ashore); 2) one WHOI gateway

buoy (connected by radio), upgraded with a gumstix

processor; 3) the CMRE CRV Leonardo, with a PC in the

laboratory on board, connected by LAN to the acoustic

modem (deployed through her moon pool) and controlled

via a radio link from land; 4) two Folaga AUVs (Figure 6

- produced by Graaltech [23]) equipped with gumstix; 5)

a “MANTA” portable modem system devised by the Un-

derwater System and Technology Laboratory (LSTS) at

the University of Porto, consisting of an acoustic modem,

a small PC and a radio interface [31]. A driver for the

WHOI FSK Micro-Modem [17] has been implemented

for SUNSET and extensively tested. The Folaga AUV

and the MANTA portable system, carried around by

a Rigid Hull Inflatable Boat (RHIB) and connected to

the shore laboratory by freewave radio, have been used

as mobile platforms. Moreover, SUNSET has been ex-

tended to collect information from the navigation system

of the Folaga AUV and to transmit such information to

the central control station.

CSMA, DACAP and T-Lohi have been tested un-

der various types of application loads and application

scenarios: 1) Static single-hop data sink. Three static

nodes transmitting packets to a common sink node; 2)

Static multi-hop data sink. Two static nodes transmitting

packets to a common sink node via an intermediate static

node; 3) Mobile single-hop data sink. Both static and

mobile nodes transmitting packets to a common sink

node. The number of nodes involved in the different

experiments ranged from 4 to 6, all equipped with WHOI

FSK Micro-Modems.

9

The exact same scenarios and settings used during

the in field tests have been then simulated in order to

compare simulation and at-sea trial results. While testing

SUNSET performance we had two additional objectives.

First, we wanted to perform a thorough experimental

evaluation of some of the best known MAC protocols

(CSMA, T-Lohi and DACAP) in various scenarios. The

goal was to assess the impact of different design choices

and the pros and cons of exchanging higher amounts

of control information to limit collisions, in different

practical settings. Our second objective was to quantify,

and limit as much as possible the gap between simulation

results and at-sea experiments.

Figure 6: Folaga AUV.

For all the considered cases (different platforms, num-

ber of nodes in the network and traffic load), the im-

proved version of SUNSET was running the networking

protocol stack exchanging information between the dif-

ferent modems with an additional delays in the order of

tens of milliseconds and additional overhead per packet

of few bits, proving again that the proposed framework

is lightweight enough to be used for both simulations

and real-life testing. The obtained results showed that

acoustic modem constraints, additional delays and over-

heads can strongly impact MAC protocol performance.

Moreover, the conducted comparison between simulation

results and experimental data showed significant gaps

when the detailed operations, limitations and delays of

the acoustic modem (FSK WHOI Micro-Modem in this

case) were not included. Once the delays related to the

different components involved during the experiments

were included and the proposed timing module was

properly set, the gap between experimental at-sea traces

and simulation results reduced significantly. This makes

us believe that simulations can be used to predict real-

life performance at sea, provided that care is taken in

capturing all the important acoustic propagation physics

and the physical attributes of the hardware used in the ex-

periment. Ignoring the actual delays and overhead related

to the specific acoustic modem used for the experiments

and ignoring the effect they have on the protocol stack

setting can result in bad protocol settings and selections,

degrading the network performance. Additional details

can be found in [8].

Evologics. In November 2010 support for Evologics

modems [18] has also been included in our framework

and the related driver for the modems version S2C R

with networking firmware 1.4 has been designed, imple-

mented and tested in the swimming pool available at the

NATO Centre for Maritime Research and Experimenta-

tion.

- Tests conducted during 2011

Folaga. During the the CMRE ACommsNet10 experi-

ment, SUNSET running on gumstix devices was inter-

faced with the navigation system of the Folaga AUV

(Figures 6). During those tests, SUNSET was used to

collect information from the AUV and to broadcast these

information to other nodes in the network in order to

monitor AUV operations. In March 2011 more tests with

the Folaga AUV have been conducted in the laboratory

at CMRE. A driver to control the operations of the

AUV has been designed and implemented for SUNSET.

Acoustic commands have been sent remotely to the ve-

hicle using acoustic links in order to instruct the Folaga

AUV to perform the requested operations. The conducted

tests show the flexibility of SUNSET architecture and its

capability to be interfaced with whatever external device

once APIs are provided to control the operation of the

specific device.

CMRE ACommsNet11. In summer 2011, we also par-

ticipated to the CMRE ACommsNet11 experiment to

further explore the flexibility of the SUNSET framework

when using different acoustic modems and mobile nodes.

A driver for the Evologics modems S2C R (networking

firmware version 1.6) has been designed, implemented

and extensively tested first in the swimming pool avail-

able at CMRE and then in the harbor of La Spezia.

New timing module settings have been investigated

when using Evologics modems and additional MACs and

preliminary routing tests have been conducted using the

improved version of SUNSET.

CO2Net. During the CMRE ACommsNet11 experiment,

SUNSET has been also interfaced with a novel sensing

platform, developed by the Geochemistry Department

of the University of Rome “La Sapienza,” which is

able to monitor temperature and the concentration of

methane and CO2 dissolved in water. Sensing, acous-

tic communications and networking capabilities have

10

Figure 7: Acoustic modem and measurement probe with

the gumstix inside the PVC housing.

been combined together to create the first prototype

of CO2Probe (Figure 7) performing accurate real-life

monitoring of underwater CO2 storage infrastructures.

Several CO2Probes can work and cooperate together,

thus creating the CO2Net, a first easy to use, flexible

and easy to extend, complete monitoring system for

underwater CO2 storage infrastructures, based on the

emerging underwater sensor networking paradigm. In

our experiments sensors were collecting the requested

data and, using acoustic communications and networking

capabilities provided by SUNSET, all requested data

where provided in real-time to the central control station.

The system was remotely accessible and the end user

was able to configure and change in real-time monitoring

parameters, such as sampling rate, the rate at which

the measured data were transmitted to the other nodes,

etc. All the details about the proposed CO2Probe and

CO2Net and the obtained results can be found in [21].

- Tests conducted during 2012

INESC. During the first months of 2012, SUNSET has

been interfaced with the MARES Autonomous Underwa-

ter Vehicle (AUV), produced by INESC TEC/University

of Porto (Figure 8). A new driver has been designed

and implemented to allow to control the operation and

navigation of the vehicle using SUNSET messages and

acoustic communications.

In February 2012, the implemented solution has been

integrated inside the MARES AUV and tested in the

swimming pool at the Oceansys laboratory. A gumstix

device has been used to run SUNSET inside the vehicle

and Evologics modems S2C R 18/34 were used for

acoustic data transmissions. One modem was connected

to the control station and another one to the vehicle.

The vehicle was controlled using acoustic commands

and the selected protocol stack (running on SUNSET)

was responsible for delivering the acoustic packet from

the central station to the vehicle and vice versa. More-

Figure 8: MARES AUV with acoustic modem.

over, while the vehicle was at the surface, we have

also tested the use of radio communication to connect

to SUNSET and locally instruct the vehicle on the

operations to perform. According to the small size of the

considered swimming pool, different types of maneuvers

have been tested (small movements, activation of the

propellers, changes on the AUV depth, pitch, yaw, etc.)

showing the capability to reliably remotely control the

AUV in real-time. These results confirm the validity

of the proposed solution when controlling the vehicle

using both radio and acoustic communication. A driver

to control the operation of INESC TEC Autonomous

Surface Vehicle is currently under test.

Figure 9: Kongsberg acoustic modem with CO2Probe.

Kongsberg. Experiments with cNode Kongsberg

modems [19] have been conducted within the EU-

funded project CLAM “Collaborative embedded

networks for submarine surveillance” [25] in Enschede,

The Netherlands, in March 2012. A new driver

for the cNode Kongsberg modem (Figure 9) has

been implemented and integrated in the SUNSET

framework. The driver has been then tested using

11

(a) Evologics acoustic modem. (b) Mobile platform.

Figure 10: CMRE experiment in April 2012.

three complete cNodes in a diving centre in Enschede.

CSMA and DACAP protocols have been used for

node communications. Moreover, a CO2Probe has

been integrated and interfaced to the cNode Kongsberg

modem. Measurements were collected by one node and

delivered in real-time to the other nodes in the network.

All the conducted tests showed again the flexibility

provided by SUNSET and its ability to fast integrate

different systems together, with negligible additional

overheads and delays.

CMRE. In April 2012, additional tests have been per-

formed at the NATO Centre for Maritime Research

and Experimentation, considering different networking

protocol solutions. A network with 5 static nodes

and 2 mobile nodes has been deployed in the har-

bor of “La Spezia”, Italy, close by the CMRE fa-

cility. Two “MANTA” portable systems, connected to

acoustic modems and carried around by Rigid Hull

Inflatable Boats (RHIBs), were considered as mobile

platforms (Figure 10). During these experiments differ-

ent routing protocols have been investigated, including

flooding solutions, the Channel Aware Routing protocol

(CARP) [30], which is a cross-layer solution developed

by the UWSN group of the Senses Lab, and an im-

proved version of the routing solution presented in [29].

Evologics modems S2C R 18/34 were used for acoustic

data transmissions. Implementing new routing and cross-

layer solutions was fast and easy, and running them in

an heterogeneous scenarios completely transparent to the

users.

Teledyne Benthos. In July 2012, SUNSET support has

been extended also to Teledyne Benthos modems [20].

A new driver has been designed and implemented and

first tests with Teledyne Benthos modems have been

performed in collaboration with the Wireless Networks

and Embedded Systems Laboratory at SUNY Buffalo.

First results have been really positive and additional tests

will be conducted in the next weeks in order to have

Teledyne Benthos modem supported by SUNSET in the

really short future.

V. CONCLUSIONS

We have designed, implemented and extensively val-

idated SUNSET, a new ns-2 based open source frame-

work for underwater sensor networks Simulation Em-

ulation and real-life Testing [3]. Using SUNSET the

same code implemented to simulate a given protocol

can be executed on real small embedded devices during

trial campaigns at sea, without any code rewriting. The

additional delays introduced by SUNSET are of the

order of milliseconds and the extra overhead due to

framework operations is extremely limited, just few bits

of information for proper packet coding and decoding.

Using SUNSET acoustic communications and network-

ing capabilities can be combined together with sensing,

navigation and control operations providing a complete

framework for real-life testing of underwater monitoring

systems. As of today SUNSET has been ported on a

variety of compact embedded platforms and has been

extensively used for several at sea campaigns run by

CMRE, WHOI, University of Porto’s groups.

SUNSET has been interfaced with different devices:

Commercial acoustic modems (WHOI Micro-Modem,

Evologics modem, Kongsberg modem and Teledyne

Benthos modem); sensing platform (environmental un-

derwater sensors for temperature, CO2 and methane

concentration); surface and underwater mobile vehicles

(Folaga AUV, MARES AUV and INESC TEC/University

of Porto ASVs). SUNSET features significantly speed up

the design and test of novel protocol stacks and allows

to transparently test the developed solutions in a variety

of different scenarios and settings, using different plat-

forms. SUNSET therefore provides a flexible, reliable

and efficient starting point for the development of a

common standard platform for running protocol stacks

to be shared, used and improved by the entire underwater

community.

ACKNOWLEDGMENTS

This work was supported in part by the EU FP 7

STREP project CLAM “CoLlAborative EMbedded Net-

12

works for Submarine Surveillance ”. The authors grate-

fully acknowledge (in alphabetical order) the CLAM

project, Evologics GmbH, the Geochemistry Department

of the Universita di Roma “La Sapienza,” Graaltech, the

INESC TEC/University of Porto group, the LSTS group

at University of Porto, The NATO Centre for Maritime

Research and Experimentation, Daniele Spaccini from

the UWSN Group of the SENSES Lab, the Wireless

Networks and Embedded Systems Laboratory at SUNY

Buffalo and the Woods Hole Oceanographic Institution

for their valuable feedback and for their support and help

during tests and experimentation.

REFERENCES

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

[2] N. Baldo, F. Maguolo, M. Miozzo, M. Rossi, and M. Zorzi,“ns2-MIRACLE: A modular framework for multi-technology andcross-layer support in network simulator 2,” in Proceedings of

the 2nd International Conference on Performance Evaluation

Methodologies and Tools, ValueTools 2007, Nantes, France, Oc-tober 23–25 2007, pp. 1–8.

[3] SENSES Lab, “SUNSET: Sapienza university networkingframework for underwater simulation, emulation and real-lifetesting.” [Online]. Available: http://reti.dsi.uniroma1.it/UWSNGroup/index.php?page=sunset

[4] I. F. Akyildiz, D. Pompili, and T. Melodia, “Underwater acousticsensor networks: Research challenges,” Elsevier Ad Hoc Net-

works Journal, vol. 3, no. 3, pp. 257–279, May 2005.

[5] J. Heidemann, W. Ye, J. Willis, A. A. Syed, and Y. Li, “Researchchallenges and applications for underwater sensor networking,”in Proceedings of the IEEE Wireless Communications and Net-

working Conference, WCNC 2006, Las Vegas, NV, April 3–62006, pp. 229–235.

[6] L. Lanbo, Z. Shengli, and C. Jun-Hong, “Prospects and problemsof wireless communication for underwater sensor networks,”Wireless Communications and Mobile Computing, Special Issue

on Underwater Sensor Networks, vol. 8, no. 8, pp. 977–994,August 2008.

[7] C. Petrioli, R. Petroccia, J. Shusta, and L. Freitag, “Fromunderwater simulation to at-sea testing using the ns-2 networksimulator,” in Proceedings of IEEE OCEANS 2011, Santander,Spain, June, 6–9 2011.

[8] 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.

[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] R. Masiero, S. Azad, F. Favaro, M. Petrani, G. Toso, F. Guerra,P. Casari, and M. Zorzi, “DESERT underwater: an NSmiracle-based framework to DEsign, simulate, emulate and realize test-beds for underwater network protocols,” in Proceedings of IEEE

OCEANS 2012, Yeosu, Korea, May, 21–24 2012.[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] F. Guerra, P. Casari, and M. Zorzi, “World ocean simulation

system (WOSS): a simulation tool for underwater networks withrealistic propagation modeling,” in Proceedings of the Fourth

ACM International Workshop on UnderWater Networks, ser.WUWNet ’09, Berkeley, California, USA, 3 November 2009,pp. 1–8.

[17] L. Freitag, M. Grund, S. Singh, J. Partan, P. Koski, andK. Ball, “The WHOI Micro-Modem: An acoustic com-munications and navigation system for multiple platforms,”http://www.whoi.edu/micromodem/, 2005.

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

[19] Kongsberg maritime, “Instruction manual cn-ode maxi transponder.” [Online]. Avail-able: http://www.km.kongsberg.com/ks/web/nokbg0397.nsf/AllWeb/4ADD212486A1B94EC125780000355234/

[20] Teledyne Benthos, “Teledyne benthos undersea systemsand equipment.” [Online]. Available: http://www.benthos.com/acoustic-telesonar-modem-product-comparison.asp

[21] A. Annunziatellis, S. Graziani, S. Lombardi, C. Petrioli, andPetroccia, “CO2Net: A marine monitoring system for CO2 leak-age detection,” in Proceedings of IEEE OCEANS 2012, Yeosu,Korea, May, 21–24 2012.

[22] Oceansys Lab, “Mares AUV and ASVs.” [Online]. Available:http://oceansys.fe.up.pt/technology.php

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

[24] N. A. Cruz, B. M. Ferreira, A. C. Matos, C. Petrioli, R. Petroccia,and D. Spaccini, “Implementation of an underwater acousticnetwork using multiple heterogeneous vehicles,” in Proceedings

of MTS/IEEE OCEANS 2012, Hampton Roads, Virginia, October,14–19 2012.

[25] “CLAM: Collaborative embedded networks for submarinesurveillance.” [Online]. Available: http://clam.ewi.utwente.nl/

[26] 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.

[27] A. Syed, W. Ye, and J. Heidemann, “Comparison and evaluationof the T-Lohi MAC for underwater acoustic sensor networks,”IEEE Journal on Selected Areas in Communications, vol. 26,no. 9, pp. 1731–1743, December 2008.

[28] B. Peleato and M. Stojanovic, “Distance aware collision avoid-ance protocol for ad-hoc underwater acoustic sensor networks.”IEEE Communications Letters, vol. 11, no. 12, pp. 1025–1027,December 2007.

[29] J. ALves and G. Zappa, “Low overhead routing for underwateracoustic networks,” in Proceedings of IEEE OCEANS 2011,Santander, Spain, June, 6–9 2011.

[30] S. Basagni, C. Petrioli, R. Petroccia, and D. Spaccini, “Channel-aware routing for underwater wireless networks,” in Proceedings

of IEEE OCEANS 2012, Yeosu, Korea, May, 21–24 2012.[31] LSTS, University of Porto, “Manta gateway.” [Online]. Available:

http://whale.fe.up.pt/main/tech