TECHNICAL REPORT 3059 February 2017

Toward a Mobility-Driven Architecture for Multimodal Underwater Networking

Pedro Forero Stephan K. Lapic

SSC Pacific

Michele Zorzi Dept. of Information Engineering

University of Padova, Padova, Italy

Approved for public release. .

SSC Pacific San Diego, CA 92152-5001

SB

SSC Pacific San Diego, California 92152-5001

G. M. Bonitz, CAPT, USN Commanding Officer

C. A. Keeney Executive Director

ADMINISTRATIVE INFORMATION The work described in this report was performed for Office of Naval Research, Communications

and Networking, and Maritime Sensing Programs by the Maritime Systems Division (Code 56400) and the Networks and Information Systems Division, Space and Naval Warfare Systems Center Pacific (SSC Pacific), San Diego, CA. Contract awards N0001413WX00411 AA and N62909-14-1-N127 provided funding for this project.

This is a work of the United States Government and therefore is not copyrighted. This work may be copied and disseminated without restriction.

Released by T. L. Jones, Head Advanced Research Branch

Under authority of M. H. Berry, Head Maritime Systems Division

EXECUTIVE SUMMARY

Relying on autonomous underwater vehicles (AUVs) for ferrying data in an underwater network is anappealing approach for supporting a wide range of underwater networking applications. By equippingAUVs with short-range, high-bandwidth underwater wireless communications, which feature lowerenergy-per-bit cost than acoustic communications, the energy-usage efficiency and data throughput of anetwork servicing data-intensive applications can be significantly improved. Although data-ferrying is anattractive concept due to its simplicity, bringing this networking paradigm to fruition requires synergisticintegration of a wide range of technologies that go beyond networking to incorporate, among others, energyrecharging and management, and AUV path-planning and navigation. This report outlines functional layersthat are necessary to accomplish the vision of a cohesive mobility-driven underwater networkingarchitecture. Our focus is on networking functionalities, AUV path-planning algorithms, and estimationand forecasting tools required to develop effective network management and monitoring mechanisms.

iii

CONTENTS

EXECUTIVE SUMMARY ..................................................................................................................... iii

1. INTRODUCTION............................................................................................................................. 1

2. BENEFITS OF NODE MOBILITY – A SAMPLE CASE ............................................................ 3

2.1 DATA RETRIEVAL WITH A STATIC UNDERWATER ACOUSTIC NETWORK .............. 3

2.2 DATA RETRIEVAL USING AUVS ........................................................................................ 4

3. MOBARCH’S PHYSICAL REQUIREMENTS ............................................................................. 6

4. MOBARCH’S FUNCTIONAL LAYERS........................................................................................ 8

4.1 NETWORKING LAYER......................................................................................................... 8

4.2 AUV PATH-PLANNING LAYER............................................................................................ 10

4.3 MONITORING LAYER .......................................................................................................... 10

5. FUTURE EXTENSIONS OF MOBARCH..................................................................................... 13

6. SUMMARY............................................................................................................................................... 14

REFERENCES.......................................................................................................................................... 15

Figures

1. Illustration of a data collection system with 100 nodes. Each node has 10 MB of datathat must be gathered at the FC for retrieval. (a) Topology of a fixed underwater acous-tic network used to move all data towards the FC as described in Section 2.1. Theshortest-path tree T rooted at the FC is shown (in dashed red lines) overlaid over allavailable acoustic links (shown in solid gray). This figure also shows the partitioning,illustrated by the node color, of the sensing nodes into 5 groups as described in Section2.2. Each cluster is served by an AUV that collects all data from the sensing nodes.Radial sectors, with central angle of 72◦, centered at the FC were used to defined thepartitioning. (b) Summary of transmitted data and energy consumption per node afterall data have been gathered at the FC through the acoustic network as described inSection 2.1. Red and green circles correspond to highlighted red and green nodes in (a). 5

2. Network model considered by MobArch. Each subnetwork (cloud icons) has an as-sociated gateway node (green triangles) that funnels all data leaving and entering the subnetwork. AUVs (blue spheres) ferry data between subnetworks and periodically recharge their batteries at the depots (gold pentagons). Gateways form a connectedacoustic network that defines the acoustic backbone of MobArch. ....................................... 6

3. Main functional layers of MobArch and their correspondence to high-level functionalitiesdefined in the classical OSI model. ........................................................................................... 8

iv

4. Sample functionality of the Networking Layer. A2 collects all data from G2 that areaddressed to G8, G7, and G9. It also downloads to G2 all data in its buffer that areaddressed to G3, G4, and G5. Since A3 will visit G2, A3 may be able to pick up thosedata from G2 and deliver them to their destination. A1’s buffer is full; thus, it can onlydeliver data. G9 is overflowing. It uses the acoustic backbone (shown in Figure 2)to request an AUV visit sooner than it is currently planned. Since the data-storagebuffer of A1 is full, it is decided that A2 should modify its planned route and visit G9directly after leaving G2, before visiting G7 and G8. Meanwhile, G9 uses its localbuffer-management policy to discard low-priority and outdated data first. ........................... 9

5. Illustration of an information request triggered by the dynamic AUV Path-Planning Layer.It occurs as soon as A2 completes its data exchange with G2 and is ready to be routed.G2 can broadcast a request for control data, or send a multicast message to neighbor-ing gateways and depots only. Although control data from other parts of the networkare also relevant, it is not necessary to collect them at G2. Instead, the AUV Path-Planning Layer relies on the networkwide estimation and forecasting tools provided bythe Monitoring Layer to estimate and forecast necessary network metrics. Since AUVsen route may not be reachable through the acoustic backbone, all information requestsare addressed to gateways and depots only. ........................................................................... 11

v

1. INTRODUCTION

Renewed interest in the undersea domain, sparked by applications including environmental monitoring,deep-sea exploration and exploitation, and undersea surveillance [1], has triggered the emergence of a newgeneration of undersea systems. These systems feature enhanced sensing and actuation technologies thatallow them to gather large volumes of data, ranging from acoustic and environmental measurements tohigh-resolution imagery and video. Although they are equipped with enhanced wireless communicationtechnologies, establishing reliable communications with these systems while they are deployed remains achallenge. Nevertheless, netted and seamless operation among them and between them and their operatorsare paramount to cope with the vastness of typical undersea operating areas and increasing demand forundersea data.

Underwater acoustic networks epitomize the current networking paradigm envisioned for the undersea.Acoustic communications (ACOMMs) enable long-range, low-bandwidth communications and, thus, makeit possible for sparsely deployed systems to communicate. Although popular, underwater ACOMMs faceformidable challenges that limit their capabilities and demand specialized protocols. They suffer fromsignificant transmission path losses at high frequencies, long propagation delays, low anddistance-dependent bandwidth, time-varying multi-path propagation, long interference ranges, andsignificant Doppler effects [2]. Furthermore, acoustic transmitters require properly designed media accesscontrol (MAC) protocols able to mitigate acoustic interference. Even when the latency and reliability levelof ACOMMs are tolerable, their hefty energy-per-bit cost quickly renders them unaffordable for mostbattery-powered undersea systems attempting to transmit large volumes of data.

The prevailing paradigms for communicating with, and retrieving data from, undersea systems are basedon:

• physical recovery, and

• a combination of data preprocessing, data compression, and either tethering to a surface buoy ableto use radio frequency (RF) communications or using undersea ACOMMs to transmit the data.

These methods suffer several shortcomings from various financial, infrastructure, and communicationperspectives. Physical retrieval of the systems is maximally efficient in terms of energy used forcommunications. However, its associated cost, demand for specialized recovery infrastructure, and theinherent disconnectedness of the system throughout the entirety of its mission render this approachinadequate for many applications. Data preprocessing and compression caters to improved connectivitywhen using ACOMMs or RF communications through a surface buoy, but continues to be confronted bythe communications-related energy consumption. Moreover, in many situations buoys must be submergedto avoid interfering with maritime traffic, thereby adding the buoy surfacing system and its associatedenergy usage to the overall system infrastructure and energy requirements. Prompt access to undersea data,enhanced cooperation among undersea systems, and the extended operational lifetimes envisioned forfuture undersea missions further challenge the aforementioned paradigms and demand an enhancedunderwater networking architecture.

The advent of short-range, high-bandwidth underwater wireless modes of communications coupled withenhanced autonomous underwater vehicle (AUV) technologies has given rise to a mobility-drivenunderwater networking paradigm [3], [4]. In this paradigm, battery-powered AUVs acting as data ferriesvisit each network node (undersea system) and use high-bandwidth underwater wireless communicationsfor uploading (downloading) data from (to) them. High-bandwidth underwater wireless communications,including free-space optical communications (OCOMMs) [5], magnetic induction (MI) [6], and underwaterRF communications [7], feature lower energy-per-bit cost than ACOMMs at short ranges and, thus, can

1

reduce the energy consumption of the overall undersea network. Moreover, they enable netting systemslocated in areas where using ACOMMs alone has traditionally been problematic, such as shallow watersand surf zones (5- to 10-m depth) [6], [7]. An added benefit of this paradigm is that interference amongundersea systems located even few meters away from each other is practically nonexistent due to the highattenuation that OCOMMs, MI, and RF signals experience underwater. Multiple transmitter-receiver pairscan transmit simultaneously and in close proximity without causing significant interference amongthemselves. The bulk of energy consumption for the network, which includes the undersea systems and theAUVs, is due to the AUVs’ propulsion system. Thus, for a successful implementation of this paradigm it isparamount to consider how to route the AUVs, and where and when to recharge the AUV batteries so as tooptimize their energy usage, specially since their recharge times are lengthy. From a network managementperspective, recharging the AUV batteries leads to a dynamic network featuring a variable number ofAUVs available to ferry data.

The contribution of this work is to propose a cohesive mobility-driven underwater networkingarchitecture (MobArch) that captures unique aspects of the implementation of the mobility-drivennetworking paradigm as a viable underwater networking solution. We do not intend to provide a completedesign and performance evaluation of a specific architecture for MobArch, but rather to discuss by examplethe major challenges and tradeoffs of designing such an architecture. MobArch features dynamic datarouting and AUV path-planning algorithms able to cope with the dynamic nature of the network and theundersea environment. A successful implementation of MobArch relies on the availability and affordabilityof reliable technologies that support AUV battery recharging stations, AUV navigation and dockingsystems, underwater acoustic networking, and point-to-point high-bandwidth underwater wirelesscommunications. While it requires a cross-layer design approach, our presentation emphasizes aspects ofMobArch germane to the Network and Transport layers of the Open Systems Interconnection (OSI) model.Specific technology requirements are mentioned as required. Before introducing MobArch, the benefits ofusing a mobility-driven paradigm for networking are illustrated through an example.

2

2. BENEFITS OF NODE MOBILITY – A SAMPLE CASE

This section illustrates the benefits of using node mobility for underwater data collection through asimplified scenario. Admittedly, many challenges associated with a real implementation of the ensuingscenarios are disregarded to simplify the discussion. Nevertheless, considerations about deployment cost,maturity of OCOMM technologies, reliability of AUV navigation, and efficiency of undersea energytransfer also drive the selection of the most appropriate data collection approach for any practical scenario.

Assume that multiple battery-powered sensing nodes are deployed to collect undersea data. All datamust be retrieved through a high-speed access point, hereafter named fusion center (FC). Figure 1aillustrates the underwater data collection system considered here. It comprises 100 nodes randomly locatedover a 34 km × 34 km square-shaped area with the FC located in its center. Each sensing node has a fixeddata payload of 10 MB. The goal of the system is to gather all data to the FC for retrieval. The next twosubsections illustrate the performance level achievable when using two different networking paradigms.

2.1 DATA RETRIEVAL WITH A STATIC UNDERWATER ACOUSTIC NETWORK

In this scenario, it is assumed that the sensing nodes form a connected acoustic network. Thus, there exists a path connecting the FC to every network node. For the network topology illustrated in Figure 1a, this is accomplished by presuming the availability of ACOMM links able to support transmission ranges up to 5 km. At a nominal transmission rate of 5,000 bps, transmitting the data payload over a single acoustic link requires roughly 4.4 hrs. Acoustic modems such as the Teledyne Benthos 920 Series1, the LinkQuest UWM100002, and the EvoLogics S2C R 12/243 can support these data rate and range requirements. Using 40 W as a nominal acoustic transmission power, it follows that the associated price-per-bit of ACOMMs is 2.216 µWh/bit and the overall energy consumption to transmit 10 MB of data is 177.28 Wh.

FC relies on a shortest-path tree T rooted at the FC to gather all data (see Figure 1a). The tree T is aspanning tree, that is, the distance from the FC to any node v ∈ T is a geodesic between the FC and v overthe acoustic network. Due to the long-range propagation of acoustics and since the communicationmedium is shared by all nodes, a MAC protocol must be used to mitigate interference and data losses dueto collisions when transmitting the data towards the FC. However, including such a MAC protocol wouldcompound our analysis of energy usage and data latency. In practice, data retransmissions due to packeterrors and collisions, and the usage of a MAC protocol will cause the energy usage, data transmitted, andlatency seen by the FC to increase. Although useful for the simplified analysis presented in this section,using a spanning tree for routing data towards the FC is neither necessary nor recommended. Alternativedata routing approaches for underwater acoustic networks can be found in [8].

Instead of using a MAC protocol, it is assumed that: (a1) the ACOMMs links are error-free, (a2) allnodes can simultaneously transmit and receive data, and (a3) there is no acoustic interference amongnodes. One quickly realizes that nodes with lower depths in T relay more data towards the FC (see Figure1b). Hence, they use more energy for acoustic communications and deplete their batteries sooner than othernodes. For instance, Node 24 transmits its own data and relays data from 41 other nodes. It consumes 7.44kWh on acoustic communications alone. The entire network consumes 90.06 kWh, all of it provided bythe, often non-rechargeable, batteries of the sensing nodes. In terms of data latency, gathering all data at theFC takes a staggering 7.78 days. Due to (a1)–(a3), these performance values define optimistic lower

3

1Benthos 920 Series ATM 925 supports data rates between 140 and 15,360 bps at 2–6 km ranges. Data retrieved fromhttp://teledynebenthos.com/product/acoustic_modems/920-series-atm-925 on February 2, 2016.

2LinkQuest UWM10000 supports data rates up to 5,000 bps at ranges up to 10 km. Data retrieved from http://www.link-quest.com/html/models1.htm on February 2, 2016.

3EvoLogics S2C R 12/24 supports data rates up to 9,200 bps at ranges up to 6 km. Data retrieved fromhttps://www.evologics.de/en/products/acoustics/s2cr_12_24.html on February 2, 2016.

bounds on the energy usage, data volumes transmitted, and latency observed at the FC. In a real underwateracoustic network deployment, it is expected that all these values will increase in magnitude according tothe specific MAC protocol used and the bit-error rates observed in the acoustic channel.

2.2 DATA RETRIEVAL USING AUVS

Instead of using the aforementioned data collection framework, this section uses a flotilla of five AUVsto collect all data and deliver them to the FC. The sensing nodes are partitioned into five clusters. Eachcluster is assigned to an AUV for service. AUVs are launched from the FC and use a nearest-neighbor ruleto decide what node in their assigned cluster to visit next. Once all nodes have been visited, each AUVreturns to the FC and delivers the data. All nodes and AUVs use OCOMMs to exchange data.

For this example, REMUS-6004 AUVs with a 5.2-kWh battery are considered. Their mission duration capability of up to 70 hrs enables them to travel up to 388.1 km at a nominal speed of 1.54 m/s (3 knts). The OCOMMs system considered features a bit rate of 10 Mbps at a range of 10 m and uses 5 W of power to transmit. Hence, its associated cost-per-bit is 138.89 pWh/bit. With these characteristics, OCOMMs consume 11.11 mWh to upload/download 10 MB of data. The latency of the data collection system depends on the AUV travel times and data exchange times. At 10 Mbps, it takes 8 s to upload (download) 10 MB of data from (to) any node. The AUV-cycle lengths for the node partition shown in Figure 1 range between 65.56 and 92.18 km. Disregarding ocean currents, an AUV moving at 1.54 m/s completes the shortest cycle in 11.83 hrs and the longest cycle in 16.63 hrs, and consumes 0.88 and 1.24 kWh, respectively. Thus, it takes 16.63 hrs for all the data to arrive at the FC. Each AUV consumes less than 25%of its battery capacity when collecting data from its assigned set of nodes. The entire system consumes 5.26 kWh, nearly all of it provided by the rechargeable batteries of the AUVs. In this case each AUV can complete its cycle without recharging its battery. When ACOMMs alone were used to collect the data, two nodes needed battery capacities larger than 5.2 kWh to satisfy the energy requirements of their own ACOMMs.

Different from the scenario described in the previous section, increasing the amount of data to becollected per node does not significantly impact the overall energy consumption and latency of the system.Here, the latency and energy consumption due to OCOMMs are dominated by the AUV travel times andAUVs’ energy consumption associated to their propulsion systems. Ocean currents will impact AUVenergy consumption and should be carefully considered when selecting AUV trajectories.

4The REMUS 600 features a 5.2 kWh rechargeable lithium ion battery, supports speeds of up to 2.6 m/s (5 knts), and can yieldup to 70 hrs of endurance. Data retrieved from REMUS 600 Autonomous Underwater Vehicle at http://www.km.kongsberg.com onFebruary 2, 2016.

4

Figure 1. Illustration of a data collection system with 100 nodes. Each node has 10 MB of data thatmust be gathered at the FC for retrieval. (a) Topology of a fixed underwater acoustic network usedto move all data towards the FC as described in Section 2.1. The shortest-path tree T rooted at theFC is shown (in dashed red lines) overlaid over all available acoustic links (shown in solid gray). Thisfigure also shows the partitioning, illustrated by the node color, of the sensing nodes into 5 groupsas described in Section 2.2. Each cluster is served by an AUV that collects all data from the sensingnodes. Radial sectors, with central angle of 72◦, centered at the FC were used to defined thepartitioning. (b) Summary of transmitted data and energy consumption per node after all data havebeen gathered at the FC through the acoustic network as described in Section 2.1. Red and greencircles correspond to highlighted red and green nodes in (a).

5

3. MOBARCH’S PHYSICAL REQUIREMENTS

Motivated by the example presented in the previous section, this section develops the rationale forMobArch, and introduces its physical building blocks and supporting infrastructure requirements. Theensuing presentation underscores the physical blocks needed by MobArch and the technology challengestheir implementation entails.

The idea of using mobile nodes as data ferries to enable connectivity in an otherwise disconnectednetwork was first introduced in the context of disruption-tolerant networking (DTN) [9], and was quicklyadopted by the underwater networking community [3], [4]. Despite its conceptual simplicity, developingall necessary technologies to enable this form of underwater networking has proven difficult in part due tothe breadth of engineering disciplines involved and the challenges associated with deployment andoperation of undersea systems. Works focusing on the data-retrieval problem have considered multipleAUV path-planning problem formulations [4]. However, the development of a cohesive networkingarchitecture capturing the intertwine among data networking functionalities, networkwide controlrequirements, and AUV path-planning and battery-recharging demands remains insufficient.

MobArch’s vision is to develop an underwater networking architecture that naturally integrates AUV anddata management. MobArch comprises several building blocks as illustrated in Figure 2. The overallnetwork is comprised by multiple disconnected subnetworks, where nodes in different subnetworks arepresumed to be disconnected. Beyond being out of ACOMMs range, this is a valid assumption when thevolume of data to be exchanged between nodes in different subnetworks is so large that ACOMMs arerendered impractical. A subnetwork can even be a singleton representing a high-speed access point to, e.g.,an above-water RF network or a fiber optic cable. Each subnetwork is assumed to be connected. Allintra-subnetwork data traffic is handled through the local communications infrastructure.

LegendSubnetwork

Gateway node

AUV

Depot

Figure 2. Network model considered by MobArch. Each subnetwork (cloud icons) has anassociated gateway node (green triangles) that funnels all data leaving and entering thesubnetwork. AUVs (blue spheres) ferry data between subnetworks and periodically recharge theirbatteries at the depots (gold pentagon). Gateways form a connected acoustic network that definesthe acoustic backbone of MobArch.

6

Each subnetwork has an associated high data-storage capacity node, known as the gateway. The gatewaybehaves as a throwbox where data can be stored for extended periods while on their way to their destination.Data to be transmitted (received) to (from) other subnetworks are funneled through the gateway. AUVs canalso drop data at a gateway where they wait to be advanced toward their destination by another AUV. It isassumed that gateways are able to use both ACOMMs and high-bandwidth, underwater wirelesscommunications. Gateways can represent cluster heads that define a hierarchical networking architecture.

A flotilla of AUVs is used to collect (deliver) data from (to) the gateways. AUVs are equipped withhigh-speed, wireless communication technology that allows them to communicate with the gateways. Theyalso feature high data-storage capacity so that they can collect and maintain data from multiple gateways.AUVs are battery-powered and, thus, they need to be periodically recharged. To this end, specialAUV-recharging nodes called depots are also deployed. Note that MobArch requires the deployment ofnavigation, homing, and docking systems to enable AUVs to locate, navigate toward, and possibly dock atgateways and depots.

Depots are visited by AUVs to recharge their batteries. They are equipped with ACOMMs and, for thepurpose of this work, are presumed to always be able to satisfy the energy demands of the AUVs.Nevertheless, depots have a finite number of recharging ports. Thus, if multiple AUVs try to concurrentlyrecharge their battery at the same depot, some of them may have to wait until a recharging port becomesavailable. Depots must support homing and docking functionalities for AUVs so that battery rechargingcan take place.

Within MobArch, ACOMMs continue to play a fundamental role as the enabler of long-range connectivity among gateways. Gateways and depots form a connected acoustic network which is used for collecting and disseminating control data from and to the entire network. From a networking vantage point, this enables MobArch to separate the control and the data planes. The control plane corresponds to the acoustic backbone network5 comprising gateways and depots. Similarly, the data plane corresponds to the virtual links instantiated by the AUVs. This separation enables the control plane to use ACOMMs to disseminate service policy adjustments to the entire network and collect networkwide status data for developing management and monitoring tools without being affected by the payload data volumes. The data plane uses the AUVs and a high-speed mode of communications to transport large data volumes at reduced energy and latency costs. Note, however, that such connectivity assumption limits the maximum separation possible among gateways which may render MobArch unsuitable for very sparse network deployments, and require the deployment of acoustic relays between gateways.

5Backbone network refers to the infrastructure that connects all gateways and depots for transporting control data. Differentfrom its traditional use in computer networks, it is neither presumed that the backbone network features high-capacity links nor thatit will transport large data volumes.

7

4. MOBARCH’S FUNCTIONAL LAYERS

A goal of MobArch is to support large-volume data exchanges among subnetworks while providing aprescribed quality-of-service (QoS) level. This goal demands the design of networking protocols, AUVpath-planning algorithms, and monitoring tools able to provide delivery, throughput, and delay guaranteesfor all network traffic while allowing some level of management and supervision.

Networking protocols within MobArch will be responsible for data routing and gateway memorymanagement. They will rely on DTN technologies to provide end-to-end (source-gateway todestination-gateway) delivery guarantees. Moreover, they can influence the selection of the paths to befollowed by AUVs according to network-related parameters such as data prioritization and memory usageat both gateways and AUVs. Likewise, AUV paths can influence data-routing and gateway-memorymanagement policies. From a management and monitoring perspectives, one would like to have assuredand non-interrupted access to all network components. Unfortunately, collecting networkwide stateinformation regularly is impractical due to the disconnected nature of the environment and the high costassociated with collection of control data through the acoustic backbone network featured by MobArch.However costly, some minimum level of network-state control information needs to be exchanged tocapture the dynamics of the underlying communication network with AUV management and operation.

The main functional layers of MobArch are illustrated in Figure 3. Although they require a cross-layerdesign approach to access the status of AUVs and gateways, their functionalities can be broadly associatedwith those of the OSI’s Network and Transport layers. The following subsections describe the variousMobArch layer functionalities and their interactions. Note that MobArch does not require specific Physicaland Data Link layer technologies for point-to-point communications.

Figure 3. Main functional layers of MobArch and their correspondence to high-level functionalitiesdefined in the classical OSI model.

4.1 NETWORKING LAYER

This layer provides network and transport protocols to the acoustic backbone. These protocols aremindful of the energy constraints of the gateways. Thus, they are developed so that excessive packetreplication and interference among gateways is avoided. The known topology of the acoustic backbone canbe exploited to develop advanced routing algorithms [8]. Likewise, using advanced MAC protocols canimprove control-data throughput and reduce data latency in the acoustic backbone [10].

8

The Networking Layer also defines the routing of the network data through the links instantiated by theAUVs. As illustrated by Figure 4, the path followed by an AUV may not reach the gateway to which someof its data payload is routed. In this case, the AUV relays that portion of its data payload to an intermediategateway where they are temporarily stored. Eventually another AUV will pick up the data and advancethem towards their destination. Packet routing technologies developed for DTN can be leveraged to enableAUVs to establish routes, that is, virtual paths, for the data. These routes can be designed bearing in mindlatency-minimization and throughput-maximization objectives depending on the underlying applicationsrunning on the network.

Protocols for data prioritization and storage-queue management at the gateways are also managed by thislayer. When a gateway faces a data overflow, data priorities and time-to-live scores can be used as a metricfor a queue-management policy that, in the same spirit of MaxProp [9], judiciously discards outdated andlow-priority data first. Similarly, data priorities and gateway storage-queue metrics can be used todynamically influence the AUV path-planning algorithms. They will, for example, steer AUV routestowards regions in which larger volumes of data need transport.

Figure 4. Sample functionality of the Networking Layer. A2 collects all data from G2 that areaddressed to G8, G7, and G9. It also downloads to G2 all data in its buffer that are addressed toG3, G4, and G5. Since A3 will visit G2, A3 may be able to pick up those data from G2 and deliverthem to their destination. A1’s buffer is full; thus, it can only deliver data. G9 is overflowing. It usesthe acoustic backbone (shown in Figure 2) to request an AUV visit sooner than it is currentlyplanned. Since the data-storage buffer of A1 is full, it is decided that A2 should modify its plannedroute and visit G9 directly after leaving G2, before visiting G7 and G8. Meanwhile, G9 uses its localbuffer-management policy to discard low-priority and outdated data first.

9

Lastly, this layer is also responsible for protocols to efficiently broadcast, multicast, anycast, and geocastdata. Here, higher efficiency is achieved by protocols that reduce the number of copies of the data that arepropagated through the network, and the corresponding bandwidth and energy resources used in doing so.AUVs will be the custodians of the data and will decide when and where to replicate them. Properlydesigned multicast protocols will reduce the overall communication load of the network when, forexample, updating the firmware of a set of sensors, remotely activating multiple underwater nodes, anddelivering updated navigation or tasking information to a group of nodes.

4.2 AUV PATH-PLANNING LAYER

This layer deals with the problem of AUV path planning for ferrying data across the network, which isrelated to the celebrated vehicle routing problem (VRP) [11]. Since VRP is known to be an NP-hardproblem, a plethora of heuristics have been developed within the area of operational research to solve it,see [11], [12] and references therein. The underwater mobility-driven networking paradigm considered byMobArch brings new challenges. AUVs must collect and deliver data from multiple gateways while beingaware of their own data-storage and energy constraints. Moreover, they should do so while facing limitedconnectivity to the acoustic backbone and responding to the underlying dynamics of the network and theenvironment. The latter includes changing data priorities and QoS requirements, varying ocean currentsaffecting AUV energy consumption and travel times, and network infrastructure changes due to nodefailures and battery-recharge times.

Fixed data-ferrying paths can be chosen by leveraging tools developed for the traveling salesmanproblem and its manifold multi-agent extensions [4]. Although appealing because they lead to reducedcontrol-data exchanges and allow gateways to depend on scheduling strategies for ferrying data anddesigning their local queue-management policies, these approaches fail to respond to the underlyingnetwork dynamics. In fact, they disregard QoS provisioning to the network, which goes beyond facilitatingnetwork connectivity. Moreover, most of these approaches are episodic and presume that fixed datavolumes are periodically collected per node. In the context of MobArch data arrive to the gateways at ratesthat feature spatiotemporal variability, thus rendering fixed data-ferrying paths inadequate.

A suitable solution for AUV path-planning captures the dynamics of the AUV-battery energy levels, theAUV-battery recharge times, and the data-storage capacity limits of the AUVs and the gateways. Moreover,it interacts with the Networking and Monitoring Layers so as to responds to dynamic network demands, asillustrated by Figures 4 and 5, and judiciously plans how to assign AUVs to depots for battery recharge soas to avoid long queue-waiting times. The AUV Path-Planning Layer also influences the Networking Layerby providing AUV-route estimates which can be used for routing data along multiple gateway hops.Dynamic AUV path-planning approaches that consider energy consumption, data losses, and latency in thecontext of underwater data retrieval have been recently developed in [13, [14].

Enabling dynamic AUV path-planning demands a minimum level of coordination across the entirenetwork, which can be achieved through the acoustic backbone. Despite the bandwidth and latencychallenges associated to ACOMMs, the sporadic frequency with which AUVs visit gateways and depots,and the relative “long” (for acoustic signal propagation) AUV travel-times between them allows enoughtime for collecting all control-data required, making a routing decision, and delivering that decision back tothe AUVs [13].

4.3 MONITORING LAYER

This layer delivers management and monitoring tools for the entire network. It serves as a supportinglayer for both the Networking and the AUV Path-Planning Layers by enabling them to capitalize on aglobal view of the network to, e.g., make data-routing decisions. Ideally, one would like to measure the

10

network-state everywhere and distribute that information so as to make fully informed decisions regardingnetwork operation. However, transmitting all this information through the acoustic backbone is impractical.

A similar challenge has been faced by IP networks for which acquiring networkwide status indicatorsquickly becomes a formidable task as the network size grows. Instead of measuring everywhere,approaches using only a subset of network-measurements to predict the networkwide status have beenproposed, see [15] and references therein. These tools can be leveraged by network operators who areinterested in estimating and forecasting metrics such as the amount of data expected at each gateway,data-delivery latencies, gateway energy usage, and data losses due to buffer overflows.

The resulting estimation algorithms capitalize on the underlying network structure given by the dataroutes and AUV paths defined by the Networking and AUV Path-Planning Layers, respectively. Collectinga subset of measurements for evaluating the network-status estimators can be done on demand, that is,triggered in response to a monitoring request or by a protocol in the Networking and AUV Path-PlanningLayers (cf., Figure 5). Network operators can also use these measurements for constructing forecastingmodels. A related alternative bestows each gateway with the responsibility of maintaining local forecastingmodels.

Figure 5. Illustration of an information request triggered by the dynamic AUV Path-Planning Layer. Itoccurs as soon as A2 completes its data exchange with G2 and is ready to be routed. G2 canbroadcast a request for control data, or send a multicast message to neighboring gateways anddepots only. Although control data from other parts of the network are also relevant, it is notnecessary to collect them at G2. Instead, the AUV Path-Planning Layer relies on the networkwideestimation and forecasting tools provided by the Monitoring Layer to estimate and forecastnecessary network metrics. Since AUVs en route may not be reachable through the acousticbackbone, all information requests are addressed to gateways and depots only.

11

Each gateway will use its historical status data to train parametric models able to forecast variables ofinterest at multiple resolution levels so as to enable reliable short-term and long-term forecasts. Theparameters defining this models are periodically collected by the operator who couples them with theknown network topology to build networkwide forecasting models.

12

5. FUTURE EXTENSIONS OF MOBARCH

Several research directions to broaden the scope of MobArch are possible. One could remove theacoustic backbone requirement and have AUVs transport both control and payload data. Control data isnow disseminated through the network by AUVs that rely on gateways as intermediate storage nodes.Although this strategy ensures that control data eventually propagate through the network, theirpropagation rate may be slow and is tied to the speed of the AUVs. The network would have to rely heavilyon estimation and forecasting tools provided by the Monitoring Layer since measurements of the currentnetwork status may not always be available.

In this new paradigm, distributed and dynamic AUV path-planning functionalities become essential tocontinue supporting the main services provided by the AUV Path-Planning Layer. Their goal is to enableAUVs to plan their paths based on the information that they acquire when visiting gateways and depotsonly. To this end, AUVs leverage tools provided by the Monitoring Layer to construct and maintainnetworkwide prediction models that can be used for estimation and forecasting of networkwide parameters.

MobArch can also incorporate mobile gateway nodes and subnetworks in which the role of the gatewaycan be performed by multiple nodes. Each subnetwork may use a different node as a gateway according toa locally defined schedule chosen to maintain homogeneous energy consumption among all nodes. In thiscase, the Networking Layer must support a gateway-location discovery protocol that allows AUVs to findthe geographical location of the current subnetwork gateway. ACOMM exchanges between AUVs andsubnetwork nodes other than gateways become necessary for AUVs to learn the gateway identity andlocation.

13

6. SUMMARY

MobArch was introduced in response to the practical demands of the mobility-driven underwaternetworking paradigm. Its architecture underscores the importance of judiciously using multiple underwaterwireless communication modes for networking, enabling dynamic AUV path-planning for choosingdata-ferrying paths, developing advanced networkwide monitoring tools, and synergistically integratingAUV and data routing. Although the benefits in terms of energy usage and data latency achievable whenusing MobArch can be significant, realizing the vision of a mobility-driven underwater networkingparadigm is challenging due to the various technology challenges that must be surmounted. Nevertheless,broad scientific interest in the undersea and ongoing technology developments continue to pave the waytowards accomplishing the vision on MobArch.

14

15

REFERENCES

1. J. Heidemann, M. Stojanovic, and M. Zorzi. 2012. “Underwater Sensor Networks: Applications,Advances and Challenges,” Philosophical Transactions of the Royal Society A: Mathematical,Physical and Engineering Sciences, vol. 370, no. 1958, pp. 158–175 (November).

2. T. Melodia, H. Kulhandjian, L. Kuo, and E. Demirors. 2013. “Advances in Underwater AcousticNetworking.” In Mobile Ad Hoc Networking: Cutting Edge Directions, pp. 804–852, 2nd ed., S.Basagni, M. Conti, S. Giordano, and I. Stojmenovic, Eds.John Wiley and Sons, Hoboken, NJ.

3. M. Dunbabin, P. Corke, I. Vasilescu, and D. Rus. 2006. “Data Muling over UnderwaterWireless Sensor Networks Using an Autonomous Underwater Vehicle.” Proceedings of theIEEE International Conference on Robotics and Automation (pp. 2091–2098). May 15–19,Orlando, FL.

4. G. A. Hollinger, S. Choudhary, P. Qarabaqi, C. Murphy, U. Mitra, G. Sukhatme, M. Stojanovic, H. Singh, and F. Hover. 2012. “Underwater Data Collection Using Robotic Sensor Networks,” IEEE Journal on Selective Areas Communications, vol. 30, no. 5 (June), pp. 899–911.

5. F. Hanson, and S. Radic. 2008. “High Bandwidth Underwater Optical Communication,” AppliedOptics, vol. 47, no. 2 (January), pp. 277–283.

6. I. F. Akyildiz, P. Wang, and Z. Sun. 2015. “Realizing Underwater Communication throughMagnetic Induction,” IEEE Communications Magazine, vol. 53, no. 11 (November),pp. 42–48.

7. X. Che, I. Wells, G. Dickers, P. Kear, and X. Gong. 2010. “Re-evaluation of RFElectromagnetic Communication in Underwater Sensor Networks,” IEEE CommunicationsMagazine, vol. 48, no. 12 (December), pp. 143–151.

8. G. Han, J. Jiang, N. Bao, L. Wan, and M. Guizani. 2015. “Routing Protocols for UnderwaterWireless Sensor Networks,” IEEE Communications Magazine, vol. 53, no. 11 (November),pp. 72–78.

9. M. Khabbaz, C. M. Assi, and W. Fawaz. 2012. “Disruption-tolerant Networking: AComprehensive Survey on Recent Developments and Persisting Challenges,” IEEECommunications Surveys and Tutorials, vol. 14, no. 2 (Second Quarter), pp. 607–640.

10. S. Shahabudeen, M. Motani, and M. Chitre. 2014. “Analysis of a High-performance MACProtocol for Underwater Acoustic Networks,” IEEE Journal of Oceanic Engineering,vol. 39, no. 1(January), pp. 74–89.

11. P. Toth, and D. Vigo. 2001. “An Overview of Vehicle Routing Problems.” In The VehicleRouting Problem. Society for Industrial and Applied Mathematics, Philadelphia PA.

12. M. Zhao, J. Li, and Y. Yang. 2014. “A Framework of Joint Mobile Energy Replenishment andData Gathering in Wireless Rechargeable Sensor Networks,” IEEE Transactions on MobileComputing, vol. 13, no. 12 (December), pp. 2689–2705.

13. P. A. Forero, S. K. Lapic, C. Wakayama, and M. Zorzi. 2014. “Rollout Algorithms for DataStorage- and Energy-aware Data Retrieval Using Autonomous Underwater Vehicles.”Proceedings of the 9th International Conference on Underwater Networks & Systems(WUWNET ’14) (pp. 22:1–22:8). November 12–14, Rome, Italy. ACM.

16

14. F. Khan, S. Khan, D. Turgut, and L. Bo loni. 2014. “Greedy P ath P lanning for MaximizingValue of Information in Underwater Sensor Networks.” I n Proceediing of 10th IEEEInternational Workshop on Performance and Management of Wireless and Mobile Networks(pp. 39–44). September 8–11, Edmonton, Canada.

15. P. A. Forero, K. Rajawat, and G. B. Giannakis. 2014. “Prediction of Partially ObservedDynamical Processes over Networks via Dictionary Learning,” IEEE Transactions on SignalProcessing. vol. 62, no. 13 (July), pp. 3305–3320.

5f. WORK UNIT NUMBER

REPORT DOCUMENTATION PAGE Form Approved

OMB No. 0704-01-0188 The public reporting burden for this collection of information is estimated to average 1 hour per response, including the time for reviewing instructions, searching existing data sources, gathering and maintaining the data needed, and completing and reviewing the collection of information. Send comments regarding this burden estimate or any other aspect of this collection of information, including suggestions for reducing the burden to Department of Defense, Washington Headquarters Services Directorate for Information Operations and Reports (0704-0188), 1215 Jefferson Davis Highway, Suite 1204, Arlington VA 22202-4302. Respondents should be aware that notwithstanding any other provision of law, no person shall be subject to any penalty for failing to comply with a collection of information if it does not display a currently valid OMB control number.

PLEASE DO NOT RETURN YOUR FORM TO THE ABOVE ADDRESS. 1. REPORT DATE (DD-MM-YYYY) 2. REPORT TYPE 3. DATES COVERED (From - To)

4. TITLE AND SUBTITLE 5a. CONTRACT NUMBER

5b. GRANT NUMBER

5c. PROGRAM ELEMENT NUMBER

5d. PROJECT NUMBER

5e. TASK NUMBER

6. AUTHORS

7. PERFORMING ORGANIZATION NAME(S) AND ADDRESS(ES) 8. PERFORMING ORGANIZATION REPORT NUMBER

10. SPONSOR/MONITOR’S ACRONYM(S)

11. SPONSOR/MONITOR’S REPORTNUMBER(S)

9. SPONSORING/MONITORING AGENCY NAME(S) AND ADDRESS(ES)

12. DISTRIBUTION/AVAILABILITY STATEMENT

13. SUPPLEMENTARY NOTES

14. ABSTRACT

15. SUBJECT TERMS

16. SECURITY CLASSIFICATION OF: a. REPORT b. ABSTRACT c. THIS PAGE

17. LIMITATION OFABSTRACT

18. NUMBEROFPAGES

19a. NAME OF RESPONSIBLE PERSON

19B. TELEPHONE NUMBER (Include area code)

Standard Form 298 (Rev. 8/98) Prescribed by ANSI Std. Z39.18

February 2017 Final

Toward a Mobility-Driven Architecture for Multimodal Underwater Networking N0001413WX00411 AA and N62909-14-1-N127

Pedro Forero Michele Zorzi Stephan K. Lapic Dept. of Information Engineering SSC Pacific University of Padova, Padova, Italy

SSC Pacific 53560 Hull Street San Diego, CA 92152–5001

TR 3059

Office of Naval Research Communications and Networking, and Maritime Sensing Programs 875 N Randolph Street Arlington, VA 22217

Approved for public release.

Relying on autonomous underwater vehicles (AUVs) for ferrying data in an underwater network is an appealing approach for supporting a wide range of underwater networking applications. By equipping AUVs with short-range, high-bandwidth underwater wireless communications, which feature lower energy-per-bit cost than acoustic communications, the energy-usage efficiency and data throughput of a network servicing data-intensive applications can be significantly improved. Although data-ferrying is an attractive concept due to its simplicity, bringing this networking paradigm to fruition requires synergistic integration of a wide range of technologies that go beyond networking to incorporate, among others, energy recharging and management, and AUV path-planning and navigation. This report outlines functional layers that are necessary to accomplish the vision of a cohesive mobility-driven underwater networking architecture. Our focus is on networking functionalities, AUV path-planning algorithms, and estimation and forecasting tools required to develop effective network management and monitoring mechanisms.

autonomous underwater vehicles; underwater network; short-range, high-bandwidth underwater wireless communications; data ferrying; energy recharging and management; networking functionalities, AUV path-planning algorithms, estimation and forecasting tools

Pedro Forero

U U U U 24 (619) 553-2670

This is a work of the United States Government and therefore is not copyrighted. This work may be copied and disseminated without restriction.

INITIAL DISTRIBUTION 84300 Library (1) 55107 S. K. Lapic (1) 56490 P. Forero (1)

Defense Technical Information Center Fort Belvoir, VA 22060–6218 (1)

Approved for public release.

SSC Pacific San Diego, CA 92152-5001