AIAA SciTech Forum 

7-11 January 2019, San Diego, California 

AIAA Scitech 2019 Forum

Remote ID for Rapid Assessment of Flight and Vehicle 

Information

Abraham K.Ishihara∗

Stinger Ghaffarian Technologies, Inc, Moffett Field, CA, 94305

Joseph Rios†

NASA, Moffett Field, CA, 94305

Priya Venkatesan‡

Stinger GhaffarianTechnologies, Inc, Moffett Field, CA, 94305

The ability to rapidly identify UASinthe fieldhas emergedas a criticalneedfor the integration of small UASs into the national airspace and counter-uas operations. This paper proposes 

an architecture for rapid retrieval of UAS information leveraging NASA’s current Unmanned 

Aircraft System (UAS) Traffic Management (UTM) system. The proposed architecture utilizes UTM components: FIMS (Flight Information Management System), USS (UAS Service 

Supplier), and vehicle registration and model database in order to provide assessment of the 

UAS reported in the field including the ability to distinguish between participating and nonparticipating UTM actors. Detailed system descriptions are provided and preliminary results 

from field tests conducted during UTM TCL (Technical Capability Level) 3 are discussed. It 

is found that 94% of the remote ID look-ups resulted in positive identification. The average 

time of a look-up is found to be 1.2 seconds. Negative identification cases are examined and 

recommendations on the next steps to advance UAS remote ID areprovided.

I. Introduction

By 2024,thecommercial drone marketis estimatedto reach17billion US dollars [1]. Muchofthis growthcanbe 

attributed to significant venture capital investment over the last several years coupled with more capable UAS platforms 

targeting information and value-add services. Agriculture applications, for example, continue to drive market demand in 

theareas of crop monitoring, spraying, and soil andcrophealth. UAS packagedelivery is projected to saveup to 50 

billion US dollars as a result of 50 million drone deliveries per day [2].

Withthepotentialofmillionsofdronessimultaneouslyaccessingtheairspaceinthenearfuture,thereissignificant 

concern regarding the ability to distinguish participating from non-participating actors in the Unmanned Aircraft System 

(UAS) Traffic Management (UTM) system. There have been increasing reports of criminals and organized crime 

leveragingadvancements in drone technologies inorder to surveil targets [3], deliver contraband to prison inmates 

[4], and smuggle narcotics across borders [5]. Recently in Staten Island, NY, a hobbyist unwittingly flew a UAS into 

airspacewhereaBlackhawkUH-60M assignedtothe82ndAirborne Divisionwas located[6]. Thequadrotorcollided 

with the Blackhawk causing damage to the main rotor blade.

Inresponsetotheseevents, Counter-UASor C-UAShas emergedas acritical needinboththepublicandprivate 

sectors [7]. Although legal challenges abound [8], there has been recent venture capital investment in companies 

such as Citadel Defense Co. and Securus Technologies [9]. Over 230 counter-UAS products currently exist or are 

underdevelopmentworldwidespanningarangeoftechnologiesincludingradar,activeandpassiveoptics,acoustics, 

electromagnetic emissions, and magnetic fielddetection. Whilecounter-UAStechnologies continueto makeinroads 

withrespecttodetectionofvehiclesinclutteredenvironments (forexample,anurbansetting),rapidUASidentification 

andtheability todistinguishparticipatingfrom non-participatingactors intheUTM system remainsasignificant 

challenge. For comprehensive, end-to-end counter-UAS solutions, four components are required (collectively referred 

tohereinasDIADanddepictedinFig.1): (1)DetectUAS;(2)IdentifyUAS;(3)Assess safetyandriskmetrics;(4) 

Defeat UAS (disable or thwart mission objectives).

∗NASA Ames Research Center, Moffett Field, CA., AIAA Member

†NASA Ames Research Center, Moffett Field, CA., AIAA Senior Member

Downloaded by NASA AMES RESEARCH CENTER on January 10, 2019 | http://arc.aiaa.org | DOI: 10.2514/6.2019-2077
10.2514/6.2019-2077

Copyright © 2019 by the American Institute of Aeronautics and Astronautics, Inc. All rights reserved.
2

TheDetectblock referstoprocessbywhichacollectionofphenomenologicaldataisacquiredbyoneormore 

sensors (activeorpassive)andprocessedviasensorfusionorothertechniquesinordertolocateandtrackapotential 

droneasittraversesitsflightpath.TheblocklabeledIdentify,whichistheprimaryfocusofthispaper,constitutes 

thepointintheflow whereinformationisgleanedfromthedetectblockandprovides registrationand/orposition 

information to a public safety USS (discussed below) to ‘look-up’ or acquire corresponding information in the UTM 

system. The information provided by the UTM system could include vehicle performance specifications, past flight data 

including detailed trajectory and planning information, current and future flight plan information and owner contact 

details.

Historicalinformationcouldbeuseful inordertopredictanomalousbehavior. Whileitisnotknownthetypeof 

traffic patterns that mayemerge∗ as theUTMsystem unfolds, machinelearningtechniques couldbeusedtoidentifyin 

near real-time unusual flight patterns arising from witting or unwitting actors. For example, package delivery trajectories 

may followrelatively predictablepatterns givenasetofknownparameters suchas vehicletype,timeof year,location, 

weather,andeconomicmetrics.Atthesametime,deliveryroutesmaybelocatednearassetsvulnerabletoapotential 

UAS threat that would require rapid intervention to defend.

Assessment,thethirdblock, comprises thegarneringand processingof all relevantinformationfrom thedetect 

andidentify blocks as well as additional information regardingtheassettobeprotected. Risk metrics are evaluated 

andadecisionismadeastohowtodefeatthepotentialthreat,ifany.This leads totheDefeatblockwherealistof 

counter-UASoptionsaremadeavailable.Itisquitepossiblethatonesuchoptioncouldbesimplymakingcontact 

withanunwittingoperator bringingattentiontotheperceivedthreat. Further discussionof detect, assess, anddefeat 

(including the associatedlegal challenges) is beyondthepresent scope.

Fig. 1 Detect Identify Assess Defeat (DIAD)

Theprimary contributionsofthispaperareas follows:(1)initialarchitectureforremoteIDinthecontextofthe 

UTM system, (2) descriptionofthepreliminary prototype deployed, and (3) initial assessment ofthesystem usedin 

UTM TCL3fieldtests conducted February throughJune2018. Theremainder ofthispaperis as follows:InSectionII,

abriefdescriptionoftheproblemandrelevantbackgroundinformationontheNASAUTMprojectispresented.In 

SectionIII,theinitialremoteIDarchitectureandscenariosarediscussed.ThemainresultsarepresentedinSectionIV

and summary in SectionV.

Probability of

Detection

UAS Pos./Vel. 

Estimate Tracking

UVIN

Risk Metrics

Safety Metrics 

Context 

Assessments

Detect

t

Identify

y

Assess

s

Defeat

t

USS

USS

Disc over y

USS FIMS

Public

Safety Vehic le

USS Reg/DB USS

Vehicle Type

Owner/Operator 

Contact Current 

Operation Future

Operations

Counter-UAS

Action

Jamming 

GPS

Spoofing

Net

Downloaded by NASA AMES RESEARCH CENTER on January 10, 2019 | http://arc.aiaa.org | DOI: 10.2514/6.2019-2077
3

II. Background and Previous Results

By2021,thecombinednumber of commercial andhobbyist UASscouldreach6 million[10]. Thescale,type, risk, 

andincreasingcomplexityofthepotentialUASoperationswouldlikelyoverwhelmtheexistingAirTrafficManagement 

(ATM) system. To address this challenge, NASA developed an initial concept termed Unmanned Aircraft System (UAS) 

Traffic Management(UTM)in2015[11]whichprovidedaresearchplatform totestandintegrateinnovativestrategies

∗Traffic patterns will likely be driven by market need and regulatory requirements which are currently evolving.
4

andsolutions. Incollaboration withthe FAA, UTM hasevolvedandconsistsofasuiteof services [12]toaidthe 

managementofcomplexUASoperations inuncontrolled(ClassG) airspace.It establishes safe,efficient, andsecure 

mechanisms for UAS operators toshare flight operation intent and receive common situational awareness. The elements 

of UTM consistof: (1) USS(UASService Supplier) whichis theentity that receives flightoperations from aUAS 

operator and provides support for deconfliction, conformance monitoring, and communication with FIMS; (2) FIMS 

(FlightInformationManagementSystem)whichisthecentralizedgatewayofinformationbetweentheUSSsandFAA;

(3) SDSP (Supplementary Data Service Supplier) whichis the entity that provides data or services to USSs or UAS 

operators.FurtherdescriptionoftheUTMsystemanditsinterplaybetweenATCservicescanbefoundin[12].

In2018, NASA worked withsix test sites to demonstrate UTM Technical Capability Level (TCL) 3 whichexplored 

thefollowingelements: (1) Moderate Population; (2) Moderate Traffic Density; (3) Suburban Applications;(4) Mixed 

Operations;(5)VehicletoVehicleCommunication;(6)PublicSafetyOperations. Thetestsites werelocatedinAlaska, 

North Dakota, Nevada, New York, Texas, and Virginia.

In support of the UTM project the Vehicle Registration and Model Database (VRMD) was created to enable the 

storageand retrieval of detailedvehicle-specific information for use intrajectory performanceanalysis andpotential 

counter-UASapplications. Thetotal numberofmanufacturers thatcurrentlyexists inthedatabaseis168andthetotal 

numberofdistinctvehicles types(availabletoselectaspartoftheregistrationprocess)is474. This includesboth 

publicly availablevehicles andcustom vehicles (vehicles built or customizedforthis test or areotherwisenot publicly 

available). Asanexample,Fig. 2.depicts thebreakdownforvehicleclass,MTOW(Maximum Take-OffWeight), 

maximum velocity, and maximum endurance. In the histogram subplots, UAS categories defined in [13] are also shown. 

Eachvehicletypehas associated withit over thirty model properties whichcanbequeriedinreal-timeviathe VRMD 

API.

AspartofUTMTCL3fieldtest(across thesix testsites),approximately124vehicles registeredviatheNASA 

VRMD system. The registered vehicles include vehicles that were reserved for backup and vehicles that failed and 

werereplacedduringthecourseofpreparationforthetestingevents. Sixteenofthevehicleswereusedforsimulation. 

Registration was facilitated by a web-portal madepublicly availableand partners from the test sites were providedaccess 

through NASA’saccess andidentity control system. Prior toperformingany testing, all vehicles that wereanticipated 

to fly had to register and provide detailed vehicle model specifications. The process of registeringa vehicle involves 

selectingthevehicletypefromavehiclelist(containingthe474vehicletypes)andenteringadditional vehicleinstance 

(therealizationof avehicletype) information. Uponits creation,VRMD issues auniversally uniqueidentifier (version 

4 UUID) termed UTM Vehicle Identification Number (UVIN).

III. UTM Remote ID System

A. Architecture

The remote ID architecture that was implemented in UTM TCL3is shown in Fig. 3. Theprimary objective of the 

remoteIDconceptistotestandvalidatealistofscenarioswhereidentificationofavehicleisrequiredbyanauthorized 

entityworkingneartheoperation.Anexampleofthisscenarioiswhenapoliceofficerobserves aUASflyingoverhead 

and requires thefollowing:

1) Identification of the UAS owner and contact

2) Vehicleproperties including class (fixed-wing, quad, etc.)

3) Current flight plan, vehicle speed and heading, and future operations

4) UTM state of the corresponding flight plan, e.g. ROGUE, NON-CONFORMING, etc.

Given the aboveinformation, the officer may assess the situation and choose the appropriate counter-UAS measure. It is 

Downloaded by NASA AMES RESEARCH CENTER on January 10, 2019 | http://arc.aiaa.org | DOI: 10.2514/6.2019-2077
5

importanttonotethatacounter-measure might beas simpleas contactingtheowner/operator andconveyingthatthe 

vehicleshouldnotbethere.Iftheowner/operator,‘turnsthevehiclearound’ thenthatmissionwaseffectively‘defeated’

from the public safety officer’s point of view.

Three test sites conducted one or more of the test scenarios discussed below. Each test scenario involves (1) a 

UAS to be remotely identified and zero or more UASs nearby that may also be simultaneously broadcasting drone 

identificationinformation,(2)apublicsafety USS,(3)apublicsafety user whoperforms theremoteUASidentification 

andvalidatestheresultsofthetests,and(4)aUSSthatreceives theoriginalflightplanfortheUAStobeidentified(note 

that certaintests whichdonotincludevehicleregistrationand/orproperflightplansubmissiontoa USSexcludedthis 

component). A public safety USS is a USS that has been grantedby FIMS the PUBLIC_SAFETY role (indicated bya 

dashedarrowinFig. 3.). Boundtothis roleareanumberofpublicsafetypermissionsenablingittorequestinformation
6

vel.<30

30<vel.<60 

60<vel.<87

Hybrid 

(9/2%)

MTOW [lb]

150

Helicopter 

(57/12%)

100

Mulit-Rotor 50

(139/29%)

Fixed Wing

(269/57%)

0

Maximum Velocity [kts] Maximum Endurance [min]

100 80

90

70

80

60

70

50 60

50 40

40 30

30

20

20

10 10

0 0

Fig. 2 UTM Vehicle Registration and Model Database (VRMD) Summary. At the time of this writing, the 

database contains 474distinct vehicle types that operators canselect from during the registrationprocess. Each 

vehicle typehas associated with it over thirty modelproperties whichcanbequeriedinreal-time via the VRMD 

API.

from otherUSSsandquery theVRMD toobtaindetailedvehicle-specific information. Apublic safety userisaperson 

whois registered withapublic safety USS andhas relevant credentials/authorizationtocommunicate withit usinga 

suitabledevice(tablet,phone,etc)overthepublicinternet.Testsitesprovidedtheappropriatehardwareandsoftware 

forboththe UAStobeidentifiedandthepublic safetyuser(thesensorsaredescribedin SectionIV).

UASremoteIDisamulti-stepprocesswhichwenowdescribe.Thereareeightstepswhichcorrespondtothelabels 

in Fig. 3.

Step1: A UASisdetectedbyoneor moresensors correspondingtothe Detectblock in Fig.1. This includes 

anyadditional informationsuchas thebroadcastofpositionand UVIN (registration)data.

Step 2: After acquiring the information, the Vehicle Identification Device (VID)†transmits an HTTP GET 

request to a public safety USS.

Step3: If the information received contains a UVIN, the public safety USS requests information from the UTM 

Vehicle Registry and Model Database (VRMD). The public safety USS has specialized roles that enable 

ittoaccess requiredvehicleinformationincludingmake, model,owner contactinformation,andother 

properties.

Step4: Theresponsefrom VRMD is returnedindicating whether thevehiclehasbeenfoundornot.Iffound, 

additional vehicle-specific information isprovided.

Step 5: The public safety USS sends a request to the USS Discovery Service. The USS Discovery Service

MTOW<4.4 

4.4<MTOW<19.8

19.8<MTOW<55

endur.<15

15<endur.<30 

30<endur.<60

Downloaded by NASA AMES RESEARCH CENTER on January 10, 2019 | http://arc.aiaa.org | DOI: 10.2514/6.2019-2077
7

†

In this paper, the device that detects the vehicle and transmits the information to the public safety USS is referred to as the VID. However, in 

general this could be any system and need not be a portable device.
8

Fig. 3 UTM Remote ID Flow Diagram

receivestherequestandretrievesthe‘owning’USSinstance(highlightedinredinFig. 3).Thisrequest 

isbasedontheUVINand/orreported4dpositionestimateoftheUASasdeterminedbytheVID(Detect 

block in Fig. 1). Anillustrationofthis process for twooverlapping USS instances is shown on theleft 

sideofFig.4.AUSSinstanceisaspecificrealizationdefinedbyaboundingrectangle.AUSSmay 

instantiate zero or more USS instances tosupportits missions.

Step6: Thepublic safetyUSSthenperformsaninquiry tothe‘owning’USStoretrieveadditional information 

suchas thecurrentflight operationsubmitted(GUFI), current UTM state, positionandvelocity ofthe 

UAS(ifidentified),andfutureflightoperations. Dependingonthescenario,the‘owning’USSinstance 

many needtobeselectedfrom alistof candidate USSinstances. This is illustratedontherightsideof 

Fig. 4. UTM operation states includestates such as ACTIVE, ROGUE, NON-CONFORMING, AND 

CLOSED.

Step7: Thepublic safetyUSSassemblesallrelevantpiecesofinformationandperformsDroneObservation 

Resolution(DOR)-aprocesswhereitprovidesits ‘best’estimateoftheobservedvehicleanditsstatus 

withrespecttothe UTM ecosystem. This couldbechallengingwhenthereexists multipleoverlapping 

USSs and multipleoperations overlappingintimeandspace. Inaddition, positionupdates andother 

messages could be used to fine-tune the estimate.

Step 8: The DOR is assembled and returned to the VID for display to the public safety user.

B. Remote ID TestScenarios

Having described the general flow ofinformation, the remote ID test scenarios that were considered‡ as part of 

UTM TCL3testingarenowdiscussed. As indicatedabove,not all paths in Fig. 3. aretraversedsincesomescenarios 

donot,forexample,involvethebroadcastofaUVIN tothe VID.Whenthepositionsofthevehicleor theVID are 

referred to WGS-84 [14] isassumed.

1

Vehicle ID 

Device 

(VID)

US

FIM S

S

USS

Discover

y

REST 

API

6 US

2

5 S

8

7

Public 

Safety 

USS

3

4

Vehicle

Registration US

S

Downloaded by NASA AMES RESEARCH CENTER on January 10, 2019 | http://arc.aiaa.org | DOI: 10.2514/6.2019-2077
9

Scenario 1: Valid UVIN; flight plan & observation consistent

The UAS transmits a valid UVIN to the VID and its coordinates are also estimated by the VID§. The

‡Not all of these scenarios were fully field tested.

§

In the event that the VID is unable to provide an estimate, the position of the VID itself could be used as an estimate provided the detection

range is small relative to the UAS movement capabilities.
10

Fig. 4 [Left]: Overlapping USS instances. The UAS location transmitted by the VID is located in a region of 

intersection between two USS instances. Both USS instance IDs are returned to the public safety USS. [Right]: 

VID position reported contained in operation (identified by a GUFI) associated with USS instance B.

public safety USS receives the UVIN and the vehicle coordinates. DOR determines

ï UVIN is valid

ï Flight plan submitted is consistent with the observation

Scenario 2: Valid UVIN; flight plan & observation inconsistent

The UAStransmits avalid UVIN totheVID andits coordinates arealsoestimatedby theVID. The 

public safety USS receives the UVIN andvehiclecoordinates. DOR determines:

ï UVIN is valid

ï Flightplansubmittedis inconsistent withtheobservation(forexample,arogueoperation)

Scenario 3: Valid UVIN; no flight plan submitted

TheUAStransmitsvalidUVINtotheVIDanditscoordinatesarealsoestimatedbytheVID.The 

public safety USS receives the UVIN andvehiclecoordinates. DOR determines

ï UVIN is valid

ï There isno flightplansubmitted by the operatorof thevehicle withinatimerange that 

coincides with the observationtime

Scenario 4: Unregistered (or expired) UVIN

TheUAStransmitsa UVIN totheVIDandits coordinates arealsoestimatedbytheVID.Thepublic 

safety USS receives the UVIN andvehiclecoordinates. DOR determines

ï Theredoesnotexistanentry inthevehicleregistrationdatabaseor thatthe UVIN hasexpired

Scenario 5: No transmission; valid flight plan

The UAS does nottransmit a UVIN to the VID, however,its coordinates are estimated by the VID. 

Thepublic safety USS receives thevehiclecoordinates. DOR determines

ï Thereexistsatleastoneflightplanthatis consistent withthetransmittedcoordinates

ï Therearevalid UVINsofthevehicle(s) whoseflightplan(s) is (are) consistent withthe 

observation and notes lack of transmission

Scenario 6: No transmission; no flight plan

The UAS does nottransmit a UVIN to the VID, however,its coordinates are estimated by the VID. 

Thepublic safety USS receives thevehiclecoordinates. DOR determines

ï Theredoesnotexistaflightplanthatis consistent withthetransmittedcoordinates

ï Determines this is a non-participating vehicle

IV. Main Results

ε(d)

GUF

I

d(t) USS 

B

USS 

A

ε(d)

d(t) USS 

B

Downloaded by NASA AMES RESEARCH CENTER on January 10, 2019 | http://arc.aiaa.org | DOI: 10.2514/6.2019-2077
11

Inthis section,theresults from theremoteID fieldtests whichwereperformedas part ofthe UTM TCL3campaign 

arenowdiscussed. RemoteID tests wereperformedatthe NorthDakota, NewYork,andVirginiatest sites. Datafrom 

theNYandNDtestsites arepresentedbelowandincludeScenarios1and5describedabove.Fig. 5. summarizes the 

vehicles thatparticipated,including several performancespecifications.
12

Vehicle TestSiteManufacture

r

Model MTOW Endurance Range Cruise

ND Altavian Nova 14.8 [lb] 80 [min] 1.1 

[mi]

30 

[kts]

ND Sharper A6 39.7 [lb] 75 [min] 1.1 

[mi]

30 

[kts]

ND

Pulse 

Aerospace Vapor 55 55 [lb] 60 [min] 4.9 

[mi]

21.7

[kts]

NY DJI S1000 24 [lb] 12 [min] 3.6 

[mi]

9.72

[kts]

NY DJI M100 7.9 [lb] 10 [min] 2.5 

[mi]

9.72

[kts]

Fig. 5 Remote ID: Vehicle Specifications. A total of five vehicles took part in remote ID test scenarios during 

the UTM TCL3 field demonstrations (February-June 2018).

NorthDakotaTestSite: AllremoteIDtestsoccurredatCampGraphtonNorthlocatednearDevilsLakeMunicipal 

Airport(KDVL).Eachtestincludedthreevehiclessimultaneously operatingnear oneanother. Twovehicles (Altavian 

NovaF700and SharperShapeA6) always flew as ‘participating’ vehicles,thatis,they wereregisteredandfiledflight 

plans witha USS. Onevehicle(Vapor) servedas the‘non-participating’or intruder vehicle.

Tworemote ID systems were examined, bothusing μAvionix ADS-B technology. The first was a passivesystem 

wherelocal areareceivers weredeployedandcontinually monitoredforUVIN andpositioninformationtransmission. 

This system could be deployed to locations wherepersistent surveillance and situational awareness is required providing 

anadditional dataandverificationlayer. For example,if avehicleunwittingly didnot properly fileaflight planbut was 

abletotransmititsUVINandpositioninformation,thesystemcoulddeterminethevehicletype,itsproperties,and 

contacttheowner toassess whetherornotthis constitutedabadactor inthesystem.

In the second system, a handheld receiver was developed to providea public safety officer to actively identify a 

vehicle. The receiver hadinternet connectivity and was abletoquery thepublic safety USS once UVIN andposition 

information was received(see Fig. 3). Fig. 6. depicts oneoftheremoteID testflights that occurredon April 17, 2018 

around 14:50 GMT.

NewYorkTestSite: AllremoteID flights wereconductedatthe NY UAStest siteatGriffiss InternationalAirportin 

Rome,NY.Ineachtest,aDJIS1000andM100(seeFig. 5.) equippedwithvarioussensorpackageswereflown.Three 

UAS Remote ID methods were tested: (1) ADS-B (using μAvionix), (2) Secure Integrated C2, and (3) Infrared Light 

Beacon Encoding.

Inthefirst method, μAvionixPing2020ADS-B transceivers wereinstalledandprogrammedtotransmit UVIN and 

position information over 978MHz. Multipleground-based ADS-B receivers received the transmission and a smart 

phoneapplication wasusedby thepublic safetyofficer tointerface withthepublic safety USS.

The second method, termed secure integrated C2, leveraged the Internet Engineering Task Force (IETF) Host 

Downloaded by NASA AMES RESEARCH CENTER on January 10, 2019 | http://arc.aiaa.org | DOI: 10.2514/6.2019-2077
13

IdentificationProtocol(HIP).Aprimaryadvantageof HIPis its separationofidentityandlocationasopposedto 

traditional TCP/IP architectures which combine them based on IP addresses leading to non-verifiable identities subject 

tospoofingandotherformsofattack.Instead,identity isestablishedbasedon2048-bit RSApublic keys.

Inthethirdmethod,infraredlightbeaconswereinstalledoneachUASandwereprogrammedtotransmitUVINdata 

at1Hz. Thepublic safetyofficers usedhandheldIR receivers connectedtoasmart-phoneapplicationthatinterfaced 

withthepublicsafetyUSS.Generally,this technology requiredthepublicsafetyofficers tobeincloserproximity tothe 

UAS being identified (see Table3).
14

Shar

p

N

O

Fig. 6 Remote ID Look-Up Test: The blue trajectory depicts the A6 (participating multi-rotor) simulating a 

scenario of filming a sporting event. Also depicted in blue is its geo-fence. The Vapor (intruder helicopter), 

depicted in red, takes off and breaches the geo-fence of the A6. The public safety officer becomes aware of the 

intruder and uses its VID to identify the intruding vehicle. Two look-ups are shown by the white lines indicating 

thepositions ofbothvehicle andpublic safety officer at the times of look-up. The averagedistance 179.45 [m] and 

time 1.13 [s] are computed over all data from the ND test site. Also shown is the Nova (participating fixed-wing) 

in yellow.

NonParticipating

Vapor 55

Pulse 

Aerospace

UTMParticipating

Intruder 

breaches

A6 geo-fence

A6

Shar er Shape 

UTM-Participating

NOVA F7200

Altavian

Remote ID LookUp

Avg. Dist: 179.45 [m] 

Avg. Time: 1.13 [s]

Top 

View

Public Safety

Officer 

Location

Downloaded by NASA AMES RESEARCH CENTER on January 10, 2019 | http://arc.aiaa.org | DOI: 10.2514/6.2019-2077
15

ADS-B 

(71%)

The primary metrics analyzed included detection and 

look-up latencies as well as the distances from the vehicle 

tothevehicleidentificationdevice(VID) attimes oflookup. RemoteIDdetectionlatencyisdefinedasthetime 

duration(measuredinseconds)fromtheinitial detection 

bytherelevantsensorsuitetoitsacquisitionofaUVIN, 

position,orother informationrequiredforaremoteID 

look-up.InFig. 3.,this is thetimedurationbetweensteps 

1and2. RemoteIDlook-uplatency isdefinedas thetime 

duration(measuredinseconds)from theinitiationofthe

Infrared (5%)

Secure C2 

(24%)

HTTP request by the VID to its corresponding HTTP 

response. InFig. 3.,this is thetimedurationbetween 

steps2and8. A timeoflook-upisdefinedas thetime 

(GMT) that step 2occurs.

Fig. 7 Detection Technology Breakdown

Overall,there wereatotalofthreetechnologiesexaminedin TCL3 RemoteID experiments¶. ADS-Bbased 

technology(usingμAvionixhardware)was testedmostfrequently(generatedthehighestnumberoflookupdata).The 

second was secure C2andthethird was IR-basedtechnology. Fig. 7. depicts this breakdownbasedonthepercentage of 

look-ups by technology.

Atotalof12flights (12distinctGUFIs) wereflownforremoteID (8attheNYtest siteand4atthe ND test site) 

generating a total of 326 look-up data points. Table 1 shows the minimum, maximum, average, and standard deviation of 

thelook-uplatency times forallUTMremoteIDlook-ups.Thelastcolumn,positiveidentificationpercentage,indicates 

the percentage ofthe 326 look-ups that resulted ina positiveidentification of an observed vehicle. A look-upis said 

toresultinapositiveidentification(inScenarios1and5)ifthepublic safetyUSSreturns totheVID anHTTP200 

or success messagealong with thevehicleproperties,flight plan, owner contact, andother information. A look-upis 

saidtoresultinanegativeidentificationif(inScenarios1and5)thepublicsafetyUSSreturns totheVIDanHTTP 

404ornotfoundmessagewheninfacttheobservedvehicleisregisteredandhasacorrespondingacceptedflightplan 

submittedtoa USS.Ofthe326look-ups,306or93.87percentresultedinapositiveidentification. Twentylook-upsor

Total 

Look-ups

Minimum 

Latency [s]

Average 

Latency [s]

Maximum 

Latency [s]

Standard 

Deviation 

[s]

Positive ID 

Percentage

326 0.40 1.20 9.49 0.86 93.87

Table 1 Overall Look-up Latency Metrics. The minimum, maximum, average, and standard deviation of the 

latency times for all UTM remote ID look-ups are computed. This included whether or not the look-up resulted 

in a successful identification. In the last column the percentage of successful look-ups is reported.

6.13 percent resulted in a negative identification.

Itis foundthattheaveragelook-uplatency time was 1.2[s] whichis reasonablegiventhatthe HTTP request must 

ultimately traverse several network connections to disparate components (public safety USS, vehicle registration, USS 

discovery service, etc.). In addition, each component also has its owndatabase connection which in most cases was an 

Amazon Web Service RDS (Relational Database Service). The maximum time was found to be 9.49 [s]. Longer look-up 

timeswerelikelyduetopublicsafetyUSSserverperformanceissues(seestep2inFig. 3.) duetounanticipatedheavy 

Downloaded by NASA AMES RESEARCH CENTER on January 10, 2019 | http://arc.aiaa.org | DOI: 10.2514/6.2019-2077
16

loads. Specifically,it was foundthatthenumber of connections tothedatabase(AWS RDS) exceededtheallowable 

limit.

Typically,this numberis adjusted tooptimizedatabaseperformance. Inaddition, optimizingtheconnectionpool 

maintainedbytheapplicationcouldalsohaveimpactonperformance. Othersourcesofdelaycouldbeduetothe 

vehicleregistrationservicewhichusedathirdpartyauthenticationservicethatisknowntoresultinintermittentdelays 

of several seconds.

¶DSRC was used at the Virginia test site, however, data analysis of those flights are not included in this paper.
17

J

( )

∑ ( )

Let R befixedandsupposethevehicleisobservedatt

∗

. Letthecostfunctionalbedefinedby J[u] =

tf

1· dt,

Look-up Times

140

120

100

80

60

40

20

0

Fig. 8 Look-Up Time Histogram. The average look-up time was 1.2 [s]. The maximum (one occurrence) was

9.4 [s]. The standard deviation was 0.86 [s]. Delays were likely due to increased traffic on the public safety USS 

or vehicle registration service and their dependencies.

Itisalsodepictedin Table2thedetection 

latency statistics. This variedby technology 

since each one has different processing steps 

that enabletheinformation(positionand UVIN) 

to be processed and properly formatted for an 

HTTP request in step 2.

Minimum 

Latency [s]

Average 

Latency [s]

Maximum 

Latency [s]

Standard 

Deviation 

[s]

0.001 1.542 5.200 1.120

Table 2 Overall Detect Latency Metrics. The detect latency

is defined by the time elapsed from when the detector acquires 

the relevant information to the time it becomes available to the 

software component that initiates the look-up.

All ofthenegativeidentificationcases (6%) 

weretesting Scenario5,thatis,thescenario 

whereonlyanestimateofthevehicleposition 

is provided. WhentheVID submits theposition 

estimate,itmustalsoprovideaboundingradius

whichisusedtosearchforvehicles knownbyUTMtobewithinthatboundatthetimeofthedetection. Therearea 

numberofchallenges thatcouldpotentiallyresultinanegativeidentification. First,theestimateofthevehicleposition 

andtimeneeds tobesufficiently accurate. Second,theboundingradius musttakeintoconsiderationthe timedelay 

associated with the look-up (see Fig.8).

Toillustratethesecondissue,let∆Tdenotethetotal delay,thatis,thesumofthedetectionandlook-uplatencies for 

aparticular look-up. Supposethatthedynamicsofthevehiclearedescribedby x = f t, x,w wherewrepresentsa 

non-autonomous wind field component. Let xp denote the components of x that describe the position of the vehicle. 

Suppose at time t

∗

, the VID detects the vehicle, that is, it generates an estimate for xp t

∗

 = xp

∗

. Upon selecting a 

boundingradius,R,therearetwopossibilitiesatthetimeoflook-upasshowninFig.9.Ifthevehicleattimet

∗ +∆Tis 

insideoftheregion(see A)thenapositiveidentificationresults.Ifthevehicleattimet

∗ +∆Tisoutsideoftheregion

(see B ) then a negative identification results.

Althoughthereexists asufficiently largeradius,R,that guarantees thevehicleis containedwithintheregionatthe 

timeoflook-up,itmay resultinmultiplevehiclesbeingidentifiedespecially inthecaseofhighdensityoperations. 

An optimization problem naturally emerges: find the smallestradiussuch thatthe region is guaranteed to containthe 

vehicle to be identified attime t

∗ +∆T. The solution depends on a number of factors includingthe vehicle dynamicsand 

windconditions. Oneapproachtosolvethis problem is toappeal tooptimal control theory which webriefly describe.

Downloaded by NASA AMES RESEARCH CENTER on January 10, 2019 | http://arc.aiaa.org | DOI: 10.2514/6.2019-2077
18

( )

p f p p denotes the complement of the open ball of radius

thatis,a minimum timecostfunctional. Theoptimal control problem reads: findu∗ = argmin J[u] su

t

∗

bject to

the constraint that x (t ) ∈ B

c

(x

∗

; R), where B

c

(x

∗

; R)

u ∈U

R about

xp t

∗ = xp

∗

. This is known as a free-time, fixed-endpoint problem where the control minimizes the time to reach the

destination. The minimum time, t

∗

f

, is clearly a function of the bounding radius, R. To find the smallest possible R, a 

search must be performed in order to compute R∗ = argmin{t

∗

f

(R) : t

∗ + ∆T < t∗

f

(R)}. That is, R∗is the smallest radius
19

such that at the time of look-up (t

∗ + ∆T ) the vehicle is within the region.

Fig. 9 Vehicle Position at Time of Look-Up. In the case of A, the vehicle is within the circular region with 

radius R andresults ina positive identification. In the case of B, the vehicle is outside of the circular region with 

radius R and results in a negative identification.

Alsoofinterest is thedistribution of distances 

fromthevehicletotheVIDorpublicsafetyofficer at times oflook-up. Overall, 26,588 vehicle 

position data elements were collected over 97 

minoftotalflighttimeandlinear interpolation 

wasusedtocomputethedistancefromthevehicles tothepublic safety officers. Table3depicts 

thequartilesandthe minimum and maximum 

statistics forthedistances (in meters) basedon 

thetechnology. TheIR technology hadthelowest

Technology Min Q1 Q2 Q3 Max

ADS-B 45.81 59.47 82.50 141.82 194.73

Infrared 54.52 57.33 66.72 73.18 84.24

Secure C2 48.18 57.96 88.78 111.70 163.95

Table 3 Distance at Times of Look-Up by Technology [m]

range since the receiver had to be in closer proximity to the vehicle in order to obtain a detection.

Tosummarizetheresults,therewereatotalof12flights,326look-updatapointsanda94%successrate. The 

sensortechnologiesusedhadasignificantimpactonthedataandsuccess rate. Forexample,whiletheIRtechnology 

approachispromising,furtherresearchisneededregardingits detectionrange,susceptibilitytoenvironmentfactors, 

andvehicleorientation(Eulerangles)andspeedduringaparticularmission.Inaddition,ifthepublicsafetyofficer 

is required to manage simultaneously twodifferent devices (one for detection and one for interfacing with the public 

safety USS) this may impact the failure rate adversely especially when pointing accuracy on a moving target is required. 

ADS-B technologies had the highest number of look-up tests and the highest range (maximum distance) from the public 

safety officer atthetimeoflook-up. This is likelyduetothe maturity ofthetechnology (for example,theIR andsecure 

C2approaches was custom built specific tothis test)anditsgeneral widespreadfamiliarity.

Whilethisanalysis representsanimportantfirst stepinremoteIDusingtheUTMsystem,itisrecommended 

thatfutureremoteID experiments break theexperimentinto morefocusedsubsets inordertoanalyzeseparately the 

individual components. This includes sensor technologies, communication protocols, and the various s/w and network 

R R

A

R

B

Drone 

Observatio

n 

Resolution

Look-up 

at

∆T+t*

Latency: ∆T

Downloaded by NASA AMES RESEARCH CENTER on January 10, 2019 | http://arc.aiaa.org | DOI: 10.2514/6.2019-2077
20

components that comprise Fig. 3.

V. Summary

ThispaperdiscussedtheUTMremoteIDframeworkandexaminedinitialdatacollectedduringtheUTMTCL3field 

tests that wereconducted February throughJune2018. TheproposedarchitectureutilizedUTM components: FIMS 

(Flight Information Management System), USS (UAS Service Supplier), and vehicle registration and model database in 

order toprovideassessment ofthe UASreportedinthe fieldincludingtheability todistinguishbetweenparticipating 

andnon-participatingUTMactors. Detailedsystemdescriptionswereprovidedandpreliminaryresultsfromfieldtests
21

werediscussed. This includedananalysis ofthedetect andlook-uplatencies anddistances betweenthevehicles to 

beidentifiedand thepublic safety officers. Future work should focus on (1) developingrequirements for thelatency 

metricsmeasuredinthisstudywhichmaydependonnumerous factorsincludingrisk,geographiclocation,population 

density,etc.,(2)theemergingtechnologies thatenableremoteidentificationofvehiclesatlongerdistances,and(3)a 

morecomprehensiveandthoroughanalysisofthevarious UTMcomponentsandtheir network interconnections that 

play a critical role in remote ID.

Acknowledgments

Thedesign, planningandscheduling,s/w development,communicationsupport,anddatacollectionforthe2018 

UTM TCL3fieldtests constitutedanenormous endeavor andthis acknowledgment captures only asmall fractionof 

theindividualsandeffortinvolved.WethankArwaAweiss,EdgarTorres,andHemilModifortheirtirelesseffortsin 

communicatingwithpartnersandensuringdatarequirements werefulfilled.WethankDanielLiddellandShawnLi for 

their database support and meticulous analysis. Wethank Lawrence Markosian for helpful discussions on the remote ID 

scenarios. Wethank Daniel Mulfinger, DavidSmith, Confesor Santiago, andSandraLozito fortheir thorough review 

of this work and helpful feedback. We thank Jeff Homola, Marcus Johnson, Jaewoo Jung, Joey Mercer, and Irene 

Skupniewicz for helpful discussions throughout. Wealsothank Chris Theisenand Mark Reilly for helpful discussions 

ontheremoteID datasetsandprovidinginvaluableinsights. Lastly,wethank theeffort oftheentire UTMteam without 

which no data would havebeen available for analysis.

References

[1] “Global Market Insights,” https://www.gminsights.com/industry-analysis/consumer-drone-market, March 2018.

[2] Jenkins,D.,Vasigh,B.,Oster,C., andLarsen,T.,ForecastoftheCommercialUASPackageDeliveryMarket,Embry-Riddle 

Aeronautical University, 2017.

[3] Margaritoff,M.,“AustralianDrugCartelUsedDronetoSpyonPolice,”http://www.thedrive.com/aerial/12050,2017.

[4] Craig,T.,Russo, J.,andShaffer, J., “Eyes in the skies: the latest threat to correctional institution security,” Corrections Today, 

2017.

[5] Repard, P., “In New Tactic, Smugglers Use Drone to Fly Meth over Mexican Border into San Diego, Officials Say,”

http://www.latimes.com/local/lanow/la-me-drug-smuggle-drone-20170819-story.html, 2018.

[6] Carey, B., “Army Confirms Black Hawk, Drone Collided Over New York City,” https://www.ainonline.com/aviationnews/defense/2017-09-25/army-confirms-black-hawk-drone-collided-over-new-york-city, September 25, 2017.

[7] Snead, J.,Seibler, J.-M., and Inserra, D.,“Establishing a Legal Framework forCounter-Drone Technologies,” 2018.

[8] Rupprecht, J., “7 big problems with counter-drone technology (drone jammers, anti-drone guns, etc.),”

https://jrupprechtlaw.com/drone-jammer-gun-defender-legal-problems, 2018.

[9] Geiver, L., “Early 2018 brings rush of counter-UAS activity,” http://www.uasmagazine.com/articles/1829/early- 2018-brings-rushof-counter-uas-activity, March 13,2018.

[10] Schaufele,R.,Ding, L., Miller,N.,Barlett,H.,Lukacs, M.,andBhadra,D.,“FAAAerospaceForecast: FiscalYears2017-2037,”

Washington, DC, 2017.

[11] Prevot, T., Rios, J., Kopardekar, P., Robinson III, J. E., Johnson, M., and Jung, J., “UAS traffic management (UTM) concept 

of operations to safely enable low altitude flight operations,” 16th AIAA Aviation Technology, Integration, and Operations 

Conference, 2016, p. 3292.

Downloaded by NASA AMES RESEARCH CENTER on January 10, 2019 | http://arc.aiaa.org | DOI: 10.2514/6.2019-2077
22

[12] FAA,“Unmanned Aircraft Systems (UAS) Traffic Management (UTM) Concept of Operations,” , 2018.

[13] Maddalon, J.M.,Hayhurst,K. J., Koppen,D.M., Upchurch, J.M., Morris,A.T.,andVerstynen,H. A.,“Perspectives on 

unmanned aircraft classification for civil airworthiness standards,” 2013.

[14] Smith, R. W.,Department of Defense WorldGeodetic System 1984: its definition and relationships with local geodetic systems, 

Defense Mapping Agency,1987.