Chapters 3 to 5 assumed that a message, once built, somehow reaches its destination. Below the sea surface that assumption fails. Radio does not propagate more than a few metres in seawater, a fibre-optic tether exists only where a vehicle is physically connected to the ship, and everything else must travel as sound. Phase 3 of WIA-ENE-040 (PHASE-3-PROTOCOL.md) defines the layered stack that carries WIA messages over acoustic links: a physical layer of four frequency bands, a data link with forward error correction and ARQ, a TDMA medium-access scheme, the WIA-UWRP routing protocol, the WIA-UTP and WIA-UFTP transport protocols, the PTPu time protocol, and an emergency and QoS scheme on top.
This chapter walks up that stack one layer at a time. For each layer it states what the specification requires, then checks the numbers against the physics from Chapter 1. In several places the numbers do not agree with each other or with the speed of sound, and the chapter says so explicitly and proposes how an implementer should resolve the gap. All data rates, ranges and timings computed in this chapter are worked examples under stated assumptions, not measured performance of any modem.
Phase 3 §2.1 divides the usable acoustic spectrum into four bands. The first four data columns of the table below are copied from the specification. The last two columns are added by this book: the one-way propagation delay at the upper end of the typical range, assuming a sound speed of about 1,500 m/s, and the absorption coefficient at a representative frequency inside the band, computed with Thorp's empirical formula (a widely used approximation for seawater absorption at low kilohertz frequencies).
| Band | Frequency | Typical range | Data rate | Use case (spec) | One-way delay at max range | Absorption (Thorp) |
|---|---|---|---|---|---|---|
| VLF | 1–3 kHz | 10–20 km | 100–500 bps | Long-range coordination | ≈ 13.3 s at 20 km | ≈ 0.14 dB/km at 2 kHz |
| LF | 3–8 kHz | 5–10 km | 500–2,000 bps | Inter-vehicle communication | ≈ 6.7 s at 10 km | ≈ 0.38 dB/km at 5 kHz |
| MF | 8–16 kHz | 1–5 km | 2–10 kbps | Standard telemetry | ≈ 3.3 s at 5 km | ≈ 1.6 dB/km at 12 kHz |
| HF | 16–30 kHz | 100–1,000 m | 10–50 kbps | High-bandwidth short range | ≈ 0.7 s at 1 km | ≈ 6.1 dB/km at 25 kHz |
Two consequences follow directly from the last two columns and shape everything above the physical layer. First, latency is measured in seconds, not milliseconds, so any timer inherited from terrestrial networking (TCP retransmission timers, Raft heartbeats, CSMA backoff slots) must be rescaled. Second, absorption grows roughly with the square of frequency, so the bands that offer bandwidth are exactly the bands that cannot reach far. The standard does not hide this trade-off; it simply asks the implementer to pick the band per link.
The primary modulation is frequency-shift keying: binary FSK (BFSK) for long-range, low-rate links and M-ary FSK (MFSK) for higher rates. FSK is chosen because a receiver can detect energy in a frequency bin without tracking the carrier phase, which the multipath and Doppler of a moving vehicle make difficult. Phase-shift keying is the secondary scheme: QPSK for medium range, and OFDM for high-bandwidth short-range links, where many narrow subcarriers each see a nearly flat channel.
Transmit power is expressed as source level: at most 190 dB re 1 µPa at 1 m, adjustable in 1 dB steps, with automatic power control driven by link quality. The signal bandwidth is 500 Hz–2 kHz for VLF/LF, 2–8 kHz for MF and 8–14 kHz for HF. A single transmission lasts between 100 ms and 10 s. An implementation should treat the 190 dB figure as a ceiling that the power controller works down from, not as an operating point: every decibel not transmitted saves battery energy and reduces interference with neighbouring nodes and with marine life.
Each transmission is a physical frame of five parts, specified by duration rather than by bits because the bit rate depends on the band and modulation:
┌─────────────┬───────────┬─────────────┬──────────┬───────────┐
│ Preamble │ Sync │ Header │ Payload │ FCS │
│ 50–100 ms │ 10–20 ms │ 20–40 ms │ variable │ 10–20 ms │
└─────────────┴───────────┴─────────────┴──────────┴───────────┘
channel start-of modulation, link-layer CRC-32
estimation frame length, frame
and AGC delimiter addressing (6.2)The fixed parts add up to 90–180 ms before a single payload bit is sent. That overhead is the reason the standard pushes the payload up to 256 bytes rather than sending many small frames, and it becomes important in 6.3, where it has to fit inside a 400 ms TDMA slot.
The specification gives bands and ranges but no link budget. A designer checking whether a given band will close over a given distance can start from the passive sonar equation in its simplest form:
SNR (dB) = SL − TL − NL + DI
TL (dB) = k · 10·log10(r / 1 m) + α(f) · r / 1000
k = 2 spherical, 1 cylindrical, 1.5 "practical" spreading
α(f) (dB/km, f in kHz, Thorp)
= 0.11 f²/(1+f²) + 44 f²/(4100+f²) + 2.75e−4 f² + 0.003Here SL is the source level, TL the transmission loss over range r, NL the ambient noise level in the receiver band and DI the directivity index of the receiving transducer. Noise depends on the site, sea state and shipping, so it must be measured or taken from site survey data; the book does not assume a value. The transmission-loss part is pure geometry and physics, and the table below evaluates it with practical spreading (k = 1.5) at one representative point in each band.
| Case (example) | Spreading loss | Absorption loss | Total TL |
|---|---|---|---|
| VLF, 2 kHz, 15 km | 62.6 dB | 2.0 dB | 64.7 dB |
| LF, 5 kHz, 7.5 km | 58.1 dB | 2.9 dB | 61.0 dB |
| MF, 12 kHz, 3 km | 52.2 dB | 4.9 dB | 57.1 dB |
| MF, 12 kHz, 10 km | 60.0 dB | 16.4 dB | 76.4 dB |
| HF, 25 kHz, 1 km | 45.0 dB | 6.1 dB | 51.1 dB |
| HF, 25 kHz, 5 km | 55.5 dB | 30.5 dB | 86.0 dB |
The pattern is the point. At the low-frequency end, absorption is a rounding error and the loss is almost entirely geometric; at 25 kHz, pushing the range from 1 km to 5 km adds 35 dB, most of it absorption. That is why each band's "typical range" in the specification shrinks as its data rate grows. Real channels add multipath, refraction by the sound-velocity profile and Doppler shift, none of which this first-order budget captures; it is a screening tool, not a prediction.
The scope of Phase 3 includes hybrid acoustic–fibre systems. A tethered ROV has a fibre link with bandwidth several orders of magnitude above any acoustic band and a propagation delay set by the speed of light in glass, which is negligible at tether lengths. The practical rule for an implementation is that the Phase 3 link and network formats remain the common currency: frames that arrive over fibre can be carried inside UDP datagrams without FEC and without TDMA, while the same frames travelling onward to an AUV or lander are transmitted acoustically. A gateway node (typically the ROV or a depressor weight) therefore needs to understand only one frame format, not two.
Phase 3 §3.1 defines a link-layer frame whose fixed header is 80 bits, followed by a 32-bit timestamp, 0–256 bytes of payload and a CRC-32. The specification draws the header on a 32-bit grid, which hides the fact that the fields do not align to bytes. Laid out as a single bit string it looks like this:
bit 0 4 8 24 40
┌──────┬──────┬──────────────────────┬──────────────────────┬──
│ Ver │ Type │ Sequence Number │ Source Address │ …
│ 4 │ 4 │ 16 │ 16 │
└──────┴──────┴──────────────────────┴──────────────────────┴──
bit 40 56 66 68 72 80
┌──────────────────────┬───────────────┬───┬───────┬─────────┐
… │ Destination Address │ PayloadLength │Pri│ Rsv │Hop Count│
│ 16 │ 10 │ 2 │ 4 │ 8 │
└──────────────────────┴───────────────┴───┴───────┴─────────┘
bit 80 ─ 112 : Timestamp (32, Unix seconds)
then : Payload (0–256 bytes) + CRC-32 (32)| Field | Bits | Rule in spec | Implementation note |
|---|---|---|---|
| Version | 4 | Current value 1 | Reject unknown versions rather than guessing. |
| Type | 4 | Codes 0x0–0x7 (table below) | 0x8–0xF are unassigned; treat as reserved. |
| Sequence Number | 16 | Monotonically increasing | Wraps at 65,535; compare with serial-number arithmetic. |
| Source / Destination | 16 + 16 | 0xFFFF = broadcast | Structure defined in 6.4. |
| Payload Length | 10 | 0–256 bytes | Field could encode 1,023; values above 256 are invalid. |
| Priority | 2 | 0 LOW … 3 CRITICAL | Same four levels as the Phase 1 priority field. |
| Reserved | 4 | Future use | Send 0, ignore on receipt. |
| Hop Count | 8 | TTL for multi-hop routing | Decrement per hop; drop at 0. |
| Timestamp | 32 | Unix seconds | See the 2038 note in 6.2.5. |
| CRC-32 | 32 | Cyclic redundancy check | Polynomial and coverage are profile decisions (6.2.5). |
With the timestamp, the header is 14 bytes; with the CRC, a full frame carries 18 bytes of overhead around at most 256 bytes of payload, before any error-correction coding.
| Code | Name | Role | Used in |
|---|---|---|---|
| 0x0 | DATA | Ordinary payload | Every layer above |
| 0x1 | ACK | Positive acknowledgement | ARQ (6.2.4) |
| 0x2 | NACK | Negative acknowledgement | ARQ, selective repeat |
| 0x3 | BEACON | Discovery and synchronisation | TDMA superframe (6.3) |
| 0x4 | ROUTE_REQUEST | Route discovery | WIA-UWRP (6.4) |
| 0x5 | ROUTE_REPLY | Route response | WIA-UWRP (6.4) |
| 0x6 | EMERGENCY | Emergency alert | 6.7 |
| 0x7 | CONTROL | Network control | Slot requests, HELLO, time sync |
The specification does not assign a frame type to HELLO messages or to PTPu sync exchanges. A reasonable profile carries both as CONTROL frames with a one-byte subtype at the start of the payload, which keeps the four-bit type space free for future versions.
Three mechanisms protect a frame before any retransmission is needed. The payload is protected by the Reed–Solomon code RS(255, 223), which appends 32 parity bytes to 223 data bytes and can correct up to 16 erroneous bytes per codeword. The header is protected by a rate-1/2 convolutional code with constraint length K = 7, the same family used widely in radio and satellite links; it doubles the header size but allows soft-decision Viterbi decoding, which matters because a corrupted header makes the whole frame undeliverable. Finally, interleaving with a depth of four frames spreads a burst of errors, such as a fade caused by a surface reflection, across several codewords so that each one sees only a few errors.
Two details are left open and need a profile decision. A 256-byte payload does not fit in one RS(255, 223) codeword, whose data part is 223 bytes, so the payload has to be split into two shortened codewords (for example 128 + 128 data bytes, each with 32 parity bytes, giving 320 coded bytes). And interleaving across four frames means a receiver cannot decode the first frame until it has received the fourth. If a node owns only one TDMA slot per superframe, those four frames span four superframes, roughly 36–40 s, which is longer than the 30 s delay bound of the HIGH QoS class (6.7). An implementation should therefore interleave within a frame, or across consecutive frames sent in one burst, for any traffic above NORMAL priority.
When FEC is not enough, the link layer retransmits. The specification uses Stop-and-Wait ARQ for critical data, Selective Repeat ARQ for bulk data, timeouts that adapt to the measured round-trip time, and at most five retransmissions. On top of that it names Type-II hybrid ARQ with incremental redundancy, where a retransmission carries additional parity rather than a copy, and chase combining, where the receiver adds up the soft values of repeated copies.
The cost of Stop-and-Wait on an acoustic link is worth computing once. Take, as an example, a full 256-byte frame at 5 kbps: with the coding described above it occupies about 2,816 coded bits, or 0.63 s of air time including a 70 ms preamble and sync. At 1 km the round trip adds 1.33 s and the ACK about 0.19 s, so the channel carries useful data only 29% of the time. At 3 km the figure falls to 13%. Stop-and-Wait is simple and therefore appropriate for a few critical commands, but bulk data must use Selective Repeat with a window of many frames, as the UFTP example in 6.5 shows.
zlib.crc32), covering the 14-byte header and the uncoded payload, computed before FEC encoding and checked after FEC decoding.The following Python function builds the link frame exactly as laid out above. It is deliberately free of FEC so that the bit layout can be tested on its own; the FEC encoder wraps the result.
import struct, zlib
FRAME_TYPES = {"DATA": 0x0, "ACK": 0x1, "NACK": 0x2, "BEACON": 0x3,
"ROUTE_REQUEST": 0x4, "ROUTE_REPLY": 0x5,
"EMERGENCY": 0x6, "CONTROL": 0x7}
MAX_PAYLOAD = 256
def pack_frame(ftype, seq, src, dst, payload, priority=1,
hop_count=8, timestamp=0, version=1):
"""80-bit header + 32-bit timestamp + payload + CRC-32, big-endian."""
if len(payload) > MAX_PAYLOAD:
raise ValueError("payload > 256 bytes: fragment first (6.5)")
fields = [(version, 4), (FRAME_TYPES[ftype], 4), (seq, 16),
(src, 16), (dst, 16), (len(payload), 10),
(priority, 2), (0, 4), (hop_count, 8)]
word = 0
for value, width in fields:
if not 0 <= value < (1 << width):
raise ValueError(f"{value} does not fit in {width} bits")
word = (word << width) | value
header = word.to_bytes(10, "big") + struct.pack(">I", timestamp)
body = header + payload
return body + struct.pack(">I", zlib.crc32(body))
def unpack_frame(frame):
body, fcs = frame[:-4], struct.unpack(">I", frame[-4:])[0]
if zlib.crc32(body) != fcs:
raise ValueError("FCS mismatch")
word = int.from_bytes(body[:10], "big")
out = {}
for name, width in reversed([("version", 4), ("type", 4), ("seq", 16),
("src", 16), ("dst", 16), ("length", 10), ("priority", 2),
("reserved", 4), ("hop_count", 8)]):
out[name] = word & ((1 << width) - 1)
word >>= width
out["timestamp"] = struct.unpack(">I", body[10:14])[0]
out["payload"] = body[14:14 + out["length"]]
return out
frame = pack_frame("DATA", seq=4711, src=0x0A03, dst=0x0A01,
payload=b'{"d":3547.2}', priority=2,
timestamp=1736951400) # 2025-01-15T14:30:00Z
assert len(frame) == 14 + 12 + 4
assert unpack_frame(frame)["src"] == 0x0A03A 12-byte payload produces a 30-byte frame. The range check on every field is not decoration: a 10-bit length field silently truncates a 300-byte payload to 44 if the value is masked instead of checked, and the receiver would then report a CRC error that points to the wrong cause.
Many vehicles and sensors share one acoustic channel, so Phase 3 §3.4 organises access as time-division multiple access with dynamic slot allocation. A network coordinator, usually the surface station or a mother vehicle, starts each superframe with a BEACON that announces the slot schedule. Twenty data slots of 400 ms follow, each owned by one node, and a 500 ms contention period closes the superframe, in which nodes without a slot can request one.
t = 0 s 0.5 s 8.5 s 9.0 s 10.0 s
├────────┼──────┬──────┬──────┬─ … ─┬──────┬──────┼────────┼ - - - - -┤
│ BEACON │ S01 │ S02 │ S03 │ │ S19 │ S20 │ CONT. │ ??? │
│ 500 ms │400 ms│400 ms│400 ms│ │400 ms│400 ms│ 500 ms │ 1.0 s │
├────────┼──────┴──────┴──────┴─ … ─┴──────┴──────┼────────┼ - - - - -┤
20 × 400 ms = 8.0 s CSMA unaccountedThe specification calls this a 10-second superframe, but its parts add up to 0.5 + 20 × 0.4 + 0.5 = 9.0 s. Either the total is wrong or one second of the structure is not described. The most useful reading, and the one this book recommends, is that the missing second is a guard interval. Acoustic TDMA needs one: a 400 ms slot corresponds to only 600 m of sound travel, so a node 3 km from the coordinator hears the beacon 2 s late, and its transmission reaches a receiver on the far side of the network with a further delay. Without guard time or propagation-aware scheduling, slots from nodes at different distances overlap at the receiver.
An implementation should therefore (1) carry the superframe length, slot length and guard length explicitly in the BEACON payload, rather than hard-coding "10 s"; (2) give each node a transmit offset derived from its estimated range to the coordinator (for example from the round-trip time of its slot request) so that its frame arrives inside its slot; and (3) use the remaining 1.0 s as a trailing guard in deployments whose diameter exceeds a few hundred metres. The errata list at the end of this chapter records the inconsistency.
The second issue is capacity. After the 90–180 ms of fixed physical overhead from 6.1.3, a 400 ms slot leaves 220–310 ms for coded bits. The table converts that to bytes at three example channel rates, before FEC.
| Channel rate (example) | Coded bytes per slot, long preamble (180 ms) | Coded bytes per slot, short preamble (90 ms) | Full 256-byte frame (≈ 352 coded bytes) fits? |
|---|---|---|---|
| 2 kbps | 55 | 77 | No |
| 5 kbps | 137 | 193 | No |
| 10 kbps | 275 | 387 | Only with a short preamble |
At typical MF rates a single slot cannot carry a full-size frame. The standard's own maximum packet duration of 10 s makes the same point from the other side: long packets only make sense if a node can own several consecutive slots. A conforming coordinator should therefore allocate slots in contiguous runs and let a node's frame span its run, and a node should size its frames to its allocation. The specification's "priority-based slot assignment" can then be read as the order in which runs are handed out.
Slots are reallocated every ten superframes, which is 90–100 s depending on how 6.3.2 is resolved. Between reallocations, a node that needs capacity sends a request in the contention period using CSMA with binary exponential backoff: after the n-th collision it waits a random number of backoff units between 0 and 2n − 1. The specification does not define the backoff unit. On land a backoff slot is microseconds; underwater it should be at least the maximum one-way propagation delay across the network, otherwise two nodes that both sensed the channel as idle will still collide because neither has yet heard the other. For the same reason carrier sensing underwater is weak evidence: "idle" only means that no sound has arrived yet. A 500 ms contention window is short relative to kilometre-scale propagation, so requests should be small, and the coordinator should acknowledge them in the next BEACON instead of immediately.
A node address is 16 bits: an 8-bit Network ID identifying the mission or deployment, followed by an 8-bit Node ID unique within that network. Three ranges are reserved: 0x0000 as invalid or unassigned, 0xFFFF as broadcast, and 0xFF00–0xFFFE as multicast groups.
The multicast range is exactly the address space of Network ID 255. A deployment that assigns Network ID 255 to a mission would find every one of its unicast addresses interpreted as a multicast group. The fix is simple and costs one network out of 256: treat Network ID 255 as reserved for multicast and broadcast, and assign mission networks from 1–254. Within a network the specification does not reserve node IDs, but using 0x00 as "the network itself" and 0xFF as "all nodes in this network" gives a per-network broadcast that the base scheme lacks. The table summarises the recommended plan.
| Address range | Meaning in spec | Recommended profile |
|---|---|---|
| 0x0000 | Invalid / unassigned | Unchanged |
| 0x0100–0xFEFF | Network ID + Node ID | Networks 1–254; node IDs 0x01–0xFE |
| 0xNN00 / 0xNNFF | Ordinary node addresses | Network address / network-wide broadcast |
| 0xFF00–0xFFFE | Multicast groups | Unchanged; Network ID 255 never assigned |
| 0xFFFF | Broadcast | Unchanged |
WIA-UWRP is a hybrid of proactive and reactive routing. Routes to frequently contacted nodes, such as the surface gateway, are maintained continuously; routes to other nodes are discovered on demand. Discovery follows the familiar pattern: the source broadcasts a ROUTE_REQUEST, intermediate nodes rebroadcast it with the hop count incremented, the destination answers with a ROUTE_REPLY, and the source chooses among the replies using hop count, link quality, estimated delay and node energy. Maintenance relies on periodic HELLO messages to neighbours, on monitoring SNR and packet loss, and on a route timeout of 300 s (configurable), with backup routes kept for critical paths.
The rebroadcast step needs duplicate suppression, which the specification does not mention: each node should remember the (source, request sequence) pairs it has already forwarded and drop repeats. In a 20-node network where every node rebroadcasts once, a single discovery already costs 20 transmissions, each occupying a slot or a contention window.
The specification scores a candidate route as follows:
Route_Cost = α·HopCount + β·Delay + γ·PacketLoss + δ·(1/Energy)
α = 1.0, β = 0.5 (Delay in s), γ = 10.0, δ = 0.1It describes γ as a weight on packet loss "in percent" and δ as applying to the inverse of remaining battery "percent". Taken literally, those units make one term dominate and another disappear. Consider two example routes to the same destination: a direct link with 4.0 s delay, 25% loss and 90% remaining energy, and a two-hop route through an AUV relay with 4.5 s total delay, 5% loss per hop (9.75% end to end) and a relay at 30% energy.
| Interpretation | Direct route | Two-hop relay | What drives the choice |
|---|---|---|---|
| Loss and energy as percent (literal) | 1 + 2.0 + 250 + 0.001 = 253.0 | 2 + 2.25 + 97.5 + 0.003 = 101.8 | Loss only; energy has no effect |
| Loss and energy as fractions 0–1 (recommended) | 1 + 2.0 + 2.5 + 0.11 = 5.61 | 2 + 2.25 + 0.98 + 0.33 = 5.56 | All four terms contribute |
Under the fractional interpretation the terms are of comparable size, and a nearly drained relay visibly penalises its route, which is what an energy term is for. This book therefore recommends fractions, and it also fixes how per-hop values combine along a path, which the specification leaves open: delays add, delivery probabilities multiply, and energy is taken from the weakest node on the path.
from dataclasses import dataclass
ALPHA, BETA, GAMMA, DELTA = 1.0, 0.5, 10.0, 0.1 # Phase 3 section 4.2
@dataclass
class Hop:
delay_s: float # one-way delay incl. air time, seconds
loss: float # frame loss on this hop, fraction 0..1
energy: float # remaining energy of the receiving node, 0..1
def route_cost(hops):
delay = sum(h.delay_s for h in hops)
deliver = 1.0
for h in hops:
deliver *= (1.0 - h.loss)
energy = max(min(h.energy for h in hops), 0.01) # avoid 1/0
return (ALPHA * len(hops) + BETA * delay
+ GAMMA * (1.0 - deliver) + DELTA / energy)
direct = [Hop(4.0, 0.25, 0.90)]
relay = [Hop(2.2, 0.05, 0.30), Hop(2.3, 0.05, 0.90)]
print(f"direct {route_cost(direct):.2f} relay {route_cost(relay):.2f}")
# direct 5.61 relay 5.56Whatever convention a deployment adopts, every node must use the same one; otherwise two nodes rank the same route differently and routing loops become possible, which Phase 3 §10 explicitly requires implementations to prevent.
Nodes that know their position may use GPSR (Greedy Perimeter Stateless Routing): forward to the neighbour closest to the destination, and switch to perimeter (face) routing when no neighbour is closer. Positions are broadcast every 60 s and cached for 300 s. The specification adds "depth-aware routing to avoid thermoclines", which reflects a real effect: a strong sound-speed gradient bends rays and can create shadow zones between nodes at different depths. In practice this means that geographic distance alone is a poor predictor of link quality, so geographic routing should fall back to measured link statistics when they are available.
WIA-UTP is a reliable, connection-oriented transport with a TCP-style three-way handshake: SYN, SYN-ACK, ACK. The handshake costs one and a half round trips. At 3 km the one-way delay is 2 s, so the handshake alone takes about 6 s of propagation, before counting frame air time and the wait for each node's next TDMA slot. The Phase 3 conformance test requires connection establishment in under 15 s; that is achievable at MF ranges, but at VLF distances of 15–20 km the propagation alone is 30–40 s and the test can only be met at short range. This is one of several tests that Chapter 8 flags as range-dependent.
The timeout follows the TCP estimator: a smoothed RTT with gain α = 0.125, a mean deviation with gain β = 0.25, and timeout = SRTT + 4·RTTVAR, clamped between 5 and 60 s. The specification's pseudo-code updates the smoothed RTT first and then computes the deviation against the new smoothed value. IETF RFC 6298, which defines the same estimator for TCP, computes the deviation against the old value first. The difference is small, but two implementations that differ in this order will not produce identical timers, which matters for conformance testing with fixed fixtures. This book follows RFC 6298 and initialises with SRTT = R and RTTVAR = R/2 on the first sample, as that RFC does.
| Sample (example) | Measured RTT | SRTT | RTTVAR | Timeout (clamped 5–60 s) |
|---|---|---|---|---|
| 1 | 8.0 s | 8.00 s | 4.00 s | 24.0 s |
| 2 | 9.0 s | 8.13 s | 3.25 s | 21.1 s |
| 3 | 7.5 s | 8.05 s | 2.59 s | 18.4 s |
| 4 | 12.0 s | 8.54 s | 2.93 s | 20.3 s |
RTT samples on an acoustic TDMA network include the wait for the next slot, so they are noisy and heavy-tailed. The 60 s ceiling is what keeps the timer from growing without bound after a burst of losses; the 5 s floor prevents spurious retransmissions on short links where the slot wait, not propagation, dominates.
Messages longer than 256 bytes are split into fragments. Each fragment carries a 16-bit fragment ID naming the original message, an 8-bit fragment number, an 8-bit total count and a 16-bit byte offset: 6 bytes in all. The specification's illustration divides a 1,024-byte message into four 256-byte fragments, which leaves no room for that header. If the fragment header travels inside the 256-byte link payload, each fragment carries 250 bytes of data, the 1,024-byte message needs five fragments, and the largest message that the 8-bit fields can describe is 255 × 250 = 63,750 bytes.
The receiver buffers fragments, accepts them out of order, requests missing ones with a selective ACK and abandons the message after a reassembly timeout of 120 s. That timeout interacts badly with TDMA. The conformance suite tests fragmentation for messages of up to 10 KB, which is 41 fragments. A node that owns one slot per 9–10 s superframe can send at most one fragment per superframe, so the message would take roughly 370–410 s, far beyond 120 s. Either the node must hold at least four or five slots per superframe for the duration of the transfer, or the timeout should be defined as an inactivity timer that restarts on every fragment received. This book recommends the second reading, because it keeps working when a transfer is slowed by retransmissions.
For files, WIA-UFTP adds chunked transfer with per-chunk acknowledgement, resumption after a broken connection, priority-based chunk scheduling and LZ4 compression. The exchange runs FILE_REQUEST with metadata, FILE_ACCEPT with a chunk map, the chunks themselves (with FEC), acknowledgements, retransmission of missing chunks, and finally FILE_COMPLETE.
The specification quotes rough transfer times. Rather than repeat them, the book rebuilds the estimate for one case so that readers can repeat it with their own parameters. The example is a 1 MB (106 bytes) file over a dedicated point-to-point link with a channel rate of 5 kbps before coding, a range of 2 km, no competing TDMA traffic and the frame format of 6.2.
| Step | Assumption (example) | Effect | Cumulative time |
|---|---|---|---|
| 1. Raw bits | 8 × 106 bits at 5,000 bit/s | Lower bound | 1,600 s ≈ 26.7 min |
| 2. Framing and FEC | 250 data bytes per frame (6-byte fragment header); 14-byte header coded to 28 bytes; payload as two shortened RS codewords (320 bytes); CRC 4 bytes; 70 ms preamble and sync; 0.633 s per frame | Efficiency 63% | 4,000 frames: 2,533 s ≈ 42.2 min |
| 3. Acknowledgement turnaround | Selective Repeat, window of 16 frames, then one ACK; half-duplex modem; RTT 2.67 s plus ACK air time 0.19 s | Efficiency 78% | 3,246 s ≈ 54.1 min |
| 4. Losses | 10% of frames retransmitted once | ÷ 0.9 | 3,606 s ≈ 60.1 min |
| 5. Compression | If LZ4 halves the file, for example a text log | ÷ 2 | ≈ 30 min |
Three lessons follow. The coding and framing overhead alone costs more than a third of the nominal rate, and half-duplex turnaround costs another fifth even with a generous window; an end-to-end efficiency of roughly 40–50% of the nominal rate is a realistic planning figure for this kind of link. Compression helps only for compressible content: imagery and already-compressed sonar products gain almost nothing. And the real lever is not the transport protocol but the choice of what to send acoustically at all. In most expeditions the bulk data waits for recovery or a fibre connection, and the acoustic link carries summaries, thumbnails and commands.
At the top of the stack, commands and their responses are JSON documents that mirror the Phase 2 command API from Chapter 5. The IDs and coordinates below are fictional:
{
"messageType": "COMMAND",
"commandId": "CMD-000871",
"timestamp": "2025-01-15T14:30:00.000Z",
"source": "SURFACE-STATION-01",
"destination": "ROV-EXAMPLE-01",
"command": "NAVIGATE_TO_WAYPOINT",
"parameters": { "latitude": 12.3456, "longitude": 145.6789, "depth": 3550.0 },
"priority": "HIGH",
"timeout": 300
}
{
"messageType": "RESPONSE",
"commandId": "CMD-000871",
"timestamp": "2025-01-15T14:30:05.000Z",
"source": "ROV-EXAMPLE-01",
"destination": "SURFACE-STATION-01",
"status": "ACKNOWLEDGED",
"result": { "executionStarted": true,
"estimatedCompletion": "2025-01-15T14:35:00.000Z" }
}The command above is about 330 bytes as printed and still about 285 bytes when minified, so even without whitespace it exceeds one 256-byte payload and travels as two fragments. Over an acoustic link, minify every JSON message, consider a shorter key dictionary or a binary encoding for routine commands, and keep the commandId stable across retries so that the vehicle can recognise and ignore a duplicate command: a retransmitted NAVIGATE_TO_WAYPOINT is harmless, but a retransmitted sampling or release command may not be. The timeout of 300 s is the application-level deadline and should comfortably exceed the transport timeout of 6.5.2.
Because JSON is expensive, Phase 3 §6.2 defines a 13-byte binary telemetry record: NodeID (2 bytes), Timestamp (4), Depth (2), Temperature (2), Pressure (2) and Battery (1). The encodings are checked against the operating envelope below.
| Field | Encoding in spec | Representable range | Required range (Phase 1) | Verdict |
|---|---|---|---|---|
| Depth | uint16, centimetres | 0–655.35 m | 0–11,000 m | Erratum: unusable below 655 m |
| Temperature | int16, 0.01 °C | −327.68 to 327.67 °C | −2 to 400 °C | Adequate for vehicle water temperature; cannot carry vent-fluid readings |
| Pressure | uint16, 0.1 bar | 0–6,553.5 bar | 0–1,100 bar | Adequate |
| Battery | uint8, percent | 0–255 | 0–100 % | Adequate |
| Timestamp | 4 bytes, Unix seconds | to 2038 (signed) or 2106 (unsigned) | — | Declare unsigned |
A deep-sea standard whose compact telemetry cannot express any depth below 655 m has an error, not a limitation, and this book does not present the record as working. Two corrections keep the record small. Option A keeps 16 bits and changes the unit to 0.2 m, covering 0–13,107 m at 20 cm resolution, which is finer than most navigation solutions. Option B widens depth to 24 bits of centimetres, making the record 14 bytes. Either change must bump the Version field so that receivers do not misread old records. The pressure field, which already covers full ocean depth at 0.1 bar (roughly 1 m of water), is a usable stand-in until the erratum is resolved.
For operations that several vehicles must agree on, such as starting synchronised sampling, Phase 3 uses a modified Raft consensus algorithm with 30 s heartbeats, acoustic-aware leader election and a preference for geographically central leaders. The last point matters more than it seems: Raft needs a majority to acknowledge each entry, and a leader in the middle of the formation has the shortest worst-case round trip to that majority. Election timeouts must be several heartbeat intervals long and randomised, so that a lost heartbeat does not immediately trigger a new election, and a vehicle that loses contact with the majority must be designed to continue its current plan safely instead of waiting for consensus.
Every WIA message is timestamped, and Chapter 3 asked for ±1 s agreement with UTC. Underwater there is no GPS, so vehicles synchronise acoustically with PTPu, a simplified adaptation of the exchange defined in IEEE 1588 (Precision Time Protocol). The surface station sends SYNC at its time t1; the vehicle receives it at its own time t2, later sends DELAY_REQ at t3, and the station records its arrival at t4 and returns that value in DELAY_RESP. Then:
offset = [(t2 − t1) − (t4 − t3)] / 2 (vehicle clock minus station clock)
delay = [(t2 − t1) + (t4 − t3)] / 2 (mean one-way delay)Both formulas assume the forward and return paths take the same time. Underwater that assumption is weaker than on a cable: the vehicle moves between the two messages, and the two directions can follow different ray paths. The error in the offset is half the asymmetry. As a worked example, suppose the vehicle clock is truly 0.800 s ahead, the forward delay is 2.000 s and the return delay is 2.030 s. With t1 = 100.000 s, the vehicle reads t2 = 102.800 s; it replies at t3 = 105.800 s (vehicle time) and the station reads t4 = 107.030 s. The formulas give an offset of 0.785 s and a delay of 2.015 s: an error of 15 ms, well within the ±100 ms target.
The larger risk is where the timestamps are taken. A SYNC frame lasts hundreds of milliseconds, so stamping "when sending started" on one side and "when decoding finished" on the other introduces an error of the same order as the whole budget. Both ends must timestamp the same physical point of the frame, for example the end of the sync word. Clock drift, by contrast, is small at the specified 60 s interval: an oscillator with a 20 ppm error (an illustrative figure) drifts 1.2 ms between synchronisations.
An emergency alert is a compact 16-byte record sent at maximum power: a flag byte 0xFF, a 2-byte node ID, 12 bytes of latitude, longitude and depth, and a 1-byte type code.
| Code | Emergency type |
|---|---|
| 0x01 | CRITICAL_SYSTEM_FAILURE |
| 0x02 | LOSS_OF_PROPULSION |
| 0x03 | LEAK_DETECTED |
| 0x04 | POWER_CRITICAL |
| 0x05 | ENTANGLEMENT |
| 0x06 | OPERATOR_EMERGENCY |
The specification does not say how the 12 position bytes are split. A clear profile is three big-endian signed 32-bit integers: latitude and longitude in units of 10−7 degree (about 1 cm) and depth in millimetres, which covers full ocean depth with room to spare. The natural carrier is the EMERGENCY frame type 0x6 at priority 3, with the 16-byte record as its payload; the leading 0xFF flag then lets a receiver recognise an alert even when it has recovered only part of the frame.
Receivers rebroadcast the alert (flooding), the surface station acknowledges it, and the rescue procedure begins. Flooding needs the same duplicate suppression as route discovery, keyed on node ID and emergency type, or a single alert will circulate through the network until every node's queue is full of copies.
Both the CRITICAL QoS class and the conformance tests require delivery of emergency alerts in under 5 s. Sound needs 5 s to travel 7.5 km, and the VLF and LF bands are defined for ranges of 5–20 km, where one-way propagation alone is 3.3–13.3 s. Air time adds more: the alert plus header and CRC is 34 bytes, about 80 bytes after coding, which takes roughly 2.2 s at 300 bps including preamble. Within a 5 s budget, a single-hop alert at 300 bps can therefore travel only about 4 km; at 2 kbps, about 6.9 km. The requirement is meaningful at MF and HF distances and physically impossible at the long ranges the low bands exist for. This book reads it as "under 5 s at ranges up to a few kilometres", and Chapter 8 scopes the corresponding test accordingly.
During an emergency ascent the vehicle transmits a beacon at 10 kHz, in the MF band, as a 1 s pulse every 5 s (a 20% duty cycle) until it reaches the surface or its battery runs out. The specification says the beacon contains the node ID and last known position. A plain tone cannot carry data, so the 1 s pulse must be a modulated burst, for instance the 16-byte emergency record at a robust FSK rate. Recovery crews typically also want an unmodulated component that a simple directional receiver can home in on, so an implementation may alternate the two.
Phase 3 §9 defines four priority classes and reserves a share of bandwidth for each. The last two columns translate those shares into the 20 slots of a superframe and the delay bounds into superframes, which is how a coordinator actually enforces them.
| Priority | Class | Max delay | Use | Bandwidth | Slots of 20 | Delay in superframes (9–10 s) |
|---|---|---|---|---|---|---|
| 3 | CRITICAL | 5 s | Emergency alerts | 20% reserved | 4 | < 1 — needs pre-emption |
| 2 | HIGH | 30 s | Vehicle commands | 40% reserved | 8 | 3 |
| 1 | NORMAL | 2 min | Telemetry | 30% reserved | 6 | 12–13 |
| 0 | LOW | Best effort | Bulk transfer | 10% minimum | 2 | — |
Scheduling within a node is strict priority for CRITICAL and weighted fair queueing for the rest, with LOW guaranteed at least 10% so that it never starves. The table exposes one conflict: a 5 s bound is shorter than a superframe, so waiting for a reserved CRITICAL slot cannot meet it. CRITICAL traffic must therefore be allowed to pre-empt, either by transmitting in any slot (accepting a collision risk) or in the contention period, and receivers must stay in receive mode whenever they are not transmitting. Reservations should also be work-conserving: four CRITICAL slots that sit empty in normal operation should be lent to HIGH traffic, not wasted.
Phase 3 describes a sound architecture. Its choices, FSK for robustness, RS plus convolutional coding, hybrid ARQ, TDMA with a contention window, hybrid routing and a TCP-style transport with long timers, are all appropriate for a channel that is slow, lossy and delayed by seconds. What it lacks is internal arithmetic consistency and a few declarations that interoperability depends on. The list below collects the issues this chapter found, as proposed changes for a v1.x revision; Chapter 8 folds them into the full errata list.
| # | Location | Issue | Proposed resolution |
|---|---|---|---|
| P3-1 | §3.1 | Byte order and CRC-32 variant not stated | Big-endian; IEEE 802.3 polynomial over header and payload |
| P3-2 | §3.1, §6.2 | 32-bit Unix-second timestamps overflow in 2038 if signed | Declare unsigned, or widen |
| P3-3 | §3.3 | 256-byte payload exceeds one RS(255, 223) codeword; frame interleaving delays HIGH traffic | Two shortened codewords; interleave within a burst |
| P3-4 | §3.4 | "10 s" superframe sums to 9 s; slots too short for full frames at MF rates | Explicit 1 s guard, lengths in BEACON, contiguous slot runs |
| P3-5 | §4.1 | Multicast range overlaps Network ID 255 | Never assign Network ID 255 |
| P3-6 | §4.2 | Route-cost units make loss dominate and energy vanish | Fractions 0–1; path aggregation rules |
| P3-7 | §5.1 | RTT update order differs from RFC 6298 | Follow RFC 6298 |
| P3-8 | §5.2, §10 | Fragment header not counted; 120 s reassembly too short for 10 KB under TDMA | 250-byte fragment data; inactivity timer |
| P3-9 | §6.2 | Compact telemetry depth tops out at 655.35 m | 0.2 m unit or 24-bit field, new Version |
| P3-10 | §8, §9, §10 | 5 s emergency delivery impossible at VLF/LF ranges and shorter than a superframe | Scope to short range; CRITICAL pre-emption |
With these decisions written into a deployment profile, two independently built modems and network stacks can exchange WIA frames and agree on what every bit means. The next chapter moves from the water column to the shore and follows the same data into research networks, repositories and cloud archives.