Over the past few weeks I’ve read numerous articles and posts by industry representatives and journalists commenting on the recent Notice of Proposed Rule Making (NPRM) for the draft Remote ID regulation from the FAA – I feel compelled to share my thoughts. My perspective is based on my involvement in this space since 2015, having come from a communications and aviation background, and intimately involved in ASTM International standards for Remote ID and while leading its UAS Traffic Management (UTM) working group.
Regrettably there are few posts that remain objective, with most promoting an approach that furthers their own business interests. Equally disheartening is the limited acknowledgment of ongoing work with industry led consensus standards, research, demonstrations and evaluations over the past few years. I’d like to speak as somebody that wishes to advance the industry and not just my own business.
Even though the RID NPRM is imperfect, it still provides a starting point. We need to pragmatically evaluate its intended security and safety concerns. I firmly believe there is no single magic bullet for Remote Identification that meets every requirement, nor should we expect the first draft of the regulation to provide that bullet.
A couple of things to bear in mind as you read this article. There are some areas I’m not addressing in this article like the commercial implications and detailed analysis about impacts on recreational users. There is already sufficient material published for those topics, so let me begin by laying a foundation about remote ID.
Remote ID Basics
Remote ID allows governmental and civil identification of UAS for safety, security, and compliance purposes. The objective is to increase UAS Remote Pilot accountability by removing anonymity while preserving operational privacy for remote pilots, businesses, and their customers.
In Europe, Remote Identification is a component of “Electronic Conspicuity.” Electronic Conspicuity (EC) is an umbrella term for range of technologies that in their most basic form, transmit the position of the host aircraft to other airspace users operating compatible equipment. More advanced devices can transmit and receive the drone’s position, displaying and alerting pilots to air traffic conflicts with compatible EC devices. EC devices modify the traditional aviation method for pilots to see and avoid other aircraft, into be seen and avoid.
In the United States, the FAA defines Remote ID as the ability of a UAS in flight to provide identification and location information that other parties can receive. It also establishes the foundation for information sharing for future operational concepts such as beyond visual line of site (BVLOS) operations and addresses safety and security concerns which will be become more significant when expanded UAS operations become a reality.
Before we get into all these details let’s step back and summarize the Remote ID NPRM.
The NPRM primarily focuses at providing a new capability for law enforcement. This makes sense, because remote identification is not really necessary for cooperative, or “good actors.” However, it does provide law enforcement a tool to ID the drone and locate its operator. The NPRM does not impact drones weighing less than 0.55 pounds.
The draft rule does affect drone manufacturers that will need to add Remote ID hardware to support this new capability, likely resulting in increased costs and therefore opposed.
There are two kinds of remote identification mechanisms referenced in the NPRM, Network and Broadcast. It’s important to understand the key distinction between these two options.
Broadcast Remote ID is based on the transmission of radio signals directly from an airborne UAS to ground receivers in the UAS’s vicinity. Network Remote ID is based on communication via the internet from a Remote ID service provider that interfaces with the UAS, or with other sources in the case of Non-Equipped Network Participants. Basically, the drone is communicating with something that provides remote identification information to the internet.
Going a little deeper, the NPRM requires a specialized wireless broadcast or network data exchange containing information message elements that require:
- The identity of the UAS consisting of one of the following:
- The serial number assigned to the unmanned aircraft by the producer or,
- Session ID assigned by a Remote ID USS.
- An indication of the latitude and longitude of the control station and unmanned aircraft.
- An indication of the barometric pressure altitude of the control station and unmanned aircraft.
- A Coordinated Universal Time (UTC) time mark.
- An indication of the emergency status of the UAS, which could include lost-link or downed aircraft.
Additionally, the NPRM also states, “..the FAA anticipates that the message elements related to any standard remote identification UAS or limited remote identification UAS are publicly available information and may be accessed by any person able to receive a broadcast or who has access to a Remote ID USS.”
This public access is similar to the FAA’s recent initiative called Low Altitude Authorization and Notification Capability (LAANC). While some of the data is publicly available, there are some elements that are not shared to ensure some level of privacy.
The NPRM states three different categories or deployment classes: Standard, Limited, and Without. In the first two cases it is expected that both the drone and controller locations will be shared as part of the Remote ID capability. It is important to understand the differences between the three classes.
Standard Remote Identification UAS
In this case the drone or ground control station (GCS) transmits remote ID information to the network via a new concept called Remote ID USS provider. If no network is available, the drone needs to be capable of broadcasting information using its onboard Bluetooth or Wi-Fi module.
There are no operating restrictions so these drones could fly visual line of sight (VLOS) or beyond visual line of sight (BVLOS).
Limited Remote Identification UAS
In this case the drones are assumed to be operating visual line of site (VLOS) up to 400 feet from the controller. The assumption is that the drone or the GCS can transmit the Remote ID information over the Internet to a Remote ID USS provider. However, there is no requirement to support Broadcast capability in case the network is unavailable. Hence, there is no need for any specific drone manufacturer equipment or retrofitted hardware on the drone. This means that you can fly in this category only when you have a network connection, which might be very limiting and there are plenty of areas in US where we will not have any cellular network coverage.
UAS without Remote Identification
The last class are those UAS without any means of remote identification capability. All recreational users are in this category. In this case, the users are restricted to fly in FAA recognized identification areas (FRIA) and they must just operate in those predefined areas similar to an accredited RC field for community club users. There are additional nuances in this category that would benefit from more discussion beyond the scope of this article.
Self-Test – No Compliance No Takeoff
One of the challenging requirements in the NPRM is the self-test capability. A drone that is not equipped with a functioning Remote ID capability will not be permitted to take off. There is an additional requirement that the RID capability should be tamper resistant, resulting in deeper integration with the drone manufacturer hardware.
Under this NPRM, flying a drone is not as simple as buying it and launching into the air. This draft rule will require the drone to be configured with a special software and hardware before the will be compliant to fly.
I agree with the analysis and summary provided by retired Major General James Poss, wrote in his post on Inside Unmanned Systems.
“Manufacturers must make RID integral to the drone’s flight system. If the RID fails during the drone’s start-up check, the unmanned aerial vehicle (UAV) won’t take off. Manufacturers must also make RID “tamper resistant” and provide cybersecurity to stop unsophisticated operators from changing their RID settings. Big battle here also—manufacturers had wanted to make RID compliance solely the responsibility of the remote pilot and not themselves. That said, this mandate might change the drone market profoundly. DJI definitely has the cash to comply and provide the paperwork saying they comply because they make thousands of drones. Compliance paperwork alone could cost tens of thousands of dollars for each type of drone manufactured. Can Hollywood camera drone companies afford that when making a dozen or so drones for a particular movie camera?
A good compromise is to certify RID modules separately from the unmanned aircraft. That way, a handful of secure RID module manufacturers can go through the pain of compliance and UAV would be compliant with the RID module on board”.
Law Enforcement Perspective
Chris Korody from Drone Business Center has done excellent job capturing the Law Enforcement perspective in his writeups. The key observation is there’s more work required to make the NPRM useful for Law Enforcement since the whole aspect of integration into the current operational workflow has been overlooked. Below are some of the key highlights from Chris’s writeup
“The NPRM leaves the LEO holding up their cell phone with very little of the information they are used to having. Today, when an officer gets out of their patrol car, he or she has already run the plate and the registered owner. This is a time-tested approach for ensuring officer safety.
Yet there is nothing in the NPRM about how RID data will be integrated with the rest of the data that LE routinely uses. This is a critical point because LEOs are trained to use biographical information about the person they have in front of them. And because things happen fast, their safety depends on having it available in real-time.
Each query requires personally identifiable information (PII) such as date of birth (DOB) and/or Social Security Number (SSN). Information that the proposed S# database does not collect. Nor does the current pilot license program.
No one is saying it, but RID will be a whole new database that will have to be built, managed, maintained, updated, supported, routinely audited and paid for. As best as I can tell from the NPRM, the FAA seems to expect the RID USS to foot the bill.
This database will also have to be integrated with the pilot license database. Remember the analogy – vehicle plate, driver’s license.
From the LE perspective, the most useful information that the FAA has is the data used by TSA. Ideally, when the knowledge test is finally published, the recreational pilot’s license database will be integrated with Part 107.
And lest we think the problem is solved just by recognizing it, another major hurdle exists – access to the information. For any organization to get access to the FBI’s NCIC information, they must be able to adhere to CJIS compliance policies and regulations – which are stringent and burdensome, as well as NLETS.”
Where are we with Standards?
ASTM International recently published F3411 – 19 (Standard Specification for Remote ID and Tracking) which covers the performance requirements for remote identification of UAS. Here are the highlights of the standard we worked on in conjunction with numerous industry partners, government and academia. You’ll see many similarities to the NPRM.
Courtesy: ASTM International
Broadcast Remote ID
Broadcast Remote ID equipment on participating UAS requires equipment to continuously transmit Remote ID data using one of the transmit protocols for Bluetooth or Wi-Fi. It’s possible that additional transmit protocols may be added in the future as warranted by available technology. The initial technologies were selected for compatibility with commonly carried hand-held mobile devices that have their own receiver antenna, like cell phones. However, equipment to receive the broadcast data is not part of the standard. Other implementations, such as receivers not integrated with hand-held devices, are possible.
Both Bluetooth and Wi-Fi continuously broadcast messages to advertise the presence of the associated device. These advertisements normally allow other devices to discover and establish connections with the associated device, but the advertisements themselves can carry a payload. These advertisements contain the broadcast Remote ID data. A hand-held device does not need to establish a connection to receive Remote ID data, instead it need only receive and process the advertisements.
Broadcast Remote ID can be used anywhere but it is critical in areas where network coverage is unreliable, disrupted, or not available.
The standard also includes a range of options for authentication of broadcast data. Some of those options include digital signatures over portions or all of the Remote ID message set. While the standard does not specify the encoding format associated with signatures, it does include a standard API that would be used by a receiver of the broadcast data (e.g., an app on a smartphone) to contact a verifier with the signature data for a broadcast to determine message validity.
Network Based Remote ID
Network Remote ID can be used when both UAS operations and end users of Remote ID display applications access the internet, typically via cellular network. Cellular coverage tends to be higher in urban areas.
The nominal case supports Networked UAS (i.e., UAS that remain in contact with a Remote ID Service Provider during flight), although the standard accommodates intermittent loss of network connectivity.
Support for Recreational Users and Hobbyists
Network Remote ID also includes provisions for participation in Remote ID by non-equipped UAS (i.e., UAS that are neither broadcast capable nor equipped to communicate with a Remote ID Service Provider during flight, such as most radio-controlled model aircraft). These non-equipped network participants report their operations (e.g., aircraft ID, location in terms of a volume of airspace, operating times) in advance. The information is used to create a position report for use by Remote ID display applications where the uncertainty of the position report is defined by the airspace volume for the operation. The current telemetry of the aircraft within the volume is not known and cannot be displayed to a Remote ID end user, but the display application can display the volume and provide the identity of the UAS.
Did you forget about Security and Cyber Threats?
A common theme between drones and other Internet of Things (IoT) enabled services is that they will all leverage and rely on commercial wireless broadband solutions for either command and control (C2) or real time sensor data management and transfer. These next generation networks will have to support a highly diverse range of new applications, user requirements, and connected devices, sensors, robotics, mission critical wireless communication, and automated manned and unmanned vehicle systems.
The only way all this can become a reality is by continuing to evolve existing wireless technologies, cellular and non-cellular and also work on new licensed or unlicensed radio access technologies. These next generation networks will be heterogeneous networks using a myriad of wireless technologies.
Even though these technologies will evolve to support the throughput and latency requirements for safe drone operations, one of the key challenges we will face is agile, reliable, safe and secure support for different use cases and user requirements. We as the industry need to consider all key technical areas and explore ways of integrating “security by design” principles into commercial drone ecosystem development.
We will need new service delivery models that involve new actors in the ecosystem. Virtualization and cloud infrastructures will be leveraged to provide flexibility, scalability and the ability to deliver richer services quickly. Data access wireless networks will need to provide users and other third parties access via APIs to for granular control and security of the services. This paradigm shift will enable innovative capabilities but also create complex security challenges.
Communication between various nodes for a Remote ID solution will need to be encrypted using an industry-standard encryption mechanism with a minimum encryption strength of 128 bits. This requirement is intended to address both integrity and confidentiality of Remote ID data in transit. TLS is an example of an industry-standard authenticated encryption mechanism.
The table below outlines the current state of comparison between the NPRM, ASTM standards and field demonstrations.
What is practical and What is really needed?
In May of 2019, ANRA was the first UAS Service Supplier (USS) to use the proposed at that time ASTM standard WK65041 (Remote ID and Tracking) for both broadcast and network methods and conduct real-world operational evaluations along with law enforcement officials at the FAA test site in New York.
Part of the assessment included multiple USS at the test site using UAS traffic management (UTM) software to manage drone operations while also serving as the network RID service and display provider.
Additionally, network publishing was evaluated to visualize data within an internet-based service area. In this case, the Display App made a request to network RID display provider which had aggregated RID data for all flights in the area managed by network RID service providers and provided the aggregated data back to the Display App.
While I’m proud our company achieved this milestone, my true motivation was to prove the standards (draft at the time) were realistic and could be operational assessed. We did, it worked, and we learned some lessons – most importantly from law enforcement.
We knew we needed to conduct more testing in a collaborative environment, so later in 2019, ANRA Technologies, along with other Industry Partners as well as regulators successfully demonstrated the versatility of ASTM standard. The team of industry players simulated three common scenarios on September 12th 2019 within controlled airspace for San Francisco International Airport and demonstrated the benefits of network based remote ID based on the proposed ASTM standard.
This event was followed by a similar demonstration in Bern, Switzerland on September 16th which included both network and broadcast based Remote ID. This all work happened in collaboration with the Swiss U-Space Implementation (SUSI) team, Swiss Federal Office of Civil Aviation (FOCA), and Skyguide, the Swiss Air Navigation Service Provider.
Even though these tests were successful, there are subtle differences between the NPRM and the standard as captured previously, it still proves that both network and broadcast based remote identification have their place and can meet the requirements outlined in the NPRM with some tweaks and additional security measures put in place to ensure the safety and security of the operators as well as the airspace. We have to keep in mind that a bad actor will fly a drone no matter what and but it’s rules and regulations if too onerous are going to hamper the commercial industry by impacting the good actors.
It is also prudent to allow operators to choose between network and broadcast based remote identification capabilities based on the operational areas as well as the use cases such as VLOS vs BVLOS operations.
The NPRM should be modified to allow message elements to permit both encrypted and not encrypted elements. For example, information such as drone operator location and be only available to specialized apps that have the correct access and privilege to decrypt that information.
This would be on the similar lines like when you get pulled over by a cop and they can run your license plate and get all the details whereas concerned citizen can only see the license plate and not necessarily access all the details associated with the car or its owner.
- FAA NPRM is not all bad it can be used as a great starting point
- Both Network and Broadcast based Remote Id capabilities are required depending on the Use Case.
- Security concerns about disclosing the location of the operator can be mitigated by using encryption mechanisms to ensure that those message elements are only available to authorized users.
- The ASTM standard already supports security an encryption recommendations and methodologies, see “Annex A1 – Broadcast Authentication Verifier Service.”
- FAA should seriously think about eliminating the requirement for having the hardware root of trust it is reasonable to expect a hardware broadcast solution on board the drones but having it enforce no take off would require deep integrations with the OEMs in the hardware which adds cost and complexity which is not desirable.
- Limited Remote Identification UAS needs to support Broadcast Remote ID mechanism as well
- There is a need to integrate the FAA databases with other law enforcement databases.