# M10 communications-support source register

Reviewed 2026-10-12; relay-topology sources added 2026-10-13. Scope: mission-data needs, receiver evidence and bounded offline/tabletop teaching exercises. These sources support selected concepts, not radio licensing, coverage, flight authorization, field readiness or learner achievement. CPX remains paused.

| ID | Primary source and actual reading | Supported scope | Limits |
| --- | --- | --- | --- |
| COM01 | [MAVLink Command Protocol](https://mavlink.io/en/services/command.html), rendered body lines224–283 | Command acknowledgement/result and completion are distinguishable; long-running progress/final result need interpretation | Not proof of mission-data receipt, network availability or human acceptance. No flight-control code, retry settings or full linked definitions read |
| COM02 | [MAVLink Heartbeat/Connection Protocol](https://mavlink.io/en/services/heartbeat.html), rendered body lines224–281 | Component presence and channel-dependent connection monitoring | Presence is not data quality, receipt or flight permission. No universal heartbeat/timeout rate, RF parameter or coverage claim |
| COM03 | [RFC9171 Bundle Protocol Version7](https://www.rfc-editor.org/rfc/rfc9171.html), January2022: abstract/metadata, introduction near179, lifetime near697–701, selected status/reception/delivery extracts near761–768,839–865 | Intermittent connectivity motivates store/carry/forward; receipt, forwarding, delivery and lifetime are separate concepts | Selected passages only, not whole document, security analysis, errata or implementation certification. This exercise is not BPv7 wire format or protocol interoperability |
| COM04 | [ITU-T F.749.18 (06/2024): Framework and requirements for emergency services using civilian unmanned aerial vehicles](https://www.itu.int/epublications/publication/itu-t-f-749-18-2024-06-framework-and-requirements-for-emergency-services-using-civilian-unmanned-aerial-vehicles), sections 7.1–7.2, 8.1 and Appendix I | Emergency UAS communications are a system of devices, network access, services and applications; a relay needs airborne equipment and an onward terrestrial or satellite path. The text differentiates relay UAS from task-specific UAS and discusses constrained backhaul/prioritization | International recommendation and illustrative use cases, not Thai authorization, a required design for every incident, a claim that any drone provides coverage, or a measured performance result |
| COM05 | [NIST Public Safety Communications Research: Uncrewed Aircraft Systems](https://www.nist.gov/ctl/pscr/research-portfolios/uncrewed-aircraft-systems), updated 23 June 2026, Portfolio Problem Statement and Featured Project | NIST identifies reliable telemetry/multimedia transfer and multi-hop links as research problems; proposed simulation measures include latency, packet loss, link robustness and interference | Research portfolio and project goals, not completed validation of the teaching scenario or a threshold for a particular link, radio or aircraft |

The actual reading occurred during M09 verification preparation and is retained in the task's preliminary research record. No full-standard claim is made. The RFC page exposes errata links, but those were not reviewed; no latest-compliance claim follows.

Paraphrase budgets across the chapter, kits and this record are capped at160/140/180 English-equivalent words respectively; no extended quotations or source-image redistribution. Repeated citations identify provenance without reproducing whole articles. The Thai mission workflow, KSEC tasks, selection matrix, byte/rate example, JSON schema, toy time limits, expected cases and offline program are authored teaching design.

The example 2MiB at256kbit/s uses explicit authored assumptions: 2×1024×1024×8/256000 =65.536seconds of ideal serialization before overhead or interruptions. It is not a link measurement. The toy30second need therefore cannot be met by that ideal configuration; this does not prescribe a transmitter or operational bitrate.

The fixture uses fictional identifiers and relative times. Its checksum is an integrity comparison against an authored digest, not sender authentication. Prior accepted records are authored initial-state assumptions. Each case resets independently. Program results demonstrate local logic only; human receipt, RF, aircraft and learner results remain NOT_RUN. Specialist reviewer is not assigned; field review pending.

Revisit when the actual aircraft/interface/manual, communications service, recipient process, information-sharing authority or governing radio/aviation requirements are chosen or changed. The current chapter links to existing legal/operational foundations rather than inventing universal operating parameters. No scheduled automation or contact with third parties is created.

## M10 relay-topology tabletop card · 2026-10-13

`TRAIN-M10-RELAY-01` is a new fictional planning card separate from the C01–C12 offline receiver fixture. COM04 supports asking about the access leg, onward network/backhaul, carried communications equipment and service priority; COM05 supports asking what latency, packet loss, interference and robustness evidence a real test would need. COM03 supports keeping queued, delivered and human-acknowledged states distinct. The four-path decision table, diagram, role tasks and expected answers are authored teaching design. No signal measurement, network service, identity, airspace or spectrum permission, human receipt, aircraft test, learner run or field result has occurred. A diagram arrow cannot establish connectivity. The command/control link remains a separate safety boundary from mission data even when a proposed aircraft carries communications equipment.
