Submitted by Mark Davis
As you probably know, the FAA has been evaluating the requirement for UAVs to transmit a kind of electronic license plate, or “Remote ID”. The FAA formed an ARC in 2017, which issued its report in September of that year [1].
An NPRM should be out soon, which may shed further light on the requirement. Meanwhile, ASTM F.38 02 will shortly release the first draft of a proposed technical standard [2]. The standard only covers technical methods, and does not propose anything related to rulemaking. However, some points of this standard may be interesting to us hobbyists.
1. The document provides for a Broadcast Remote ID and a Networked Remote ID.
2. The Broadcast method would be Wifi (at 2.4GHz or 5.8GHz), using the NAN protocol, or Bluetooth at 2.4GHz (BLE4 or BLE5 may be used).
3. Networked Remote ID is primarily intended to be a query of local USS entities. A USS is a “”UTM Service Supplier”, which would be a software process supplying Unmanned Traffic Management service in a local area. UTM is not expected to be applicable to hobby flights. However, it has been informally discussed that hobbyist groups (such as the AMA for example) could provide a phone-based app allowing a pilot to manually enter a flight declaration (covering few hundred meters around the pilot) into the Networked Remote ID system, for a UAV that has no Broadcast capability. Also, if you have something like, for example, a Mavic with your phone connected to the controller, and the phone is connected to the internet, a phone app could interface to a source of Networked Remote ID for that vehicle. So there are several ways hobby flights could provide Networked Remote ID, despite not being typical USS-based flights.
4. In addition to Broadcast and Networked Remote ID, the user of Remote ID could get information from other sources. One such source might be a quasi-static map for AMA clubs, for example, which could be argued to reduce or eliminate the need for other means of Remote ID at such sites. These are just ideas under discussion informally – there is no decision or even firm proposal.
5. The format of ID proposed includes much telemetry information, including position and velocity vector. Obviously a bolt-on module would not necessarily have access to that unless it also had its own GPS, or had access to this telemetry from the UAV. A regulator could adopt the standard without requiring these fields, but just FYI, they are there.
So how will this affect our club? Really, it is too soon to tell. Various potential criteria for ruling whether a vehicle is subject to these requirements are discussed in the ARC report, and include among many other things, whether or not the vehicle is capable of Beyond Visual Line of Sight (BVLOS) flight, even if it is not being flown BVLOS at the moment.
For those with DJI or other common drones with video backhaul, these generally are based on a Wifi chip, and so could be retrofitted to broadcast the required ID by interleaving it with the video backhaul. The ID information is very low rate compare to video, so the difference should be imperceptible. Using this method, Broadcast Remote ID can be added to such vehicles with a software upgrade.
For most of the VLOS flying we do at SEFSD, a static site declaration, or a temporary app-based declaration, might avoid the need to add anything to the model. But again, this is only one possible scenario of many.
For FPV fliers, the situation might be more complex, since these might be deemed technically capable of BVLOS flight even if not used BVLOS at our field. Some transmitters, as I mentioned, can piggyback the Remote ID on the video backhaul stream. But if you have a self-contained FPV system attached to a model, especially if it is not based on a Wifi chip, it is unclear how that might be affected.
Also there is the issue of how ID numbers are determined and managed, and whether they are per model, per pilot, or a mix of these. The ASTM standard has low detail on this point, leaving this issue mostly to regulators. Note that recently ICAO initiated an effort to unify identity and security across all of aviation [3], and this might find its way into Remote ID. The ICAO effort is relatively new, and Remote ID is considered an urgent case, so it remains to be seen if ICAO can provide some function in time to meet the FAA’s initial Remote ID system.
[1] FAA Remote ID ARC Final Report. https://www.faa.gov/regulations_policies/rulemaking/committees/documents/media/UAS%20ID%20ARC%20Final%20Report%20with%20Appendices.pdf
[2] ASTM F.38 02 WK65041. This document is not yet public but is very similar to system described on public website www.opendroneid.org
[3] ICAO/ICANN press release. https://www.icao.int/Newsroom/Pages/ICAO-ICANN-sign-new-agreement-to-guide-progress-on-proposed-aviation-trust-framework-for-digital-environments.aspx
