Local Broadcast and Messaging

Andi Lamprecht ·2026-05-11· 10 min read· Draft

1. Scope and Audience

This page is for RF engineers, embedded developers, and verifier-app implementers. It assumes the reader has already loaded the capsule onto the aircraft per Disconnected Operations §4 and is now asking “what exactly goes on the wire?”

The conceptual story — why capsules are pre-signed, how time tampering is mitigated, how verification still works — stays in Disconnected Operations. The standards-compliance argument (does this fit Part 89 / F3411 / F3586?) stays in Remote ID Standards Compatibility.

2. Coexistence with Regulatory Remote ID

Many drones already broadcast over Bluetooth or Wi-Fi to comply with ASTM F3411 / FAA Remote ID rules. ATOMx is layered on top of, not in place of, the regulatory broadcast.

The aircraft transmits the standard Remote ID message set unchanged: Basic ID, Location/Vector, Self-ID, System, Operator ID. Receivers without ATOMx awareness see this and behave exactly as they do today.

ATOMx-specific data is carried inside the Authentication Message (F3411 Message Type 0x2). The 4-bit Authentication Type field has explicit “Available for Private Use” codes (0xA–0xF) that F3411 §5.4.5.11 reserves for custom attestation. ATOMx uses one of those (registry path discussed in Remote ID Standards Compatibility §6). ATOMx-aware receivers parse the payload; ATOMx-unaware receivers treat the Authentication Message as an unknown sub-type and ignore it. Backwards-compatible by construction.

3. Broadcast Channels

Channel-selection priority is currently a runtime decision per aircraft capability — see Open Questions for the formal selection ladder.

4. The Authentication Message Envelope

4.1 Block Structure (F3411 §5.4.5.9–5.4.5.15)

Every F3411 broadcast message is a 25-byte block: 1 byte of header + 24 bytes of body. The Authentication Message is a sequence of such blocks called pages, all sharing the same Message Counter (§5.4.4.2, BUR0060).

Page 0 layout (F3411 Table 8):

Pages 1–15 layout (F3411 Table 9):

Maximum capacity: 17 + 15 × 23 = 362 bytes total — but the on-the-wire Length field is a uint8 capped at 255 bytes. F3411 explicitly notes that data beyond the 255-byte Length limit may be sent on additional pages up to LastPageIndex, but this is a rarely-used corner of the spec.

4.2 ATOMx Payload Fragmentation

ATOMx’s ≈140-byte attestation (composition table below) fragments cleanly across 7 pages:

    flowchart LR
    P0["Page 0<br/>17 B payload<br/>+ timestamp"] --> P1["Page 1<br/>23 B"]
    P1 --> P2["Page 2<br/>23 B"]
    P2 --> P3["Page 3<br/>23 B"]
    P3 --> P4["Page 4<br/>23 B"]
    P4 --> P5["Page 5<br/>23 B"]
    P5 --> P6["Page 6<br/>23 B"]
    P6 --> Done["155 B capacity<br/>≈140 B used"]
    classDef pg fill:#fef3c7,stroke:#b45309,color:#7c2d12
    class P0,P1,P2,P3,P4,P5,P6 pg
  

Capacity used: 17 + 6 × 23 = 155 bytes. ATOMx attestation: ≈140 bytes. Slack: ~15 bytes — enough for minor format growth without slipping into an 8th page.

4.3 Reassembly Rules

• All pages in a single Authentication Message share the same Message Counter (BUR0060).
• Pages may arrive out of order. Receivers reassemble by PageNumber up to LastPageIndex, then validate the concatenated Auth Data against ATOMx’s payload schema.
• Page 0 is mandatory — it carries the Timestamp and the LastPageIndex. A receiver that misses Page 0 cannot determine total length and must wait for the next broadcast cycle.
• A missing intermediate page invalidates the whole attestation; receivers do not act on partial payloads.

5. ATOMx Payload Composition

6. Message Pack Scheduling

On Bluetooth 5 LE Long Range and Wi-Fi Beacon, F3411 bundles up to 9 blocks into a Message Pack (Message Type 0xF, §5.4.7). Each multi-page Auth Message page counts as one block toward the 9-cap.

ATOMx (7 Auth pages) + the Part 89 mandatory set (Basic ID, Location/Vector, System) = 10 blocks — one over the cap. The full reasoning, the 9-block cap citation (BB50120), and the alternating-Pack mitigation diagrams live in Remote ID Standards Compatibility §5.1.

On Bluetooth Legacy 4.x, Packs don’t apply — each advertisement carries one 25-byte block. Auth pages are interleaved with required messages over time at the static refresh rate ([BcMinStaticRefreshRate], F3411 Annex A3).

7. Sideband Channel (Wi-Fi Direct)

When a verifier observes a broadcast but does not have the matching capsule cached, the verifier may fetch it directly from the aircraft over Wi-Fi Direct.

    flowchart LR
    subgraph A["Aircraft"]
        SE[Secure Element<br/>identity key + capsule]
    end
    A -->|BT / Wi-Fi NaN<br/>Authentication Message| Att[/Compact Attestation/]
    Att --> Verifier[Authority Field Device]
    Verifier -->|cache hit| Verify[Local Verify]
    Verifier -.cache miss.-> Side[Wi-Fi Direct<br/>sideband request]
    Side <-->|capsule| A
    Side --> Verify
  

7.1 Mutual Authentication

The Wi-Fi Direct sideband is mutually authenticated:

Aircraft refuses sideband requests from devices that do not present an enrolled authority device certificate. This prevents a hostile peer from harvesting capsules — the protected claims inside would still be envelope-encrypted, but defense-in-depth keeps the encrypted blob away from unauthorized peers entirely.

7.2 Retrieval Methods Compared

8. Multi-Aircraft RF

A single field verifier may observe many aircraft simultaneously — a sUAS swarm, an airshow, a wildfire-response operation.

9. Mid-Flight Amendment Delivery and Deferred Verification

9.1 Mid-Flight Amendments

A flight underway in disconnected mode may receive an amendment (TFR pop-up, jurisdiction state change, authority instruction). Delivery paths in priority order:

1. Operator app sideband — if the pilot’s phone has any cellular signal at any moment, ATOMx pushes the amendment; phone relays to controller relays to aircraft
2. Direct cellular — if the aircraft has its own modem and is in coverage
3. Authority field-device sideband — an authorized verifier within range can push an amendment via Wi-Fi Direct after authenticating
4. Best-effort, not-acknowledged — if none of the above succeed, ATOMx records the amendment as issued-but-not-acknowledged; the conformance engine evaluates the original package on the aircraft side and flags any post-flight divergence in reconciliation

Mid-flight amendments are an open question for fully air-gapped environments; the current model gracefully degrades rather than fails. See Origins §9.

9.2 Deferred Verification (Cache-Miss Fallback)

When a verifier observes a broadcast and has neither the capsule cached nor a way to fetch it (sideband fails, no peer in range):

When the verifier reaches connectivity, captured broadcasts are reconciled — ATOMx returns the matching capsule and the verifier retroactively renders the historical operational view. Deferred verification does not retroactively change the public state operators saw at the time, but it does enable post-event review.

10. Open Questions

11. Cross-References

• Disconnected Operations — the trust/verification story (capsule, time, reconciliation)
• Remote ID Standards Compatibility — F3411 / Part 89 / F3586 / F3548 compatibility analysis; Message Pack scheduling diagrams
• Aircraft Hardware Identity — secure-element signing of the live attestation
• Authorization Package — what’s inside the capsule that the broadcast points at