guwmanet—multicast routing in underwater acoustic networks

GUWMANET – Multicast Routing in Underwater Acoustic Networks

Michael Goetz1, Ivor Nissen2

1 Fraunhofer Institute for Communication, Information Processing and Ergonomics (FKIE), 53343 Wachtberg, Germany, [email protected]

2 Research Department for Underwater Acoustics and Marine Geophysics (FWG) – WTD 71, 24148 Kiel, Germany, [email protected]

Abstract: Underwater networks move more and more into the focus of the research community, especially for military purposes. They enable the full integration of underwater components like submarines or sensor platforms into maritime Network Centric Warfare (NCW). Nevertheless, most of the scientific work was done in physical layer methods and medium access protocols.In this paper we introduce a new network protocol called Gossiping in Underwater Acoustic Mo-bile Ad-hoc Networks (GUWMANET), which realizes medium access and routing functionality in a cross-layer design. In contrast to other routing approaches for underwater networks, we de-veloped a network protocol from scratch, fitting the special needs of underwater communication, instead of adopting existing terrestrial protocols.We use multi-hop strategies to achieve a higher maximum transmission range than that of our physical layer method. Additionally, multicast addresses are used which allow an unlimited number of nodes. The routes between the nodes are build up automatically and need no prece-ding configuration, which allows a full ad-hoc capability including mobile nodes. In combina-tion with the Generic Underwater Application Language (GUWAL), which has a 16 bit header with the multicast source and destination address, GUWMANET needs only 10 bits additional overhead. This is realized by using gossiping strategies, where each node itself decides whether it forwards the data or not.Keywords: multicast, multi-hop, gossiping, routing, underwater acoustic networks, mobile ad-hoc networks, emission control, implicit acknowledgment, clustering, bursts

I. IntroductionIn the last years, underwater networks received more and more attention

in scientific, industrial and particularly military areas. They enable the full integra-tion of underwater components like submarines, Autonomous Underwater Vehicles (AUVs), gliders, or bottom sensors into maritime Network Centric Warfare (NCW) for example in Mine Counter-Measure (MCM) or Anti Submarine Warfare (ASW) operations. Especially, Underwater Wireless Networks (UWNs) moved into the fo-cus of the research community to enable full flexibility of the platforms without

28 Military Communications and Information Technology...

the need for any cables, which are not only expensive but also difficult to handle and limiting the maneuverability of the moving nodes [1].

The ocean is almost impervious to electro-magnetic waves which makes them useless for wireless underwater communication over distances greater than a hundred meters; wireless communication to submerged nodes can only be realized using sound. The network protocol GUWMANET presented in this paper, developed by Fraunhofer FKIE and FWG, is designed to establish a robust mobile ad-hoc UWN working in all-weather and sea conditions. Within this scope GUWMANET is a possible candidate to fulfill delay tolerant scenarios defined by the project Robust Acoustic Communications in Underwater Networks (RACUN) under the European Defense Agency (EDA) [2], [3]. A detailed description of the sce-narios follows in Chapter III.

II. Physical layer restrictionsIn principle, sound waves can propagate several hundreds of kilometers

in deep waters, nevertheless they underlie natural restrictions which make robust underwater communication challenging. Due to the fact that the absorption loss of sound waves increases with frequency, the available bandwidth stays in reciprocal relation to the maximum transmission range, as shown in Figure 1. In addition, the weather conditions influence the maximum transmission range, because breaking waves and rain increase the noise level. To overcome these bandwidth limitations, we introduce multi-hop strategies in our protocol, which are well-known from terrestrial Mobile Ad-hoc Networks (MANETs).

Figure 1. Upper bound of the User Data Rate (UDR in bps) over transmission range (km) in deep and shallow waters and different weather conditions, simplified with homogeneous propagation

conditions. The worse the weather condition, the lower is the expected transmission range

29Chapter 5: Tactical Communications and Networks

GUWMANET is designed for a physical layer method based on impulse com-munication, the so called Transient Underwater Acoustic Communication System (TUWACS) [4]. It sends out short data bursts with a fixed length of 128 bit in 0.3 s plus 10 bits for a network header. This clarifies that there is no room for much pro-tocol overhead and an underwater network protocol must be as efficient as possible.

Another difference to terrestrial communications is the low and varying sound propagation speed between 1405 and 1560 meters per second. This does not only increase the Doppler compensation complexity significantly, but also the signal prop-agation delay. TUWACS is designed for a maximum internode distance of 10 km. This distance leads to an optimal frequency band of 3.5−7.5 kHz. A transmission over a distance of 10 km needs 6−7 s, which must be considered in the protocol design. A basic assumption of terrestrial protocols is that the transmission time is much higher than the propagation time. Therefore, terrestrial network protocols cannot be easily adopted. Instead, a completely new one has to be developed from scratch to meet the requirements of underwater networks.

III. ScenarioWith reference to Figure 2, in the scalable RACUN scenario [5] it is assumed

that an underwater acoustic network is deployed in proximity of a harbor to be surveilled. All nodes are bottom-mounted and organized in subsequent barri-ers. These are sets of nodes arranged in a line topology: the first barrier is placed in front of the harbor, and is composed of the largest number of nodes in order to ensure the largest sensing coverage along the coast. The distance between nearest neighbors within a barrier is set to 3 km. The sensing range is assumed to be 2 km. Every 8 km comes another barrier which can sense movement as well as relay data towards the cooperating fleet at the sea base. Again, the nodes in the barrier are arranged in a line topology. While proceeding towards the sea base, the number of nodes per barrier is reduced from 5 (in the first barrier) to 2 (in the barrier far-thest from the shore); in fact, the most important sensing task is carried out near the coast, whereas the barriers out at sea are key for relaying packets. Nevertheless, their sensed data are useful to confirm the detections of the first barrier and to give some further clue about the direction of movement of the boats exiting the harbor.

The network covers a total area of 16 km × 32 km. We recall that the intended maximum transmission range of a node in our networks amounts to about 10 km, hence the barriers are typically in range of each other. In this paper, we assume that two nodes are deployed close to the last barriers: one buoy on the right side and one ship on the left side. These entities are part of the network, and act as seaborne sinks.

Although the number of nodes is reduced after each barrier, our network to-pology features high connectivity, and multiple path alternatives exist. This makes the network robust against node failures as well as broken links (for example caused


by the noise of the boat propellers disturbing the communications). Additionally, the gateway buoy and the ship stationing at sea are equipped with both acoustic and radio communication hardware: therefore, as either receives data over acoustic links, such data is immediately relayed to all other sinks and the cooperating fleet using radio communications.

3km

8km

Last barrier

First Barrier

Sea base withcooperating �eet

Surveilled harbor

Ship Buoy

Figure 2. RACUN harbor surveillance network scenario, with 14 bottom nodes organized in 4 parallel barriers. Additionally, a ship and a gateway buoy act as sea-borne sinks, as they gather detection infor-

mation from the network and relay it to the cooperating fleet stationing in the sea base area

The traffic generation pattern in this scenario is inherently event-based, for example the detection of an intruder by a sensor node. Most of the time there is no communication in the network. Also the network protocol should work reactively instead of generating periodically control messages. This saves energy and keeps the network covert.

IV. Application dataBesides the physical layer restrictions, it is important to know which kind

of data will be transmitted in the network in order to design an appropriate network protocol. Due to the low bandwidth the application data format must be as short and efficient as possible. For this propose we specified the so called Generic Underwater


Application Language (GUWAL) [6] which is suitable for any kind of underwater application. It is based on the following four parcel types:

1. Data Request2. Data (sensor data, status, GPS position, ...)3. Command and Control (sleep, move, change mode, ...)4. Text Message (SMS)In GUWAL the basic parcel size is 128 bits; but it is also possible to use

variable length if needed. All parcels include an operational header, a checksum of 16 bits each, and 96 bits payload with variable fields depending on the parcel type, as shown in Table 1. Among other fields, the header contains a source and a destination address used for a cross-layer approach. An operational address is 6 bits long, whereby the first two bits define the type of the node. The following groups are defined:

1. Gateway Node (buoy/ship with acoustic and radio link)2. Bottom Node (environment sensor or relay node)3. Mobile Node (submerged unit: diver, AUV, submarine)4. Surface and Air Nodes (node without acoustic link like ship, airplane or operation center via satellite).

Table 1. Format of a GUWAL parcel with source, destination and priority field as header and a checksum

Position Length Field1-2 2 Parcel Type3 1 End-to-End Acknowledgment4 1 Priority Flag

5-10 6 Operational Source Address11-16 6 Operational Destination Address17-112 96 Payload113-128 16 Checksum

The latter four bits are a node identifier to distinguish nodes of the same type, whereby zero is defined as broadcast to all nodes of the same type. The address with all bits set to one is reserved for broadcasting to all nodes in the networkregardless of their type. As a result, there are 15 network addresses in groups 1-3 and 14 in group 4, hence 59 in total. In order to allow more than 59 par-ticipants in the network, it is envisaged that multiple nodes can share the same address. For example, it is not mandatory from an operational point of view to distinguish bottom nodes in the same area, especially if they are only relay nodes. As a consequence, the network protocol may handle nodes with the same address as multicast groups. How this is achieved by GUWMANET is explained in detail in the following chapter.


V. Protocol designIn this chapter we introduce our new network protocol GUWMANET. In the first

part, we introduce the Medium Access Control (MAC) and the Automatic Repeat re-Quest(ARQ)mechanismswhichareusedin GUWMANET.Furthermore,the detailsof the addressing problem resulting from shared multicast addresses are discussed. The introduction of a local nickname additional to the GUWAL network address is motivated. At the end we describe the initialization steps and the routing algorithm, followed by an extension for improvements based on network-coding strategies.

A. Medium Access Control

The MAC layer manages the access to the acoustic communication channel. This can be done in a contention-free manner like code, space, frequency or time division multiple access or randomized, accepting possible collisions in the shared medium water. We decided to apply a time-based random access method, which is much more efficient than fixed divisions in networks with event based and bursty traffic and a physical layer using short impulses, as in underwater scenarios. A de-tailed survey of MAC mechanisms with regard to underwater acoustic networks can be found in [7].

In random access methods every node can access the sound channel whenever it has data to send while regarding specific rules. The methods can be subdivided into two types, with previous channel reservation or direct data transmission. In our case channel reservation is inefficient, because the data packets consisting of 128 bits are already very short and a reservation would take a long time due to Round Trip Times (RTT) of up to 15 s having internode distances of 10 km. Moreover, the transmission times are with 0.3 s short compared to the long propagation delay. Most of the time, nodes wait for incoming data packets instead of transmitting. This is an important distinction to terrestrial networks.

Another consideration is to apply carrier-sensing before transmitting data. However, sensing the medium prior to a transmission does not allow drawing conclusions about the channel state at the receiver side several seconds later when the signal arrives. Hence, we use a simple ALOHA [8] method without carrier-sensing in GUWMANET. Nevertheless, we point out that underwater acoustic communication is half-duplex. It is not possible to transmit data during a recep-tion or vice versa.

B. Automatic Repeat reQuest

Using a random access method like ALOHA means that packet collisions may occur, even if the transmissions itself are very short. Additionally, bit errors due tohighnoiseorlowsignalstrengthcan resultin packetlosses.Therefore,ARQ


methods have to be used to guarantee a successful reception. Typically, the receiver node sends an acknowledgment packet back to the transmitter to indicate a correct packet reception. If an acknowledgment stays out, the source node will automati-cally repeat the packet after a predefined period of time.

The application language GUWAL already supports end-to-end acknowledg-ments, which are sent by the final destination node as operational notice of receipt. This acknowledgment is optional and is requested by setting the acknowledg-ment bit in the header.

In multi-hop networks it is reasonable to add additional link layer packet repetition mechanisms, which will detect packet losses at each hop. In wired net-works explicit packets have to be sent to inform the transmitter about a successful reception. In MANETs this can be done in an implicit way without additional transmissions due to the shared medium in wireless multi-hop networks. The source node is able to overhear if the next hop forwards the packet and therefore gets a so called implicit acknowledgment. If the packet will not be forwarded, the source node will automatically repeat the packet until it overhears a packet forwarding at-tempt. In consequence, the destination node must also repeat the packet to inform the previous hop about the successful reception.

In GUWMANET this implicit acknowledgments are used with exponential backoff timers for packet error control as described later in Section G. Addition-ally, our network protocol is delay tolerant and supports so called Emission Control (EMCON), which means that nodes can decide to stay silent for an arbitrary time period. This is for example important for submarines, which do not want to get detected due to transmissions. Therefore, it is possible that acknowledgments stay out, even the transmission was successful. A packet is repeated with exponential backoff to attempt to deliver the packet successfully, but it cannot be guaranteed that the packet was received correctly. It is also not possible to make assumptions like a node is broken even if it did not reply for a longer period. Nevertheless, for this period where a node stays in EMCON state it is not available for packet for-warding and related routes have to be updated.

C. Addressing

As mentioned earlier, each network address can be used as multicast group including multiple nodes of the same type. From operational view, it is not man-datory to distinguish nodes inside this group, but for the network protocol it is mandatory to facilitate forwarding mechanisms. Therefore, we introduce a second local address of 5 bits in addition to the global 6 bit operational network address, which is independent from the network address and the node type. In the following this local address is called nickname.

To allow full ad-hoc capability, the local nicknames are not predefined and have to be chosen automatically after network deployment. In our MANET exists


no master node coordinating the address allocation, therefore each node has to choose its nickname by itself. These should be unique in the local 2-hop neigh-borhood to allow all nodes to distinguish between its neighbors. Typically, this is done making a neighborhood discovery, where the new node requests lists with neighborhood information from all its neighbors. We propose another algorithm to reduce the number of transmissions and thereby the energy consumption, because battery power is a limited resource in underwater scenarios.

The idea is to overhear at first the network traffic for a listen period TL. If dur-ing this period communication takes place in the neighborhood, the node becomes acquainted with its neighbors and learns their nicknames passively. Additionally, it gets information about its 2-hop neighborhood, because the network header of GUWMANET includes beside the transmitter’s nickname also the nickname of the last hop, as described later. After TL the node knows a subset of its 2-hop neighborhood and chooses randomly a presumably free local nickname. Now it transmits to its local neighborhood a nickname notification (NN) parcel to indicate its presence and nickname choice. The chosen nickname is included in the network header as source address. All other information is included inside a special GUWAL parcel. GUWAL has reserved a separate data type for such network control parcels where each network protocol can define up to eight individual control parcels.

The network control parcel NN of GUWMANET includes the predefined multicast GUWAL address of the node, its unique 16 bit MAC address and a list with up to 10 local nicknames of its by now known 1-hop neighbors, as shown in Table 2. Typically, underwater networks are sparse; anyway, multiple NN packets are sent if there are more than 10 neighbors. The NN parcels are also used for network initialization described in the next section.

Table 2. Format of a Nickname Notification (NN) parcel included in a GUWAL Data frame

Position Length Field1-2 2 Parcel Type (Data)3 1 End-to-End Acknowledgment (no)4 1 Priority Flag (low)

5-10 6 Source Address (own address)11-16 6 Destination Address (broadcast = 1111112)17-20 4 Data Type (Network Control)21-23 3 Network Control Type (NN)24-42 19 Timestamp43-92 50 Nicknames of 10x 1-hop Neighbors

93-108 16 MAC (own address)109-111 3 unused113-128 16 Checksum


If any of the neighbors receives a NN and has an objection, because it already has a neighbor with this nickname, it replies with a nickname collision notifica-tion (NCN) parcel which has the same fields as the NN parcel. But instead of us-ing the own 16 bit MAC address the one of the discovering node is used which was included in the corresponding NN parcel. This allows the discovering node to extend its 2-hop neighborhood list and to choose another free nickname. Before transmitting a new updated NN parcel the node waits a period TC to collect further NCN parcels if such were send. In the case a node receives an NN parcel in which it is not included in the 1-hop neighborhood list, it automatically sends its own NN parcel to inform the other node about its presence, if it has not already sent an NCN parcel for that nickname notification.

NCN parcels are repeated with a binary exponential backoff algorithm until a new NN parcel is received or a limit of Lrep is reached. An exponential backoff is used to allow fast repetitions to correct simple packet errors at the beginning and late repetitions to handle (temporally) asymmetric or broken links. NN par-cels are not repeated automatically, only after the incoming of NN or NCN parcels of neighbor nodes.

Although the probability is low, it is possible that nickname collisions stay undetected. This may occur due to packet losses, asymmetric or temporally bro-ken links during the nickname allocation, or mobile nodes moving to other areas. Therefore, the network protocol is designed to tolerate double nickname occupan-cies. This only leads to redundancies during packet forwarding as will be shown later. If a nickname collision is detected later, the detecting node will try to fix this by sending an NCN parcel, followed by the same procedure as described above.

D. Initialization

In our network protocol each node among the nickname needs some initial network control information. This information is exchanged automatically with an initialization parcel after a node deployment to allow full ad-hoc capability. This parcel includes for example a 32 bit UNIX timestamp. The timestamp is used as reference time for a shortened 19 bit timestamp which is used in GUWAL, see Table 2. It allows date stamping inside a three month operating period with an ac-curacy of 15 s.

Due to the limited battery power resulting in an operation period of three month, inaccurate clocks with a clock drift of one second per week and a lack of syn-chronization it is not necessary to have a longer timestamp with higher accuracy. Before a node can use this shortened GUWAL timestamp it must know the starting point regarding to the UNIX timestamp where the GUWAL timestamp is zero.

The initialization parcel is send out as reply to parcels with a timestamp set to zero, here the NN parcel. After the node received the initialization parcel it is ready for use.


E. Routing

In this section we describe the routing strategies of GUWMANET in detail. As mentioned before, multi-hop strategies and multicast addresses are used to fulfill the operational needs of an underwater network. Besides this, an important design aspect was to have as less overhead as possible due to fixed burst length of the underlying impulse communication.

The basic idea behind GUWMANET is to leave the decision whether to for-ward a parcel to the nodes themselves, comparable to the behavior when gossiping. A node hears a parcel/gossip and decides if there are nodes in the neighborhood which may be interested in this information. If any node repeats everything we have simple flooding, but this is very inefficient and wastes a lot of energy. Therefore, the nodes in our network learn passively if they are on the direct route to the des-tination. As already mentioned, we need only 10 bits additional network protocol overhead for this purpose. The 5 bit local nickname of the transmitter and during route establishments the nickname of the last or next hop.

In the beginning, the nodes have only information about the topology in the lo-cal two-hop neighborhood. To get global topology information, each node stores all incoming packets: P D × H × T × Swhereby D represents the 128 bits GUWAL data packets, H the network headers, T the local receive times and S the estimated Signal-to-Noise Ratio (SNR).

After a listen period TL plus an additional random backoff time TBackoff each node forwards the data packet d, even if it is addressed itself as destination, because there might exist more nodes in the network with the same operational network address (multicast). The forwarding node puts its own nickname into the source address field of the network header. For the last hop field all received parcels with data content d in M are considered: Pd: ={(d', h', t', s') P | d' = d}

In this subset all parcels with a SNR lower than a threshold SNRmin are filtered out:

min: {( ', ', ', ') | ' }d dP d h t s P s SNR

As last hop field the own nickname is chosen if the node is the first trans-mitter or the nickname of the transmitter of the first received parcel m in Pd

* or, if Pd

* is empty, the parcel with the highest SNR is chosen:

* * *' : " : ' ", if

' : " : ' ", elsed d d

d d

p P p P t t PP

p P p P s s

If a node overhears that it was elected as last hop inside a forwarded message of one of its neighbors, it generates a temporary routing entry with the two 6 bits


source and destination addresses included in the data part and the physical ad-dresses of the last and next hop.

All addressed destination nodes receiving the packet have to reply with an acknowledgment parcel. With the help of the temporary routing entries the acknowledgment packet can be routed back to the source node. Each node that was elected as last hop knows that it is on the direct way back to the source node and responsible for data forwarding. All nodes being involved in the back routing process convert the temporary routing entries into permanent ones and will now forward all data packets with the same GUWAL source and destina-tion address tuple. We emphasize that after this process only the routes from the source node to the destination nodes are learned but not vice versa, because there might be more nodes with the same address like the source node which are not considered yet.

After a route is established, all following data transmissions are sent with the last hop field set to zero. This indicates that there is a known route and all other nodes without permanent routing entries should not flood this message again. If the route gets broken due to node or link failures, the last hop field is reused again as before, which initiates a new route discovery with flooding.

Mobile nodes like submarines and AUVs possess a special role during the route discovery process. Due to their mobility, they are bad candidates for static routes. Therefore, they are only elected as last hops if there exist no alternatives after an additional waiting period of Tmob. Also, the established routes to or from mo-bile nodes have a limited lifetime. If a node has not forwarded a message during a predefined time period Tlife the routing entries are discarded and a new routing process is started, because it is unlikely that this route still works. Mobile nodes can be easily identified by their operational address; they have the group number 3 as defined in Chapter IV.

We explain in the next section with a simple example how the above described route establishment works.

F. Route establishment example

Figure 3 shows an example topology whereby each dot represents a node and each line a connection between two nodes. The number above each node represents its local nickname, whereby the apostrophes are only for distinction in this description. In reality the nicknames 1 and 1’ are equal. The local nicknames should only be unique in the two-hop neighborhood if possible. In the following, we explain how the route establishment works; if node 1 with the GUWAL address A wants to transmit data to node 4’ with the GUWAL address B.


Figure 3. Example network topology with local nicknames

First of all, node 1 broadcasts its data packet. Thereby, the source nickname and the last hop field inside the network header are set to 1: 1 → [1,1] + [A → B: DATA]

In the beginning, no nodes have routing information. Therefore, all neighbors of node 1 which receive this message forward the data. The parcel itself stays steady, whereby the source nickname of the network header is replaced by the nickname of the forwarding node. As last hop the nickname of node 1 is chosen, as shown in Figure 4. 2 → [2,1] + [A → B: DATA]

In this way, the message is flooded through the network.

Figure 4. Node 2 rebroadcasts the data of node 1. Node 1 overhears that it was chosen as last hop and creates a temporally routing entry

Figure 5. Temporally routes (see Table 3) used to send back the acknowledgment. On the way back, the routing entries get persistent

During this flooding process each node overhearing a message with a last hop nickname equal to its own creates a routing entry in a temporally routing table, as shown in Table 3.

Also the addressed node 4’ with the GUWAL address rebroadcasts the data par-cel, because there might be more nodes with the GUWAL address B in the network: 4’ → [4,3] + [A → B: DATA]


After this, node 4’ sends out an acknowledgment parcel which is forwarded back to node 1 using the temporally routing tables. During the complete back forwarding the last hop field is set to zero: 4’ → [4,0] + [B → A: ACK]

Table 3. Temporally routing entries of all nodes

Node From To Next Node From To Next1 A B 2 7 A B 81 A B 3 8 A B 6’1 A B 4 3’ A B 4’1 A B 5 5’ A B 7’1 A B 6 6’ A B 2’1 A B 7 7’ A B 1’2 A B 3’ 4’ A B 8’3 A B 5’

Due to the empty last hop field, the message is not flooded back. Instead, only node 3’ forwards the acknowledgment back, because it has a temporally routing entry after overhearing his election as last hop from node 4’ in the pre-vious transmission. This is repeated until the acknowledgement reaches node 1 and a complete persistent route is established. Even, if there is more than one destination node, all routes are learned simultaneously. Additionally, we point out that it is necessary to store the data parcel itself in each temporally routing entry, to distinguish parallel route discoveries. The acknowledgment parcel includes the 16 bit checksum of the data parcel which allows an association of the ACK with the temporary routing entry.

As mentioned before, this route is valid for transmissions from A to B only and not vice versa, because the GUWAL address of A is not necessarily used as unicast address.

G. Packet loss and broken link handling

In general, the probability of collisions in the underwater channel is very low; even though flooding creates a lot of redundancy during the route establishment phase. That is because the transmission time is very low compared to the propaga-tion time; in consequence the channel is idle most of the time and not occupied with an ongoing transmission. In our underlying impulse communication we have a transmission time of 0.3 s for a GUWAL parcel whereas the propagation time can be up to 6−7 s. This is a fundamental difference to terrestrial networks where the data rate is much higher and the signals propagate with light speed.


On the other side, the bit error rate of an underwater channel can be very high, depending on weather conditions and noise. Therefore, packet losses must be handled. As mentioned in the previous chapter we use implicit acknowledgments to indicate successful transmissions from hop to hop. If a packet forwarding from a neighbor stays out, the message will be repeated. In GUWMANET a message is retransmitted up to 5 times with an exponential backoff. After this, the link is declared as broken and the neighbor is removed from the neighborhood list.

If a link is broken during a forwarding process on an established route, the route has to be updated. As already mentioned, this is done by using the last hop field. The neighbor nodes will flood the message again, if the last hop field is nonzero. This results in a new route discovery process to renew the broken route.

Nevertheless, these single routes without redundancy are very vulnerable to temporally link failures or asymmetric links. To overcome this problem, we intro-duce in the next section an enhancement of GUWMANET, which adds additional redundancy along a route if necessary.

H. Corridor as route enhancement

In this section we introduce a modification of GUWMANET to enhance the packet delivery ratio during bad weather conditions. Rain and breaking waves on the surface increase the channel noise significantly which leads to a much higher bit error rate. To overcome this problem, additional redundancy is gener-ated by involving the neighbors along the direct route. We call this enlarged route corridor, which is illustrated in Figure 6.

Figure 6. Corridor as route enhancement for a higher packet delivery ratio

For this objective, the route discovery process is modified in the following way. If a data parcel reaches one of its addressed destination nodes it will send out an acknowledgement as usual. But this time, the last hop is not left empty anymore. Instead, it is used in acknowledgment parcels as next hop field, where-in the transmitter puts its elected previous hop. This node is intended to forward the acknowledgment back to the source node. Now, not only this elected next hop will forward the packet, but also all nodes having this elected node as direct neighbor. This is like gossiping in the real world; gossip is circulated if you know your neighbor is interested in it too.


Figure 7 shows an example. Node 4’ has elected node 3’ as next hop, whereby node 6’ and node 7’ knowing node 3’ and 4’ participate as corridor nodes in the for-warding process. Multiple receptions at node 3’ allow utilization of network-coding strategies, as described later in Chapter VII. This technique allows restoring mes-sages, even if all single transmissions are error-prone.

Figure 7. Adding next hop during back forwarding of an acknowledgment

To avoid unnecessary transmissions, the additional corridor nodes only for-ward the data if the node on the direct route did not. For this purpose, we introduce an additional backoff Tcorridor to the normal backoff Tbackoff combined with the link quality Lquality which is between 0 and 1: Tforward = Tbackoff + Tcorridor . (2 − Lquality)

The timer is canceled if the node overhears a transmission of the node on the direct route or reset if the message was repeated first by another neighbor.

During the back forwarding of the acknowledgment the nodes on direct node make their persistent routing entries as before. But this time, also the nodes on the corridor make persistent routing entries, which indicate that they are jointly responsible to forward data parcels. Note, during data forwarding the next/last hop is still not used and left empty as before. The packet forwarding will be only decided with the usage of the persistent routing entries.

VI. EvaluationSea trials are costly due to the need of expensive equipment and personal. There-

fore, we developed an underwater acoustic emulation system to test GUWMANET in an environment as close as possible to real hardware. This emulation test bed uses a real acoustic channel with the same physical layer methods as underwater. The only difference is, that the communication takes place in air instead of water. Insulation material is used to model the absorption losses of sound waves, which allows the modulation of a scenario of 8 km × 30 km. Only the propagation delay is artificially created by delaying incoming transmissions.

A cluster of 10 computers equipped with microphones and loudspeakers are used to emulate the network nodes. They are arranged in a topology similar to the RACUN scenario described in Chapter III with 4 barriers consisting of 9 bot-tom nodes and an additional mobile node.


We implemented GUWMANET inside this emulations system and made a concept study of the routing mechanisms and first performance analyses. The route establishment algorithms were tested with 3 hops and multicast addresses. These emulations are the first step of the evaluation and will be enlarged to additional simulations and sea trials.

VII. Network-codingIn underwater acoustic networks high bit error rates are common. Therefore,

error detection and correction techniques have to be used to enable reliable com-munications. Common ways are the use in the form of so called checksums in com-binationwithARQandForward Error Correction (FEC) mechanisms in the physical layer methods. If a packet error is detected, the simplest way is to drop the packet and wait/ask for a retransmission. But retransmissions waste valuable energy, oc-cupy the channel and increase the packet delay.

A much more efficient way is to use a posteriori error correction techniques like clustering of all incoming short 128 bit parcels. The idea behind this is to merge multiple corrupted parcels and merge them into correct one. In real life gossiping messages contains lies; the gossip average results in true facts. The network-coding approach with clustering techniques was proposed in the RACUN project [9] and is an essential part of gossiping.

VIII. ConclusionIn this paper we introduced a new network called Gossiping in Underwater

Mobile Ad-Hoc Networks (GUWMANET). This protocol is designed from scratch fitting to the special needs of underwater communication. It is designed to fulfill the requirements of the scenarios defined in the RACUN project; an European project for robust underwater communication, supporting stationary as well as bottom nodes.

GUWMANET is based on impulse communication as physical layer method, which sends out short data bursts with a fixed length of 128 bit. This makes it nec-essary, that our protocol gets along with only 10 bit additional protocol overhead. These 10 bits are used for two 5 bit local nicknames, identifying the transmitter node and the last hop. With the help of these two fields a persistent route can be found, even if there are multiple destinations. We also defined the Generic Under-water Application Language (GUWAL) to overcome the restrictions of 128 bits for application data.

At least, we introduced a protocol enhancement using corridors for packet forwarding. These corridors generate additional redundancy if necessary and en-able network-coding strategies to restore error-prone messages. This is done by us-ing clustering algorithms, which can be used to the low message size of 128 bit and the low number of packet transmissions in underwater networks.


IX. Future workAs mentioned in the evaluation chapter, we already made first concept studies

and analyses of GUWMANET. The next steps are simulations with the simulation framework DESERT Underwater, an NS-Miracle-based [11], [13] framework to DEsign, Simulate, Emulate and Realize Test-beds for underwater network protocols [10] developed by the University of Padova. This framework allows us to enlarge our studies to higher node numbers as were foreseen in the RACUN scenario. Beside this, GUWMANET can be compared with other network protocols which are already implemented in DESERT underwater.

After detailed simulation and emulation studies sea trials are planned to demonstrate the capability of our network protocol to fulfill the requirements of the RACUN scenario.

X. AcknowledgmentWe gratefully acknowledge the partners of the project Robust Acoustic Com-

munications in Underwater Networks (RACUN) for their helpful discussions and advices. The RACUN project is part of the EDA UMS program (European Un-manned Maritime Systems for MCM and other naval applications), and is funded by the Ministries of Defence of the five participating nations Germany, Italy, Neth-erlands, Norway, Sweden. Partners of this project are: Atlas Elektronik (Germany), WTD71-FWG (Germany), L-3 Communications ELAC Nautik (Germany), TNO (The Netherlands), Kongsberg Maritime (Norway), FFI (Norway), FOI (Sweden), SAAB (Sweden), WASS (Italy) and CETENA (Italy).

REFERENCES

[1] I.F. Akyildiz, D. Pompili, T. Melodia, “Underwater Acoustic Sensor Networks: Research Challenges”, Ad Hoc Networks, vol. 3, no. 3, pp. 257-279, May 2005.

[2] European Defense Agency (EDA) Project Arrangement No. B0386, http://www.racun-project.eu

[3] J. Kalwa, “The RACUN-project: Robust acoustic communications in underwater networks – An overview”, OCEANS, 2011 IEEE – Spain, pp. 1-6, 6-9 June 2011, DOI: 10.1109/Oceans-Spain.2011.6003495.

[4] I. Nissen, “Alternativ Ansatz zur verratsarmen Unterwasser-kommunikaton durch Verwendung eines Transienten im Kontext von IFS und JUWEL”, FWG Research Report IB 2009-3; Research Department for Underwater Acoustics and Marine Geophysics (FWG) – WTD 71, Kiel, 2009.

[5] M. Goetz, S. Azad, P. Casari, I. Nissen, M. Zorzi, “Jamming-Resistant Multi-path Routing for Reliable Intruder Detection in Underwater Networks”, Proceedings


of the Sixth ACM Inernational Workshop on Underwater Networks, WUWNet’11, Seattle, Washington, USA, Dec. 1-2, 2011. DOI: 10.1145/2076569.2076579.

[6] I. Nissen, M. Goetz, “Generic Underwater Application Language (GUWAL) – A Specification Approach”, Research Report WTD71 – 0161/2010 FB, Kiel, Germany, 20.12.2010.

[7] R. Otnes, A. Asterjadhi, P. Casari, M. Goetz, T. Husøy, I. Nissen, K. Rimstad, P. van Walree, M. Zorzi, “Underwater Acoustic Networking Techniques”, SpringerBriefs in Electrical and Computer Engineering, DOI: 10.1007/978-3-642-25224-2_1, 2012.

[8] N. Abramson, “Development of the ALOHANET”. IEEE Transactions on Information Theory, 31(2):119-123, 1985.

[9] I. Nissen, M. Goetz, T. Wiegmann, T. Schäl, “Clustering of tactical underwater messages”, Research Report WTD71-0065/2012, Kiel 2012. In Preparation.

[10] R. Masiero, S. Azad, F. Favaro, M. Petrani, G. Toso, F. Guerr, P. Casari, M. Zorzi, “DESERT Underwater: an NS-Miracle-based framework to DEsign, Simulate, Emulate and Realize Test-beds for Underwater network protocols”, Oceans 2012, Yeosou, Republic of Korea, May 2012.

[11] The Network Simulator – ns-2, Last time accessed: March 2012. Available: http://nsnam.isi.edu/nsnam/index.php/User_Information

[12] The DESERT Underwater libraries – DESERT, Last time accessed: March 2012. Available: http://nautilus.dei.unipd.it/desert-underwater

[13] The Network Simulator – NS-Miracle, Last time accessed: March 2012. Available: http://dgt.dei.unipd.it/download

guwmanet—multicast routing in underwater acoustic networks

Documents