NASA/TM—2018–219714

Air Traffic Management Technology 

Demonstration – 3 (ATD-3) 

Multi-Flight Common Route (MFCR) Concept 

of Operations

Version 1.0

Karl D. Bilimoria

Ames Research Center, Moffett Field, California

Doug Helton, George Price

Crown Consulting Inc., Arlington, VA

 

Click here: Press F1 key (Windows) or Help key (Mac) for help 

May 2018

https://ntrs.nasa.gov/search.jsp?R=20180004053 2018-12-09T16:47:38+00:00Z
NASA STI Program ... in Profile

Since its founding, NASA has been dedicated 

to the advancement of aeronautics and space 

science. The NASA scientific and technical 

information (STI) program plays a key part in 

helping NASA maintain this important role.

The NASA STI program operates under the 

auspices of the Agency Chief Information Officer. 

It collects, organizes, provides for archiving, and 

disseminates NASA’s STI. The NASA STI 

program provides access to the NASA 

Aeronautics and Space Database and its public 

interface, the NASA Technical Reports Server, 

thus providing one of the largest collections of 

aeronautical and space science STI in the world. 

Results are published in both non-NASA channels 

and by NASA in the NASA STI Report Series, 

which includes the following report types:

• TECHNICAL PUBLICATION. Reports of 

completed research or a major significant 

phase of research that present the results of 

NASA Programs and include extensive data 

or theoretical analysis. Includes compilations of significant scientific and technical 

data and information deemed to be of 

continuing reference value. NASA counterpart of peer-reviewed formal professional 

papers but has less stringent limitations on 

manuscript length and extent of graphic 

presentations.

• TECHNICAL MEMORANDUM. 

Scientific and technical findings that are 

preliminary or of specialized interest, 

e.g., quick release reports, working 

papers, and bibliographies that contain 

minimal annotation. Does not contain 

extensive analysis.

• CONTRACTOR REPORT. Scientific and 

technical findings by NASA-sponsored 

contractors and grantees.

• CONFERENCE PUBLICATION. 

Collected papers from scientific and 

technical conferences, symposia, seminars, 

or other meetings sponsored or 

co-sponsored by NASA.

• SPECIAL PUBLICATION. Scientific, 

technical, or historical information from 

NASA programs, projects, and missions, 

often concerned with subjects having 

substantial public interest.

• TECHNICAL TRANSLATION. 

English-language translations of foreign 

scientific and technical material pertinent to 

NASA’s mission.

Specialized services also include organizing 

and publishing research results, distributing 

specialized research announcements and 

feeds, providing information desk and personal 

search support, and enabling data exchange 

services.

For more information about the NASA STI 

program, see the following:

• Access the NASA STI program home page 

at http://www.sti.nasa.gov

• E-mail your question to help@sti.nasa.gov

• Fax your question to the NASA STI 

Information Desk at 443-757-5803

• Phone the NASA STI Information Desk at 

443-757-5802

• Write to:

STI Information Desk

NASA Center for AeroSpace Information

7115 Standard Drive

Hanover, MD 21076-1320

This page is required and contains approved text that cannot be changed.
NASA/TM—2018–219714

Air Traffic Management Technology 

Demonstration – 3 (ATD-3) 

Multi-Flight Common Route (MFCR) Concept 

of Operations

Version 1.0

Karl D. Bilimoria

Ames Research Center, Moffett Field, California

Doug Helton, George Price

Crown Consulting, Inc, Arlington, VA

 

 Insert conference information, if applicable; otherwise delete 

Click here: Press F1 key (Windows) or Help key (Mac) for help 

National Aeronautics and

Space Administration

Ames Research Center

Moffett Field, CA 94035-1000

May 2018
 Enter acknowledgments here, if applicable. 

Click here: Press F1 key (Windows) or Help key (Mac) for help 

Available from:

Click here: Press F1 key (Windows) or Help key (Mac) for help 

NASA Center for AeroSpace Information

7115 Standard Drive

Hanover, MD 21076-1320
3

Multi-Flight Common Route (MFCR)

Concept of Operations 

Version 1.0

 

Prepared and Submitted by: 

Karl D. Bilimoria 

NASA Ames Research Center 

 

Doug Helton 

Crown Consulting, Inc. 

 

George Price 

Crown Consulting, Inc.

 

 

November 2017 
4

APPROVALS:

Leighton Quon* Date

ATD Project Manager

NASA Ames Research Center

Mike Madson* Date

ATD Deputy Project Manager

NASA Ames Research Center

Kapil Sheth* Date

ATD-3 Sub-Project Manager 

NASA Ames Research Center

Karl Bilimoria* Date

MFCR Technical Lead

NASA Ames Research Center

Stephanie Harrison* Date

ATD-3 Lead Systems Engineer

NASA Langley Research Center

Maryam Amer* Date

MFCR Systems Engineer

Millennium Engineering & Integration Co.

*This document version is electronically signed in PAM.

This document is part of the ATD-3 Technology Development Activity documentation, controlled by the 

ATD-3 Change Control Manager at NASA Ames Research Center, Moffett Field, California. Aeronautics 

Directorate, Aviation Systems Division.
5

Revision History:

Rev Date Sections 

Affected

Description of Change Who

V0.1 08-27-17 All Initial draft MFCR ConOps D. Helton

Crown Consulting, Inc.

V0.2 11-01-17 All Incorporated NASA edits and 

comments

D. Helton

Crown Consulting, Inc.

V0.3 11-20-17 All Incorporated NASA edits and 

comments, proofed

D. Helton, G. Price

Crown Consulting, Inc.

V0.4 11-29-17 All Incorporated NASA edits and 

comments, proofed

D. Helton, G. Price

Crown Consulting, Inc.

V1.0 11-29-17 - Finalized Document M. Amer

Table of Contents

1 Introduction ..........................................................................................................................................6

2 Scope.....................................................................................................................................................7

3 Current System Shortfalls.....................................................................................................................8

4 Multi-Flight Common Route (MFCR) Capability....................................................................................9

4.1 Capability Description..................................................................................................................9

4.2 User Interface and Procedures..................................................................................................12

4.3 Convective Weather Model.......................................................................................................15

4.4 MFCR Use Case..........................................................................................................................18

5 System Dependencies.........................................................................................................................19

6 Potential Future Enhancements .........................................................................................................21

7 References ..........................................................................................................................................24

 
6

1 INTRODUCTION 

Increasing the capacity and efficiency of the National Airspace System (NAS) is a primary goal of the 

Federal Aviation Administration’s (FAA) NextGen program. The advent of area navigation capability and 

direct routing automation upgrades over the past decade has improved en route capacity and efficiency 

during fair-weather conditions. However, improvements have not been as great during adverse 

weather. Automation system limitations and the associated policies and procedures continue to present 

challenges during adverse weather, leading to excessive delays, fuel consumption, and adverse 

environmental impacts. Adverse weather, in the form of convective storms, high winds, turbulence, 

snow and ice, low visibility, and low ceilings, is responsible for roughly 70% of the delays in U.S.

operations. Weather-related delays were responsible for 32,000 minutes of average delay in the NAS 

during the summer of 2014 [1]. During significant convective activity, FAA traffic managers use playbook 

routes as part of severe weather avoidance plans to safely divert traffic around weather-impacted 

regions. These strategic plans, devised two or more hours in advance of departure, provide 

predictability, but they introduce large deviations from nominal routes and may be very inefficient if the 

weather develops differently than predicted. Currently, traffic managers are able to reroute limited 

numbers of these flights using manual procedures, but they lack the automation tools necessary to 

manage routing changes for all the impacted flights. The National Aeronautics and Space Administration 

(NASA) has been developing automation that can identify flights in need of rerouting, suggest more 

efficient routes, and simplify coordination with airspace users and downstream air traffic facilities, 

providing greater operational efficiency, reduced delays, lower operating costs, and increased Air Traffic 

Management (ATM) productivity.

 
7

2 SCOPE 

Convective storms continue to be one of the most challenging obstacles for en route operations. They 

are difficult to predict more than one hour in advance, and traffic managers lack the tools necessary to 

quickly respond to outdated routes when storm systems develop differently than predicted. This often 

results in inefficient routes, unnecessary flight delays, and increased operating costs – negative impacts

that will become worse as traffic demand increases. A suite of integrated ground-based technologies 

and decision-making aids being developed under NASA’s Airspace Technology Demonstration - 3 (ATD-3)

Project continuously search for more efficient weather-avoidance routes and help traffic managers, 

controllers, and airspace users to respond rapidly to weather changes and associated traffic 

management initiatives. These route-efficiency enhancements, targeted at en route airspace, will enable 

continued use of en route and arrival metering in the presence of weather. 

NASA’s Multi-Flight Common Route (MFCR) automation represents one element of those technologies 

focusing primarily on delay recovery in the en route phase of flight. Delay recovery is an attenuation of 

flight-time delay, accomplished by periodically revising weather-avoidance routing as the convective 

weather system evolves. MFCR is intended for use by Traffic Management Coordinators (TMCs) in Air 

Route Traffic Control Centers (ARTCCs, or Centers) and traffic management specialists (TMSs) in the Air 

Traffic Control System Command Center (ATCSCC). MFCR leverages existing weather, airspace, and 

traffic data, as well as improvements in navigation, surveillance, communication, and digital information

technologies, to build on existing ATM automation and address some of the shortcomings associated 

with strategic traffic flow management initiatives and weather forecasting uncertainties. These 

capabilities provide significant potential benefits in the form of time, fuel, and cost savings. The concept 

of operations described in this document describes MFCR functionality as delivered by NASA to the FAA

in December 2017, including a list of potential enhancements that may be realized when the system is 

fielded.

 
8

3 CURRENT SYSTEM SHORTFALLS 

In today’s operations, Traffic Management Initiatives, or TMIs, are necessary to ensure that aircraft 

safely avoid areas of adverse weather and to meter traffic when demand in a given area exceeds air 

traffic control’s capacity to safely separate aircraft. Although necessary for safety, route diversions and 

metering can be overly conservative due to uncertainty in weather forecasts and to airspace capacity 

limitations predicted to occur in sectors adjacent to the weather. 

When significant convective activity is forecasted to develop in an area of the NAS, FAA traffic managers 

identify those areas as Flow Constrained Areas (FCAs), and they may implement a Severe Weather 

Avoidance Plan (SWAP) (e.g., playbook routes), to safely divert traffic around those weather-impacted 

regions. In order to provide traffic managers and aircraft operators with ample time to prepare and 

allocate the necessary resources where needed, playbook routes are identified two to six hours prior to 

the time the constraint is predicted to develop. This lead time and the associated uncertainties in 

weather forecasts often result in the selection of overly conservative playbook routes to ensure safety

and to help avoid widespread route changes. 

The current system lacks automation tools to enable traffic managers to quickly identify and coordinate 

workable reroutes. Traffic managers and airspace users can manually identify and request more efficient 

routes, but the associated workload required to coordinate numerous reroutes is very high at a time 

when these managers are very busy. When large-scale reroutes are made, the revised routes generally 

yield a suboptimal compromise among weather avoidance, throughput, and route efficiency. 

Recent efforts have provided more flexible operational tools to account for dynamic changes. A notable

example is the Collaborative Trajectory Options Program (CTOP), which allows operators to file multiple 

routes based on the amount of delay to which the flight is subjected and the operators’ associated 

preferences for that flight. Although this capability provides a level of improvement over traditional 

single-route flight plans and rerouting procedures, it is not available for airborne flights. 

Automation tools for traffic managers and controllers can continuously monitor weather development 

and movement, determine the efficacy of associated flow constraints, and dynamically identify workable 

opportunities for time- and fuel-saving corrections to weather-avoidance routes, providing the potential 

to significantly improve efficiency in en route airspace operations. 

 
9

4 MULTI-FLIGHT COMMON ROUTE (MFCR) CAPABILITY 

Over the past several years, NASA has developed and tested a ground-based automation application 

called Multi-Flight Common Route (MFCR) to support en route delay recovery. This application is 

designed to assist traffic flow managers in efficiently rerouting airborne traffic after the original 

weather-avoidance routes have become outdated due to evolving convective weather systems [2]. 

MFCR is an extension of NASA’s Dynamic Weather Routes (DWR) capability, which in turn is based on 

the Direct-To tool developed and tested at NASA from 1998 through 2001 [3][4][5]. DWR is a dispatcher 

tool that identifies dynamic time-saving reroutes for individual flights within a Center to avoid 

convective weather. MFCR is a traffic manager tool that builds on DWR by simultaneously monitoring 

and evaluating flight trajectories in all 20 Centers to identify common reroutes that provide the greatest 

overall time savings for multiple flights on similar routes. Although capable of identifying individual 

reroute opportunities, MFCR’s primary function is to identify common routes that can be flown by a 

group of flights operating in the same vicinity. 

Grouping flights on a common reroute makes more efficient use of constrained airspace, such as gaps in 

convective weather, and reduces the number of reroute recommendations that need to be evaluated

and coordinated by a traffic manager. Thus, more flights are able to benefit from timely reroutes when 

airspace constraints or traffic manager workload would otherwise prevent individual reroutes.

MFCR currently avoids convective weather, active Special Use Airspaces (SUAs), and Temporary Flight 

Restrictions (TFRs), but it could avoid any constraint that is defined by polygons, such as overloaded 

airspace sectors and turbulence. The better the constraint information provided to MFCR, the better the 

MFCR reroute recommendations and the lower the traffic manager effort needed to implement those 

recommendations. 

4.1 CAPABILITY DESCRIPTION 

MFCR processes flights in all 20 Centers across the NAS. It begins to monitor and analyze trajectories

once flights climb to 15,000 feet, and it will recommend time-saving weather-avoidance reroutes for 

groups of flights operating above FL250 within the same Center. The time savings predicted for each 

group account for the effects of winds. The default minimum savings threshold for a group of flights is 

10 minutes, with each individual flight saving at least 3 minutes, but these parameters may be adjusted 

by the user to best address the current operational conditions. 
10

Figure 1: Structure of MFCR solution

Figure 1 shows the basic structure of an MFCR solution consisting of a Maneuver Start Point (MSP), a

Merge Point (MP), and a Return Capture Fix (RCF). Up to two auxiliary waypoints for weather avoidance

may be added between the MSP and MP, as well as between the MP and RCF. The MSP is unique to

each flight in the group and is located at a point five minutes (user adjustable) downstream of the 

flight’s current position. This lead time allows enough time for traffic managers to evaluate, modify, and 

coordinate the reroute, and for controllers to issue clearances and deconflict flights prior to the merge 

point. MFCR selects an RCF waypoint that is as far downstream as typically acceptable in local Center 

operations and is common to the original flight plan routes for all the flights in the group. This point

represents the flight plan fix at which the flights return to their original flight plan route.

Reroutes avoid convective weather, SUAs, and TFRs scheduled to be active at the time the reroute 

transits the airspace. Due to the number and variety of other constraints that may impact a direct route, 

the MFCR algorithm does not avoid all operational constraints, such as congested sectors, sector 

traversal restrictions (e.g., crossing arrival/departure sectors, proximity to sector boundaries), fixcrossing restrictions, or other restrictions imposed by letters of agreement. The variables and complex 

factors associated with these types of constraints are extremely difficult to implement effectively in 

automation tools without imposing requirements on a multitude of other systems. Instead, MFCR 

provides the user with constraint information and a user-friendly trial planning function that allows the

user to tailor reroutes to fit the operational scenario.
11

Named fixes are used for all waypoints for ease of use where available; otherwise, waypoints are 

defined by fix, radial, and distance (FRD). A snap-to named fix capability automatically replaces any 

auxiliary waypoints with nearby named fixes for ease of use in voice-based operations, but traffic 

managers may still opt to use a FRD fix. The current flight plan trajectory and the MFCR reroute 

trajectories are both analyzed for sector loading and conflicts with active SUAs or TFRs. All conflicts are 

displayed on the user interface, thereby providing immediate feedback to the user about the suitability 

of a MFCR recommended reroute or a user modification of a recommended reroute. Recommended 

reroutes and all the associated data are also updated every minute with traffic updates.

Figure 2: Example of MFCR Direct Route Limit Regions

The default location of the RCF is intended to approximate an operationally acceptable route clearance

based on direct routes historically approved for flights in the Center. Direct route clearance data 

collected for the previous one-year period are used to create “limit polygons” for each Center, as 

denoted by the cyan colored polygons in the example shown in Figure 2. The three limit polygons shown 

in Figure 2 are for Minneapolis Center (top), Fort Worth Center (bottom-left), and Atlanta Center 

(bottom-right). Each limit polygon spans multiple Centers. MFCR will select a waypoint, common to all 

the flight plan routes within the group, which is on or close to the downstream boundary of the limit 

polygon of the Center in which the flights are currently located. This method indirectly accounts for 
12

Center preferences and routine constraints. A more complete set of Traffic Flow Management (TFM)

and Air Traffic Control (ATC) constraints may enable use of other methods to extend the range within 

which RCFs may be selected. 

MFCR checks downstream Time-Based Flow Management (TBFM) arrival metering constraints for each 

flight before including it in the recommended reroute. The MFCR research prototype uses a simple 

proxy for this check, based on distance to destination. As long as a flight is outside its destination’s TBFM 

planning horizon, it will be considered for inclusion in time-saving reroutes. Future integration between 

MFCR and TBFM could enable the negotiation of a revised scheduled time of arrival (STA) for flights 

inside the TBFM planning horizon based on reroute savings and permit these flights to benefit from 

MFCR’s en route delay recovery. Flights inside the TBFM freeze horizon would still be excluded from 

MFCR reroutes.

4.2 USER INTERFACE AND PROCEDURES 

MFCR reroute recommendations are presented to the appropriate TMC, who evaluates and modifies it

as needed. Figure 3 shows an example of the user interface. The bottom left portion of the display lists 

recommended group reroutes, showing overall savings for the group and the number of flights in the 

group. Selecting a group in this pane highlights the line in yellow and brings up a list of flights for that 

group in the lower right portion of the display with a breakdown of individual flight savings, the Center 

in which the flight is currently located, inclusion of the flight in a TMI, conflicts with congested sectors

and SUA, and waypoints for each flight’s new route. Individual flights can be omitted from the group by 

checking the “remove” box on this list.

The upper portion of the Graphical User Interface (GUI) includes a trial planner interface in the left pane, 

with active flight plan and trial-plan (recommended reroute) sector loading maps in the right panes. As 

the trial plan modifications are made, all information related to the reroute is updated accordingly, 

providing the user with immediate feedback and enhanced situational awareness. Yellow-colored

sectors indicate that demand is predicted to exceed sector capacity, but some of the flights are not yet 

airborne. Red-colored sectors indicate that demand is predicted to exceed sector capacity and all of the 

flights are currently airborne, which implies a higher level of confidence in the prediction. Various 

factors impact sector capacity, but not all of those are known to automation systems. Rather than 

routing around congested sectors, MFCR presents sector congestion information in the GUI, allowing

the user to evaluate and modify the routing based on operational need.
13

Figure 3: MFCR Display
14

Once the traffic managers find a recommendation to be operationally suitable, they coordinate with 

Area Supervisors for the sectors that currently control the flights in the group, as well as with traffic 

managers in other facilities that would be affected by the recommended reroute. Coordination with the 

Air Traffic Control System Command Center (ATCSCC) may also be necessary. This coordination could 

take place via customary voice communication or by integrating automation, such as the Advanced 

Flight-Specific Trajectories (AFST, formerly Strategic Traffic Flow Management Application (SFMA)), 

and/or the MFCR interface itself [6]. When the traffic manager accepts the MFCR recommendation via 

the GUI, the corresponding flight plan amendments are sent to the air traffic displays of the appropriate 

sector controllers by using the AirBorne ReRoute (ABRR) capability. The sector controllers then offer the 

reroute to the pilots of the affected flights via Data Comm or voice communications. The flight crews 

coordinate their proposed reroutes with their dispatchers, if necessary, and once the flight crews accept

the new routes, the sector controller(s) implement the corresponding flight plan amendment in the 

automation system.

In Figure 3, the green routes depict the current flight plan routes. In this example, these routes 

represent “LEV West Partial” playbook routes, which are typically used when a large weather system in 

the south-central U.S. blocks transcontinental traffic. These playbook routes merge westbound traffic 

from the southeastern U.S. at Three Rivers, TX (THX) and send the traffic via intermediate waypoints to 

El Paso, TX (ELP), after which traffic follows standard jet routes to destinations in the western U.S. In the 

illustration, these routes are still in effect even though the weather has moved to the north, as depicted 

by yellow, orange, and red contours in the large map on the left of the figure. This capability presents an 

opportunity for time-saving, constraint-free MFCR reroute recommendations, shown by yellow lines.

The MFCR recommendation in Figure 3 identifies nine flights in Houston Center that are recommended

to be merged at fix LEJON, the Merge Point, and then sent direct to ELP, the Return Capture Fix. The 

new routes of these nine flights are estimated to provide a total time savings of 53 minutes at an 

average of about 6 min per flight. These flights have been organized into a new flow along the common 

route segment from LEJON to ELP. If this new flow continues to be free of weather, there is also an 

opportunity to update the playbook routes assigned to other flights and provide time savings to aircraft 

that are currently upstream of this route modification. This option would provide a beneficial 

intermediate routing solution prior to lifting the playbook restriction entirely when the weather 

dissipates fully.

Traffic managers may also access the MFCR savings decay feature that shows approximately how the 

overall savings of a recommended reroute group would decline as the implementation of a 

recommended reroute is delayed; Figure 4 shows an example. One reason for delaying the issuance of a 
15

reroute would be the need to perform other, more urgent traffic management tasks. The savings decay 

graph provides TMCs with a decision aid to determine how long they have to respond to the reroute 

recommendation before significant potential savings are lost. 

Another reason to delay responding to a recommended reroute would be to wait for additional flights 

that will soon enter the Center to join the reroute group. MFCR currently identifies these flights by 

highlighting them in red, as shown in Figure 3 (see close to KCLT at the top right of the large pane), and 

it provides the TMC with the means to identify estimated time savings for each flight if it were to be 

rerouted once within the Center’s airspace. In some cases, waiting for MFCR to add more flights in the 

reroute group will increase total flight-time savings and avoid the need to coordinate multiple groups. 

TMCs can use this information in combination with the estimate in the savings-decay graph to decide 

when to start coordinating the reroute recommendation.

Figure 4: Reroute Savings Decay Over Time

4.3 CONVECTIVE WEATHER MODEL 

MFCR uses outputs from FAA’s Corridor Integrated Weather System (CIWS) and Convective Weather 

Avoidance Model (CWAM) to identify routes that will avoid convective cells. CIWS forecasts the growth, 
16

decay, and movement of convective weather (see Figure 5). Forecasts are updated every five minutes 

with a two-hour look-ahead time in five-minute increments. This allows MFCR to identify alternative 

routes that remain clear of predicted weather between the MSP and RCF. 

Figure 5: CIWS and CWAM Forecast Sample

CWAM provides polygons, from FL250 to FL450 in 1,000 foot increments, around convective cells that 

pilots are predicted to deviate around, based on storm intensity, echo tops, and look-ahead time. A 

CWAM polygon is identified by the percentage of pilots who would deviate around the storm at that 

distance based on extensive historical data. For example, a 70% CWAM polygon represents a region that 

70% of pilots would avoid. A 70% CWAM polygon will be smaller (or sometimes the same), with 

boundaries closer to the weather cells, than a 60% CWAM polygon.

Figure 6: CIWS Cell and Corresponding 60, 70, & 80% CWAM Polygons

Figure 6 shows an example of the difference between 60%, 70%, and 80% CWAM polygons. CWAM 

polygons are updated with the CIWS forecast. MFCR currently uses 70% CWAM polygons for weather 
17

avoidance when generating reroute recommendations, but it can be adapted to use polygon-based 

convective weather model outputs from other sources, if desired.

MFCR logic includes gap detection and rejection logic to ensure that a gap between CWAM polygons is 

large enough to safely route aircraft. This function includes a distance buffer that will reject a route 

amendment if it will go through a gap that is narrower than 50 nautical miles laterally on either side of 

the route to the predicted cells at the time the aircraft reaches the point closest to the cells (see Figure 

7). The gap-width parameter is user adjustable.

If convective cells are predicted to encroach on one side of a trajectory but not on the other (blue 

polygons in left graphic in Figure 7), it is generally not considered an operational problem because there 

is room for flight crews to maneuver around the cell. MFCR avoids narrow gaps, which are defined as a 

condition where cells are predicted to be on both sides of the trajectory at points within 50 nautical 

miles along-track distance of one another (pair of yellow polygons in right graphic of Figure 7).

Figure 7: MFCR Gap Detection

 

 

50 nm
18

4.4 MFCR USE CASE 

The table below summarizes the process to implement a reroute using MFCR.

Step 1:

Traffic Management 

Coordinator (TMC) 

Evaluation, Approval,

and Dissemination

• The MFCR display and interface resides in the TMU and 

continually runs in the background. The adjustable parameters 

(e.g., savings threshold, convective cell buffers) are set by the 

user.

• When MFCR identifies reroutes that could save more time than 

the minimum savings threshold, it posts a list of each flight 

grouping and a list of those flights in order of greatest flight time 

savings. Each new MFCR group posted to the list triggers an 

audible alert. 

• The traffic managers on duty hear the alert and review and 

modify the proposed MFCR route(s) as needed. They then

coordinate the candidate reroute with the impacted Front Line 

Managers (FLMs) and downstream TMUs, as needed, to make 

any additional modifications.

• The traffic manager then forwards vetted reroutes to the sector 

controller(s) currently handling the flights by using the AirBorne 

ReRouting (ABRR) system.

Step 2:

Sector Controller 

Review and Clearance 

• The Sector Controller receives the proposed MFCR reroute(s) via 

ABRR, amends routes for traffic avoidance, if needed, and offers 

route amendment to flight crew(s) via voice communications or 

data communications, when available.

Step 3: 

Flight Crew Review, 

Coordination and 

Acceptance

• The flight crew receives the proposed MFCR route clearance and

reviews and evaluates the new route using on-board navigation, 

weather detection systems, and aids. If the proposed MFCR route 

impacts airline plans, the flight crew may ask the controller to 

stand by while they coordinate the change with their dispatcher. 

After review, the flight crew accepts or declines the clearance. 

• If declining, the crew may suggest an amendment, which the 

controller will approve, disapprove, or continue to negotiate for a 

compromise.

• Once the controller and flight crew agree on the reroute, the 

controller(s) issue the clearance, the flight crew(s) accepts the 

clearance, and the flight plan routes are updated in the 

automation systems.

• Should storm cells encroach on their new route, the crew(s) will 

use normal avoidance and ATC communication procedures.

• MFCR will continue to search for additional savings. 

 
19

5 SYSTEM DEPENDENCIES 

MFCR currently relies on information from other FAA systems as outlined below. 

Traffic Data – One-minute track updates are used to determine current state of flights. (Source: TFMS)

Flight Plan Data – Flight plan updates for airborne flights are used to determine flight identification, 

destination, current and planned route and waypoints, and estimated times of arrival (ETAs). (Source: 

TFMS)

Arrival Metering Data – Arrival metering data is used to identify flights that are subject to arrival 

metering constraints in order to determine if a flight is eligible for an MFCR reroute. (Source: TBFM)

Current and Forecast Wind Data – Wind data is used to compute wind-adjusted time savings of 

potential routes and determine the most efficient group reroute. (Source: NOAA Rapid Refresh Wind 

Model)

Current and Forecast Convective Weather Data – FAA Corridor Integrated Weather System (CIWS) 

provides MFCR with convective weather data (two-hour forecast in five-minute increments) and is 

combined with the Convective Weather Avoidance Model (CWAM) to provide MFCR with pilot deviation 

probability polygons for MFCR’s weather avoidance logic. (Source: FAA)

Aircraft Type and Performance Data - Aircraft-type performance tables are used for computing 

climb/cruise/descent trajectories and fuel-savings. (Source: Eurocontrol Base of Aircraft Data (BADA) or 

equivalent data)

Airspace Adaptation Data – Airspace data are obtained to identify airports, waypoints, airways, 

departure procedures, STARs, and Center and sector boundaries. (Source: 56-day Chart Change Updates 

(CCU))

Sector Congestion Data - Sector congestion is determined by using the Monitor Alert Parameter (MAP).

(Source: FAA)

Center Reroute Limit Polygons – Reroute limit polygons are used to determine how far downstream to 

place the Return Capture Fix (RCF) for a reroute. The underlying data is obtained by processing the 

previous one-year of trajectory data for all Centers to identify direct clearances issued by controllers.

(Source: TFMS track data recordings, plus special processing)
20

Reroute Traffic Management Initiatives (TMI) – TFM route restrictions are used to identify flights 

subject to route (and/or other) TMIs. (Source: TFMS)

Special Use Airspace (SUA) and Temporary Flight Restrictions (TFRs) Data – Scheduled SUA and TFR 

data are the basis for SUA/TFR avoidance. (Source: sua.faa.gov and tfr.faa.gov websites)
21

6 POTENTIAL FUTURE ENHANCEMENTS 

Based on feedback from subject matter experts (SMEs) and researchers that have evaluated and 

developed the MFCR application, a number of enhancements, described below, should be considered 

for implementation if and when the FAA fields the system. 

Negotiation of Scheduled Time of Arrival (STA) – If a flight is within the TBFM planning horizon and 

subject to arrival metering at its planned destination, it is currently excluded from consideration for 

time-saving MFCR reroutes. However, if the flight has not yet reached its freeze horizon, there may be 

sufficient flexibility in the TBFM arrival sequencing and spacing that would allow a flight to arrive earlier. 

Limited integration between MFCR and TBFM may enable simplified negotiation between the two 

systems and allow MFCR flights to move to an earlier STA, depending on its distance from the 

destination and/or uncertainty in arrival scheduling. 

User-Selected Return Capture Fix (RCF) – MFCR currently selects an RCF that is common to the original 

flight plans in the group and is close to the downstream border of the limit polygon. The RCF selected by 

MFCR is currently fixed and cannot be changed by the user. This software limitation should be removed

in the fielded version to allow the user to change the RCF location, just as the other waypoints in the 

reroute may be changed. Depending on how this capability is implemented, it could potentially reduce 

savings or alter system requirements. For example, savings could be compromised if the new RCF 

selected is not as far downstream, or if flights drop out because the revised RCF is not in their original 

flight plan routes. Alternatively, if the requirement for the RCF to be part of the original flight plan 

routes is removed, MFCR or associated automation systems would need to fill in the necessary route 

segments to return each flight to its original route downstream of the RCF in order to maintain route 

continuity. In any case, selection of acceptable RCF fixes could be supported by a drop-down list with 

pre-approved possibilities based on revised RCF requirements.

Center Limit Polygons Defined by Traffic Flow Managers – Direct route clearance data collected for the 

previous one year is used to create “limit polygons” for each Center. These polygons can be modified by 

the user and can be adjusted in MFCR to allow users to amend the polygons periodically to account for 

updates in airspace, inter-facility agreements, and operational practice. 

Combined Limit Polygons – MFCR RCF limit polygons are implemented on an individual Center basis; 

hence the scope of MFCR reroute recommendations and the selected RCFs is at the Center level. In 

some situations, substantially larger benefits may be obtained by generating recommendations for 
22

reroutes that extend beyond the limit polygons and traverse multiple Centers. This is particularly 

applicable to the use of MFCR by a Traffic Management Specialist (TMS) at the ATCSCC. By adding the 

capability to combine the limit polygons for selected Centers, a TMS could generate multi-Center 

reroute recommendations, as desired. 

Combined Savings Decay and Growth Graph – In MFCR’s current implementation, the traffic manager 

decides when to start coordinating a reroute recommendation by mentally combining two pieces of 

information: (1) the savings decay of the reroute group as time progresses, and (2) the savings growth as 

new flights get added to the reroute group. Combining these two sources of information into a single 

graph, showing the net increase or decrease of savings over time, would enable an easier and more 

accurate assessment of when to start coordination of a reroute recommendation.

Display Sector Loading Change – Sector maps are currently displayed on the GUI separately for current 

and recommended routes (with yellow and red indicators of congestion), enabling the user to determine 

how the recommended routes would increase or decrease sector loading by comparative examination 

of the data. The sector loading display feature could be enhanced by directly displaying the change

between the current and projected downstream sector loading in a single graphical representation. This 

would provide direct feedback to the user about the impact of recommended reroutes on downstream 

sector loading and congestion, eliminating the need for two windows.

Additional Constraints – MFCR is capable of avoiding any constraints that can be defined by a polygon. 

With the proper attributes and definitions, constraint avoidance could be expanded beyond convective 

weather, SUA, and TFRs to include factors such as congested sectors, arrival and departure corridors, 

areas of turbulence, and sectors in which controller training is taking place. Enhanced logic that avoids

routing flights along sector boundaries or cuts through corners of sectors would also increase the 

acceptance of MFCR suggested routes [7].

Altitude Changes – MFCR reroutes are currently limited to lateral deviations. Adding the vertical 

dimension to MFCR time-saving recommendation capabilities could increase the benefits. There may be 

times when reroutes could take advantage of altitude changes to more easily avoid constraints, such as

vertically limited convective cells or arrival/departure corridors. MFCR recommendations for vertical 

maneuvers may alleviate some of those limitations and permit the flight to move to a more fuel-efficient

altitude. 

Data Comm Integration – The use of Data Comm would greatly reduce the workload of controllers, 

pilots, and dispatchers while increasing situational awareness by allowing them to review and negotiate 
23

reroutes more quickly and easily [8][9]. More rapid communication and coordination of reroutes would 

reduce workload. Data Comm integration would also allow MFCR routes to be defined and 

communicated using dynamic coordinates rather than named waypoints or FRD fixes, increasing the 

flexibility of MFCR to avoid constraints.

 
24

7 REFERENCES 

[1] S. McMahon, “National Airspace System Efficiency,” FAA End of Season Review, Washington 

DC, October, 2014

[2] Kapil Sheth, Alexis Clymer, Alex Morando, Fu-Tai Shih, “Analysis of Multi-Flight Common Routes 

for Traffic Flow Management,” AIAA Aviation Technology, Integration, and Operations 

Conference, June 2016

[3] David McNally, Kapil Sheth, Chester Gong, John Love, Chu Han Lee, Scott Sahlman, Jinn-Hwei 

Cheng, “Dynamic Weather Routes: A Weather Avoidance System For Near-Term TrajectoryBased Operations,” 28th International Congress Of The Aeronautical Sciences, 2012 

[4] D. McNally, et al., “Operational Evaluation of Dynamic Weather Routes at American Airlines,” 

Tenth USA/Europe Air Traffic Management Research and Development Seminar, Chicago, IL,

June 2013 

[5] Banavar Sridhar, Gano B. Chatterji and Shon R. Grabbe, “Benefits of Direct-To Tool in National 

Airspace System”, IEEE Transactions on Intelligent Transportation Systems, Volume 1, Issue 4,

December 2000

[6] S. Kamine, L. Askey, B. Bateman, M. Hokit, S. Janssen, T. Stewart, B. Yaklich, “Preliminary 

Concept of Operations for Strategic Traffic Flow Management Application,” MITRE Technical 

Report (MTR140493), December 2014

[7] Bilimoria, K.D., Hayashi, M., and Sheth, K., “Subject Matter Expert Evaluation of Multi-Flight

Common Route Advisories,” AIAA Aviation Technology, Integration, and Operations Conference,

June 2017

[8] D. McNally, C. Gong, S. Sahlman, “Integration of Dynamic Weather Routes Automation with 

Air/Ground Data Communications,” 2015 Integrated Communication Navigation and 

Surveillance (ICNS) Conference, April 2015 

[9] C. Gong, C. Santiago, R. Bach, ”Simulation Evaluation of Conflict Resolution and Weather 

Avoidance in Near-Term Mixed Equipage Datalink Operations,” 12th AIAA Aviation Technology, 

Integration, and Operations Conference, Indianapolis, IN, September 2012