AIRSPACE / KNOWLEDGE & DESIGN

Remote ID | What the broadcast tells you, and what it doesn't

Information that identifies an aircraft and information that coordinates a flight play different roles. Starting from what each scheme actually transmits, we think through the screen and the data model.

Read this page in order
01

Remote ID is a mechanism for identification

The FAA describes Remote ID as a system in which an aircraft in flight broadcasts identification and location information that others can receive. In the United States there are three ways to comply: a Standard Remote ID aircraft, an add-on broadcast module, or flying at an FAA-Recognized Identification Area (FRIA) under its conditions. Japan's rules are not the same, so check the requirements for each jurisdiction rather than treating them as one.

Source: FAA | Remote IdentificationSource: MLIT Japan | Unmanned Aircraft Registration Portal
02

Compare what each US scheme broadcasts

InformationStandard Remote IDBroadcast module
IdentificationInformation identifying the aircraftSerial number of the module
Aircraft dataLatitude, longitude, geometric altitude, velocityLatitude, longitude, geometric altitude, velocity
Ground positionControl station location and geometric altitudeTakeoff location and geometric altitude
TimeTime markTime mark
Emergency statusEmergency status indicationNot treated as an equivalent field

This table summarizes the description in the FAA AIM. It is not a universal data specification. If you display the control station and the takeoff point under one label such as "operator position", the meaning gets mixed up, so keep them apart.

Source: FAA AIM | Airspace Access for UAS
03

Tag every received value with its source and freshness

In a product, store the sender's timestamp and the receiver's timestamp separately, along with the receiver, the scheme, and what the position and altitude values actually mean. A position from a few seconds ago is not the current position, and you should expect the receiver's clock to drift too.

{
  "source_kind": "rid_broadcast",
  "scheme": "US_STANDARD_EXAMPLE",
  "subject_id": "example_id",
  "emitted_at": null,
  "received_at": "2026-09-30T00:00:00Z",
  "position": {"lat": null, "lon": null},
  "altitude": {"value": null, "reference": "unknown"},
  "ground_position_kind": "control_station",
  "authentication_state": "not_evaluated"
}

This is a proposed internal normalized model, not a replacement for any actual transmission specification. Keep missing values as null rather than 0, and never silently mix in an altitude you could not convert.

04

What you must not infer from a broadcast

  • Receiving a message does not mean its authenticity has been verified.
  • Receiving nothing is not evidence that no aircraft is nearby.
  • Do not design a system that publicly exposes an owner's name or similar details from an identifier alone.
  • Do not confuse Remote ID with control commands to the aircraft or with permission to use airspace.

Limit retention periods and visibility to what the purpose requires. A map anyone can view and a screen used by the person responsible for operations do not need to show the same personal information.

DEFINITION OF DONE

Before you ship, check these.

  • Takeoff location and control station location are displayed as distinct things.
  • The last received time and any loss of freshness are visible to the user.
  • Unknown schemes and missing fields are never filled in with values from another scheme.

Design checkpoints for spec reviews and acceptance testing.

Check the sources

Explanations of rules and definitions draw on the references below. The screens, data models, and definition of done are our own design proposals.

Sources checked on September 30, 2026. For your specific case, please confirm with the latest official information.