AEGLOSLAB 무인항공과 첨단항공모빌리티

제9부 규격·프로토콜·인터페이스

9.16 항법 신호·데이터 규격: GNSS ICD·OSNMA·RTCM·NMEA·SBAS·지형 데이터

9.16.1 이 장에서 배우는 것 / 선수 지식 / 특히 중요한 독자

앞의 장은 GNSS의 원리와 오차(4.2), 좌표계와 필요항법성능(4.1)을 다루었다. 이 장은 그 항법 정보가 어떤 문서에서 어떤 비트 구조와 수치로 규정되어 위성에서 수신기로, 보정국에서 수신기로, 수신기에서 비행 제어 컴퓨터로, 지형 파일에서 임무 소프트웨어로 전달되는가를 읽는다. 규격마다 공개 범위가 다르므로 원문을 읽은 항목과 읽지 못한 항목을 구분해 밝힌다. 민간 개방 신호만 다루며 GPS M 코드·정밀 서비스 같은 군용 신호는 이 장의 범위 밖이다(4.6.7.3).

배우는 것:

  • ICD의 구조 — GPS L1 C/A LNAV 프레임의 비트 수지(1,500비트·30 s), L5·L1C·Galileo·BeiDou·GLONASS의 프레임 시간 상수.
  • 메시지 구조가 정하는 하한 — 시계·궤도를 모두 받는 시간(LNAV 18~36 s), 책력 12.5분, 방송력의 유효 간격.
  • Galileo OSNMA — 40비트 필드에서 DSM·MACK까지의 길이 식, 인증 지연(60 s·360 s), 시각 동기 조건($T_L=30$ s), 태그 위조 확률, 원문 시험 벡터의 재현.
  • 보정 데이터 형식 — RTCM 3 MSM 메시지의 크기와 필요 선로 속도, NTRIP, SBAS 메시지 형식.
  • 수신기 출력 — NMEA 0183 문장과 UBX 프레임의 길이·정밀도·전송 시간.
  • 지형 데이터 — DEM 격자 간격의 위도 의존, ICAO eTOD의 수치 요구와 공개 DEM의 비교, 위치 오차와 DEM 오차의 합성.

선수 지식: 4.1(좌표계, 높이는 4.1.3.4), 4.2(GNSS 원리·보강), 9.1(규격의 세계). 높이 기준은 2.8.3.2와 9.14.8이 다루었다. 이 장은 그 설명을 반복하지 않고 신호·메시지·데이터 형식 문서의 구조와 수치에 집중한다.

특히 중요한 독자: 항법·비행 제어 소프트웨어 개발자는 9.16.3·9.16.5·9.16.6을, 인증·보안 담당자는 9.16.4와 9.16.12를, 임무·지형 데이터 담당자는 9.16.7을, 규제·정책 담당자는 9.16.3.1·9.16.7.3·9.16.11을 먼저 읽는다.

기준 시점과 정직성. 2026년 11월 기준이다. 원문을 읽은 것: GPS IS-GPS-200 N판(2022-08-01, 248쪽)·IS-GPS-705 J판(2022-08-01, 125쪽)·IS-GPS-800 J판(2022-08-01, 146쪽), Galileo OS SIS ICD 2.2판(2025-11), OSNMA SIS ICD 1.1판(2023-10)·수신기 지침 1.3판(2024-01)·서비스 정의 문서(SDD) 1.0판(2025-07), EGNOS OS SDD 3.0판(2024-11), BeiDou B1I 3.0판(2019-02)·B1C 1.0판·B2a 1.0판(2017-12), GLONASS ICD L1·L2 5.1판(2008), RTKLIB 소스(rtcm3.c·rtcm.c·rtcm3e.c·sbas.c·stream.c, GitHub master, rtcm3.c의 마지막 변경 2018-01-30), BKG의 NTRIP 문서 1.0판, gpsd의 NMEA 해설, u-blox F9 HPG 1.32 인터페이스 설명서(UBX-22008968 R01, 2022-05), MAVLink common.xml, NASA LP DAAC의 SRTM 사용자 안내서 V3(2015-10 개정), Copernicus DEM 제품 핸드북 5.0판(2022-11-29), EUROCONTROL TOD 매뉴얼 3.0판(2021-05-04). IS-GPS 3종은 gps.gov의 파일 경로가 현재 404이고 미국 해안경비대 항법센터(navcen)는 403을 돌려주어, 인터넷 아카이브에 보존된 gps.gov 사본(2025-08-03·2025-09-15 스냅샷)을 읽었다. 이 사본이 현행 최신판인지는 확인하지 못했다 (확인 필요). GLONASS ICD는 뉴브런즈윅대 사이트에 호스팅된 사본이다(공식 사이트가 아님). 읽지 못한 것: NMEA 0183·IEC 61162-1 본문(유료), RTCM 10403.x·10410.1 본문(유료이며 BKG의 무료 공개본은 프로토콜 예시가 비어 있다), RTCA DO-229(유료), ICAO 부속서 10·부속서 15·PANS-AIM 본문(EUROCONTROL 매뉴얼이 인용한 범위만), QZSS의 IS-QZSS 문서(약관 동의 화면 뒤에 있어 내려받지 않았다), BeiDou B2b·PPP-B2b·GLONASS CDMA ICD, SRTM의 임무 정확도 논문(접근 403), KASS·KPS의 인터페이스 규격, 한국 수치지형도·DEM의 격자·정확도 규격. 제조사·기관 주장치는 (공개 주장치), 읽지 못한 부분은 (확인 필요)로 표시했다. 계산은 모두 9.16-calc.py의 출력이며 입력 가정은 그때마다 밝힌다.

9.16.2 개념·직관 — 항법 데이터는 다섯 개의 규격 층을 지난다

인터페이스 통제 문서(ICD)는 공급자와 사용자의 경계를 정한다. 위성을 만드는 쪽과 수신기를 만드는 쪽이 같은 비트 정의를 읽어야 하므로 ICD는 변조·부호와 메시지 필드의 폭·척도(LSB)·범위·단위를 정한다. IS-GPS-200N은 변경 절차도 규정한다. 변경은 인터페이스 통제 실무 그룹(ICWG)의 참여 기관이 제안하고 제안 인터페이스 개정 통지(PIRN)의 검토 기간은 45일이다(§1.2, p. 1). 따라서 ICD는 판이 있는 문서이고, 수신기와 비행 소프트웨어는 어느 판에 맞추었는지 기록해야 한다(9.1).

층대표 규격방향과 속도본문 공개이 장
신호·메시지IS-GPS-200·705·800, Galileo OS SIS ICD, BeiDou ICD, GLONASS ICD위성에서 수신기로 단방향, 수십~수백 bit/s무료 공개(접근 경로는 바뀐다)9.16.3
메시지 인증Galileo OSNMA SIS ICD·수신기 지침·SDD위성과 서버, 20 bit/s무료 공개9.16.4
보정RTCM 10403.x(MSM)·10410.1(NTRIP), SBAS기준국·GEO에서 수신기로, 수 kbit/sRTCM·DO-229 유료, 소스·SDD·공개 해설로 확인9.16.5
수신기 출력NMEA 0183, 제조사 이진 프로토콜(UBX)수신기에서 호스트로, 4,800~115,200 baudNMEA 유료, UBX 설명서 공개9.16.6
지형·장애물SRTM·Copernicus DEM, ICAO eTOD파일(격자·정확도)대부분 공개9.16.7

이 수치들이 설계를 지배하는 이유는 첫 위치 고정 시간, 보정 링크의 대역, 출력 지연, 지형 높이의 정확도가 모두 규격 문서의 수치에서 결정되기 때문이다. 세 축의 요구는 다르다. 군용은 이 장의 범위 밖이다. 민간 UAS의 접점은 대부분 수신기 출력(NMEA·UBX)과 RTK 보정이다. AAM은 여기에 메시지 인증, 무결성 정보(SBAS·ARAIM), eTOD 수준의 지형 데이터 요구가 더해진다(9.16.9).

9.16.3 GNSS 인터페이스 규격(ICD)의 구조

9.16.3.1 문서의 계보와 접근 경로

미국은 신호별로 인터페이스 사양(IS)을 둔다. IS-GPS-200은 L1 C/A·L2의 LNAV(부록 II)와 L2C의 CNAV(부록 III)를, IS-GPS-705는 L5를, IS-GPS-800은 L1C를 정한다. Galileo는 OS SIS ICD 하나가 E1·E5a·E5b의 신호와 I/NAV·F/NAV 메시지를 정하고 OSNMA SIS ICD가 인증 필드를 보충한다. BeiDou는 신호마다 문서가 있다(B1I 3.0판, B1C·B2a 1.0판, 2020-08 게시의 B2b·PPP-B2b·BDSBAS-B1C 등). GLONASS의 FDMA ICD는 5.1판(2008)이다. QZSS는 서비스별 IS-QZSS 문서(PNT-006은 2024-07-11, L1S-009는 2026-02-20, L6-008은 2026-03-18, 신호 인증 서비스 SAS-001은 2024-05-27)가 게시되어 있음을 목록으로만 확인했다.

접근 경로가 판 관리의 일부이다. 이 장의 IS-GPS 3종은 공식 포털 두 곳에서 받지 못해 아카이브 사본으로 읽었다. 아카이브 조회에서 N판 이후의 글자(O~Q)는 찾지 못했으나 부재의 증거는 아니다. 같은 문서로 연결되는 링크가 바뀌거나 막히는 일이 흔하므로, 인증·형상 관리 문서에는 판 기호와 날짜뿐 아니라 내려받은 경로와 해시를 기록하는 편이 안전하다. IS-GPS-200N의 후속 변경 통지(2023년의 RFC 502)가 있다는 사실은 문서 제목으로만 확인했고 내용은 읽지 못했다 (확인 필요).

9.16.3.2 GPS L1 C/A LNAV — 프레임과 비트 수지

LNAV는 50 bit/s로 방송되며 프레임은 1,500비트 = 300비트 부프레임 5개이다(§20.3.1·20.3.2, p. 79). 부프레임은 30비트 단어 10개이고 모든 단어에 (32,26) 해밍 부호의 패리티 6비트가 붙는다(§20.3.5, p. 138). 따라서 단어는 0.6 s, 부프레임은 6 s, 프레임은 30 s이다. 첫 두 단어가 TLM(프리앰블 10001011 8비트, 메시지, 무결성 상태 플래그)과 HOW(6초 단위 TOW 17비트, 경보 플래그, A-S 플래그, 부프레임 번호 3비트)이다(§20.3.3.1·20.3.3.2, p. 90~92). HOW의 TOW는 다음 부프레임이 시작하는 시각을 6 s 단위로 세며 최댓값은 $604{,}800/6-1=100{,}799$이다. TLM의 비트 23은 보증 수준을 표시한다. 0이면 순간 거리 오차가 방송된 URA 지수 상한의 4.42배를 5.2 s 넘게 경보 없이 넘을 확률이 시간당 $10^{-5}$ 미만이고, 1이면 5.73배·$10^{-8}$ 미만이다(§20.3.3.1, p. 91).

GPS L1 C/A LNAV — 프레임 1,500비트 = 30 s 부프레임 1 6 s·300비트 시계 보정 건전성·WN 부프레임 2 6 s·300비트 궤도 1 IODE·toe 부프레임 3 6 s·300비트 궤도 2 IODE 부프레임 4 6 s·300비트 25페이지 전리층·UTC 책력 25~32 부프레임 5 6 s·300비트 25페이지 책력 1~24 건전성 한 부프레임 = 30비트 단어 10개(단어당 0.6 s) TLM HOW 3 4 5 6 7 8 9 10 단어 3~10: 정보 24비트 + 패리티 6비트 TLM: 프리앰블 8비트·메시지·무결성 플래그, HOW: TOW 17비트 Galileo E1-B I/NAV — 부프레임 30 s = 15페이지 × 2 s 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 페이지마다 홀수 부분에 OSNMA 40비트가 실린다 HKROOT 8비트 MACK 32비트(태그·키 조각) 15페이지 합계: HKROOT 120비트 + MACK 480비트 = 600비트 / 30 s HKROOT = NMA 헤더 8 + DSM 헤더 8 + DSM 블록 104
GPS L1 C/A LNAV의 프레임(위)과 Galileo E1-B I/NAV의 부프레임(아래)은 둘 다 30 s이다. LNAV는 부프레임 5개(각 300비트, 6 s)이고 부프레임 4·5는 25페이지를 순환해 책력 전체를 받는 데 25프레임 750 s가 걸린다. I/NAV는 2 s짜리 페이지 15개이고 각 페이지의 홀수 부분에 OSNMA 40비트(HKROOT 8 + MACK 32)가 실려 30 s마다 HKROOT 120비트와 MACK 480비트가 방송된다.
부프레임내용(원문 표·그림의 필드 폭을 합산)정보 비트근거
1주 번호 10, L2 코드 2, URA 4, 건전성 6, IODC 10, L2 P 플래그 1, $T_{GD}$ 8, $t_{oc}$ 16, $a_{f2}$ 8, $a_{f1}$ 16, $a_{f0}$ 22 (예약 87비트)103Table 20-I, Figure 20-1
2IODE, 궤도 조화항 계수, $\Delta n$, $M_0$, $e$, $\sqrt{A}$, $t_{oe}$, 적합 구간 플래그, AODO190Table 20-III
3$C_{ic}$, $\Omega_0$, $C_{is}$, $i_0$, $C_{rc}$, $\omega$, $\dot\Omega$, IODE, IDOT190Table 20-III
4(25페이지)책력 SV 25~32(페이지 2~5·7~10), 항법 메시지 보정표(13), 특수 메시지(17), 전리층·UTC(18), 안티스푸프·구성·건전성(25)페이지당 190§20.3.3.5.1
5(25페이지)책력 SV 1~24(페이지 1~24), 건전성·책력 기준 시각(25)페이지당 190§20.3.3.5.1, Table 20-V

부프레임 3~10번째 단어 여덟 개의 정보 비트는 $8\times24-2=190$이고 부프레임 2·3은 이를 전부 사용한다. 원문이 말하는 부프레임 2·3의 "나머지 375비트"는 합 380비트에서 AODO 5비트를 뺀 값과 같고(§20.3.3.4.1, p. 103), 책력 한 페이지의 "책력 174비트 + 건전성 8비트"는 190에서 데이터 ID·SV ID 8비트를 뺀 값과 일치한다(§20.3.3.5.1.2, p. 114). 시계·궤도 정보는 103 + 190 + 190 = 483비트로, 1,500비트 프레임의 32 %이고 유효 전송률은 16.1 bit/s이다. 나머지는 TLM·HOW, 패리티(단어당 20 %), 예약 비트, 책력·전리층·UTC이다. 부프레임 4·5가 25페이지를 순환하므로 책력 전체는 $25\times30=750$ s(12.5분)에 한 번 방송되고 책력은 최소 6일마다 갱신된다(§20.3.2, p. 79; §20.3.3.5.1.2, p. 115).

9.16.3.3 갱신과 유효 간격

시계·궤도는 CEI(시계·궤도·무결성) 데이터 세트 단위로 갱신된다. 정상 운용에서는 데이터 세트를 2시간 전송하고 적합 구간은 4시간이다. 제어 부문과의 접촉이 끊긴 확장 운용에서는 전송 간격이 4·6·12·24시간, 적합 구간이 6·8·14·26시간으로 늘고 적합 구간 플래그가 1이 된다(Table 20-XII, p. 135; 지속 일수 2~14·15~16·17~20·21~62일). IODC는 10비트이고 IODE는 IODC의 하위 8비트이다. 부프레임 2·3의 IODE와 부프레임 1의 IODC 하위 8비트가 하나라도 다르면 컷오버가 일어난 것이므로 데이터를 다시 모아야 한다(§20.3.3.4.1, p. 103). 새 IODE는 직전 6시간에 방송한 값과 달라야 하고(§20.3.4.4, p. 134), 컷오버는 프레임 경계에서 일어나 부프레임 1·2·3이 함께 바뀐다(§20.3.4.1, p. 134). 새 시퀀스의 첫 데이터 세트는 $t_{oe}$가 정시에서 벗어나므로 $t_{oe}\bmod3600\neq0$이면 지난 4시간 안에 컷오버가 있었음을 알 수 있다(§20.3.4.5, p. 137).

비행 소프트웨어에 주는 함의는 두 가지이다. 서로 다른 IODE의 부프레임을 섞어 위성 위치를 계산하면 안 된다. CNAV와 LNAV의 데이터 세트도 섞지 말고 각각 한 세트로 사용하라고 부록 III이 권고한다(§30.3.1, p. 141). 저장한 방송력을 핫 스타트에 재사용하는 기간의 상한은 적합 구간이 정하는 것으로 읽힌다 (추정, ICD가 핫 스타트를 직접 규정하지는 않는다).

9.16.3.4 현대화 신호와 다른 위성군의 메시지 구조

신호(문서)선로 속도메시지 단위오류 정정시계·궤도 수신 시간
GPS L1 C/A LNAV(IS-GPS-200N)50 bit/s부프레임 300비트·6 s, 프레임 30 s단어 패리티(해밍 (32,26))18~36 s
GPS L5 CNAV(IS-GPS-705J)50 bit/s(부호화 후 100 sym/s)메시지 300비트·6 s(프리앰블 8, PRN 6, 형식 6, TOW 17, 경보 1, 본문 238, CRC 24)1/2 합성곱 부호(구속장 7), NH10형식 10·11과 시계(30계)가 각각 24 s 이내 반복
GPS L1C CNAV-2(IS-GPS-800J)100 sym/s프레임 1,800심볼·18 s(TOI 9, 시계·궤도 600, 가변 274비트)LDPC 1/2, 블록 인터리빙, CRC 2418~36 s(프레임 단위, 가정)
BeiDou B1I D1(B1I 3.0)50 bit/s부프레임 300비트·6 s, 프레임 30 s, 초프레임 12분(24프레임)BCH(15,11), 인터리빙18~36 s
BeiDou B1C B-CNAV1(B1C 1.0)100 sym/s프레임 1,800심볼·18 s(14 + 600 + 264 = 878비트)64진 LDPC, 인터리빙18~36 s(프레임 단위, 가정)
BeiDou B2a B-CNAV2(B2a 1.0)200 sym/s프레임 600심볼·3 s(288비트: PRN 6, 형식 6, SOW 18, 본문 234, CRC 24)64진 LDPC(96,48)계산하지 않음(형식 순환 미열람)
GLONASS FDMA(ICD 5.1)50 bit/s문자열 2 s(데이터 85비트 1.7 s + 시각 표지 0.3 s), 프레임 30 s, 초프레임 2.5분문자열당 해밍 검사 8비트8~32 s(문자열 1~4)
Galileo F/NAV, E5a-I(OS SIS ICD 2.2)50 sym/s페이지 10 s(244비트), 부프레임 50 s, 프레임 600 s1/2 합성곱 부호40~60 s
Galileo I/NAV, E1-B(OS SIS ICD 2.2)250 sym/s페이지 2 s(1 s짜리 두 부분), 부프레임 30 s, 프레임 720 s1/2 합성곱 부호, 30×8 인터리빙계산하지 않음

현대화 신호는 정보 속도를 크게 올리지 않고 오류 정정과 CRC를 추가하는 방향이다. L1C의 정보 속도는 883비트/18 s = 49.1 bit/s, B1C는 878비트/18 s = 48.8 bit/s로 LNAV의 50 bit/s와 같은 수준이며, 24비트 CRC와 LDPC 부호가 더해졌다. B2a는 288비트/3 s = 96 bit/s이다. L1C·B1C는 시계·궤도 600비트가 부프레임 2 하나에 모여 있으나 부프레임 2와 3의 심볼 1,748개를 38×46 블록 인터리버에 넣어 방송하므로(L1C §3.2.3.5) 프레임 전체가 도착해야 복호할 수 있다고 보았다 (복호 단위는 가정).

9.16.3.5 워크스루 1 — 메시지 구조가 정하는 시계·궤도 수신 시간

문제. 위성 신호를 이미 획득하고 비트 동기를 마친 수신기가 시계·궤도를 모두 받아 첫 위치를 계산하기까지 메시지 구조만으로 얼마가 걸리는가. 가정: 수신기는 단위(부프레임·문자열·페이지·프레임)의 시작부터 복호하고, 단위 중간에서 수신을 시작하면 그 단위는 다음 순환에서 받으며, 수신 시작 시각은 주기 안에서 균일하다. 오류는 없다. 필요한 단위는 LNAV·D1의 부프레임 1·2·3, GLONASS의 문자열 1~4, F/NAV의 페이지 1~4, L1C·B1C의 프레임 전체이다. 순환 스케줄에서 마지막 필요 단위가 끝나는 시각을 정확한 분수로 계산했다.

신호하한 [s]평균 [s]상한 [s]
GPS L1 C/A LNAV18.029.436.0
BeiDou B1I D118.029.436.0
GLONASS FDMA8.022.232.0
Galileo F/NAV(E5a-I)40.053.060.0
GPS L1C·BeiDou B1C(프레임 단위)18.027.036.0

LNAV의 하한 18 s는 부프레임 1이 시작되는 순간에 수신을 시작한 경우의 $3\times6$ s이고, 상한 36 s는 부프레임 1을 막 놓친 경우의 $30+6$ s이다. GLONASS가 짧은 이유는 위성 자신의 시계·궤도가 문자열 1~4(8 s)에 모여 있기 때문이고, F/NAV가 긴 이유는 50 s 부프레임의 앞 네 페이지(40 s)를 모두 받아야 하기 때문이다. 이는 메시지 구조의 하한이다. 콜드 스타트의 첫 위치 고정 시간은 여기에 신호 획득과 비트·부프레임 동기 시간이 더해지며, 제품 값은 보조 데이터(저장된 방송력, 네트워크 보조)에 크게 의존해 이 장은 인용하지 않는다. 위성 네 기를 함께 받아야 하므로 위성마다 프레임 위상이 다르면 시간이 더 길어진다. GLONASS ICD는 위성 사이의 문자열·프레임·초프레임 경계가 2 ms 이내로 동기된다고 규정하나(§4.3), GPS·BeiDou의 이 정렬 정도는 확인하지 못했다 (확인 필요).

약신호의 효과. 독립 비트 오류와 오류 정정 없음을 가정하면 원시 비트 오류율이 $10^{-3}$일 때 300비트 부프레임이 패리티를 통과할 확률은 74.1 %이고 $10^{-2}$일 때는 4.9 %이다. 후자에서는 한 부프레임을 얻는 데 평균 20.4개 프레임(약 10분)이 필요하다. 현대화 신호가 합성곱·LDPC 부호를 넣은 이유를 이 계산이 보여 준다.

9.16.4 Galileo OSNMA — 항법 메시지 인증의 비트 구조

9.16.4.1 필드 구조

OSNMA는 E1-B I/NAV 공칭 페이지의 홀수 부분에 있는 40비트 필드(HKROOT 8비트 + MACK 32비트)로 방송된다(SIS ICD §2, p. 6). 부프레임은 15페이지(30 s)이므로 30 s마다 HKROOT 120비트와 MACK 480비트, 합계 600비트가 나가고 이는 20 bit/s이다. 방송하지 않는 위성의 필드는 40비트 0이며 어느 위성이 방송하는지는 미리 알 수 없다. 방송 위성의 수는 문서 작성 시점에 20기였고 나머지 위성의 자료는 교차 인증으로 확인한다(§1.4·§5.2). HKROOT는 NMA 헤더 8비트(상태 NMAS 2, 사슬 ID 2, 사슬·공개키 상태 CPKS 3, 예약 1)와 DSM 헤더 8비트(DSM ID 4, 블록 ID 4), DSM 블록 104비트로 이루어진다(§3.1·§3.2). MACK은 MACK 헤더(Tag0·MACSEQ 12비트·COP 4비트), 태그와 Tag-Info(16비트), TESLA 키로 이루어진다(§4).

9.16.4.2 길이 식과 값

항목식(SIS ICD)값원문 표와 대조
DSM-KROOT 길이$l_{DK}=104\lceil 1+(l_K+l_{DS})/104\rceil$키 96·서명 512: 728(7블록), 키 128·512: 832(8블록), 키 256·P-521 서명 1,056: 1,456(14블록)Table 7의 최소·최대와 일치
DSM-PKR 길이$l_{DP}=104\lceil(1040+l_{NPK})/104\rceil$P-256(264): 1,352(13블록), P-521(536): 1,664(16블록)Table 3과 일치
MACK당 태그 수$n_t=\lfloor(480-l_K)/(l_t+16)\rfloor$(128, 40)에서 6, (96, 20)에서 10, (256, 40)에서 4Annex C의 $n_t$ 4~10 열두 항목 모두 (KS, TS) 조합으로 재현

허용 매개변수는 키 길이 96~256비트(Table 10), 태그 길이 20·24·28·32·40비트(Table 11), 서명 ECDSA P-256·P-521(Table 15), 해시 SHA-256·SHA3-256, MAC HMAC-SHA-256·CMAC-AES이다. 수신기 지침의 시험 벡터는 키 128비트, 태그 40비트, P-256, SHA-256, HMAC-SHA-256, MAC 조회표 34이고(Annex A.2) SDD는 검증해야 할 최소 등가 태그 길이를 40비트로 정한다(§2.1.5.2). 짧은 태그 여러 개를 모아 $l_t\cdot N_t\ge L_{min}$을 만족시킬 수 있다(SIS ICD Eq. 10).

9.16.4.3 인증 지연과 서비스 수치

ADKD 0 태그는 직전 부프레임의 자료(I/NAV 워드 1~5: 궤도·시계·상태)를 인증하고, 태그의 키는 다음 MACK 메시지에 실린다(§4.2.1.3, §5.8.2, p. 23·31). 자료 부프레임이 끝난 뒤 태그 부프레임 30 s와 키 부프레임 30 s가 지나야 하므로 인증은 자료 부프레임 종료 60 s 뒤(시작 90 s 뒤)에 가능하다. ADKD 12(느린 MAC)는 키가 10부프레임 더 늦게 나가므로 360 s(390 s)이다. ADKD 4는 GST-UTC와 GST-GPS 변환 변수를 인증한다. 키는 해시 사슬의 역순으로 방송되고, 부동 KROOT가 최소 하루에 한 번 나가므로 현재 키를 KROOT까지 검증하는 해시는 최대 $86{,}400/30+1=2{,}881$회이다(§5.5.1, Eq. 19).

지표(SDD 1.0, 앙각 5° 이상, 1년 평균)최소 성능
ADKD 0, 위성 4기 이상, 30 s 안에 태그95 % 이상
ADKD 0, 가시 위성 전부, 600 s 안80 % 이상
ADKD 12, 위성 4기 이상, 240 s 안95 % 이상
ADKD 4, 위성 1기 이상, 60 s 안97 % 이상
인증 자료를 포함한 첫 위치 고정(TTFF-AD), 핫 스타트 95 %ADKD 0 130 s, ADKD 12 460 s
TTFF-AD, 웜 스타트 95 %(DSM 8블록)ADKD 0 300 s, ADKD 12 520 s
TTFF-AD, 콜드 스타트 95 %6시간 이하

콜드 스타트가 6시간인 이유는 공개키(DSM-PKR)가 6시간마다(00·06·12·18시 GST) 30분 동안만 방송되기 때문이다(§5.4, SDD 표 7의 각주). 수신기는 Merkle 트리 루트를 공장에서 내장하거나 GSC 서버에서 받는다(§6.2). KROOT 8블록은 한 위성에서 받으면 최소 $8\times30=240$ s, PKR 13블록은 390 s이다.

9.16.4.4 시각 동기 요구

수신기는 자료와 태그를 키가 공개되기 전에 받았음을 보장해야 한다. 이를 위해 수신기 시계는 GST에 맞아야 하며 요구 $T_L$은 30 s이다. 수신기 지침은 시각 불확도 $B$가 $B<T_L/2=15$ s이면 모든 태그를, $B<T_L/2+150=165$ s이면 느린 MAC만 사용할 수 있고 둘 다 아니면 OSNMA를 사용하면 안 된다고 규정한다(§2.1, Annex C, p. 9·56~57). 시각을 위성 신호에서만 얻는 수신기에는 순환 의존이 생긴다. 위조 신호가 시각을 15 s 어긋나게 한 뒤에는 키가 공개된 자료에 맞는 태그를 위조하는 것이 이론상 가능해진다 (추론). 따라서 UAS는 독립 시각 원천(전원이 꺼진 동안 유지되는 시계, 네트워크 시각)과 그 불확도의 추정 방법을 설계에 포함해야 한다(4.1.9).

9.16.4.5 워크스루 2 — 태그 위조 확률과 시험 벡터의 재현

문제. 40비트 태그가 위조를 얼마나 막는가. 식은 8.11.7과 같다. 태그가 $t$비트이고 시도가 $n$번이면 위조가 한 번이라도 수락될 확률은 $P=1-(1-2^{-t})^{n}$이다. 가정: 위조자가 인증에 사용되는 위성 4기마다 30 s에 한 번 위조 자료와 태그를 보내고 수신기가 매번 검증한다(1시간에 $n=480$). 키를 모르는 위조자는 태그를 무작위로 맞춰야 하며 9.16.4.4의 시각 요건이 지켜진다고 둔다.

태그 길이 [비트]2024283240
1시간 위조 수락 확률$4.6\times10^{-4}$$2.9\times10^{-5}$$1.8\times10^{-6}$$1.1\times10^{-7}$$4.4\times10^{-10}$

목표 $10^{-9}$을 만족하는 최소 길이는 $\lceil\log_2(480/10^{-9})\rceil=39$비트이므로 SDD의 40비트는 이 가정을 충족한다. 8.11-calc의 같은 함수에 $n=600$(잠금 정책 행)을 넣으면 32비트에서 $1.4\times10^{-7}$, 필요 태그는 40비트로 8.11.7의 표와 일치한다. 두 경우의 차이는 시도율의 출처이다. C2 링크에서는 링크 용량이 시도율을 정하지만 OSNMA에서는 30 s 부프레임 주기가 정한다. 이 값은 무작위 위조만 계산한 것이며 키 관리·재전송·시각 공격은 별개의 문제이다.

시험 벡터의 재현. 수신기 지침 Annex A의 시험 벡터를 표준 라이브러리(hashlib·hmac과 정수 연산)로 다시 계산했다.

검증원문 값재계산
TESLA 키 $K_1=\mathrm{trunc}_{128}(\mathrm{SHA256}(K_2\Vert GST_{SF}\Vert\alpha))$EFF99904…ED92일치
루트 키 $K_0=F(K_1)$, $F^2(K_2)$5BF8C9CB…F0FF일치
Tag0(HMAC-SHA-256의 앞 40비트)E37BC4F858일치
MACSEQ(12비트)0xB08일치
DSM-KROOT 패딩 PDK(88비트)5E130DA4…9522일치
DSM-KROOT의 ECDSA P-256 서명(512비트)원문 공개키로 검증유효

9.16.4.6 인증이 하는 것과 하지 않는 것

OSNMA가 인증하는 자료는 SIS ICD Table 14의 ADKD 0·4·12(궤도·시계·상태, 시각 변환 변수)가 전부이다. 거리 측정 신호 자체의 진위, 신호의 재방송, 재밍은 이 규격의 대상이 아니다(4.6.7.1). 인증이 없는 신호와의 대비. 읽은 LNAV 구조에는 인증 필드가 없다. 부프레임 1의 예약 87비트와 예약 페이지가 있으나 인증용으로 정의되어 있지 않다(Figure 20-1, §20.3.3.5.1). 따라서 GPS에 인증을 더하려면 별도의 신호나 메시지 설계가 필요하며 시험 계획은 4.6.7.3에 있다. QZSS는 신호 인증 서비스(IS-QZSS-SAS-001)와 CLAS 보정 메시지 인증 초안의 게시를 목록으로만 확인했다. 항법 입력을 외부 진입점으로 보는 보안 위험 평가는 8.11.6, 인증 키·서명의 관리 요건은 9.19, 지상·UTM 보안은 8.12, 제품 서명·갱신은 8.13, 스푸핑·재밍의 원리와 사례는 4.5이 다룬다. 이 장은 공격 절차를 다루지 않는다.

9.16.5 보정 데이터 규격 — RTCM·NTRIP·SBAS

9.16.5.1 RTCM 3의 프레임과 MSM

RTCM 3 프레임은 프리앰블 0xD3(8비트), 예약 6비트, 길이 10비트, 본문(최대 1,023바이트), CRC-24Q 3바이트이다(RTKLIB rtcm.c의 input_rtcm3). 본문 앞 12비트가 메시지 번호이다. 다중 신호 메시지(MSM)는 위성군마다 번호 일곱 개가 배정된다. GPS 1071~1077, GLONASS 1081~1087, Galileo 1091~1097, SBAS 1101~1107, QZSS 1111~1117, BeiDou 1121~1127이며 끝자리 1~7이 MSM 종류이다(rtcm3.c). RTKLIB는 MSM 4~7만 관측값으로 복호하고 1~3은 머리부만 읽는다. MSM의 머리부는 169비트이다. 메시지 번호 12, 기준국 ID 12, 시각 30(GLONASS는 요일 3과 일 내 시각 27), 다중 메시지 비트 1, IOD 3, 세션 시간 7, 시계 조정 2, 외부 시계 2, 평활 1, 평활 구간 3, 위성 마스크 64, 신호 마스크 32를 합한 값이며 그 뒤에 위성 × 신호 셀 마스크가 따른다.

MSM위성당 비트셀당 비트셀의 필드(RTKLIB 복호 순서)
41848미세 의사거리 15, 미세 위상거리 22, 잠금 시간 4, 반주기 모호성 1, CNR 6
53663MSM4 + 위상거리율 15(위성당 확장 정보 4·대략 위상거리율 14 추가)
61865고해상도: 의사거리 20, 위상거리 24, 잠금 시간 10, 반주기 1, CNR 10
73680MSM6 + 위상거리율 15

위성당 18비트는 대략 거리의 정수 밀리초 8비트와 밀리초 이하 10비트이다. 셀 수가 $n_{sat}\times n_{sig}>64$이면 RTKLIB는 메시지를 거부한다(decode_msm_head). 표준 본문의 같은 한계는 읽지 못했다 (확인 필요). 기준국 좌표 메시지는 1005가 25바이트, 1006이 27바이트이다(rtcm3e.c). RTKLIB의 MSM 구현은 RTCM 10403.2(2013) 기준이며 NavIC MSM은 없다. 10403.3 이후의 변경은 확인하지 못했다 (확인 필요).

9.16.5.2 워크스루 3 — MSM 메시지의 크기와 필요 선로 속도

문제. 다중 위성군 RTK 보정을 1 Hz로 보내는 데 선로 속도가 얼마나 필요한가. 가정: 가시 위성 38기(GPS 10·GLONASS 8·Galileo 8·BeiDou 12), 모든 위성이 같은 수의 신호를 추적, 위성군마다 MSM 메시지 하나, 1005를 10 s마다 보낸다. 한 메시지의 크기는 $6+\lceil(169+n_{sat}n_{sig}+n_{sat}s_{sat}+n_{cell}s_{cell})/8\rceil$바이트이다.

8 16 24 32 40 48 56 0 4 8 12 16 20 24 가시 위성 수(합계) 필요 선로 속도 [kbit/s] 9,600 baud 직렬 한계 7.68 MSM4·2신호 MSM4·3신호 MSM7·2신호 MSM7·3신호
MSM 보정 데이터를 1 Hz로 보낼 때 필요한 선로 속도. 위성군 4개에 가시 위성을 균등 배분하고 모든 위성이 같은 수의 신호를 추적한다고 가정했다. MSM 한 메시지는 위성군마다 하나이고 헤더 169비트, 셀 마스크, 위성당 18비트(MSM4) 또는 36비트(MSM7), 셀당 48비트(MSM4) 또는 80비트(MSM7)로 구성된다(RTKLIB 소스에서 읽은 값). 가시 위성 38개(GPS 10·GLONASS 8·Galileo 8·BeiDou 12), 2신호이면 MSM4는 5.3 kbit/s, MSM7은 8.4 kbit/s이고 3신호 MSM7은 11.5 kbit/s이다. 8N1 직렬 선로는 바이트당 10비트를 사용하므로 9,600 baud의 데이터 용량은 7.68 kbit/s이다.
구성한 주기 [B]선로 속도 [kbit/s]9,600 baud 직렬(960 B/s) 점유
MSM4·2신호6635.3269 %
MSM4·3신호8957.1893 %
MSM7·2신호1,0528.44110 %
MSM7·3신호1,43611.51150 %

9,600 baud 직렬 선로는 MSM7을 4개 위성군에 1 Hz로 보낼 수 없다. MSM4·2신호도 69 %를 차지하며 선로 오버헤드와 다른 메시지의 여유는 31 %이다. BKG의 NTRIP 문서는 NtripCaster가 스트림당 50~500 B/s의 낮은 대역을 전제로 조정되었다고 적는데(§3.4) 이는 RTCM 2.x 시대의 가정이고 위의 스트림(665~1,439 B/s)은 그 범위를 넘는다.

MAVLink 경로. 기체가 C2 링크로 보정을 받으면 GPS_RTCM_DATA(#233)가 한 번에 180바이트를 나르고 flags의 조각 번호 2비트 때문에 RTCM 메시지 하나는 최대 4조각, 720바이트이다(common.xml). 위 구성의 가장 큰 단일 메시지는 MSM7·BeiDou 12기·2신호의 325바이트(2조각)이다. 그러나 셀이 64개인 극단(위성 16×신호 4에서 748 B, 32×2에서 820 B, 64×1에서 964 B)은 720바이트를 넘으므로 수신기 설정에서 셀 수를 제한해야 한다. 이 극단이 실제 수신기에서 나오는지는 확인하지 못했다 (확인 필요). MAVLink의 구조는 9.5이 다룬다.

9.16.5.3 NTRIP — 전송 규격

NTRIP은 RTCM 스트림을 HTTP 기반으로 인터넷에 배포하는 프로토콜이며 NtripSource가 NtripServer를 거쳐 NtripCaster에 올리고 NtripClient가 마운트포인트로 받는다. 클라이언트가 마운트포인트를 비우면 캐스터는 소스 테이블(STR·CAS·NET 레코드, 세미콜론 구분 필드)을 보낸다(BKG §2·§6). 10410.1(2.0판)의 본문은 읽지 못했다. BKG의 무료 공개본(1.0판)은 프로토콜 예시 블록을 "공식 RTCM 문서를 구매하라"는 문구로 비워 두었으므로 요청 형식은 RTKLIB 클라이언트(stream.c의 reqntrip_c)로 확인했다. 클라이언트는 GET /<마운트포인트> HTTP/1.0과 User-Agent: NTRIP …, 인증이 필요하면 Authorization: Basic <base64(사용자:암호)>를 보내고 ICY 200 OK를 받으며 소스 테이블은 SOURCETABLE 200 OK로 시작해 ENDSOURCETABLE로 끝난다. 기본 포트는 2101이다.

두 가지를 읽어 둔다. 첫째 기본 인증은 base64이므로 암호가 평문이나 다름없다(BKG §5.3도 Basic의 가장 큰 약점으로 암호가 평문으로 가는 점을 든다). 둘째 가상 기준국을 받으려고 클라이언트가 NMEA GGA를 보내면 캐스터가 클라이언트의 위치를 추적할 수 있다고 문서가 직접 경고한다(§5.4). RTCM 메시지의 CRC-24Q는 오류 검출이지 인증이 아니므로 보정 데이터의 출처 확인은 규격 밖의 전송 계층에 달려 있다. TLS 지원 여부는 확인하지 못했다 (확인 필요). 보정 데이터의 위·변조 위험은 범주만 밝히며 8.12와 9.19를 참조한다.

9.16.5.4 SBAS — L1 메시지

L1 SBAS는 1,575.42 MHz에서 1023비트 PRN 부호를 250 bit/s 메시지로 변조해 방송한다(EGNOS OS SDD §4.1.1). RTKLIB sbas.c의 PRN 마스크(형식 1) 복호에서 메시지 구조를 읽을 수 있다. 8비트 선두부 + 6비트 형식 + 마스크 210비트 + IODP 2비트 + 24비트 패리티가 250비트이며 250 bit/s에서 메시지 하나가 1 s이다. 사용되는 형식은 EGNOS SDD Table 4와 같다.

형식(MT)내용
0사용 금지(시험 모드), 시험 중에는 MT0/2로 고속 보정을 함께 보내기도 한다
1PRN 마스크(보정 대상 위성)
2~5, 24고속 보정(24는 고속 6기 + 장기 1기 혼합)
25장기 보정(위성 궤도·시계 오차, 최대 2기)
6, 7, 10무결성 정보, 고속 보정 열화 계수, 열화 매개변수
9, 17GEO 궤도, GEO 책력
12SBAS 시각과 UTC의 오프셋
18, 26전리층 격자점 마스크, 수직 지연·정확도
27, 63서비스 메시지(서비스 지역), 널 메시지

EGNOS OS의 공개 주장치는 최악 사용자 위치에서 수평 3 m, 수직 4 m(95 %)이다(SDD Table 6). SDD는 EGNOS GEO가 L1 메시지를 L5(1,176.45 MHz)로도 방송하나 안전 용도 사용자는 L1만 사용할 수 있고 이는 ICAO SARPs와의 편차라고 적는다(§4.1.1 각주). SBAS 수신 장비 요건(DO-229)과 ICAO 부속서 10의 본문은 읽지 못했다. KASS의 인터페이스 규격은 확인하지 못했다 (확인 필요). KASS의 사업과 서비스 상태는 4.2.7, 보강 방식의 비교는 4.2.6.1이 다룬다.

9.16.6 수신기 출력 규격 — NMEA 0183과 UBX

9.16.6.1 NMEA 0183 문장

NMEA 0183은 RS-422 호환 4,800 bit/s, 8N1(또는 7N2)의 ASCII 문장이다. 소비자용 수신기는 9,600 baud를 흔히 사용한다(gpsd 해설). 문장은 $, 토커 ID 2글자와 형식 3글자, 쉼표로 나눈 필드, *, 체크섬 2자리 16진수, CR·LF이다. 체크섬은 $와 * 사이 문자의 8비트 배타적 논리합이며 오류 검출용이다. 문장의 최대 길이는 CR·LF를 포함해 82바이트이다. 판은 2.3(1998-03), 3.0(2000-07), 4.0(2008-11), 4.10(2012-07), 4.11(2018-11)이다(gpsd 해설의 판 연표).

GGA의 필드는 UTC 시각, 위도·경도(ddmm.mmmmm), 품질 지시(0 무효, 1 GPS, 2 DGPS, 3 PPS, 4 RTK 고정, 5 RTK 부동, 6 추측항법, 7 수동, 8 시뮬레이션), 사용 위성 수, HDOP, 안테나 고도(평균해수면), 지오이드 분리, 차분 보정의 나이, 기준국 ID이다. 높이 기준은 두 필드에서 나온다. 타원체고는 $h=H+N_g$이므로(4.1.3.4) 고도 $H$와 지오이드 분리 $N_g$를 더해 복원한다. u-blox의 예제는 499.6 m와 48.0 m로 $h=547.6$ m이고, gpsd의 예제는 1,113.0 m와 −21.3 m로 $h=1{,}091.7$ m이다. 수신기가 사용한 지오이드 모델은 두 문서 어디에도 적혀 있지 않다. GGA의 사용 위성 수는 0~12 범위로 정의되어(u-blox 설명서) 다중 위성군 수신기가 20기를 사용해도 12를 넘겨 보고할 수 없다. 위도·경도의 마지막 자리는 $10^{-5}$분으로 1.85 cm이고(UBX의 $10^{-7}$도는 1.11 cm), 시각은 10 ms 단위이다. 예제 문장의 체크섬을 다시 계산하면 u-blox 설명서의 예제 9개 가운데 GSA·RMC 2개가 맞지 않는다. 그 둘은 NMEA 4.10의 필드(GSA의 시스템 ID, RMC의 항법 상태)를 추가한 뒤 체크섬을 갱신하지 않은 것으로 보이며(필드를 뺀 문장과는 일치), 나머지 7개는 일치한다. 설명서의 예제는 적합성 시험 벡터가 아니다.

9.16.6.2 UBX 프레임

UBX 프레임은 동기 문자 0xB5 0x62, 클래스 1바이트, ID 1바이트, 길이 2바이트(리틀 엔디언, 페이로드만), 페이로드, 체크섬 CK_A CK_B이다. 체크섬은 클래스부터 페이로드 끝까지의 8비트 Fletcher 알고리즘이다(§3.2·§3.4). 오버헤드는 8바이트이다. 위치·속도·시각 해인 UBX-NAV-PVT는 페이로드 92바이트로 프레임 100바이트이며 경도·위도를 $10^{-7}$도 단위로, 타원체고와 해발 고도를 mm 단위로 모두 포함하고 수평 정확도 추정(hAcc)을 함께 낸다. UBX-RXM-RAWX는 $16+32n_{meas}$바이트로 의사거리·위상·도플러의 원시 측정을, UBX-RXM-SFRBX는 $8+4n_{words}$바이트로 신호가 방송한 항법 부프레임을 그대로 출력한다. 호스트가 방송력이나 OSNMA 같은 메시지를 직접 해석하려면 후자와 같은 원시 출력이 필요하다. 이 설명서에서 OSNMA 지원은 찾지 못했다 (판 확인 필요).

9.16.6.3 워크스루 4 — 전송 시간과 갱신율의 한계

가정: 8N1(바이트당 10비트), 다중 위성군 NMEA 한 세트는 GGA·RMC·VTG와 위성군마다 GSA 하나(4개), GSV 10문장(위성군별 $\lceil n/4\rceil$)으로 문장 길이는 예제 문장 길이에서 어림해 950바이트, UBX RAWX는 측정 40개로 1,304바이트이다.

출력크기 [B]4,800 baud9,600 baud38,400 baud115,200 baud
NMEA GGA 1문장75156 ms78 ms19.5 ms6.5 ms
NMEA 다중 위성군 한 세트9501.98 s0.99 s0.25 s0.08 s
UBX NAV-PVT100208 ms104 ms26 ms8.7 ms
UBX RXM-RAWX(측정 40개)1,3042.72 s1.36 s0.34 s0.11 s

NMEA 표준 속도 4,800 baud에서는 GGA 한 문장의 전송 지연이 156 ms이고, 9,600 baud에서 다중 위성군 NMEA 한 세트는 1 Hz의 한계(0.99 s)에 이른다. NAV-PVT의 최대 갱신율은 9,600 baud에서 9.6 Hz, 115,200 baud에서 115 Hz이다. RAWX 5 Hz(52 kbit/s)는 38,400 baud(최대 2.9 Hz)로 출력할 수 없고 115,200 baud(최대 8.8 Hz)가 필요하다. 출력 지연은 제어 루프의 위상 여유를 줄이므로 수신기 설정의 보율은 항법 필터의 갱신율과 함께 정해야 한다.

9.16.7 지형·장애물 데이터 — SRTM·Copernicus DEM·eTOD

9.16.7.1 공개 DEM의 사양

항목SRTM V3(NASA LP DAAC)Copernicus DEM(GLO-30·GLO-90)
격자1″(3601×3601), 3″(1201×1201), 30″GLO-30 1″, GLO-90 3″, 유럽 한정 EEA-10 0.4″
타일·범위1°×1°, 북위 60°~남위 56°1°×1°, 전 지구
수직 기준EGM96 지오이드(수평 WGS 84)EGM2008(EPSG 3855), 수평 WGS 84-G1150(EPSG 4326)
성격2000-02 우주왕복선 레이더 간섭계, 공극을 ASTER GDEM2·GMTED2010·NED로 채움편집된 수치표면모형(WorldDEM, TanDEM-X 2010-12~2015-01 취득), 건물·수관 포함
정확도 주장이 장이 읽은 안내서에는 없다 (확인 필요, 4.8.3.4)절대 수직 4 m 미만(LE90), 수평 6 m 미만(CE90), 상대 2 m 미만(기울기 20 % 이하) (공개 주장치)
파일1° 타일DGED(GeoTIFF 32비트 실수), DTED(16비트 정수)

Copernicus DEM의 정확도는 전 지구 평균 통계이며 남극·그린란드를 제외하고 지역 편차가 있다고 핸드북이 밝힌다. 이 값은 DSM의 지표 피복(수관·건물)과 취득 시점(2015년 이전) 이후의 변화를 반영하지 않는다. 파일 형식(GeoTIFF·LAS 등)은 9.17가, DEM이 TRN에 미치는 영향은 4.8.3.4가 다룬다.

9.16.7.2 워크스루 5 — 격자 간격을 미터로

문제. 각초 단위 격자가 위도에 따라 몇 미터인가. WGS 84 타원체로 경도 방향 간격 $\Delta_{\lambda}=\Delta''\,\dfrac{\pi}{648000}\,N\cos\varphi$, 위도 방향 $\Delta_{\varphi}=\Delta''\,\dfrac{\pi}{648000}\,M$($N$은 묘유선, $M$은 자오선 곡률반경)로 계산했다.

0 10 20 30 40 50 60 70 80 0 20 40 60 80 100 위도 [°] 동서 방향 격자 간격 [m] 서울 37.6° 3″ 고정(SRTM 3″) GLO-90(계수 적용) 1″ 고정(SRTM 1″) GLO-30(계수 적용)
DEM의 동서 방향 격자 간격을 위도의 함수로 계산했다(WGS 84 타원체). 경도 방향 간격을 각초로 고정하면 미터 간격이 $\cos\varphi$에 비례해 줄어 위도 60°에서 절반이 되고 고위도에서 0에 가까워진다. Copernicus DEM은 위도대마다 경도 간격을 1·1.5·2·3·5·10배로 늘려(핸드북 5.0 Table 3) 위도 80°까지 미터 간격을 GLO-30에서 16~32 m 범위로 유지한다. 0~50° 대는 계수가 1이어서 고정 격자와 같다. 서울(37.6°N)에서 1″ 격자는 남북 30.8 m, 동서 24.5 m이다. 남북 방향 간격은 위도와 거의 무관하다(1″에 30.7~31.0 m).
위도1″ 남북 [m]1″ 동서 [m]3″ 동서 [m]비고
0°30.730.992.8
37.6°(서울)30.824.573.6
50°30.919.959.7Copernicus의 계수 1이 끝나는 위도
60°30.915.546.5고정 격자는 절반

계산값은 Copernicus 핸드북 Table 3의 미터 범위(GLO-30·GLO-90, 위도대 여섯 개의 양 끝 열두 값)와 0.1 m 이내로 일치한다. 격자를 각초로 정의하는 DEM은 위도에 따라 동서 간격이 달라진다. 1° 타일 하나는 1″ 격자에서 $3600^2=1.296\times10^{7}$ 샘플이며 16비트 정수로 25.9 MB, 32비트 실수로 51.8 MB이다. 서울 부근에서 1″ 격자 셀은 30.8 m × 24.5 m이다.

9.16.7.3 ICAO eTOD 수치 요구와 공개 DEM의 비교

eTOD는 ICAO 부속서 15·PANS-AIM이 정한 지형·장애물 데이터 집합이며 네 영역을 둔다. 영역 1은 국가 영토 전체, 영역 2는 공항 주변(부속서 15 개정 36에서 2a~2d로 세분), 영역 3은 이동 지역에 접한 구역, 영역 4는 정밀 접근(Category II·III) 활주로 앞의 전파 고도계 구역이다(TOD 매뉴얼 §3.4.1). 지형 수치 요구는 PANS-AIM 부록 1 Table A1-8이다(매뉴얼 §3.5.5.2, p. 51).

영역격자 간격수직 정확도수평 정확도GLO-30(1″, 4 m, 6 m)의 단순 비교
13″(약 90 m)30 m50 m세 항목 모두 요구 이하
21″(약 30 m)3 m5 m격자는 같고 수직(4 m > 3 m)·수평(6 m > 5 m)이 초과
30.6″(약 20 m)0.5 m0.5 m세 항목 모두 초과
40.3″(약 9 m)1 m2.5 m세 항목 모두 초과

정확도의 신뢰 수준은 모두 90 %이고 무결성 분류는 영역 1이 일반(routine), 나머지가 필수(essential)이다. 이 표는 공개 주장치를 요구값과 나란히 놓은 것이며 적합 판정이 아니다. 요구는 영역별 지표 피복과 검증 방법까지 포함한다. 장애물은 영역 1에서 지상 100 m 이상, 영역 2에서 항행에 위험한 모든 장애물이며 수직 정확도 30 m(영역 1)·3 m(영역 2)·0.5 m(영역 3)·1 m(영역 4)이다(매뉴얼 §3.6.2·Table A1-6, p. 53·68~69). 매뉴얼은 지형을 GeoTIFF나 ASCII 격자로, 장애물을 AIXM 5.1.1 응용 스키마로 제공하도록 안내한다(9.14.7.1). eTOD의 수직 기준은 EGM-96 평균해수면이다(§5.4.2, p. 125).

9.16.7.4 높이 기준이 어긋나는 지점

출처높이지오이드 기준
NMEA GGA, UBX hMSL평균해수면(해발)수신기 내부 모델(문서에 명시 없음)
UBX height타원체고없음
SRTM V3해발EGM96
Copernicus DEM해발EGM2008
eTOD(부속서 15)해발EGM-96
ASTM F3548·AIXM 변환(9.14.8)WGS 84 타원체고만 허용변환에 모델 필요

서로 다른 높이 기준의 값을 빼면 지오이드고 차이가 오차로 들어간다. EGM96과 EGM2008의 지오이드고 차이의 크기는 지오이드 격자를 읽지 않아 계산하지 못했다 (확인 필요). 높이 기준의 원리와 변환은 4.1.3.4, 2.8.3.2, 9.14.8이 다룬다.

9.16.7.5 워크스루 6 — 위치 오차와 DEM 오차의 합성

문제. DEM으로 지상고(AGL)를 계산할 때 기체의 위치 오차와 DEM의 오차가 합쳐 얼마가 되는가. 지상고 오차의 1σ를 다음 네 항의 제곱합 제곱근으로 둔다.

$$\sigma_{AGL}=\sqrt{\sigma_{v}^{2}+\sigma_{DEM}^{2}+\left(\tan\theta\,\sigma_{h}\right)^{2}+\left(\tan\theta\,\sigma_{DEM,h}\right)^{2}}$$

가정: 항은 서로 독립이고 지형 기울기 $\theta$ 방향의 수평 한 축 오차만 높이로 바뀐다. $\sigma_{DEM}=4/1.645=2.43$ m(LE90 4 m), $\sigma_{DEM,h}=6/2.146=2.80$ m(CE90 6 m), $\theta=20°$이다. 기체의 95 % 값은 단독 GNSS 수평 5 m·수직 8 m(가정), SBAS 수평 3 m·수직 4 m(EGNOS 공개 주장치), RTK 고정해 수평 3 cm·수직 6 cm(가정)이다.

GNSS 구성기체 수직 $\sigma_v$ [m]DEM 수직 [m]기울기 항 합 [m]$\sigma_{AGL}$ [m]95 % [m]
단독 GNSS4.082.431.264.929.6
SBAS2.042.431.113.366.6
RTK 고정해0.032.431.022.645.2

RTK로 기체 높이를 센티미터로 알아도 DEM 기반 지상고는 5 m 수준이다. DEM 항(2.43 m)이 지배하기 때문이다. 이는 지표 피복 불일치(수관·건물, 4.8.3.4)를 넣지 않은 하한이다. 지상고가 중요한 운용은 거리 센서(레이더 고도계, LiDAR, 2.8·6.6)로 직접 측정하는 편이 낫다. 위치 오차가 지리 위치 결정에 미치는 영향은 6.10이 다룬다.

9.16.7.6 한국 제도 — 소개 수준

국토지리정보원이 수치지형도와 수치표고모델(DEM)을 제공하며 공공데이터포털에 「국토지리정보원_DEM」(20240924판)이 등록되어 있고 내려받으려면 로그인이 필요하다. 설명은 "공간정보를 입체화한 수치표고모델"로만 적혀 있어 격자 간격·정확도·수직 기준은 확인하지 못했다 (확인 필요). 2024년 5월에 국토지리정보원이 경기도와 0.5 m급 DEM의 공동 구축 협약을 맺었다는 보도가 있다 (2차). 공간정보의 반출·보안 제한은 18.20, 항공 장애물 정보는 14.21, 국내 표준 체계는 9.22이 다룬다.

9.16.8 설계 트레이드오프 — 항법 입력의 인터페이스를 어떻게 구성할 것인가

방식을 셋으로 펼친다.

① NMEA 단일 경로. 모든 수신기와 지상 도구가 읽는다. 장점은 호환성과 사람이 읽을 수 있는 로그이다. 단점은 정보 손실(사용 위성 수 12 한계, 시각 10 ms, 지오이드 모델 불명), 큰 전송량(한 세트 950바이트), 인증·스푸핑 지표 같은 무결성 정보의 부재이다.

② 제조사 이진 프로토콜과 보정 주입. UBX 같은 이진 출력으로 위치(100바이트)·오차 추정·원시 측정을 받고 RTCM을 C2 링크나 셀룰러로 주입한다. 장점은 정밀도(위도·경도 1.1 cm), 효율, 오차 추정이다. 단점은 제조사 문서의 판에 종속되고 주입 경로의 대역·조각 한계(9.16.5.2)를 관리해야 하는 점이다.

③ 원시 측정과 항법 비트를 받아 호스트에서 해석. RAWX·SFRBX 계열 출력으로 방송력·OSNMA·SBAS를 호스트가 검증한다. 장점은 인증·무결성의 통제권과 수신기 교체의 자유이다. 단점은 개발·인증 비용, 시각 요건(9.16.4.4), 대역(RAWX 5 Hz에 52 kbit/s)과 계산량이다.

방식장점단점누구에게 맞는가
① NMEA호환·가독성정보 손실·무결성 정보 없음시험·로그 보조, 비핵심 기능
② 이진·보정 주입정밀·효율제조사 종속·주입 경로 관리일반 민간 UAS의 비행 제어
③ 호스트 해석인증·무결성 통제비용·대역·시각 요건인증·무결성 증거가 필요한 중대 운용

견해: 하나만 택하지 않고 비행 제어 입력은 ②로, 인증·무결성 감시는 ③의 일부(원시 측정과 인증 상태의 출력 확보)로, NMEA는 시험·기록용으로 두는 구성이 근거가 가장 강하다. 근거는 세 가지이다. 첫째 NMEA는 9,600 baud에서 한 세트가 1 s에 이르러 제어 루프에 부적합하다(9.16.6.3). 둘째 OSNMA는 호스트나 수신기가 시각 요건을 만족하는지 검증해야 의미가 있어 시각 불확도를 알 수 있는 쪽이 통제해야 한다(9.16.4.4). 셋째 DEM·보정·인증이 각자 다른 높이·시각 기준을 사용하므로 변환을 한곳에서 관리해야 한다(9.16.7.4). 반대 견해로는 인증과 RAIM은 수신기 제조사가 내부에서 구현한 것이 더 검증되어 있으므로 호스트가 다시 구현하면 오류 위험만 늘린다는 주장이 있다. 이 경우에도 수신기가 인증 상태와 무결성 지표를 출력해 주는지는 사양에서 확인해야 한다.

9.16.9 세 축 비교

항목군용 드론민간 UASAAM(eVTOL)
사용 신호이 장의 범위 밖(군용 신호는 4.6.7.3, 제10~12부)L1 C/A 중심, 다중 위성군·이중 주파수 수신기이중 주파수 다중 위성군, SBAS와 무결성 정보(Galileo I/NAV 워드 22의 ISM 등)
메시지 인증범위 밖선택(OSNMA 지원 수신기, 시각 요건 필요)요구 수준은 이 장이 확인하지 못함 (확인 필요)
보정범위 밖RTK(RTCM·NTRIP)·SBAS, 선로 대역 제한SBAS·ARAIM 중심(4.4), 지상 보정 사용 여부는 확인 필요
수신기 인터페이스범위 밖NMEA·UBX 같은 제조사 프로토콜이중화·항공 장비 인터페이스(이 장 범위 밖, 9.4)
지형 데이터범위 밖공개 DEM(DSM), 오차 합성 필요eTOD 수준의 요구 (확인 필요)

9.16.10 관련 규격·프로토콜

문서발행무엇을 정하나상세 장
IS-GPS-200 N판(2022-08-01)미국 우주군L1 C/A·L2 신호, LNAV 메시지 — 원문 확인(아카이브 사본)이 장
IS-GPS-705 J판·IS-GPS-800 J판(2022-08-01)미국 우주군L5 CNAV, L1C CNAV-2 — 원문 확인(아카이브 사본)이 장
Galileo OS SIS ICD 2.2판(2025-11)EU(EUSPA)E1·E5a·E5b 신호, I/NAV·F/NAV, ISM — 원문 확인이 장, 4.4
Galileo OSNMA SIS ICD 1.1판·수신기 지침 1.3판·SDD 1.0판EU(EUSPA)OSNMA 비트 구조·수신기 요건·서비스 수치 — 원문 확인이 장
BeiDou ICD B1I 3.0판·B1C 1.0판·B2a 1.0판중국 위성항법시스템관리실B1I D1·D2, B-CNAV1, B-CNAV2 — 원문 확인(B2b 등 미열람)이 장
GLONASS ICD L1·L2 5.1판(2008)러시아FDMA 신호와 메시지 — 원문 확인(대학 호스팅 사본)이 장
IS-QZSS-PNT-006 등일본 내각부QZSS 신호·서비스 — 목록만 확인, 본문 미열람이 장
RTCM 10403.xRTCMDGNSS·RTK 메시지(MSM) — 본문 미열람(유료), RTKLIB 소스로 확인이 장
RTCM 10410.1·BKG NTRIP 1.0판RTCM·BKGNTRIP — 10410.1 미열람, 1.0판 공개본 확인이 장
RTCA DO-229, ICAO 부속서 10 제I권RTCA·ICAOSBAS 신호·장비 — 미열람(유료), EGNOS SDD로 확인4.1.7
EGNOS OS SDD 3.0판(2024-11)EU(EUSPA)SBAS 메시지 형식과 서비스 성능 — 원문 확인이 장, 4.2
NMEA 0183, IEC 61162-1NMEA·IEC수신기 출력 문장 — 본문 미열람(유료), gpsd 해설·u-blox 설명서로 확인이 장
u-blox F9 HPG 1.32 인터페이스 설명서u-bloxUBX·NMEA 출력 — 원문 확인(2022-05판)이 장
MAVLink common.xmlMAVLinkGPS_RTCM_DATA 등 — 원문 확인9.5
ICAO 부속서 15·PANS-AIM, EUROCONTROL TOD 매뉴얼 3.0판ICAO·EUROCONTROLeTOD 영역·수치 요구 — 부속서 본문 미열람, 매뉴얼 인용 범위 확인이 장, 14.21
Copernicus DEM 핸드북 5.0판, SRTM 사용자 안내서 V3Airbus·NASA공개 DEM의 격자·기준·정확도 — 원문 확인이 장, 4.8

전체 지도는 A.6에 있다.

9.16.11 관련 규제·인증 요구와의 연결

  • 필요항법성능과 GNSS 규제(4.1.7, 4.2.14). 이 장의 SBAS 메시지와 무결성 플래그가 정확도·무결성 요구의 신호 쪽 근거이다.
  • GNSS 취약성과 수신기 방호(4.5, 4.6). OSNMA의 시각 요건과 인증 범위가 방호 설계의 입력이다.
  • 보안(8.11, 8.12, 8.13, 9.19). 항법 입력의 보안 위험 평가, 보정 데이터 전송의 위·변조, 키 관리.
  • 항공정보와 지오존(14.21, 9.14). eTOD·AIXM과 높이 기준의 변환.
  • 규격 읽기와 적합성 시험(9.1, 9.23). 판 관리와 예제 문장의 한계(9.16.6.1).
  • 결합 항법과 ARAIM(4.4). Galileo ISM과 인증 신호의 결합.
  • 한국 표준과 공간정보(9.22, 18.20). 국내 규격과 지형 자료의 제도.

9.16.12 함정과 한계

오해실제더 볼 곳
IS-GPS 최신판은 공식 포털에서 받을 수 있다이 장은 두 포털에서 받지 못해 아카이브 사본을 읽었다9.16.3.1
인증 신호를 사용하면 위조를 막는다OSNMA는 메시지만 인증하고 신호 위조·재밍은 막지 못하며 시각이 틀리면 무력하다9.16.4.4·9.16.4.6
태그 40비트면 어떤 위협에도 충분하다무작위 위조만 계산한 값이며 시각·키·재전송은 별개이다9.16.4.5
NMEA 9,600 baud면 1 Hz에 충분하다다중 위성군 한 세트가 0.99 s이다9.16.6.3
GGA의 사용 위성 수는 실제 수이다0~12로 정의되어 12를 넘을 수 없다9.16.6.1
설명서의 예제 문장은 그대로 시험에 사용할 수 있다u-blox 설명서의 GSA·RMC 예제는 체크섬이 맞지 않는다9.16.6.1
보정 스트림은 50~500 B/s이다RTCM 2.x 시대의 값이며 MSM 다중 위성군은 665~1,439 B/s이다9.16.5.2
NTRIP은 암호화되어 있다1.0판의 기본 인증은 base64이고 GGA가 위치를 노출한다9.16.5.3
DEM의 높이는 어느 것이든 같은 기준이다SRTM은 EGM96, Copernicus는 EGM2008, eTOD는 EGM-96이다9.16.7.4
공개 DEM은 eTOD를 만족한다GLO-30의 주장치는 영역 2의 수직·수평 요구를 넘는다9.16.7.3
RTK면 지상고도 센티미터로 안다DEM 항이 지배해 약 5 m이다9.16.7.5

미해결 문제. IS-GPS 현행판과 변경 통지의 내용, RTCM 10403.x와 10410.1 본문의 MSM 한계·NTRIP 2.0의 보안 기능, DO-229와 KASS의 인터페이스, QZSS·BeiDou B2b·GLONASS CDMA의 규격, 수신기 제품별 OSNMA 지원과 시각 요건 구현, SRTM의 정확도 근거, 한국 DEM의 사양, EGM96과 EGM2008의 지오이드고 차이는 이 장의 자료로 답할 수 없다 (확인 필요). 이 장의 수치는 원문의 상수와 이 책의 가정으로 계산한 것이며 실측이 아니다.

9.16.13 체크포인트·연구 질문

체크포인트:

  1. LNAV 프레임의 크기·시간과 책력 전체를 받는 시간을 구하고, 부프레임 2·3의 정보 비트가 190인 이유를 설명하라.
  2. 시계·궤도를 모두 받는 데 걸리는 시간이 LNAV에서 18~36 s이고 GLONASS에서 8~32 s인 이유를 설명하라(9.16-calc.py).
  3. OSNMA에서 ADKD 0 자료가 인증되기까지의 지연을 부프레임 단위로 구하고, 느린 MAC에서는 어떻게 달라지는가?
  4. 수신기의 시각 불확도가 20 s이면 OSNMA를 사용할 수 있는가? 근거를 적어라.
  5. 38기 다중 위성군 MSM7·2신호 보정의 필요 선로 속도와 9,600 baud 직렬 선로의 점유율을 구하라.
  6. GGA의 고도와 지오이드 분리에서 타원체고를 복원하고, DEM(Copernicus)과 비교할 때 무엇을 맞춰야 하는가?
  7. 서울(37.6°N)에서 1″ DEM 셀의 동서 간격과 남북 간격은 각각 얼마이며 GLO-30의 eTOD 영역 2 적합성에 대해 무엇을 말할 수 있는가?

연구 질문(25.7에 모은다):

  • 인증된 항법 메시지만 사용했을 때의 기하 열화와 인증 지연을 항법 필터의 무결성 감시에 반영하는 방법은 무엇인가.
  • 수신기 시계가 위성 신호에 의존할 때 OSNMA의 시각 요건을 독립적으로 만족시키는 최소 구성은 무엇인가.
  • 보정 데이터(RTCM·SBAS)의 출처 인증을 전송 계층이 아니라 메시지 수준에서 제공하는 규격은 어떤 형태이어야 하는가.
  • 공개 DEM의 높이 기준·지표 피복·취득 시점의 불일치를 지상고 추정의 불확도에 정량적으로 반영하는 방법은 무엇인가.

1차 출처(이 장):

  • U.S. Space Force, GPS Interface Specification IS-GPS-200 N판, IS-GPS-705 J판, IS-GPS-800 J판(각 2022-08-01) — 인터넷 아카이브에 보존된 gps.gov 사본.
  • 유럽연합(EUSPA), Galileo Open Service Signal-In-Space ICD 2.2판(2025-11), OSNMA SIS ICD 1.1판(2023-10), OSNMA Receiver Guidelines 1.3판(2024-01), OSNMA SDD 1.0판(2025-07), EGNOS OS SDD 3.0판(2024-11) — gsc-europa.eu.
  • 중국 위성항법시스템관리실, BDS SIS ICD B1I 3.0판(2019-02), B1C 1.0판, B2a 1.0판(2017-12) — en.beidou.gov.cn.
  • Russian Institute of Space Device Engineering, GLONASS ICD L1·L2 5.1판(2008) — 호스팅 사본.
  • RTKLIB(T. Takasu) 소스 rtcm3.c·rtcm.c·rtcm3e.c·sbas.c·stream.c(GitHub master, rtcm3.c 커밋 3a92abf, 2018-01-30).
  • BKG, Networked Transport of RTCM via Internet Protocol (Ntrip) 1.0판 공개본.
  • E. S. Raymond, NMEA Revealed(gpsd 문서). u-blox, F9 HPG 1.32 Interface Description UBX-22008968 R01(2022-05).
  • MAVLink, message_definitions/v1.0/common.xml(GPS_RTCM_DATA).
  • NASA LP DAAC, The Shuttle Radar Topography Mission (SRTM) Collection User Guide V3(2015-10 개정). Airbus, Copernicus DEM Product Handbook 5.0판(2022-11-29).
  • EUROCONTROL, Terrain and Obstacle Data Manual, EUROCONTROL-GUID-0158, 3.0판(2021-05-04).
  • NMEA 0183·IEC 61162-1·RTCM 10403.x·10410.1·RTCA DO-229, ICAO 부속서 10·15·PANS-AIM 본문, IS-QZSS 문서 — 읽지 못함 (확인 필요).

다음 장: 9.17 — 지리공간·임무 데이터 규격: OGC·GeoTIFF·LAS·비행 로그 형식으로 간다.