UUV Underwater Communications and Networking

Protocol and test design for heterogeneous UUV networks with scarce, delayed, and intermittent acoustic links.

Robotics and Controls · Underwater Systems

An unmanned underwater vehicle (UUV) uses several networks with different physics: high-rate links inside the vehicle, tether or optical links at short range, acoustic communication underwater, and radio-frequency (RF) or satellite links after surfacing. Do not hide those boundaries behind one reliability model.

Link Typical role Design consequence
Copper or fiber tether ROV control, video, and sometimes power high bandwidth, tether mechanics, handling, and failure path
Acoustic modem command, status, and sparse data low throughput, long and variable latency, intermittent delivery
Optical modem short-range high-rate transfer alignment, turbidity, and ambient light
Wi-Fi or cellular commissioning and surfaced offload useful only at or above the surface
Satellite remote surfaced telemetry antenna exposure, cost, sky view, and latency
CAN, Ethernet, or serial onboard sensing and control bounded latency, load control, and fault containment

Keep high-rate sensing, control, and raw logging onboard. Use the external link for mission control, health, progress, detections, and carefully selected data products.

Design for acoustic constraints

One-way propagation delay is approximately

\[t_p = \frac{R}{c}\]

where $R$ is range and $c$ is local sound speed. Using $c = 1500\ \text{m/s}$ at 1 km range:

\[t_p \approx 0.67\ \text{s}\]

The propagation-only round trip is therefore at least 1.33 s before packet duration, processing, medium access, acknowledgment, or retry delays. Multipath, Doppler, ambient noise, self-noise, geometry, and transducer placement add loss and variability.

WHOI’s Micro-Modem documentation spans roughly 80 to 5400 bit/s across supported packet types. Those are modem capabilities, not guaranteed application throughput. Packet overhead, medium access, retries, range, and channel conditions reduce useful rate.

Track application goodput separately:

\[G = \frac{\text{successfully delivered payload bits}} {\text{elapsed time}}\]

A 32-byte payload delivered once in 5 s is only 51.2 bit/s of application goodput, regardless of the modem’s burst signaling rate.

For a one-way acoustic transmission, a screening signal-to-noise ratio is:

\[\mathrm{SNR} = \mathrm{SL} - \mathrm{TL} - \mathrm{NL} + \mathrm{AG}\]

where source level SL, transmission loss TL, noise level NL, and receive array gain AG use compatible underwater decibel references and bandwidth. Link margin is:

\[M = \mathrm{SNR} - \mathrm{SNR}_{\text{required}} - L_{\text{implementation}}\]

A first-pass spherical-spreading estimate is:

\[\mathrm{TL} \approx 20\log_{10}\left(\frac{R}{1\ \text{m}}\right) + \alpha R\]

At 1 km, spreading alone contributes 60 dB before absorption, boundary interaction, shadowing, multipath, transducer pattern, or installation loss. A hypothetical budget with SL = 190 dB, TL = 70 dB, NL = 85 dB, AG = 0 dB, required SNR = 12 dB, and 5 dB implementation loss leaves 18 dB margin. The number is useful only if the reference quantities, receiver bandwidth, waveform, depth, sound-speed profile, and noise state are defined.

Measure packet delivery and SNR against range, geometry, vehicle state, and time. The link budget predicts whether detection is plausible. It does not predict collision loss or queue delay. For shared channels, define time-division multiple access (TDMA), reservation, polling, or contention behavior, and size guard time for propagation uncertainty, clock error, and modem turnaround.

Budget the complete transaction

For an acknowledged exchange:

\[T_{\text{cycle}} = T_{\text{tx}} + \frac{2R}{c} + T_{\text{processing}} + T_{\text{ack}} + T_{\text{access}}\]

The terms for modem processing, acknowledgment duration, and medium access can dominate propagation. WHOI reports an example in which a rate-5 packet takes 4.9 s to transmit, while adding acknowledgment at 1500 m grows the cycle to about 15.5 s. That vendor example is configuration-specific, but it demonstrates why signaling rate is not transaction latency.

Build a timing budget for each message class:

Message Payload Maximum age Retry policy Queue priority
abort or safe-state command minimal fixed schema expires quickly bounded immediate retries highest
mission redirect compact waypoint or behavior update mission dependent acknowledged and idempotent high
health summary selected state and fault bits one reporting interval replace stale entry medium
detection report timestamped feature summary science dependent store and forward medium
bulk data chunked product usually delay tolerant resume-capable low

Estimate energy per delivered message

A first-order transmit-only estimate is:

\[E_{\text{delivered}} \approx \frac{P_{\text{tx}}T_{\text{tx}}}{p_{\text{delivery}}}\]

For an illustrative 20 W transmitter, 2 s transmit duration, and 0.8 delivery probability:

\[E_{\text{delivered}} \approx 50\ \text{J}\]

One hundred such delivered messages consume about 5 kJ, or 1.39 Wh, in transmit energy alone. Add listening, receive, processing, wake-up, retry scheduling, and power-amplifier efficiency before using the result in a vehicle energy budget.

Make the application protocol interruption-tolerant

Assume the link can disappear, duplicate messages, deliver them out of order, and recover after a command has become stale.

Use:

  • compact, versioned message schemas,
  • explicit source, destination, mission, and sequence identifiers,
  • timestamps and validity windows,
  • idempotent commands where practical,
  • acknowledgments with bounded retry and a defined terminal state,
  • priority queues and rate limits,
  • store-and-forward status,
  • authentication and replay resistance appropriate to the threat and hardware model.

Keep command semantics independent of transport retries. A repeated packet must not repeat an irreversible action.

Define command authority

Specify:

  • which commands are valid in each mission state,
  • whether remote control can override an onboard abort,
  • expiry and replay handling,
  • link-loss behavior,
  • operator confirmation for destructive or unrecoverable actions,
  • behavior when topside and onboard mission versions disagree,
  • how authority transfers between acoustic, tethered, and local operators.

A message can be correctly decoded and still be unsafe to execute.

Engineer the onboard network separately

Define:

  • clock source, synchronization accuracy, and timestamp location,
  • message schemas, units, frame conventions, and compatibility rules,
  • bandwidth budgets and burst headroom,
  • queue limits, backpressure, and overload behavior,
  • startup dependencies and degraded operation after a node failure,
  • stale-data detection and process supervision.

ROS 2’s sensor-data QoS uses best-effort reliability and a small queue because timely samples may matter more than complete history. That can suit some onboard sensor streams. Commands, configuration, mission state, and safety data need profiles chosen from their actual loss, replay, and deadline semantics. Publisher and subscriber QoS must also be compatible or they will not communicate.

Record:

  • modem, transducer, and firmware versions,
  • frequency band, waveform, source level, and vendor sensitivity values,
  • range, depth, geometry, orientation, and water profile,
  • ambient and vehicle self-noise state,
  • packet size, offered load, delivery ratio, goodput, and latency distribution,
  • retries, duplicate rate, and energy per useful message,
  • mission state and vehicle operating mode.

Test command expiry, duplicate delivery, partial message sets, long outages, saturated queues, clock disagreement, and recovery. Validate in the actual acoustic environment. A vendor range or rate is scenario-dependent.

UUV Navigation and State Estimation, Measurement and Instrumentation, and Design Verification and Test.

Sources