Delay and/or Disruption  Tolerant Networking (DTN) protocols are important when dealing with partitioned wireless communication clusters, i.e., when dynamic connections are often broken for longer times than the maximum allowed network latency. A combination of ad-hoc and DTN functionalities is key for underwater sensor networking where AUVs can temporarily leave the network area or where a submarine can go silent for a while [1,2,3].

DTN is an active research field, especially in terrestrial and space applications such as wildlife tracking, vehicular networks (mobile ad-hoc networks, MANETs), interplanetary networks, or in situations after a disaster, where the protocol enables transport of the data between groups of disconnected mobile nodes, if the communication path between senders and receivers is completely broken or disconnected for longer time periods (e.g., emission control) [4,5,6,7]. Several delay-tolerant networking protocols have been developed in the past years [1,2,3,4,5,6,7,8,9,10,11,12,13,14,15,16,17,18,19,20,21,22,23,24,25,26,27]. Amongst others, the (now disbanded) DTN Research Group of the Internet Research Task Force (IRTF)  made some significant contributions by developing an architecture [28] and specifying protocols for DTN. The most important product of this group is the Bundle Protocol specification [29]. The DTN Working Group of the Internet Engineering Task Force (IETF) is revising and standardizing the Bundle Protocol.

6.1 Store-Carry-Forward Paradigm

Before explaining the Bundle Protocol  specification, the Store-Carry-Forward paradigm [5] is introduced, a key element of DTN. In a conventional packet-switched (non-flooding) network layer such as IP, a network node that is to forward a packet consults its Forwarding Information Base (FIB) to determine the Next Hop address associated with the destination address of the packet. If a Next Hop address is found, then the packet may sit in a queue of the associated outgoing interface for a while, waiting its turn, but it will eventually be transmitted: this is referred to as Store-and-Forward. However, if no Next Hop address for the given destination is present in the FIB, then the node has no other option than to discard the packet. DTN allows a node to hold on a Protocol Data Unit (PDU) for which a Next Hop is not readily available. If the node is mobile, then its movements may bring it within communication range of the final destination of that PDU  or within range of a suitable Next Hop: hence Store-Carry-Forward.

6.2 Bundle Protocol Specification

One of the main implementations of the Store-Carry-Forward paradigm is the Bundle Protocol specification. The idea behind the Bundle Protocol is that, in an environment with long communication delays and frequent disruptions, protocol interactions between communication endpoints should be kept to a minimum. Data to be exchanged should be grouped together with all necessary meta data and protocol information into a self-contained Protocol Data Unit, the Bundle. In terms of the OSI  (or TCP/IP) model, the Bundle Protocol can be thought of as residing at the Application  Layer, forming an overlay over the traditional protocol stack. The entity instantiating the Bundle Protocol layer at a node is called the Bundle Protocol Agent (BPA). The transfer of a Bundle from one BPA  to another BPA  is end-to-end communication from the OSI  point of view, but several of such transfers in sequence may be required to convey a Bundle from its source DTN endpoint to its destination DTN endpoint, with intermediate BPAs acting as Bundle relays, see Fig. 4.1. Bundles are made up of blocks, always including a single Primary Block and a single Payload Block, and optionally one or more Extension Blocks. The Primary Block contains Bundle Protocol  header information, including a Source and a Destination Endpoint Identifier (EID). These EIDs take the form of URLs, consisting of a scheme name followed by a scheme-specific part (e.g., dtn://ucomms/auv-1). Bundles can be much larger than (IP) packets, with the size of the latter typically being constrained by the Maximum Transmission Unit (MTU) of the underlying link layer technology (packet fragmentation should generally be avoided). Breaking down Bundles into segments that the Transport Layer can handle is a task for the Convergence Layer that resides below the Bundle Protocol  Layer. Convergence Layers for different Transport Layer protocols have been specified, e.g., for TCP [30] and for datagram-based transport [31].

Fig. 4.1
figure 1

Protocol stacks in a combined DTN Bundle-relaying and packet-forwarding configuration

Full size image

In an environment where node movement patterns are largely unpredictable,Footnote 1 BPAs need to become aware of each other’s presence before Bundles can be exchanged. This necessitates a mechanism for DTN Neighbour Discovery, which can either involve the use of a special kind of Bundles (in-band) or be based on a dedicated protocol external to the BPA  (out-of-band). Moreover, when a DTN node encounters another DTN node that does not hold the Destination Endpoint for some of the Bundles that the first node is carrying, it has to decide whether or not to transfer or copy those Bundles to the other node. Essentially, it has to assess whether the encountered node is a viable candidate for getting the Bundles closer to their Destination Endpoint. This process is referred to as DTN routing. It should be realized, however, that this is very different from routing at the packet level. Many different DTN routing strategies can be found in literature. A distinction is made between single-copy and multi-copy schemes. The former allows only a single instance of a given Bundle to be present in the network at any time, whereas the latter uses duplication of Bundles to increase the probability of their delivery and/or decrease latency. Examples of multi-copy routing strategies are Epidemic [8, 32] and Spray-and-Wait [33], and an example of a single-copy scheme is the custody transfer mechanism [3].

6.3 DTN for Underwater Acoustic Networks

Bundle-Protocol-based DTN is developed for terrestrial and interplanetary networks, and a valid question would be to what extent it is applicable to underwater acoustic communications. The Bundle Protocol  and its supporting Convergence Layer introduce additional protocol overhead, for which the time and bandwidth in the underwater acoustic network may be limited. An interesting new development to reduce communication overhead is the context-based adaptation in DTN [27], in which DTN protocols can be adapted to variations in network conditions. The adaptation is guided by predefined context parameters that can be collected by the node itself. DTN does not only require a (distributed) storage capability within the network, but the network should also be able to detect that a destination node cannot be reached before sending messages to that node (Store-Carry-Forward).

Furthermore, Bundle-Protocol-based DTN is targeting adverse communication conditions, including long propagation delays and frequent disruptions, but not necessarily very low transmission rates. In fact, it can be argued that the Bundle Protocol works best in environments where node encounters are of an opportunistic nature. I.e., when during contact periods a relatively high transmission rate can be used, presumably over short distances, for example using optical communication. However, the Store-Carry-Forward paradigm of DTN is deemed to be valuable in the context of underwater communications. It may be worth exploring whether this paradigm can somehow be implemented at the Network Layer instead of the Application Layer, i.e., packet-based DTN instead of Bundle-based DTN. Unfortunately, there are no known specifications to fall back on for such an alternative approach to DTN. The required technology would thus have to be developed from scratch.

Some efforts have already been made to adapt known DTN mechanisms for the underwater network environment with untrustworthy links. A first step in this direction was the ACommsNet10 trial in September 2010, performed by CMRE (La Spezia, Italy), by using new local, low-overhead, adaptive routing schemes [34]. Additionally, the capability to exchange data between separated network clusters with AUVs was tested within a German national WTD 71/FKIE cooperation. For this purpose, the network protocol was extended, among other enhancements, by a so-called postman functionality. The protocol extension was tested with two SeaCat AUVs and three bottom nodes during a sea trial near Bornholm in November 2014 and in Summer 2017 in the North Sea. GUWAL  was used as application language, which was already used in the RACUN demonstration and was only extended by DTN network control packets, e.g., for the postman handshake. An advantage of GUWAL are the timestamps within the packets, which can be used to decide if a delayed packet is still valid and should be exchanged with a postman or should be dropped.

6.4 Data Muling

A commonly used application for DTN is Data Muling. Data muling is the activity of transporting data between (static) nodes using one or more mobile nodes. In Underwater Sensor Networks (UWSNs), data muling usually refers to an AUV  transporting data between nodes, or clusters of nodes, between which there are no (long-range) communication links. Typical scenarios that employ data muling are postman scenarios, where communication between disjoint parts of a network is assisted by a mobile postman, data offloading from static sensor nodes to mobile nodes, and data offloading from mobile (inspection) nodes to static gateway nodes (wireless docking). Data offloading is typically performed using some form of high-speed communication technology. Optical communication is commonly used [35,36,37], and another option is to use a high-frequency acoustic link.

Some prerequisites for efficient data muling are: AUV localization of and distance estimation to sensor nodes using, for instance, the methods presented in the previous chapter; high-speed communication links, high-frequency acoustic or electro-magnetic; and protocol stacks designed to handle intermittent links (delay/disruption-tolerant-networking). Depending on the purpose of the data mule and the scenario in which it is used, efficient route planning in order to visit sensor nodes in an energy-efficient manner can also be an important requisite. In [38], Hollinger et al. treated route planning as a traveling salesman problem, with the problem formulation modified to account for the unreliable communication links.

In [36], the AUV is equipped with a down-facing camera and is assumed to have low-accuracy maps of sensor node locations. The AUV  also surfaces occasionally to correct drift in its position estimate. The AUV is tasked with visiting all stationary nodes to offload data. The sensor nodes are equipped with low-rate acoustical modems which can be used for signaling events and beaconing, but this is not demonstrated in the paper. When the AUV is in the vicinity of a node, it processes the images from the camera to locate and hover over the sensor node. When the AUV  has started hovering it uses optical communication to offload data before moving to the next node. The system is demonstrated in a pool containing three sensor nodes and one AUV.

The system demonstrated in [37] uses acoustic beaconing to let the AUV locate the sensor nodes using either a stochastic gradient descent approach or a particle filter. Both methods are shown to successfully localize the sensor node, with the particle filter performing best. The AUV is said to need only a rough estimate of the sensor node position, with an error margin similar to the range of the acoustic beacon. The sensor node sends acoustic beacons every six seconds and constantly streams optical data. When a packet is successfully received by the AUV over the optical link it switches from using the acoustic beacons to the optical signal to stay hovering over the sensor node.

In [39], the medium access problem that occurs when a data mule visits a cluster of nodes is examined. More specifically, the authors compare random access schemes with a proposed polling-based scheme called UW-polling. The protocol consists of three parts: a neighborhood discovery phase where the AUV determines which nodes to poll, a data prioritization phase where the nodes communicate what data to send and finally the AUV  polls the nodes in an order determined in the previous phase. UW-polling is compared to random-access schemes, CS-Aloha  and Distance-aware collision avoidance protocol (DACAP), in terms of throughput, packet delivery ratio, delay and energy efficiency. The CS-Aloha protocol is modified in the sense that the AUV  transmits trigger packets which triggers the Aloha procedure in the sensor nodes for a given time. The modification prevents sensor nodes to transmit blindly when the AUV is out of range. At low source power levels UW-polling offers benefit in terms of robustness compared to the other schemes, however, for higher source levels, the performance is similar to CS-aloha. In [40], UW-polling  is compared to another protocol proposed by the same authors called U-Fetch, in which sensor nodes forward data to cluster heads, which are appointed for communicating with the AUV. It is shown that U-Fetch provides lower latency than UW-polling, at the cost of lower packet delivery ratio.

A multi-modal data mule scenario using a combination of acoustic and optical communications is analyzed in [41]. The system uses the previously mentioned CS-Aloha-Trig protocol with a fixed physical-layer modality during each trigger period. Between trigger periods, the AUV  can decide to switch between acoustic and optical communication, based on the received power for each modem. Network  simulations using the DESERT framework [42], extended to model multi-modal communications, are used to determine the throughput in different water conditions. To handle difficult, turbid conditions, the data mule needs to stand still longer at each node in order to correctly determine when to switch physical-layer modality.