제6장: Phase 3 수중 음향 통신 프로토콜 스택

제3장부터 제5장까지는 메시지를 만들기만 하면 어떻게든 목적지에 도착한다고 가정하였다. 해수면 아래에서는 이 가정이 성립하지 않는다. 전파는 바닷물 속에서 몇 미터도 나아가지 못하고, 광케이블 테더는 잠수정이 모선에 물리적으로 연결된 경우에만 존재하며, 나머지 모든 통신은 소리로 전달되어야 한다. WIA-ENE-040의 Phase 3(PHASE-3-PROTOCOL.md)는 음향 링크 위로 WIA 메시지를 운반하는 계층형 스택을 정의한다. 네 개의 주파수 대역으로 이루어진 물리 계층, 순방향 오류 정정(FEC)과 ARQ를 갖춘 데이터 링크, 시분할 다중접속(TDMA) 매체 접근 방식, 라우팅 프로토콜 WIA-UWRP, 전송 프로토콜 WIA-UTP와 WIA-UFTP, 시각 동기 프로토콜 PTPu, 그리고 그 위의 비상 통신과 QoS 체계가 그것이다.

이 장은 스택을 한 계층씩 올라가며 살펴본다. 계층마다 명세가 무엇을 요구하는지 정리한 뒤, 그 수치를 제1장에서 다룬 물리 법칙과 대조한다. 여러 곳에서 수치들이 서로 맞지 않거나 음속과 모순되는데, 이 장은 그 사실을 분명히 밝히고 구현자가 그 간극을 어떻게 메워야 하는지 제안한다. 이 장에서 계산한 전송률·거리·시간은 모두 명시한 가정 아래의 계산 예시이며, 특정 모뎀의 실측 성능이 아니다.

6.1 물리 계층: 대역·변조·프레임·링크 버짓

6.1.1 네 개의 주파수 대역

Phase 3 §2.1은 사용 가능한 음향 스펙트럼을 네 대역으로 나눈다. 아래 표의 앞쪽 다섯 열은 명세의 내용이고, 마지막 두 열은 이 책이 덧붙인 것이다. 하나는 전형적 도달 거리의 상한에서 음속을 약 1,500 m/s로 두었을 때의 단방향 전파 지연이고, 다른 하나는 대역 안의 대표 주파수에서 Thorp 경험식(수 kHz 대역의 해수 흡수 계수를 근사할 때 널리 쓰이는 식)으로 계산한 흡수 계수이다.

대역주파수전형적 거리전송률용도(명세)최대 거리 단방향 지연흡수 계수(Thorp)
VLF1–3 kHz10–20 km100–500 bps원거리 협조 통신20 km에서 약 13.3초2 kHz에서 약 0.14 dB/km
LF3–8 kHz5–10 km500–2,000 bps잠수정 간 통신10 km에서 약 6.7초5 kHz에서 약 0.38 dB/km
MF8–16 kHz1–5 km2–10 kbps표준 텔레메트리5 km에서 약 3.3초12 kHz에서 약 1.6 dB/km
HF16–30 kHz100–1,000 m10–50 kbps근거리 고대역폭1 km에서 약 0.7초25 kHz에서 약 6.1 dB/km

마지막 두 열에서 곧바로 두 가지 결론이 나오며, 이는 물리 계층 위의 모든 설계를 좌우한다. 첫째, 지연은 밀리초가 아니라 초 단위이다. 따라서 육상 네트워크에서 가져온 타이머(TCP 재전송 타이머, Raft 하트비트, CSMA 백오프 슬롯)는 모두 척도를 다시 잡아야 한다. 둘째, 흡수는 대략 주파수의 제곱에 비례하여 커지므로, 대역폭을 주는 대역은 바로 멀리 가지 못하는 대역이다. 표준은 이 상충 관계를 숨기지 않으며, 링크마다 대역을 고르는 일을 구현자에게 맡긴다.

6.1.2 변조 방식과 송신 파라미터

1차 변조 방식은 주파수 편이 변조(FSK)이다. 원거리 저속 링크에는 이진 FSK(BFSK)를, 더 높은 전송률에는 M진 FSK(MFSK)를 쓴다. FSK를 택한 이유는 수신기가 반송파 위상을 추적하지 않고도 주파수 빈의 에너지만으로 심볼을 검출할 수 있기 때문이다. 움직이는 잠수정에서는 다중 경로와 도플러 효과 때문에 위상 추적이 어렵다. 2차 방식은 위상 편이 변조(PSK)로, 중거리에는 QPSK를, 근거리 고대역폭 링크에는 OFDM을 쓴다. OFDM에서는 좁은 부반송파 하나하나가 거의 평탄한 채널을 보게 된다.

송신 출력은 음원 준위로 표현한다. 최대 190 dB re 1 µPa @ 1 m이며, 1 dB 단위로 조정할 수 있고 링크 품질에 따른 자동 출력 제어를 갖춘다. 신호 대역폭은 VLF/LF가 500 Hz–2 kHz, MF가 2–8 kHz, HF가 8–14 kHz이다. 한 번의 송신은 100 ms에서 10초 사이이다. 구현에서는 190 dB를 운용점이 아니라 출력 제어기가 내려가며 조정하는 상한으로 다루어야 한다. 덜 낸 1 dB마다 배터리가 절약되고, 이웃 노드와 해양 생물에 대한 간섭도 줄어든다.

6.1.3 물리 프레임

각 송신은 다섯 부분으로 된 물리 프레임이다. 비트율이 대역과 변조 방식에 따라 달라지므로 명세는 각 부분을 비트 수가 아니라 시간으로 규정한다.

┌─────────────┬───────────┬─────────────┬──────────┬───────────┐
│  프리앰블   │   동기    │    헤더     │ 페이로드 │    FCS    │
│  50–100 ms  │ 10–20 ms  │  20–40 ms   │  가변    │ 10–20 ms  │
└─────────────┴───────────┴─────────────┴──────────┴───────────┘
  채널 추정·    프레임      변조 방식·    링크 계층   CRC-32
  자동 이득     시작        길이·주소     프레임
  제어          구분자                    (6.2)

고정 부분만 합해도 페이로드 비트를 하나도 보내기 전에 90–180 ms가 소요된다. 표준이 작은 프레임을 여러 개 보내지 않고 페이로드를 256바이트까지 키우는 이유가 이 오버헤드이며, 이 오버헤드를 400 ms TDMA 슬롯 안에 넣어야 하는 6.3절에서 이 점이 중요해진다.

6.1.4 1차 근사 링크 버짓

명세는 대역과 거리만 제시할 뿐 링크 버짓은 제시하지 않는다. 특정 대역으로 특정 거리의 링크가 성립하는지 확인하려는 설계자는 가장 단순한 형태의 수동 소나 방정식에서 출발할 수 있다.

SNR (dB)  =  SL − TL − NL + DI
TL (dB)   =  k · 10·log10(r / 1 m)  +  α(f) · r / 1000
             k = 2 구면 확산, 1 원통 확산, 1.5 "실용" 확산
α(f) (dB/km, f는 kHz, Thorp)
          =  0.11 f²/(1+f²) + 44 f²/(4100+f²) + 2.75e−4 f² + 0.003

여기서 SL은 음원 준위, TL은 거리 r에 대한 전달 손실, NL은 수신 대역의 주변 소음 준위, DI는 수신 트랜스듀서의 지향 지수이다. 소음은 해역·해상 상태·선박 통항에 따라 달라지므로 실측하거나 해역 조사 자료에서 가져와야 하며, 이 책은 소음 값을 가정하지 않는다. 전달 손실 부분은 순수한 기하와 물리이므로, 아래 표는 실용 확산(k = 1.5)을 적용하여 각 대역의 대표 지점에서 이를 계산한 것이다.

경우(예시)확산 손실흡수 손실총 전달 손실
VLF, 2 kHz, 15 km62.6 dB2.0 dB64.7 dB
LF, 5 kHz, 7.5 km58.1 dB2.9 dB61.0 dB
MF, 12 kHz, 3 km52.2 dB4.9 dB57.1 dB
MF, 12 kHz, 10 km60.0 dB16.4 dB76.4 dB
HF, 25 kHz, 1 km45.0 dB6.1 dB51.1 dB
HF, 25 kHz, 5 km55.5 dB30.5 dB86.0 dB

핵심은 수치의 경향이다. 저주파 쪽에서는 흡수가 무시할 만하고 손실 거의 전부가 기하학적 확산이다. 반면 25 kHz에서는 거리를 1 km에서 5 km로 늘리면 손실이 35 dB 늘어나며, 그 대부분이 흡수이다. 명세에서 전송률이 높은 대역일수록 "전형적 거리"가 짧아지는 이유가 여기에 있다. 실제 채널에는 다중 경로, 음속 프로파일에 의한 굴절, 도플러 편이가 더해지는데, 이 1차 근사는 그중 어느 것도 반영하지 않는다. 따라서 이는 예측 도구가 아니라 선별 도구이다.

6.1.5 광케이블의 위치

Phase 3의 범위에는 음향–광케이블 혼합 시스템도 포함된다. 테더로 연결된 ROV의 광 링크는 어떤 음향 대역보다도 몇 자릿수 넓은 대역폭을 가지며, 전파 지연은 유리 속 빛의 속도로 정해지므로 테더 길이에서는 무시할 수 있다. 구현상의 실용 원칙은 Phase 3의 링크·네트워크 형식을 공통 화폐로 유지하는 것이다. 광케이블로 도착한 프레임은 FEC와 TDMA 없이 UDP 데이터그램에 실어 운반하고, 같은 프레임을 AUV나 랜더로 넘길 때는 음향으로 송신한다. 그러면 게이트웨이 노드(대개 ROV 또는 디프레서 웨이트)는 두 가지가 아니라 한 가지 프레임 형식만 이해하면 된다.

6.2 데이터 링크 계층: 헤더·프레임 유형·FEC·ARQ

6.2.1 헤더 비트 배치

Phase 3 §3.1은 80비트 고정 헤더, 32비트 타임스탬프, 0–256바이트 페이로드, CRC-32로 구성된 링크 계층 프레임을 정의한다. 명세는 헤더를 32비트 격자에 그려 놓았기 때문에 필드들이 바이트 경계에 맞지 않는다는 사실이 잘 드러나지 않는다. 하나의 비트열로 펼치면 다음과 같다.

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 초)
그 뒤       : Payload (0–256 바이트)  +  CRC-32 (32)
필드비트명세의 규칙구현 참고
Version4현재 값 1모르는 버전은 추측하지 말고 거부한다.
Type4코드 0x0–0x7(아래 표)0x8–0xF는 미할당이므로 예약으로 취급한다.
Sequence Number16단조 증가65,535에서 순환하므로 일련번호 산술로 비교한다.
Source / Destination16 + 160xFFFF = 브로드캐스트구조는 6.4절에서 정의한다.
Payload Length100–256바이트필드는 1,023까지 표현하지만 256을 넘는 값은 무효이다.
Priority20 LOW … 3 CRITICALPhase 1 priority 필드와 같은 네 단계이다.
Reserved4향후 사용0으로 보내고 수신 시 무시한다.
Hop Count8다중 홉 라우팅용 TTL홉마다 감소시키고 0이면 폐기한다.
Timestamp32Unix 초6.2.5절의 2038년 문제를 참고한다.
CRC-3232순환 중복 검사다항식과 적용 범위는 프로파일에서 정한다(6.2.5).

타임스탬프까지 합치면 헤더는 14바이트이고, CRC까지 포함하면 한 프레임은 오류 정정 부호화 전에 최대 256바이트의 페이로드 주위로 18바이트의 오버헤드를 갖는다.

6.2.2 프레임 유형

코드이름역할사용처
0x0DATA일반 페이로드상위 모든 계층
0x1ACK긍정 확인 응답ARQ(6.2.4)
0x2NACK부정 확인 응답ARQ, 선택적 재전송
0x3BEACON탐색 및 동기TDMA 슈퍼프레임(6.3)
0x4ROUTE_REQUEST경로 탐색WIA-UWRP(6.4)
0x5ROUTE_REPLY경로 응답WIA-UWRP(6.4)
0x6EMERGENCY비상 경보6.7절
0x7CONTROL네트워크 제어슬롯 요청, HELLO, 시각 동기

명세는 HELLO 메시지와 PTPu 동기 교환에 프레임 유형을 배정하지 않았다. 두 가지 모두 CONTROL 프레임으로 보내고 페이로드 첫 바이트에 하위 유형을 두는 프로파일이 합리적이다. 그러면 4비트 유형 공간을 향후 버전을 위해 남겨 둘 수 있다.

6.2.3 순방향 오류 정정과 인터리빙

재전송이 필요해지기 전에 세 가지 장치가 프레임을 보호한다. 페이로드는 리드–솔로몬 부호 RS(255, 223)로 보호된다. 이 부호는 223바이트 데이터에 패리티 32바이트를 덧붙이며, 부호어당 최대 16바이트의 오류를 정정한다. 헤더는 부호율 1/2, 구속장 K = 7의 컨볼루션 부호로 보호된다. 무선·위성 링크에서 널리 쓰이는 계열로, 헤더 크기가 두 배가 되지만 연판정 비터비 복호가 가능해진다. 헤더가 손상되면 프레임 전체를 전달할 수 없으므로 이 보호가 중요하다. 마지막으로 깊이 4프레임의 인터리빙은 해수면 반사로 인한 페이딩 같은 연집 오류를 여러 부호어로 흩어, 각 부호어가 소수의 오류만 겪도록 한다.

두 가지 세부 사항이 열려 있어 프로파일에서 결정해야 한다. 첫째, 256바이트 페이로드는 데이터 부분이 223바이트인 RS(255, 223) 부호어 하나에 들어가지 않는다. 따라서 페이로드를 단축 부호어 두 개로 나누어야 한다(예: 데이터 128 + 128바이트에 각각 패리티 32바이트, 부호화 후 320바이트). 둘째, 네 개의 프레임에 걸친 인터리빙은 수신기가 네 번째 프레임을 받기 전까지 첫 프레임을 복호하지 못한다는 뜻이다. 한 노드가 슈퍼프레임마다 TDMA 슬롯을 하나만 가진다면 이 네 프레임은 슈퍼프레임 네 개, 즉 약 36–40초에 걸치며, 이는 HIGH QoS 등급의 지연 한도 30초(6.7절)보다 길다. 따라서 NORMAL보다 높은 우선순위의 트래픽은 프레임 내부에서, 또는 한 번의 연속 송신에 포함된 프레임끼리만 인터리빙해야 한다.

6.2.4 ARQ와 하이브리드 ARQ

FEC로 부족하면 링크 계층이 재전송한다. 명세는 중요 데이터에 정지-대기(Stop-and-Wait) ARQ를, 대용량 데이터에 선택적 재전송(Selective Repeat) ARQ를 쓰고, 측정한 왕복 시간에 따라 타임아웃을 조정하며, 재전송은 최대 5회로 제한한다. 그 위에 재전송 때 사본 대신 추가 패리티를 보내는 증분 중복 방식의 Type-II 하이브리드 ARQ와, 수신기가 반복 수신한 사본들의 연판정 값을 합산하는 체이스 결합을 명시한다.

음향 링크에서 정지-대기 방식의 비용은 한 번 계산해 볼 가치가 있다. 예를 들어 5 kbps에서 256바이트 페이로드를 가득 채운 프레임을 보낸다고 하자. 위의 부호화를 적용하면 약 2,816개의 부호화 비트가 되고, 70 ms의 프리앰블·동기를 포함하면 송신 시간은 0.63초이다. 거리 1 km에서는 왕복에 1.33초, ACK에 약 0.19초가 더해지므로 채널이 유효 데이터를 나르는 시간은 전체의 29%에 불과하다. 3 km에서는 13%로 떨어진다. 정지-대기 방식은 단순하므로 소수의 중요 명령에는 적합하지만, 대용량 데이터는 6.5절의 UFTP 예시처럼 창 크기가 큰 선택적 재전송을 써야 한다.

6.2.5 명세가 구현자에게 남긴 결정

6.2.6 참조 코드: 프레임 패킹과 검사

다음 파이썬 함수는 위에서 설명한 배치 그대로 링크 프레임을 만든다. 비트 배치만 따로 시험할 수 있도록 일부러 FEC를 넣지 않았으며, FEC 부호기가 그 결과를 감싼다.

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비트 헤더 + 32비트 타임스탬프 + 페이로드 + CRC-32, 빅엔디언."""
    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"] == 0x0A03

12바이트 페이로드는 30바이트 프레임이 된다. 모든 필드에 대한 범위 검사는 장식이 아니다. 10비트 길이 필드를 검사하지 않고 마스킹만 하면 300바이트 페이로드가 조용히 44로 잘리고, 수신기는 원인과 무관한 CRC 오류를 보고하게 된다.

6.3 매체 접근 제어: TDMA 슈퍼프레임

6.3.1 슈퍼프레임 구조

여러 잠수정과 센서가 하나의 음향 채널을 공유하므로, Phase 3 §3.4는 동적 슬롯 할당을 갖춘 시분할 다중접속(TDMA)으로 접근을 조직한다. 대개 해상 기지국이나 모선 역할의 잠수정인 네트워크 조정자가 슬롯 일정을 알리는 BEACON으로 슈퍼프레임을 시작한다. 이어서 각각 한 노드가 소유하는 400 ms 데이터 슬롯 20개가 오고, 슬롯이 없는 노드가 슬롯을 요청할 수 있는 500 ms 경쟁 구간이 슈퍼프레임을 마감한다.

 t = 0 s   0.5 s                                         8.5 s    9.0 s     10.0 s
 ├────────┼──────┬──────┬──────┬─ … ─┬──────┬──────┼────────┼ - - - - -┤
 │ BEACON │ S01  │ S02  │ S03  │     │ S19  │ S20  │  경쟁  │   ???    │
 │ 500 ms │400 ms│400 ms│400 ms│     │400 ms│400 ms│ 500 ms │  1.0 s   │
 ├────────┼──────┴──────┴──────┴─ … ─┴──────┴──────┼────────┼ - - - - -┤
            20 × 400 ms = 8.0 s                     CSMA      설명 없음

6.3.2 사라진 1초

명세는 이를 10초 슈퍼프레임이라고 부르지만, 구성 요소를 더하면 0.5 + 20 × 0.4 + 0.5 = 9.0초이다. 합계가 틀렸거나, 구조의 1초가 기술되지 않은 것이다. 가장 유용한 해석이자 이 책이 권하는 해석은 사라진 1초를 보호 구간(guard interval)으로 보는 것이다. 음향 TDMA에는 보호 구간이 반드시 필요하다. 400 ms 슬롯은 소리가 600 m를 가는 시간에 불과하므로, 조정자로부터 3 km 떨어진 노드는 비콘을 2초 늦게 듣고, 그 노드의 송신은 네트워크 반대편의 수신기에 다시 지연되어 도착한다. 보호 시간이나 전파 지연을 고려한 스케줄링이 없으면, 거리가 서로 다른 노드들의 슬롯이 수신기에서 겹친다.

따라서 구현은 (1) "10초"를 코드에 고정하지 말고 슈퍼프레임 길이·슬롯 길이·보호 구간 길이를 BEACON 페이로드에 명시적으로 싣고, (2) 슬롯 요청의 왕복 시간 등으로 추정한 조정자까지의 거리로부터 노드별 송신 오프셋을 정해 프레임이 자기 슬롯 안에 도착하게 하며, (3) 배치 직경이 수백 미터를 넘는 경우 남는 1.0초를 후행 보호 구간으로 사용해야 한다. 이 장 끝의 정오표에 이 불일치를 기록하였다.

6.3.3 슬롯 하나에 들어가는 양

두 번째 문제는 용량이다. 6.1.3절의 고정 물리 오버헤드 90–180 ms를 빼면 400 ms 슬롯에는 부호화 비트를 위한 220–310 ms가 남는다. 아래 표는 이를 세 가지 예시 채널 전송률에서 FEC 적용 전 바이트 수로 환산한 것이다.

채널 전송률(예시)슬롯당 부호화 바이트, 긴 프리앰블(180 ms)슬롯당 부호화 바이트, 짧은 프리앰블(90 ms)256바이트 전체 프레임(부호화 약 352바이트) 수용 여부
2 kbps5577불가
5 kbps137193불가
10 kbps275387짧은 프리앰블일 때만 가능

전형적인 MF 전송률에서는 슬롯 하나로 최대 크기 프레임을 나를 수 없다. 명세 자신이 정한 최대 패킷 길이 10초도 반대 방향에서 같은 점을 말해 준다. 긴 패킷은 한 노드가 연속된 슬롯 여러 개를 가질 수 있을 때만 의미가 있다. 따라서 적합한 조정자는 슬롯을 연속 묶음으로 할당하고 노드의 프레임이 그 묶음에 걸치도록 허용해야 하며, 노드는 할당량에 맞추어 프레임 크기를 정해야 한다. 이렇게 보면 명세의 "우선순위 기반 슬롯 배정"은 묶음을 나누어 주는 순서로 해석할 수 있다.

6.3.4 재할당과 경쟁

슬롯은 슈퍼프레임 10개마다 재할당되며, 이는 6.3.2절을 어떻게 해석하느냐에 따라 90–100초이다. 재할당 사이에 용량이 필요한 노드는 경쟁 구간에서 이진 지수 백오프를 적용한 CSMA로 요청을 보낸다. n번째 충돌 뒤에는 0부터 2n − 1 사이의 무작위 개수만큼 백오프 단위를 기다린다. 명세는 백오프 단위를 정의하지 않았다. 육상에서 백오프 슬롯은 마이크로초 단위이지만, 수중에서는 적어도 네트워크를 가로지르는 최대 단방향 전파 지연 이상이어야 한다. 그렇지 않으면 채널이 비었다고 감지한 두 노드가 서로의 신호를 아직 듣지 못했기 때문에 결국 충돌한다. 같은 이유로 수중에서 반송파 감지는 약한 증거에 불과하다. "비어 있음"은 아직 아무 소리도 도착하지 않았다는 뜻일 뿐이다. 500 ms 경쟁 구간은 킬로미터 단위의 전파 지연에 비해 짧으므로, 요청은 작게 만들고 조정자는 즉시 응답하는 대신 다음 BEACON에서 확인해 주어야 한다.

6.4 네트워크 계층: 주소 체계와 WIA-UWRP 라우팅

6.4.1 16비트 주소

노드 주소는 16비트로, 임무 또는 배치를 식별하는 8비트 Network ID 뒤에 그 네트워크 안에서 유일한 8비트 Node ID가 온다. 세 범위가 예약되어 있다. 0x0000은 무효·미할당, 0xFFFF는 브로드캐스트, 0xFF00–0xFFFE는 멀티캐스트 그룹이다.

그런데 멀티캐스트 범위는 정확히 Network ID 255의 주소 공간과 같다. 어떤 임무에 Network ID 255를 배정하면, 그 네트워크의 모든 유니캐스트 주소가 멀티캐스트 그룹으로 해석된다. 해결책은 간단하며 256개 네트워크 중 하나만 희생하면 된다. Network ID 255를 멀티캐스트·브로드캐스트 전용으로 예약하고, 임무 네트워크에는 1–254를 배정하는 것이다. 명세는 네트워크 안의 Node ID를 예약하지 않지만, 0x00을 "네트워크 자체"로, 0xFF를 "이 네트워크의 모든 노드"로 쓰면 기본 체계에 없는 네트워크 단위 브로드캐스트를 얻을 수 있다. 아래 표는 권장 주소 계획을 요약한 것이다.

주소 범위명세상 의미권장 프로파일
0x0000무효·미할당변경 없음
0x0100–0xFEFFNetwork ID + Node ID네트워크 1–254, Node ID 0x01–0xFE
0xNN00 / 0xNNFF일반 노드 주소네트워크 주소 / 네트워크 단위 브로드캐스트
0xFF00–0xFFFE멀티캐스트 그룹변경 없음, Network ID 255는 배정하지 않음
0xFFFF브로드캐스트변경 없음

6.4.2 경로 탐색과 유지

WIA-UWRP는 선응형(proactive)과 반응형(reactive)을 결합한 혼합 라우팅이다. 해상 게이트웨이처럼 자주 통신하는 노드로의 경로는 계속 유지하고, 그 밖의 노드로의 경로는 필요할 때 탐색한다. 탐색 절차는 익숙한 형태이다. 출발 노드가 ROUTE_REQUEST를 브로드캐스트하고, 중간 노드는 홉 수를 늘려 재브로드캐스트하며, 목적 노드가 ROUTE_REPLY로 응답하면, 출발 노드는 홉 수·링크 품질·추정 지연·노드 에너지를 기준으로 응답 중 하나를 고른다. 유지는 이웃에게 보내는 주기적 HELLO 메시지, SNR과 패킷 손실 감시, 300초(설정 가능)의 경로 타임아웃에 의존하며, 중요 경로에는 예비 경로를 유지한다.

재브로드캐스트 단계에는 중복 억제가 필요한데 명세에는 언급이 없다. 각 노드는 이미 전달한 (출발 노드, 요청 순번) 쌍을 기억하고 반복되는 요청을 버려야 한다. 노드 20개인 네트워크에서 모든 노드가 한 번씩만 재브로드캐스트해도 탐색 한 번에 이미 20회의 송신이 들며, 그 하나하나가 슬롯이나 경쟁 구간을 차지한다.

6.4.3 경로 비용 함수와 그 단위

명세는 후보 경로의 점수를 다음과 같이 매긴다.

Route_Cost = α·HopCount + β·Delay + γ·PacketLoss + δ·(1/Energy)
             α = 1.0,  β = 0.5 (Delay는 초),  γ = 10.0,  δ = 0.1

명세는 γ를 "퍼센트" 단위 패킷 손실의 가중치로, δ를 남은 배터리 "퍼센트"의 역수에 대한 가중치로 설명한다. 이 단위를 문자 그대로 적용하면 한 항이 지배하고 다른 항은 사라진다. 같은 목적지로 가는 두 예시 경로를 생각해 보자. 하나는 지연 4.0초, 손실 25%, 남은 에너지 90%인 직접 링크이고, 다른 하나는 AUV 중계를 거치는 2홉 경로로 총 지연 4.5초, 홉당 손실 5%(종단 간 9.75%), 중계 노드 에너지 30%이다.

해석직접 경로2홉 중계 경로선택을 좌우하는 요소
손실·에너지를 퍼센트로(문자 그대로)1 + 2.0 + 250 + 0.001 = 253.02 + 2.25 + 97.5 + 0.003 = 101.8손실뿐이며 에너지는 영향 없음
손실·에너지를 0–1 비율로(권장)1 + 2.0 + 2.5 + 0.11 = 5.612 + 2.25 + 0.98 + 0.33 = 5.56네 항 모두 기여

비율로 해석하면 각 항의 크기가 비슷해지고, 거의 방전된 중계 노드가 자기 경로에 눈에 띄는 불이익을 준다. 에너지 항이 존재하는 이유가 바로 그것이다. 따라서 이 책은 비율 해석을 권하며, 명세가 열어 둔 경로 전체의 홉별 값 결합 방법도 정한다. 지연은 더하고, 전달 확률은 곱하며, 에너지는 경로에서 가장 약한 노드의 값을 쓴다.

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   # 송신 시간을 포함한 단방향 지연(초)
    loss: float      # 이 홉의 프레임 손실 비율 0..1
    energy: float    # 수신 노드의 남은 에너지 비율 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)   # 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.56

배치가 어떤 규약을 택하든 모든 노드가 같은 규약을 써야 한다. 그렇지 않으면 두 노드가 같은 경로의 순위를 다르게 매겨 라우팅 루프가 생길 수 있으며, Phase 3 §10은 구현이 라우팅 루프를 방지할 것을 명시적으로 요구한다.

6.4.4 선택 사항인 지리 기반 라우팅

자기 위치를 아는 노드는 GPSR(Greedy Perimeter Stateless Routing)을 쓸 수 있다. 목적지에 가장 가까운 이웃에게 전달하고, 더 가까운 이웃이 없으면 경계(face) 라우팅으로 전환한다. 위치는 60초마다 브로드캐스트되고 300초 동안 캐시된다. 명세는 "수온약층을 피하는 수심 인지 라우팅"을 덧붙이는데, 이는 실제 현상을 반영한다. 음속 경사가 강하면 음선이 휘어져 수심이 다른 노드들 사이에 음영대가 생길 수 있다. 실무적으로는 지리적 거리만으로 링크 품질을 예측하기 어렵다는 뜻이므로, 측정된 링크 통계가 있으면 지리 기반 라우팅은 그것으로 되돌아가야 한다.

6.5 전송 계층: WIA-UTP·단편화·WIA-UFTP

6.5.1 연결 설정

WIA-UTP는 TCP식 3방향 핸드셰이크(SYN, SYN-ACK, ACK)를 쓰는 신뢰성 있는 연결 지향 전송이다. 핸드셰이크에는 왕복 1.5회가 든다. 3 km에서 단방향 지연은 2초이므로, 프레임 송신 시간과 각 노드의 다음 TDMA 슬롯을 기다리는 시간을 빼고도 핸드셰이크에만 약 6초의 전파 시간이 걸린다. Phase 3 적합성 시험은 연결 수립을 15초 안에 끝낼 것을 요구한다. MF 거리에서는 달성할 수 있지만, 15–20 km의 VLF 거리에서는 전파 시간만 30–40초이므로 근거리에서만 충족할 수 있다. 제8장은 이 항목을 거리에 따라 달라지는 시험 가운데 하나로 표시한다.

6.5.2 적응형 재전송 타임아웃

타임아웃은 TCP 추정기를 따른다. 이득 α = 0.125의 평활 RTT, 이득 β = 0.25의 평균 편차를 구하고, 타임아웃 = SRTT + 4·RTTVAR로 계산하되 5초와 60초 사이로 제한한다. 명세의 의사 코드는 평활 RTT를 먼저 갱신한 뒤 새 평활값을 기준으로 편차를 계산한다. 같은 추정기를 TCP용으로 정의한 IETF RFC 6298은 이전 평활값을 기준으로 편차를 먼저 계산한다. 차이는 작지만, 순서가 다른 두 구현은 동일한 타이머 값을 내지 못하며, 이는 고정 시험 데이터로 적합성을 시험할 때 문제가 된다. 이 책은 RFC 6298을 따르고, 그 RFC와 같이 첫 표본에서 SRTT = R, RTTVAR = R/2로 초기화한다.

표본(예시)측정 RTTSRTTRTTVAR타임아웃(5–60초 제한)
18.0초8.00초4.00초24.0초
29.0초8.13초3.25초21.1초
37.5초8.05초2.59초18.4초
412.0초8.54초2.93초20.3초

음향 TDMA 네트워크의 RTT 표본에는 다음 슬롯까지의 대기 시간이 포함되므로 잡음이 크고 꼬리가 두껍다. 60초 상한은 연속 손실 뒤 타이머가 끝없이 커지는 것을 막고, 5초 하한은 전파보다 슬롯 대기가 지배하는 짧은 링크에서 불필요한 재전송을 막는다.

6.5.3 단편화와 재조립

256바이트를 넘는 메시지는 단편으로 나뉜다. 각 단편은 원래 메시지를 가리키는 16비트 단편 ID, 8비트 단편 번호, 8비트 전체 개수, 16비트 바이트 오프셋, 합계 6바이트의 헤더를 갖는다. 명세의 그림은 1,024바이트 메시지를 256바이트 단편 네 개로 나누는데, 이렇게 하면 이 헤더가 들어갈 자리가 없다. 단편 헤더가 256바이트 링크 페이로드 안에 들어간다면 단편마다 데이터는 250바이트이고, 1,024바이트 메시지는 단편 다섯 개가 필요하며, 8비트 필드로 표현할 수 있는 최대 메시지는 255 × 250 = 63,750바이트이다.

수신기는 단편을 버퍼에 모으고, 순서가 바뀐 도착을 허용하며, 선택적 ACK로 빠진 단편을 요청하고, 120초의 재조립 타임아웃이 지나면 메시지를 포기한다. 이 타임아웃은 TDMA와 잘 맞지 않는다. 적합성 시험은 최대 10 KB 메시지의 단편화를 시험하는데, 이는 단편 41개이다. 9–10초 슈퍼프레임마다 슬롯을 하나만 가진 노드는 슈퍼프레임당 단편 하나밖에 보내지 못하므로 전송에 약 370–410초가 걸리며, 이는 120초를 훨씬 넘는다. 전송하는 동안 노드가 슈퍼프레임당 슬롯을 네다섯 개 이상 확보하거나, 타임아웃을 단편을 받을 때마다 다시 시작하는 무활동 타이머로 정의해야 한다. 재전송으로 전송이 늦어져도 계속 동작하므로 이 책은 두 번째 해석을 권한다.

6.5.4 WIA-UFTP와 처리량 계산 예시

파일 전송을 위해 WIA-UFTP는 청크 단위 전송과 청크별 확인 응답, 연결이 끊긴 뒤의 재개, 우선순위 기반 청크 스케줄링, LZ4 압축을 더한다. 교환 절차는 메타데이터를 담은 FILE_REQUEST, 청크 맵을 담은 FILE_ACCEPT, (FEC를 적용한) 청크 전송, 확인 응답, 빠진 청크의 재전송, 마지막으로 FILE_COMPLETE 순이다.

명세는 대략적인 전송 시간을 제시한다. 이 책은 그 수치를 옮기는 대신 한 가지 경우에 대해 추정을 처음부터 다시 계산하여, 독자가 자기 파라미터로 같은 계산을 반복할 수 있게 한다. 예시는 1 MB(106바이트) 파일을 부호화 전 채널 전송률 5 kbps, 거리 2 km, 경쟁하는 TDMA 트래픽이 없는 전용 점대점 링크로, 6.2절의 프레임 형식을 써서 보내는 경우이다.

단계가정(예시)효과누적 시간
1. 원시 비트8 × 106비트를 초당 5,000비트로하한1,600초 ≈ 26.7분
2. 프레이밍과 FEC프레임당 데이터 250바이트(단편 헤더 6바이트), 14바이트 헤더를 28바이트로 부호화, 페이로드는 단축 RS 부호어 두 개(320바이트), CRC 4바이트, 프리앰블·동기 70 ms, 프레임당 0.633초효율 63%프레임 4,000개: 2,533초 ≈ 42.2분
3. 확인 응답 전환선택적 재전송, 16프레임 창 뒤 ACK 1회, 반이중 모뎀, RTT 2.67초 + ACK 송신 0.19초효율 78%3,246초 ≈ 54.1분
4. 손실프레임의 10%를 한 번씩 재전송÷ 0.93,606초 ≈ 60.1분
5. 압축텍스트 로그처럼 LZ4로 크기가 절반이 되는 경우(예시)÷ 2약 30분

여기서 세 가지 교훈을 얻는다. 부호화와 프레이밍 오버헤드만으로 명목 전송률의 3분의 1 이상이 사라지고, 넉넉한 창을 써도 반이중 전환이 다시 5분의 1가량을 가져간다. 이런 링크에서는 명목 전송률의 40–50% 정도를 종단 간 효율로 잡는 것이 현실적인 계획치이다. 압축은 압축 가능한 내용에만 효과가 있으며, 영상이나 이미 압축된 소나 산출물은 거의 이득이 없다. 그리고 진짜 지렛대는 전송 프로토콜이 아니라 무엇을 음향으로 보낼지의 선택이다. 대부분의 탐사에서 대용량 데이터는 회수나 광케이블 연결을 기다리고, 음향 링크는 요약·썸네일·명령을 나른다.

6.6 응용 계층과 다중 잠수정 협조

6.6.1 COMMAND와 RESPONSE 메시지

스택의 맨 위에서 명령과 응답은 제5장의 Phase 2 명령 API를 반영한 JSON 문서이다. 아래의 ID와 좌표는 가상의 값이다.

{
  "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" }
}

위 명령은 표시된 형태로 약 330바이트이고, 공백을 제거해도 약 285바이트이다. 즉 공백이 없어도 256바이트 페이로드 하나를 넘으므로 단편 두 개로 전송된다. 음향 링크에서는 모든 JSON 메시지에서 공백을 제거하고, 일상적인 명령에는 짧은 키 사전이나 바이너리 인코딩을 고려해야 하며, 재시도할 때도 commandId를 그대로 유지하여 잠수정이 중복 명령을 알아보고 무시할 수 있게 해야 한다. 재전송된 NAVIGATE_TO_WAYPOINT는 무해하지만, 재전송된 채집 명령이나 투하 명령은 그렇지 않을 수 있다. 300초의 timeout은 응용 수준의 마감 시간이며, 6.5.2절의 전송 타임아웃보다 충분히 길어야 한다.

6.6.2 압축 텔레메트리 레코드와 수심 결함

JSON은 비용이 크므로 Phase 3 §6.2는 13바이트 바이너리 텔레메트리 레코드를 정의한다. NodeID(2바이트), Timestamp(4), Depth(2), Temperature(2), Pressure(2), Battery(1)이다. 아래 표는 각 인코딩을 운용 범위와 대조한 것이다.

필드명세의 인코딩표현 가능 범위요구 범위(Phase 1)판정
Depthuint16, 센티미터0–655.35 m0–11,000 m오류: 655 m보다 깊으면 사용 불가
Temperatureint16, 0.01 °C−327.68–327.67 °C−2–400 °C잠수정 주변 수온에는 충분하나 열수 분출 유체 측정값은 담지 못함
Pressureuint16, 0.1 bar0–6,553.5 bar0–1,100 bar충분
Batteryuint8, 퍼센트0–2550–100%충분
Timestamp4바이트, Unix 초2038년(부호 있음) 또는 2106년(부호 없음)까지—부호 없음으로 선언

655 m보다 깊은 수심을 하나도 표현하지 못하는 압축 텔레메트리는 심해 표준에서 한계가 아니라 오류이며, 이 책은 이 레코드를 동작하는 것으로 제시하지 않는다. 레코드를 작게 유지하면서 고치는 방법은 두 가지이다. 방법 A는 16비트를 유지하고 단위를 0.2 m로 바꾸어 0–13,107 m를 20 cm 분해능으로 담는 것으로, 이는 대부분의 항법 해보다 정밀하다. 방법 B는 수심을 24비트 센티미터로 넓혀 레코드를 14바이트로 만드는 것이다. 어느 쪽이든 수신기가 옛 레코드를 잘못 읽지 않도록 Version 필드를 올려야 한다. 이 오류가 해결될 때까지는 0.1 bar(물 약 1 m) 단위로 이미 전 해양 수심을 담는 압력 필드를 대용으로 쓸 수 있다.

6.6.3 분산 합의

동기화된 채집 개시처럼 여러 잠수정이 합의해야 하는 작업에 대해 Phase 3는 수정된 Raft 합의 알고리즘을 쓴다. 하트비트 간격을 30초로 늘리고, 음향 환경을 고려한 리더 선출을 하며, 지리적으로 가운데 있는 리더를 선호한다. 마지막 조건은 보기보다 중요하다. Raft는 각 항목에 대해 과반수의 확인이 필요한데, 대형의 한가운데 있는 리더가 그 과반수까지의 최악 왕복 시간이 가장 짧다. 선출 타임아웃은 하트비트 간격의 몇 배로 길게 잡고 무작위화하여, 하트비트 하나를 잃었다고 곧바로 새 선출이 시작되지 않게 해야 한다. 또 과반수와 연락이 끊긴 잠수정은 합의를 기다리지 않고 현재 계획을 안전하게 계속하도록 설계해야 한다.

6.6.4 PTPu 시각 동기

모든 WIA 메시지에는 타임스탬프가 붙고, 제3장은 UTC와 ±1초 이내의 일치를 요구하였다. 수중에는 GPS가 없으므로 잠수정은 IEEE 1588(Precision Time Protocol)의 교환 방식을 단순화한 PTPu로 음향 동기를 맞춘다. 해상 기지국이 자기 시각 t1에 SYNC를 보내면 잠수정은 자기 시각 t2에 이를 받고, 이후 t3에 DELAY_REQ를 보내며, 기지국은 그 도착 시각 t4를 기록하여 DELAY_RESP로 돌려준다. 그러면 다음이 성립한다.

offset = [(t2 − t1) − (t4 − t3)] / 2     (잠수정 시계 − 기지국 시계)
delay  = [(t2 − t1) + (t4 − t3)] / 2     (평균 단방향 지연)

두 식 모두 가는 경로와 오는 경로의 소요 시간이 같다고 가정한다. 수중에서 이 가정은 케이블보다 약하다. 두 메시지 사이에 잠수정이 움직이고, 두 방향이 서로 다른 음선 경로를 따를 수 있기 때문이다. 오프셋 오차는 비대칭의 절반이다. 계산 예시로, 잠수정 시계가 실제로 0.800초 앞서 있고, 가는 지연이 2.000초, 오는 지연이 2.030초라고 하자. t1 = 100.000초이면 잠수정은 t2 = 102.800초를 읽는다. 잠수정이 (자기 시각으로) t3 = 105.800초에 응답하면 기지국은 t4 = 107.030초를 읽는다. 식에 넣으면 오프셋 0.785초, 지연 2.015초가 나온다. 오차는 15 ms로 ±100 ms 목표 안에 넉넉히 들어온다.

더 큰 위험은 타임스탬프를 찍는 위치이다. SYNC 프레임은 수백 밀리초 동안 이어지므로, 한쪽은 "송신 시작 시점"을, 다른 쪽은 "복호 완료 시점"을 찍으면 전체 예산과 같은 크기의 오차가 생긴다. 양쪽 모두 프레임의 같은 물리적 지점, 예를 들어 동기어의 끝에서 타임스탬프를 찍어야 한다. 반면 명세의 60초 동기 간격에서 시계 표류는 작다. 오차가 20 ppm인 발진기(예시 수치)는 동기 사이에 1.2 ms 표류한다.

6.7 비상 통신과 서비스 품질

6.7.1 비상 경보

비상 경보는 최대 출력으로 송신하는 16바이트 압축 레코드이다. 플래그 바이트 0xFF, 2바이트 노드 ID, 위도·경도·수심 12바이트, 1바이트 유형 코드로 이루어진다.

코드비상 유형
0x01CRITICAL_SYSTEM_FAILURE
0x02LOSS_OF_PROPULSION
0x03LEAK_DETECTED
0x04POWER_CRITICAL
0x05ENTANGLEMENT
0x06OPERATOR_EMERGENCY

명세는 위치 12바이트를 어떻게 나누는지 말하지 않는다. 명확한 프로파일은 빅엔디언 부호 있는 32비트 정수 세 개로, 위도와 경도는 10−7도(약 1 cm) 단위, 수심은 밀리미터 단위로 두는 것이며, 이것으로 전 해양 수심을 여유 있게 담을 수 있다. 자연스러운 운반 수단은 우선순위 3의 EMERGENCY 프레임(유형 0x6)이고 16바이트 레코드를 그 페이로드로 싣는다. 그러면 맨 앞의 0xFF 플래그 덕분에 수신기는 프레임의 일부만 복구했을 때도 경보임을 알아볼 수 있다.

수신 노드들은 경보를 재브로드캐스트(플러딩)하고, 해상 기지국이 확인 응답을 보내며, 구조 절차가 시작된다. 플러딩에도 경로 탐색과 같은 중복 억제가 필요하다. 노드 ID와 비상 유형을 키로 삼지 않으면 경보 하나가 네트워크를 계속 돌아 모든 노드의 큐를 사본으로 채운다.

6.7.2 경보가 5초 안에 도착할 수 있는가

CRITICAL QoS 등급과 적합성 시험은 모두 비상 경보를 5초 안에 전달할 것을 요구한다. 소리는 5초에 7.5 km를 가며, VLF와 LF 대역은 5–20 km 거리용으로 정의되어 있어 단방향 전파만으로 3.3–13.3초가 걸린다. 송신 시간도 더해진다. 경보에 헤더와 CRC를 더하면 34바이트, 부호화 후 약 80바이트이며, 300 bps에서는 프리앰블을 포함해 약 2.2초가 걸린다. 따라서 5초 예산 안에서 단일 홉 경보는 300 bps에서 약 4 km, 2 kbps에서 약 6.9 km까지만 갈 수 있다. 이 요구 사항은 MF·HF 거리에서는 의미가 있지만, 저주파 대역이 존재하는 이유인 원거리에서는 물리적으로 불가능하다. 이 책은 이를 "수 킬로미터 이내 거리에서 5초 미만"으로 읽으며, 제8장은 해당 시험의 범위를 그에 맞추어 한정한다.

6.7.3 비상 부상 비콘

비상 부상 중에 잠수정은 MF 대역인 10 kHz에서 5초마다 1초 펄스(점유율 20%)로 비콘을 송신하며, 해수면에 도달하거나 배터리가 다할 때까지 계속한다. 명세는 비콘에 노드 ID와 마지막으로 알려진 위치가 담긴다고 한다. 단순한 순음은 데이터를 운반할 수 없으므로 1초 펄스는 변조된 버스트여야 하며, 예를 들어 강건한 FSK 전송률로 16바이트 비상 레코드를 싣는 방식이 있다. 회수 요원은 보통 단순한 지향성 수신기로 추적할 수 있는 무변조 성분도 원하므로, 구현은 두 가지를 번갈아 보낼 수 있다.

6.7.4 QoS 등급과 슬롯 예약

Phase 3 §9는 네 개의 우선순위 등급을 정의하고 등급마다 대역폭 몫을 예약한다. 마지막 두 열은 그 몫을 슈퍼프레임의 슬롯 20개로, 지연 한도를 슈퍼프레임 수로 환산한 것이며, 조정자가 실제로 이를 집행하는 방식이다.

우선순위등급최대 지연용도대역폭슬롯 20개 중슈퍼프레임(9–10초) 단위 지연
3CRITICAL5초비상 경보20% 예약41 미만 — 선점 필요
2HIGH30초잠수정 명령40% 예약83
1NORMAL2분텔레메트리30% 예약612–13
0LOW최선 노력대용량 전송최소 10%2—

노드 내부 스케줄링은 CRITICAL에 엄격 우선순위를, 나머지에 가중 공정 큐잉을 적용하며, LOW가 굶지 않도록 최소 10%를 보장한다. 표는 한 가지 충돌을 드러낸다. 5초 한도는 슈퍼프레임보다 짧으므로 예약된 CRITICAL 슬롯을 기다려서는 지킬 수 없다. 따라서 CRITICAL 트래픽에는 선점을 허용해야 한다. 충돌 위험을 감수하고 아무 슬롯에서나 송신하거나 경쟁 구간에서 송신하는 방식이며, 수신기는 송신하지 않는 동안 항상 수신 상태를 유지해야 한다. 예약은 또한 작업 보존형이어야 한다. 평상시 비어 있는 CRITICAL 슬롯 네 개는 버리지 말고 HIGH 트래픽에 빌려주어야 한다.

6.8 요약: 무엇을 구현하고 무엇을 고칠 것인가

Phase 3는 타당한 아키텍처를 제시한다. 강건성을 위한 FSK, RS와 컨볼루션 부호의 결합, 하이브리드 ARQ, 경쟁 구간을 둔 TDMA, 혼합 라우팅, 긴 타이머를 쓰는 TCP식 전송은 모두 느리고 손실이 많으며 초 단위로 지연되는 채널에 적합한 선택이다. 부족한 것은 내부 산술의 일관성과, 상호운용성이 기대는 몇 가지 선언이다. 아래 목록은 이 장에서 찾은 문제를 v1.x 개정을 위한 변경 제안으로 모은 것이며, 제8장은 이를 전체 정오표에 반영한다.

#위치문제제안하는 해결
P3-1§3.1바이트 순서와 CRC-32 변형이 명시되지 않음빅엔디언, 헤더와 페이로드에 IEEE 802.3 다항식 적용
P3-2§3.1, §6.232비트 Unix 초 타임스탬프가 부호 있는 정수이면 2038년에 넘침부호 없음 선언 또는 필드 확장
P3-3§3.3256바이트 페이로드가 RS(255, 223) 부호어 하나를 초과하고, 프레임 간 인터리빙이 HIGH 트래픽을 지연시킴단축 부호어 두 개, 연속 송신 내부 인터리빙
P3-4§3.4"10초" 슈퍼프레임의 합이 9초이고, MF 전송률에서 슬롯이 최대 프레임보다 짧음1초 보호 구간 명시, BEACON에 길이 기재, 연속 슬롯 묶음
P3-5§4.1멀티캐스트 범위가 Network ID 255와 겹침Network ID 255 배정 금지
P3-6§4.2경로 비용 단위 때문에 손실이 지배하고 에너지가 사라짐0–1 비율, 경로 결합 규칙
P3-7§5.1RTT 갱신 순서가 RFC 6298과 다름RFC 6298을 따름
P3-8§5.2, §10단편 헤더가 계산에서 빠짐, TDMA에서 10 KB에 120초 재조립은 부족단편 데이터 250바이트, 무활동 타이머
P3-9§6.2압축 텔레메트리의 수심 상한이 655.35 m0.2 m 단위 또는 24비트 필드, 새 Version
P3-10§8, §9, §105초 비상 전달이 VLF/LF 거리에서 불가능하고 슈퍼프레임보다 짧음근거리로 한정, CRITICAL 선점

이러한 결정을 배치 프로파일에 적어 두면, 서로 독립적으로 만든 두 모뎀과 네트워크 스택이 WIA 프레임을 주고받으며 모든 비트의 의미에 합의할 수 있다. 다음 장은 수중에서 해안으로 무대를 옮겨, 같은 데이터가 연구망·데이터 저장소·클라우드 아카이브로 흘러가는 과정을 따라간다.

← 제5장 제7장 →