1 

Automated Management of Small Unmanned 

Aircraft System Communications and 

Navigation Contingency 

Jaewoo Jung1 and Sreeja Nag2 

NASA Ames Research Center, Moffett Field, CA 94035, USA 

NASA has been pioneering research and development of technologies and requirements 

for the traffic management ecosystem for Unmanned Aircraft (UA) that complements the 

FAA’s Air Traffic Management system under the Unmanned Aircraft System (UAS) Traffic 

Management (UTM) project. In this effort, the FAA, industry, and academia developed nine 

requirements for managing Communications and Navigation (C&N) off-nominal situations, 

as nominally functioning C&N systems are essential for safe UA operations. The requirements 

were reviewed by the UTM community and practiced during NASA’s UTM flight 

demonstration in 2019. Some of the requirements could not be fulfilled during the 

demonstration, and recommendations to automate the management of C&N contingency are 

made to improve the fulfillment of requirements. The recommendations include the 

standardization of the means to detect C&N off-nominal situations and the integration of the 

UAS and UAS Service Supplier off-nominal mitigation process. 

I. Introduction 

In the USA, Visual Line-of-Sight (VLOS) operations of small Unmanned Aircraft System (sUAS) are 

commonplace and several types of operations that require approval, such as night operations and operations over 

people, are becoming routine with the upcoming rulemaking [1,2]. However, Beyond Visual Line-of-Sight (BVLOS) 

operations may not become routine until the traffic management ecosystem for Unmanned Aircraft (UA) that 

complements the FAA’s Air Traffic Management system is in place [3,4]. NASA has been pioneering research and 

development of technologies and requirements for this ecosystem under the UAS Traffic Management (UTM) project 

since 2014, and the term “UTM” has become synonymous with the complementary ecosystem [5,6]. 

NASA’s UTM effort consists of a series of Technical Capability Levels (TCL) activities that are increasingly 

complex. In TCL1, completed in 2015, VLOS operations such as agriculture, firefighting, and infrastructure 

monitoring were addressed with a focus on geofencing and operations scheduling [7]. Technologies and requirements 

for BVLOS operations in sparsely populated areas were examined in TCL2 in 2016, and for those operations over 

moderately populated areas in TCL3 in 2017 and 2018 [8,9,10]. TCL4 built on the earlier TCLs and focused on 

operations in higher-density urban areas for tasks such as newsgathering and package delivery, and for managing 

large-scale contingencies. 

Throughout the TCL activities, sUAS operations encountered Communications and Navigation (C&N) offnominal conditions, such as loss of Command and Control (C2) communications link and degraded navigation 

performance [11,12]. Since nominally functioning C&N systems are essential for safe UA operations, a working group 

consisting of NASA, the FAA, the industry and academia members developed an approach to handle C&N offnominal events. This paper describes a set of C&N contingency management requirements that comes from the 

working group’s effort and the UTM community response to the requirements in Section II. The details of 

requirements practice during the TCL4 demonstration are in Section III. Some requirements were not fulfilled in the 

demonstration and Section IV provides guidance for automating contingency management to improve requirements 

fulfillment. The paper concludes in Section V. 

1 Aerospace Technologist, Aviation Systems Division, Senior Member. 2 Research Scientist, Bay Area Environment Research Institute. 

Downloaded by NASA AMES RESEARCH CENTER on January 13, 2020 | http://arc.aiaa.org | DOI: 10.2514/6.2020-2195 

AIAA Scitech 2020 Forum 

6-10 January 2020, Orlando, FL 

10.2514/6.2020-2195 

This material is declared a work of the U.S. Government and is not subject to copyright protection in the United States. 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

AIAA SciTech Forum
Downloaded by NASA AMES RESEARCH CENTER on January 13, 2020 | http://arc.aiaa.org | DOI: 10.2514/6.2020-2195 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

II. Communications and Navigation Contingency Management Requirements 

A. C&N Working Group and Requirement Development 

To coordinate and facilitate the incremental implementation of the UTM in the National Air Space (NAS), NASA 

and the FAA formed a Research Transition Team (RTT) in 2017 [13]. The team is divided into four working groups, 

Concept and Use Case Development, Data Exchange and Information Architecture, Sense and Avoid, and C&N. The 

industry and academia were invited to participate in the last three working groups. The C&N working group, whose 

objective is to explore communications and navigation solutions to ensure that UA is under the operational control of 

the operator and remain within a defined area, led the discussion on off-nominal situations and development of C&N 

contingency management requirements. 

As the C&N working group formed, NASA sent out an input request3 to gather the group’s view on C&N system 

performance. Twenty organizations provided the input, which was discussed in a series of meetings. From these 

discussions, the following insights were developed. First, the C&N system performance must reflect operational 

complexity. For example, UA flying among many other UA and manned aircraft over a densely populated area 

requires higher C&N system performance than a single UA flying over a barren area. Second, communications 

between UA and its operator can be disrupted especially when the protected aviation spectrum is not used. The cause 

of this disruption includes intentional or unintentional radio frequency (RF) interference and blocked radio line of 

sight (e.g., a building between UA and its operator) [14,15]. Third, given the prevalent use of Global Navigation 

Satellite System (GNSS) receiver, such as the Global Positioning System (GPS), in the UA navigation system, 

navigation performance can be degraded due to RF interference, blocked radio line-of-sight to GNSS satellites, and 

reflected satellite signal (i.e., multipath) especially in low-altitude environments [16,17]. It was understood that 

disrupted communications and degraded navigation performance situations pose a risk to safe UA operations. 

The C&N working group applied the insights about the C&N system performance and off-nominal situations to 

develop contingency management requirements. Operator participation in UTM was assumed as a part of the 

contingency management [6]. In particular, operators were expected to use UAS Service Supplier (USS) to coordinate 

multiple BVLOS operations in the same geographical area, be informed of the NAS constraints, inform the FAA of 

UA operation issues that could impact the NAS operation, and manage off-nominal situations [18]. The role of USS 

is shown in Fig.1, UTM architecture. Table 1 shows nine C&N contingency requirements. The keywords “MUST” 

and “SHOULD” in the requirements should be interpreted as described in BCP 14 [RFC2119] [RFC8174]. 

Fig. 1 UTM Architecture, January 2019 

3 Additional information about this input process is in Appendix A. 

2 
 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

Downloaded by NASA AMES RESEARCH CENTER on January 13, 2020 | http://arc.aiaa.org | DOI: 10.2514/6.2020-2195 

Table 1 C&N Contingency Management Requirements 

Req. ID4 Requirement Text Requirement Justification 

OSM.001 

The operator MUST have the 

means to detect loss of 

communication between aircraft 

and its operator. 

The UTM system is built for operators to perform missions within 

constraints and directives that can change over time. Therefore, 

operators must know whether they can communicate or not with their 

UA to adhere to dynamic constraints and directives. 

OSM.002 

The operator SHOULD make 

the means to detect loss of 

communication with aircraft 

known to USS. 

USS, with appropriate data from Supplemental Data Service Provider 

(SDSP), should be able to provide communications quality of service 

information for a mission when the means to detect loss of 

communication is known. This will likely reduce the loss of 

communication incidence during a mission. 

OSM.003 

The operator MUST define 

steps to mitigate the loss of 

communication with aircraft. 

Operators must communicate with their UA to adhere to constraints 

and directives, which can change during a mission. Therefore, 

mitigation steps must be in place to resolve the loss of communication 

safely. 

OSM.004 

The operator SHOULD make 

the steps to mitigate the loss of 

communication with aircraft 

known to USS. 

USS, with similar information from other operators and adjacent 

USSs, should be able to support mitigation steps with minimal impact 

on overall operations under its service. 

OSM.005 

The operator MUST have the 

means to detect loss of aircraft 

onboard navigation. 

The UTM system is built for operators to perform missions within 

constraints and directives. Therefore, when UA is not maintaining the 

necessary navigation solution accuracy and integrity to adhere to 

constraints and directives, the operator must know this condition. 

OSM.006 

The operator SHOULD make 

the means to detect loss of 

aircraft onboard navigation 

known to USS. 

USS, with appropriate data from SDSP, should be able to provide 

navigation service quality forecast for UAS mission when its means to 

detect loss of navigation is known. This will likely reduce the loss of 

navigation incidence during a mission. 

OSM.007 

The operator MUST define 

steps to mitigate the loss of 

aircraft onboard navigation. 

UA must maintain the necessary navigation solution accuracy and 

integrity to adhere to constraints and directives. Therefore, mitigation 

steps must be in place to resolve the loss of navigation safely. 

OSM.008 

The operator SHOULD make 

the steps to mitigate the loss of 

aircraft onboard navigation 

known to USS. 

USS, with similar information from other operators and adjacent 

USSs, should be able to support mitigation steps with minimal impact 

on overall operations under its service. 

OSM.009 The operator MUST collect offnominal situation data. 

When UTM operations encounter off-nominal situations, data must be 

collected to take lessons learned to reinforce operational compliance 

and to enhance operational safety. 

4 OSM stands for Off-nominal Situation Management. This term and the ID number can change as UTM develops 

and should only be considered for consistency in the paper. 

3 
 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

B. UTM Community Response to the Requirements 

Downloaded by NASA AMES RESEARCH CENTER on January 13, 2020 | http://arc.aiaa.org | DOI: 10.2514/6.2020-2195 

In 2018, C&N contingency management requirements and justifications were sent out to the RTT participants with 

an online survey form for feedback. In the survey, each requirement was restated and the responder was given a scale 

of one to seven to indicate the applicability of that requirement. A “one” indicates the requirement should not be a 

requirement of UTM and a “seven” indicates the requirement is reasonable as written and is needed in UTM. The 

responder was also given three choices to indicate when the requirement should take effect. The choices were 1) When 

the UTM system achieves Initial Operational Capability, IOC (e.g., TCL1 operations), 2) After the UTM system 

achieves the IOC but before Full Operational Capability, FOC (e.g., TCL2 operations), and 3) When the UTM system 

achieves FOC (e.g., TCL3, TCL4 operations). A space to provide additional input was provided in the form. 

The survey collected 19 responses, nine from the C&N working group members, five from other RTT working 

group members, and five from non-members. Of the 19, eleven represented organizations’ view, six represented 

teams’ and two were personal. Fig. 2 shows applicability for each requirement in a boxplot. The percent of the 

responses for the three target periods for a requirement to take effect, in IOC, between IOC and FOC, and in FOC, is 

shown in Fig. 3. 

Fig. 2 OSM Requirements Applicability 

Fig. 3 Time Period for the OSM Requirements to Take Effect 

4 
 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

Downloaded by NASA AMES RESEARCH CENTER on January 13, 2020 | http://arc.aiaa.org | DOI: 10.2514/6.2020-2195 

The applicability percentiles in Fig. 2 show that all requirements were reasonable as written and needed for UTM, 

with the median ranging from the lowest 6 to the highest 7. In Fig. 3, a majority of the responses indicated that three 

requirements, OSM.001, OSM.005, and OSM.009 should take effect in IOC. This showed that off-nominal situation 

detection and data collection are foundational parts of UTM. The rest of the requirements were deemed to be needed 

beyond IOC when UTM supports BVLOS operations (e.g., TCL2~4), showing the importance of off-nominal 

mitigation steps and sharing them with USS for safe and efficient BVLOS operations. A majority of the responses 

indicated OSM.006 to be effective at FOC. For this requirement, USS should be able to provide navigation service 

quality forecast with input from SDSP, and the response showed that this capability may not be viable before FOC. 

It was also suggested in the feedback that the term “loss of aircraft onboard navigation” used in OSM.005 to 

OSM.008 should be revised to “degraded navigation performance”. This was to avoid potential misinterpretation of 

the term for indicating a total loss of navigation capability on a UA, which is not the condition stated in the 

requirement’s justification text. Given this, “degraded navigation performance” was adopted to describe the navigation 

off-nominal situation in the subsequent C&N working group discussions and in this paper. 

III. C&N Contingency Management Requirements Practice in the TCL4 Demonstration 

A. Description of the TCL4 Demonstration 

In the Fall of 2018, NASA provided a Statement of Work to six of the FAA-designated UAS test sites to conduct 

TCL4 demonstration in a series of flights. The six Test Site Operators (TSO) submitted proposals, and Nevada5 (NV) 

and Texas6 (TX) were selected. The demonstration was a set of scenario-driven activities that integrated NASA and 

the RTT objectives. Five scenarios were created where each scenario focused on different challenges associated with 

operations in a potential TCL4 environment, such as persistent, mixed tempo, and high-density BVLOS operations 

over an urban area. The summary of the scenarios is as follows. 

Scenario 1: Normal high-density operations interrupted by a weather event 

Scenario 2: Pop-up concert in a park, emergency operations, and temporary airspace restriction 

Scenario 3: UAS operation near airport, mixed operation with manned aircraft, rogue UAS 

Scenario 4: Flight over people, safe landing, UAS obstacle collision, and response 

Scenario 5: High-density operations, USS negotiation, USS failure 

Throughout the early months of 2019, NASA personnel, the TSOs, and their partners conducted collaborative 

table-top exercises and simulations to prepare for the demonstration. NV prepared the flight range in the downtown 

Reno area and TX in the downtown Corpus Christy area. The TSOs periodically informed NASA about the status of 

the certificate of waiver application to the FAA (e.g., use of visual observer), arrangement for accessing city properties, 

sUAS readiness for operating in the range, and other tasks. 

The demonstration took place in the Summer of 2019, and a total of 144 live operations were flown from June 

18th to June 28th in the Reno range for scenarios 1, 2, and 4 with nine UA made by three manufacturers, AirRobot 

GmbH & Co. KG (1), Drone America (5), and SZ DJI Technology Co., Ltd (3). Five USS developed by AirMap Inc., 

AiRXOS (a GE venture), ANRA Technologies, Avision Inc., and Uber Technologies Inc. supported the operations. 

A total of 208 operations were flown from August 12th to August 16th, and August 19th to August 23rd in the Corpus 

Christy range for all five scenarios with nine UA made by two manufacturers, 3DR (2) and SZ DJI Technology Co., 

Ltd (7). Seven USS developed by AirMap Inc., AiRXOS (a GE venture), ANRA Technologies, Avision Inc., Collins 

Aerospace (a unit of United Technologies Corp.), OneSky (Analytical Graphics, Inc.), and Uber Technologies Inc. 

supported the operations. 

For all operations, NASA USS connected with other USS for data collection and operations monitoring. In both 

flight ranges, arrangements were made to only allow demonstration participants in the sUAS operations area. Extended 

VLOS operations were used to emulate BVLOS operations. That is, UA was in sight of designated visual observers 

when the operator was unable to see it due to obstruction (e.g., UA behind a building) or distance, and the observers 

and the operator maintained a line of communication among them to keep track of operational issues. Additional 

information about the demonstration, including details of scenarios, events, and measures of performance, is in 

reference [19]. 

5 Operated by Nevada Institute for Autonomous Systems (NIAS). 6 Operated by the Lone Star UAS Center of Excellence & Innovation (LSUASC). 

5 
 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

B. C&N Contingency Management Requirements Practice in the Demonstration 

Downloaded by NASA AMES RESEARCH CENTER on January 13, 2020 | http://arc.aiaa.org | DOI: 10.2514/6.2020-2195 

OSM.001 & OSM.003: Loss of C2 Communications Detection and Mitigation 

During the TCL4 demonstration, operators used sUAS’s built-in functions to handle the loss of C2 

communications. All sUAS were equipped with a C2 communications system connecting UA and a ground control 

system (GCS), such as a radio modem and Long-Term-Evolution (LTE) data modem. The GCS was typically 

programmed to send a heartbeat packet to UA and receive an acknowledgment from the UA continuously, and a 

prolonged interruption to this exchange, such as five seconds (set by the operator), automatically triggered the UA to 

return to the launch location (RTL) where the operator was co-located. As the UA approached the launch location, the 

operator attempted to re-establish the C2 communications to control the UA. Some UA were equipped with a radio 

transceiver for connecting UA and a hand-held remote controller. In this case, the operator took control of the UA 

using the remote controller as the UA completed RTL. Some UA were capable of visually indicating loss of C2 

communications, such as the fast flashing of status indicator lights on the UA in yellow color. The operator also had 

an option to proactively command the UA to execute RTL via the GCS when weakening communications link health 

was known, such as lower than expected signal strength. Given this, OSM.001 and 003 were practiced in the 

demonstration. 

OSM.005 & OSM.007: Degraded Navigation Performance Detection and Mitigation 

Degraded navigation performance was handled using sUAS built-in functions. Typically, UA were programmed 

to automatically land when a certain condition was met, such as lower than six GPS satellites in view (set by the 

operator). In some cases, UA were programmed to enter a loitering mode using an onboard barometer or downward 

& forward vision systems (i.e., hold altitude but may drift due to wind) when a certain condition was met and wait for 

the operator to control the UA. Some UA were capable of visually indicating degraded navigation performance, such 

as the slow flashing of status indicator lights on the UA in yellow color. The operator had an option to command the 

UA to land via GCS when navigation performance degradation was known, such as increasing geometric dilution of 

precision (GDOP) that is an indication of increasing position error. Given this, OSM.005 and 007 were practiced in 

the demonstration. 

OSM.002 & OSM.006: Informing USS of Off-nominal Situation Detection Means 

The means to detect C&N off-nominal situations were documented by the TSOs per NASA’s request. However, 

it was unclear whether this information was made available to USS participants; therefore, OSM.002 and 006 were 

considered not practiced in the demonstration. Recommendation to standardize C&N off-nominal situation detection 

and use of the standard to better fulfill the requirements is discussed in Section IV. 

OSM.004 & OSM.008: Informing USS of Off-nominal Situation Mitigation Steps 

In UTM, an operator submits an operation plan to USS and the plan can be activated when the USS accepts the 

plan after checking constraints, such as conflicts with existing operations and other operation plans [18]. For the TCL4 

demonstration, the Data Exchange and Information Architecture and the C&N working groups provided guidance to 

the participating sUAS operators and USS developers about expanding the operation plan to include a set of 

contingency plans. A contingency plan was designed to contain a reason for the plan, such as a lost C2 communications 

link, a mitigation step, such as UA to perform RTL, an area defined in a polygon with vertices in latitude and longitude 

when the mitigation step involves a destination (e.g., a safe area to land), and planned altitude when the mitigation 

step involves loitering. 

Operators were required to prepare a set of contingency plans so that different types of off-nominal situations can 

be addressed using the set, and USS developers worked with operators so that a contingency plan can be activated in 

a timely manner when an off-nominal situation occurs. Analysis of contingency plan activation messages, specified 

in USSREQ-API [18], showed that of 116 off-nominal situations, only 33 activated a contingency plan while resolving 

the situation. The number of off-nominal situations was based on all off-nominal reports submitted to USS in the 

demonstration. Given this, OSM.004 and 008 were practiced in a limited scope in the demonstration. A 

recommendation to automate C&N contingency management to better fulfill the requirements is discussed in Section 

IV. 

OSM.009: Off-nominal data collection 

To support meeting the C&N working group objectives, scripted C&N off-nominal events representing the loss of 

C2 communication and degraded navigation performance, were included in the demonstration scenarios. sUAS 

operators participating in such events were directed to act as if their operation encountered the scripted off-nominal 

6 
 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

Downloaded by NASA AMES RESEARCH CENTER on January 13, 2020 | http://arc.aiaa.org | DOI: 10.2514/6.2020-2195 

situation and resolve the situation. The occurrence of actual (i.e., non-scripted) off-nominal situations was anticipated 

and the operators were directed to prioritize safe resolution of the situation over scenario participation. When either 

scripted or actual off-nominal situations occurred, operators were required to submit an off-nominal report including 

a narrative of the situation to USS upon resolution of the situation. A total of 116 reports were submitted. Given this, 

OSM.009 was practiced in the demonstration. An analysis of the submitted reports is in reference [20]. 

IV. Improving C&N Contingency Management Requirements Fulfillment with Automation 

A. Standardized Means to Detect C&N Off-nominal Situations 

In the TCL4 demonstration, the TSO assigned a director of flight operations and allotted staff to oversee operations 

at the flight range. When a communications or navigation off-nominal situation occurred, the operator contacted the 

director to inform about the situation (e.g., “Communications to UA is lost”). Once the nature of the situation was 

understood, the director communicated with USS so that the USS was aware of the change in the operation. If the 

operator and USS shared a standard means to detect off-nominal situations, such coordination can be automated. This 

automation would remove the critical path, the director in the center of coordination, and increase operational 

efficiency as USS would be able to activate a relevant contingency plan without waiting to be informed by the operator. 

The standard means can also meet OSM.002 and OSM.006. 

Loss of C2 Communications, UA to Operator Direction 

To standardize the means to detect loss of C2 communications, the operator and USS are recommended to agree 

on the value of two communications performance parameters, the Minimum Data Transfer Rate, and the Maximum 

Round Trip Latency. To determine the Minimum Data Transfer Rate, a set of telemetry variables that is essential to 

monitor UA operation (Flight Essential Telemetry, FET) should be adopted, and the data rate necessary to securely 

transfer FET should be estimated. Table 2 shows the suggested FET variables and associated descriptions. In the table, 

the camel case is used for the variable name and the unit for the variable is appended. When the operator receives FET 

and its integrity is confirmed, an acknowledgment should be sent to UA. It is also recommended that the operator 

transfer FET to USS as received. To determine the Maximum Round Trip Latency, the operator and USS should assess 

the operational risk that can result from the lack of FET update. For a reference, NASA’s USS specification uses a 1-

second update rate for position sharing among USS [18]. 

Once the values for the Minimum Data Transfer Rate and the Maximum Round Trip Latency are known, the 

operator and USS can detect loss of C2 communications when the Minimum Data Transfer Rate is not maintained for 

longer than the Maximum Round Trip Latency. Correspondingly, sUAS should be configured so that 1) UA will 

automatically begin loss of C2 communication mitigation step when it does not receive FET acknowledgment from 

the operator for a duration longer than the Maximum Round Trip Latency, 2) UA will resume operation when the 

communication is reestablished, and 3) UA will initiate safe landing when the loss continues for longer than a 

Telemetry Timeout period. The timeout is used to instill predictability in handling off-nominal situations. That is, 

sUAS and the operator can attempt to regain normalcy upon the off-nominal situation, but within the timeout. For a 

reference, 30 seconds is used for the Telemetry Timeout in the TCL4 demonstration. Discussion on safe landing is in 

reference [21~24]. 

Table 2. Example Flight Essential Telemetry Variables and Descriptions 

Telemetry Variable Name Description 

vehiclePositionLat_deg Vehicle position in latitude, in decimal degrees 

vehiclePositionLon_deg Vehicle position in longitude, in decimal degrees 

vehicleWGS84Alt_ft Vehicle WGS-84 altitude 

pressureAltitude_ft Pressure altitude in feet 

externalTemperature_C The external temperature in degrees Centigrade 

relativeHumidity_prct Relative humidity in percent 

navigationAccuracyCategoryPosition NACp category from RTCA DO-260B 

navigationIntegrityCategory NIC category from RTCA DO-260B 

7 
 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

Downloaded by NASA AMES RESEARCH CENTER on January 13, 2020 | http://arc.aiaa.org | DOI: 10.2514/6.2020-2195 

geometricVerticalAccuracyCategory GVA from RTCA DO-260B 

heading_deg Heading (deg, True North) 

groundCourse_deg Ground Course, also known as track (deg, True North) 

groundSpeed_ftPerSec Ground Speed in ft/s 

trueAirspeed_ftPerSec True airspeed in ft/s 

verticalSpeef_ftPerMinute Vertical speed in feet per minute, negative indicates descent 

roll_deg Roll (deg). Negative roll indicates left 

pitch_deg Pitch (deg). Negative pitch indicates nose down 

yaw_deg Yaw (deg). Zero-degree yaw is North. 

rollRate_degPerSec Roll Rate (deg/s). Negative indicates the leftward rate 

pitchRate_degPerSec Pitch Rate (deg/s). Negative indicates the downward rate 

yawRate_degPerSec Yaw Rate (deg/s) Negative indicates the counter-clockwise rate 

vehicleHealth 

Must indicate the state of the communications system, the navigation system, 

safe landing system when equipped, Attitude Determination and Control 

system (ADAC), and resource (e.g., remaining fuel/ flight time) 

Fig. 4 UA C&N Off-nominal Situation Mitigation Flowchart 

8 
Downloaded by NASA AMES RESEARCH CENTER on January 13, 2020 | http://arc.aiaa.org | DOI: 10.2514/6.2020-2195 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

Fig. 5 USS C&N Off -nominal Situation Mitigation Flowchart 

Loss of C2 Communications, Operator to UA direction 

The operator and USS are recommended to agree on the Response Time to positively confirm that UA can respond 

to changes in operational constraints, such as the UAS Volume Reservation. For this confirmation, USS should 

periodically send a constraint change status message to the operator, who then should send associated C2 input to UA 

for responding to the change. This message can be empty and the associated C2 input null, such as “no constraint 

change” and “null C2 input”, respectively. For each constraint change status message, USS should receive UA’s 

acknowledgment conveyed by the operator. When this acknowledgment is not received for longer than the Response 

Time, a loss of C2 communications situation is detected by the operator and the USS. Correspondingly, sUAS should 

be configured so that 1) UA will automatically begin loss of C2 communication mitigation steps when it does not 

receive a C2 input for a duration longer than the Response Time, 2) UA will resume operation when the 

communication is reestablished, and 3) UA will initiate safe landing when the loss continues for longer than a C2 

Timeout period. For a reference, 300 seconds is used for the C2 Timeout in the TCL4 demonstration. 

Degraded Navigation Performance 

The operator and USS are recommended to agree on the minimum horizontal accuracy bound (NACp), 

containment radius (NIC), and geometric vertical accuracy (GVA) necessary for operation [25,26]. While it is possible 

to use NACp, NIC, GVA categories and values from RTCA DO-260B [27], the use of more granular ones is 

recommended. For example, GVA in the RTCA document has only three categories (0,1,2) and values (larger than 

150m, at or more precise than 150m, and at or more precise than 45m) and additional categories and values would be 

useful for increasing the number of vertically stacked operations, leading to more efficient use of low-altitude airspace. 

Once the minimum NACp, NIC, and GVA for operation are known, sUAS should be configured so that 1) UA 

will automatically begin degraded navigation performance mitigation steps when NACp, NIC, or GVA becomes worse 

than the minimum 2) UA will resume operation when the navigation performance meets or exceeds the minimum, and 

3) UA will initiate safe landing when the degradation continues for longer than a Navigation Timeout period. For a 

reference, 10 seconds is used for the Navigation Timeout in the TCL4 Demonstration. The operator and USS can 

9 
 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

detect degraded navigation performance with normally functioning C2 communications, and what should be done in 

case of concurrent loss of C2 communication is recommended in the next subsection. 

Downloaded by NASA AMES RESEARCH CENTER on January 13, 2020 | http://arc.aiaa.org | DOI: 10.2514/6.2020-2195 

B. Integrated sUAS-USS C&N Off-nominal Mitigation 

With the standard means to detect C&N off-nominal situations, the sUAS operator and USS are recommended to 

implement an integrated approach to process mitigation steps. This implementation should fully automate C&N offnominal situations contingency management and improve the fulfillment of OSM.004 and OSM.008. C&N offnominal situation mitigation flowcharts for UA and USS are shown in Fig. 4 and Fig. 5. In UA, mitigation of degraded 

navigation performance is prioritized with the assumption that loss of C2 communications mitigation relies on a 

nominally functioning navigation system. Boxes 120 and 130 are used to handle this prioritization. For USS, degraded 

navigation performance can only be detected with nominally functioning C2 communication. Therefore, in box 210, 

the contingency plan should include mitigation steps for a possible degraded navigation performance when the loss of 

C2 communication is detected. Additional information on the function boxes and decision diamonds in Fig. 4. and 

Fig. 5 is in Appendix B. 

V. Conclusion 

NASA has been pioneering research and development of technologies and requirements for the traffic management 

ecosystem for UA that complements the FAA’s Air Traffic Management system under the UTM project. Since 

nominally functioning C&N systems are essential for safe UA operations, NASA, the FAA, industry, and academia 

developed nine requirements for managing C&N off-nominal situations. This paper described how the requirements 

were derived and ultimately tested in a field demonstration in 2019. Some of the requirements could not be fulfilled 

in the demonstration and the paper recommends automating the management of C&N contingency to improve the 

fulfillment of requirements. The recommendations include the standardization of the means to detect C&N offnominal situations and the integration of the UAS and UAS Service Supplier off-nominal mitigation process. 

Appendix A 

The following questions were sent out to the C&N working group members in January 2017. Twenty organizations 

provided input: ANRA Technologies, AT&T, DCS, Ericsson, Flyspan Systems, GE, Harris, Higher Ground, Innovets, 

Intel, InterDigital, Ligado Network, Nokia Bell Labs, R3E, Rockwell Collins, Sharper Shape, Team GC2IT and FRA, 

T-Mobiles, uAvionix, and University of Colorado, Boulder. 

Communications (command and control, or C2): 

- How would one define C2 Quality of service (QOS)? 

- What should we measure at aircraft and at Ground Control System (GCS) to monitor QOS during small 

UAS BVLOS operation? 

o Ones that are currently measured by UAS operators with standard 

o Ones that are currently measured but without standard 

o Ones that should be measured 

- Would it be possible to provide QOS forecast for a planned mission area and time? 

- What should we measure to do this forecasting? 

- How should we define C2 off-nominal situation and what mitigation steps should Unmanned Aircraft 

(UA) and its operator take? 

Navigation 

- How would one define navigation performance? 

- What should we measure at aircraft to monitor this performance? 

o Ones that are currently measured by UAS operators with standard 

o Ones that are currently measured but without standard 

o Ones that should be measured 

- Can we predict changes in Navigation performance/error for a planned mission area and time? 

- What should we measure to do this prediction? 

- How should we define navigation off-nominal situation and what mitigation steps should UA and its 

operator take? 

10 
 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

Appendix B 

Downloaded by NASA AMES RESEARCH CENTER on January 13, 2020 | http://arc.aiaa.org | DOI: 10.2514/6.2020-2195 

Explanations of the function boxes and decision diamonds in Fig. 4 and Fig. 5 are as follows. 

Fig. 4 

100: UA in nominal or contingency mode of operation 

102: Degraded navigation performance check 

104: Loss of C2 communications check 

106: Safe landing in progress check 

108: Complete the safe landing process 

110: UA operation completed 

112: Communications timeout counter initiation check 

114: Start the communications timeout counter 

116: Initiate loss of C2 communications mitigation steps 

118: Communications timeout check 

120: If loss of C2 communications mitigation is in progress, stop that mitigation 

122: Navigation timeout counter initiation check 

124: Navigation timeout check 

126: Start the navigation timeout counter 

128: Initiate degraded navigation performance mitigation steps 

130: If loss of C2 communications mitigation was stopped due to degraded navigation performance situation, and the 

navigation performance returned, continue the stopped loss of C2 communications mitigation 

132: Initiate a safe landing process 

Fig. 5 

200: Nominal operation (i.e., original operation plan active) 

202: Loss of C2 communication check 

204: Degraded navigation performance check 

210: Contingency operation (i.e., contingency plan active) 

212: Communications or Navigation timeout check 

214: Confirm UA landing 

216: Compile information for an off-nominal report filing 

218: sUAS Operation completed 

Acknowledgments 

F. A. Authors thank UTM project, the NV and the TX test site personnel for their dedication, leading to a safe and 

successful completion of the TCL4 demonstration. 

References 

[1] U.S. Code of Federal Regulation Title 14 Part 107 - Small Unmanned Aircraft Systems, June 2016. 

[2] U.S. Notice of Proposed Rulemaking, “Operation of Small Unmanned Aircraft Systems Over People”, FAA, February 2019. 

[3] FAA UAS Traffic Management, URL: https://www.faa.gov/uas/research_development/traffic_management/ [retrieved 29 

October 2019]. 

[4] U.S. Public Law 114-190, “FAA Extension, Safety, and Security Act of 2016”, 2016. 

[5] Kopaderkar, P. et. al. “UAS Traffic Management Concept of Operations”, AIAA Paper 2016-3292, June 2016. 

[6] “UAS Traffic Management Concept of Operations v1.0”, FAA, May 2018. 

[7] Rios, J. L., Mulfinger, D., Homola, J., and Venkatesan, P., “NASA UTM National Campaign”, doi: 

10.1109/DASC.2016.7778080, September 2016. 

[8] Johnson, M. el. Al. “Flight Test Evaluation of UTM Concept for Multiple Beyond-Visual-Line-of-Sight Operations”, 12th 

USA/Europe ATM R&D Seminar, Seattle, WA, June 2017. 

[9] Homola, J. et. al. “Technical Capability Level 2 UAS Traffic Management Flight Demonstration: Description and Analysis”, 

doi: 10.1109/DASC.2017.8101994, September 2017. 

[10] Aweiss, A. et. al. “Flight Demonstration of UTM at Technical Capability Level 3”, IEEE/AIAA 38th Digital Avionics Systems 

Conference, San Diego, CA, September 2019. 

[11] Jung, J. et. al. “Initial Approach to Collect Small UAS Off-nominal Operational Situations Data”, AIAA Paper 2018-3030, 

June 2018. 

[12] Glaab, L. J., and Logan, M. J., “Failure Mode Effects Analysis and Flight Testing for Small Unmanned Aerial Systems”, 

AIAA Paper 2017-3270, June 2017. 

11 
 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

[13] “UAS Traffic Management (UTM) Research Transition Team (RTT) Plan”, NASA, FAA, March 2017. 

Downloaded by NASA AMES RESEARCH CENTER on January 13, 2020 | http://arc.aiaa.org | DOI: 10.2514/6.2020-2195 

[14] “Command and Control (C2) Data Link White Paper”, RTCA WP-2, March 2014. 

[15] Jung, J., Nag, S., and Modi, H., “Effectiveness of Redundant Communications Systems in Maintaining Operational Control 

of Small Unmanned Aircraft”, IEEE/AIAA 38th Digital Avionics Systems Conference, San Diego, CA, September 2019. 

[16] Enge, P. et. al. “Measurement of Man-Made Spectrum Noise Floor”, NASA CR-2004-213551, November 2004. 

[17] Musa, S. M., and Wu, Z., “Aeronautical Telecommunications Network”, CRC Press, August 2015, Chap. 6. 

[18] Rios, J. L. et. al. “UAS Service Supplier Specification”, NASA TM-2019-220376, October 2019. 

[19] “Flight demonstration of UTM at Technical Capability Level 4”, (to be published) 

[20] Jung, J. et. al. “Small UAS Off-nominal Operations Reporting System UTM TCL4 Implementation, Data Collection, and 

Analysis”, (to be published) 

[21] Glaab, L. J. et. al. “Safe2Ditch Autonomous Crash Management System for Small Unmanned Aerial Systems: Concept 

Definition and Flight Test Results”, NASA TM-2018-220110, November 2018. 

[22] Ippolito C. A. et. al. “An Autonomy Architecture for High-Density Operations of Small UAS in Low-Altitude Urban 

Environments”, AIAA Paper 2019-0689, January 2019. 

[23] Di Donato, P. F. A., and Atkins, E., “Evaluating Risk to People and Property for Aircraft Emergency Landing Planning”, 

AIAA Journal of Aerospace Information Systems, Vol. 14, No. 5, May 2017, pp. 259, 278. doi: 10.2514/1.I010513 

[24] Chakrabarty, A., Stepanyan V., Krishnakumar K., and Ippolito, C., “Real-Time Path Planning for Multi-copters Flying in 

UTM-TCL4”, AIAA Paper 2019-0958, January 2019. 

[25] Jung, J. et. al. “Applying Required Navigation Performance Concept for Traffic Management of Small UAS”, 30th Congress 

of the International Council of the Aeronautical Sciences, Daejeon, Korea, September 2016. 

[26] Cho, J., and Yoon, Y., “How to Assess the Capacity of Urban Airspace: A Topological Approach using Keep-in and Keepout Geofence”, Transportation Research Part C 92, 2018, pp. 137, 149. doi: 10.1016/j.trc.2018.05.001. 

[27] “Minimum Operational Performance Standards (MOPS) for 1090 MHz Extended Squitter Automatic Dependent Surveillance 

- Broadcast (ADS-B) and Traffic Information Services - Broadcast (TIS-B)”, RTCA DO-260B, December 2011. 

12