21.1. Overview

Agents offering the LINK service provide single-hop communication.

Single-hop here refers to a single hop in the Unet sense. For example, a link may be provided over wireless RF network that has multiple physical hops (e.g. using UDP/IP). However, as long as the link does not pass through multiple Unet nodes, it is considered a logically single-hop link.

All agents supporting the LINK service must also support the DATAGRAM service ( Chapter 14 ).

It is recommended that agents offering the LINK service provide reliability, when requested. Agents that are able to provide reliability, do so by advertising the DATAGRAM service capability RELIABILITY.

LINK service providers using the PHYSICAL service should also consult the MAC service to determine when they should transmit.

In a typical Unet, gateway nodes may have several LINK service providers, with the ROUTING service ( Section 22.2 ) provider forwarding datagrams across links.

21.1.1. Messages

The LINK service defines only one optional message, used only by agents advertising the LINK_STATUS capability.

21.1.2. Parameters

Agents offering the LINK service may support the following parameter:

  • dataRate — nominal data rate of link in bps (0 if unknown)

21.1.3. Capabilities

Agents may support several optional capability:

Agents advertising this capability will send LinkStatusNtf messages on its topic, when a link becomes active, is lost, or has significant change in quality.

Start the 2-node network and connect to node A:

> agentsForService org.arl.unet.Services.LINK

> uwlink
« Reliable acoustic link »

Link protocol with support for reliability and fragementation-reassembly.

  MTU ⤇ 848
  RTU ⤇ 848

  dataRate ⤇ 731.4286

  acks = 2
  controlChannel = 1
  dataChannel = 2
  mac = mac
  maxPropagationDelay = 2.5
  maxRetries = 2
  phy = phy
  reservationGuardTime = 0.5

> uwlink << new CapabilityReq()

We see that in the 2-node network simulation, the only agent that provides the link service is the uwlink agent of type ReliableLink . This agent fragments large datagrams, and transmits a batch of frames at a time, before waiting for an acknowledgement from the peer node. Unacknowledged frames are retransmitted until all frames are delivered, or there are too many retries. Once all frames are received, the peer node’s uwlink agent reassembles the datagram and delivers it. The agent also provides link status notifications.

ReliableLink provides the LINK service for all underwater links in Unet basic stack that ships as part of the community edition.

With the default PHYSICAL service settings, the nominal data rate provided by this link is 731 bps, and that only 848 or less bytes may be transferred per datagram. The actual data rate may differ, depending on the size of the datagram, reliability settings, and the channel conditions.

We also see that ReliableLink provides a set of configurable parameters:


Number of acknowledgements to use for reliable data transfer. Since a lost acknowledgement frame results in retransmission of the entire batch of frames, multiple acknowledgements are used to improve the robustness of the acknowledgement frame.


Frame type to use for control information. This is usually the CONTROL frame type.


Frame type to use for data frames. This is usually the DATA frame type.


MAC service provider to use for reserving the channel. This is automatically discovered during startup. Setting this to null disables MAC reservation.


Maximum expected propagation delay for the link (in seconds). This should be set based on the expected single-hop communication range, and the sound speed (in case of acoustic links). This parameter is used to determine expected round-trip time for setting timeouts for acknowledgement frames.


Maximum number of retries per frame. Once the maximum number of retries is exceeded, a datagram transfer is deemed to have failed.


PHYSICAL service provider for data transmission. This is automatically discovered during startup, but may be configured manually on gateway nodes with multiple PHYSICAL service providers.


Guard time (in seconds) that is included in a MAC reservation of the channel. The guard time allows for small timing variability in transmission and small delays in response from peer node.

In the Unet premium stack, ECLink replaces ReliableLink as the default LINK service provider for underwater links.

ECLink uses an erasure correction code (type of error correction code that deals with lost frames) to reduce the protocol overhead required for retransmissions in a lossy channel. This usuaully results in significantly better performance than ReliableLink in poor channel conditions, and when transferring large datagrams.

If you have a modem with the commercial version of UnetStack3, it’ll have ECLink loaded as the default LINK service provider:

> uwlink
« Erasure coded link »

Link protocol based on erasure coding, for fast large data transfers over a single hop.

  MTU  3145584
  RTU  1450

  compress = true
  controlChannel = 1
  dataChannel = 2
  mac = mac
  maxBatchSize = 65533
  maxPropagationDelay = 3.0
  maxRetries = 2
  minBatchSize = 3
  phy = phy
  reliability = false
  reliableExtra = 0.2
  unreliableExtra = 0.3

  dataRate  731.4286

> uwlink << new CapabilityReq()

We see that the MTU for ECLink is quite large (as compared to ReliableLink ), as ECLink can efficiently transfer large amounts of data. While the dataRate parameter advertises a similar nominal rate as with ReliableLink , you’ll find that ECLink yields better practical performance when transferring large files, and in poor channel conditions. ECLink also supports data compression, and link status notifications.

The phy , controlChannel , dataChannel , mac , maxRetries , and maxPropagationDelay parameters of ECLink are similar to the ones in ReliableLink . However, ECLink has several additional parameters that control performance:


Minimum number of frames to send in each batch.


Maximum number of frames to send in each batch.


Default reliability for a datagram transfer, if a DatagramReq does not specify reliability ( null ).


Fraction of extra frames to transmit for erasure correction, during reliable datagram transfer (using acknowledgements to determine retries). A value of 0.2 indicates 20% extra frames are transmitted. This allows for 20% frame loss without the need for retries.


Fraction of extra frames to transmit for erasure correction, during unreliable datagram transfer (no acknowledgement or retries). A value of 0.3 indicates 30% extra frames are transmitted. This allows for successful datagram transfer with as much as 30% frame loss.


Enable/disable data compression.

<<< [Medium access control] [Routing and route maintenance] >>>