Documents
Resources
Learning Center
Upload
Plans & pricing Sign in
Sign Out

Data Comm RFI Follow Up 031708

VIEWS: 6 PAGES: 303

									              REQUEST FOR INFORMATION/MARKET SURVEY
            COMMUNICATION SERVICES/DATA COMMUNICATIONS

This announcement is a follow up to prior Request for Information (RFI)/Market
Surveys. This announcement is NOT A SCREENING INFORMATION REQUEST
(SIR) OR REQUEST FOR OFFER (RFO) of any kind. Further, the FAA is not
seeking or accepting unsolicited proposals.

All interested parties are advised that the FAA will not pay for any information or
any administrative costs incurred that are associated with any response received
from industry in response to this announcement. Therefore, any costs associated
will be solely at the interested party’s expense.


Background

The Federal Aviation Administration (FAA) has initiated an investment analysis process
to evaluate the alternatives for a Data Communications program to provide Air/Ground
services with the aircraft, as a critical element of achieving the Next Generation Air
Transportation System (NextGen) vision for air traffic control. These services are
described in the attached Data Communications Initial Program Requirements (iPR)
document with some additional background material provided in the Communications
Operating Concepts and Requirements (COCR) document.

Current Status

The FAA has released two prior Requests for Information (RFI) related to the Data
Communications program; one seeking information on the air-ground network and
related infrastructure (#5470), and one related to the ground system, en route automation,
and related processing functions (#6034). The responses to these previous RFIs did not
explicitly address some business and technical considerations involved in procuring a
Data Communications air-ground service that integrates the components of the air-ground
systems. The FAA seeks additional discussions with industry that will expand the
previous RFI responses to address these issues and address specific questions about
previous RFI responses.

Approach

The Data Communications program will be implemented incrementally. Currently three
phases are planned, in which the first will provide air traffic services (ATS) using data
communications as a supplement to voice communications. For these Segment 1 (S1)
operations, services will be implemented in en route airspace and at selected air traffic
control towers. Accommodation for aircraft equipped with FANS-1/A+ is being
investigated, using the interoperability requirements stipulated in RTCA SC-189 PU-40.
The second segment includes updates and improvements to standards, expansion of
service to selected TRACON environments and additional services that expand the use of
4D-trajectories and enable advanced air traffic operations which require data
communications. The third segment expands segment 2 capabilities as the final step
towards enabling the NextGen operational concepts.

The FAA expects to begin initial Segment 1 Data Communications operations in (2013-
2015) followed by the expanded Segment 2 services starting in (2018-2019). The Data
Communications program will provide service to equipped aircraft during Segment 2 and
beyond, as the operational procedures and definition of affected airspace are developed.
Segment 1 and Segment 2 will utilize VDL Mode 2 for the data subnetwork and will
employ ATN networking. Current analyses indicate that VDL Mode 2 will be sufficient
to support Segment 3 services and air traffic demand. The Data Communications
program will update these analyses as the Segment 3 services are finalized, and more is
known about future traffic profiles.

Focus Area

From analysis of responses the FAA received from the previous RFIs, the FAA has
determined that focused discussions with industry would be mutually beneficial. The
FAA seeks clarification and further exploration of these responses, focused on industry
perspectives regarding options for a potential service that integrates the components of
the air-ground system into an overall Data Communication service. FAA Data
Communications service is defined to include all data communications functions from
air-ground message delivery back to the interface with the application protocols. Figure 1
provides a notional illustration of the major functional components for the ground
elements of a Data Communications system.


Figure1.



     En Route                   Data
    Automation             Communications                                         ATN
                                                                                  Stack
                             Applications
                           & Message Mgmt
                                                          Application Protocols




     TRACON                                                                                Communications
    Automation                                                                    FANS /
                                                                                             (Air-Ground
     Interface            • Controller-Pilot Data Link                            ACARS
                                                                                           Message Delivery)
    Functionality thru    Communication                                           Stack
     C-ARTS/STARS         • Automatic Dependent
                          Surveillance (ADS-C)
                          • Flight Information Services
       Tower                                                                        IP
    Automation                                                                    Stack
     Interface
    Functionality thru     Connection Mgmt
          TDLS



                         Monitoring & Control


                                    Ground-Ground Message Delivery
Given the existing and projected National Airspace System architecture, the Data
Communications capabilities must integrate with existing FAA Automation systems to
provide integrated user interfaces to the controllers and system managers. The FAA
remains interested in exploring the options associated with Data Communications as a
service that integrates the components of the air-ground systems and seeks industry input
to identify the business and technical opportunities as well as challenges for providing the
necessary functional and performance capabilities.

Enclosures

Included are several appendices which provide relevant material:


Appendix A, FAA Initial Program Requirements


Appendix B, TDLS Airports

Appendix C, Communications Operating Concepts and Requirements, Version 2.0.

Appendix A is the current requirements framework for the Data Communications System.
Appendix B provides a listing of the airports currently expecting to have coverage with
this service.
Appendix C is included as it provides an additional background on the subset of
applications called out in Appendix A


Discussions

Industry response is welcome as the FAA continues to conduct the investment analysis
regarding the acquisition of communications services. The FAA will entertain supporting
relevant meetings and /or demonstrations with interested parties from industry. To
request a meeting, please email a proposed agenda, contact information and suggested
dates, to Dana Brooks at dana.brooks@faa.gov. Upon review, the FAA will contact the
interested party to set up the meeting.

During these meetings, the FAA reserves the right to discuss responses to these previous
RFIs in order to seek better understanding or clarification of the submittal. Disclosure
constraints associated with material marked Proprietary will be fully respected.
Communications with one industry representative do not necessitate communications
with others.

Any information provided under this request is for informational purposes only and will
not be released to the public. Any proprietary information submitted must be adequately
marked as proprietary and will be protected if appropriately marked.
If there are any questions concerning this RFI/Market Survey, contact Dana Brooks at
202-267-8704.
                                   Suggested Topics

The FAA is interested in obtaining industry input on potential business models, and the
system integration, transition, and operational implications of service contract (s) for
services (external to the demarcation point of legacy automation). These services would
include the air-to-ground subnet, ATN service, and the ground-ground network. The
FAA is also interested in discussing concepts concerning system monitoring and control
and the extensibility of all services to meet Segment Two requirements.


The FAA is also interested in further discussions about the role a Service Provider (SP)
could have in structuring an affordable business model to enable FAA goals for reduction
of operational costs, as well as facilitating equipage among the user community.
______________________________________________________________________

Below are some questions that address the suggested topics. These questions are not all
inclusive and should not limit preparation for these discussions.
Questions:

Establishing a Service:

   -   Could the SP provide all services beyond the demarcation point of the legacy
       automation systems, or would the FAA need to provide other system elements?

   -   How would you address business and technical challenges involved with the
       successful integration of existing FAA automation systems and the data
       communications applications?

   -   How would potential Data Communication service business models be structured
       to ensure affordability and what would be the impact to such variables as
       commodity being procured, cash flow requirements, length of contract, fee
       structure, and ownership?

   -   How might the provision of data communications as a Data Communication
       service be used to facilitate equipage among the user community?

   -   How would the SP analyze and allocate requirements to maximize use of COTS
       software, minimize duplicate development in different domains, and plan for
       evolution to later segments?

   -   What risks are envisioned in integration of sub-elements outside the SP’s control,
       and how would the risks be mitigated?

   -   Are there any commercial uses of the SP infrastructure that would enable the SP
       to spread system operating costs over a wider customer base?
   -   If the SP did not provide the Subnetwork, how would the vendor assure system
       performance under peak loading conditions?

   -   As stated in the previous RFI, if the FAA ATO were to provide real estate for
       radio sites as a government-furnished resource, would the SP be interested in
       using these facilities?


Operating and sustaining a service:

   -   How would the SP operate the system for the FAA to ensure required system
       performance is consistently achieved? Given that Data Comm is a controller-pilot
       network that relies on Avionics performance to provide service, how would the
       SP interact with the NAS user community?

   -   Does implementing a service facilitate the transition from today’s current state to
       an end state ATN network?

   -   The Data Comm Segment 1 service performance requirements are similar to those
       achieved by current airline operational control service provider networks.
       Segment 2 services will likely require significantly better network performance in
       terms of security, availability and latency. How would the Service Provider plan
       for and manage this upgrade?

   -   What are the implications of a potential FAA requirement to enable transition of
       the data communications services, from a network over which both AOC and
       ATC message traffic would flow, to a network in which ATC message traffic is
       delivered via a separate, dedicated air/ground network? What barriers or
       opportunities might be faced? What sort of cash flow/return on investment would
       be required to overcome any such barriers? What unique advantages might be
       realized?

   -   What are the implications of a potential FAA requirement for a separate,
       dedicated ATS air/ground network for Segment One? What barriers or
       opportunities might be faced? What sort of cash flow/return on investment would
       be required to overcome any such barriers? What unique advantages might be
       realized?

   -   At the end of the contract, how would the SP envision transition of the service to
       the next SP (assuming that the FAA would not retain any physicals assets at
       contract conclusion)?
Initial Program Requirements
              for
    Data Communications




         September 18, 2007




    Federal Aviation Administration
     800 Independence Avenue SW
        Washington, DC 20591
(intentionally left blank)
                        Program Requirements
                                        for

                               Data Communications


Approved by: ________________________            Date: ___________

Vice President, Operations Planning (ATO-P)

Approved by: ________________________            Date: ___________

Vice President, Technical Operations Services (ATO-W)

Approved by: ________________________            Date: ___________

Vice President, En Route and Oceanic Services (ATO-E)

Approved by: ________________________            Date: ___________

Vice President, Terminal Services (ATO-T)

Approved by: ________________________            Date: ___________

Vice President, System Operations Services (ATO-R)


Concurrence by: _______________________          Date: ___________

Director, Office of Systems Engineering, ATO-P


Submitted by: ___________________________        Date: ___________

Manager, ATC Communications Services, Data Communications Program, ATO-W


Focal Point

Gregg Anderson

Technical Operations, ATC Communications,

       Data Communications Program, AJW-55

Phone: 202-493-4779
(intentionally left blank)
                                                             Table of Contents
1.     BACKGROUND ........................................................................................................6
     1.1      MISSION NEED ................................................................................................................ 6
2.     OPERATIONAL CONCEPT .................................................................................10
     2.1      OPERATIONS ................................................................................................................. 10
     2.2      MAINTENANCE.............................................................................................................. 31
     2.3      QUANTITIES AND LOCATIONS ....................................................................................... 31
     2.4      SCHEDULE CONSTRAINTS ............................................................................................. 32
3.     TECHNICAL PERFORMANCE...........................................................................33
     3.1      OPERATIONAL AND FUNCTIONAL REQUIREMENTS....................................................... 33
     3.2      PRODUCT CHARACTERISTICS AND PERFORMANCE REQUIREMENTS ............................ 46
4.     PHYSICAL INTEGRATION .................................................................................55
     4.1      REAL PROPERTY ........................................................................................................... 55
     4.2      RESERVED ................................................................................................................. 55
     4.3      ENVIRONMENTAL ......................................................................................................... 55
     4.4      ENERGY CONSERVATION .............................................................................................. 55
     4.5      HEATING, VENTILATION, AND AIR CONDITIONING ...................................................... 56
     4.6      GROUNDING, BONDING, SHIELDING, AND LIGHTNING PROTECTION ............................ 56
     4.7      CABLES ......................................................................................................................... 56
     4.8      HAZARDOUS MATERIALS.............................................................................................. 57
     4.9      POWER SYSTEMS AND COMMERCIAL POWER............................................................... 57
     4.10     TELECOMMUNICATIONS ............................................................................................... 57
     4.11     SPECIAL CONSIDERATIONS ........................................................................................... 57
5.     FUNCTIONAL INTEGRATION...........................................................................59
     5.1      INTEGRATION WITH OTHER FAA ENTERPRISE ARCHITECTURE ELEMENTS ................ 59
     5.2      INFORMATION REQUIREMENTS ..................................................................................... 59
     5.3      SOFTWARE INTEGRATION ............................................................................................. 59
     5.4      SPECTRUM MANAGEMENT............................................................................................ 60
     5.5      STANDARDIZATION ....................................................................................................... 61
6.     HUMAN INTEGRATION ......................................................................................62
     6.1      HUMAN SYSTEMS ENGINEERING .................................................................................. 62
     6.2      HUMAN MACHINE INTERFACE ...................................................................................... 63
     6.3      EMPLOYEE SAFETY AND HEALTH................................................................................. 70
7.     SECURITY...............................................................................................................72
     7.1      TECHNICAL CONTROLS ................................................................................................. 72
     7.2      MANAGEMENT CONTROLS............................................................................................ 74
     7.3      OPERATIONAL CONTROLS ............................................................................................ 75
8.     IN-SERVICE SUPPORT ........................................................................................77
     8.1      STAFFING ...................................................................................................................... 77
     8.2      SUPPLY SUPPORT .......................................................................................................... 77
     8.3      SUPPORT EQUIPMENT ................................................................................................... 78
     8.4      TECHNICAL DATA ......................................................................................................... 78
     8.5      TRAINING AND TRAINING SUPPORT.............................................................................. 79
     8.6      FIRST- AND SECOND-LEVEL REPAIR ............................................................................ 79


                                                                            2
     8.7       DEPOT MAINTENANCE .................................................................................................. 79
     8.8       PACKAGING, HANDLING, STORAGE, AND TRANSPORTATION ....................................... 80
     8.9       DISPOSAL ...................................................................................................................... 80
     8.10      FACILITY CODES ........................................................................................................... 80
     8.11      PROJECT MATERIAL MANAGEMENT ............................................................................. 81
     8.12      TECHNICAL OPERATIONS CERTIFICATION .................................................................... 81
9.     TEST AND EVALUATION ...................................................................................82
     9.1       CRITICAL OPERATIONAL ISSUES ................................................................................... 82
     9.2       TEST AND EVALUATION REQUIREMENTS ..................................................................... 82
10.         IMPLEMENTATION AND TRANSITION .....................................................84
     10.1      DEPLOYMENT PLANNING .............................................................................................. 84
     10.2      GROUND INFRASTRUCTURE IMPLEMENTATION ............................................................ 87
     10.3      TRANSITION .................................................................................................................. 88
     10.4      IN-SERVICE TRANSITION ............................................................................................... 89
     10.5      ATC FACILITIES INTERFACE ......................................................................................... 90
     10.6      DATA PRESENTED TO SERVICE PROVIDERS.................................................................. 90
     10.7      COEXISTENCE WITH PRESENT SYSTEM......................................................................... 90
     10.8      IMPLEMENTATION CONSIDERATIONS ........................................................................... 90
11.         QUALITY ASSURANCE ...................................................................................91
     11.1      QUALITY ASSURANCE PROGRAM ................................................................................. 91
12.         CONFIGURATION MANAGEMENT..............................................................92
     12.1      NAS CONFIGURATION MANAGEMENT CHANGE CONTROL PROCEDURES ................... 92
13.         IN-SERVICE MANAGEMENT.........................................................................93
     13.1      PRODUCT BASELINE ..................................................................................................... 93
     13.2      PERFORMANCE MONITORING ....................................................................................... 93
14.         SYSTEM SAFETY MANAGEMENT ...............................................................94
     14.1      SAFETY ASSESSMENTS ................................................................................................. 94
     14.2      INTEGRATED SAFETY PLAN .......................................................................................... 94
     14.3      RISK ACCEPTANCE AND SAFETY RISK MANAGEMENT DOCUMENTATION APPROVAL 94
     14.4      STANDARDS .................................................................................................................. 94
APPENDIX A MISSION SHORTFALL CORRELATION MATRIX .....................96

APPENDIX B ACRONYMS........................................................................................100

APPENDIX C DEFINITIONS.....................................................................................103

APPENDIX D REFERENCES ....................................................................................107

APPENDIX E COCR MAPPING TO DATA COMMUNICATIONS SERVICES111

APPENDIX F TERMINAL SITE LISTS ...................................................................113

                                                               Table of Figures




                                                                            3
Figure 2-1 Data Communications ATS Functions by Flight Phase.............................................. 11
Figure 3-1 High Level Functional Architecture Diagram ............................................................. 33




                                                          4
                                                    Table of Tables

Table 3-1 Minimum Air/Ground Message Capacity per Flight for Segment One........................ 47
Table 3-2 Minimum Air/Ground Message Capacity per Flight for Segment Two ....................... 49
Table 3-3 Minimum Air/Ground Message Capacity per Flight for Segment Three ..................... 52
Table 14-1 Segment One TDLS Sites......................................................................................... 113
Table 14-2 Segment Two Tower Sites........................................................................................ 115
Table 14-3 Segment Two TRACON Sites.................................................................................. 118




                                                              5
1.    BACKGROUND

The following sections describe the mission need and the safety, capacity, and efficiency and
productivity shortfalls that substantiate the mission need.

1.1       Mission Need

The Federal Aviation Administration (FAA) has established an operational plan for the Air
Traffic Management (ATM) system of the twenty-first century. In this plan the National
Airspace System (NAS) will rely increasingly on advanced capabilities provided by ground and
airborne Air Traffic Services (ATS) Provider (ATSP) Systems. NAS Concept of Operations and
Vision for the Future of Aviation and the Joint Planning and Development Office (JPDO)
concepts of use, require transmission of complex trajectory clearances, weather information and
air traffic advisories.

In the future ATM environment it will no longer be possible to rely exclusively on voice
messages for the exchange of information. Transition from voice for flight crew-controller
communication to a predominance of data communication has been identified as a key goal for
Air Traffic Control (ATC).

The addition of data communications will support improvements in airspace use and capacity.
Data communications will:

      •    Provide for a more efficient air/ground (A/G) information exchange mechanism
      •    Provide an additional means of communication between flight crews and controllers
      •    Reduce congestion on the voice channels
      •    Reduce operational errors and flight crew deviations resulting from misunderstood
           instructions and read back errors
      •    Enable trajectory based operations
      •    Reduce controller and flight crew workload.

The evolution of data communications in the U. S. air transportation system is anticipated to
occur in three segments. The first segment will facilitate data communications deployment and
introduce initial 4-D (four dimensional; latitude, longitude, altitude, and time) routes. The
second segment will introduce conformance management and initial 4-D agreements. The third
segment will expand 4-D agreements and provide an operational environment that allows the
transfer of some separation assurance tasks from the ground to the air.

1.1.1      Mission Shortfall

As the NAS transforms to achieve the JPDO Next Generation Air Transportation System
(NextGen) vision, and concepts of use for trajectory-based flight and Information Management,
most of the planned operational improvements will be implemented via data communications.
The overall shortfall is that the current NAS does not have an air/ground data communications
capability.



                                                  6
Specific related performance gaps include the following:
   • Safety shortfalls
   • Capacity shortfalls
   • Efficiency and productivity shortfalls.

It is recognized that the scope of the mission shortfalls identified herein are broader than will be
addressed solely by a data communications capability. During the course of investment analysis,
an understanding of the joint contributions of a portfolio of capabilities will need to be
addressed; for example, an assessment of trajectory based operations will need to encompass the
joint effects of data communications, automation, traffic flow management, and required
navigation performance. None of these discrete investments can deliver their full potential
benefits without the synergies arising from their joint integration. This mission shortfall
statement is a step in the process of defining the entire mission shortfalls to be addressed in
realizing the NextGen concept of operations.

1.1.1.1   Safety Shortfalls

Current communication capabilities cannot adequately convey the information required between
air traffic controllers and airspace users to assure that target levels of safety can be provided in an
environment of increased demand for access to airspace. The ability to issue complex clearances
to manage aircraft-to-aircraft and aircraft-to-airspace conflicts, as well as implementation of
weather avoidance strategies, is limited. Expanded aircraft status reporting, real-time airspace
access support and new ground decision support system integration is needed. Some symptoms
of this shortfall, as cited in the August 2006 Mission Shortfall Statement, include:
     • Peak communication workload demands on the Radar controller take a larger portion of
         the controller's available cognitive resources.
     • Situations conducive to producing errors, confusion, read-back and hear-back errors
         arising from voice congestion and voice communication quality.
     • Inability to implement a coherent "sector resource management” concept for the sector
         team where air/ground communication workload can be shared.
     • Alternate means to enable air/ground communication support for contingency plans when
         the primary voice communication capability is not available. For example, when a
         catastrophic event results in the loss of air/ground voice communication at an Air Route
         Traffic Control Center (ARTCC) or during transient events such as a “stuck microphone”
         in the cockpit.

Eliminating these shortfalls will result in fewer air/ground communication errors which lead to
operational errors and flight crew deviations.


1.1.1.2   Capacity Shortfalls

Key capabilities needed to support NextGen operational demands are not resident in the existing
air/ground communication systems. Performance gaps include:
    • The capability to rapidly and accurately communicate complex clearances containing
        multiple latitude/longitude-defined route elements, such as those associated with High



                                                  7
          Altitude Airspace Design; arrival and approach procedure names; and, speed, altitude,
          and heading instructions and preferences.
   •      The ability to more effectively manage inter- and intra-facility sector air/ground voice
          communication transfer.
   •      The ability to efficiently communicate air traffic instructions such as altimeter settings
          and aircraft beacon codes.
   •      The ability to disseminate efficiently, airspace congestion and weather advisories; and
          NAS infrastructure status information.
   •      The ability to efficiently communicate complete departure clearances and revisions
          necessitated by traffic management initiatives.
   •      The ability to provide for the maximum efficient use of the airspace and strategic plans by
          adjusting individual flights to reduce contention for resources and assure no resource is
          allowed to remain idle in the face of demand.
   •      Limited ability to use four-dimensional trajectories associated with flight objects and the
          airspace plan to identify areas of congestion, and the potential need for flow control
          initiatives to mitigate severe congestion.

Potential solutions for capacity capability shortfalls must address applicable end-to-end
performance and technical interoperability requirements, as defined through the appropriate
regulatory process.


1.1.1.3     Efficiency and Productivity Shortfalls

Critical operational capabilities are not available in the existing communication infrastructure.
The August 2006 Mission Shortfall Statement documents gaps between the current voice-driven
communications system and future needs in areas of safety, capacity, efficiency, service, and
infrastructure. Paramount in the data communications system mission shortfall statement is the
need for the Air Traffic Organization (ATO) to reduce unit cost for operations and increase
productivity to meet growing demands for services. In the statement of ATO efficiency
shortfalls, key performance gaps include:
    • Lack of the ability to support airspace user operational requirements, utility, performance,
        and other flight operations preferences. Avionics and airframe manufacturers need
        consistent global communication capabilities requirements.
    • Lack of the ability to exchange user preferred trajectories in real time. There are limited
        decision support tools to communicate and ensure user preferred routing, integrated
        sequencing, and spacing of arrivals and departures in Terminal Radar Approach Control
        (TRACON) airspace.
    • Absence of synchronization between on-board avionics, such as Flight Management
        Systems, with ground Flight Data Processing Systems. Lack of synchronization between
        airborne and ground-based ATC increases controller and flight crew workload, imposes
        additional communications requirements, and introduces risks of operational errors and
        incidents. Providing for synchronization between aircraft flight management systems and
        ground-based ATC data processing systems provides increased predictability for flights
        and will allow aircraft operators to reduce costs, optimize flight routes, improve utility,
        and reduce dependency on voice communications.



                                                   8
   •    Misaligned communications infrastructure and service delivery to meet anticipated
        growth in the number of sectors and areas of specialization that must be supported for a
        given airspace combined with the high cost for hiring additional/maintaining current
        controller staff, leads to smaller and smaller sectors thus increasing flight crew/controller
        workloads and increased cost.
   •    Currently, air/ground communication capabilities are not integrated with other aspects of
        the automation environment. Instructions to and requests from airspace users must be
        independently exchanged via voice air/ground communications and then manually
        updated in automation systems such as the flight data processor leading to system errors
        and less efficient movement of aircraft through the airspace.
   •    Inability to handle multiple, simultaneous traffic management initiated trajectory changes
        is limited to single voice transmissions that are prone to miscommunications and may
        lead to system errors.
   •    Inability to automate many repetitive and time-consuming tasks precludes labor resources
        from focusing on more productive tasks.
   •    The current communication system lacks the capabilities inherent in modern, network-
        based communications and therefore limits more efficient dynamic resource management.

Better service to customers will result in less airspace user delays; increased flexibility of the
NAS in response to airspace user demands; better knowledge-sharing; and increased schedule
predictability for airspace user operations.

Potential solutions for productivity capability shortfalls must address applicable ATO business
case expectations and be in consonance with the JPDO NextGen Integrated Plan.

1.1.2   Technology Opportunity

The JPDO NextGen vision identifies technology opportunities for the implementation and use of
data communications as an enabling service for conflict probe (CP) and traffic flow management
(TFM) automation capabilities.

A data communications architecture is envisioned that will employ a globally interoperable
International Civil Aviation Organization (ICAO) message set integrated with both ground and
air automation. Implementation is expected in multiple segments leading to the implementation
of trajectory based operations.




                                                  9
2.    OPERATIONAL CONCEPT

The following sections provide a description of the proposed data communications operations.
The implementation of data communications in three segments is described with operational
scenarios describing typical data communications services to be made available in each segment,
in addition to the services implemented in the previous segment(s).

2.1   Operations

Data communications will take on an ever increasing role in controller to flight crew
communication, contributing significantly to the increased efficiency, capacity, and safety of the
NAS. The evolution of data communications in the operational environment will be based upon
the incremental implementation of advanced communication capabilities. Data communications
represents the first phase of the transition from the current analog voice system to an ICAO
compliant system in which digital communication becomes an alternate and eventually
predominant mode of communication.

The JPDO NextGen System will make use of 4-D Trajectory Management as the core concept for
ATM in 2025. Use of 4-D trajectory management acknowledges that all basic decisions, across
all time horizons, are fundamentally related to the trajectory. 4-D trajectories are exchanged via
data communications between aircraft/aircraft operators and ground automation systems.

Data communications capabilities will be fully integrated into controller workstations and the
flight deck. Data communications will provide an additional means for two-way exchange
between controllers and flight crews for ATC clearances, instructions, advisories, flight crew
requests and reports. Routine communication will be increasingly handled by data
communications for appropriately equipped users.

NextGen will affect sector resource management and the coordination amongst the sector control
team, traffic flow management personnel, and automation. Research is currently being planned
and conducted (e.g., Multi-Sector Planner) to determine the extent to which data communications
functions can be shared amongst members of the control team, traffic flow management
personnel, automation or other ATC entities. Whichever methodology proves to be most cost
beneficial, the data communications system remains largely independent of these functional
architecture boundaries. Provided appropriate interfaces are established to access the data
communications functions, data communications can operate in various modes simultaneously.

A regulatory strategy to ensure equipage is envisioned to be necessary in order to develop
performance-based airspace and have aircraft data communications equipage in place to handle
the anticipated air traffic growth while maintaining an acceptable level of system efficiency.

Data communications in the NAS is envisioned to be implemented in three segments to meet the
mission shortfalls in a practical, evolutionary approach to achieve the NextGen vision. The basis
of the functions in this document is the Communications Operating Concept and Requirements
for the Future Radio System, COCR Version 2.0, dated May 4, 2007. The following sections
describe the services and capabilities envisioned for each segment of the data communications in
support of NextGen.


                                                10
Figure 2-1 shows a typical flight profile and the ATS functions supporting the user in each
domain.




              Figure 2-1 Data Communications ATS Functions by Flight Phase

2.1.1   Segment One (2012 and beyond)

The initial capabilities will concentrate on implementation in the tower and en route
environments and will serve as the initial building block for trajectory based operations.

In the tower environment, the first segment in implementing data communications capabilities
will provide for new methods for delivery of departure clearances, revisions, and taxi
instructions. In the en route environment, data communications will provide the basic
capabilities for controllers and flight crews to transfer ATC clearances, requests, instructions,
notifications, voice frequency communications transfers, and flight crew reports as a supplement
to voice. Subsequently, initial 4-D routes to manage continuous descent approaches will be
implemented on a limited basis at certain airports with aircraft meeting capability requirements.

2.1.2   Segment Two (2017 and beyond)

Segment Two data communications extends data communications capabilities to the TRACON
domain. These data capabilities will not only provide a more efficient means to support strategic



                                                11
communication within traditional terminal airspace but will also support the expansion of
NextGen trajectory based operations into other portions of terminal airspace.

In addition, data communications capabilities will be expanded to include 4-D trajectory
agreements in performance-based airspace. The initial portion of the 4-D trajectory is agreed to
be stable and conflict free and will only change for exceptions, while subsequent portions of the
trajectory may be updated as necessary.

Segment Two also adds trajectory conformance management to monitor the trajectory based
clearances. Data communications facilitates conformance management by providing the means
for the aircraft and the ground system to exchange the detailed data necessary to perform
conformance management without the direct involvement of the flight crew or controller. Three
types of conformance management agreements are envisioned: periodic, event-based, and on-
demand. The aircraft’s capability to accurately fly its cleared route of flight and improvements in
conformance predictability, either through ground automation improvements, interaction with
traffic flow management and flight operations centers or through the provision of aircraft intent
data, will increase the precision of trajectory modeling and enable new concepts in separation
assurance.

The exact mechanism for this capability (e.g., automatic dependent surveillance broadcast, point
to point addressed applications, ground automation conflict prediction improvements) is still to
be determined. Research will determine the most cost-effective and technically superior
approach to increasing the certainty of an aircraft’s future position. The data communications
system design will be flexible enough to accommodate the chosen approach.

A regulatory strategy will become effective requiring data communications capabilities to be part
of the aircraft’s minimum equipment requirements for access to performance-based airspace.
The regulatory strategy will ensure a level of aircraft equipage such that the benefits of data
communications in performance-based airspace will be realized. This expansion, including the
regulatory strategy and implementation of enhanced data communications, provides the basis for
evolving the NAS from tactical control to management-by-planning and intervention-by-
exception. This is also the time when traffic levels are projected to rise to the point where voice
communications is anticipated to restrict air traffic growth, and therefore data communications
will evolve to become the necessary means of air-ground communications.

2.1.3   Segment Three (2022 and beyond)

Segment Three will add data communications capability that will support delegation of
separation responsibility to the flight crew and increased situational awareness through
distribution of aircraft specific route of flight environmental characteristics to include weather,
NAS status, system constraints, and collaborative decision making information. Ground
automation enhancements have expanded the time horizon for detection of conflicts beyond that
available in Segment Two. This provides even longer term predictability to the 4-D trajectory
agreements which are now commonplace. Performance-based airspace has been expanded to
include lower altitudes in the en route domain connecting to super-density TRACON airspace at
selected regional airport domains.




                                                12
2.1.4     Operational Scenarios

The following scenarios illustrate how the capabilities described above will be used in the
operational environment as the implementation of data communications evolves in the NAS.
These scenarios describe the nominal operations. Generally, there are variations on the
operations that are acceptable, but are not presented in these scenario descriptions. The
variations would occur less frequently than the typical operations.

In all three segments, there will be a mix of aircraft with respect to data communications
equipage in certain portions of the airspace. Some aircraft will not be equipped with data
communications and are provided with ATC services using traditional voice methods. These
aircraft are referred to as legacy equipped and typically fly in the lowest altitude strata. Other
aircraft will be equipped with one of two levels of data communications capabilities: basic and
high performance (HP). Aircraft equipped to utilize the Segment One services are identified as
basic equipped. Aircraft equipped to utilize the full services provided by Segment Two and
Three are identified as HP equipped. The following scenarios describe the capabilities of basic
and HP data communications.


2.1.4.1     Segment One

The following sections provide a data communications scenario for Segment One.


2.1.4.1.1    Pre-Departure

The flight crew prepares the aircraft for the flight and, in particular, they initiate data services
with the ground data communications system, which recognizes the initiation and responds with
appropriate data communications information.

In response to a flight crew request, and where available via data communications, the ground
provides relevant textual weather information, field conditions, approach and departure runways,
plus local notices to airmen related to the departure airfield.

The flight crew requests a departure clearance from the tower. The controller/automation uses
arrival/departure sequence information and any traffic flow constraints related to the aircraft, to
formulate the departure clearance. If the requested clearance has already been created, the
ground system replies with the departure clearance. If the requested clearance does not yet exist,
the ground system delivers the request to the assigned controller who sends the clearance to the
flight crew via data communications. The routing information supports multiple formats e.g.,
ATS routes, fix names, or 4-D trajectories. Should the route of flight change while the aircraft is
still at the gate, the controller will decide to issue the revised departure clearance through data
communications or by voice, depending on the dynamics of the situation.


2.1.4.1.2    Departure Taxi and Take-Off




                                                 13
Once the flight crew compares and validates the departure clearance against the filed flight plan,
the flight crew requests a taxi route instruction using data communications. The assigned
controller reviews the taxi route instruction the automation suggests is appropriate for the
aircraft, and upon approval, sends the taxi route instruction via data communications.

Due to convective weather along the filed route of flight, traffic management programs are
instituted and as a result, the aircraft receives a revised departure clearance while in the taxi
queue. The controller will decide to use voice or data communications to provide the revised
departure clearance as it becomes available. Due to rapidly changing conditions, there may be
multiple revised departure clearances generated and sent to the aircraft.

The last automatic controller-flight crew data exchange on the airport surface takes place no later
than 10 minutes prior to predicted departure (wheels up) time. Manual data communications
exchanges, e.g., a revised departure clearance or a departure time notification, will continue to
take place as determined by the controller/flight crew. Surface air traffic control data
communications cease once the aircraft has been cleared for takeoff.

The flight crew receives, via voice, takeoff clearance and instructions to contact the next
TRACON control position via voice. From takeoff clearance until the aircraft checks in with the
En Route facility, ATC will not employ data communications in this timeframe.


2.1.4.1.3    Departure in TRACON Airspace

As the aircraft leaves the airport environment and enters TRACON airspace, the flight crew
follows the departure clearance and contacts the departure controller using voice. All
communication services in the departure TRACON airspace are conducted via voice in the
Segment One timeframe. Communications handoff from the TRACON to the first en route
sector is via voice. 1


2.1.4.1.4    Domestic En Route Airspace

After completing the initial contact by voice, communications with the first en route controller is
conducted through data communications. The data communications system automatically
validates the aircraft’s Mode-C and confirms the assigned altitude for the receiving controller.
The controller takes necessary action to alleviate conflicts using air traffic control voice or data
communications clearance services as appropriate. The flight crew responds in the same mode
and flies the aircraft according to the instructions given. The controller employs decision support
tools to assist in implementing traffic management initiatives or routings based on local
constraints. New route clearances are uplinked through data communications. The flight crew
enters the new routing into the aircraft flight management system and follows the new clearance.

       1
        During the transition from domains which are equipped for data communications to those that are not, the data communications
       system must have knowledge of what control position/facility is equipped to provide data communications services. Managing the
       data communications eligibility transfer to that control position in a manner which protects the integrity of data communications to
       ensure that errors are not introduced by inadvertent data communications exchanges before eligibility is established is of
       paramount importance and will be a key requirement of the FAA’s Data Communications infrastructure.




                                                                  14
At this time, the controller determines that the voice channel in use has been blocked. In order to
address this concern and free the voice channel for communications, the controller initiates a data
communications uplink to all equipped aircraft in his/her sector requesting that the flight crew
check for voice radio malfunction. Within moments, the blockage of the frequency is resolved
and the controller re-establishes voice communications for tactical instructions as necessary.

In conjunction with the ground automation handoff, which is done automatically unless the
controller takes an extra action to prevent it, data communications provides the next voice
frequency to the flight crew, and transfers the data communications eligibility to the next sector
or Center. The data communications system automatically validates the aircraft’s Mode-C
reported altitude and confirms the assigned altitude for the receiving controller.

The flight crew uses data communications to request and receive relevant information, including
textual weather, arrival airport field conditions, and local notices to airmen for the destination
airport.

As the aircraft prepares for the transition from level cruise to descent, the appropriate controller
uses data communications to provide scheduled time over fix information to the flight crew. The
flight crew uses on-board tools to create a route request, which consists of a 4-D trajectory to
meet the constraint, tailored to the aircraft’s performance and airline preferences. The flight crew
then downlinks to the en route controller the route request that meets the scheduled time over fix.
The controller coordinates the request with the arrival TRACON airspace via ground-to-ground
communications and the en route controller initiates the transmission of a data communications
response containing the confirmed clearance. The en route controller generates a handoff to the
TRACON and data communications provides the next voice frequency for the TRACON arrival
sector. The flight crew then contacts the TRACON controller via voice. At the appropriate
transition point, controller-flight crew data communications are terminated. Data
communications may continue to be used for information services where available.


2.1.4.1.5   Arrival TRACON Airspace

The aircraft flight management system flies the trajectory using a Standard Terminal Arrival
Route (STAR) or Area Navigation (RNAV) route when appropriate. The controller can
intervene via voice if a situation requires immediate action. If the controller needs to optimize
traffic flows, to the extent possible the trajectory of non-equipped aircraft will be altered before
taking an equipped aircraft off such negotiated 4-D trajectories. All controller-flight crew
communications are issued via voice in the arrival TRACON airspace during Segment One
timeframe.


2.1.4.1.6   Arrival Airport

All controller-flight crew communications are via voice during airport arrival operations in
Segment One. The flight crew contacts the tower runway controller who monitors the traffic
situation and intervenes, if required. The tower runway controller issues the landing clearance to



                                                 15
the flight crew, provides a recommended runway exit, and directs the flight crew to contact the
ground controller at the appropriate time.


2.1.4.1.7    Arrival Taxi

During Segment One, all controller-flight crew communications during the arrival taxi phase are
via voice. The flight crew contacts the tower ground controller who issues taxi information. The
flight crew then maneuvers the aircraft to the arrival gate.


2.1.4.2     Segment Two

The following sections provide a data communications scenario for Segment Two.

Equipage requirements for entry into performance-based airspace are now in effect resulting in
more aircraft being equipped with data communications capability. The data communications
capability includes integration of the aircraft communications functions and the flight
management system navigation function for direct transfer of the clearance information.
Expansion of the data communications capability, including conformance management into
TRACON airspace has occurred by the end of the Segment Two timeframe. The use of data
communications in Segment Two begins as an alternative to voice and transitions over time to
the required method of communications enabling trajectory based operations in larger volumes of
airspace.

Changes in services from Segment One are identified by bold face type.


2.1.4.2.1    Pre-Departure

The flight crew prepares the aircraft for the flight and initiates data services with the ground data
communications system, which recognizes the initiation and responds with appropriate data
communications information.

As part of the flight planning process, the flight crew or AOC determines that an optimal
routing will require flight into HP airspace (HPA). HPA has been established in select
regions and altitudes to segregate traffic operating on pre-negotiated trajectories.
Therefore, a proposed route including standard routing through traditional airspace, and
4-D trajectory based routing for transit through HPA is developed and loaded into the
flight management system for aircrew review. The proposed 4-D trajectory portion will be
used later in the flight to facilitate negotiation of the aircraft’s final 4-D trajectory through
HPA. If applicable, the routing will identify the desired HP Standard Instrument
Departures (HP-SIDs), Tailored Arrival and/or HP Standard Terminal Arrival Routes
(HP-STARs), accessible because this aircraft is appropriately equipped. The time element
of this 4-D trajectory will be Required Times of Arrival (RTAs) based, and are treated as
estimates, until the aircraft approaches the HPA. At that point, the 4-D trajectory
including RTAs will be updated as a route clearance for operations in the HPA.


                                                 16
In response to a flight crew request, and where available, the ground provides relevant textual
weather information, field conditions, approach and departure runways, plus local notices to
airmen related to the departure airfield via data communications.

At the request of the flight crew, ATM-related operational data for the flight (e.g.,
departure sequence, collaborative decision making agreements, and slot-time allocations)
are relayed by data communications to the flight crew in preparation for departure. In the
Segment Two timeframe, traffic managers, at both the national and local level, have
enhanced decision support tools for the assessment, planning and execution of traffic
management initiatives. This results in greater flexibility, better predictability of airspace
constraints, and improved predicted trajectories for individual aircraft provided through
4-D trajectory negotiation, trial planning and availability of aircraft intent from the user.
Traffic managers and TFM automation are able to defer issuing restrictions until closer to
the actual execution window, reducing the issuance of multiple clearances while continuing
to collaborate with the users to define optimal solutions.

The flight crew requests a departure clearance. The data communications system determines
whether or not the clearance has already been submitted to the automation system awaiting
delivery or delivers the request to the assigned controller. The controller/automation uses the
automation system that provides arrival/departure sequence information and any traffic flow
constraints related to the aircraft, to formulate the departure clearance that is sent to the flight
crew via data communications. The routing information supports multiple formats e.g., ATS
routes, fix names, or 4-D trajectories as described above for the HPA operation. Should the route
of flight change while the aircraft is still at the gate, the controller will decide to issue the revised
departure clearance through data communications or by voice, depending on the dynamics of the
situation.

After issuance of the departure clearance, the automation system generates a request via
data communications to the aircraft automation to report its active route. This information
is compared with the departure clearance to verify consistency.


2.1.4.2.2   Departure Taxi and Take-Off

Once the flight crew compares and validates the departure clearance against the filed flight plan,
the flight crew requests a taxi route instruction using data communications. The assigned
controller reviews the taxi route instruction suggested by the automation for the aircraft, and
upon approval, sends the taxi route instruction via data communications. Taxi revisions via
data communications are now provided for equipped aircraft. This maximizes efficient use
of airport resources, and as a result, the equipped aircraft is placed further ahead in the
taxi sequence. This is possible since controller and flight crew workload for equipped
aircraft is reduced; higher traffic throughput can be achieved by prioritizing equipped
departures. In addition, preferential sequencing of HP equipped aircraft is enabled.

Due to convective weather along the filed route of flight, traffic management programs are
instituted and as a result, the aircraft becomes eligible for a revised departure clearance while in
the taxi queue. Enhanced capabilities and increased access to surface data and flight status
provide traffic management automation with information about the flight’s location, taxi

                                                   17
sequence, and the departure queues. As a result, the TFM automation provides departure
clearance revisions at an operationally appropriate amount of time in advance of the
departure. This will minimize workload associated with multiple revisions. The controller
will decide to use voice or data communications to provide the revised departure clearance as it
becomes available.

The last automatic controller-flight crew data exchange on the airport surface can take place no
later than 10 minutes prior to predicted wheels up time. Manual data communications
exchanges, e.g., a revised departure clearance or a departure time notification, will continue to
take place as determined by the controller/flight crew. Once the aircraft has been cleared for
takeoff via voice, data communications manages the data communications eligibility
transfer to the next TRACON control position and surface ATC data communications cease.

The flight crew receives voice frequency communications transfer via voice.


2.1.4.2.3   Departure in TRACON Airspace

As the aircraft leaves the airport environment and enters TRACON airspace, the flight crew
follows the departure clearance and contacts the departure controller using voice. Since the
aircraft is appropriately equipped, the HP-SID procedure is followed as filed.

The controller validates the aircraft’s Mode-C and confirms the assigned altitude. Depending on
the time criticality of a given clearance, and the altitude of the aircraft, communication
services in the departure TRACON airspace are conducted via a mixture of voice and data.
Typical exchanges via data communications for a departing aircraft include altitude and
direct routing assignments. Frequency change messages to contact or monitor the next
frequency are communicated via data communications based on the handoff. The data
communications system manages the data communications eligibility transfer to the next
control position.

The automation system monitors the aircraft behavior as required, current and predicted,
to assure conformance with the given trajectory. Improvements in trajectory prediction
are provided either through ground automation algorithm improvements or through the
provision of aircraft intent data that increases the precision of trajectory modeling.
Improved trajectory predictions enable the beginning of new concepts in separation
assurance for the TRACON airspace. Since conformance management provided in
TRACON airspace may not offer the same performance as that provided in the en route
environment, this service may provide operational capabilities that differ from those
provided in en route. The conformance management capability may be used optionally per
aircraft in the TRACON domain.

Air traffic management policies are updated to ensure data-communications enabled
operations are followed-through by providing guidelines that encourage controllers to
resolve conflicts by altering unequipped aircraft flight paths before altering data-
communications equipped aircraft on agreed upon trajectories. As such, the aircraft
transitions through TRACON airspace along the predicted flight path without speed,
altitude or vector-based trajectory changes.

                                                18
2.1.4.2.4     Domestic En Route Airspace

During Segment Two, the domestic en route phase of flight for appropriately equipped aircraft
consists of two type of operations: normal operations (mixture of unequipped aircraft, data
communications capable aircraft and HPA aircraft) and HPA operations (all aircraft are HPA
qualified).


2.1.4.2.4.1    Normal Domestic En Route Airspace

Communications with the first en route controller is conducted through data communications.
The data communications system automatically validates the aircraft’s Mode-C and confirms the
assigned altitude for the receiving controller. Routine clearances with aircraft are communicated
via data communications while time critical clearances continue to be communicated by voice.
Some of the aircraft operating in this normal (not HP) airspace are equipped with full 4-D
trajectory-capable integrated data communications, while other aircraft have less capable
data communications. Those aircraft that lack ATC data capabilities rely exclusively on
voice. Only aircraft capable of communicating and conducting 4-D trajectory operations
via data communications may enter the HPA, which may initially be established at higher
en route altitudes. Agreements between the aircraft system and the ground automation are
now in place with all aircraft entering performance-based airspace and non-conformance
reports are only generated when an event occurs beyond the parameters set in the
agreement. Aircraft not properly equipped continue to operate in normal (non-HP)
airspace.


2.1.4.2.4.2    Domestic En Route High Performance Airspace

As the aircraft climbs, the controller oversees the planned flight path prior to the aircraft’s
entry into HPA, just as he or she would today. In the normal en route sector prior to HPA
entry, the controller would update the entry, exit, and other HPA constraints, if necessary.
The HPA entry, 4-D trajectory, and exit previously loaded into the flight management
system during the pre-departure phase are updated to reflect any changes made by ATC,
and to reflect the current timing and actual position of the aircraft. The aircraft downlinks
the revised requested profile, which is probed for conflicts by automation, then presented
to the controller, who will typically approve and send the HPA clearance to the aircraft. If
the automation determines a conflict will exist within the probed window of time, the
automation will suggest revised constraints for controller approval and uplink to the
aircraft. If the controller determines the conflict-free routing is sub-optimal, the controller
may revise the constraints and uplink them.

During Segment Two, HPA controllers remain responsible for separation, and remain in
the loop when issuing 4-D trajectories. However, once aircraft transition into HPA, the
controller’s role is strategic, and while maintaining situational awareness at the traffic flow
level, is expecting not to issue further instructions or clearances. Controller situational
awareness is maintained by the system depicting in real time the aircraft trajectories and

                                               19
displaying proposed changes in routes (including existing route, proposed route, conflict
creating the need, others affected, etc.) graphically for controller approval.

This transitions the HPA controller’s duties to “management by exception”, where
performance-based airspace rules dictate that the decision support tool conflict detection
and resolution capabilities provide separation assurance support functions. Since the
controller remains responsible for separation, the output of decision support tools are
reviewed by the controller and when a conflict is predicted a proposed resolution is sent to
the aircraft via data communications. This review process ensures that the controller
remains aware of the situation at a strategic level, but is not required to detect conflicts.
This allows the airspace design to be changed supporting larger areas of responsibility per
controller, thereby reducing air traffic service provider unit costs, while enabling user-
preferred 4-D routing though HPA.

While performance-based airspace enables numerous efficiencies, during this timeframe the
vertical and lateral separation standards remain unchanged. HPA represents a portion of the en
route airspace the flight traverses. In the remaining airspace, occupied by aircraft of varying
levels of equipage, aircraft continue to be managed using Segment One data communications
services, voice communications as necessary, and tactical control methods. Aircraft that are
transitioning from HPA to the arrival stream are provided with preferential treatment to
continue 4-D tailored arrival operations.

The controller assesses any trajectory changes generated by traffic management initiatives
and takes necessary action, through data communications, to alleviate conflicts by sending
a new trajectory to the flight crew. The flight crew checks whether the aircraft is capable
of complying with the proposal through the flight management system, in this particular
case the flight crew responds with an alternative trajectory. The ground automation
confirms the proposal is conflict free and provides a new trajectory agreement to the
controller for transmission to the aircraft. To prevent mistakes on re-entry of the
trajectory clearance information, the data communications airborne system and the flight
management system navigation function are interfaced, allowing direct transfer of
clearance data upon flight crew approval.

The automation system monitors the aircraft trajectory intent as required, current and
future, to assure conformance with the given trajectory. This is done through either
ground automation algorithm improvements or through the provision of aircraft intent
data that increases the precision of trajectory modeling, enabling new concepts in
separation assurance.

While operating in HPA, aircraft operating under 4-D agreements continuously compare
their current and predicted position (in time and space) to the 4-D agreement. When the
aircraft detects a pending non-conformance the aircraft automation reports a non-
conformance to the ground system. The ground system generates a proposed resolution,
which would include a new set of conflict avoiding trajectory constraints for the aircraft to
follow. The proposed constraints are reviewed by the controller, and if approved, uplinked
to the aircraft automation, which translates the constraints into a new, proposed 4-D route
of flight for flight crew review. Upon acceptance, the aircraft downlinks the revised
routing, which is validated as conflict–free and displayed to the controller, who performs a

                                               20
strategic assessment of the routing, accepts the new 4-D agreement and releases the
automation generated 4-D trajectory clearance. Upon receipt, the aircraft automation
displays the 4-D trajectory in the clearance, indicates it matches the 4-D request, and
transfers the trajectory data to the flight management system active route when accepted
by the flight crew.

By this time, it has become common practice for controllers to accept recommendations
from these tools to eliminate conflicts several sectors downstream in a strategic fashion.
Knowledge of the actual pending conflict is not necessary. The tactical methods employed
earlier in Segment One, where recognition of conflicts within ones own area of
responsibility was recognized by the controller and mitigated in a tactical fashion, have
begun to fade. Conflict resolution tools forward highest ranked resolutions to upstream
controllers to mitigate conflicts in advance versus waiting for the conflict to be resolved by
the controller at the point of conflict. Additionally, where controllers used to provide
“short cuts” to the flight crew in order to shorten the route of flight, the ATM system in
Segment Two is increasingly reliant on predictable routings, so this method of providing
operational benefit has also faded. These changes to the operating paradigm are an
accepted practice in Segment Two.

The flight crew requests relevant information for the weather, airport field conditions and local
notices to airmen for the destination airport through data communications. Selected aircraft
parameters are monitored by data communications-enabled conformance management
capability which decreases controller and flight crew workload and improves surveillance
performance.

Since the aircraft’s position in high-performance airspace is more readily predicted further
out ahead of the aircraft, when initiatives are implemented to mitigate congestion in
airspace ahead of the aircraft, aircraft in HPA will have more time to execute cost-efficient
adjustments. In addition, improved predictability may reduce the likelihood that aircraft
operating in HPA are included in the congestion mitigating traffic flow initiatives.

At approximately 200 miles away from the destination airport, while in HP airspace, the 4-
D trajectory is updated to ensure the aircraft crosses the fix at the handoff to TRACON
airspace as required.

As the aircraft approaches the Top of Descent position, the appropriate controller provides
scheduled time of arrival information to the flight crew via data communications. The flight
crew then downlinks a route request to the en route controller, through data communications,
which is composed of a tailored 4-D trajectory based on the aircraft’s performance. The
controller coordinates the request with the arrival TRACON airspace via ground-to-ground
communications and the en route controller initiates the transmission of a data communications
response containing the confirmed clearance.

During Segment Two, aircraft will typically exit HPA and descend through normal
airspace before entering TRACON airspace. If negotiated and agreed in advance, the
aircraft may continue on a 4-D tailored arrival, which may include a continuous descent
approach, into the TRACON. While the 4-D trajectory operations in HPA were optimized to
reflect the predictability enabled by all aircraft in the HPA operating on 4-D trajectories, these 4-


                                                 21
D tailored arrivals conducted outside HPA will be conducted recognizing the effects of mixing
equipage and capabilities as found on the aircraft in normal airspace. Aircraft exiting HPA and
conducting a 4-D tailored arrival may access a wedge of airspace, established above current
arrival/descent airspace that allows procedural segregation from aircraft conducting the
traditional step descent arrivals.

In conjunction with the ground automation handoff, which is done automatically unless the
controller takes an extra action to reject it, data communications provides the next frequency to
the flight crew, and transfers the data communications eligibility to the next sector or Center.
The data communications system automatically validates the aircraft’s Mode-C reported altitude
and confirms the assigned altitude for the receiving controller.

Policies have been changed where unequipped aircraft are moved first to mitigate conflicts
supporting service-for-equipage philosophies. Automation tailors resolutions based on
aircraft capabilities e.g., 4-D trajectory changes for HP equipped aircraft and ATS route,
fix name, or altitude changes for basic equipped aircraft.

Tasks for controllers monitoring performance-based airspace are essentially the same as in
mixed performance airspace, but the frequency of execution is reduced by a large degree.

The en route controller generates a handoff to the TRACON airspace and data communications
provides the voice frequency for the TRACON airspace arrival sector to the flight crew and
manages the data communications eligibility transfer.


2.1.4.2.5   Arrival TRACON Airspace

The flight crew contacts the TRACON controller via data communications. The data
communications system automatically validates the aircraft’s Mode-C reported altitude,
and confirms the assigned altitude and ATIS code for the receiving controller. The
TRACON controller employs data communications to relay the initial information on
approach expectations, potential airport information changes, and initial clearances.

The aircraft flight management system flies the trajectory using an HP-STAR, which is an
HP arrival route optimized for aircraft equipped for HP operations. If available, the
aircraft may have previously negotiated an even more efficient arrival based upon an
aircraft-specific continuous descent profile. Selected aircraft parameters continue to be
monitored by the conformance management function through data communications which
decreases controller and flight crew workload and improve surveillance performance. If
the aircraft descends too close to the ground, warnings are automatically communicated via
data communications or by voice if warranted. Routine clearances are communicated via
data communications while time critical clearances continue to be issued via voice if a situation
requires near term action. Should aircraft flying tailored arrival procedures receive voice
instructions to change course, the 4-D trajectory agreement is nullified.

Once the aircraft is established on the approach, a data communications clearance to execute
the approach is issued. An instruction to monitor the tower voice communication



                                               22
frequency is subsequently issued via data communications. Data communications manages
the data communications eligibility transfer.

These new operating methods have relieved much of the tasking previously done manually
by the controllers resulting in capacity, throughput, and efficiency gains.


2.1.4.2.6    Arrival Airport

All controller-flight crew communications are issued via voice. The tower runway controller
contacts the flight crew to provide relevant traffic and landing clearance information while
monitoring the traffic situation. After the aircraft lands, the tower runway controller issues
runway exit and directs the flight crew to contact the ground controller.


2.1.4.2.7    Arrival Taxi

The tower ground controller clears the flight crew to taxi via voice or data communications
depending upon the dynamics of the situation and monitors the traffic situation as they
maneuver the aircraft to the arrival gate.


2.1.4.3     Segment Three

The following sections provide a data communications scenario for Segment Three.

In Segment Three, aircraft will have an even wider range of capabilities than in Segment Two,
supporting varying levels of total system performance via on-board capabilities and associated
crew training leading to a further expansion of performance-based airspace. This will include the
ability to perform delegated separation, spacing, and merging tasks and to precisely navigate and
execute 4-D trajectories.

The mode of operation described under the Segment Two scenario is now in common use for all
aircraft. The ground automation capability for detecting and planning conflict free trajectories
has extended the time horizon predictability for these agreements. Every aircraft seeking to
operate in performance-based airspace is now equipped with a cockpit display capable of high
definition graphics. This allows the use of advanced concepts in ATM, based on graphical
depictions of the surrounding aircraft and airport situation. These advances allow ATM to be
conducted on a Management by Planning and Intervention by Exception basis for much of the
separation assurance function.

Changes in services from Segment Two are identified by bold face type.


2.1.4.3.1    Pre-Departure




                                                23
The flight crew prepares the aircraft for the flight and, in particular, they initiate data services
with ground data communications which recognizes the initiation and responds with appropriate
data communication information.

As part of the flight planning process, the flight crew or AOC determines that an optimal routing
will require flight into HPA. HPA has been established in select regions and altitudes to
segregate traffic operating on pre-negotiated trajectories. Therefore, a proposed route including
standard routing through traditional airspace, and 4-D trajectory based routing for transit through
HPA is developed and loaded into the flight management system for aircrew review. The
proposed 4-D trajectory portion will be used later in the flight to facilitate negotiation of the
aircraft’s final 4-D trajectory through HPA. If applicable, the routing will identify the desired
HP-SIDs, Tailored Arrival and/or HP-STARs, accessible because this aircraft is appropriately
equipped. The time element of this 4-D trajectory will be RTAs based, and are treated as
estimates, until the aircraft approaches the HPA. At that point, the 4-D trajectory including
RTAs will be updated as a route clearance for operations in the HPA.

In response to a flight crew request, and where available, the ground provides relevant weather
information, field conditions, approach and departure runways, plus local notices to airmen
related to the departure airfield via data communications.

ATM-related operational data for the flight (e.g., departure sequence, collaborative decision
making agreements, and slot-time allocations) are relayed by data communications to the flight
crew, by subscription, in preparation for departure.

In advance of a planned departure, users now file 4-D trajectory-based flight plans for
operations in HPA. Users and air traffic service providers collaboratively negotiate 4-D
trajectory agreements from take-off to approach, based on user requests and anticipated
constraints. This agreement is embedded in the departure clearance. The final point in the
clearance also includes the required time constraint for the arrival fix.

The flight crew requests a departure clearance. The data communications system determines
whether or not the clearance has already been submitted to the automation system awaiting
delivery or delivers the request to the assigned controller. The controller/automation uses the
automation system that provides arrival/departure sequence information and any traffic flow
constraints related to the aircraft, to formulate the departure clearance that is sent to the flight
crew via data communications. The routing information supports multiple formats e.g., ATS
routes, fix names, or 4-D trajectories as described above for the HPA operation. Should the route
of flight change prior to departure, a revision will be issued through data communications or by
voice depending on the dynamics of the situation.

After issuance of the departure clearance, the ground automation system generates a request via
data communications to the aircraft automation to report its active route. This information is
compared with the departure clearance to verify consistency.


2.1.4.3.2   Departure Taxi and Take-Off




                                                 24
The flight crew requests approval to taxi the aircraft using data communications. The assigned
controller provides a detailed taxi route instruction response which has been suggested by the
automation system then approved by the controller, containing specific directions to follow. This
taxi route may be displayed on an airport map in the cockpit.

Taxi revisions via data communications are now provided for equipped aircraft which maximizes
efficient use of airport resources, and as a result, the equipped aircraft is placed further ahead in
the taxi sequence. This is possible since workload for equipped aircraft is reduced; both on the
ground and in the air, so higher traffic throughput can be achieved by prioritizing equipped
departures. In addition, preferential sequencing of HP equipped aircraft is enabled.

Now enhanced capabilities within traffic management programs are providing departure
clearance revisions at an operationally appropriate amount of time in advance of the departure.
This will minimize workload associated with multiple revisions.

The last automatic controller-flight crew data exchange on the airport surface can take place no
later than 10 minutes prior to predicted wheels up time. Manual data communications exchanges
will continue to take place as determined by the controller/flight crew. Surface ATC data
communications cease once the aircraft has been cleared for takeoff.

The flight crew receives take-off clearance and voice frequency communications transfer via
voice. Data communications manages the data communications eligibility transfer to the next
TRACON control position.


2.1.4.3.3   Departure in TRACON Airspace

As the aircraft leaves the airport environment and enters TRACON airspace, the flight crew
follows the departure clearance and contacts the departure controller using voice. Since the
aircraft is appropriately equipped, the HP-SID procedure is followed as filed.

The controller validates the aircraft’s Mode-C and confirms the assigned altitude. Depending on
the time criticality of a given clearance, and the altitude of the aircraft, communication services
in the departure TRACON airspace are conducted via a mixture of voice and data. Typical
exchanges via data communications for basic equipped departing aircraft include altitude and
direct routing assignments.

The aircraft follows the previously negotiated 4-D trajectory. Trajectory negotiations
conducted pre-departure typically leave some conflicts unresolved such that maximum use
of the airspace resource can be utilized. Therefore, the controller takes necessary action
via data communications to alleviate potential conflicts through the revision of the 4-D
agreement or assignment of delegated separation services e.g., Crossing and Passing. On an
exception basis tactical control is conducted via voice communications.

The automation system monitors the aircraft behavior as required, current and predicted, to
assure conformance with the given trajectory either through ground automation algorithm
improvements or through the provision of aircraft intent data that increases the precision of
trajectory modeling, enabling the beginning of new concepts in separation assurance for the

                                                 25
TRACON airspace. Since conformance management provided in TRACON airspace may not
offer the same performance as that provided in the en route environment, this service may
provide operational capabilities that differ from those provided in en route. The conformance
management capability may be used optionally per aircraft in the TRACON domain.

Air traffic management policies provide guidelines which encourage controllers to resolve
conflicts by altering unequipped aircraft flight paths before altering data-communications based
trajectories are now commonplace. As such, the aircraft transitions through TRACON airspace
along the predicted flight path without speed, altitude or vector-based trajectory changes.

The voice frequency and data communications eligibility transfers are conducted automatically
without the need for flight crew interaction.


2.1.4.3.4     Domestic En Route Airspace

The following sections describe normal domestic and HP en route operations.


2.1.4.3.4.1    Normal Domestic En Route Airspace

As communications services and the nature of air traffic control have evolved, the
communications requirements have evolved also. Trust in the system’s performance is
increased. Routine exchanges are minimized. Almost everything the flight must do is embedded
in the 4-D agreement. Agreements between the aircraft system and the ground automation are
now in place with all aircraft in performance-based airspace and non-conformance reports are
only generated when an event occurs beyond the parameters set in the agreement. Changes are
more in the context of overall trajectory maintenance. Conflict management by the controller is
still required in the en route environment so as not to over constrain the system using excessive
separation in high density operations.

In conjunction with the ground automation handoff, which is done automatically unless the
controller takes an extra action to reject it, the voice frequency and data communications
eligibility transfers are conducted automatically without the need for flight crew interaction
to the next sector or Center. The data communications system automatically validates the
aircraft’s Mode-C and confirms the assigned altitude for the receiving controller.

Communications with the first en route controller is conducted through data communications.
Routine clearances with aircraft are communicated via data communications while time critical
clearances continue do be communicated by voice. Some of the aircraft operating in this normal
(not HP) airspace are equipped with full 4-D trajectory-capable integrated data communications,
while other aircraft have less capable data communications or lack ATC data capabilities and
thus rely exclusively on voice. Only aircraft capable of communicating and conducting 4-D
trajectory operations via data communications may enter the HPA, which may initially be
established at higher en route altitudes. Aircraft not properly equipped continue to operate in
normal (non-HPA) airspace.




                                               26
2.1.4.3.4.2   Domestic En Route High Performance Airspace

As the aircraft climbs, the controller oversees the planned flight path prior to the aircraft’s entry
into HPA, just as he or she would today. In the normal en route sector prior to HPA entry, the
controller would update the entry, exit, and other HPA constraints, if necessary. The HPA entry,
4-D trajectory, and exit previously loaded into the flight management system during the pre-
departure phase are updated to reflect any changes made by ATC, and to reflect the current
timing and actual position of the aircraft. The aircraft downlinks the revised requested profile,
which is probed for conflicts by automation, then presented to the controller, who will typically
approve and send the HPA clearance to the aircraft. If the automation determines a conflict will
exist within the probed window of time, the automation will suggest revised constraints for
controller approval and uplink to the aircraft. If the controller determines the conflict-free
routing is sub-optimal, the controller may revise the constraints and uplink them.

During Segment Three, HPA controllers remain responsible for separation, and remain in the
loop when issuing 4-D trajectories. However, once aircraft transition into HPA, the controller’s
role is strategic, and while maintaining situational awareness at the traffic flow level, is expecting
not to issue further instructions or clearances. Controller situational awareness is maintained by
the system depicting in real time the aircraft trajectories and displaying proposed changes in
routes (including existing route, proposed route, conflict creating the need, others affected, etc.)
graphically for controller approval.

This transitions the HPA controller’s duties to “management by exception”, where performance-
based airspace rules dictate that the decision support tool conflict detection and resolution
capabilities provide separation assurance support functions. Since the controller remains
responsible for separation, the output of decision support tools are reviewed by the controller and
when a conflict is predicted a proposed resolution is sent to the aircraft via data communications.
This review process ensures that the controller remains aware of the situation at a strategic level,
but is not required to detect conflicts, except in unusual circumstances. This allows the airspace
design to be changed supporting larger areas of responsibility per controller, thereby reducing air
traffic service provider unit costs, while enabling user-preferred 4-D routing though HPA.

While performance-based airspace enables numerous efficiencies, during this timeframe the
vertical and lateral separation standards remain unchanged. HPA represents a portion of the en
route airspace the flight traverses. In the remaining airspace, occupied by aircraft of varying
levels of equipage, aircraft continue to be managed using Segment One data communications
services, voice communications as necessary, and tactical control methods. Aircraft that are
transitioning from HPA to the arrival stream are provided with preferential treatment to continue
4-D tailored arrival operations.

The controller assesses any trajectory changes generated by traffic management initiatives and
takes necessary action, through data communications, to alleviate conflicts by sending a new
trajectory to the flight crew. The flight crew checks whether the aircraft is capable of complying
with the proposal through the flight management system, in this particular case the flight crew
responds with an alternative trajectory. The ground automation confirms the proposal is conflict
free and provides a new trajectory agreement to the controller for transmission to the aircraft. To
prevent mistakes on re-entry of the trajectory clearance information, the data communications


                                                 27
airborne system and the flight management system navigation function are interfaced, allowing
direct transfer of clearance data upon flight crew approval.

The automation system monitors the aircraft trajectory intent as required, current and future, to
assure conformance with the given trajectory. This is done through either ground automation
algorithm improvements or through the provision of aircraft intent data that increases the
precision of trajectory modeling, enabling new concepts in separation assurance.

Data communications supports aircraft clearances to use the appropriate services to self-
separate e.g., Crossing and Passing, Sequencing and Merging or In-Trail Procedures.
Separation responsibility is delegated to the flight crew for these functions.

While operating in HPA, aircraft operating under 4-D agreements continuously compare their
current and predicted position (in time and space) to the 4-D agreement. When the aircraft
detects a pending non-conformance that will not be resolved by normal flight automation, the
aircraft automation informs the aircrew, which decides to make corrections to aircraft operations,
or to request a revised 4-D agreement. If neither is accomplished in a timely manner, the aircraft
automation reports a non-conformance to the ground system. The ground system generates a
proposed resolution, which would include a new set of conflict avoiding trajectory constraints for
the aircraft to follow. The proposed constraints are reviewed by the controller, and if approved,
uplinked to the aircraft automation, which translates the constraints into a new, proposed 4-D
route of flight for flight crew review. Upon acceptance, the aircraft downlinks the revised
routing, which is validated as conflict–free and displayed to the controller, who performs a
strategic assessment of the routing, accepts the new 4-D agreement and releases the automation
generated 4-D trajectory clearance. Upon receipt, the aircraft automation displays the 4-D
trajectory in the clearance, indicates it matches the 4-D request, and transfers the trajectory data
to the flight management system active route when accepted by the flight crew.

It has become common practice for controllers to accept recommendations from these tools to
eliminate conflicts several sectors downstream in a strategic fashion. Knowledge of the actual
pending conflict is not necessary. Conflict resolution tools forward highest ranked resolutions to
upstream controllers to mitigate conflicts in advance versus waiting for the conflict to be
resolved by the controller at the point of conflict. The ATM system is reliant on predictable
routings, so the method of providing operational benefit by giving flight crews “short cuts” in
order to shorten the route of flight has faded. These changes to the operating paradigm become
an accepted practice in Segment Three.

The flight crew requests relevant information for the weather, airport field conditions and local
notices to airmen for the destination airport through data communications. Selected aircraft
parameters are monitored by data communications-enabled conformance management capability
which decreases controller and flight crew workload and improves surveillance performance.

Since the aircraft’s position in high-performance airspace is more readily predicted further out
ahead of the aircraft, when initiatives are implemented to mitigate congestion in airspace ahead
of the aircraft, aircraft in HPA will have more time to execute cost-efficient adjustments. In
addition, improved predictability may reduce the likelihood that aircraft operating in HP aircraft
are included in the congestion mitigating traffic flow initiatives.



                                                28
At approximately 200 miles away from the destination airport, while in HPA, the 4-D trajectory
is updated and extended to ensure the aircraft crosses the fix at the handoff to TRACON airspace
as required.

As the aircraft approaches the Top of Descent position, the appropriate controller provides
scheduled time of arrival information to the flight crew via data communications. The flight
crew then downlinks a route request to the en route controller, through data communications,
which is composed of a tailored 4-D trajectory based on the aircraft’s performance. The
controller coordinates the request with the arrival TRACON airspace via ground-to-ground
communications and the en route controller initiates the transmission of a data communications
response containing the confirmed clearance.

Aircraft will typically exit HPA and descend through normal airspace before entering TRACON
airspace. If negotiated and agreed in advance, the aircraft may continue on a 4-D tailored arrival,
which may include a continuous descent approach, into the TRACON. While the 4-D trajectory
operations in HPA were optimized to reflect the predictability enabled by all aircraft in the HPA
operating on 4-D trajectories, these 4-D tailored arrivals conducted outside HPA will be
conducted recognizing the effects of mixing equipage and capabilities as found on the aircraft in
normal airspace. Aircraft exiting HPA and conducting a 4-D tailored arrival may access a wedge
of airspace, established above current arrival/descent airspace, which allows procedural
segregation from aircraft conducting the traditional step descent arrivals.

In conjunction with the ground automation handoff, which is done automatically unless the
controller takes an extra action to reject it, data communications provides the next frequency to
the flight crew, and transfers the data communications eligibility to the next sector or Center.
The data communications system automatically validates the aircraft’s Mode-C reported altitude
and confirms the assigned altitude for the receiving controller.

Automation tailors resolutions based on aircraft capabilities e.g., 4-D trajectory changes for HP
equipped aircraft and ATS route, fix name, or altitude changes for lesser equipped aircraft.

Tasks for controllers monitoring performance-based airspace are essentially the same as in mixed
performance airspace, but the frequency of execution is reduced by a large degree.

The en route controller generates a handoff to the TRACON airspace and data communications
provides the voice frequency for the TRACON airspace arrival sector to the flight crew and
manages the data communications eligibility transfer.

The automation system monitors the aircraft trajectory intent as required, current and future, to
assure conformance with the given trajectory. This is done through either ground automation
algorithm improvements or through the provision of aircraft intent data that increases the
precision of trajectory modeling.

It has become common practice for automation to provide clearances directly to the
aircraft to eliminate conflicts in a strategic fashion. Knowledge of the actions taken by the
automation is provided to the controller to maintain situational awareness. The
automation only provides resolutions to the controller for decision making when more than
one option is available to maintain separation. The controller selects the option which best


                                                29
serves the needs of the overall operation. This change to the operating paradigm is an
accepted practice in Segment Three.

The policy where lesser equipped aircraft are moved before highly equipped aircraft is a
routine practice.

ATM flight information (e.g., arrival sequence, collaborative decision making agreements,
and slot-time allocations) is now provided by subscription.


2.1.4.3.5   Arrival TRACON Airspace

The flight crew contacts the TRACON controller via data communications. The data
communications system automatically validates the aircraft’s Mode-C and confirms the assigned
altitude and ATIS code for the receiving controller. The TRACON controller replies with the
initial information on approach expectations, potential airport information changes, and initial
clearances. Aircraft continue to employ continuous descent profiles from the en route Top of
Descent constraint. Arrival at the final constraint, which is typically the final approach fix,
terminates trajectory based operations.

When necessary due to the traffic density, aircraft use the appropriate data
communications services (e.g., Merging and Spacing (M&S) or Paired Approach) to
perform delegated separation in the final approach phase from traffic landing on the same
or closely spaced parallel runways. Separation responsibility is delegated to the flight crew
for these functions.

A data communications clearance to execute the approach is issued. An instruction to monitor
the tower voice communication frequency is subsequently issued via data communications. Data
communications manages the data communications eligibility transfer.

These new operating methods have relieved much of the tasking previously done manually
by the controllers. Now, in super-density environments all aircraft are equipped to
perform these functions, controllers use the recommendations of the decision support
resolution tools to send data communications clearances to authorize these operations. In
less dense airspace, there is a mix of aircraft capabilities. Service-for-equipage
philosophies are routine even in these environments.


2.1.4.3.6   Arrival Airport

The arrival taxi instructions are provided before the aircraft begins the final approach for
landing. All the functions introduced under previous segments continue to be in use in Segment
Three.

The tower runway controller contacts the flight crew to provide relevant traffic and landing
clearance information while monitoring the traffic situation. After the aircraft lands, the tower
runway controller confirms the previously provided runway exit and directs the flight crew to
contact the ground controller.

                                               30
2.1.4.3.7    Arrival Taxi

The tower ground controller clears the flight crew to taxi via voice or data communications
depending upon the dynamics of the situation and monitors the traffic situation as they maneuver
the aircraft to the arrival gate.

2.2     Maintenance

The maintenance concepts will be further clarified and defined based on cost and alternatives
approved by ATO. Additionally, there is potential that in the Segment Two and Three
timeframes, the NAS maintenance concept may change.

2.3     Quantities and Locations

The operational deployment is planned as follows:

Segment One: Data communications will be available at all 20 continental United States
           (CONUS) en route facilities. Additionally, it will be available at the 73 tower data
           link services (TDLS) airports.
Segment Two: Data communications will be available at all the facilities from Segment One
           plus 50 TRACON facilities and an additional 94 airports.
Segment Three: Data communications will be available at some number of ATC facilities across
           the NAS consistent with the NextGen concept.

               Note: Segment Two data communications will provide Very High Frequency
               (VHF) Data Link (VDL) Mode 2 coverage at the 94 airports. VDL2 coverage and
               operational systems will be provided at the TRACONs.

The data communications Terminal sites are listed in Appendix F.

The support deployment is planned as follows:
       Data communications en route support systems will be available at the William J. Hughes
       Technical Center (WJHTC) (five systems) and the Mike Monroney Aeronautical Center
       (MMAC) (four systems).
       Data communications tower support systems will be available at the MMAC (seven
       systems), Salt Lake (one system), Herndon (one system), and the MMAC (one system).
       Data communications TRACON support systems will be available at the WJHTC (to be
       determined (TBD) systems) and the MMAC (TBD systems).

There will be four en route systems for contractor development.

2.3.1    Data Communications Coverage

Data communications will provide air-ground communications coverage in accordance with the
following:
       For terminal airspace the greater of:


                                               31
            o Airspace defined by:
                        5 nautical miles (NMs) out from TDLS airport, surface-5000 feet
                        20 NMs out from TDLS airport, 2500 feet-10000 feet (part of this overlaps
                        with 5 NM ring)
                        40 NMs out from TDLS airport, 10000 feet-12000 feet
                        60 NMs out from airport, 12000 feet-16000 feet
            o Class B and Class C airspace served by Tower/TRACONS as specified in 2.3.
       Data communications will provide air-ground communications line-of-site coverage to
       115 NM off the coast and land borders of the CONUS.
       Data communications will provide air-ground communications coverage from 16000 feet
       to flight level (FL) 600 across the NAS within the CONUS.

               Note: Site specific issues will be handled during site surveys.

2.4   Schedule Constraints

Initial Operational Capability (IOC) at the key site(s) is planned for each of the three segments as
follows:
         Segment One: Tower fiscal year (FY) 2012, En Route FY 2014
         Segment Two: Tower and TRACON FY 2017, En Route FY 2018
         Segment Three: FY 2022

Full Operational Capability (FOC) is TBD.

Dependencies are TBD.




                                                 32
3.    TECHNICAL PERFORMANCE

The following sections present the operational, functional, and performance requirements for
data communications.

3.1     Operational and Functional Requirements

This document identifies requirements associated with the provision of data communications in
the NAS. The data communications services will provide Air Traffic Services and not Airline
Operational Control services. The requirements identified in this document may be allocated to
any new NAS system elements specific to the provision of data communications and/or to
existing or planned elements in the NAS. However, data communications is not specifically
requiring new capabilities in the TRACON, such as a Flight Data Processor (FDP) or Conflict
Probe. Figure 3-1 shows the high level functional architecture for data communications.




                        Figure 3-1 High Level Functional Architecture Diagram

3.1.1    Segment One Requirements

         Note: Unless specified, the following requirements for Segment One are applicable to
         the tower and en route domains.



                                                 33
3.1.1.1     Messaging Requirements


3.1.1.1.1     Data communications shall provide tools for controller composition of messages.

3.1.1.1.2 Data communications shall provide the standard(s) to build the tools for pilot
composition of messages.

3.1.1.1.3     Data communications shall compose messages for:
          a. controller approval/acknowledgement,

          b. automated transmission of non-trajectory changing messages without controller
             intervention in the en route domain, or

          c. automated transmission of adapted messages without controller intervention in the
             tower domain.

3.1.1.1.4 Data communications shall provide the message format standard(s) for pilot
approval/acknowledgement.

3.1.1.1.5     Data communications shall:
          a. provide tools for composition of predefined messages,

          b. store predefined messages, and

          c. retrieve predefined messages.

3.1.1.1.6     Data communications shall provide tools for controller deferral of messages.
                 Note: This requirement allows the message that is in the process of being created
                 to be deferred until the controller gets back to it.

3.1.1.1.7     Data communications shall provide tools for controller rejection of messages.

3.1.1.1.8     Data communications shall provide tools for controller editing of messages.

3.1.1.1.9     Data communications shall:
          a. validate the content and format of messages and

          b. error check
messages.

3.1.1.1.10     Data communications shall provide tools to:
          a. transmit messages and

          b. process responses to those messages.



                                                 34
3.1.1.2     Unique Identification Requirements

                 Note: The following requirements relate to other parts of NAS equipment, e.g.,
                 Standard Terminal Automation Replacement System (STARS) and En Route
                 Automation Modernization (ERAM), with which data communications will
                 interface.

3.1.1.2.1 Data communications shall uniquely identify elements (e.g., aircraft, automation
systems, control positions, applications) performing data communications.

3.1.1.2.2     Data communications shall identify the element’s data communications capabilities.

3.1.1.2.3 Data communications shall use the identified data communications capabilities of
each element to determine what services are offered to that element.

3.1.1.2.4 Data communications shall associate aircraft with flight plans (and/or flight objects,
if available).


3.1.1.3     Data Communications Requirements


3.1.1.3.1     Data communications shall deliver information to addressed recipient(s).

3.1.1.3.2     Data communications shall:
          a. initiate,

          b. maintain, and

          c. terminate
service between the elements of the system.

3.1.1.3.3     Data communications shall provide the capability for:
             a. monitoring and

             b. control

of data communications resources.

3.1.1.3.4 Data communications shall support the establishment and transfer of data control
authority by an aircraft for exchange of operational control messages with a single, authorized
ground element.

3.1.1.3.5 Data communications shall assign eligibility to exchange controller-pilot data
communications messages between the authorized ground element(s) and the aircraft.




                                                 35
3.1.1.3.6 Data communications shall support the adaptation of communication eligibility to
enable one (or more) control position(s) to exchange data messages with an aircraft.
               Note: Eligibility is typically granted to one or more positions in a sector, but may
               also be granted to related positions outside of the sector. For example, eligibility
               for departure clearances might be granted to both flight data and ground control
               positions in the tower.

3.1.1.3.7     Data communications shall report on the status of data communications messages.

3.1.1.3.8     Data communications shall provide:
          a. automated and

          b. manual
transfer of controller-pilot data communications eligibility between control positions.

3.1.1.3.9 Data communications shall provide the capability to override eligibility to exchange
controller-pilot data communications messages.


3.1.1.4     Instructions, Advisories, and Report Request Responses Requirements


3.1.1.4.1     Data communications shall provide tools for the controller to:
          a. compose and

          b. send
instructions to aircraft.

3.1.1.4.2 Data communications shall provide tools for the controller to provide air traffic
advisories to aircraft.

3.1.1.4.3     Data communications shall provide tools for the controller to:
          a. accept and

          b. process
reports from aircraft.


3.1.1.5     Automatic Terminal Information Service Requirements


3.1.1.5.1     Data communications shall:
          a. accept requests for and

          b. provide



                                                 36
current terminal information to aircraft.

3.1.1.5.2     Data communications shall provide tools for a user to:
          a. compose,

          b. edit, and

          c. verify
the content of the ATIS.

3.1.1.5.3 Voice synthesized terminal information shall be identical to the data communications
generated digital ATIS terminal information.


3.1.1.6     Integration Requirements


3.1.1.6.1 Data communications shall electronically exchange information with external
systems without requiring manual reentry.


3.1.1.7     Recording of Messages, Statistical, and Performance Data


3.1.1.7.1     Ground-based data communications shall record all:
          a. sent and

          b. received
data communications messages.

3.1.1.7.2     Ground-based data communications shall:
          a. collect and

          b. store
data communications service, system, and subsystem statistical and performance data.

3.1.1.7.3     Ground-based data communications shall provide tools to:
          a. retrieve and

          b. analyze
stored message, statistical, and performance data.


3.1.1.8     Departure and Taxi Clearance Requirements




                                                 37
3.1.1.8.1     Data communications shall provide tools for a controller to:
          a. accept,

          b. process requests for, and

          c. provide
departure clearances to aircraft.

3.1.1.8.2     Data communications shall provide tools for a controller to:
          a. accept,

          b. process requests for, and

          c. provide
revisions to departure clearances to aircraft.

3.1.1.8.3     Data communications shall provide tools for a controller to:
          a. accept,

          b. process requests for, and

          c. provide
multiple departure clearances to an aircraft at an airport in the same day.

3.1.1.8.4     Data communications shall provide tools for a tower controller to:
          a. accept,

          b. process requests for, and

          c. provide
departure taxi route instructions to aircraft.

3.1.1.8.5     Data communications shall provide tools for a tower controller to:
          a. accept,

          b. process requests for, and

          c. provide
revisions to departure taxi route instructions to aircraft.


3.1.1.9     En Route Clearance Requirements


3.1.1.9.1     Data communications shall provide tools for the controller to:
          a. accept,


                                                  38
        b. process requests for, and

        c. provide
route modifications including 4-D trajectories to aircraft.

3.1.1.9.2    Data communications shall provide tools for the controller to:
        a. accept,

        b. process requests for, and

        c. provide
vertical clearances to aircraft.

3.1.1.9.3    Data communications shall provide tools for the controller to:
        a. accept,

        b. process requests for, and

        c. provide
speed changes to aircraft.

3.1.1.9.4    Data communications shall provide tools for the controller to:
        a. accept,

        b. process requests for, and

        c. provide
heading changes to aircraft.

3.1.1.9.5    Data communications shall provide tools for the controller to:
        a. accept,

        b. process requests for, and

        c. provide
crossing constraints to aircraft.

3.1.1.9.6    Data communications shall provide tools for the controller to:
        a. accept,

        b. process requests for, and

        c. provide
lateral offsets to aircraft.

3.1.1.9.7    Data communications shall provide tools for the controller to:



                                                 39
        a. accept,

        b. process requests for, and

        c. provide
arrival, approach, and departure procedures to aircraft.

3.1.1.9.8 Data communications shall interact with decision support tools which evaluate
proposed:
        a. constraints and

        b. routes
for acceptability.

3.1.1.9.9    Data communications shall provide tools which:
        a. notify,

        b. generate, and

        c. display to the controller
proposed resolution(s) to trajectories that are identified as out of conformance with cleared
trajectories.

3.1.1.9.10 Data communications shall provide tools in the en route domain to send voice
frequency assignments to aircraft with instructions to monitor the next frequency.

3.1.1.9.11 Data communications shall provide tools in the en route domain to send voice
frequency assignments to aircraft with instructions to contact the controller on the assigned
frequency.

3.1.1.9.12 Data communications shall provide tools in the en route domain to validate the
aircraft’s Mode-C altitude.

3.1.1.9.13 Data communications shall provide tools in the en route domain for confirmation of
the aircraft’s assigned altitude.

3.1.1.9.14 Data communications shall provide tools in the en route domain to notify aircraft
that a voice frequency is blocked.


3.1.1.10     Applicable Standards


3.1.1.10.1    The following documents shall provide requirements for the services of Segment
One:




                                                40
       a. ICAO 9880-AN/466, Manual On Detailed Technical Specifications For The
          Aeronautical Telecommunication Network (ATN) using ISO/OSI standards and
          protocols,

       b. RTCA DO-290, Safety and Performance Requirements Standard for Air Traffic Data
          Link Services in Continental Airspace, Change 2,

       c. RTCA DO-yyy, Safety and Performance Requirements Standard for Advanced Air
          Traffic Data Communications Services, (draft)

       d. RTCA DO-280B, Interoperability Requirements Standard For ATN Baseline 1
          (INTEROP ATN B1),

       e. RTCA DO-305, Future Air Navigation System 1/A (FANS 1/A) – Aeronautical
          Telecommunications Network (ATN) Interoperability Standard,

       f. ICAO SARPs, Aeronautical Telecommunication Network (ATN), Volume II, Part II,
          Communications Procedures, Chapter 5, Aeronautical Mobile Service, Second
          Edition,

       g. ICAO Standards and Recommended Practices (SARPs), Aeronautical
          Telecommunications, Annex 10 to the Convention on International Civil Aviation,
          Volume III, Part I, Digital Communication Systems, Chapter 3, Aeronautical
          Telecommunication Network (ATN),

       h. Interoperability Standard for Data Communications via 623, draft,

       i. Interoperability Standard for Data Communications via ATN, draft, and

       j. Interoperability Standard for Data Communications via a mixture of ATN and FANS
          1/A, draft.

3.1.1.10.2 The controller-pilot data link communications (CPDLC) message elements in
Appendix 5 of ICAO Doc 4444 Procedures for Air Navigation Services – Air Traffic
Management (PANS-ATM) shall be available for use for the services of Segment One.

3.1.1.10.3   When there is a conflict between the requirements in:
       a. this document,

       b. FAA Orders, and

       c. the applicable standards,
the precedence of requirements shall be:
       d. this document,

       e. FAA Orders, and then

       f. the applicable standards.




                                               41
3.1.2     Segment Two Requirements

                 Note: The requirements in this section are for Segment Two capabilities which
                 will be built on the capabilities implemented in Segment One. Unless specified,
                 these requirements are applicable to tower, TRACON and en route domains.


3.1.2.1     Data Communications Requirements


3.1.2.1.1 Data communications shall evaluate active trajectories for acceptability for no less
than a one hour time horizon.

3.1.2.1.2     Data communications shall provide tools for the controller to:
          a. accept,

          b. process, and

          c. respond to
user preferences from aircraft.

3.1.2.1.3 Data communications shall interact with decision support tools which evaluate
proposed:
          a. constraints and

          b. routes
for acceptability.

3.1.2.1.4 Data communications shall provide tools for the controller to establish trajectory
agreements for the 4-D portions of the planned route for aircraft.

3.1.2.1.5 Data communications shall establish agreements for aircraft-generated flight path,
trajectory, and status information.

3.1.2.1.6 Data communications shall provide aircraft-generated flight path, trajectory, and
status information to decision support tools.

3.1.2.1.7 Data communications shall provide means to determine, for each aircraft operating
under a 4-D agreement, the aircraft’s current and intended conformance with the then-current 4-
D agreement.

3.1.2.1.8     Data communications shall provide tools which:
          a. notify,

          b. generate, and

          c. display to the controller


                                                 42
proposed resolution(s) to trajectories that are identified as out of conformance with established
trajectory agreements.

3.1.2.1.9 Data communications shall have the capability to provide automated low altitude
alerts to aircraft.

3.1.2.1.10 Data communications shall provide the capability to communicate clearances
between the en route and terminal domains.


3.1.2.2     Terminal Clearance Requirements


3.1.2.2.1 Data communications shall compose messages for automated transmission of non-
trajectory changing messages without controller intervention.

3.1.2.2.2 Data communications shall provide tools to send voice frequency assignments to
aircraft with instructions to monitor the next frequency.

3.1.2.2.3 Data communications shall provide tools to send voice frequency assignments to
aircraft with instructions to contact the controller on the assigned frequency.

3.1.2.2.4      Data communications shall provide tools to validate the aircraft’s Mode-C altitude.

3.1.2.2.5      Data communications shall provide tools for confirmation of the aircraft’s assigned
altitude.

3.1.2.2.6      Data communications shall provide tools to notify aircraft that a voice frequency is
blocked.

3.1.2.2.7 Data communications shall exchange 4-D trajectory information between system
elements.

3.1.2.2.8      Data communications shall provide tools for the controller to provide:
          a. arrival taxi information and

          b. arrival taxi clearances
to aircraft.

3.1.2.2.9      Data communications shall provide tools for the controller to:
          a. accept,

          b. process requests for, and

          c. provide
route modifications including 4-D trajectories to aircraft.


                                                   43
3.1.2.2.10    Data communications shall provide tools for the controller to:
        a. accept,

        b. process requests for, and

        c. provide
vertical clearances to aircraft.

3.1.2.2.11    Data communications shall provide tools for the controller to:
        a. accept,

        b. process, and

        c. display
altitude change notifications from aircraft.

3.1.2.2.12    Data communications shall provide tools for the controller to:
        a. accept,

        b. process requests for, and

        c. provide
speed changes to aircraft.

3.1.2.2.13    Data communications shall provide tools for the controller to:
        a. accept,

        b. process requests for, and

        c. provide
heading changes to aircraft.

3.1.2.2.14    Data communications shall provide tools for the controller to:
        a. accept,

        b. process requests for, and

        c. provide
crossing constraints to aircraft.

3.1.2.2.15    Data communications shall provide tools for the controller to:
        a. accept,

        b. process requests for, and

        c. provide



                                                44
lateral offsets to aircraft.

3.1.2.2.16     Data communications shall provide tools for the controller to:
          a. accept,

          b. process requests for, and

          c. provide
arrival, approach, and departure procedures to aircraft.

3.1.2.2.17     Data communications shall interact with decision support tools which evaluate
proposed:
          a. constraints and

          b. routes
for acceptability.

3.1.3     Segment Three Requirements

                 Note: The requirements in this section are for Segment Three capabilities which
                 will be built on the capabilities implemented in Segment Two. Unless specified,
                 these requirements are applicable to tower, TRACON and en route domains.

3.1.3.1 Data communications shall evaluate active trajectories for acceptability for no less than
a two hour time horizon.

3.1.3.2 Data communications shall provide current, routine safety critical information to
aircraft without human intervention.
               Note: Examples of routine safety critical information are turbulence and icing.

3.1.3.3     Data communications shall:
          a. accept,

          b. process requests for, and

          c. provide
automated transmission of adapted messages without controller intervention.

3.1.3.4 Data communications shall exchange information in support of delegated separation
operations for aircraft.




                                                 45
3.2     Product Characteristics and Performance Requirements

The following sections present the performance requirements for each of the three data
communications segments.

3.2.1     Segment One Product Characteristics and Performance Requirements

The following sections present the performance requirements for data communications Segment
One.


3.2.1.1     Performance


3.2.1.1.1 Data communications shall provide service that is classified essential as defined in
NAS-SR-1000, National Airspace System, System Requirements Specification.

3.2.1.1.2 The design of the data communications ground system shall meet the inherent
availability and equipment and service availability as defined in FAA-HDBK-006, Reliability,
Availability, and Maintainability Handbook.

3.2.1.1.3 Data communications shall meet all performance requirements with the expected
quantity and mix of data communications messages for Segment One in Table 3-1 and aircraft
counts in 3.2.1.2.

3.2.1.1.4 Data communications shall meet a 95th percentile end-to-end one-way technical
message latency requirement of 8 seconds for the most time critical clearance messages.

3.2.1.1.5 Data communications shall meet a 95th percentile end-to-end one-way message
technical latency requirement of 30 seconds for all data messages.

3.2.1.1.6    Data communications shall be maintained for 20 minutes in the event of a power
failure.


3.2.1.2     Number of Aircraft Supported


3.2.1.2.1 Data communications shall be capable of providing simultaneous service to no fewer
than 41 aircraft per en route control position.

3.2.1.2.2 Data communications shall be capable of providing simultaneous service to no fewer
than 65 control positions per en route facility.

3.2.1.2.3 Data communications shall be capable of providing simultaneous service to no fewer
than 300 data communications equipped aircraft per en route facility.



                                               46
3.2.1.2.4 Data communications shall be capable of providing simultaneous service to no fewer
than 3900 data communications equipped aircraft in the CONUS en route domain.

3.2.1.2.5 Data communications shall be capable of providing simultaneous service to no fewer
than 150 aircraft per tower facility.

3.2.1.2.6 Data communications shall be capable of providing simultaneous service to no fewer
than 4500 data communications equipped aircraft at data communications equipped airports.

3.2.1.2.7 Data communications shall be capable of providing simultaneous service to no fewer
than 200 data communications equipped aircraft in the en route domain within a 115 NM range.


3.2.1.3   Message Exchange Rates


3.2.1.3.1 Data communications shall support the minimum air/ground message capacity per
aircraft within the indicated domain as shown in Table 3-1.

             Table 3-1 Minimum Air/Ground Message Capacity per Flight for Segment One


Communication Type      Tower                       En Route
                        (for departing aircraft)    (for all aircraft)
Communication           1 Logon & Session           1 Logon & Session Start/Termination
Management              Start/Termination           1 Next Data Authority per ARTCC
                        1 Next Data Authority
                                                    1 Transfer of Control per sector
Clearances              1 Departure Clearance       5 Basic Clearances, Instructions, or
                                                    Reports
                        1 Revised Departure
                        Clearance for 10% of        1 Route Clearance for 25% of the aircraft
                        the aircraft                1 Controlled Time of Arrival
                        1 Departure Taxi
                                                    1 Tailored Arrival Procedure
Notifications &         1 Departure ATIS            1 Arrival ATIS*
Advisories
                        1 Arrival ATIS*             1 Beacon Code Update for 5% of the
                                                    aircraft
                        1 Advisory or
                        Notification           1 Advisory or Notification
*Note: The source of all ATIS is the Tower. The delivery of the ATIS depends on the aircraft’s
location.


3.2.1.4   Coverage Area Supported




                                                   47
3.2.1.4.1 Data communications shall provide air-ground communications coverage on the
surface at TDLS airports.

3.2.1.4.2 Data communications shall provide air-ground communications coverage from 16000
feet to FL600 across the NAS and 115 NM off the coast and land borders of the CONUS.

3.2.2     Segment Two Product Characteristics and Performance Requirements

                Note: The requirements in this section are for Segment Two capabilities which
                will be built on the capabilities implemented in Segment One.


3.2.2.1     Performance


3.2.2.1.1 Data communications shall provide service that is classified critical as defined in
NAS-SR-1000, National Airspace System, System Requirements Specification.

3.2.2.1.2    Data communications shall be designed with no common mode failures.

3.2.2.1.3 Data communications shall meet all performance requirements with the expected
quantity and mix of data communications messages for Segment Two in Table 3-2 and aircraft
counts in 3.2.2.2.

3.2.2.1.4 Data communications shall meet a 95th percentile end-to-end one-way technical
message latency requirement of 5 seconds for the most time critical clearance service.

3.2.2.1.5 Data communications shall meet a 95th percentile end-to-end one-way message
technical latency requirement of 10 seconds for all data messages.

3.2.2.1.6 Data communications shall provide message integrity of 10-7 or less for the most time
critical clearance service.

3.2.2.1.7 Data communications shall provide undetected misdirection of 10-7 per message or
less for the most time critical clearance service.


3.2.2.2     Number of Aircraft Supported


3.2.2.2.1 Data communications shall be capable of providing simultaneous service to no fewer
than 68 aircraft per en route control position.

3.2.2.2.2 Data communications shall be capable of providing simultaneous service to no fewer
than 100 control positions per en route facility.




                                               48
3.2.2.2.3 Data communications shall be capable of providing simultaneous service to no fewer
than 600 data equipped aircraft per en route facility.

3.2.2.2.4 Data communications shall be capable of providing simultaneous service to no fewer
than 7900 data communications equipped aircraft in the CONUS en route domain.

3.2.2.2.5 Data communications shall be capable of providing simultaneous service to no fewer
than 220 aircraft per tower facility.

3.2.2.2.6 Data communications shall be capable of providing simultaneous service to no fewer
than 7200 data communications equipped aircraft at data communications equipped airports.

3.2.2.2.7 Data communications shall be capable of providing simultaneous service to no fewer
than 29 aircraft per TRACON control position.

3.2.2.2.8 Data communications shall be capable of providing simultaneous service to no fewer
than 92 control positions per TRACON.

3.2.2.2.9 Data communications shall be capable of providing simultaneous service to no fewer
than 150 data communications equipped aircraft per TRACON facility.

3.2.2.2.10 Data communications shall be capable of providing simultaneous service to no
fewer than 2100 data communications equipped aircraft in the CONUS terminal domain
(excluding airports).

3.2.2.2.11 Data communications shall be capable of providing simultaneous service to no
fewer than 300 data communications equipped aircraft in the en route domain within a 115 NM
range.

3.2.2.2.12 Data communications shall be capable of providing simultaneous service to no
fewer than 170 data communications equipped aircraft in the terminal domain (excluding
airports) within a 115 NM range.


3.2.2.3   Message Exchange Rates


3.2.2.3.1 Data communications shall support the minimum air/ground message capacity per
aircraft within the indicated domain as shown in Table 3-2.

            Table 3-2 Minimum Air/Ground Message Capacity per Flight for Segment Two


Communication Type     Tower                       En Route                Terminal
                       (for departing aircraft)    (for all aircraft)      (for all aircraft)
Communication          1 Logon                     1 Logon & Session       1 Logon &
Management                                         Start/Termination for   Session
                       1 Session Start


                                                  49
                     1 Next Data Authority    30% of the aircraft       Start/Termination
                                                                        for 30% of the
                                              1 Next Data Authority
                                                                        departing aircraft
                                              per facility
                                                                        1 Next Data
                                              1 Transfer of Control
                                                                        Authority per
                                              per sector
                                                                        facility for
                                                                        departing aircraft
                                                                        1 Session
                                                                        Termination for
                                                                        arriving aircraft
                                                                        1 Transfer of
                                                                        Control per sector
Clearances &         1 Departure Clearance    4 Basic Clearances,       2 Basic
Instructions                                  Instructions, or          Clearances,
                     1 Revised Departure
                     Clearance for 30% of     Reports                   Instructions, or
                                                                        Reports
                     the aircraft             1 Trajectory
                     1 Departure Taxi         Clearance per facility    1 Controlled Time
                                                                        of Arrival for 50%
                                              1 Controlled Time of
                                              Arrival for 50% of the    of the arriving
                                              aircraft                  aircraft

                                              1 Tailored Arrival        1 Arrival Taxi
                                              Procedure for 70% of      1 Tailored Arrival
                                              the aircraft              Procedure for
                                                                        30% of the
                                                                        arriving aircraft
Notifications &      1 Departure ATIS         1 Arrival ATIS*           1 Arrival ATIS*
Advisories                                                              for 25% of the
                     1 Advisory or            1 Beacon Code
                     Notification             Update for 5% of the      arriving aircraft
                                              aircraft                  1 Advisory or
                                                                        Notification
                                              1 Advisory or
                                              Notification              1 User
                                                                        Preferences
                                              1 User Preferences
                                                                        Downlink
                                              Downlink
Flight Path Intent                            1 Agreement               1 Agreement
                                              Setup/Update per          Setup/Update per
                                              facility                  facility
                                              2 Demand Reports per 1 Demand Report
                                              facility             per facility
                                              1 Event Report per        1 Event Report
                                              facility for 50% of the   per facility for
                                              aircraft                  25% of the aircraft



                                             50
*Note: The source of all ATIS is the Tower. The delivery of the ATIS depends on the aircraft’s
location.


3.2.2.4    Coverage Area Supported


3.2.2.4.1 Data communications shall provide air-ground communications coverage in
accordance with:
          o Airspace defined by:
                   5 NMs out from TDLS airport, surface-5000 feet
                   20 NMs out from TDLS airport, 2500 feet-10000 feet (part of this overlaps
                   with 5 NM ring)
                   40 NMs out from TDLS airport, 10000 feet-12000 feet
                   60 NMs out from airport, 12000 feet-16000 feet
          o Class B and Class C airspace served by Tower/TRACONS as specified in 2.3.

3.2.3     Segment Three Product Characteristics and Performance Requirements

                Note: The requirements in this section are for Segment Three capabilities which
                will be built on the capabilities implemented in Segment Two.


3.2.3.1    Performance


3.2.3.1.1 Data communications shall meet all performance requirements with the expected
quantity and mix of data communications messages for Segment Three in Table 3-2 and aircraft
counts in 3.2.3.2.


3.2.3.2    Number of Aircraft Supported


3.2.3.2.1 Data communications shall be capable of providing simultaneous service to no fewer
than 95 aircraft per en route control position.

3.2.3.2.2 Data communications shall be capable of providing simultaneous service to no fewer
than 128 en route control positions.

3.2.3.2.3 Data communications shall be capable of providing simultaneous service to no fewer
than 700 data communications equipped aircraft per ARTCC facility.

3.2.3.2.4 Data communications shall be capable of providing simultaneous service to no fewer
than 10300 data communications equipped aircraft in the CONUS en route domain.




                                               51
3.2.3.2.5 Data communications shall be capable of providing simultaneous service to no fewer
than 280 aircraft per tower facility.

3.2.3.2.6 Data communications shall be capable of providing simultaneous service to no fewer
than 9200 data communications equipped aircraft at data communications equipped airports.

3.2.3.2.7 Data communications shall be capable of providing simultaneous service to no fewer
than 44 aircraft per TRACON control position.

3.2.3.2.8 Data communications shall be capable of providing simultaneous service to no fewer
than 128 TRACON control positions.

3.2.3.2.9 Data communications shall be capable of providing simultaneous service to no fewer
than 240 data communications equipped aircraft per TRACON facility.

3.2.3.2.10 Data communications shall be capable of providing simultaneous service to no
fewer than 2900 data communications equipped aircraft in the CONUS terminal domain
(excluding airports).

3.2.3.2.11 Data communications shall be capable of providing simultaneous service to no
fewer than 410 data communications equipped aircraft in the en route domain within a 115 NM
range.

3.2.3.2.12 Data communications shall be capable of providing simultaneous service to no
fewer than 250 data communications equipped aircraft in the terminal domain (excluding
airports) within a 115 NM range.


3.2.3.3   Message Exchange Rates


3.2.3.3.1 Data communications shall support the minimum air/ground message capacity per
aircraft within the indicated domain as shown in Table 3-3.

            Table 3-3 Minimum Air/Ground Message Capacity per Flight for Segment Three


Communication Type      Tower                       En Route                Terminal
                        (for departing aircraft)    (for all aircraft)      (for all aircraft)
Communication           1 Logon                     1 Logon & Session       1 Logon &
Management                                          Start/Termination for   Session
                        1 Session Start
                                                    30% of the aircraft     Start/Termination
                        1 Next Data Authority                               for 30% of the
                                                    1 Next Data Authority
                                                                            departing aircraft
                                                    per facility
                                                                            1 Next Data
                                                    1 Transfer of Control
                                                                            Authority per
                                                    per sector
                                                                            facility for


                                                   52
                                                                        departing aircraft
                                                                        1 Session
                                                                        Termination for
                                                                        arriving aircraft
                                                                        1 Transfer of
                                                                        Control per sector
Clearances &         1 Departure Clearance    4 Basic Clearances,       3 Basic
Instructions                                  Instructions, or          Clearances,
                     1 Revised Departure
                                              Reports                   Instructions, or
                     Clearance for 30% of
                     the aircraft             0.5 Trajectory            Reports
                                              Clearance per facility    1 Trajectory
                     1 Departure Taxi
                                              1 Controlled Time of      Clearance per
                                              Arrival for 95% of the    facility
                                              aircraft                  1 Controlled Time
                                                                        of Arrival for 75%
                                              1 Tailored Arrival
                                              Procedure for 95% of      of the arriving
                                              the aircraft              aircraft
                                                                        1 Arrival Taxi
                                                                        1 Tailored Arrival
                                                                        Procedure for
                                                                        75% of the
                                                                        arriving aircraft
Notifications &      1 Departure ATIS         1 Arrival ATIS*           1 Arrival ATIS*
Advisories           1 Advisory or            1 Beacon Code             for 25% of the
                     Notification             Update for 5% of the      arriving aircraft
                                              aircraft                  1 Subscription
                                              1 Subscription            Setup/Update
                                              Setup/Update              2 Advisory or
                                                                        Notification
                                              2 Advisory or
                                              Notification              1 User
                                                                        Preferences
                                              1 User Preferences
                                                                        Downlink
                                              Downlink
Flight Path Intent                            0.5 Agreement             1 Agreement
                                              Setup/Update facility     Setup/Update per
                                              0.5 Demand Reports        facility
                                              per facility              1 Demand Report
                                                                        per facility
                                              1 Event Report per
                                              facility for 75% of the   1 Event Report
                                              aircraft                  per facility for
                                                                        50% of the aircraft



                                             53
*Note: The source of all ATIS is the Tower. The delivery of the ATIS depends on the aircraft’s
location.




                                              54
4.    PHYSICAL INTEGRATION

               Note: Physical integration of data communications will be planned to ensure
               minimal disruption to ATO operations and will involve coordination with FAA
               functional divisions (facility management, environmental, energy, safety, and
               power).

4.1   Real Property

4.1.1 Data communications ground-based unique equipment installed in FAA-owned or
provided facilities shall be integrated into, and conform to the limitations of, existing NAS
facilities.

4.2   RESERVED

4.3   Environmental

4.3.1 Data communications ground-based unique equipment installed in FAA-owned or
provided facilities shall comply with:
       a. Code of Federal Regulations (CFR), Title 40, Environmental Protection, and

       b. state,

       c. local,

       d. Department of Transportation (DOT), and

       e. FAA
environmental orders and directives.
4.3.2 Non-FAA owned facilities shall be in accordance with:
       a. national,

       b. state, and

       c. local
building and electrical codes.
4.3.3 Non-FAA owned facilities shall be in accordance with:
       a. Environmental Protection Agency (EPA) and

       b. Occupational Safety and Health Administration (OSHA)
standards.

4.4   Energy Conservation

4.4.1 Data communications ground-based unique equipment installed in FAA-owned or
provided facilities shall meet the requirements of Executive Order 13123, Greening the
Government Through Efficient Energy Management, dated June 3, 1999.

                                                55
4.5     Heating, Ventilation, and Air Conditioning

The following sections present the heating, ventilation, and air conditioning environmental
requirements.

4.5.1    Equipment Operating Environment


4.5.1.1 Data communications ground-based unique equipment installed in FAA-owned or
provided facilities shall be designed to meet the non-operating and operating environment
requirements defined in FAA-G-2100G, Electronics Equipment, General Requirements.

4.5.2    Impact on Equipment Operating Environment


4.5.2.1 Data communications ground-based unique equipment installed in FAA-owned or
provided facilities shall operate with existing facility Heating, Ventilation, and Air Conditioning
(HVAC).

4.6     Grounding, Bonding, Shielding, and Lightning Protection

4.6.1 All grounding and bonding of data communications ground-based unique equipment
residing in NAS facilities shall comply with:
         a. FAA-STD-019E, Lightning and Surge Protection, Grounding, Bonding and Shielding
            Requirements for Facilities and Equipment,

         b. FAA Order 6950.19, Practices and Procedures for Lightning Protection Grounding,
            Bonding, and Shielding Implementation,

         c. FAA Order 6950.20 Fundamental Considerations of Lightning Protection
            Grounding, Bonding, and Shielding,

         d. National Fire Protection Association (NFPA) Standard 70, National Electric Code,

         e. ANSI/IEEE 1100-1992, Grounding Shielding and Bonding, and

         f. FAA-G-2100G, Electronics Equipment, General Requirements.
4.6.2 Data communications ground-based unique equipment not installed in FAA-owned or
provided facilities but physically or electrically interfacing with NAS equipment or facilities
shall comply with the NAS requirements applicable to such interfaces.

4.7     Cables

4.7.1 Data communications ground-based unique equipment installed in FAA-owned or
provided facilities shall meet the requirements of:
         a. National Fire Protection Association (NFPA) Standard 70, National Electric Code,



                                                56
         b. FAA Order 6630.4, En Route Communications Installation Standards Handbook,

         c. FAA Order 6950.22, Maintenance of Electrical Power and Control Cables,

         d. FAA-C-1217, Electrical Work, Interior, and

         e. FAA-G-2100G, Electronic Equipment, General Requirements.
4.7.2 Cabling between data communications ground-based unique equipment not installed in
FAA-owned or provided facilities and FAA/owned operated equipment or FAA facilities shall
comply with the requirements of 4.7.1.

4.8    Hazardous Materials

4.8.1 Data communications ground-based unique equipment installed in FAA-owned or
provided facilities shall be compliant with the Reduction of Hazardous Substances (RoHS)
Directive 2002/95/EC.

4.9    Power Systems and Commercial Power

4.9.1 The data communications ground-based unique equipment installed in FAA-owned or
provided facilities and operated from FAA critical power shall be designed to meet critical power
requirements.

4.9.2 Data communications ground-based unique equipment installed in FAA-owned or
provided facilities shall meet the requirements of FAA-G-2100G, Electronic Equipment, General
Requirements.

4.10     Telecommunications

4.10.1 Data communications ground-based unique equipment installed in, or interfacing with,
FAA-owned or provided equipment or facilities shall:
         a. comply with the appropriate FAA interface requirements documents (IRDs) and

         b. interface control documents (ICDs).

4.11     Special Considerations

The following sections present specific requirements for data communications under special
conditions.

4.11.1    {reserved}

4.11.2    Occupational Safety and Health Administration


4.11.2.1 Physical integration of data communications ground-based unique equipment installed
in FAA-owned or provided facilities shall be accomplished in such a manner as to maintain
facility compliance with OSHA regulations.


                                                  57
4.11.3     Space


4.11.3.1 Installation of data communications ground-based unique equipment installed in
FAA-owned or provided facilities shall comply with Section 6.2 of the National Fire Protection
Association Standard 70, National Electric Code.

4.11.4     Electrostatic and Electromagnetic

The following sections present electrostatic discharge and electromagnetic requirements.


4.11.4.1    Electrostatic Discharge


4.11.4.1.1 Data communications ground-based unique equipment installed in FAA-owned or
provided facilities shall meet Electrostatic Discharge (ESD) requirements referenced in FAA-
STD-019E, Lightning and Surge Protection, Grounding, Bonding and Shielding Requirements
for Facilities and Equipment.


4.11.4.2    Electromagnetic Compatibility


4.11.4.2.1 Data communications ground-based unique equipment installed in FAA-owned or
provided facilities shall meet electromagnetic compatibility requirements referenced in:
         a. MIL-Standard-464, Electromagnetic Environmental Effects Requirements for
            Systems, and

         b. FAA-G-2100G, Electronics Equipment, General Requirements.




                                               58
5.    FUNCTIONAL INTEGRATION

The following sections present functional integration requirements. These requirements address
integrating data communications into the NAS operational environment as well as software
integration and spectrum management.

5.1     Integration With Other FAA Enterprise Architecture Elements

The following sections present the requirements for integrating data communications into the
FAA enterprise architecture.

5.1.1     Remote Maintenance Monitoring System Interface Capabilities


5.1.1.1 Data communications shall interface to the existing automation monitor and control
system(s) to allow the Tech Ops to assess the following remotely:
          a. Operating Status of the (service provider or NAS) data communications service(s)

          b. Operating Status of the equipment installed in FAA-owned or provided facilities

          c. Fault Isolation of equipment installed in FAA-owned or provided facilities that the
             FAA is responsible for maintaining.


5.1.2     Controller Display System Interface Capability


5.1.2.1 Data communications shall exchange information with Display System(s) to allow the
Tech Ops to perform data communications activities.

5.1.3     Supervisor Interface Capability


5.1.3.1 Data communications shall provide an interface to allow Air Traffic Management
supervisors to perform all supervisory data communications activities at supervisor work
stations.

5.2     Information Requirements

There are no information requirements for data communications at this time.

5.3     Software Integration

5.3.1     Software


5.3.1.1     The FAA shall have


                                                 59
          a. unrestricted access to, or

          b. option to acquire
the reprocurement data package for data communications application software installed in FAA-
owned or operating equipment.

5.3.1.2 Data communications software shall be designed to permit the controller to accept
recommended uplink messages from other applications without requiring the message to be
copied or re-keyed.

5.3.1.3 Data communications Human Machine Interface (HMI) shall integrate ATC uplink
messages from other applications intended for use by controllers using data communications.

5.3.1.4 The contents of data communications messages shall be available for other applications
without requiring the message contents to be copied and re-keyed.

5.3.1.5     Data communications shall incorporate support software tools for the purpose of:
          a. configuration management,

          b. system administration and security,

          c. adaptation,

          d. system build,

          e. test,

          f. training,

          g. data capture and storage, and

          h. data reduction and analysis (DR&A).

5.3.2     Adaptation


5.3.2.1     Data communications shall be adaptable to suit:
          a. local and

          b. national
operational or procedural requirements.

5.4     Spectrum Management

5.4.1 Data communications shall employ properly allocated radio spectrum protected for
aeronautical safety services.




                                                   60
5.5   Standardization

5.5.1 Interfaces to FAA-owned or operated equipment shall exchange information using open,
standardized or commercially available protocols.




                                            61
6.    HUMAN INTEGRATION

The following sections present the requirements related to human-data communications
integration.

6.1     Human Systems Engineering

6.1.1     Human Factors shall be addressed in the:
          a. design,

          b. development, and

          c. test
of data communications in accordance with FAA Order 9550.8 Human Factors Policy.

6.1.2     Human Factors Program


6.1.2.1 A Human Factors Program shall be established for data communications in accordance
with the FAA Human Factors Job Aid.


6.1.2.2     Development Contractor’s Human Engineering Program


6.1.2.2.1 The data communications development contractor shall conduct a Human Factors
Engineering Program in accordance with MIL-HDBK-46855A, Human Engineering Program
Process and Procedures:
          a. Section 4 Program Tasks and

          b. Section 7 HE Procedures for Contractors.

6.1.2.2.2 Early human-in-the-loop prototyping of the human interfaces shall be accomplished
prior to major design commitments.

6.1.2.2.3 Data communications shall conform with the FAA Human Factors Design Standard
(HFDS), HF-STD-001, chapters 2-10, 12, 14, and 15.

6.1.2.2.4     Data communications Segment One shall comply with:
          a. RTCA, DO-256, Minimum Human Factors Standards for Air Traffic Services
             Provided Via Data Communications Utilizing the ATN, Builds I and IA and

          b. RTCA, DO-238, Human Engineering Guidance for Data Link Systems.

6.1.2.2.5 Data communications shall provide accessibility in accordance with FED-STD-795,
Uniform Federal Accessibility Standard (UFAS).

                                                62
6.1.2.2.6 Data communications routine administrative and business task interfaces shall be in
accordance with 36 CFR 1194, Electronics and Information Technology Accessibility Standard
implementing Section 508 of the Rehabilitation Act of 1973, as amended (29 CFR 794d).

6.1.2.2.7 Early human-in-the-loop prototyping of the human interfaces shall be accomplished
prior to major design commitments.

6.2     Human Machine Interface

The following sections present the human machine interface requirements.

6.2.1     General


6.2.1.1 Data communications human-system interfaces and procedures shall be designed to
enable users to meet:
          a. safety and

          b. performance
requirements.

6.2.2     Performance Requirements


6.2.2.1 Data communications shall be designed to meet the RTCA DO-290 human
performance allocations.

6.2.2.2     Data communications:
          a. Segment Two and

          b. Segment Three
shall have an ATC Clearance Service (ACL) design goal such that the two way end-to-end
service transaction (system and human components) is completed in equal to or less than 24
seconds 95th percentile.

                 Note: The final allocation between system and human components will be
                 verified via human factors analysis. A two-way service transaction is composed of
                 two operational messages. A message from the initiator to the responder and an
                 operational response from the responder back to the initiator. If the responder
                 replies with a Standby, then there is no expectation that the two-way transaction
                 time will be met by the eventual operational response. The final allocations
                 between the system and human components will be verified via human factors
                 analysis.

6.2.3     Human Factors Design Standard




                                                63
6.2.3.1 Data communications shall be in accordance with DOT/FAA/CT-96/1 Human Factors
Design Guide (HFDG) for Acquisition of Commercial-Off-the-Shelf Subsystems, Non-
Developmental Items, and Developmental Systems Chapters 2-10, 12, 14, and 15.


6.2.3.2     Usability


6.2.3.2.1     Data communications human-system integration shall be in accordance with the
HFDS:
          a. Chapter 3.1 General and

          b. Chapter 3.2 Design and evaluation.


6.2.3.3     Operational Suitability


6.2.3.3.1 Data communications human-to-system interfaces shall be compatible and consistent
within and across system and NAS elements in accordance with the HFDS:
          a. Chapter 2.4 Standardization and

          b. Chapter 3.1 General.


6.2.3.4     Function Allocation


6.2.3.4.1 Data communications function assignment to humans (users) shall be in accordance
with the HFDS, revised Chapter 3.11 Function allocation/levels of automation.


6.2.3.5     Human Capabilities and Limitations


6.2.3.5.1 Data communications displays and attendant commands and controls shall be
compatible with human perceptual and cognitive capabilities and limitations in accordance with
the HFDS, Chapter 3.4 Interface.


6.2.3.6     Human-to-System Interfaces


6.2.3.6.1 Data communications human-to-system interfaces shall be in accordance with the
HFDS, Chapter 2 General design requirements.



                                                  64
6.2.3.6.2    Design Simplicity


6.2.3.6.2.1 Data communications human-to-system interfaces shall be designed for simplicity
of use in accordance with the HFDS, Chapter 2.2 Simplicity.


6.2.3.6.3    Identical Functions


6.2.3.6.3.1 Data communications equipment with identical functions shall employ identical or
highly similar human-system interfaces, including hardware and software tools, in accordance
with the HFDS, Chapter 2.3 Consistency.


6.2.3.6.4    Situational Awareness


6.2.3.6.4.1 Data communications information displays shall meet situational awareness
requirements in accordance with the HFDS, Chapter 3.12 Information automation.


6.2.3.7     Workload/Resource Allocation


6.2.3.7.1 Data communications shall be designed so that the associated workload does not
significantly reduce attention to the primary task.


6.2.3.8     Communications and Teamwork


6.2.3.8.1 Data communications shall enable personnel communication and information
interchange in accordance with the HFDS, Chapter 3.2.3 Consider effect on coordination.


6.2.3.9     Automation Guidelines


6.2.3.9.1 Data communications human-to-system interfaces shall comply with the HFDS,
Chapter 3 Automation.


6.2.3.9.2    Fail Safe Design




                                              65
6.2.3.9.2.1 Data communications human-to-system interfaces shall be analyzed for system
safety and personnel safety hazards in accordance with ASD-100-SSE-1, NAS Modernization
System Safety Management Program.


6.2.3.9.3     Human Error Resistant


6.2.3.9.3.1 Data communications human-to-system interfaces shall be human error resistant in
accordance with the HFDS, Chapter 2.5.3 Make systems error resistant.


6.2.3.9.4     Human Error Tolerant


6.2.3.9.4.1 Data communications human-to-system interfaces shall human error tolerant, in
accordance with the HFDS, Chapter 2.5.4 Make systems error tolerant.

6.2.3.9.4.2 Data communications shall be designed to reduce human errors - particularly
message reception, processing and sending errors - that could result in unsafe conditions, to the
levels specified in 6.2.3.9.4.3.

6.2.3.9.4.3 Data communications interfaces, procedures, and training, shall be designed to
meet the following ACL service safety requirements for human error rates (for message reception
and sending):
       a. threshold of less than 1 error in 250 transactions and

       b. design objective of less than 1 error in 1000 transactions.


6.2.3.9.5     Infrequent Critical Tasks


6.2.3.9.5.1 Data communications human-to-system interfaces shall be designed for ease of
handling infrequent, critical situations and emergencies in accordance with the HFDS, Chapter
2.5.7 Provide emergency procedures for critical systems.


6.2.3.9.6     Automation Function Indications


6.2.3.9.6.1    Data communications shall provide indications when automation functions:
       a. are enabled and

       b. when they are disabled
in accordance with the HFDS:


                                                66
        c. Chapter 3.3 System response and feedback and

        d. Chapter 3.6 Modes.


6.2.3.9.7     Degraded Mode Operation


6.2.3.9.7.1 Data communications interfaces shall be designed to enable efficient, accurate use
during degraded modes (when one or more functions are disabled) in accordance with the HFDS,
Chapter 3.6.6 Provide consistent features and functions.


6.2.3.9.8     Fault Management


6.2.3.9.8.1 Data communications automated diagnostics aids shall enable fault management
and system failure recovery through timely user notification of specific failures or potential
failures in accordance with the HFDS, Chapter 3.8 Fault Management.


6.2.3.10      Computer-Human-Interface Requirements


6.2.3.10.1 Data communications computer-to-human interfaces shall be in accordance with the
HFDS, Chapter 8 Computer human interface.

6.2.3.10.2     Data communications display of information shall be integrated into existing user
interfaces.


6.2.3.10.3     Screen Design


6.2.3.10.3.1     Data communications screen designs shall be accordance with the HFDS:
        a. Chapter 8.1 Screen Design and

        b. integrate within the existing screen design features.


6.2.3.10.4     Visual Coding


6.2.3.10.4.1 Data communications visual coding shall be in accordance with the HFDS,
Chapter 8.6 Coding.




                                                 67
6.2.3.10.5     Color-Coding


6.2.3.10.5.1    Data communications color-coding shall be in accordance with the HFDS:
       a. Chapter 8.6 Coding and

       b. Chapter 8.6.2 Color.


6.2.3.10.6     Redundant Coding


6.2.3.10.6.1 Data communications color-coding shall have a second, redundant coding
dimension in accordance with the HFDS, Chapter 8.6.2.1.5 Redundant use.


6.2.3.10.7     Auditory Alerts and Alarms


6.2.3.10.7.1 Data communications alarms and alerts shall be in accordance with the HFDS,
Chapter 7 Alarms, audio, and voice.


6.2.3.10.8     User Interaction


6.2.3.10.8.1    Data communications user-to-system interactions shall be in accordance with the
HFDS:
       a. Chapter 8.7 Interaction and

       b. 8.8 General interactive techniques.


6.2.3.10.9     Systems Operations


6.2.3.10.9.1 Data communications human-to-system interfaces shall be in accordance with the
HFDS Chapter 8.15 System Operations.


6.2.3.10.10     System Response Time


6.2.3.10.10.1 Data communications shall provide feedback when system response to a control
action is greater than 2 seconds in accordance with the HFDS, Chapter 8.15.6 System response
time.


                                                68
6.2.3.11     Workstations


6.2.3.11.1 Data communications workstations shall be in accordance with the HFDS, Chapter
10 Workstation and Workplace design.


6.2.3.12     Displays


6.2.3.12.1 Data communications displays shall be selected in accordance with the HFDS,
Chapter 5 Displays and printers.


6.2.3.12.2    Readability


6.2.3.12.2.1 Data communications displays shall be readable from the position from which
they will be used in accordance with the HFDS, Chapter 5.1.2 Location and arrangement.


6.2.3.12.3    Input Devices


6.2.3.12.3.1 Data communications input devices shall be in accordance with HFDS, Chapter 9
Input devices.


6.2.3.13     Maintainability


6.2.3.13.1 Data communications maintainer-to-system interfaces shall be in accordance with
the HFDS, Chapter 4 Designing equipment for maintenance.


6.2.3.14     Labeling


6.2.3.14.1 Data communications equipment labeling shall be in accordance with HFDS,
Chapter 4.3.5 Labeling and marking.


6.2.3.14.2    Safety Labels




                                             69
6.2.3.14.2.1 Data communications equipment safety labeling shall be in accordance with the
HFDS, Chapter 12.16 Safety labels and placards.


6.2.3.15     User Documentation


6.2.3.15.1 Data communications user documentation shall be in accordance the HFDS,
Chapter 15 User documentation.


6.2.3.15.2     Technical Manuals


6.2.3.15.2.1 Data communications technical manuals shall be in accordance the HFDS,
Chapter 15 User documentation.

6.3     Employee Safety and Health

Human factors issues are critical to safety, availability, and the effectiveness of data
communications.

6.3.1 Lowest Replaceable Units (LRUs) in NAS maintained data communications ground-
based unique equipment shall be designed to permit removal and replacement by one person in
accordance with the Human Factors Design Standard.
6.3.2 Data communications personnel safety shall be in accordance with:
          a. FAA Order 3900.19B Occupational Safety and Health Program,

          b. the HFDS Section 12 Personnel safety, and

          c. FAA-G-2100G Electrical Equipment, General Requirements.

6.3.3     Anthropometry and Biomechanics


6.3.3.1 Data communications human-to-system physical interfaces shall be in accordance with
the HFDS, Chapter 14 Anthropometry and biomechanics.

6.3.4     Maintainer Workspace


6.3.4.1     Data communications maintainer:
          a. physical and

          b. visual
access shall be in accordance with the HFDS:



                                                 70
          c. Chapter 4.3.4.1 Physical accessibility and

          d. 29 CFR 1910.303 Electrical.


6.3.4.2     Access to Serviceable Components


6.3.4.2.1 Data communications Lowest (Line) Replaceable Units shall be accessible and
removable at the equipment’s operational location in accordance with the HFDS, Chapter 4.3.4
Positioning equipment.


6.3.4.3     Critical Item Location


6.3.4.3.1 Data communications critical items shall be accessible in accordance with the HFDS,
Chapter 4.3.4.2 Relative accessibility.


6.3.4.4     High Failure Rate Item Location


6.3.4.4.1 Data communications high failure-rate items shall be accessible in accordance with
the HFDS, Chapter 4.3.4.2 Relative accessibility.


6.3.4.5     Equipment Mounting


6.3.4.5.1 Data communications components shall be mounted in accordance with the HFDS,
Chapter 4.3.3 Mounting in drawers, on racks, and on hinges.




                                                 71
7.    SECURITY

The Preliminary Security Risk Assessment for data communications was performed to determine
the minimum security requirements, which are identified in this section. The security
requirements are organized according to the security control families in National Institute of
Standards and Technology (NIST) Federal Information Processing Standards (FIPS) Publication
200, Minimum Security Requirements for Federal Information and Information Systems.

7.1     Technical Controls

Technical controls are the safeguards or countermeasures that are primarily implemented and
executed by information systems.

7.1.1     Access Control


7.1.1.1     Data communications shall limit information system access to authorized:
          a. users,

          b. processes acting on behalf of users, and

          c. devices (including other information systems).

7.1.1.2 Data communications shall limit information system access to the types of transactions
and functions that authorized users are permitted to exercise.

7.1.2     Audit and Accountability


7.1.2.1     Data communications shall provide an audit capability.

7.1.2.2 Data communications shall ensure that the actions of individual information system
users can be uniquely traced to those users so they can be held accountable for their actions.

7.1.3     Identification and Authentication


7.1.3.1     Data communications shall identify information system:
          a. users,

          b. processes acting on behalf of users, and

          c. devices.

7.1.3.2     Data communications shall authenticate the information system:
          a. users,


                                                 72
          b. processes acting on behalf of users, and

          c. devices.

7.1.4     System and Communications Protection


7.1.4.1     Data communications shall provide boundary protection at the external boundaries.

7.1.4.2 Data communications shall provide boundary protection at key internal boundaries of
the information system.

7.1.4.3 In Segments One and Two, data communications shall protect from intentional threats
the integrity of Ground-Ground information
          a. stored,

          b. processed, and

          c. transmitted.

7.1.4.4 In Segments One and Two, data communications shall protect from unintentional
threats the integrity of Ground-Ground information
          a. stored,

          b. processed, and

          c. transmitted.

7.1.4.5 In Segment Two, data communications shall protect from intentional threats the
integrity of Air/Ground information
          a. stored,

          b. processed, and

          c. transmitted.

7.1.4.6 In Segment Two, data communications shall protect from unintentional threats the
integrity of Air/Ground information
          a. stored,

          b. processed, and

          c. transmitted.

7.1.4.7     Data communications shall protect itself from threats to availability.

7.1.4.8     Data communications shall use only government-approved cryptographic algorithms.


                                                  73
7.1.4.9 Data communications shall perform all cryptographic operations using FIPS PUB 140-
2, Security Requirements for Cryptographic Modules validated cryptographic modules operating
in approved modes of operation.

7.1.5     Integrity


7.1.5.1    Data communications shall protect assets from unauthorized modification.

7.1.5.2    Data communications shall protect assets from unauthorized deletion.

7.1.5.3    Data communications shall protect assets from unauthorized creation.

7.1.5.4    Data communications shall protect assets against false or misleading data.

7.1.6     Availability


7.1.6.1    Data communications shall protect assets from denial of service.

7.1.6.2    Data communications shall protect assets unacceptable degradation of service.

7.1.7     Confidentiality


7.1.7.1    Data communications shall restrict the release of NAS data to authorized entities.

7.1.8     Non-Repudiation


7.1.8.1    Data communications shall implement non-repudiation.

7.1.9     Malicious Activity


7.1.9.1    Data communications shall detect malicious activity.

7.1.9.2    Data communications shall deter malicious activity.

7.1.9.3    Data communications shall alert specialists when malicious activity is detected.

7.2     Management Controls

Management controls are the safeguards or countermeasures that focus on the management of
information systems and the management of risk.




                                                74
7.2.1     Certification, Accreditation, and Security Assessments


7.2.1.1 Data communications shall implement an information system security program in
accordance with FAA Order 1370.82A, FAA Information Systems Security Program.

7.2.2     System Services Acquisition


7.2.2.1 Data communications shall ensure that third-party providers employ adequate security
measures to protect:
          a. information,

          b. applications, and

          c. services outsourced from the organization.

7.3     Operational Controls

Operational controls are the safeguards or countermeasures that are primarily implemented and
executed by people (e.g., day-to-day procedures).

7.3.1     Maintenance


7.3.1.1 Data communications shall perform periodic and timely maintenance on organizational
information systems.

7.3.2     Media Protection


7.3.2.1     Data communications shall protect information system media.

7.3.3     Physical and Environmental Protection


7.3.3.1 The Data Communications Program Office shall ensure that the physical security
controls for the data communications ground components comply with;
          a. FAA Order 1600.6, Physical Security Management Program and

          b. FAA Order 1600.69, FAA Facility Security Management Program.

7.3.4     Personnel Security


7.3.4.1 Data communications shall provide personnel security controls in accordance with
FAA Order 1600.1, Personnel Security Program.


                                                75
7.3.4.2 Data communications shall provide contractor and industrial personnel security
controls in accordance with FAA Order 1600.72, Contractor and Industrial Security Program.

7.3.5     System and Information Integrity


7.3.5.1     Data communications shall provide protection from malicious code.

7.3.5.2 Data communications shall provide the capability to produce information system
security
          a. alerts and

          b. advisories.




                                               76
8.    IN-SERVICE SUPPORT

An Integrated Logistics Support (ILS) program will be established in accordance with FAA
Acquisition Management System (AMS) guidance to ensure that integrated logistics support
requirements are uniformly identified, acquired, allocated, controlled, and maintained.

To provide sound integrated logistics support planning for data communications the ILS
elements listed below are required to be within data communications lifecycle phases (mission
analysis, investment analysis, solution implementation, in-service management). It is also
necessary to manage the interdependencies among these elements within each phase while
adhering to the principles of asset supply chain management (i.e., the integration of suppliers,
users, and schedules). The nine elements that need to be addressed for data communications are:
            Maintenance planning;
            Maintenance support facility;
            Direct-work maintenance staffing;
            Supply support;
            Support equipment;
            Training, training support, and personnel skills;
            Technical data;
            Packaging, handling, storage, and transportation;
            Computer resources support.

8.1     Staffing

Support staffing for the data communications will be in accordance with FAA Order 1380.40,
Airway Facilities Sector Level Staffing Standard System.

8.1.1    The
         a. operation and

         b. maintenance
of data communications shall minimize:
         a. NAS site,

         b. second-level engineering, and

         c. depot
human resource requirements.

8.2     Supply Support

It is anticipated that the data communications Prime Contractor or the FAA Logistics Center in
Oklahoma City, Oklahoma will provide supply support and repair services for the data
communications system. This should include all activities associated with ordering, receiving,
tracking, sending, cataloging, and inventory management of supplies needed in order to operate
and maintain the system.


                                               77
8.2.1     Initial Site and Depot Spares

Data communications NAS maintained ground-based unique equipment will be delivered with
initial site and depot spares in accordance with FAA Order 6000.38, Policy to Determine NAS
Equipment Sparing Requirements for Airways Facilities Work Centers.

8.2.1.1 The list of site spares shall be recommended by the contractor and approved by the
government.

8.2.1.2 The suite of site spares shall be sufficient to support the availability requirements of
data communications.

8.2.2     Bar Coding and Asset Tracking


8.2.2.1     Data communications ground-based unique equipment shall use the FAA:
          a. bar code asset serial number symbology,

          b. quality, and

          c. format
specifications contained in the latest edition of the FAA Bar Coding Specification available at the
time this requirement is baselined in the contractors’ deliverable, to bar code system components
at the line replaceable/repairable unit, including all site spares.

8.2.2.2 All data communications LRUs for hardware and software applications will be bar
coded to identify inventory as part of shipment for site installations and all site sparing.

8.3     Support Equipment

8.3.1     Data communications ground-based unique equipment shall be designed to:
          a. make use of existing support equipment, test equipment, and tools in the FAA
             inventory, and

          b. identify requirements for additional or unique support and test equipment.

8.4     Technical Data

The following sections present the requirements for technical instructions books and for
maintenance documentation.

8.4.1     Technical Instruction Books

Technical manuals will be provided for data communications maintenance for all levels of FAA
maintenance, as required. Manuals and applicable Commercial Off-the-Shelf (COTS)



                                                 78
documentation will be delivered to each data communications site both electronically and in
hardcopy with the hardware delivery.

8.4.1.1 Data communications Technical Instruction Books (TIBs) shall reflect the as-accepted
configuration of data communications.

8.4.2    Second-Level Hardware and Software Maintenance Documentation

Second-level hardware and software maintenance documentation will be delivered to the
operational support organization prior to deployment of data communications ground-based
unique equipment.

8.4.3    Re-procurement Data Package

An option to receive all or part of the data communications Re-procurement Data Package will
be available to ensure the FAA’s ability to acquire replacement equipment.

8.5     Training and Training Support

Training will be developed in accordance with FAA-STD-028C, Contract Training Programs,
(as modified by the Government) to provide ATO personnel with the knowledge and skills to
operate, maintain and monitor data communications in accordance with the implementation,
operations and maintenance concepts of the program.

8.5.1    Course Development

The data communications program shall provide for a minimum of two operational try-outs of
the ATO personnel training curriculum.

8.6     First- and Second-Level Repair

Data communications NAS maintained ground-based unique equipment will be maintained in
accordance with FAA Order 6000.30, National Airspace System Maintenance Policy and FAA
Order 6000.15, General Maintenance Handbook for Airway Facilities. Contractor assisted
maintenance for data communications, if required, will be in accordance with FAA Order
6000.41, Policy Governing Contractor-Assisted Maintenance For The National Airspace System.
Maintenance and logistics support will be provided at government acceptance for each site.

8.6.1 Second-Level Engineering support for data communications hardware and software, if
required, shall be provided in accordance with:
         a. FAA Order 6000.30, National Airspace System Maintenance Policy and

         b. FAA Order 1100.157, National Systems Engineering Divisions Maintenance
            Program Procedures, Operational Support (AOS).

8.7     Depot Maintenance



                                              79
8.7.1 A life cycle cost trade off analysis shall be performed to determine the repair policy for
data communications ground-based unique equipment components.
8.7.2 Any
         a. unique and

         b. developmental
hardware shall be
         c. treated as a developmental item,

         d. be provisioned, and

         e. be a candidate for depot repair.
8.7.3 The FAA Logistics Center (FAALC) shall manage all vendor repair contracts for data
communications ground-based unique equipment.

8.8     Packaging, Handling, Storage, and Transportation

8.8.1 Data communications Packaging, Handling, Storage, and Transportation shall be in
accordance with:
         a. FAA Order 4650.31, Vendor Shipments of Nationally Furnished Operations-Funded
            Material,

         b. FAA Order 4770.3, Transportation and Traffic Management of Government
            Property,

         c. American Society for Testing and Materials (ASTM)-D3951, Standard Practice for
            Commercial Packaging and

         d. MIL-STD-2073-1, DOD Material Procedures for Development and Application of
            Packaging Requirements.

8.9     Disposal

A disposal plan will be developed in accordance with FAA Order 4800.2, Utilization and
Disposal of Excess and Surplus Personal Property, and be coordinated with the NAS Logistics
Property Management Division.

8.9.1    Data Communications Lifecycle

8.9.1.1 Data communications ground-based unique equipment life cycle shall be no less than
that required for government acceptance.

Periodic technology refreshment of hardware and software may occur to ensure satisfactory
performance and supportability at affordable costs.

8.10     Facility Codes



                                                80
A facility identification code will be assigned to data communications in accordance with FAA
Order 1375.4, Standard Data Elements.
8.10.1 Data communications shall have a profile in the Facilities, Services, and Equipment
Profiles (FSEP).
8.10.2 Facility Reference Data File (FRDF) information shall be disseminated for data
communications in accordance with FAA Order 6030.45, Facility Reference Data.

8.11   Project Material Management

8.11.1 Data communications facilities and equipment project material shall be managed in
accordance with:
       a. FAA Order 4630.2, Standard Allowance of Supplies and Working Equipment for
          National Airspace System Facilities,

       b. FAA Order 4650.7, Management of NAS F&E Project Material and

       c. FAA Order 4630.30, Management and Control of NAS F&E Project Material.
8.11.2 Data communications project material shall be managed in accordance with FAA Order
4140.1, Integrated Material Management Program.
8.11.3 National stock numbers shall be assigned to data communications material in
accordance with FAA Order 4500.3, Federal Catalog and Standardization Programs (FCSP).
8.11.4 Contractor depot inventories of operating material shall be maintained in accordance
with FAA Order 4630.1, Management of Depot Inventories of Operating Material.
8.11.5 Data communications material shall be inventoried in accordance with FAA Order
4633.1, Physical Inventory.
8.11.6 Lost, damaged, misplaced, and destroyed material shall be removed from inventory in
accordance with FAA Order 4630.3, Survey of Lost, Damaged, or Destroyed Personal
Government Personal Property.

8.12   Technical Operations Certification

8.12.1 The service and systems of data communications meeting the criteria stated in FAA
Order 6000.15, General Maintenance Handbook for Airways Facilities, shall be certified.
8.12.2 Data communications shall be certified in accordance with FAA Order 6000.15,
General Maintenance Handbook for Airway Facilities.
8.12.3 Data communications operational approval shall be consistent with RTCA DO-264,
Guidelines for Approval of ATS Supported by Data Communications.




                                              81
9.    TEST AND EVALUATION

The following sections present test and evaluation requirements.

9.1     Critical Operational Issues

                Note: Test planning and conduct will involve required stakeholders.

9.1.1    Testing shall be conducted to:
         a. ensure that functional and subnetwork performance requirements can be met in an
            operational environment and

         b. to resolve the following Critical Operational Issues (COIs):

         c. COI 1: Does data communications interface and operate with existing equipment and
            systems?

         d. COI 2: Can data communications be used without disruption or degradation to ATC
            operations?

         e. COI 3: Does data communications provide the required level of reliability,
            maintainability and availability?

         f. COI 4: Can data communications be maintained without disruption or degradation of
            current ATC operations?

         g. COI 5: Does data communications maintain at least the current level of efficiency
            and accuracy of communications between the controller and pilot?

         h. COI 6: Does data communications time performance allow for effective exchange of
            controller and pilot communications?

         i. COI 7: Does data communications HMI effectively support the ATO?

         j. COI 8: Is sufficient training provided for ATO to effectively operate data
            communications?
9.1.2 Testing shall be conducted to ensure compliance with RTCA DO-264, Section 5.2
qualification requirements.

9.2     Test and Evaluation Requirements

Test and Evaluation (T&E) is conducted by the FAA, in accordance with Acquisition
Management System (AMS) Test & Evaluation Process Guidelines, to evaluate the subsystem
operational effectiveness and suitability including compatibility, interoperability, degraded
operations, maintainability and supportability. T&E also identifies deficiencies in NAS
hardware, software, human performance factors, COIs and/or operational concepts.

9.2.1    System Test



                                                 82
The following categories and classes of tests may be conducted for data communications:

   1. Functional Testing - This testing will verify all functional threads. The objective is to
      verify the complete message set and associated functions have been properly
      implemented. Testing will be conducted in a simulated environment.

   2. Performance/Load Testing - Simulation will be used as required to create realistic levels
      of traffic on the FAA portion of the ground-based system.

   3. Up-level/Regression Testing - This testing will ensure that data communications
      application changes have been integrated into data communications without adversely
      affecting the baseline system.

   4. End-to-End Testing - This testing will be conducted using the air-ground subnetwork and
      avionics in a laboratory environment with attenuated radio frequency (RF). This testing
      will verify end-to-end operational and technical interoperability using scenarios that
      exercise complete end-to-end data communications.

   5. Independent Network Test - This testing will determine subnetwork performance
      independent of data communications messages.

   6. Operational Suitability and Effectiveness - This testing will evaluate the operational
      suitability and effectiveness of data communications with respect to ATC controller
      operations, flight deck operations, ground/air communications network, aircraft operator,
      FAA maintenance and FAA support functions.

   7. Flight and End-to-End Testing – Flight testing/end-to-end testing will be conducted in an
      airspace environment where the equipped test aircraft will fly in and out of
      RF/subnetwork coverage. This testing will verify end-to-end operational and technical
      interoperability, which exercises end-to-end data communications.

   8. Interface Testing – Testing with interfacing systems to ensure data communications does
      not disrupt or degrade the operations or maintainability of the interfacing systems.

9.2.2   Field Familiarization

ATO site personnel perform field familiarization to confirm readiness for integration of the
system into each NAS site, leading to system commissioning.




                                               83
10.    IMPLEMENTATION AND TRANSITION

The following sections present requirements for the implementation of and orderly transition to
data communications services.

10.1     Deployment Planning

10.1.1 Deployment planning shall be conducted in accordance with the Acquisition
Management System policy and guidance in order to obtain the in-service decision prior to
delivery of data communications into the NAS.
10.1.2 The In-Service Review Checklist template shall be:
         a. tailored and

         b. used
to assess operational readiness and suitability prior to deploying data communications.

10.1.3     Project Implementation Plan


10.1.3.1 A project implementation plan shall be generated using current guidelines consisting
of those activities necessary to:
         a. prepare the site,

         b. deliver,

         c. install,

         d. integrate,

         e. test, and

         f. commission
data communications into NAS operations.

10.1.3.2    An implementation approach for Physical Equipment and Facilities shall be provided.

10.1.3.3 ATC operational capability shall be maintained during data communications
implementation activities.

10.1.4     Site Surveys


10.1.4.1 Site surveys shall be completed to determine needed modifications to assigned space
and other site preparations necessary for the:
         a. installation and

         b. integration


                                               84
of data communications into facilities.

10.1.4.2
         a. Site surveys and

         b. system specifications
shall identify:
         a. office,

         b. administrative,

         c. contractor, and

         d. FAA
workspace.

10.1.5     Site Preparation


10.1.5.1 A Generic Site Implementation Plan (GSIP) shall be prepared in accordance with
current guidelines.

10.1.5.2    Site preparation for data communications shall be:
         a. planned,

         b. scheduled, and

         c. overseen
by facility personnel.

10.1.5.3    The FAA shall:
         a. provide site preparation engineering support and

         b. prepare generic and site-specific engineering packages
to support data communications.

10.1.5.4 Contractors and program offices shall provide revisions to specific site preparation
and requirement activities in time to allow their incorporation prior to system delivery.

10.1.6     Facility Modifications


10.1.6.1    The FAA shall:
         a. plan,

         b. schedule, and


                                                85
         c. oversee
construction of site-specific facility modifications.

10.1.7     Fit-up Activities


10.1.7.1    Contractor fit-up activities shall not degrade air traffic operations.

10.1.7.2    Contractor fit-up work shall be in accordance with:
         a. FAA-G-2100G, NFPA 70, and

         b. state and

         c. local
codes.

10.1.8     Equipment Delivery


10.1.8.1    Equipment delivery shall be coordinated to ensure that:
         a. personnel and

         b. internal and external space
are available to accept deliveries at established times.

10.1.8.2 Contractors shall be responsible for determining the conditions necessary for interim
storage and security of delivered equipment and supplies.

10.1.8.3    Contractors shall be:
         a. responsible for moving data communications equipment into the facility and

         b. placing and

         c. installing
it.

10.1.9     Power-up Test and Compatibility


10.1.9.1 Initial power-up testing shall be accomplished, except on operationally active critical
power centers.

10.1.9.2 Electrical equipment shall be tested for power compatibility prior to connection to
FAA critical power panels.

10.1.9.3    Electrical equipment connected to NAS equipment shall be tested for compliance with



                                                  86
         a. FAA-G-2100G, Electronic Equipment, General Requirements and

         b. FAA Order 6950.2, Electrical Power Policy Implementation, NAS Facilities.

10.2     Ground Infrastructure Implementation

The following sections present the requirements for the implementation and integration of the
data communications ground-based equipment.

10.2.1      Integration


10.2.1.1      An integration strategy for:
         a. Physical Equipment and

         b. Facilities
shall be provided.

10.2.1.2      The integration strategy shall cover:
         a. facility equipment,

         b. space,

         c. operations, and

         d. personnel
impacts and procedures.

10.2.1.3      The integration strategy shall ensure that integration has no unsafe impact on:
         a. ATC and

         b. airspace user
operations.

10.2.1.4      The integration strategy shall provide for the continuity of:
         a. full ATC and

         b. airspace user
services.

10.2.1.5      The integration strategy shall allow for the:
         a. integration and

         b. acceptance testing
of data communications.



                                                      87
10.2.1.6      The integration strategy shall provide for:
         a. interfaces and

         b. external facilities
to ensure the continuity of air traffic control services.

10.2.1.7      The integration process shall provide capabilities for:
         a. redundancy, and

         b. fallback.

10.2.1.8      The integration strategy shall provide:
         a. procedures and

         b. a methodology
for the physical integration of data communications into the NAS.

10.2.1.9      The FAA shall provide human resources for:
         a. integration and

         b. test
activities.

10.2.1.10      Required operational interruptions or changes in operational procedures shall be:
         a. defined,

         b. examined,

         c. evaluated, and

         d. managed
through an integration plan.

10.2.1.11      FAA site personnel shall have consent authority over site-specific system integration
issues.

10.3     Transition

10.3.1     The transition approach shall include:
         a. a process for moving between systems, elements and components, as well as

         b. a fallback process
that is operationally acceptable.
10.3.2 A transition plan shall be developed that allows for:
         a. facility equipment,


                                                    88
          b. space,

          c. operations, and

          d. personnel
impacts and procedures.
10.3.3 The transition plan shall ensure that the transition has no adverse impact on:
          a. ATC and

          b. airspace user
operations.
10.3.4 The transition plan shall allow for the:
          a. installation,

          b. integration, and

          c. acceptance testing
of the equipment.
10.3.5 The transition plan shall provide:
          a. procedures and

          b. methodology
for the
          a. logical and

          b. physical
transition of data communications into the NAS and where applicable, for transition of the legacy
system out of the NAS.
10.3.6 The transition plan shall include the approach for:
          a. Operations,

          b. Physical Equipment, and

          c. Facilities.
10.3.7     The transition plan shall provide for continuity of full ATC services.
10.3.8     The transition process shall provide for:
          a. redundancy, and

          b. fallback.

10.4      In-service Transition

10.4.1 Data communications shall provide for in-service transition activities with related
systems.
10.4.2 Air traffic operational capability shall be maintained during transition.
10.4.3 The data communications transition strategy shall provide for:


                                                  89
        a. interfaces and

        b. external facilities
to ensure the continuity of Air Traffic Control Services.
10.4.4 Required
        a. operational interruptions or

        b. changes in operational procedures
shall be:
        c. defined,

        d. examined,

        e. evaluated, and

        f. managed
through a transition plan.

10.5    ATC Facilities Interface

10.5.1 Data communications shall be capable of interfacing with all appropriate ATC facilities
regardless of the:
        a. transition state or

        b. level of technical evolution
of each site.

10.6    Data Presented to Service Providers

10.6.1 The data presented to any communication service provider during initial system
transition shall be consistent with industry standards for the communication service provider
interface.

10.7    Coexistence with Present System

10.7.1 The installation and operation of data communications shall produce no adverse impact
upon the other NAS subsystems with which it interfaces.

10.8    Implementation Considerations

The message composition tools should consider the following:
        a. RTCA, DO-256, Minimum Human Factors Standards for Air Traffic Services
           Provided Via Data Communications Utilizing the ATN, Builds I and IA and

        b. RTCA, DO-238, Human Engineering Guidance for Data Link Systems.




                                                90
11.    QUALITY ASSURANCE

The quality assurance requirements for data communications are presented in the following
sections.

11.1     Quality Assurance Program

11.1.1    The data communications Quality Assurance Program (QAP) shall be:
         a. established and

         b. maintained
in accordance with ISO 9001:2000 Quality Management Systems Requirement, International
Organization for Standardization, and provide:
         c. A quality assurance organization that has sufficient responsibility and authority to
            identify and evaluate quality problems, and to initiate, recommend, or provide
            solutions.

         d. Procedures and controls to assure hardware and software quality assurance during all
            operations through final acceptance.

         e. Controls to assure (including internal program quality assurance audits) that all
            inspection and testing is performed in compliance with contract requirements and that
            all test data is complete, correct, traceable, repeatable, and acceptable.

         f. Maintenance of proper record keeping function to provide objective evidence and
            traceability of operations performed.

         g. Procedures and controls for assuring that all hardware and software products or
            services procured from subcontractors conform to contract requirements.

         h. Procedures and controls to assure that all documentation is adequately reviewed and
            meets contract requirements.

         i. Procedures and controls for the prevention of hardware and software deficiencies,
            detection and analysis of deficiencies when they do occur, as well as procedures for
            corrective action.
11.1.2    The data communications QAP shall comply with RTCA DO-264, section 7.1.1.

A system of periodic internal quality audits or reviews to verify quality activities and related
results are in compliance with planned arrangements, and to verify that the QAP is performing
effectively.




                                                 91
12.    CONFIGURATION MANAGEMENT

The data communications configuration management requirements are presented in the following
sections.

12.1     NAS Configuration Management Change Control Procedures

12.1.1    Data communications Configuration Management shall be in accordance with:
         a. FAA Order 1800.8f, National Airspace Configuration Management and

         b. EIA-649-A, National Consensus Standard for Configuration Management.
12.1.2 Data communications Engineering Change Proposals and deviations shall comply with
EIA-649-A, National Consensus Standard for Configuration Management.
12.1.3 Data communications NAS Change Proposals (NCPs) shall comply with FAA Order
1800.8F, National Airspace System Configuration Management.




                                             92
13.    IN-SERVICE MANAGEMENT

Requirements for assessing the performance of data communications are presented in the
following sections.

13.1     Product Baseline

13.1.1 The product baseline for data communications shall comply with RTCA DO-264,
section 7.1.2.

13.2     Performance Monitoring

13.2.1    Performance shall be:
         a. monitored and

         b. provided
using data obtained in Section 5.1.1, Remote Maintenance Monitoring System Interface
Capabilities of this document.
13.2.2 Data communications performance shall comply with RTCA DO-264, section 7.2.1.




                                             93
14.    SYSTEM SAFETY MANAGEMENT

The system safety management requirements for data communications are presented in the
following sections.

14.1     Safety Assessments

14.1.1    Program safety assessments shall be in accordance with the following:
         a. the RTCA DO-264, Guidelines for Approval of ATS Supported by Data
            Communications,

         b. the ATO-S 2006-1, Safety Risk Management Guidance for System Acquisitions
            (SRMGSA),

         c. the FAA Safety Management System (SMS) Manual,

         d. FAA Order 8040.4 Safety Risk Management, and

         e. FAA System Safety Handbook, December 30, 2000.

14.2     Integrated Safety Plan

14.2.1 An Integrated Safety Plan (ISP) shall be developed for the final investment decision in
accordance with ATO-S 2006-1, Safety Risk Management Guidance for System Acquisitions
(SRMGSA).

14.3     Risk Acceptance and Safety Risk Management Documentation Approval

14.3.1 Program Risk Acceptance and Documentation Approval procedures shall be conducted
in accordance with ATO-S 2006-1, Safety Risk Management Guidance for System Acquisitions
(SRMGSA) and the Safety Management System.

14.4     Standards

14.4.1 The requirements for data communications shall also be in accordance with the
following;
         a. Executive Order 12196, Occupational Safety and Health Program for Federal
            Employees,

         b. Title 29 CFR 1960, Safety And Health Provisions for Federal Employees,

         c. FAA Order 3900.19B, Occupational Safety and Health Program,

         d. FAA Order 8040.4, Safety Risk Management,

         e. Aeronautical Information Manual,

         f. Federal Aviation Regulations,


                                               94
g. FAA Order JO 1000.37 Air Traffic Organization Safety Management System,

h. FAA-STD-025E, Preparation of Interface Documentation,

i. FAA-STD-60, Data Standard for National Aerospace System, and

j. RTCA DO-278, Guidelines for Communication, Navigation, Surveillance and Air
   Traffic Management (CNS/ATM) Systems Software Integrity Assurance or equivalent.




                                     95
Appendix A Mission Shortfall Correlation Matrix

The Mission Shortfall Statement/Requirements correlation matrix below traces shortfall statements from the Mission Shortfall Statement for
Data Communications to the Preliminary Program Requirements for Data Communications. The shortfall statements are called out below and
section/sub-section numbers are used to direct the reader to the appropriate section of the Mission Shortfall Statement (MSS).

Those shortfall statements for which no trace to the requirements is shown, are related to the infrastructure improvement needs and are not
specifically addressed in the Preliminary Program Requirements for Data Communications.

MSS Section          MSS Sub-             Shortfall Statement                                     PPR Section or Sub-Section
                     Section
2.0 SERVICE          2.1.1 Safety         The current NAS voice air/ground communications         3.1.1.1 Messaging Requirements
IMPROVEMENT          Technology           system requires controllers to issue and verify         3.1.1.3 Data Communications Requirements
MISSION NEED         Opportunity          instructions to pilots. This workload-intensive,        3.1.1.4 Instructions, Advisories, and Report Request
                                          voice-based process can generate                        Responses Requirements
                                          miscommunications, which can contribute to              3.1.1.5 Automatic Terminal Information Service
                                          operational errors.                                     Requirements
                                                                                                  3.1.1.8 Departure and Taxi Clearance Requirements
                                                                                                  3.1.1.9 En Route Clearance Requirements


2.0 SERVICE          2.1.2 Productivity   Data communications achieves these results by           3.1.1.4 Instructions, Advisories, and Report Request
IMPROVEMENT          Shortfall            automating repetitive tasks, replacing voice            Responses Requirements
MISSION NEED                              communications with less workload-intensive data        3.1.1.5 Automatic Terminal Information Service
                                          communications, and enabling ground systems to use      Requirements
                                          real-time aircraft data to improve traffic management   3.1.1.6 Integration Requirements
                                          efficiency.                                             3.1.1.8 Departure and Taxi Clearance Requirements
                                                                                                  3.1.1.9 En Route Clearance Requirements




                                                                            96
MSS Section      MSS Sub-            Shortfall Statement                                      PPR Section or Sub-Section
                 Section
2.0 SERVICE      2.1.3 Capacity      The 1996 Terminal Data Benefits Study, bolstered by      3.1.3 Segment Three Requirements
IMPROVEMENT      Shortfall           recent Eurocontrol research and trials, showed
MISSION NEED                         slightly larger capacity gains were possible when data
                                     communications were introduced in bottleneck
                                     approach and departure airspace.



2.0 SERVICE      2.1.3 Capacity      Advanced concepts such as 4 dimensional flight path      3.1.1.6 Integration Requirements
IMPROVEMENT      Shortfall           management, higher density operations, and               3.1.1.9 En Route Clearance Requirements
MISSION NEED                         “management by planning/intervention by                  3.1.2 Segment Two Requirements
                                     exception”, will be possible when data                   3.1.3 Segment Three Requirements
                                     communications are robust and universal. Only then       3.2.1.1 Performance
                                     can the NAS realize the system capacity required to      3.2.1.2 Number of Aircraft Supported
                                     meet ever-increasing demand for air travel               3.2.1.3 Message Exchange Rates
                                                                                              3.2.1.4 Coverage Area Supported
                                                                                              3.2.2 Segment Two Product Characteristics and
                                                                                              Performance Requirements
                                                                                              3.2.2.1 Performance
                                                                                              3.2.2.2 Number of Aircraft Supported
                                                                                              3.2.2.3 Message Exchange Rates
                                                                                              3.2.2.4 Coverage Area Supported
                                                                                              3.2.3 Segment Three Product Characteristics and
                                                                                              Performance Requirements
                                                                                              3.2.3.1 Performance
                                                                                              3.2.3.2 Number of Aircraft Supported
                                                                                              3.2.3.3 Message Exchange Rates
2.0 SERVICE      2.1.3 Capacity      Solutions to meet these performance gaps must be         3.1.1.10 Applicable Standards
IMPROVEMENT      Shortfall           operationally and technically interoperable between
MISSION NEED                         airspace users and the ATO; and, be globally
                                     harmonized.
3.0              3.1.2 Ground User   Additional functions in the controller and supervisor    3.1.1.3 Data Communications Requirements
INFRASTRUCTURE   Interfaces          workstations will be required.                           3.1.2 Segment Two Requirements
IMPROVEMENT                                                                                   3.1.2.1 Data Communications Requirements
MISSION NEED




                                                                        97
MSS Section      MSS Sub-            Shortfall Statement                                        PPR Section or Sub-Section
                 Section
3.0              3.1.2 Ground User   It is also expected that, depending on systems             3.1.1.7 Recording of Messages, Statistical, and
INFRASTRUCTURE   Interfaces          engineering decisions, other displays, such as traffic     Performance Data
IMPROVEMENT                          management unit displays and maintenance/support
MISSION NEED                         user interfaces will require additional functionality in
                                     order to support data communications.


3.0              3.1.3 Ground Data   Data Communications will require new functions             3.1.1.6 Integration Requirements
INFRASTRUCTURE   Processing          (controller pilot data communications, flight
IMPROVEMENT                          information functions, and the ability to uniquely
MISSION NEED                         identify aircraft capable of data communications)
                                     which directly support data communications (shown
                                     in subsequent paragraphs).
3.0              3.1.3 Ground Data   For example, the flight data processor interfaces          3.1.1.6 Integration Requirements
INFRASTRUCTURE   Processing          directly with controller-pilot data communications
IMPROVEMENT                          function.
MISSION NEED
3.0              3.1.3 Ground Data   The flight data processor will also require new            3.1.1.2 Unique Identification Requirements
INFRASTRUCTURE   Processing          functionality (e.g. data verification, eligible
IMPROVEMENT                          controller/aircraft identification).
MISSION NEED
3.0              3.1.3 Ground Data   Enhancements to the accuracy of conflict probes, as        3.1.3 Segment Three Requirements
INFRASTRUCTURE   Processing          well as timely and accurate interchanges with Traffic
IMPROVEMENT                          Flow Management and various Weather Systems,
MISSION NEED                         could be provided through direct interfaces or
                                     through System Wide Information Management
                                     (SWIM) system.
3.0              3.1.3 Ground Data   This new functionality will provide by 2017 to allow       3.1.2 Segment Two Requirements
INFRASTRUCTURE   Processing          for the transfer to expanded airport information to        3.1.3 Segment Three Requirements
IMPROVEMENT                          include the transfer of static airport maps to the
MISSION NEED                         cockpit. Additional functionality will later be added
                                     which provides for an enhanced map support zero
                                     visibility ground operations.




                                                                         98
MSS Section      MSS Sub-              Shortfall Statement                                       PPR Section or Sub-Section
                 Section
3.0              3.1.3.1 Identifying   Providing controllers, flight crews and various           3.1.1.2 Unique Identification Requirements
INFRASTRUCTURE   Data                  automation systems a single point to identify data
IMPROVEMENT      Communications        communications capable aircraft and ground systems
MISSION NEED     Capable Aircraft      is essential for the safe and efficient operation of a
                 and Ground Systems    data communications system.
3.0              3.1.3.2 Controller    This application will provide the capability to           3.1.1.1 Messaging Requirements
INFRASTRUCTURE   Flight Crew           establish, manage, and terminate controller-flight        3.1.1.2 Unique Identification Requirements
IMPROVEMENT      Communications        crew communications between ATS ground and                3.1.1.3 Data Communications Requirements
MISSION NEED                           aircraft system peers. Once a connection is               3.1.1.4 Instructions, Advisories, and Report Request
                                       established it will provide the capability to exchange    Responses Requirements
                                       clearances, data requests, informational message          3.1.1.5 Automatic Terminal Information Service
                                       exchanges which includes the automation of                Requirements
                                       processes which today’s systems require manual            3.1.1.8 Departure and Taxi Clearance Requirements
                                       controller intervention.                                  3.1.1.9 En Route Clearance Requirements

3.0              3.1.3.2 Controller    Specifically, this function enables the transmission of   3.1.2 Segment Two Requirements
INFRASTRUCTURE   Flight Crew           aircraft state and parametric information to the          3.1.3 Segment Three Requirements
IMPROVEMENT      Communications        ground system (on an automated basis) to enable the
MISSION NEED                           ground to perform enhanced trajectory management
                                       and more accurate conflict detection .


3.0              3.1.4 Ground          The existing functionality may require additional         3.2.2.2 Number of Aircraft Supported
INFRASTRUCTURE   Message Delivery      capacity as the use of data communications grows in       3.2.3.2 Number of Aircraft Supported
IMPROVEMENT                            the NAS.
MISSION NEED
3.0              3.1.5 Air-Ground      This air/ground network includes the ground and air       3.1.1.3 Data Communications Requirements
INFRASTRUCTURE   Message Delivery      radio systems as well as the routing and
IMPROVEMENT                            communications management functions which
MISSION NEED                           directly support the establishment and management of
                                       the radio link.




                                                                          99
Appendix B Acronyms

4-D             Four Dimensional (latitude, longitude, altitude, and time)
A/G             Air/Ground
ACL             ATC Clearance Service
ACM             ATC Communications Management Service
AMC             ATC Microphone Check Service
AMS             Acquisition Management System
AOS             Operational Support
ARMAND          Arrival Manager Information Delivery Service
ARTCC           Air Route Traffic Control Center
ASAS            Airborne Separation Assistance Service
ASTM            American Society for Testing and Materials
ATC             Air Traffic Control
ATIS            Automatic Terminal Information Service
ATM             Air Traffic Management
ATN             Aeronautical Telecommunications Network
ATO             Air Traffic Organization
ATS             Air Traffic Services
ATSP            ATS Provider
C&P             Crossing and Passing
CDA             Current Data Authority
CFR             Code of Federal Regulations
CNS/ATM         Communications, Navigation, Surveillance and Air Traffic Management
COCR            Communications Operating Concept and Requirements
COI             Critical Operational Issue
CONUS           Continental United States
COTRAC          Common Trajectory Coordination Service
COTS            Commercial Off-the-Shelf
CP              Conflict Probe
CPDLC           Controller-Pilot Data Link Communications
D-ATIS          Data Link Automatic Terminal Information Service
D-FLUP          Data Link Flight Update
D-TAXI          Data Link Taxi
DCL             Departure Clearance Service
DLL             Data Link Logon Service
DOT             Department of Transportation
DR&A            Data Reduction and Analysis
DSC             Down Stream Clearance Service
EIA             Electronic Industries Alliance
EPA             Environmental Protection Agency
ERAM            En Route Automation Modernization
ESD             Electrostatic Discharge
ETD             Estimated Time of Departure
FAA             Federal Aviation Administration
FAALC           FAA Logistics Center
FANS            Future Air Navigation System


                                       100
FCSP       Federal Catalog and Standardization Programs
FDP        Flight Data Processor
FIPS       Federal Information Processing Standards
FL         Flight Level
FLIPINT    Flight Path Intent Service
FOC        Full Operational Capability
FRDF       Facility Reference Data File
FSEP       Facilities, Services, and Equipment Profiles
FY         Fiscal Year
GSIP       Generic Site Implementation Plan
HFDG       Human Factors Design Guide
HFDS       Human Factors Design Standard
HMI        Human Machine Interface
HP         High Performance
HP-SIDs    HP Standard Instrument Departures
HP-STARs   HP Standard Terminal Arrival Routes
HPA        High Performance Airspace
HVAC       Heating, Ventilation, and Air Conditioning
ICAO       International Civil Aviation Organization
ICD        Interface Control Document
ILS        Integrated Logistics Support
IOC        Initial Operational Capability
IRD        Interface Requirements Document
ISO        International Organization for Standardization
ISP        Integrated Safety Plan
ITP        In-Trail Procedure
JPDO       Joint Planning and Development Office
LRU        Lowest Replaceable Unit
M&S        Merging and Spacing
MMAC       Mike Monroney Aeronautical Center
MSS        Mission Shortfall Statement
MTBF       Mean Time Between Failure
NAS        National Airspace System
NCP        NAS Change Proposal
NextGen    Next Generation Air Transportation System
NFPA       National Fire Protection Association
NIST       National Institute of Standards and Technology
NM         Nautical Mile
OSHA       Occupational Safety and Health Administration
PAIRAPP    Paired Approaches
PPD        Pilot Preferences Downlink
QAP        Quality Assurance Program
RF         Radio Frequency
RNAV       Area Navigation
RoHS       Reduction of Hazardous Substances
RTAs       Required Times of Arrival
SARPs      Standards And Recommended Practices
SIDs       Standard Instrument Departures


                                   101
SMS      Safety Management System
SRMGSA   Safety Risk Management Guidance for System Acquisitions
STAR     Standard Terminal Arrival Route
STARS    Standard Terminal Automation Replacement System
T&E      Test and Evaluation
TBD      To Be Determined
TDLS     Tower Data Link Services
TFM      Traffic Flow Management
TIB      Technical Instruction Book
TRACON   Terminal Radar Approach Control
UFAS     Uniform Federal Accessibility Standard
VDL2     VHF Data Link Mode 2
VHF      Very High Frequency
WJHTC    William J. Hughes Technical Center




                                102
Appendix C Definitions
Aircraft Identification: A group of letters, figures or a combination thereof which is identical to
or the code equivalent of the aircraft call sign. It is used in Field 7 of the ICAO model flight
plan.

Aircraft Address: A unique combination of 24 bits available for assignment to an aircraft for the
purpose of air-ground communications, navigation, and surveillance.

Authority: The ground facility that the aircraft recognizes as the one from which it will accept
data communications messages.

Availability (non-security): Availability is the probability that data communications with all
appropriately equipped aircraft in the area is in service.

Availability (security): Ensuring timely and reliable access to and use of information.

Certification: The technical verification performed prior to commissioning and/or service
restoration of the ground system after a scheduled/unscheduled interruption affecting certification
parameters, and periodically thereafter inclusive of the insertion of the prescribed entry in the
facility maintenance log. The certification validates that the ground system is providing an
advertised service to the user, and/or that the system/equipment is capable of providing that
advertised service. It includes independent determination about when a system/equipment
should be continued in, restored to, or removed from service.

Certification Parameter: Ground system certification parameters are selected critical indicators
of the quality of the required or advertised services being provided to the user of systems,
subsystems, and equipment.

Confidentiality: Preserving authorized restrictions on access and disclosure, including means for
protecting personal privacy and proprietary information.

Conformance Management: Conformance management is the process by which the aircraft and
the ground system exchange detailed data to ensure that the aircraft’s flight path and the ground
system stored flight plan match within defined parameters.

Continuity: Continuity is the probability that the transaction will be completed before the
transaction expiration time, assuming that data communications is available when the transaction
is initiated.

Control Position: A control position encompasses all sector air traffic controllers working at a
sector.

Current Data Authority: The ground authority permitted to conduct a data communications
session with an aircraft.

Data Communications: All services, hardware, and software procured by the data
communications program that supports the data communications end-to-end service.


                                               103
Data Communications End-to-End Service: The capability for controllers and pilots or
maintainers and test devices to exchange ATC messages in a digital data format.

Data Communications End-to-End System: The end-to-end infrastructure (including services,
hardware, and software) that enables the capability for controllers and pilots to exchange Air
Traffic Control (ATC) messages in digital format. This includes aircraft avionics, ground
system, and any service provider. The term digital format does not preclude the possible use of
voice recognition and synthesis technology.

Data Communications Ground System: All ground based services, hardware, and software that
support the data communications end-to-end service.

Data Communications Ground Based Unique Equipment: Any piece of FAA ground
equipment whose sole purpose is to support data communications service.

Display System: FAA ground equipment that displays flight and surveillance data to the sector
team.

Eligible Aircraft: Those aircraft for which a control position(s) is responsible for providing
ATC services.

End-to-End: Pertaining to or relating to an entire communication path, typically from (1) the
interface between the information source and the communication system at the transmitting end
to (2) the interface between the communication system and the information user or processor or
application at the receiving end.

End-to-End Data: Data that is passed between the processor at the controller’s position (or other
information source) and the airborne processor.

End-to-End Transfer Delay: The period elapsed from the time at which the originating user (or
other information source) initiates the triggering event until the time the transmitted information
is available for display to the intended recipient.

End User: An ultimate source and/or consumer of information.

Enhanceability: The capability of a system to interface with additional unspecified systems,
process data from those systems, and accommodate improvements to hardware and software
elements, with the original architecture (no system or architecture modifications required).

Estimated Off Block Time: The ICAO terminology for “Estimated Time of Departure” (ETD).

FAA-Owned or Operated Equipment: Any device or system component that the FAA holds
title to, is directly responsible for the continued operation of, and/or which the FAA intends to
take ownership of upon termination of a lease.




                                                104
FAA Telecommunications Infrastructure: FAA ground equipment that is used to interconnect
the data communications system with ATN communications service providers. It is also used for
interfacility communications.

Failure: The event or inoperable state in which any function, within a subsystem that is being
used as an integral part of the NAS primary function, does not or would not perform as specified.

Ground-based unique equipment installed in FAA-owned or provided facilities: Any device or
system component that is required to provide, monitor or control any element of the data
communications service, and is physically located in a building, shelter or location that is
government owned or provided on behalf of the government.

Integrity (non-security): Integrity is the acceptable rate of transactions completed with
undetected error.

               Note: Integrity relates to the trust which can be placed in the correctness of the
               information provided.

Integrity (security): Guarding against improper information modification or destruction, and
includes ensuring information non-repudiation and authenticity.

Key Parameter: Requirements that must be met to provide a minimally acceptable level of
service. When key parameters are not met the program will be subject to termination by the Joint
Resources Council.

Lowest Replaceable Unit: The lowest replaceable component at the site.

M&C: The FAA ground equipment that displays system monitor and control information to the
airway facilities team.

Mean Time Between Failures: A basic measure of reliability for items: The mean number of
life units during which all parts of the item perform within their specified limits, during a
particular measurement interval under stated conditions.

Mean Time to Repair: Mean Time to Repair includes diagnostic time, removal of the failed
LRU, replacement and installation of the new LRU including any adjustments or data loading
necessary to initialize the LRU, and all adjustments required to return the subsystem to normal
operation and to perform certification.

Mean Time to Restore Service: The mean time required to restore functionality, performance,
and the operational state existing prior to any failure.

Next Data Authority: The ground system that provides for the establishment and maintenance of
a transport connection for the purposes of rapid switching to the Current Data Authority (CDA)
state and conducting a data communications dialogue pertaining to the services of the receiving
Air Traffic Services unit when the aircraft designates it as the CDA.

Normal Termination: The intentional discontinuation of service.


                                               105
Outstanding Messages: Messages that have not received a qualified response from the intended
recipient.

Qualification: Evaluation of the implementation and performance to its requirements document.

Reliability: A characteristic of a system element or service expressed as the Mean Time Between
Failure (MTBF). MTBF is computed as the mean time from an initial instant when the element
or service is available until the next failure event.

Security Controls: The management, operational, and technical controls (safeguards or
countermeasures) prescribed for an information system, which taken together, adequately protect
the confidentiality, integrity, and availability of the system, its data, and information.

Service Transaction: A transaction begins when a controller, pilot, or automation sends a
message that requires an operational response. The transaction ends when the initiator receives
the operational response for the initial message. In most cases, this is two messages. Note that
this does not include non-operational messages such as transport layer acknowledgements and
logical acknowledgements. A Standby response does not close the transaction.

Terminal: The terminal, terminal area, or terminal airspace is a generic term that includes tower
airspace and TRACON airspace.

Threshold: Minimum or maximum acceptable operational value for system capability or
characteristic that, in the user’s judgment, is necessary to provide an operational capability that
will satisfy the mission need.

Tools: An application that supports the operation of the NAS. A tool generally has an interface
to the user for input, output, or both, but may perform some functions directly between systems
without user interaction. Data communications tools allow the controller and flight crew to
initiate the transfer of data between the air and the ground and to monitor responses for the
opposing system.

Trajectory Agreement: A trajectory agreement consists of a 4-D route and the conformance
parameters for that route.




                                                106
Appendix D References

              Note: The latest version of all referenced material will be used. Where there is
              conflict between the documents, FAA Orders will take precedence.

36 CFR 1194, Electronics and Information Technology Accessibility Standard

Acquisition Management System (AMS) Test & Evaluation Process Guidelines

Aeronautical Information Manual

ANSI/IEEE 1100-1992, Grounding Shielding and Bonding

ASD-100-SSE-1, NAS Modernization System Safety Management Program

ASTM-D3951, Standard Practice for Commercial Packaging

ATO-S 2006-1, Safety Risk Management Guidance for System Acquisitions (SRMGSA)

Code of Federal Regulations, Title 40, Environmental Protection

Communications Operating Concept and Requirements for the Future Radio System, COCR
Version 2.0, dated May 4, 2007

Directive 2002/95/EC, Reduction of Hazardous Substances

DOT/FAA/CT-96/1 Human Factors Design Guide (HFDG) for Acquisition of Commercial-Off-
the-Shelf Subsystems, Non-Developmental Items, and Developmental Systems

EIA-649-A, National Consensus Standard for Configuration Management

Executive Order 12196, Occupational Safety and Health Program for Federal Employees

Executive Order 13123, Greening the Government Through Efficient Energy Management, dated
June 3, 1999

FAA Bar Coding Specification

FAA-C-1217, Electrical Work, Interior

FAA-G-2100G, Electronic Equipment, General Requirements

FAA HDBK-006, Reliability, Availability, and Maintainability (RMA) Handbook

FAA Human Factors Job Aid




                                              107
FAA Order 1100.157, National Systems Engineering Divisions Maintenance Program
Procedures, Operational Support (AOS)

FAA Order 1370.82A, FAA Information Systems Security Program

FAA Order 1375.4, Standard Data Elements

FAA Order 1380.40, Airway Facilities Sector Level Staffing Standard System

FAA Order 1600.1, Personnel Security Program

FAA Order 1600.6, Physical Security Management Program

FAA Order 1600.69, FAA Facility Security Management Program

FAA Order 1600.72, Contractor and Industrial Security Program

FAA Order 1800.8F, National Airspace Configuration Management

FAA Order 3900.19B, Occupational Safety and Health Program

FAA Order 4140.1, Integrated Material Management Program

FAA Order 4500.3, Federal Catalog and Standardization Programs (FCSP)

FAA Order 4630.1, Management of Depot Inventories of Operating Material

FAA Order 4630.2, Standard Allowance of Supplies and Working Equipment for National
Airspace System Facilities

FAA Order 4630.3, Survey of Lost, Damaged, or Destroyed Personal Government Personal
Property

FAA Order 4630.30, Management and Control of NAS F&E Project Material

FAA Order 4633.1, Physical Inventory

FAA Order 4650.31, Vendor Shipments of Nationally Furnished Operations-Funded Material

FAA Order 4650.7, Management of NAS F&E Project Material

FAA Order 4770.3, Transportation and Traffic Management of Government Property

FAA Order 4800.2, Utilization and Disposal of Excess and Surplus Personal Property

FAA Order 6000.15, General Maintenance Handbook for Airway Facilities

FAA Order 6000.30, National Airspace System Maintenance Policy


                                            108
FAA Order 6000.38, Policy to Determine NAS Equipment Sparing Requirements for Airways
Facilities Work Centers

FAA Order 6000.41, Policy Governing Contractor-Assisted Maintenance For The National
Airspace System

FAA Order 6030.45, Facility Reference Data

FAA Order 6630.4, En Route Communications Installation Standards Handbook

FAA Order 6950.2, Electrical Power Policy Implementation, NAS Facilities

FAA Order 6950.19, Practices and Procedures for Lightning Protection Grounding, Bonding,
and Shielding Implementation

FAA Order 6950.20, Fundamental Considerations of Lightning Protection Grounding, Bonding,
and Shielding

FAA Order 6950.22, Maintenance of Electrical Power and Control Cables

FAA Order 8040.4, Safety Risk Management

FAA Order 9550.8, Human Factors Policy

FAA Safety Management System (SMS) Manual

FAA-STD-019E, Lightning and Surge Protection, Grounding, Bonding and Shielding
Requirements for Facilities and Equipment

FAA-STD-025E, Preparation of Interface Documentation

FAA-STD-028C, Contract Training Programs

FAA-STD-60, Data Standard for National Aerospace System

FAA System Safety Handbook, December 30, 2000

FED-STD-795, Uniform Federal Accessibility Standard (UFAS)

Federal Aviation Regulations

FIPS PUB 140-2, Security Requirements for Cryptographic Modules

HF-STD-001, FAA Human Factors Design Standard

ICAO 9880-AN/466, Manual On Detailed Technical Specifications For The Aeronautical
Telecommunication Network (ATN) using ISO/OSI standards and protocols


                                             109
ICAO Doc 4444, Procedures for Air Navigation Services – Air Traffic Management (PANS-
ATM)

ICAO SARPs, Aeronautical Telecommunication Network (ATN), Volume II, Part II,
Communications Procedures, Chapter 5, Aeronautical Mobile Service, Second Edition

ICAO Standards and Recommended Practices (SARPs), Aeronautical Telecommunications,
Annex 10 to the Convention on International Civil Aviation, Volume III, Part I, Digital
Communication Systems, Chapter 3, Aeronautical Telecommunication Network (ATN)

ISO 9001:2000 Quality Management Systems Requirement, International Organization for
Standardization

MIL-HDBK-46855A, Human Engineering Program Process and Procedures

MIL-STD-2073-1, DOD Material Procedures for Development and Application of Packaging
Requirements

NAS-SR-1000, National Airspace System, System Requirements Specification

National Fire Protection Association Standard 70, National Electric Code

RTCA DO-238, Human Engineering Guidance for Data Link Systems

RTCA DO-256, Minimum Human Factors Standards for Air Traffic Services Provided via Data
Communications Utilizing the ATN, Builds I and IA

RTCA DO-264, Guidelines for Approval of ATS Supported by Data Communications

RTCA DO-278, Guidelines for Communication, Navigation, Surveillance and Air Traffic
Management (CNS/ATM) Systems Software Integrity Assurance

RTCA DO-280B, Interoperability Requirements Standard For ATN Baseline 1 (INTEROP ATN
B1)

RTCA DO-290, Safety and Performance Requirements Standard for Air Traffic Data Link
Services in Continental Airspace (Continental SPR Standard), Change 2

RTCA DO-305, Future Air Navigation System 1/A (FANS 1/A) – Aeronautical
Telecommunications Network (ATN) Interoperability Standard

RTCA DO-yyy, Safety and Performance Requirements Standard for Advanced Air Traffic Data
Communications Services, (draft)

Title 29 CFR 1960, Basic Program Elements For Federal Employee Safety And Health
Programs And Related Matters



                                             110
Appendix E COCR Mapping to Data Communications Services
The following table is a mapping of the COCR identified services to the data communications
program services.

 Data Communications           COCR Capability              Data Communications Service
 Functional Service                                         Availability
                                                            Segment Segment Segment
                                                              One        Two     Three
 ATC Clearances                ATC Clearance Service           X          X        X
                               (ACL)
 Free Text (e.g., ATC          ATC Microphone Check            X          X           X
 Microphone Check)             Service (AMC)
 Initial 4-D Trajectories in   Common Trajectory               X          X           X
 mixed airspace.               Coordination Service
                               (COTRAC)
 Unique Identification         Data Link Logon Service         X          X           X
                               (DLL)
 D-ATIS                        Data Link Automatic             X          X           X
                               Terminal Information
                               Service (D-ATIS)
 Departure Clearances          Departure Clearance             X          X           X
                               Service (DCL)
 Automatic Hand-Off            ATC Communication               X          X           X
 Generation (providing         Management Service
 frequency for voice and       (ACM)
 connection mgmt for data)
 Departure Taxi Clearances     Data Link Taxi Service (D-      X          X           X
                               TAXI)
 Uplink Controlled Time of     Arrival Manager                 X          X           X
 Arrival to aircraft.          Information Delivery
                               Service (ARMAND)
 Aircrew Preferences           Pilot Preferences Downlink                 X           X
 (Aircraft capabilities)       (PPD)
 Arrival Taxi Instructions     D-TAXI                                     X           X
 4-D Trajectory Agreements     COTRAC                                     X           X
 in Performance-Based
 Airspace (e.g., 60 minutes
 conflict free)
 Down Stream Clearance         Down Stream Clearance                      X           X
 service (G-G                  Service (DSC)
 implementation)
 Conformance Management        Flight Path Intent Service                 X           X
 (using ADS-C)                 (FLIPINT)
 Info on Delays/Constraints    Data Link Flight Update                    X           X
 (D-FLUP)                      Service (D-FLUP)
 M&S, C&P, ITP services        Airborne Separation                                    X


                                               111
 dependent on ACL               Assistance System (ASAS)
 messages                       Merging & Spacing
                                (M&S), Crossing &
                                Passing (C&P), In-Trail
                                Procedures (ITP)
 Widespread use of 4-D          COTRAC                                                      X
 Trajectory Agreements
 down to Paired Approach
 (e.g., 2 hr. conflict free)
 Paired Approaches              Paired Approaches                                           X
                                (PAIRAPP)

In the table above an X in a box indicates that service is planned to be available in that data
communications program segment.




                                                112
Appendix F Terminal Site Lists

The following table is the list of data communications TDLS sites for Segment One.

                                   Table 14-1 Segment One TDLS Sites

ID                                   Facility                                   CITY        STATE
ABQ     Albuquerque International Sunport Airport                      Albuquerque           NM
ADW     Andrews Air Force Base                                         Camp Springs          MD
ALB     Albany International Airport                                   Albany                NY
ANC     Ted Stevens Anchorage International Airport                    Anchorage             AK
ATL     Hartsfield-Jackson Atlanta International Airport               Atlanta               GA
AUS     Austin-Bergstrom International Airport                         Austin                 TX
BDL     Bradley International Airport                                  Windsor                CT
BNA     Nashville International Airport                                Nashville              TN
BOI     Boise Air Terminal/Gowen Field Airport                         Boise                  ID
BOS     General Edward Lawrence Logan International Airport            Boston                MA
BUF     Buffalo Niagara International Airport                          Buffalo               NY
BUR     Bob Hope Airport                                               Burbank               CA
BWI     Baltimore/Washington International Thurgood Marshall Airport   Baltimore             MD
CLE     Cleveland-Hopkins International Airport                        Cleveland             OH
CLT     Charlotte/Douglas International Airport                        Charlotte             NC
CMH     Fort Columbus International Airport                            Columbus              OH
CVG     Cincinnati/Northern Kentucky International Airport             Covington              KY
DAL     Dallas Love Field Airport                                      Dallas                 TX
DCA     Ronald Reagan Washington National Airport                      Washington            DC
DEN     Denver International Airport                                   Denver                CO
DFW     Dallas/Fort Worth International Airport                        Dallas-Forth Worth     TX
DTW     Detroit Metropolitan Wayne County Airport                      Detroit                MI
ELP     El Paso International Airport                                  El Paso                TX
EWR     Newark Liberty International Airport                           Newark                 NJ
FLL     Fort Lauderdale/Hollywood International Airport                Fort Lauderdale        FL
GSO     Piedmont Triad International Airport                           Greensboro            NC
HNL     Honolulu International Airport                                 Honolulu               HI
HOU     William P. Hobby Airport                                       Houston                TX
HPN     Westchester County Airport                                     White Plains           NJ
IAD     Washington Dulles International Airport                        Washington            DC
IAH     George Bush Intercontinental/Houston Airport                   Houston                TX
IND     Indianapolis International Airport                             Indianapolis           IN
JAX     Jacksonville International Airport                             Jacksonville           FL
JFK     John F. Kennedy International Airport                          New York              NY
LAS     McCarran International Airport                                 Las Vegas             NV
LAX     Los Angeles International Airport                              Los Angeles           CA
LGA     La Guardia Airport                                             New York              NY
LIT     Adams Field Airport                                            Little Rock           AR
MCI     Kansas City International Airport                              Kansas City           MO
MCO     Orlando International Airport                                  Orlando                FL
MDW     Chicago Midway International Airport                           Chicago                IL
MEM     Memphis International Airport                                  Memphis                TN



                                                    113
ID                                 Facility                                  CITY    STATE
MIA   Miami International Airport                                  Miami               FL
MKE   General Mitchell International Airport                       Milwaukee           WI
MSP   Minneapolis-St Paul International/Wold-Chamberlain Airport   Minneapolis        MN
MSY   Louis Armstrong New Orleans International Airport            New Orleans         LA
OAK   Metropolitan Oakland International Airport                   Oakland            CA
OKC   Will Rogers World Airport                                    Oklahoma City      OK
OMA   Eppley Airfield Airport                                      Omaha              NE
ONT   Ontario Municipal Airport                                    Ontario            CA
ORD   Chicago O'Hare International Airport                         Chicago             IL
PBI   Palm Beach International Airport                             West Palm Beach     FL
PDX   Portland International Airport                               Portland           OR
PHL   Philadelphia International Airport                           Philadelphia       PA
PHX   Phoenix Sky Harbors International Airport                    Phoenix             AZ
PIT   Pittsburgh International Airport                             Pittsburgh         PA
PVD   Theodore Francis Green State Airport                         Providence          RI
RDU   Raleigh/Durham International Airport                         Raleigh/Durham     NC
RNO   Reno/Tahoe International Airport                             Reno               NV
SAN   San Diego International Airport                              San Diego          CA
SAT   San Antonio International Airport                            San Antonio         TX
SDF   Louisville International-Standiford Field Airport            Louisville          KY
SEA   Seattle/Tacoma International Airport                         Seattle            WA
SFO   San Francisco International Airport                          San Francisco      CA
SJC   Norman Y. Mineta San Jose International Airport              San Jose           CA
SJU   Louis Munoz Marin International Airport                      San Juan           PR
SLC   Salt Lake City International Airport                         Salt Lake City      UT
SMF   Sacramento International Airport                             Sacramento         CA
SNA   John Wayne Airport-Orange County Airport                     Santa Anna         CA
STL   Lambert-St. Louis International Airport                      St. Louis          MO
TEB   Teterboro Airport                                            Teterboro           NJ
TPA   Tampa International Airport                                  Tampa               FL
TUL   Tulsa International Airport                                  Tulsa              OK




                                                  114
The following table is the list of data communications airport tower sites for Segment Two that
are in addition to the Segment One data communications sites.

                                Table 14-2 Segment Two Tower Sites

  ID                         Facility                                    CITY         STATE
ABE    LEHIGH VALLEY INTERNATIONAL ARPT                        Allentown                 PA
ACY    ATLANTIC CITY INTERNATIONAL ARPT                        Atlantic City             NJ
AHN    ATHENS/BEN EPPS ARPT                                    Athens                    GA
ANE    ANOKA COUNTY-BLAINE ARPT(JANES FIELD) ARPT              Minneapolis               MN
APA    CENTENNIAL ARPT                                         Denver                    CO
APC    NAPA COUNTY ARPT                                        Napa                      CA
ARR    AURORA MUNI ARPT                                        Chicago/Aurora             IL
AXH    HOUSTON SOUTHWEST ARPT                                  Houston                   TX
BDR    IGOR SIKORSKY MEM ARPT                                  Bridgeport                CT
BFI    BOEING FIELD AIRPORT                                    Seattle                   WA
BHM    BIRMINGHAM INTL ARPT                                    Birmingham                AL
BIL    BILLINGS LOGAN INTERNATION ARPT                         Billings                  MT
CAE    COLUMBIA METROPOLITAN ARPT                              Columbia                  SC
CCR    BUCHANAN FIELD ARPT                                     Concord                   CA
CDW    ESSEX COUNTY ARPT                                       Caldwell                  NJ
CNO    CHINO ARPT                                              Chino                     CA
CPR    NOTRONA COUNTY INTERNATIONAL ARPT                       Casper                    NY
CRP    CORPUS CHRISTI INTERNATIONAL ARPT                       Corpus Christi            TX
CRQ    MC CLELLAN-PALOMAR ARPT                                 Carlsbad                  CA
CSG    COLUMBUS METROPOLITAN ARPT                              Columbus                  GA
DAY    JAMES M COX DAYTON INTL ARPT                            Vandalia                  OH
DPA    DUPAGE ARPT                                             Chicago/West Chicago       IL
DSM    DES MOINES INTERNATIONAL ARPT                           Des Moines                 IA
DVT    PHOENIX DEER VALLEY ARPT                                Phoenix                   AZ
DWH    DAVID WAYNE HOOKS MEMORIAL ARPT                         Houston                   TX
EMT    EL MONTE ARPT                                           El Monte                  CA
ENW    KENOSHA REGIONAL ARPT                                   Kenosha                   WI
EVV    EVANSVILLE REGIONAL ARPT                                Evansville                 IN
FAI    FAIRBANKS INTERNATIONAL ARPT                            Fairbanks                 AK
FCM    FLYING CLOUD ARPT                                       Minneapolis               MN
FDK    FREDERICK MUNICIPAL ARPT                                Frederick                 MD
FFZ    FALCON FLD ARPT                                         Mesa                      AZ
FRG    REPUBLIC ARPT                                           Farmingdale               NY
FTY    FULTON COUNTY AIRPORT-BROWN FIELD ARPT                  Atlanta                   GA
FWA    FORT WAYNE INTERNATIONAL ARPT                           Fort Wayne                 IN
FXE    FORT LAUDERDALE EXECUTIVE ARPT                          Fort Lauderdale           FL
GEG    SPOKANE INTERNATIONAL ARPT                              Spokane                   WA
GLS    SCHOLES INTERNATIONAL ARPT AT GALVESTON                 Galveston                 TX
GYR    PHOENIX GOODYEAR ARPT                                   Goodyear                  AZ
HEF    MANASSAS REGIONAL/HARRY P. DAVIS FIELD ARPT             Manassas                  VA
HHR    JACK NORTHROP FIELD/HAWTHORNE MUNICIPAL ARPT            Hawthorne                 CA
HPN    WESTCHESTER COUNTY ARPT                                 White Plains              NY
HVN    TWEED-NEW HAVEN ARPT                                    New Haven                 CT
HWD    HAYWARD EXECUTIVE ARPT                                  Hayward                   CA
ICT    WICHITA MID-CONTINENT ARPT                              Wichita                   KS



                                               115
  ID                         Facility                        CITY      STATE
ILG    NEW CASTLE COUNTY ARPT                     Wilmington              DE
ISP    LONG ISLAND MAC ARTHUR ARPT                Islip                   NY
JVL    SOUTHERN WISCONSIN REGIONAL ARPT           Janesville              WI
LGB    LONG BEACH /DAUGHERTY FIELD/ ARPT          Long Beach              CA
LMT    KLAMATH FALLS ARPT                         Klamath Falls           OR
LVK    LIVERMORE MUNI ARPT                        Livermore               CA
LWS    LEWISTON-NEZ PERCE COUNTY ARPT             Lewiston                 ID
MAF    MIDLAND INTERNATIONAL ARPT                 Midland                 TX
MCN    MIDDLE GEORGIA REGIONAL ARPT               Macon                   GA
MGM    MONTOGOMERY REGIONAL ARPT                  Montgomery              AL
MHT    MANCHESTER ARPT                            Manchester              NH
MIC    CRYSTAL ARPT                               Minneapolis             MN
MLB    MELBOURNE INTL ARPT                        Melbourne               FL
MMU    MORRISTOWN MUNI ARPT                       Morristown              NJ
MOD    MODESTO CITY-CO-HARRY SHAM FLD ARPT        Modesto                 CA
MRY    MONTEREY PENINSULA ARPT                    Monterey                CA
MYF    MONTGOMERY FIELD ARPT                      San Diego               CA
OGG    KAHULUI ARPT                               Kahului                  HI
OMN    ORMOND BEACH MUNICIPAL                     Ormond Beach            FL
ORL    EXECUTIVE ARPT                             Orlando                 FL
PAE    SNOHOMISH COUNTY (PAINE FLD) ARPT          Everett                 WA
PAO    PALO ALTO ARPT OF SANTA CLARA CO ARPT      Palo Alto               CA
PDK    DEKALB-PEACHTREE ARPT                      Atlanta                 GA
PNE    NORTHEAST PHILADELPHIA ARPT                Philadelphia            PA
POC    BRACKETT FIELD ARPT                        La Verne                CA
POU    DUTCHESS COUNTY ARPT                       Poughkeepsie            NY
PRC    ERNEST A. LOVE FIELD ARPT                  Prescott                AZ
                                                  Chicago/Prospect
PWK    CHICAGO EXECUTIVE ARPT                     Heights/Wheeling        IL
RAL    RIVERSIDE MUNI ARPT                        Riverside               CA
RDM    ROBERTS FIELD ARPT                         Redmond                 OR
RFD    CHICAGO/ROCKFORD INTL ARPT                 Chicago/Rockford        IL
RHV    REID-HILLVIEW OF SANTA CLARA COUNTY ARPT   San Jose                CA
RIC    RICHMOND INTERNATIONAL ARPT                Richmond                VA
RSW    SOUTHWEST FLORIDA INTL ARPT                Fort Myers              FL
SAC    SACRAMENTO EXECUTIVE ARPT                  Sacramento              CA
SCK    STOCKTON METROPOLITAN ARPT                 Stockton                CA
SDL    SCOTTSDALE ARPT                            Scottsdale              AZ
SEE    GILLESPIE FIELD ARPT                       San Diego/El Cajon      CA
SFB    ORLANDO SANFORD ARPT                       Orlando                 FL
SLE    MCNARY FLD ARPT                            Salem                   OR
SMO    SANTA MONICA MUNI ARPT                     Santa Monica            CA
SNS    SALINAS MUNI ARPT                          Salinas                 CA
STP    ST PAUL DOWNTOWN HOLMAN FLD ARPT           St Paul                 MN
STS    CHARLES M. SCHULZ SONOMA COUNTY ARPT       Santa Rosa              CA
TIX    SPACE COAST REGIONAL ARPT                  Titusville              FL
TLH    TALLAHASEE REGIONAL ARPT                   Tallahassee             FL
TMB    KENDALL-TAMIAMI EXECUTIVE ARPT             Miami                   FL
TOA    ZAMPERINI FIELD ARPT                       Torrance                CA
TUS    TUCSON INTL ARPT                           Tucson                  AZ
UGN    WAUKEGAN REGIONAL ARPT                     Chicago/Waukegan        IL


                                          116
 ID                          Facility                 CITY   STATE
VGT   NORTH LAS VEGAS ARPT                    Las Vegas         NV
VNY   VAN NUYS ARPT                           Van Nuys          CA




                                        117
The following table is the list of data communications TRACON sites for Segment Two.

                               Table 14-3 Segment Two TRACON Sites

  ID                           Facility                                 CITY       STATE
A80    Atlanta TRACON                                         Peachtree City        GA
A90    Boston TRACON                                          Boston                MA
ABQ    Albuquerque TRACON                                     Albuquerque           NM
ALB    Albany TRACON                                          Albany                NY
AUS    Austin TRACON                                          Austin                 TX
BNA    Nashville TRACON                                       Nashville              TN
BOI    Boise TRACON                                           Boise                  ID
BUF    Buffalo TRACON                                         Buffalo               NY
C90    Chicago TRACON                                         Elgin                  IL
CLE    Cleveland TRACON                                       Cleveland             OH
CLT    Charlotte TRACON                                       Charlotte             NC
CMH    Columbus TRACON                                        Columbus              OH
CVG    Cincinnati TRACON                                      Covington              KY
D01    Denver TRACON                                          Denver                CO
D10    Dallas-Fort Worth TRACON                               Dallas-Forth Worth     TX
D21    Detroit TRACON                                         Detroit                MI
ELP    El Paso TRACON                                         El Paso                TX
GSO    Greensboro TRACON                                      Greensboro            NC
I90    Houston TRACON                                         Houston                TX
IND    Indianapolis TRACON                                    Indianapolis           IN
JAX    Jacksonville TRACON                                    Jacksonville           FL
L30    Las Vegas TRACON                                       Las Vegas             NV
LIT    Little Rock TRACON                                     Little Rock           AR
M98    Minneapolis TRACON                                     Minneapolis           MN
MCI    Kansas City TRACON                                     Kansas City           MO
MCO    Orlando TRACON                                         Orlando                FL
MEM    Memphis TRACON                                         Memphis               TN
MIA    Miami TRACON                                           Miami                  FL
MKE    Milwaukee TRACON                                       Milwaukee              WI
MSY    New Orleans TRACON                                     New Orleans            LA
N90    New York TRACON                                        Ronkonkoma            NY
NCT    Northern California TRACON                             Sacramento            CA
OKC    Oklahoma City TRACON                                   Oklahoma City         OK
P50    Phoenix TRACON                                         Phoenix                AZ
P80    Portland TRACON                                        Portland              OR
PBI    Palm Beach TRACON                                      West Palm Beach        FL
PCT    Potomac TRACON                                         Warrenton             VA
PHL    Philadelphia TRACON                                    Philadelphia          PA
PIT    Pittsburgh TRACON                                      Pittsburgh            PA
PVD    Rhode Island TRACON                                    Providence             RI
RDU    Raleigh/Durham TRACON                                  Raleigh/Durham        NC
RNO    Reno/Tahoe TRACON                                      Reno                  NV
S46    Seattle/Tacoma TRACON                                  Seattle/Tacoma        WA
S56    Salt Lake City TRACON                                  Salt Lake City         UT
SAT    San Antonio TRACON                                     San Antonio            TX
SCT    Southern California TRACON                             San Diego             CA



                                              118
 ID                       Facility                      CITY   STATE
SDF   Louisville TRACON                    Louisville            KY
T75   St. Louis TRACON                     St. Louis            MO
TPA   Tampa TRACON                         Tampa                 FL
TUL   Tulsa TRACON                         Tulsa                OK




                                     119
                                      TDLS Site Listing
Project Name: Aeronautical Data Link - Tower Data Link Services
Project Number: 26800189
CIP Number: C200400
  #    LOC ID       QTY     REGION                CITY             ST
  1     TEB          1       AEA               Teterboro           NJ
  2     PHL          1       AEA              Philadelphia         PA
  3     BOS          1       ANE                 Boston            MA
  4     BDL          1       ANE        Windsor Locks (Bradley)    CT
  5     EWR          1       AEA                Newark             NJ
  6     BUF          1       AEA                 Buffalo           NY
  7     ELP          1       ASW                El Paso            TX
  8      PIT         1       AEA               Pittsburgh          PA
  9     ABQ          1       ASW              Albuquerque          NM
 10     MCI          1       ACE              Kansas City          MO
 11     MCO          1       ASO                Orlando            FL
 12     MIA          1       ASO                 Miami             FL
 13     JFK          1       AEA          New York (JFK Intl.)     NY
 14     MSY          1       ASW             New Orleans           LA
 15     LGA          1       AEA         New York (La Guardia)     NY
 16     TPA          1       ASO                 Tampa             FL
 17     SAT          1       ASW              San Antonio          TX
 18     AUS          1       ASW                 Austin            TX
 19     DEN          1       ANM                 Denver            CO
 20     DCA          1       AEA        Washington (Regan Natl.)   DC
 21      IAD         1       AEA          Washington (Dulles)      DC
 22     SJU          1       ASO               San Juan            PR
 23     FLL          1       ASO            Fort Lauderdale        FL
 24     SFO          1       AWP             San Francisco         CA
 25     SJC          1       AWP               San Jose            CA
 26     CLT          1       ASO                Charlotte          NC
 27     OAK          1       AWP                Oakland            CA
 28     GSO          1       ASO              Greensboro           NC
 29     BWI          1       AEA               Baltimore           MD
 30     SMF          1       AWP              Sacramento           CA
 31    DFW-w         1       ASW                 Dallas            TX
 32     BNA          1       ASO                Nashville          TN
 33    DFW-e         1       ASW                 Dallas            TX
 34     CLE          1       AGL               Cleveland           OH
 35     BUR          1       AWP                Burbank            CA
 36     RDU          1       ASO           Raleigh - Durham        NC
 37     TUL          1       ASW                  Tulsa            OK
 38     CMH          1       AGL               Columbus            OH




                                                                        1 of 2
                                      TDLS Site Listing
Project Name: Aeronautical Data Link - Tower Data Link Services
Project Number: 26800189
CIP Number: C200400
  #    LOC ID       QTY     REGION                  CITY          ST
 39     ONT          1       AWP                  Ontario         CA
 40     SDF          1       ASO                 Louisville       KY
 41     LAX          1       AWP               Los Angeles        CA
 42     CVG          1       ASO                Cincinnati        OH
 43     IAH          1       ASW                 Houston          TX
 44     SAN          1       AWP                San Diego         CA
 45     MEM          1       ASO                 Memphis          TN
 46     ORD          1       AGL                 Chicago          IL
 47     LAS          1       AWP                Las Vegas         NV
 48     ATL          1       ASO                  Atlanta         GA
 49     DTW          1       AGL                  Detroit         MI
 50     PHX          1       AWP                 Phoenix          AZ
 51     STL          1       ACE                 St. Louis        MO
 52     IND          1       AGL               Indianapolis       IN
 53     SNA          1       AWP               Santa Anna         CA
 54     MSP          1       AGL               Minneapolis        MN
 55     SEA          1       ANM                  Seattle         WA
 56    MDW           1       AGL            Chicago (Midway)      IL
 57     SLC          1       ANM              Salt Lake City      UT
 58     MKE          1       AGL                Milwaukee         WI
 59     PDX          1       ANM                 Portland         OR
 60     OKC                                   Oklahoma City
 61      LIT                                    Little Rock
 62     DAL                                 Love Field (Dallas)
 63     PVD                                     Providence




                                                                       2 of 2
   COCR Version 2.0




Communications Operating
Concept and Requirements
         for the
  Future Radio System




     EUROCONTROL/FAA
 Future Communications Study
   Operational Concepts and
      Requirements Team




                               EUROCONTROL
   COCR Version 2.0




Intentionally left blank




           2
                                 COCR Version 2.0




                       EXECUTIVE SUMMARY
EUROCONTROL and the Federal Aviation Administration (FAA) have initiated a
joint study under a Memorandum of Agreement through Action Plan 17 (AP 17) to
identify potential future communications technologies to meet safety and regularity of
flight communications requirements, i.e., those supporting Air Traffic Services (ATS)
and safety related Aeronautical Operational Control (AOC) communications.

This document identifies the future ATS concepts and then uses Air Traffic
Management (ATM) operational requirements and airline operating concepts
expected to be implemented in the highest density airspace regions to specify
requirements in the Communications Operating Concepts and Requirements (COCR)
document.

The COCR is used to determine candidate data communications technologies –
existing or future – that can meet these requirements. The COCR is independent of
any specific aircraft and ground radio communications technology. The physical
implementation of the radio components of a communication system are collectively
referred to as the Future Radio System (FRS).

The COCR considers two main phases of communications to support Air Traffic
Management. The first phase (Phase 1) is based on existing or emerging data
communications services and completes around 2020. Initial steps under this phase
are starting in some regions now. The second phase (Phase 2) represents a new
paradigm in the use of data communication. Data communications services are
introduced that replace or supplement those in Phase 1, and data communications is
the primary means of air-ground communication. Data communications supports
increased automation in the aircraft and on the ground.

In developing the COCR, the following approach was adopted: First, using the
overall context for future communications, a Phase 1 and a Phase 2 concept of
operations was developed based on existing concepts for the evolution of ATM.
Second, this concept of operations was used to identify ATS and AOC data
communications services. Third, an operating environment in which these services
would be provided was defined to ensure all implications of each service were
addressed. Fourth, the services were grouped into eight categories; and security,
safety, and performance assessments were performed for each of the eight categories.
These assessments were used to specify high-level end-to-end requirements for each
service/category. Next, an allocation of the high-level end-to-end requirements was
made to the FRS. Using a method of operation for each service, indicative
performance and capacity requirements were developed using a queuing model. This
enabled capacity requirements that the FRS needs to support to be calculated. The
COCR contains two example applications of the performance results.

There are a number of considerations to take into account when interpreting or
employing these results:
       The communications loading analysis and capacity results represent the
       product of a set of assumptions and, while intended to be representative,


                                          3
                                  COCR Version 2.0


       should not be interpreted as the only method of determining the required
       throughput. This analysis is sensitive to a number of assumptions, and slight
       changes to any of several assumptions could alter the results.
       The analysis results are largely driven by the FRS allocations derived from
       service-based performance requirements. Should subsequent safety analyses
       change the service level hazard-based requirements, the FRS allocations may
       require revision, and the loading results could change.
       Implications of the operational concepts and services could impact
       communications loading. For example, sector sizes may grow beyond the
       sizes estimated herein, as the operational focus shifts from tactical control to
       strategic planning. Sector size growth may necessitate more dynamic sector
       boundaries and/or longer range communications. Any of these factors could
       impact these capacity results.
It should be noted that some of the values in this version of the COCR are
considerably larger (up to 1600% in some cases) than those in version 1.0. This is
due to a number of factors which include the following:
       Revision of the use of some services in domains
       Some corrections to the queuing model
However, the overall capacity results are broadly the same because the large increases
in small values produce similar results.

This final version of the COCR has been developed primarily to estimate the
requirements for a future communication system and to enable selection of supporting
communications technologies. To achieve this, a requirements-driven approach was
taken to assess air-ground and air-air data and voice ATS and AOC communications
(i.e., safety and regularity of flight communications needed to support future ATM
concepts). It is the result of many days of work from a dedicated team to capture
future concepts and derive future communications requirements.

Several rounds of stakeholder consultations were conducted to ensure agreement on
the process that was followed in completing the COCR. Wide distribution of earlier
versions was provided via national and international forums. The technical
requirements for an FRS were determined from the operational requirements,
independent of any specific technology.          This approach ensures that the
communications requirements were based on needs, rather than being driven by
technology. This document will be used within the EUROCONTROL/FAA FCS
work to finalise the technology assessment, and it is offered to other activities as one
method of identifying future communication requirements.




                                           4
                                 COCR Version 2.0



                             CHANGE SHEET
This is Version 2.0 of the COCR. Version 1.0 was circulated widely in March 2006,
and the document has been reviewed by many Stakeholders. The input from those
reviews, together with refinement of information by the COCR drafting team, has
resulted in this new version. The main changes in this version compared with Version
1.0 include the following:
       Introduction of an Executive Summary
       Minor revision to the operational concepts taking into account the latest
       information from regional implementation planning
       Expansion in the definition of data link services – Section 2
       More comprehensive safety assessment; the itemized safety requirements for
       each service are contained in the Operational Services and Environment
       Definition reference document – Section 4
       Refinement of the performance requirements in light of the safety assessment
       – Section 5
       Modification to the queuing model used to produce the capacity requirements
       shown in Section 6
       Moving the example of real world use of the information to an appendix due
       to the availability of more comprehensive documents
       Correction of typographical errors




                                            5
                                                         COCR Version 2.0




                                         TABLE OF CONTENTS

EXECUTIVE SUMMARY .............................................................................................. 3

CHANGE SHEET............................................................................................................. 5

TABLE OF CONTENTS ................................................................................................. 6

LIST OF FIGURES .......................................................................................................... 8

LIST OF TABLES ............................................................................................................ 8

ACRONYMS AND ABBREVIATIONS....................................................................... 11

1     INTRODUCTION ................................................................................................... 15
      1.1     Background ................................................................................................................................ 15
      1.2     Scope ........................................................................................................................................... 16
      1.3     Context........................................................................................................................................ 17
      1.4     Approach .................................................................................................................................... 18
      1.5     Document Organisation............................................................................................................ 19
      1.6     Document References................................................................................................................ 19


2     OPERATIONAL SERVICES................................................................................. 20
      2.1     Introduction ............................................................................................................................... 20
      2.2     Air Traffic Services ................................................................................................................... 20
              2.2.1   ATS Voice Services ...................................................................................................... 21
              2.2.2   ATS Data Services ........................................................................................................ 22
      2.3     Aeronautical Operational Control (AOC) Services .............................................................. 38
              2.3.1   AOC Voice Services ..................................................................................................... 38
              2.3.2   AOC Data Services ....................................................................................................... 38


3 OPERATIONAL CONCEPT, ENVIRONMENT, AND SCENARIOS FOR
COMMUNICATIONS ................................................................................................... 43
      3.1     Introduction ............................................................................................................................... 43
      3.2     Phase 1 Concept......................................................................................................................... 43
              3.2.1   Phase 1 Environmental Characteristics and Conditions and Aircraft Performance
              Characteristics ............................................................................................................................. 45
      3.3     Phase 1 Scenario ........................................................................................................................ 47
              3.3.1   Pre-Departure Phase in the APT Domain..................................................................... 47
              3.3.2   Departure Taxi in the APT Domain.............................................................................. 49
              3.3.3   Departure in the TMA Domain..................................................................................... 49
              3.3.4   Operations in the ENR and ORP Domains................................................................... 50
              3.3.5   Arrival in the TMA Domain ......................................................................................... 52
              3.3.6   Arrival in the APT Domain .......................................................................................... 53
              3.3.7   Arrival Taxi in the APT Domain .................................................................................. 53
      3.4     Phase 2 Concept......................................................................................................................... 54


                                                                         6
                                                      COCR Version 2.0

            3.4.1   Phase 2 Environmental Characteristics and Conditions and Aircraft Performance
            Characteristics ............................................................................................................................. 58
    3.5     Phase 2 Scenario ........................................................................................................................ 59
            3.5.1   Pre-Departure Phase in the APT Domain..................................................................... 59
            3.5.2   Departure in the APT and TMA Domains ................................................................... 60
            3.5.3   Operations in the ENR, ORP and AOA Domains........................................................ 60
            3.5.4   Arrival in the TMA Domain ......................................................................................... 61
            3.5.5   Arrival Taxi in the APT Domain .................................................................................. 61


4   OPERATIONAL, SAFETY, AND SECURITY REQUIREMENTS.................. 62
    4.1     Operational Requirements ....................................................................................................... 62
            4.1.1  Service Level Operational Assessment ........................................................................ 62
    4.2     Operational Safety Requirements ........................................................................................... 64
            4.2.1  Safety Methodology...................................................................................................... 64
            4.2.2  Summary of the ATS Services Operational Safety Assessments ................................ 66
            4.2.3  Service Level Safety Assessment ................................................................................. 67
    4.3     Operational Information Security Requirements ................................................................. 70
            4.3.1  Business Goals for Information Security ..................................................................... 70
            4.3.2  Process to Determine Security Requirements .............................................................. 70
            4.3.3  Risk assessment............................................................................................................. 71
            4.3.4  Service Level Threat Severity Assessment .................................................................. 74
            4.3.5  Architectural Issues and Assumptions.......................................................................... 76
            4.3.6  Information Security Requirements.............................................................................. 78


5   PERFORMANCE REQUIREMENTS.................................................................. 81
    5.1     Voice Requirements .................................................................................................................. 81
    5.2     Data Requirements.................................................................................................................... 82
            5.2.1  RCTP Requirements ..................................................................................................... 82
            5.2.2  FRS Requirements ........................................................................................................ 87


6   COMMUNICATION LOADING ANALYSES .................................................... 94
    6.1     Introduction ............................................................................................................................... 94
    6.2     Loading Analyses Assumptions ............................................................................................... 95
            6.2.1  Operational and Environmental Assumptions.............................................................. 95
            6.2.2  Communication Implementation Assumptions .......................................................... 108
    6.3     Voice Loading Analysis........................................................................................................... 117
            6.3.1  Methodology ............................................................................................................... 117
            6.3.2  ATS Voice Transmission Characteristics................................................................... 118
            6.3.3  Service Volume Results.............................................................................................. 118
            6.3.4  Analysis of Results...................................................................................................... 119
    6.4     Addressed Data Loading Analysis......................................................................................... 120
            6.4.1  Methodology ............................................................................................................... 120
            6.4.2  Service Volume Results.............................................................................................. 121
            6.4.3  Single Aircraft Results ................................................................................................ 122
            6.4.4  Analysis of Results...................................................................................................... 124
    6.5     Broadcast Data Loading Analysis ......................................................................................... 126
            6.5.1  Methodology ............................................................................................................... 126
            6.5.2  Transmission Volume Results .................................................................................... 127
            6.5.3  Analysis of Results...................................................................................................... 130


7   CONCLUSIONS .................................................................................................... 131
    7.1     Overall ...................................................................................................................................... 131
    7.2     Global Applicability ................................................................................................................ 131
    7.3     Results....................................................................................................................................... 132


                                                                       7
                                                        COCR Version 2.0

      7.4      Observations ............................................................................................................................ 133
               7.4.1   Safety assessment methodology ................................................................................. 133
               7.4.2   Advanced ATS Services ............................................................................................. 133
               7.4.3   AOC Services.............................................................................................................. 133
      7.5      Areas for Further Consideration........................................................................................... 133


APPENDIX A STATFOR AND SAAM OVERVIEW ........................................... 136

APPENDIX B MID LEVEL MODEL DESCRIPTION ........................................ 139

APPENDIX C QUEUING MODEL DESCRIPTION ............................................ 144

APPENDIX D DEFINITIONS.................................................................................. 158

APPENDIX E FRS LATENCY ALLOCATION.................................................... 161

APPENDIX F REFERENCE LIST.......................................................................... 165

APPENDIX G RELATIONSHIP OF THE RESULTS TO A REAL WORLD
ENVIRONMENT.......................................................................................................... 168


                                               LIST OF FIGURES
Figure 1-1:       Phase 1 and Phase 2 Concept Evolution Over Time................................16
Figure 1-2:       Scope of the Future Radio System (FRS) as part of the FCI ...................18
Figure 3-1:       Phase 2 Airspace Organisation ................................................................55
Figure 4-1:       Information Security Requirement Process .............................................71
Figure 5-1:       FRS Boundary Point Examples................................................................88


                                                 LIST OF TABLES
Table 2-1: Airspace Domain Definitions....................................................................20
Table 2-2: COCR ATS Service Groups......................................................................22
Table 3-1: Phase 1 Airspace Environmental Characteristics......................................46
Table 3-2: Phase 1 Services Environmental Conditions.............................................46
Table 3-3: Phase 1 Aircraft Performance Characteristics...........................................47
Table 3-4: Phase 2 Airspace Environmental Characteristics......................................58
Table 3-5: Phase 2 Services Environmental Conditions.............................................59
Table 3-6: Phase 2 Aircraft Performance Characteristics...........................................59
Table 4-1: Phase 1 Operational Assessment...............................................................63
Table 4-2: Phase 2 Operational Assessment...............................................................64
Table 4-3: Description of Hazard Severity .................................................................65
Table 4-4: Safety Objective Definitions .....................................................................66
Table 4-5: ATS Phase 1 Operational Safety Assessment Hazard Severity and Safety
    Objectives ............................................................................................................67
Table 4-6: ATS Phase 2 Operational Safety Assessment Hazard Severity and Safety
    Objectives ............................................................................................................67
Table 4-7: Phase 1 Safety Assessment........................................................................68


                                                                        8
                                               COCR Version 2.0


Table 4-8: Phase 2 Safety Assessment........................................................................69
Table 4-9: FCI High-Level Threats ............................................................................72
Table 4-10: Threat Likelihood and Severity...............................................................73
Table 4-11: Information Security Threat Severity for ATS Services .........................75
Table 4-12: Information Security Threat Severity for AOC Services ........................76
Table 4-13: Properties of Security Controls ...............................................................77
Table 4-14: FCI Information Security Requirements .................................................79
Table 4-15: FRS Information Security Requirements ................................................80
Table 5-1: ATS Voice Performance Requirements ....................................................81
Table 5-2: AOC Voice Performance Requirements ...................................................82
Table 5-3: ATS Broadcast Service Update Intervals..................................................83
Table 5-4: Phase 1 ATS RCTP Performance Requirements ......................................84
Table 5-5: Phase 2 ATS RCTP Performance Requirements (ATS) ...........................85
Table 5-6: AOC RCTP Performance Requirements...................................................86
Table 5-7: Phase 1 ATS FRS Performance Requirements .........................................91
Table 5-8: Phase 2 ATS FRS Performance Requirements .........................................92
Table 5-9: FRS Allocated Data Performance Requirements (AOC) ..........................93
Table 6-1: Transmission Volume Ranges...................................................................97
Table 6-2: Phase 1 ATS Service Instances per Aircraft .............................................99
Table 6-3: Phase 2 ATS Service Instances per Aircraft ...........................................100
Table 6-4: AOC Service Instances per Aircraft........................................................101
Table 6-5: Phase 1 and 2 Flight Durations and Sectors/ATSUs Traversed..............102
Table 6-6: ATS Service Equipage and Voice/Data Utilisation Rate ........................103
Table 6-7: Service Volume PIACs ...........................................................................105
Table 6-8: Airport Controller Position PIACs ..........................................................106
Table 6-9: Airport Surface Vehicle Peak Counts .....................................................106
Table 6-10: Types of Surface Vehicles.....................................................................106
Table 6-11: Transmission Volume PIACs................................................................107
Table 6-12: Phase 1 Daily Operations per ATSU.....................................................107
Table 6-13: Phase 2 Daily Operations per ATSU.....................................................108
Table 6-14: NET Service Instances ..........................................................................109
Table 6-15: ATS Message Quantities and Sizes per Instance ..................................111
Table 6-16: AOC Message Quantities and Sizes per Instance .................................112
Table 6-17: NET Message Quantities and Sizes per Instance ..................................112
Table 6-18: Air-Ground Addressed COS Categories (Type DG).............................114
Table 6-19: Air-Air Addressed COS Categories (Type DA)....................................114
Table 6-20: Broadcast COS Categories (Type DB)..................................................114
Table 6-21: ATS COS Assignments .........................................................................115
Table 6-22: AOC COS Assignments ........................................................................116
Table 6-23: NET COS Assignments.........................................................................116
Table 6-24: ATS Voice Transmission Characteristics per Service Volume.............118
Table 6-25: Phase 1 Voice Communications Load...................................................118
Table 6-26: Phase 2 Voice Communications Load...................................................119
Table 6-27: Phase 1 Addressed Communication Load (kilobits per second [kbps])121
Table 6-28: Phase 2 Addressed Communication Load (kbps) – with A-EXEC.......122
Table 6-29: Phase 2 Addressed Communication Load (kbps) – without A-EXEC..122
Table 6-30: Phase 1 Addressed Communication Load (kbps) – Single Aircraft......123
Table 6-31: Phase 2 Addressed Communication Load (kbps) – Single Aircraft with
    A-EXEC.............................................................................................................123



                                                            9
                                             COCR Version 2.0


Table 6-32: Phase 2 Addressed Communication Load (kbps) – Single Aircraft
    without A-EXEC................................................................................................124
Table 6-33: Phase 1 Broadcast Information Transfer Rate – Separate Domains .....128
Table 6-34: Phase 1 Broadcast Information Transfer Rate – Fixed Range ..............128
Table 6-35: Phase 2 Broadcast Information Transfer Rate – Separate Domains .....129
Table 6-36: Phase 2 Broadcast Information Transfer Rate – Fixed Range ..............129
Table 7-1: Most Stringent FRS Allocated Data Requirements.................................132
Table 7-2: Most Stringent FRS Addressed Communication Load (kbps)................133




                                                        10
                         COCR Version 2.0


          ACRONYMS and ABBREVIATIONS
2-D        two dimensional (latitude and longitude)
3-D        three dimensional (latitude, longitude, and altitude)
4-D        four dimensional (latitude, longitude, altitude, and time)

ACAS       Aircraft Collision Avoidance System
ACL        ATC Clearance
ACM        ATC Communication Management
ADS        Automatic Dependent Surveillance
ADS-B      Automatic Dependent Surveillance – Broadcast
ADS-C      Automatic Dependent Surveillance – Contract
A-EXEC     Automatic Execution
AIRSEP     Air-to-Air Self-Separation
AMAN       Arrival Manager
AMC        ATC Microphone Check
AMN        Airspace Management and Navigation
ANSP       Air Navigation Service Provider
AOA        Autonomous Operations Area
AOC        Aeronautical Operational Control
AP         Action Plan
APT        Airport
ARMAND     Arrival Manager Information Delivery
A-SMGCS    Advanced-Surface Movement Guidance and Control System
ATC        Air Traffic Control
ATFM       Air Traffic Flow Management
ATIS       Automatic Terminal Information Service
ATM        Air Traffic Management
ATN        Aeronautical Telecommunication Network
ATS        Air Traffic Services
ATSAW      Air Traffic Situation Awareness
ATSU       ATS Unit
AVS        Advisory Services

bps        bits per second

C&P        Crossing and Passing
C-ATSU     Controlling ATSU
CDM        Collaborative Decision Making
CDTI       Cockpit Display of Traffic Information
CFMU       Central Flow Management Unit
CIS        Clearance/Instruction Services
CMU        Communications Management Unit
CNS        Communication, Navigation and Surveillance
COCR       Communications Operating Concepts and Requirements
COS        class of service
COTRAC     Common Trajectory Coordination
CPDLC      Controller-Pilot Data Link Communication
CTOT       calculated take-off time

D-ALERT    Data Link Alert


                                  11
                            COCR Version 2.0


D-ATIS        Data Link ATIS
D-ATSU        downstream ATSU
DCL           Departure Clearance
DCM           Data Communications Management Services
D-FLUP        Data Link Flight Update
DLL           Data Link Logon
D-ORIS        Data Link Operational En Route Information Service
D-OTIS        Data Link Operational Terminal Information Service
D-RVR         Data Link Runway Visual Range
DSC           Downstream Clearance
D-SIG         Data Link Surface Information and Guidance
D-SIGMET      Data Link Significant Meteorological Information
DSS           Delegated Separation Services
D-TAXI        Data Link Taxi Clearance
DYNAV         Dynamic Route Availability

E2E           end-to-end
ECAC          European Civil Aviation Conference
EFB           Electronic Flight Bag
EIS           Emergency Information Services
ENR           En Route
ETA           estimated time of arrival
ETD           estimated time of departure
EU            Europe
EUROCAE       European Organisation for Civil Aviation Equipment
EUROCONTROL   European Organisation for the Safety of Air Navigation

FAA           Federal Aviation Administration
FCI           Future Communications Infrastructure
FCS           Future Communications Study
FDPS          Flight Data Processing System
FIS           Flight Information Service
FL            Flight Level
FLIPCY        Flight Plan Consistency
FLIPINT       Flight Path Intent
FMS           Flight Management System
FPS           Flight Position/Intent/Preferences Services
FRS           Future Radio System
FUA           Flexible Use of Airspace

g             Gravity
GAT           General Air Traffic
GIS           Geographical Information System

HMI           Human Machine Interface

IATA          International Air Transport Association
ICAO          International Civil Aviation Organisation
ITP           In-Trail Procedure



                                    12
                        COCR Version 2.0


JPDO      Joint Planning and Development Office

kbps      kilobits per second
KIAS      Knots Indicated Air Speed
KTAS      Knots True Airspeed
Kph       kilometres per hour

LDC       landing data calculation

M&S       Merging and Spacing
METAR     Meteorological Aerodrome Report
MHz       mega-Hertz
MIS       Miscellaneous Services
MLM       Mid-Level Model
MNPS      Minimum Navigation Performance Specification
m/s2      metres per second squared
ms        milliseconds
MTCD      Medium Term Conflict Detection

N/A       Not available
NAS       National Airspace System (U.S.)
NextGen   Next Generation Air Transportation System
NGATS     Next Generation Air Transportation System
NM        nautical mile
NOTAM     Notice to Airmen

OAT       Operational Air Traffic
OOOI      Out-Off-On-In
OPA       Operational Performance Assessment
ORP       Oceanic, Remote, Polar
OSA       Operational Safety Assessment
OV        operational volume

PAIRAPP   Paired Approach
PIAC      Peak Instantaneous Aircraft Count
PIREP     Pilot Report
PPD       Pilot Preferences Downlink
PTT       Push to Talk

RCP       Required Communication Performance
RCTP      Required Communication Technical Performance
RF        radio frequency
RNAV      Area Navigation
RNP       Required Navigation Performance
rsvd      reserved
RTA       required time of arrival
RTD       required time of departure
RTCA      RTCA, Inc.
RVR       Runway Visual Range
RVSM      Reduced Vertical Separation Minima


                                13
                       COCR Version 2.0



s         seconds
SAAM      System for Assignment and Analysis at a Macroscopic Level
SAP       System Access Parameters
SESAR     Single European Sky ATM Research
SID       Standard Instrument Departure
SPR       Safety and Performance Requirements
SSR       secondary surveillance radar
STAR      Standard Terminal Arrival Route
STATFOR   Statistics and Forecast
SURV      Air Traffic Control Surveillance
SV        service volume

TAF       Terminal Area Forecast
TD        Transit Delay
TFM       traffic flow management
TIS-B     Traffic Information Service – Broadcast
TMA       Terminal Manoeuvring Area
TOD       Top of Descent
TODC      takeoff data calculation
TV        transmission volume

UAS       Unmanned Aerial System
UCT       Undetected Corrupted Transaction
URCO      Urgent Contact
U.S.      United States

VDL       VHF Digital Link
VHF       very high frequency (108 – 137 MHz)
VTOL      vertical takeoff and landing




                               14
                                   COCR Version 2.0



1 INTRODUCTION
1.1 Background
The European Organisation for the Safety of Air Navigation (EUROCONTROL) and
the Federal Aviation Administration (FAA) have initiated a joint study under a
Memorandum of Agreement through Action Plan 17 (AP 17) to identify potential
future communications technologies to meet safety and regularity of flight
communications requirements, i.e., those supporting Air Traffic Services (ATS) and
safety related Aeronautical Operational Control (AOC) communications.

The Future Communications Study (FCS) has two main activities:
   1. To identify the communication requirements to support emerging global future
      Air Traffic Management (ATM) concepts taking into account the needs of
      civil aviation and State aircraft operating as General Air Traffic (GAT) (i.e.,
      Operational Air Traffic (OAT) is not considered).
   2. To identify the most appropriate technology(ies) to meet these communication
      requirements.
This document covers the first activity by identifying the future concepts and defines
resulting Communications Operating Concept and Requirements (COCR). The
COCR will assist in the second activity by allowing key requirements to be matched
against candidate technologies – existing or future. To achieve this goal the COCR
identifies the requirements placed on the communications that take place through the
aircraft and ground radios. These are collectively referred to as the Future Radio
System (FRS). The COCR is technology-independent.

The operational requirements are drawn from ATM and AOC operating concepts
expected to be implemented globally to achieve the required capacity, safety, and
security. In particular, the International Civil Aviation Organisation (ICAO) Global
ATM Operating Concept [1] and the International Air Transport Association (IATA)
ATM Roadmap [9] were considered. Although not fully mature during the course of
the study, concepts and requirements being defined in the Single European Sky ATM
Research (SESAR) program and the United States (U.S.) Next Generation Air
Transportation System (NextGen) programme were taken into account to the
maximum extent possible with the information available.

The two primary drivers for the FRS are: 1) to provide an appropriate communication
infrastructure to support future air traffic growth, and 2) to provide a consistent global
solution to support the goal of a seamless air traffic management system.

The COCR considers two main phases of communications to support Air Traffic
Management. The first phase (Phase 1) is based on existing or emerging data
communication services. Initial steps of this phase are starting in some regions of the
world now. The second phase (Phase 2) represents a new paradigm in the use of data
communications. Phase 2 introduces new data communication services that replace or
supplement those in Phase 1 as data communications become the standard method of
air-ground communication and supports increased automation in the aircraft and on
the ground. In Phase 2, the data communications system becomes integral to the


                                           15
                                 COCR Version 2.0


provision of ATM. Figure 1-1 illustrates the expected timeframe of Phase 1 and
Phase 2.

In Phase 1, voice communications capabilities remain central to the provision of
ATM. In Phase 2, voice is only used for exceptional circumstances or for areas that
do not require/have data communications implementation. In Phase 2, the ATM
paradigm shifts from a tactical “Management by Intervention” to a strategic
“Management by Planning and Intervention by Exception.”

The FRS should, at a minimum, support the required air-ground and air-air data
communications. The data communications may be broadcast, multicast, and/or
addressed. Voice communication may be supported provided the FRS meets the
voice requirements in the document.




                                         Phase 1


                                                                   Phase 2

 2005      2010         2015        2020           2025       2030          2035

              Figure 1-1: Phase 1 and Phase 2 Concept Evolution Over Time

In some regions of the world, Phase 1 data communications services are already being
introduced through trials or implementation programmes. Other regions may begin
Phase 1 implementation at any time, or not at all, based on their ATM needs.
Similarly, the more advanced services described in Phase 2 may never be
implemented in some regions for various reasons such as lower traffic density or lack
of an adequate business case. This is depicted in Figure 1-1 by the dashed lines
showing continued use of Phase 1 concepts in some regions while others have
implemented those defined under Phase 2.

The performance requirements provided in this document are a “snapshot” of what
demands a full set of Phase 1 services anticipated to be in place in some regions
around 2020 would place on the communications system. The performance
requirements for Phase 2 represent the same for a fully matured set of services
anticipated to be in place in some regions in the 2030 timeframe.

A particular aircraft or ground system is not required to implement any of the services
contained in this document. Coordination between the regional stakeholders will
determine the operational services that benefit the local environment as part of a
global infrastructure.

1.2 Scope
The scope of the COCR document is to identify concepts, requirements, and trends
that will be the basis for selecting the FRS. Air Navigation Service Providers
(ANSPs) and industry are in the formative stages of determining many of the


                                           16
                                          COCR Version 2.0


underlying future concepts considered in this document. While not meant to be a
complete representation of the future global airspace operating concepts, this
document provides useful input in the ongoing effort to define them.

Civil-military interoperability has also been addressed in the development of the
COCR through coordination with the relevant military representatives. This helped
refine requirements in the areas of integrity, reliability, and security. Regulatory
aspects for civil or military ATM systems are not considered in this document.

The aviation community is considering the requirements for operating Unmanned
Aerial Systems (UASs) within the ATM infrastructure. Studies considering the
implications of operating UASs in non-segregated airspace are underway in several
regions of the world. Due to their immaturity, requirements to support command and
control links (i.e., telecommand and telemetry) have not been addressed in the COCR.
When UAS requirements in this area become available, the command and control link
traffic load could be estimated. All other communications services with UASs are
considered to be the same as those with manned aircraft, i.e., UAS operation is
transparent for the ATM system. In the future, in some parts of the world, the number
of these vehicles may represent a large portion of an Air Traffic Service Unit’s
(ATSU’s) traffic load. When providing ATS to a UAS, this may involve the relay of
communication and execution instructions to and from a remote pilot; however,
operational performance requirements between an ATSU and an UAS remain the
same as those between an ATSU and any manned aircraft.

Information security requirements associated with the ATS and AOC services defined
in Section 2 are discussed in Section 4.3. A number of new security services that
monitor and control the physical security of aircraft and the air traffic system are
currently under consideration. These services include provision of real-time video
transmission from the cockpit and provision of direct communications between
aircraft and security organisations. These physical security services are still being
defined, and it is not clear whether the FRS, a passenger communications system, or a
new dedicated communications system would be used to provide them. Therefore,
the physical security services are not discussed further in this document.

1.3 Context
The ATM environment in the timeframe of the FCS will continue to consist of ground
Human Machine Interfaces (HMIs), voice switches, Flight Data Processing Systems
(FDPSs) – (the Automation System), ground communications systems, routers,
networks, radio ground stations, airborne radios, and communication end systems
(e.g., airborne Communications Management Units [CMUs] and ground data
communications application processors). These components, combined in an end-to-
end chain must meet the performance and safety requirements for voice and data
applications.

In this document, the term FRS1 is used to refer to the physical implementation of the
radio components of a communication system that meets these requirements. The
scope of the FRS is illustrated in Figure 1-2. The FRS is part of the overall Future
Communications Infrastructure (FCI), which includes all the components (e.g.,
1
    A singular reference to technology is used, but the FRS may be a combination of technologies.


                                                    17
                                  COCR Version 2.0


processors, applications, and networks) needed for the ANSP, AOC, and aircraft to
communicate with each other.




          Figure 1-2: Scope of the Future Radio System (FRS) as part of the FCI


1.4 Approach
To determine the overall context for future communications, numerous concepts of
operations, vision statements, and plans being developed and circulated by ANSPs
around the world were reviewed. These are identified in the document reference list
in Section 1.6.

The following steps describe the approach adopted in producing the communication
operating concepts and requirements for the FRS.
   1. Develop notional vision and universal operating concepts for air traffic
      management.
   2. Identify and define the ATS and AOC required services.
   3. Define the operating environment, in which these services would be provided,
      to ensure all implications of each service were addressed.
   4. Perform safety, information security, and performance assessments for the air
      traffic services.




                                           18
                                 COCR Version 2.0


   5. Establish high-level requirements that each service would have to meet (so
      that the specified outcome or benefit of the service could be achieved safely
      and efficiently), and allocate requirements to the FRS.
   6. Calculate the FRS voice and data capacity required to deliver the specified air
      traffic services.
   7. Put the COCR into perspective and facilitate future use of the COCR by
      applying the results to sample applications.

1.5 Document Organisation
This document is organised as follows:
       Section 1 (Introduction): This section includes background and document
       scope and organization.
       Section 2 (Operational Services): This section describes the operational
       services that are referenced in the Section 3 scenarios.
       Section 3 (Operational Concept, Environment, and Scenarios for
       Communications): This section discusses operational trends and presents
       real world “day-in-the-life-of” scenarios to describe the operational concepts.
       Section 4 (Operational, Safety, and Security Requirements): This section
       provides high-level safety and security communications requirements.
       Section 5 (Performance Requirements): This section provides performance
       requirements.
       Section 6 (Communication Loading Analyses): This section presents a
       detailed communication system loading analysis based on an estimation of
       message sizes, message frequencies, performance requirements, and airspace
       aircraft densities.
       Section 7 (Conclusions): This section provides the document conclusions.
An Acronym and Abbreviation section is provided at the beginning of the document.

1.6 Document References
A complete reference list is shown in Appendix F. Document reference numbers
appear in the COCR as “[x].”




                                         19
                                       COCR Version 2.0



2 OPERATIONAL SERVICES
2.1 Introduction
This section describes the Air Traffic Services (ATS) and Aeronautical Operational
Control (AOC) services that are expected during Phase 1 and Phase 2. Section 3
divides the transition/evolution process of these services into Phases 1 and 2 and
provides scenarios demonstrating how the services in each phase could be used.

The focus and definition of the following services is data communications. In
Phase 1, voice communications will continue to support most of these services in
continental environments when required by the time criticality of the exchange. In
Phase 2, data communications will become the primary means of communication,
with voice being retained for non-routine situations.

2.2 Air Traffic Services
The ATS data communications services vary by the domain in which the aircraft is or
will be operating. The COCR divides airspace into five representative airspace
domains. Although specific regional differences exist, Table 2-1 contains the airspace
domain definitions used in this document.

Domain            COCR Definition
Airport           The APT domain consists of an area 10 miles in diameter and up to ~5000 ft consisting
(APT)             of the airport surface and immediate vicinity of the airport.
Terminal          The TMA domain consists of the airspace surrounding an airport, typically starting at
Manoeuvring       ~5000 ft up to ~FL245, that is the transition airspace used by Air Traffic Control (ATC)
Area (TMA)        to merge and space aircraft for landing or for entrance into the Enroute domain. The
                  TMA domain typically radiates out ~50 nautical miles (NM) from the centre of an
                  airport. The COCR assumes that the airspace used in departure and arrival phases of
                  flight are identical except for the direction of flight.
En Route          The ENR domain consists of the airspace that surrounds the TMA domain starting at
(ENR)             ~FL245 to ~FL600 and is the continental or domestic airspace used by ATC for the
                  cruise portion of the flight. It also includes areas to the lower limits of controlled
                  airspace (e.g., 1,500 feet) where an airport or TMA does not exist. At the ATSU level,
                  the COCR assumes this domain to have a horizontal limit extending 300 NM by 500
                  NM.
Oceanic,          The ORP domain is the same as the ENR domain, except that it is associated with
Remote, Polar     geographical areas generally outside of domestic airspace. The COCR assumes this
(ORP)             domain to have a horizontal limit extending 1000 NM by 2000 NM.
Autonomous        The AOA domain is a defined block of airspace which is associated with autonomous
Operations Area   operations where aircraft self-separate (i.e., Air Traffic Control is not used). The defined
(AOA)             block may change vertical or horizontal limits or usage times based on, among other
                  factors, traffic densities. The COCR assumes this domain to have horizontal limits of
                  400 NM by 800 NM.

                            Table 2-1: Airspace Domain Definitions

ATS services are expected to be utilised in the respective domains or in the AOA
buffer zone, but not within the AOA domain itself. Many ATS communications can


                                                  20
                                 COCR Version 2.0


be done using voice or data. The services in the following list are considered to be
either not supportable by voice (e.g., Automatic Execution [A-EXEC]) or may be
operationally inefficient when implemented by voice. Some services can be
supported by voice broadcast (e.g., Automatic Terminal Information Service [ATIS]);
however, a data communications implementation could reduce Flight Crew workload
and allow them to receive remote reports.
   1. Air Traffic Control (ATC) Microphone Check (AMC)
   2. Air Traffic Control Surveillance (SURV)
   3. Automatic Execution (A-EXEC)
   4. Common Trajectory Coordination (COTRAC)
   5. Data Link Alert (D-ALERT)
   6. Data Link Automatic Terminal Information Service (D-ATIS)
   7. Data Link Logon (DLL)
   8. Data Link Operational Route Information Service (D-ORIS)
   9. Data Link Operational Terminal Information Service (D-OTIS)
   10. Data Link Runway Visual Range (D-RVR)
   11. Data Link Significant Meteorological Information (D-SIGMET)
   12. Data Link Surface Information and Guidance (D-SIG)
   13. Data Link Flight Update (D-FLUP)
   14. Dynamic Route Availability (DYNAV)
   15. Flight Plan Consistency (FLIPCY)
   16. Flight Path Intent (FLIPINT)
   17. System Access Parameters (SAP)
   18. Traffic Information Service – Broadcast (TIS-B)
   19. Urgent Contact (URCO)
   20. Wake Vortex (WAKE)
   21. Air-to-Air Self Separation (AIRSEP)

2.2.1 ATS Voice Services
Most of the current air-ground and air-air voice communications functions will
continue to be needed. Voice communications have some advantages over data
communications, such as: high availability, low end-to-end latencies, the ability to
convey human feelings, flexibility of dialogue, provision of a party-line, and use for
non-routine, time critical, or emergency situations. This does not apply to UAS
operations or direct automation-to-automation operations in Phase 2. The party-line
will continue to be required to support broadcast of Flight Crew intent, e.g., traffic
arriving and departing at uncontrolled airports.

Although some services, such as Data Link Taxi Clearance (D-TAXI), are specifically
data communications services, taxi clearances will continue to be provided by voice


                                         21
                                                  COCR Version 2.0


    for non-equipped aircraft. In addition, a ground-to-air broadcast voice will continue
    to be used to support dissemination of Flight Information Service (FIS) information.
    The need for this voice broadcast service could be diminished over time depending on
    the extent of data communications equipage.

    2.2.2 ATS Data Services
    The ATS data services have been grouped into eight categories as indicated in Table
    2-2.

Data              Clearance/     Flight            Advisory       Flight         Emergency     Delegated-    Miscellaneous
Communications    Instruction    Information       Services       Position/      Information   Separation    Services
Management        Services       Services (FIS)    (AVS)          Intent/        Services      Services      (MIS)
Services (DCM)    (CIS)                                           Preferences    (EIS)         (DSS)
                                                                  Services
                                                                  (FPS)

Data Link Logon   ATC            Data Link         Arrival        Surveillance   Data Link     In-Trail      Air-to-Air Self
(DLL)             Clearance      Automatic         Manager        (SURV)         Alert (D-     Procedures    Separation
                  (ACL)          Terminal          Information                   ALERT)        (ITP)         (AIRSEP)
ATC                              Information       Delivery       Flight Plan
Communication     Departure      Service           (ARMAND)       Consistency    Urgent        Merging       Auto Execute
Management        Clearance      (D-ATIS)                         (FLIPCY)       Contact       and Spacing   (A-EXEC)
(ACM)             (DCL)                            Dynamic                       (URCO)        (M&S)
                                 Data Link         Route          Flight Path
                  Downstream     Operational       Availability   Intent                       Crossing
                  Clearance      Terminal          (DYNAV)        (FLIPINT)                    and Passing
                  (DSC)          Information                                                   (C&P)
                                 Service           Data Link
                                 (D-OTIS)                         System
                  ATC                              Flight         Access                       Paired
                  Microphone                       Update (D-     Parameters                   Approach
                  Check          Data Link         FLUP)          (SAP)                        (PAIRAPP)
                  (AMC)          Operational
                                 En Route
                                 Information                      Wake
                  Data Link      Service                          Broadcast
                  Taxi (D-       (D-ORIS)                         (WAKE)
                  TAXI)
                                 Data Link                        Pilot
                  Common         Significant                      Preferences
                  Trajectory     Meteorological                   Downlink
                  Coordination   Information                      (PPD)
                  (COTRAC)       (D-SIGMET)
                                                                  Traffic
                                 Data Link                        Information
                                 Runway                           Service-
                                 Visual Range                     Broadcast
                                 (D-RVR)                          (TIS-B)


                                 Data Link
                                 Surface
                                 Information
                                 and Guidance
                                 (D-SIG)


                                   Table 2-2: COCR ATS Service Groups

    2.2.2.1 Data Communications Management Services

    2.2.2.1.1      Data Link Logon (DLL)
    The DLL service exchanges information between an aircraft and an ATSU to support
    other addressed data communications services. The DLL service is executed prior to


                                                            22
                                 COCR Version 2.0


any other addressed data communications service. It is used to uniquely identify an
aircraft and to provide version and address information for all data communications
services. Once initiated, DLL provides the flight identification to the avionics, and
the remainder of the DLL takes place automatically without Flight Crew involvement.

The DLL information must be available for each ATSU that will offer data
communications services. The DLL initiation only needs to be completed once for a
given flight. For this nominal case, the ATSU with which the initiation function was
conducted does one of the following:
       Provides all other required ATSUs information in the DLL initiation response.
       Allows other ATSUs to access the DLL initiation information (e.g., DLL
       server).
       Provides aircraft DLL initiation information to a subsequent ATSU, and each
       subsequent ATSU again passes the DLL initiation information to its
       subsequent ATSU.
Alternatively, the DLL service can be accomplished by initiation of the DLL service
by the Flight Crew separately for each ATSU, e.g., when ground-ground
communication is not provided to transfer DLL information among ATSUs.

The DLL service consists of the following types of exchanges:
       Initiation (I): The initial means to exchange application information between
       an aircraft and ATSU, and to provide flight data to an ATSU. This function is
       between a given aircraft-ATSU pair, but when available, information for other
       ATSUs may be exchanged.
       Contact (C): An ATSU provides the DLL address of a specified ATSU to an
       aircraft and requests the initiation function be performed between the aircraft
       and the specified ATSU. The specified ATSU is different from the ATSU
       requesting the contact.
The DLL service uses addressed communications.

2.2.2.1.2   ATC Communication Management (ACM)
The ACM service is used for the following:
       To manage the transfer of data communication authority between sectors
       and/or ATSUs
       To terminate data communications with an ATSU
       To issue a change of voice frequency
When the ACM service is used for transfers between ATSUs/sectors or a change of
frequency, it is initiated by one of the following:
       The transferring sector or ATSU
       A request from the receiving sector or ATSU
       A request from the Flight Crew



                                         23
                                  COCR Version 2.0


The ACM service consists of the following types of exchanges:
       Requests to initiate and terminate air-ground control communications
       Indication of the next data authority
       Voice frequency contact and monitor messages
The ACM service uses addressed communications.

2.2.2.2 Clearance/Instruction Services
The following subsections provide a definition of the ATS Clearance/Instruction data
communications services.

Note: Although the some ATS clearance/instruction data communications services
may be generated by a ground automation system and sent directly to an aircraft
without Controller review/action, the execution of any trajectory altering messages
will continue to require Flight Crew action prior to execution by on-board
automation/avionics.

2.2.2.2.1   ATC Clearance (ACL)
A Flight Crew under the control of an ATSU transmits reports; makes requests; and
receives clearances, instructions, and notifications using ACL. The ACL service
specifies dialogue exchanges via air-ground addressed communications between
Flight Crews and Controllers working the specific position/sector associated with the
aircraft’s physical location. The ACL service may be initiated by either the ground
automation/Controller or the avionics/Flight Crew. Some ACL exchanges, (e.g.,
altimeter settings and secondary surveillance radar [SSR] transponder code
assignments) can be transmitted without Controller review/action. ACL is available
in all flight phases (except in the AOA domain beyond the buffer zone).

The ACL service consists of the following types of exchanges:
       ATC clearances, instructions, notifications, and requests
       Flight crew requests, reports, notifications, and compliance indications
The ACL service uses addressed communications.

2.2.2.2.2   Departure Clearance (DCL)
A flight due to depart from an airfield must obtain a departure clearance from the
Controlling ATSU (C-ATSU). The DCL service enables a Flight Crew to receive
their departure clearance and related route-of-flight information by data
communications. The DCL service provides automated assistance to Controllers and
Flight Crews to perform these communication exchanges.

DCL clearances are usually provided in response to a Flight Crew data
communications request, but may also be initiated by the Controller/ATSU
automation. A DCL clearance requires a response from the Flight Crew. The DCL
service consists of a DCL request(s) from the Flight Crew and DCL clearances and



                                          24
                                 COCR Version 2.0


revisions, as required, from the Controller or ATSU automation. DCL is available
prior to takeoff. The DCL service consists of the following types of exchanges:
       ATC departure clearances and revisions
       Flight crew clearance requests and compliance indications
The DCL service uses addressed communications.

2.2.2.2.3    Downstream Clearance (DSC)
A Flight Crew may need to obtain clearances or information from an ATSU not yet in
control of the aircraft but that will be responsible for control of the aircraft later
during the flight, i.e., a downstream ATSU (D-ATSU).

The DSC service can only be initiated by a Flight Crew request for a DSC. The DSC
service consists of a DSC request(s) from the Flight Crew and DSC clearances and
revisions, as required, from the Controller or ATSU automation. A DSC clearance
requires a response from the Flight Crew.

Clearances or information received through downstream communications that have an
affect on the aircraft’s trajectory prior to the D-ATSU’s airspace are explicitly
coordinated with the C-ATSU.

An aircraft may be in any phase of flight when requesting and obtaining a
downstream clearance. The Flight Crew conducts DSC with only one D-ATSU at a
time.

In Phase 2 this service is largely superseded by COTRAC.

The DSC service consists of the following types of exchanges:
       Flight crew requests, reports, notifications, and compliance indications
       ATC downstream clearances, instructions, and requests
The DSC service uses addressed communications.

2.2.2.2.4    ATC Microphone Check (AMC)
When the voice channel is blocked, such as when an aircraft has a stuck microphone,
the AMC service is used to contact some or all aircraft under control of that
sector/position. The AMC message instructs a Flight Crew to check the aircraft’s
communication equipment to determine if the cause of the problem is a stuck
microphone on their aircraft and, when required, take corrective action.

The AMC service consists of the following type of exchange:
       Uplink of instruction to check for a stuck microphone
The AMC service may use addressed or broadcast communications.




                                          25
                                  COCR Version 2.0


2.2.2.2.5    Data Link Taxi Clearance (D-TAXI)
The Flight Crew of an aircraft preparing to depart from an airport or of an aircraft that
has just landed must obtain a series of clearances from the C-ATSU in order to
proceed from a gate/stand to the runway or from the runway to a gate/stand. The D-
TAXI service provides automated assistance to Controllers and Flight Crews to
perform these communication exchanges for ground-movement operations. D-TAXI
clearances are usually provided in response to a Flight Crew request but may also be
initiated by the Controller/ATSU automation. D-TAXI clearances may be amended.
D-TAXI clearances require a response from the Flight Crew.

In general, for arriving aircraft, a D-TAXI clearance may be requested and/or issued
once the aircraft lands. In some cases, in order to improve surface management, D-
TAXI instructions for arriving aircraft may be issued to a Flight Crew while the
aircraft is in the approach pattern. Then, when the landing uses the anticipated turn-
off, the previously issued D-TAXI can be confirmed for execution.

The D-TAXI service consists of the following types of exchanges:
       ATC taxi clearances, instructions, and requests
       Flight crew requests, reports, notifications, and compliance indications
The D-TAXI service uses addressed communications.

2.2.2.2.6    Common Trajectory Coordination (COTRAC)
The COTRAC service is used to establish and coordinate trajectory agreements in
real-time using graphical interfaces and automation systems, in particular the Flight
Management System (FMS). COTRAC provides trajectory agreements involving
multiple constraints, e.g., latitude/longitude, altitude, and airspeed.

Initially, COTRAC may be restricted to the use of two-dimensional (2-D) trajectories
consisting of, for example, departure point, top-of-climb, top-of-descent, and arrival
fix crossing constraints. As air and ground system capabilities improve, COTRAC
will be capable of providing four-dimensional (4-D) trajectories.

The COTRAC service may be initiated by either the Flight Crew or the
controller/ATSU.     Although not part of the air-ground COTRAC data
communications exchange, 4-D trajectory-based flight plans may be coordinated
through the use of COTRAC.

A Controller/C-ATSU automation may initiate COTRAC by issuing either a
COTRAC trajectory clearance message or a trajectory constraints message. A
COTRAC trajectory is simply a clearance and is handled as such. A trajectory
constraint message provides the Flight Crew a set of constraints (e.g., required time of
arrivals [RTAs], 4-D waypoints) that must be taken into account when requesting a
trajectory. The Flight Crew can then respond with a trajectory request, which may be
in turn responded to with a trajectory clearance.

A Flight Crew can initiate COTRAC by requesting a specific COTRAC trajectory.
The Controller/C-ATSU automation then responds with 1) a requested COTRAC



                                           26
                                   COCR Version 2.0


trajectory clearance, or 2) a set of constraints used to negotiate an alternate COTRAC
trajectory, or 3) an indication that a COTRAC trajectory cannot be provided.

The COTRAC service consists of the following types of exchanges:
       Trajectory Constraints: A set of constraints provided to a Flight Crew (e.g.,
       RTAs and trajectory points).
       Trajectory Request: A Flight Crew request that includes a series of
       trajectory points including RTAs taking into account any supplied constraints.
       Trajectory Clearance: A clearance that includes a series of trajectory points,
       including RTAs.
       Trajectory Non-conformance: A report from the Flight Crew or aircraft
       automation indicating non-conformance with the trajectory clearance.
Note: FLIPINT or SURV may be used instead of a Trajectory Non-conformance
indication, to provide aircraft position and intent data either periodically or in
response to a ground specified non-conformance event.

Prior to initiating the COTRAC service, a trajectory-based flight plan may be filed.
This flight plan may include a series of 2-, 3-, or 4-D trajectory points, including key
points (e.g., top-of-descent), ATS route designators or fix names, estimated times of
arrival (ETAs), required times of arrival (RTAs) (as needed), required time of
departure (RTD) (if needed), and additional information such as Communication,
Navigation and Surveillance (CNS) performance characteristics (e.g., Required
Navigation Performance [RNP]-4, Required Communication Performance [RCP]-
120), tolerance of time variability from the proposed departure, and priority ranking
relative to other flights proposed by that user. The times at the points along the
trajectory, as desired and predicted by the user, are referred to as ETAs. The
trajectory-based flight plan is the filed flight plan that will later be negotiated prior to
flight and is a ground-ground communication.

The COTRAC service uses addressed communications.

2.2.2.3 Flight Information Services

2.2.2.3.1    Data Link Automatic Terminal Information Service (D-ATIS)
D-ATIS provides automated assistance in requesting and delivering air traffic
information including: meteorological conditions, operating procedures, runways and
approaches in use, and various other information which may affect the departure,
approach, and landing flight phases as well as surface operations relevant to a
specified airport(s) in any phase of flight (except in the AOA domain outside of the
buffer zone).

ATIS information is updated upon the issuance of a new weather report or when
conditions or procedures affecting various components of the ATIS message change
by specified criteria.




                                            27
                                COCR Version 2.0


D-ATIS supplements and/or replaces the ATIS available as a voice broadcast service
provided at aerodromes worldwide. All types of ATIS provided by voice are also
provided by data (i.e., arrival, departure and combined).

D-ATIS does not change the operational requirement to obtain ATIS prior to
contacting the associated ATS facility but does replace the repetition of the ATIS
designator back to the Controller with transmission of the ATIS code in a data
communications message to the Controller/ATSU.

When ATIS is provided by both voice and data, the operational content of voice and
data ATIS must be semantically identical and updated simultaneously.

D-ATIS consists of the following types of exchanges:
       Downlink of request (i.e., demand, periodic or event contract) for ATIS
       reports
       Uplink of contract acknowledgements
       Uplink of arrival, departure, or combined ATIS reports
D-ATIS can use addressed and/or broadcast communications.

Note: The D-ATIS information may be included as part of the information provided by
D-OTIS.

2.2.2.3.2   Data Link Operational Terminal Information Service (D-OTIS)
D-OTIS provides Flight Crews with compiled meteorological and operational flight
information derived from ATC, ATIS, Meteorological Aerodrome Report (METAR),
Notice to Airmen (NOTAM), and Pilot Report (PIREP) information tailored to the
departure, approach and landing phases of flight.

The D-OTIS information is updated when the ATIS, METAR, NOTAM, or PIREP
components of the OTIS message change by specified criteria or delivery of
operational information (e.g., delays, Collaborative Decision Making (CDM)
sequences), is considered necessary by ATC.

D-OTIS consists of the following types of exchanges:
       Downlink of request (i.e., demand, periodic, or event contract) for OTIS
       reports
       Uplink of contract acknowledgements
       Uplink of OTIS reports
D-OTIS can use addressed and/or broadcast communications.

2.2.2.3.3   Data Link Operational En Route Information Service (D-ORIS)
D-ORIS provides Flight Crews with compiled meteorological and operational flight
information, derived from ATC, En Route weather information, NOTAMs, and other
sources, specifically relevant to an area to be over-flown by the aircraft.



                                        28
                                COCR Version 2.0


The D-ORIS information is updated when the specified components of the D-ORIS
message change by specified criteria or delivery of operational information (e.g.,
delays and CDM sequences), is considered necessary by ATC.

D-OTIS consists of the following types of exchanges:
       Downlink of request (i.e., demand, periodic, or event contract) for ORIS
       reports
       Uplink of contract acknowledgements
       Uplink of ORIS reports
D-ORIS can use addressed and/or broadcast communications.

2.2.2.3.4   Data Link Significant Meteorological Information (D-SIGMET)
The D-SIGMET service provides Flight Crews with advisories of the occurrence, or
expected occurrence, of weather phenomena that may affect the safety of aircraft
operations. The preparation and issue of SIGMET reports is the prime responsibility
of meteorological watch offices. SIGMET information messages are distributed on
ground initiative to aircraft in flight through associated ATSUs.

The D-SIGMET service consists of the following types of exchanges:
       Uplink of SIGMET reports
The D-SIGMET service can use addressed and/or broadcast communications and is
provided on an event basis only.

Note: D-SIGMET information may also be embedded in the D-ATIS, D-OTIS or D-
ORIS report when applicable.

2.2.2.3.5   Data Link Runway Visual Range (D-RVR)
The D-RVR service provides Flight Crews with up-to-date RVR information related
to an airport’s runway(s). Flight Crews can request RVR information related to any
airport’s runway(s) during any phase of flight. The D-RVR information is updated
when the specified components of the D-RVR message change by specified criteria.

The D-RVR service consists of the following types of exchanges:
       Downlink of request (i.e., demand, periodic, or event contract) for RVR
       information
       Uplink of contract acknowledgements
       Uplink of RVR information
The D-RVR service can use addressed and/or broadcast communications.

2.2.2.3.6   Data Link Surface Information and Guidance (D-SIG)
D-SIG provides current airport elements necessary for ground movements (e.g.,
taxiway closures, runway re-surfacing) to the Flight Crew.


                                        29
                                   COCR Version 2.0


D-SIG is initiated by the ground automation upon completion of the DCL for
departures or upon recognition of transition to initial approach for arrivals.

In Phase 1, not many aircraft avionics will have advanced to the stage of
implementing a moving map where the D-TAXI instruction would be overlaid on the
D-SIG. Therefore, the D-SIG information in Phase 1 is used for situational awareness
only.

In Phase 2, the integration of the displays has occurred and the D-SIG information is
overlaid on on-board airport map displays that show significant surface information
including the D-TAXI route.

The D-SIG service consists of the following types of exchanges:
       Uplink of airport data which may be displayed on-board
The D-SIG service can use addressed and/or broadcast communications.

2.2.2.4 Advisory Services

2.2.2.4.1    Arrival Manager (AMAN) Information Delivery (ARMAND)
The ARMAND service transmits relevant advisories directly from the ground
automation to Flight Crews that are within the optimum-planning horizon of the
AMAN.

The ARMAND service transmits target, expected, or revised controlled arrival time
advisories relevant to the destination airport or points in space along the aircraft’s
route. The ARMAND service only offers advisories, not clearances, and thus is
consistent with the principle of not modifying the route of an aircraft that is in another
sector’s airspace. The aircraft may be beyond the limits of the ATSU that contains
the restriction point when the ARMAND service is initiated.

To enforce the AMAN time, a subsequent ACL instruction to cross a significant point
at a specified time and/or speed and/or level is issued.

The ARMAND service consists of the following types of exchanges:
       Uplink of controlled arrival times
The ARMAND service uses addressed communications.

Note: COTRAC is expected to supersede ARMAND for COTRAC-equipped aircraft.

2.2.2.4.2    Dynamic Route Availability (DYNAV)
The DYNAV service is used by an ATSU to offer a Flight Crew alternative routes as
they become available during the course of a flight. DYNAV may be initiated
automatically by the automation or manually by the Controller. The ATSU does not
need to be in control of the aircraft when providing the DYNAV service.




                                            30
                                 COCR Version 2.0


The following situations may result in availability of alternative routes: lifting of
military Special-Use Airspace reservations or initiation or dissipation of weather
phenomena or other operational restrictions.

The Flight Crew may request a clearance to use a DYNAV-offered route via the ACL,
DSC, or COTRAC service.

Note: Clearances used to provide a route offered by the DYNAV service, like any
clearance, are issued once the aircraft is under the control of the ATSU responsible
for the DYNAV route or by a D-ATSU when coordinated with any affected ATSU(s)
between the aircraft’s current position and the D-ATSU airspace.

The DYNAV service consists of the following types of exchanges:
       Uplink of available alternative route(s)
The DYNAV service uses addressed communications.

2.2.2.4.3    Data Link Flight Update (D-FLUP)
The D-FLUP service provides ATM-related operational data and information to
optimise flight operations. Examples of D-FLUP data include flight-specific
information related to the departure sequence, slot-time allocations, flow management
advisories, airspace/airport configurations, and special operations such as de-icing.
D-FLUP operates on a demand, periodic, or event basis and is available in any phase
of flight.

The D-FLUP service consists of the following types of exchanges:
       Request for D-FLUP
       Uplink of ATM operational data
The D-FLUP service may use addressed and/or broadcast communications.

2.2.2.5 Flight Position, Flight Intent, and Flight Preferences Services

2.2.2.5.1    Air Traffic Control Surveillance (SURV)
The SURV service uses Automatic Dependent Surveillance (ADS) positional
information provided by equipped aircraft for separation or monitoring purposes. The
information can be provided via broadcast, (i.e., ADS – Broadcast [ADS-B]), or via
addressed contracts, (i.e., ADS – Contract [ADS-C]). This service can be conducted
in all domains independent of radar support.

When SURV uses ADS-B, the aircraft providing the data must have the capability to
broadcast out, and the recipient for the ADS data (either another aircraft or a ground
system) must have the capability to receive and process ADS-B reports.

When SURV uses ADS-C, the aircraft providing the data must have the capability to
respond to contract requests for ADS-C data, and the requester for/recipient of the
ADS data (either another aircraft or a ground system) must have the capability to



                                          31
                                 COCR Version 2.0


establish ADS contracts (demand, periodic, and/or event) and receive and process
ADS-C reports.

The SURV service consists of the following types of exchanges:
       Uplink of contract(s) requesting ADS-C data
       Downlink of contract acknowledgements
       Downlink of current and predicted position, meteorological data, other flight
       data (i.e., ADS-C reports)
       Aircraft broadcast of position data (i.e., ADS-B reports)
The SURV service uses addressed and/or broadcast communications.

Note: The SURV service supports the surveillance portion of the Delegated
Separation Services (i.e., the ITP, M&S, C&P, and PAIRAPP).

2.2.2.5.2    Flight Plan Consistency (FLIPCY)
The FLIPCY service provides information to an ATSU for the detection of
inconsistencies between the ATC flight plan and the flight plan activated in the
aircraft’s Flight Management System (FMS).

FLIPCY consists of a ground-initiated request (manual or automated) for route
information from the aircraft. The request can be specified as a period of time or as a
number of waypoints (e.g., 15 minutes or 6 waypoints) relative to the aircraft’s
current position. The aircraft responds with the route data it can supply based on the
request. This service is conducted without Flight Crew involvement.

The FLIPCY service can be initiated prior to entry into an ATSU’s airspace, after
issuance of a departure clearance, or at any time an ATSU requires such information.

This information may result in an ACL instruction to resolve any inconsistency
between the aircraft’s reported route of flight and the ATSU’s stored route of flight
for that aircraft.

The FLIPCY service consists of the following types of exchanges:
       Uplink of contract(s) requesting FLIPCY data
       Downlink of contract acknowledgements
       Downlink of current and predicted position, meteorological data, and ground
       speed
The FLIPCY service uses addressed communications.

2.2.2.5.3    Flight Path Intent (FLIPINT)
The FLIPINT service provides information to an ATSU for the detection of
inconsistencies between the ATC flight plan and the flight plan activated in the
aircraft’s FMS.



                                          32
                                 COCR Version 2.0


The FLIPINT service is established automatically by an ATSU or manually by a
Controller. FLIPINT data is downlinked on demand, periodically, or upon occurrence
of an event, and will include the position (latitude, longitude, and altitude), ground
speed, meteorological information, and up to 128 subsequent waypoints with time,
altitude, and speed projections as requested. The aircraft responds with the route data
it can supply based on the request. This service is conducted without Flight Crew
involvement. The type or amount of data (e.g., report criteria and/or report contents)
requested via FLIPINT may be modified by the ATSU/Controller each time a
FLIPINT request is issued.

The FLIPINT service can be initiated prior to entry into an ATSU’s airspace, after
issuance of a departure clearance, to monitor compliance with a COTRAC trajectory
clearance, or at any time an ATSU requires such information.

The FLIPINT service consists of the following types of exchanges:
       Uplink of contract(s) requesting FLIPINT data
       Downlink of contract acknowledgements
       Downlink of current and predicted position, meteorological data, and ground
       speed
The FLIPINT service uses addressed communications.

Note: The FLIPINT service may provide the conformance monitoring required in the
COTRAC service. FLIPINT information may result in ACL or COTRAC instructions
to resolve any inconsistency between the aircraft’s reported route of flight and the
ATSU’s stored route of flight for that aircraft.

FLIPINT data can be used to perform the FLIPCY service, superseding the necessity
to implement FLIPCY.

2.2.2.5.4    System Access Parameters (SAP)
The SAP service consists of the extraction, transmission, and provision to the
Controller or ground automation of specific airborne avionics tactical flight
information (e.g., indicated heading, indicated air speed or mach, vertical rate,
selected level, and wind vector). The ground system uses the SAP service to provide
enhancements to ATC surveillance and trajectory prediction functions. The SAP
service is initiated by ATSU automation and conducted on a periodic or event driven
basis.

SAP is primarily used in En Route and terminal areas, but is available in all phases of
flight.

The SAP service consists of the following types of exchanges:
       Uplink of contract(s) requesting SAP data
       Downlink of contract acknowledgement(s)
       Downlink of indicated heading, indicated air speed or mach, vertical rate,
       selected level, and wind vector


                                          33
                                 COCR Version 2.0


The SAP service uses addressed communications.

2.2.2.5.5    Wake Service (WAKE)
The WAKE service provides information enabling encounter-specific separation
based on wake vortex characteristics. Ground automation uses the WAKE parameters
(e.g., aircraft type, weight, and flap and speed settings) and other environmental data
to determine the required minimum separation between a pair of aircraft to avoid a
wake vortex encounter. The WAKE service is available in all domains except ORP
and AOA.

The WAKE service consists of the following types of exchanges:
       Broadcast of WAKE characteristics (e.g., aircraft type, weight, and flap and
       speed settings)
The WAKE service uses broadcast communications.

2.2.2.5.6    Pilot Preferences Downlink (PPD)
The PPD service provides automated support for ground automation/Controller
trajectory and traffic flow planning. It is used by a Flight Crew to express flight
preferences or limitations. The PPD service allows the Flight Crew, in all phases of a
flight, to provide the ground automation/Controller with a set of preferences beyond
what is available in the filed flight plan (e.g., maximum acceptable flight level) and
request modification of some flight plan elements (e.g., desired route or speed
limitations).

The PPD service data is either transmitted by the Flight Crew to the ATSU each time
they enter/update the information, or it can be transmitted in response to a ground
automation/Controller request. PPD may be used prior to an aircraft being under
control of the sector to which the information pertains. PPD information is passed to
the next ATSU as part of ground-ground coordination when the information is still
pertinent.

The PPD service consists of the following types of exchanges:
       Uplink of request for PPD data
       Downlink of flight limitations (e.g., maximum acceptable flight level)
       Downlink of pilot flight preferences
       Downlink of flight plan modification requests (e.g., desired route or speed
       limitations)
The PPD service uses addressed communications.

2.2.2.5.7    Traffic Information Service Broadcast (TIS-B)
The TIS-B service is used by a ground system to broadcast sensor-based traffic
information and/or re-broadcast received air-ground ADS-B information. TIS-B
information is displayed on aircraft avionics to provide the Flight Crew with
situational awareness of proximate traffic.


                                          34
                                 COCR Version 2.0


The TIS-B service consists of the following types of exchanges:
       Uplink broadcast of flight traffic positional information
The TIS-B service uses ground broadcast communications.

Note: The TIS-B service will be implemented for some classes of users in various
domains.

TIS-B will become unnecessary in Phase 2 when all aircraft are equipped with the
same ADS-B technology.

2.2.2.6 Emergency Information Services

2.2.2.6.1    Data Link Alert (D-ALERT)
The D-ALERT service enables a Flight Crew to notify appropriate ground authorities
when the aircraft is in a state of emergency or in an abnormal situation.

The D-ALERT information is sent to the C-ATSU who determines which authorities
(e.g., fire/rescue, police, AOC) should receive the details of the message.
Appropriately-equipped aircraft may distribute this message to their AOC
simultaneously in order for coordination to take place with the C-ATSU.

The D-ALERT service consists of the following types of exchanges:
       Downlink aircraft emergency or abnormal situation indication
The D-ALERT service uses addressed communications.

2.2.2.6.2    Urgent Contact (URCO)
The Urgent Contact (URCO) service enables an ATSU to establish urgent voice or
data communications contact with a Flight Crew or for a Flight Crew to contact an
ATSU when other forms of communications have failed.

The URCO service consists of the following types of exchanges:
       Uplink or downlink of urgent voice or data contact message
The URCO service uses addressed and/or broadcast communications.

2.2.2.7 Delegated Separation Services

2.2.2.7.1    In-Trail Procedure (ITP)
The ITP service requires both the ACL and SURV services. The ITP service is
initiated by issuing an ACL instruction to one aircraft to perform a climb, descent, or
station-keep relative to a target aircraft. The aircraft performing the ITP instruction
receives the SURV data from the target aircraft and displays the position information
on the Cockpit Display of Traffic Information (CDTI). The Flight Crew receiving the
ITP instruction identifies the target aircraft using the CDTI and assumes separation
responsibility with the target aircraft during the procedure.


                                          35
                                  COCR Version 2.0


The ITP service consists of the following types of exchanges:
       SURV aircraft position and intent
       ITP ACL instruction(s)
The ITP service uses both addressed (ACL) and broadcast (SURV) communications.

2.2.2.7.2    Merging and Spacing (M&S)
The M&S service requires both the ACL and SURV services. The M&S service is
initiated by a Controller issuing an ACL instruction to one aircraft to perform a
merging and spacing manoeuvre relative to a target aircraft. The aircraft performing
the M&S instruction receives the SURV data from the target aircraft and displays
position information on the CDTI. The Flight Crew receiving the M&S instruction
assumes separation responsibility with the target aircraft during the procedure.

The M&S service consists of the following types of exchanges:
       SURV aircraft position and intent
       M&S ACL instruction(s)
The M&S service         uses    both   addressed   (ACL)   and   broadcast   (SURV)
communications.

2.2.2.7.3    Crossing and Passing (C&P)
The C&P service requires both the ACL and SURV services. The C&P service is
initiated by a Controller issuing an ACL instruction to one aircraft to perform a
crossing and passing manoeuvre relative to a target aircraft. The aircraft performing
the C&P instruction then receives the SURV data from the target aircraft and displays
the position information on the CDTI. The Flight Crew receiving the C&P instruction
assumes separation responsibility with the target aircraft during the procedure.

The C&P service consists of the following types of exchanges:
       SURV aircraft position and intent
       C&P ACL instruction(s)
The C&P service uses both addressed (ACL) and broadcast (SURV) communications.

2.2.2.7.4    Paired Approach (PAIRAPP)
The PAIRAPP service requires both the ACL and SURV services. The PAIRAPP
service is initiated by an ACL instruction to a pair of aircraft to perform a
simultaneous approach. Both aircraft performing the simultaneous approach
exchange SURV data and display position data on the CDTI. The Flight Crews
assume separation responsibility with the partner aircraft during the procedure.

Note: Very high SURV update rates may be required.

Typically, COTRAC agreements would bring aircraft to the point in their approaches
where minimal standard separation is reached. Upon initiation of PAIRAPP, the


                                           36
                                  COCR Version 2.0


COTRAC service would be terminated. PAIRAPP would then allow the participating
aircraft to reduce to and maintain spacing necessary to conduct closely-spaced
simultaneous parallel approaches to runways with as little as 750 feet spacing between
runway centrelines without requiring Flight Crews to visually acquire either the
runway or their partner aircraft.

The PAIRAPP service consists of the following types of exchanges:
       SURV broadcasts of aircraft positions and intent
       PAIRAPP ACL instructions
The PAIRAPP service uses both addressed (ACL) and broadcast (SURV)
communications.

2.2.2.8 Miscellaneous Services

2.2.2.8.1    Air-to-Air Self Separation (AIRSEP)
The Air-to-Air Self Separation (AIRSEP) service exchanges data between aircraft to
ensure separation in the AOA domain, without the aid of ground ATC support.
AIRSEP requires automated airborne algorithms that detect or estimate the probability
of conflicts with other flight trajectories, airspace, or weather restrictions along the
intended route of flight.

The AIRSEP service consists of the following air-air exchanges:
       Trajectory Intent Exchange: Automatic interrogation of the projected intent
       to a sufficient distance beyond a conflict point to determine the required
       encounter-specific separation.
       Conflict Negotiation: Machine-machine trajectory modification generated by
       on-board automation. Trajectories are exchanged until resolution is achieved
       or until a parameter time remaining to resolve the conflict is reached,
       whichever occurs first. The negotiated trajectory is provided to the Flight
       Crew for approval and execution.
       •    Resolution Accept/Confirmation: Response message ensuring positive
            confirmation of the negotiated trajectory.
The AIRSEP service uses addressed and/or broadcast communications.

2.2.2.8.2    Automatic Execution (A-EXEC)
The A-EXEC service provides an automated safety net to capture situations where
encounter-specific separation is being used and a non-conformance FLIPINT event
occurs with minimal time remaining to resolve the conflict. Subject to local
implementations, aircraft that support the A-EXEC service are separated based on
encounter-specific conditions.     When non-conformance occurs, triggering an
imminent loss of separation, the ground automation system generates and sends a
resolution to the aircraft for automatic execution without the Flight Crew or
Controller in the loop. Once an A-EXEC instruction has been issued and executed,
additional A-EXEC, ACL, COTRAC, or voice services may be used as required.



                                          37
                                  COCR Version 2.0


The A-EXEC service consists of the following types of exchanges:
       Uplink of clearance instruction
The A-EXEC service uses addressed communications.

Note: A-EXEC is only applicable on a very limited basis in critical situations.

The absence of a “human in-the-loop” during the execution of A-EXEC, results in
significant safety and security concerns.

2.3 Aeronautical Operational Control (AOC) Services
AOC is an important element of ATM and is needed for continued efficient operation
by airspace users. AOC services are concerned with the safety and regularity of flight
and as such are defined in Annex 10 of the ICAO Convention. AOC applications
involve voice and/or data communication between the aircraft and the AOC centre,
company, or operational staff at an airport.

Requirements for AOC voice, including communication with the airspace user
operations centres and between aircraft, will continue a downward trend as use of data
communication increases. However, AOC voice will continue to be required.

The bulk of AOC message traffic uses data communication. It is assumed that the
growth of air traffic, the increase in number of messages per aircraft, and the increase
in the size of a message will result in increased AOC data communications load.
There are two areas of communication that are anticipated to result in especially high
communication loads: communications at the gate and airborne real-time monitoring.

2.3.1 AOC Voice Services
There are two types of voice communications services. The first is an addressed
voice service that handles Flight Crew-Operations Centre communications. The
second is either a party-line or broadcast voice service that handles Flight Crew-Flight
Crew voice communications. The party-line/broadcast service is especially applicable
in oceanic and remote regions to aid in situational awareness.

2.3.2 AOC Data Services
This section contains descriptions of the AOC data communication services that are
expected to be in use during Phase 1 and Phase 2.

2.3.2.1 AOC Data Link Logon (AOCDLL)
The Flight Crew activates the data communication system and enters the required
flight identification information into the logon page in order for AOC to respond with
the correct information. The AOCDLL provides an indication to AOC that the Flight
Crew has arrived on-board the aircraft and are prepared to receive AOC generated
information in order to conduct the flight.




                                          38
                                  COCR Version 2.0


2.3.2.2 Out-Off-On-In (OOOI)
Movement Service messages including Out-Off-On-In (OOOI) report data are
automatically routed to the AOC Movement Control System. This service is a one-
way downlink from the aircraft to AOC to report significant points in the flight’s
progress.

2.3.2.3 Notice to Airmen (NOTAM)
The NOTAM service provides information to alert the Flight Crew in the event of the
following:
       Hazards such as air-shows and parachute jumps
       Closed runways
       Inoperable radio navigational aids
       Military exercises with resulting airspace restrictions
       Inoperable lights on tall obstructions
       Temporary erection of obstacles near airfields (e.g., cranes)
The Flight Crew activates this service.

2.3.2.4 Free Text (FREETEXT)
The FREETEXT service includes miscellaneous uplinks and downlinks via textual
messages between the cockpit and AOC or other ground based units. This service
does not include cockpit-to-cockpit exchanges.

2.3.2.5 Textual Weather Reports (WXTEXT)
The WXTEXT service is initiated by Flight Crew requests for airport weather
information. The WXTEXT service includes Meteorological Aerodrome Reports
(METARs) and Terminal Area Forecasts (TAFs). The AOC responds to Flight Crew
requests by delivering the requested weather information to the cockpit.

2.3.2.6 Position Report (POSRPT)
The POSRPT service includes automatic downlink of position during the climb,
cruise, and descent portions of the flight. The primary purpose of this service is
delivery of position reports at required waypoints for use in AOC tracking systems.
During all phases of flight, but principally En Route, the Flight Crew can also
manually initiate the POSRPT service for such things as in-range reporting.

2.3.2.7 Flight Status (FLTSTAT)
The FLTSTAT service includes, for example, malfunction reports including fault-
reporting codes that allow maintenance and spares to be pre-positioned at the parking
stand after landing. Fault reporting can be done manually or can be automatically
sent when triggered by an event.



                                            39
                                  COCR Version 2.0


2.3.2.8 Fuel Status (FUEL)
The FUEL service downlinks fuel status En Route and prior to landing. This service
allows ground services to dispatch refuelling capability promptly after landing. The
Flight Crew also reports the fuel status upon specific request from the AOC.

2.3.2.9 Gate and Connecting Flight Status (GATES)
The GATES service for passengers and Flight Crew includes manual and automatic
uplink of connecting flights, estimated time of departure (ETD), and gate assignments
before landing. Information about rebooking may also be included in case of late
arrival or cancelled flights.

2.3.2.10 Engine Performance Reports (ENGINE)
The ENGINE service is used to downlink aircraft condition monitoring system
(engine and systems) reports in real time, automatically and on request. This is
usually done in the En Route phase.

2.3.2.11 Maintenance Problem Resolution (MAINTPR)
Using the MAINTPR service, maintenance personnel and a Flight Crew are able to
discuss and correct technical problems while the aircraft is still airborne. Although
voice is customarily used for the discussion of the problem, this service may be used
to provide the instructions for problem resolution as a text message between
maintenance personnel and Flight Crew.

2.3.2.12 Flight Plan Data (FLTPLAN)
The FLTPLAN service provides the operators with the ability to request and receive
the AOC-developed flight plan for comparison to that assigned by ATC and for
loading into avionics. AOC flight plans have more information than flight plans filed
with ATS.

2.3.2.13 Load Sheet Request/Transfer (LOADSHT)
Upon downlink request, the Load Sheet Control System uplinks planned load sheet
and cargo documentation in the LOADSHT service. A number of data calculations
relating to aircraft loading, takeoff, and landing are required to enhance safety and/or
meet aviation regulations. The load sheet includes weight and balance information
which insures resultant weights and centre of gravity are within the performance
limits of the aircraft. A preliminary load sheet is transferred right after an AOCDLL.
A final load sheet is typically transferred just before pushback, but can be transmitted
as late as just before takeoff. The load sheet will also include a passenger manifest &
fuel status.

A takeoff data calculation (TODC) is provided for the minimum takeoff speeds and
flap settings. The calculation takes into account weights, aircraft technical parameters
(e.g., thrust), and environmental parameters (e.g., wind, temperature, density altitude
and runway length or conditions). If the TODC is sent before the final load sheet or if
the planned takeoff runway is changed, an updated TODC may be required.


                                          40
                                 COCR Version 2.0


A landing data calculation (LDC) is a calculation similar to the TODC. The LDC is
transmitted towards the end of the flight in the TMA domain.

2.3.2.14 Flight Log Transfer (FLTLOG)
The FLTLOG service is used to track the aircraft’s flight times, departure and
destination information, etc. Flight log information may be manually requested by the
AOC or automatically downlinked.

2.3.2.15 Real Time Maintenance Information (MAINTRT)
The MAINTRT service allows aircraft parameters to be sent to the airline
maintenance base in real-time to monitor the operational status of the aircraft and to
troubleshoot problems identified during the flight. Information could include engine
data, airframe systems, etc. This service allows information to be obtained more
quickly than the normal maintenance data acquisition via on-board recorders. It is
typically event driven, triggering a flow of information until resolution is achieved.
The maintenance personnel may request other parameters to be downlinked in
addition to those triggered by the event.

2.3.2.16 Graphical Weather Information (WXGRAPH)
The WXGRAPH service sends weather information to the aircraft in a form that is
suitable for displaying graphically on displays in the cockpit (e.g., vector graphics).
This service provides advisory information which supplements or replaces the textual
weather information available in current AOC services.              Graphical weather
information is expected to be more strategic in nature and will supplement on-board
tactical weather radar which has inherent range and display limitations.

2.3.2.17 Real-time Weather Reports for Met Office (WXRT)
With the WXRT service, information derived by the aircraft on the environment in
which it is flying (e.g., wind speed and direction, temperature) can be sent
automatically in real-time to weather forecasting agencies to help improve
predictions.

2.3.2.18 Technical Log Book Update (TECHLOG)
The TECHLOG service allows the Flight Crew to complete the aircraft’s technical log
electronically and send the updated log to the maintenance base. Information
regarding the technical status, physical condition, and trouble reports of the aircraft
can therefore be obtained much more quickly so that any remedial action can be taken
at an early stage.

2.3.2.19 Cabin Log Book Transfer (CABINLOG)
The CABINLOG service allows the cabin crew to complete the aircraft’s cabin-
equipment log electronically and send the updated log to the AOC. Information
regarding the status of the cabin equipment can therefore be obtained much more
quickly so that any remedial action can be taken at an early stage.



                                          41
                                 COCR Version 2.0


2.3.2.20 Update Electronic Library (UPLIB)
The Electronic Library will replace many of the paper documents currently required
to be carried in the cockpit (e.g., Aircraft Manual, Standard Instrument Departures
(SIDs), Standard Terminal Arrival Routes (STARs), and Airspace Charts). The
UPLIB service enables this information to be updated electronically either by request
or automatically. The transmitted information will be used to update various avionic
systems (e.g., an Electronic Flight Bag [EFB] device). As such, this service carries
safety-related information used for navigational purposes by the Flight Crew/Aircraft.

2.3.2.21 Software Loading (SWLOAD)
The SWLOAD service allows new versions of software to be uploaded to non-safety
related aircraft systems whilst the aircraft is at the gate.




                                         42
                                 COCR Version 2.0



3 OPERATIONAL CONCEPT, ENVIRONMENT, AND
  SCENARIOS FOR COMMUNICATIONS
3.1 Introduction
This section describes the ATM operational concepts and operating environment
considered in the COCR. The ATM concepts will increase the efficiency of air traffic
management, thereby allowing air traffic growth. Operational service capabilities are
implemented in phases to support the operational concepts. Each of these phases
increases airspace capacity. For each phase, a typical scenario is provided to
demonstrate how voice and data services would be used.

The following information applies to Section 3.
       The terms Executive, Planning, Tower Runway, Ground, and Clearance/Ramp
       Controllers are used to generically differentiate Controller roles and typically
       represent Controllers working a sector or individual positions in an airport
       tower. Locally, these Controllers may be referred to by various names, e.g.,
       Surveillance, R-Side, or Radar for Executive Controller; Sector Planner, D-
       Side, Data, or Co-ordinator for Planning Controller; or Local or Flight Data
       for Tower positions.
       The information contained in the following scenarios is based on regions of
       the world with high-density airspace. Regions of the world with lower density
       of air traffic may choose to continue with voice-based procedures but could
       benefit from transition to a more data communications-based operation for
       global harmonisation and aircraft procedural consistency.
       When data communications is used, voice-based procedures may be used as an
       alternative form of communication depending on the dynamics of the situation.
       The services (including acronyms) referred to in the following sections are
       defined and described in the acronym list and detailed in Section 2 based on
       the EUROCONTROL Operational Requirements for Air/Ground Co-operative
       Air Traffic Services [3] plus other services developed from additional sources.
       The concept is then extrapolated to reflect the future scenarios associated with
       the Phase 1 and 2 timeframes beyond that which the reference documents
       provide.
       The services listed in the following scenarios are not all-inclusive of the
       services listed in Section 2. An acronym in bold type indicates that a message
       transaction process occurs using the services defined in Section 2.

3.2 Phase 1 Concept
To support the anticipated growth of aircraft traffic, all ATM stakeholders (e.g.,
commercial aviation, general aviation, military users, neighbouring Air Navigation
Service Providers (ANSPs), regulators, airport operators, and other governing entities)
must work together in a collaborative manner to plan and execute their aviation
operations. All stakeholders may participate in, and benefit from, the advantages of
using a wide network of information. As part of this network of information, the



                                          43
                                 COCR Version 2.0


operations planning process aims to maintain a continuous balance between demand
and capacity and to identify system constraints. Stakeholders have access to the
planning process through a common network; they are able to retrieve information to
be used for their tailored purposes or make a query to identify possible constraints
and, in a collaborative manner, use the information to negotiate and develop
consensus on possible opportunities, plan new operations or mitigate potential
constraints.

The ATM system is continuously evolving. The focus of development and change
until this point in time has been on the planning process, where communication and
information exchange among ATM stakeholders have become increasingly more
important. Decision-making processes have become more collaborative as common
situational awareness among the ATM stakeholders has developed. The roles and
responsibilities of the ATM stakeholders are evolving from controlling to managing
traffic. The paradigm change from “management by intervention” to “management
by planning and intervention by exception” begins in the Phase 1 ATM environment.

The most significant evolution completed in this period is flight planning through the
implementation of a seamless layered planning process. Basic layered planning
existed earlier, but by the time of Phase 1 it has started to evolve into a continuous
planning process. Under Phase 1, the layered planning process generally satisfies an
agreed and stable demand and capacity balance. This is accomplished through
demand and capacity determination, active demand and capacity management, and re-
planning for optimisation. These tasks continue across all layers of planning and are
not restrained by the time constraints of the individual layer.

The layered planning process will not be described in detail as the focus of this
document is on the aspects or capabilities that directly impact the demand on the
digital aeronautical communication system (air-ground and air-air communications).
However, application of the layered planning process will generate the following
benefits:
       An improved picture of the predicted traffic situation enabling all ATM
       stakeholders to analyse and develop their business cases
       The active involvement of all ATM stakeholders in the decision-making
       process also supporting and facilitating the use of company planning and
       company decision support tools
       A collaborative decision-making process encompassing the ATM stakeholders
       concerned
       Communication of real-time events enabling ATM stakeholders to take
       advantage of changing conditions in real time, thus helping them to achieve
       their preferences
The Planning Controller represents the lowest planning level within the layered
planning process. The Planning Controller’s primary task is to plan and establish a
conflict-free and efficient traffic flow within his/her area of responsibility. Because
of his/her extended geographical and time-related planning horizon, he/she is able to
act early on expected complexity and conflicts and look for efficient solutions.
Furthermore, he/she is able to react more efficiently and flexibly to user requests,



                                          44
                                  COCR Version 2.0


such as direct routings, prioritisation of individual flights, or special support for on-
time arrivals.

A gradual shift in emphasis from an Air Traffic Control (ATC) environment defined
by tactical interventions towards an operating environment based on reliable planning
is beginning. As a consequence, the role of Controllers is evolving into more of a
monitoring and managerial role in certain areas. Examples of this change are seen in
the beginning steps of pre-negotiated operations, where the Flight Crew executes a
previously agreed-upon trajectory agreement. The Controller, however, retains the
responsibility for separation or co-ordinates and issues instructions where
responsibility is delegated to the Flight Crew for a specific procedure of limited
duration (e.g., spacing). Consequently, the Flight Crew’s role has begun to change
and now includes assumption of these responsibilities previously residing with the
Controller. All this is supported by new or enhanced functions of the ATM system
encompassing air and ground applications.

Operational changes are also being implemented for the management of ground
movements.       They are optimised to provide maximum use of the ground
infrastructure, even in adverse weather conditions, by using new ATM system
capabilities. The airspace structure is beginning dynamic adjustment of control sector
boundaries according to demand, allowing for limited implementation of user-
preferred trajectories.

All of the changes identified above, technical and operational, will have an impact on
the business models of ATM stakeholders. The ATM stakeholders must cope with
changing requirements on human skills, new and harmonised operational procedures
that cross ATM stakeholder business boundaries, changing requirements on their
systems, and newly implemented rules and regulations catering, for example, to
environmental issues.

3.2.1 Phase 1 Environmental Characteristics and Conditions and Aircraft
      Performance Characteristics
This section describes the Phase 1 environmental characteristics and conditions.
Table 3-1 provides the Phase 1 airspace characteristics categorised by domain. Table
3-2 provides the Phase 1 environmental conditions.

Note: The Phase 1 environmental characteristics for APT, TMA, and ENR are based
on [2]. The Phase 1 environmental conditions are copied from [2].




                                           45
                                                    COCR Version 2.0


                                  APT                         TMA                      ENR                      ORP

Communication            Voice is primary means     Voice is primary means   Voice is primary means   Data is primary means
capability and           of communication.          of communication. Data   of communication. Data   of communication.
performance              Data is used for non-      is used for non-time-    is used for non-time-    Indirect voice service
                         time-critical or routine   critical or routine      critical or routine      used for non-routine and
                         communications             communications           communications           emergency
                                                                                                      communications

Navigation capability    Precision Landing          Area Navigation          RNAV/RNP 4               ± 300 ft altimeter,
and performance          System                     (RNAV)/RNP 1                                      RVSM, Minimum
                                                                             Reduced Vertical         Navigation Performance
                         Visual separation                                   Separation Minima        Specification (MNPS),
                                                                             (RVSM)                   Inertial ±2 NM/hour
                                                                                                      drift rate, RNAV/RNP
                                                                                                      10, RNAV/RNP 4

Surveillance capability Visual and voice            Aircraft Collision       ACAS                     ACAS, Time/speed-
and performance         communication               Avoidance System                                  based verification,
                                                    (ACAS)                   Surveillance service     Distance-based
                         Surveillance                                                                 verification, Lateral
                         Monitoring                 Surveillance service                              deviation monitor
                                                                                                      ADS-C

Separation               Longitudinal 2 or 3        2.5-5 NM                 5 NM                     Lateral: 60 NM
(Horizontal)             minutes or wake                                                              (MNPS), 100 NM, 50
                         turbulence criteria,                                                         NM, or 30 NM
                         whichever is greater                                                         Longitudinal: is time-
                                                                                                      based: 5/10/15 min, or
                                                                                                      Distance-based: 50 NM
                                                                                                      or 30 NM

Separation               Not available (N/A)        1000 ft                  1000 ft                  1000 ft
(Vertical)                                                                                            2000 ft
                                                                             2000 ft
                                                                                                      RVSM
                                                                             RVSM

Traffic complexity       Complex with visual        Complex route structure RNAV complex route        Composite separation,
                         guidance                   with complex arrival and structure                parallel tracks, crossing
                                                    departure routes                                  tracks


                        Table 3-1: Phase 1 Airspace Environmental Characteristics



 Reference           Environmental Condition
 C-ENV-1             In airspace where ATC data services are used, very high frequency (VHF) and/or ultra
                     high frequency (UHF) voice services, as required by the operating rule, are available.
 C-ENV-2             A controlled flight is under the control of only one controller at a time.
 C-ENV-3             Surveillance enables the controller to detect incorrect aircraft movement.
 C-ENV-4             Flight plan submission and processing, per ICAO 4444.
 C-ENV-5             Provision and use of data communications services, per ICAO 4444.
 C-ENV-6             The airspace to which the clearance pertains is protected until the controller receives
                     the response.
 C-ENV-7             The users are properly trained to use data communications.
 C-ENV-8             Where a D-ATIS supplements the existing availability of Voice-ATIS, the information
                     shall be identical in both content and format to the applicable Voice-ATIS broadcast.
 C-ENV-9             The flight crew executes received instructions/clearances and updates onboard avionics
                     in a timely manner.

                          Table 3-2: Phase 1 Services Environmental Conditions



                                                               46
                                     COCR Version 2.0


Table 3-3 provides the Phase 1 aircraft performance characteristics for each domain.
Phase 1 aircraft performance assumptions and characteristics include the following:
       Space and Special-Use Vehicles are outside the scope of the FRS.
       Aircraft travelling over land masses (e.g., surface, TMA, En Route) will be
       limited to air speeds below Mach 1 (speed of sound) to prevent sonic booms
       (e.g., 0.95 mach).
       Air-Air speeds are based on the closing speed of two jet aircraft in the same
       wind environment.

           Parameter                   APT         TMA          ENR/ORP
           Max Gndspeed (Knots
           True Airspeed [KTAS])       160         360          850
           Max Airspeed (KTAS)         160         250          600
           Max Air-Air (KTAS)          N/A         500          1200
                                 2
           Max Acceleration (m/s )     5           50           50

                 Table 3-3: Phase 1 Aircraft Performance Characteristics


3.3 Phase 1 Scenario
As noted earlier, an acronym in bold type indicates that a message transaction process
occurs using a service defined in Section 2.

3.3.1 Pre-Departure Phase in the APT Domain
The aircraft operator provides gate/stand information, aircraft registration/flight
identification, and estimated off-block time to other users (e.g., Airport and ATC) via
the ground-ground communications system. The Flight Crew prepares the aircraft for
the flight and in particular provides the necessary inputs and checks in the Flight
Management System (FMS). They activate the data communications system, which
initiates a network connection establishment between the aircraft and ground systems,
and send an AOC Data Link Logon (AOCDLL) to AOC. Aircraft and ground
systems may exchange network keep-alive messages during the flight when there is
no traffic for a period of time. Logon and contact with the ATSU automation system
is performed by the Data Link Logon (DLL) service. The DLL contains the address
and application data required to enable addressed data communications services. The
Flight Crew requests the Flight Plan (FLTPLAN) from AOC and enters the AOC-
provided flight plan data into the FMS. The Flight Crew consults relevant
aeronautical information (e.g., Planning Information Bulletins, NOTAMs, and
Aeronautical Information Charts) concerning the flight. Real-time information on the
flight’s departure is now available in the ATSU automation system.

The Flight Crew initiates a request for a Data Link Operational Terminal Information
Service (D-OTIS) contract for the departure airfield. The Flight Information Service
(FIS) system response provides all relevant information for the weather, Automatic
Terminal Information Service (ATIS), and field conditions, plus the local NOTAMS.



                                             47
                                 COCR Version 2.0


The Flight Crew requests a departure clearance from the system via the Departure
Clearance (DCL) service. The tower sequencing system integrates the flight into an
overall arrival/departure sequence, taking into account any Air Traffic Flow
Management (ATFM) constraints, and assigns the appropriate runway for take-off.
The Controller, supported by available automation, provides the DCL response
including an updated calculated take-off time (CTOT) via data communications to the
Flight Crew. The DCL response is checked against what was provided from AOC for
consistency, and any changes are updated in the FMS. The ATSU automation
updates the integrated Arrival/Departure Manager system (AMAN/DMAN) and ATC
centres along the route of flight with the CTOT. A suitable time after delivery of the
DCL response, the ATSU performs a Flight Plan Consistency (FLIPCY) check of the
FMS flight plan data. Should an aircraft be capable of performing the FLIPINT
service, this could be used to satisfy the consistency check.

In low visibility conditions, the Flight Crew may also use the Data Link Runway
Visual Range (D-RVR) service to request RVR information for the departure and the
destination airports. For data-link equipped aircraft preparing to taxi, the current
graphical picture of the ground operational environment is uplinked and loaded using
the Data Link Surface Information Guidance (D-SIG) Service.

The Loadsheet Request (LOADSHT) is sent to AOC. The Loadsheet Response
(LOADSHT) with the “dangerous goods notification information” and the last minute
changes to the weight and balance of the aircraft are sent by the AOC and are
automatically loaded into the avionics. Some of this data will remain available for the
Data Link Alert (D-ALERT) service throughout the flight, should an emergency
occur. During this pre-flight phase, the Data Link Flight Update (D-FLUP) service is
accessed to see if there are any delays/constraints anticipated to the preparations for
the flight. The Flight Crew specifies preferences that should be considered by the
Controllers using the Pilot Preferences Downlink (PPD) service.

The Flight Crew requests a “Start Up and Push Back Clearance” via the Data Link
Taxi (D-TAXI) Service. The ATSU sequencing system calculates the planned taxiing
time and, after comparison with the issued CTOT, issues the D-TAXI response. For
appropriately equipped aircraft, the D-TAXI route is superimposed over the D-SIG
information previously received. The Flight Crew pushes back and starts up the
engines in accordance with Airport procedures. The push back generates an Out-Off-
On-In (OOOI) message to AOC advising that the flight has left the gate/stand.

As the aircraft pushes back, the Surveillance (SURV) service is activated and
continues for the duration of the flight. The Advanced Surface Movement Guidance
and Control System (A-SMGCS) picks up the surveillance message and associates the
aircraft with the FDPS flight plan. The ATSU’s sequencing tool updates the times for
the overall arrival/departure sequence. For short-haul flights (<250 NM), the updated
information is provided to the integrated AMAN at the arrival airport.

The conflict probe system of the first ATSU analyses any potential conflicts caused
by the proposed trajectory of the departing flight and informs the Planning Controller
concerned with the flight. The Planning Controller uses the information to update the
planning process.




                                          48
                                  COCR Version 2.0


3.3.2 Departure Taxi in the APT Domain
The Flight Crew requests the D-TAXI clearance from the tower ground Controller.
The tower ground Controller issues the D-TAXI response. The Flight Crew
manoeuvres the aircraft according to the taxiing instructions. The tower ground
Controller monitors the taxiing of the aircraft assisted by A-SMGCS and intervenes if
required.

The ATSU automation system generates a transfer message for the tower ground
Controller that control will be passed to the tower runway Controller frequency
automatically via ATC Communication Management (ACM) on reaching the
handover point. The tower runway Controller issues the “Line Up and Wait
Clearance” by voice to the Flight Crew in accordance with the traffic situation. The
tower runway Controller issues the “Take Off Clearance” via voice to the Flight Crew
in accordance with the traffic situation.

The ATSU automation system forwards the DLL information via ground-ground
communications to subsequent ATSUs so that data communications with respective
downstream Controllers can be conducted.

The Flight Crew commences the take off run. The ATSU automation system detects
that the aircraft is airborne and disseminates that information to the flow manager,
neighbouring sectors’ and centres’ Planning Controllers, and air defence and makes it
available for other users. An OOOI message is sent to AOC that the aircraft is
airborne.

The ATSU automation system generates a transfer message for the tower runway
Controller and uses the ACM service to provide the frequency to contact the next
sector Executive Controller to the aircraft via data communications.

3.3.3 Departure in the TMA Domain
When the aircraft is airborne, the Flight Crew contacts the first sector Executive
Controller using voice. The ATSU automation system determines the exit conditions
from the first sector. The conflict probe checks to see if the entry conditions into the
next downstream sector are conflict free and forwards coordination information to the
downstream sector.

The Executive Controller issues instructions via the ATC Clearances (ACL) service
(via voice or data, depending on the tactical nature of the situation) to the Flight Crew
to achieve the exit conditions to enter the next sector and provides this clearance
information to the ATSU automation system. The conflict probe provides the
Planning Controller and Executive Controller with information about potential
interactions with other aircraft or airspace for up to 30 minutes from present position.
The Controller team takes necessary action to alleviate these conflicts using the
appropriate services. The Flight Crew flies the aircraft according to the instructions
given. The System Access Parameters (SAP) service is initiated by the ATSU
automation system, and the downlinked information is provided to the various ground
components (e.g., for smoothing of trackers) or on request for display of parameters to
Controllers. The ATSU automation system monitors the aircraft behaviour in
accordance with the given clearances. The tracking system issues warnings to the


                                           49
                                  COCR Version 2.0


Executive Controller in case of non-compliance. The Executive Controller intervenes
if the situation requires action. The tracking system uses the ADS and radar data to
monitor whether the aircraft performance is in accordance with the ground-predicted
trajectory and updates the trajectory where necessary.

The Executive Controller transfers control of the aircraft to the next sector Executive
Controller. The data communications processing system provides the next frequency
to the Flight Crew via the ACM service and transfers the data communications
capability management to the next sector/ATSU. A new network connection is
established between the aircraft and an En Route domain ground system before the
connection with the departure TMA domain ground system is released.

3.3.4 Operations in the ENR and ORP Domains
Note: In Phase 1, a typical continental flight will pass through four En Route
facilities. Long haul flights will traverse numerous En Route facilities. The number
of sectors traversed within each En Route facility is typically two. The exchanges that
occur from a communications stand-point are the same in each En Route facility, so
the following description does not specify inter- vs. intra-facility transfers or ATSU
automation system events unless necessary for clarity of the scenario.

The ATSU automation system confirms/sets the exit/entry conditions with the sectors
in the En Route phase. At each entry into a subsequent ATSU, FLIPCY is performed
to verify the FMS route against what is held in the ATSU FDPS. The ATSU
automation system establishes a Flight Plan Intent (FLIPINT) contract (e.g., periodic
or event) with equipped aircraft while in each ATSU’s area of jurisdiction to ensure
consistency between on-board routes against ATSU FDPS routing. The Executive
Controller decides and performs, or has the Planning Controller perform, ACL as
necessary and initiates handovers to the next sector/ATSU. The ATSU automation
system supports handover by communicating the event to the Flight Crew and the
downstream sector/ATSU via ACM. The Flight Crew contacts or monitors the
frequency of the receiving sector Executive Controller when the handover is
performed. Meanwhile, the aircraft reaches top of climb and generates an Engine
Performance Report (ENGINE) to the AOC. The Controller team accesses the PPD
information from the aircraft to determine if any of the Flight Crew preferences affect
or could improve the planned trajectory. The Flight Crew initiates an ACL to request
a modification to the current trajectory. The Planning Controller assesses the request
against the conflict probe. If no conflicts are found, and after informing the Executive
Controller, the response is sent via ACL. An aircraft system notices a minor fault in
one of the cross bleed valves that generates a Flight Status (FLTSTAT) message to
AOC for maintenance action upon arrival.

During this phase of flight, the Flight Crew initiates the request for a Downstream
Clearance (DSC) with the Downstream-ATSU (D-ATSU) for the Oceanic/Remote
portion of the flight. The D-ATSU receives this request and determines whether the
requested profile can be approved. In order to issue the clearance for the
Oceanic/Remote portion of the flight, a change to the aircraft’s current trajectory is
necessary. The Planning Controller in the D-ATSU co-ordinates the changed entry
point with the Controlling-ATSU (C-ATSU) Planning Controller. The result is
provided to the D-ATSU Planning Controller for authorisation, and the DSC response



                                          50
                                  COCR Version 2.0


is sent to the aircraft. The required change to the current trajectory to comply with the
DSC is co-ordinated with the Executive Controller in the C-ATSU, is then sent to the
aircraft via ACL, and an update is provided to the flight data processing system.

Prior to entry into the oceanic/remote domain, a weather report is provided to the
Planning Controller indicating that moderate to severe turbulence may be expected
over this portion of the flight. This information is sent to the aircraft via the Data
Link Significant Meteorological Information (D-SIGMET) service. A new network
connection is established between the aircraft and the Oceanic/Remote domain ground
system before the connection with the En Route domain ground system is released.

The aircraft progresses through the Oceanic/Remote domain. The Flight Crew
requests a more efficient altitude via ACL. Due to traffic, the ACL response includes
the requirement to execute an In-Trail Procedure (ITP) using SURV information on
the flight deck display between a pair of equipped aircraft. The progress of the flight
is monitored by FLIPINT. Any events that cause the aircraft to be in non-
compliance with the planned trajectory are communicated with appropriate alerting to
the Executive Controller. Before the aircraft returns to the En Route domain, a new
network connection is established between the aircraft and the En Route domain
ground system before the connection with the Oceanic/Remote domain ground system
is released.

The ATSU automation system recognises the position of the aircraft approaching the
En Route domain and sets the exit conditions (target time) taking into account
restrictions at the destination airport (if applicable in this sector). The AMAN
calculated time is sent to the aircraft via the Arrival Manager Information Delivery
(ARMAND) service and any modifications to the aircraft’s trajectory are
communicated via ACL. The aircraft position causes a Fuel Status (FUEL) message
to be sent to AOC.

The conflict probe system provides the Planning Controller and the Executive
Controller information about potential conflicts with other aircraft within a specified
time (e.g., the next 15 minutes).

The Planning Controller analyses interactions with other aircraft that are reported to
him/her by the conflict probe system. The Planning Controller probes “what-if”
solutions for interactions. The conflict probe system may offer alternatives to the
existing route, the Planning Controller assesses these alternatives, and the alternatives
are provided via the Dynamic Route Availability (DYNAV) service for Flight Crew
assessment. The Planning Controller enters the Flight Crew-selected alternative and
updates the flight trajectory in the ATSU automation system. The Executive
Controller is notified about the required change to the trajectory of the aircraft and
issues the ACL instructions to the Flight Crew to achieve exit conditions to enter the
next sector.

The Planning Controller, in coordination with the Executive Controller, occasionally
issues instructions by data communications to the Flight Crew via ACL for cases
where a manoeuvre is planned at a later stage (e.g., >2 minutes from current flight
position). Otherwise, the Executive Controller provides instructions via ACL (voice
or data, as determined by the tactical nature of the situation). The Flight Crew flies
the aircraft according to the instructions given. The ATSU automation system


                                           51
                                   COCR Version 2.0


recognises the aircraft’s position relative to exiting the ATSU, compiles a Data Link
Operational En Route Information Service (D-ORIS) report specific to the remaining
portion of the area to be over-flown, and sends it to the aircraft.

The ATSU automation system uses the SURV and radar information to monitor that
the aircraft behaviour is in conformance with the given clearances and, in case of non-
conformance, issues warnings to the Executive Controller who intervenes via voice or
data if a situation requires action.

The Executive Controller initiates a transfer of the aircraft to the next sector. The data
communications processing system provides the next frequency to the Flight Crew via
ACM and transfers the air-ground data communications services to the next sector.

The AMAN system notifies the Planning Controller and the Executive Controller
about Top of Descent (TOD) at a time parameter prior to the TOD position. The
conflict probe indicates a conflict will occur if the aircraft is to comply with the TOD
calculation. A Merging and Spacing (M&S) operation is required to mitigate the
conflict. As the Aircraft reaches the TOD position, an ACL instruction containing
M&S instructions is issued to implement the needed trajectory. An ARMAND is
initiated containing the Standard Terminal Arrival Route (STAR) allocation, runway
for landing, and AMAN constraints.

Prior to entry into the arrival TMA domain, a new network connection is established
between the aircraft system and the arrival TMA domain ground system before the
connection with the En Route domain ground system is released.

3.3.5 Arrival in the TMA Domain
The system updates AMAN with changes to the arrival sequence. AMAN calculates
constraints by taking into account the actual traffic situation and makes the
information (time to lose/gain or hold) available to the concerned Planning Controller
and Executive Controllers in upstream sectors/ATSUs. If required, the conflict probe
system calculates a conflict-free alternative trajectory for the flight to comply with the
AMAN constraints. The Planning Controller of the receiving sector checks the PPD
service information to see if the conflict probe system-provided trajectory could be
improved with these preferences. The Planning Controller accepts the proposal and
co-ordinates the sending of the ACL instruction with the Executive Controller.

Based on the equipage and Flight Crew qualification information contained in the
flight plan and data obtained via SAP and PPD, the Executive Controller determines
which aircraft may execute a spacing application and issues M&S clearances to those
aircraft via ACL.

At this time, the Executive Controller determines that the voice communication
frequency in use has been blocked. In order to address this concern and free the voice
channel for communications, the Planning Controller initiates an uplink of the ATC
Microphone Check (AMC) service to all aircraft with which communication is
required. Within moments, the blockage of the frequency is resolved, and the
Executive Controller returns to voice communications for tactical instructions as
necessary.



                                           52
                                 COCR Version 2.0


The flight information system provides requested Data Link Automatic Terminal
Information Service (D-ATIS) information to the aircraft. The Aircraft Operator
informs the Flight Crew via data communications and informs the Tower Ground
Controller via ground-ground communications about stand/gate allocation.

The Executive Controller instructs the Flight Crew to descend. The FMS flies the
aircraft according to the given instructions to the Initial Approach Fix (IAF) and
generates a final Fuel Status (FUEL) report to AOC for refuelling planning. The
tracking system uses SURV and radar data to monitor that the aircraft behaviour is in
accordance with the given clearances and issues warnings to the Executive Controller
in case of non-compliance. The Executive Controller can intervene via voice if a
situation requires immediate action. The ATSU automation generates a D-SIG of the
arrival airport surface.

The Executive Controller issues instructions to the Flight Crew to follow the
calculated profile for final approach via ACL. The Executive Controller instructs the
Flight Crew to monitor the Tower Runway Controller via ACM.

Prior to entry into the Airport domain, a new network connection is established
between the aircraft system and the Airport domain ground system before the
connection with the TMA domain ground system is released.

3.3.6 Arrival in the APT Domain
The Tower Runway Controller monitors the traffic situation and intervenes if
required. The Tower Runway Controller issues the “Landing Clearance” to the Flight
Crew via voice. The Tower System provides a recommended D-TAXI runway exit
and the taxi-in route plan to the Tower Runway Controller. The Tower Runway
Controller issues the D-TAXI instructions to the Flight Crew via ACL, which is
overlaid on the D-SIG received prior to the final approach.

The Flight Crew lands the aircraft. The avionics detects touch down and disseminates
this OOOI information to the AOC. The common network system makes this
information available to other users. The A-SMGCS informs the Tower Runway
Controller about the aircraft vacating the runway. The Tower Runway Controller
instructs the Flight Crew to contact the Tower Ground Controller via ACM using
voice or data whichever is more appropriate for the prevailing circumstances.

3.3.7 Arrival Taxi in the APT Domain
The A-SMGCS uses SURV and radar data to notify the Tower Ground Controller of
the arrival sequence of the aircraft. The Tower Ground Controller uses the D-TAXI
information to verify the aircraft’s assigned route from the landing runway nominated
exit point to the gate/stand.

The Flight Crew contacts the Tower Ground Controller. The Tower Ground
Controller clears the Flight Crew to follow the D-TAXI route plan. The Flight Crew
manoeuvres the aircraft according to the instructions. The Tower Ground Controller
monitors the traffic situation and intervenes if required. A-SMGCS calculates the
target taxi-in period in real-time and uses a combination of SURV and radar
information to monitor the traffic situation for the detection of potentially hazardous


                                          53
                                  COCR Version 2.0


situations (e.g., conflict between aircraft, service vehicles, or obstacles) and issues
warnings to the Tower Ground Controller as required.

When the aircraft arrives at the gate/stand, the aircraft sends an OOOI to the AOC
who makes the information available for other users. AOC responds to the OOOI
message with a Flight Log Transfer (FLTLOG) message to inform the crew of the
next flight assignment. Data associated with the performance of the aircraft during
flight and maintenance information are sent to the airline. The network connection
between the aircraft and ground system is terminated.

3.4 Phase 2 Concept
The ATM system has been evolving constantly since introduction of Phase 1. All
ATM stakeholders are fully participating in the Layered Planning Process, and the use
of Collaborative Decision-Making (CDM) Processes is routine and commonplace.
This has improved and widened the database for situational awareness and
consequently makes the CDM Process faster and decreases uncertainty in decision-
making.

The adherence to the concept of Layered Planning and the philosophy of CDM has
driven the development of homogeneous procedures and the integration of systems
and services for exchange of information. The integration has evolved over time from
simple standardisation of interfaces in the beginning, via local “islands of integration”
(e.g., at aerodromes), to a system-wide integration including air and ground elements
as well as planning and executive levels.

In Phase 2, the organisation of the airspace is now either Managed or Unmanaged.
The composition of Managed Airspace is structured routes surrounding arrival and
departure airspace and airspace where user preferred trajectories are provided within
given constraints.    Unmanaged Airspace includes designated airspace where
autonomous operations are conducted and airspace where ATS is not provided; this is
illustrated in Figure 3-1. The degrees of freedom in flight planning and flight
execution are governed by traffic density and level of equipage.

All traffic within Managed Airspace is known to the ATSU(s) involved. In
Unmanaged Airspace, the ATSU may or may not be aware of the aircraft operations
depending on the ground system architecture. However, as depicted in Figure 3-1, the
airspace surrounding autonomous operations areas is managed and therefore the
ATSU has knowledge of what aircraft entered or departed that airspace, but there is
no ATC service being provided.

The level of service offered by the ATSU corresponds to the mode of operations in
the different parts of the airspace. From a communications perspective, there is still a
need for a communications buffer to exist on the managed/unmanaged airspace
boundary in order for aircraft within managed airspace to be provided with separation
assurance.




                                           54
                                              COCR Version 2.0


                                                  Unmanaged                      Communications
                                                                                   Buffer Zone
                                            Autonomous Operations


                                                                          En Route Managed
                                                                           4D Trajectory, User Pref.
                                                                           Routes, A - A Sep.


                TMA Managed
              4D Trajectory, Route Based,
              A - A Sep., & Legacy Ops


                                                   Airport
   Communications                                                               Communications
     Buffer Zone                                  Managed                         Buffer Zone

                                                                              Unmanaged
      Unmanaged


                              Figure 3-1: Phase 2 Airspace Organisation

In Phase 2, the integration of air-ground systems has evolved to an extent enabling
common use of up-to-date information in a seamless and economical way. The
information used in integrated systems comprises data from various sources, be it in
the air or on the ground (e.g., FMS, AMAN), of different natures (e.g., intent data,
forecast data), and of different urgency and priority (e.g., emergency communication,
planning information). Common rules and standards are in place for the use of
integrated systems and for the treatment of information and data. As communication
and information exchanges between ATM stakeholders became more important,
decision-making processes became collaborative as common situational awareness of
the ATM stakeholders developed, and the roles and responsibilities evolved. The
route based airspace design has predominantly been eliminated, replaced by spacing
and sequencing applications. The size of Autonomous Operation areas has continued
to increase. This paradigm change has defined the Phase 2 ATM environment.

The use of trajectory negotiations has become the norm. The evolution of Common
Trajectory Coordination (COTRAC) has taken place, helped by the reorganisation of
airspace and the emergence of avionics that allow the creation of 4-D trajectories,
unrestricted by the number of points needed for their definition.

The implementation of the correct mix of services described in Section 2, along with
supporting automation systems, has allowed an increase in the number of aircraft
monitored by a given Controller team. Sector boundaries are now routinely changed
to accommodate the division of labour amongst Controllers as traffic/weather
conditions warrant. The communications resources associated with the airspace are
all network-based and are reassigned as needed to provide coverage for the new sector
layouts.

The most significant change to the operating concept previously described under
Phase 1 is the commonplace use of transferred separation responsibility to Flight
Crews from Controllers. Use of the cockpit display to provide Air Traffic Situation
Awareness (ATSAW) of all aircraft in the vicinity and determine their short term
intent has provided the basis for this routine sharing or transferring of separation


                                                     55
                                  COCR Version 2.0


responsibilities. In some regional implementations, separation standards in all
domains have been reduced to that which is required to avoid the wake turbulence of
other aircraft or to meet a particular time of arrival at a significant point. To ensure
safety levels are maintained where encounter-specific separation is used, the ground
and airborne systems must have the capability to detect conflicts, provide resolutions,
and in rare cases implement the resolutions of the required manoeuvre by the aircraft,
without human intervention, e.g., auto execution. The avionics capabilities now
include conflict probing and resolution software used for managing conflicts when
conducting autonomous operations.

Autonomous operations are performed in dedicated volumes of the managed airspace
to accommodate the demand patterns. The dimensions of this airspace are tailored to
the need for safe operation of aircraft in autonomous mode. This may encompass
only a few flight levels in high-density airspace or bigger areas in low-density
airspace, which offer the best possible freedom of movement. The aim will be to
adjust the volumes of airspace allocated to Autonomous Operations to maximise the
benefits for capable aircraft, while providing an incentive for aircraft operators with
less capable aircraft to upgrade their avionics.

The Autonomous Operations Area (AOAs) is managed by ATC at the entry/exit
points and within a buffer zone. If due to circumstances which occurred during the
flight through the AOA, e.g., air-air conflicts, an aircraft is unable to comply with the
COTRAC upon exit, communications with the appropriate ATSU must occur ~100
NM prior to departing the AOA. Aircraft wishing to participate in this self-separation
operation must be equipped with the correct on-board automation allowing intent and
conflict resolution sharing via “machine-to-machine” negotiations. The SURV
application monitors other aircraft and triggers the conflict probe software when the
need arises. The longer term projected intent is determined by interrogating the
involved aircraft via a point-to-point data communications. The information shared
provides enough 4-D positional information beyond the detected conflict zone to
assess the best resolution. Upon analysing the positional information, on-board
avionics co-ordinate manoeuvres that resolve the conflict and present the resolution in
graphical form to the Flight Crew for activation. Some aircraft are capable of
executing these manoeuvres without human intervention when set for that mode.
Communications between the Flight Crews may or may not be necessary depending
on the geometry of the conflict.

Where once a hub and spoke operation was the norm with many medium size (e.g.,
100-140 passenger) aircraft, the industry now consists mainly of larger (e.g., 225 or
more passenger) aircraft conducting trans- and inter-continental travel operating from
the major metropolitan airports. Additionally, limited passenger services between
airports and downtown locations using aircraft capable of vertical takeoff and
landings (VTOL) are used on an increased basis.

Another revolution that has taken place is in the aircraft population. In some regions,
a new breed of “microjets” has been developed to satisfy the need for unrestricted
access to travel on an as-needed basis. The microjets, carrying 6-12 passengers, cater
to short haul domestic travel, e.g., 750 NM, to/from your own home town or
secondary suburban airports. They operate primarily from rural airports; basically on-
demand, or with little to no prearranged travel planning required and they are
competitively priced with the conventional commercial air transportation industry.


                                           56
                                          COCR Version 2.0


Some estimates2 project that this type of aircraft can represent 40% of the daily traffic
load.

Unmanned aerial systems (UAS) operating GAT are now common and routine. In the
United States, estimates approach ~13,000 of these aircraft in operation in 2025
predominantly for military, cargo, agricultural or security operations.

This shift in the aircraft population has stretched the capacity of the ATM system.
While it took some time to integrate these aircraft into the planning and decision-
making process, once all shareholders understood how to work with the system, the
increased burden of these operations became manageable. UASs, microjets, and all
other aircraft operate alongside each other without any user needing to be treated
differently.

A new type of Managed airport has also evolved. In order to assist in maintaining a
higher degree of safety and efficiency at low to medium density airport environments,
“virtual” towers where an automation platform replaces the Controller function issues
weather and sequencing information based on the aircraft provided position and intent
data. This provides a benefit to the local airport users as well as a saving to the ATSU
in reduced resources required to provide that level of service.

Managing the flow of traffic has also become a routine task. The majority of traffic is
metered from take off to arrival using four dimensional trajectory negotiations. Users
need only notify the Controller if there is a need to change the trajectory, otherwise
communication with the aircraft is mostly controlled by the System as it monitors the
traffic.

CDM allows for aircraft to join together and create a “flight” of aircraft proceeding in
the same direction to similar destinations. These operations are performed using
similar procedures as is done with military operations flights today. Airborne display
and automation systems provide assistance in the maintenance of separation from
other aircraft in the flight.

The ATM system performance requirements have now evolved to the point where
services such as A-EXEC require latency and availability levels that prevent
catastrophic consequences. For example, in order to benefit from the services in this
environment, the ATM system must receive non-conformance reports from aircraft
that are projected to deviate by more than a specified time (e.g., 10 seconds [s]) from
a previously co-ordinated longitudinal axis, or more than a specified lateral distance
(e.g., 1000 feet). This criterion causes adjustments to the agreed COTRAC trajectory
as environmental conditions cause non-conformance issues.

As data is now the primary means of communications, associated system
developments have occurred to ensure highly reliable and deterministic provision of
communications. Any intervention by Controllers is done using Phase 1 services.




2
    The U.S. JPDO has estimated that ~13,000 of these aircraft will be in operation in 2025.


                                                    57
                                                    COCR Version 2.0


 3.4.1 Phase 2 Environmental Characteristics and Conditions and Aircraft
       Performance Characteristics
 This section describes the Phase 2 environmental characteristics and conditions.
 Table 3-4 provides the Phase 2 airspace characteristics categorised by domain. Table
 3-5 provides the Phase 2 environmental conditions.

                          APT                       TMA                       ENR                      ORP                 AOA

Communication      Data is primary        Data is primary           Data is primary          Data is primary       Data is primary
capability and     means of               means of                  means of                 means of              means of
performance        communications.        communications.           communications.          communications.       communications.
                   Voice is used for      Voice is used for         Voice is used for        Indirect              Voice is used for
                   non-routine, failure   non-routine, failure      non-routine, failure     communications is     non-routine, failure
                   recovery, or           recovery, or              recovery, or             used for non-         recovery, or
                   emergency              emergency                 emergency                routine, failure      emergency
                   communications.        communications.           communications.          recovery, or          communications
                                                                                             emergency             with other aircraft.
                                                                                             communications.

Navigation         Precision Landing      RNAV/RNP 0.5              RNAV/RNP 1               RNAV/RNP 1            RNAV/RNP 1
capability and     Systems
performance                                                         RVSM                     RVSM
                   Visual separation,

Surveillance       Visual and voice       Surveillance              Surveillance             Surveillance          Airborne
capability and     communication.         service.                  Service using ADS-       Service using ADS-    Surveillance using
performance                                                         B & C.                   B & C.                ADS-B and
                   Surveillance                                                                                    AIRSEP.
                   Monitoring.                                      ACAS.                    ACAS.
                                                                                                                   ACAS.
                                                                    Deviation monitor.       Deviation monitor.

Separation         Longitudinal is        Longitudinal is           Longitudinal is          Longitudinal is        Collision avoidance
(Horizontal)       encounter-specific     encounter-specific        encounter-specific       encounter-specific     based. CDTI
                   criteria only,         criteria only, Lateral    criteria only, Lateral   criteria only, Lateral
                   Lateral is 750 ft.     is collision              is collision             is collision
                   between runway         avoidance based.          avoidance based.         avoidance based.
                   centrelines. CDTI.     CDTI                      CDTI                     CDTI

Separation         N/A                    1000 ft                   1000 ft                  1000 ft               Collision avoidance
(Vertical)                                                                                                         based. CDTI
                                                                    2000 ft                  2000 ft
                                                                    RVSM                     RVSM

Traffic complexity Complex with           Agreement based           Agreement based          Agreement based       User-preferred
                   visual guidance        trajectories              trajectories.            trajectories.         trajectories until
                                          connecting to                                                            ready to depart the
                                          complex arrival and                                                      area, then resume
                                          departure routes.                                                        agreement-based
                                                                                                                   trajectories.


                      Table 3-4: Phase 2 Airspace Environmental Characteristics


 Reference         Environmental Conditions
 C-ENV-1           Data communication is primary for provision of ATS, except in the airport domain.
 C-ENV-2           Voice communication is available.
 C-ENV-3           Clearances/instructions may be issued by automation; without controller involvement.
                   (All clearances are available for controller review).
 C-ENV-4           With the exception of an A-EXEC, no trajectory changing clearance/instruction will be
                   activated without Flight Crew action.
 C-ENV-5           A controlled flight is under the control of only one controller at a time. (ICAO Annex
                   11: para 3.5.1)[48]




                                                                   58
                                      COCR Version 2.0


Reference    Environmental Conditions
C-ENV-6      Surveillance enables detection of incorrect aircraft movement.
C-ENV-7      The airspace to which the clearance pertains is protected until the response is received.
C-ENV-8      The users are properly trained to use data communications.
C-ENV-9      Where a D-ATIS supplements the existing availability of Voice-ATIS, the information
             shall be identical in both content and format to the applicable Voice-ATIS broadcast.
C-ENV-10     The flight crew executes received instructions/clearances and updates onboard avionics
             in a timely manner.
C-ENV-11     ACAS is available.

                   Table 3-5: Phase 2 Services Environmental Conditions

Table 3-6 provides the Phase 2 aircraft performance characteristics for each domain.
The Phase 2 aircraft performance assumptions and characteristics are:
       Space and special-use vehicles are outside the scope of the FRS.
       Future speeds are based on the assumption that supersonic commercial aircraft
       may be in operation.
       Aircraft travelling over land masses (e.g., surface, TMA, En Route) will be
       limited to air speeds below Mach 1 (speed-of-sound) to prevent sonic booms,
       e.g., 0.95 mach.
       Air-Air speeds are based on the closing speed of two jet aircraft in the same
       wind environment.

       Parameter                    APT         TMA         ENR         ORP         AOA
       Max Gndspeed (KTAS)          200         410         850         1465        790
       Max Airspeed (KTAS)          200         300         600         1215        540
       Max Air-Air (KTAS)           N/A         600         1200        2430        1080
                             2
       Max Acceleration (m/s )      12.5        50          50          50          50

                   Table 3-6: Phase 2 Aircraft Performance Characteristics


3.5 Phase 2 Scenario

3.5.1 Pre-Departure Phase in the APT Domain
The mode of operation described under the Phase 1 scenario is now in common use
for all aircraft. In particular, aircraft equipage has evolved to the point where every
aircraft is now equipped with a cockpit display capable of high definition graphics.
This allows the use of advanced concepts in ATM, based on graphical depictions of
the surrounding aircraft situation, to be commonplace.

The issuance of a DCL now involves the negotiation of a highly constrained
trajectory using the COTRAC service. The negotiation of the trajectory is done in
accordance with the principles of CDM (involving the airspace user) to ensure that the



                                                59
                                  COCR Version 2.0


airspace users’ needs are considered. The final point in the clearance includes the
required constraint of the arrival airport provided by the ground system.

3.5.2 Departure in the APT and TMA Domains
The aircraft follows the 4-D trajectory previously negotiated through COTRAC. The
ATSU conflict probe system is now configured for up to a 2-hour look ahead from the
active present position. The Controller team takes necessary action to alleviate these
conflicts using the necessary services, predominantly the fine-tuning of the COTRAC
agreement of involved/impacted aircraft.

3.5.3 Operations in the ENR, ORP and AOA Domains
As the use of the services and the nature of ATC have evolved, the communications
requirements have evolved also. Trust in the system’s performance has become
commonplace. Routine exchanges are no longer needed. Everything the flight must
do is embedded in the COTRAC agreement. Communications transfers via ACM
occur automatically without Controller/Flight Crew involvement.              FLIPINT
agreements between the aircraft system and the ATSU automation system are now in
place with all aircraft and reports are only generated when an event occurs beyond the
parameters set in the COTRAC agreement. The aircraft’s COTRAC trajectory takes
into account the computational process of the arrival time constraint set by the
AMAN system. Changes to this agreement are more in the context of overall
trajectory maintenance.

However, when a non-compliance notification is received by the ATSU with less than
2 minutes remaining for resolution of the new conflict, two options are available. The
first option is to notify the Controller with a warning message and allow the resolution
to be achieved via voice.

The second option is ONLY applicable for aircraft equipped to do the A-EXEC
service which allows for reduced separation e.g., 2 NM or encounter-specific
separation. In this case, A-EXEC is initiated when the time remaining does not allow
for the delays associated with human-in-the-loop performance.           The ATSU
automation must determine what the appropriate trajectory modifications are and
initiate the transaction to the aircraft with an A-EXEC flag set to execute the
manoeuvre without the Flight Crew acknowledgement.

In En Route/Oceanic/Remote airspace environments, Unmanaged Airspace may be
designated for autonomous operations where self-separation applications are routinely
conducted. These applications have followed a natural progression from earlier
spacing applications, e.g., M&S, C&P, and ITP. Aircraft that have equipped for
autonomous operations are managed via COTRAC up to the entry point into the
AOA and are expected to comply with the existing COTRAC upon exiting the
autonomous operations area. Any changes to the exit conditions require the aircraft to
initiate a trajectory change request prior to departure from the AOA. When an aircraft
detects a potential conflict, the AIRSEP service activates to determine the trajectory
of the other aircraft involved, negotiates a solution, and provides the solution to the
Flight Crew.




                                          60
                                 COCR Version 2.0


3.5.4 Arrival in the TMA Domain
Arriving at the entry point into the TMA, the COTRAC operation continues. When
necessary due to the traffic density, aircraft are instructed via ACL to use the
appropriate services to self-separate in the final approach phase from traffic landing
on the same or closely spaced parallel runways. As the aircraft approaches the final
approach course, the PAIRAPP service is initiated. This is the point where the
COTRAC is terminated and the PAIRAPP service takes over to transfer separation
responsibility from the Controller to the Flight Crew. These services, provided in
combination, are the natural extension of the early spacing applications such as M&S
used in Phase 1 En Route airspace. The arrival taxi phase is now established before
the aircraft begins the final approach for landing. The D-SIG surface map and D-
TAXI overlay is communicated in advance of the landing clearance so that the Flight
Crew can determine any impacts to its configuration.

3.5.5 Arrival Taxi in the APT Domain
All the services introduced under the Phase 1 timeframe continue to be in use to some
extent unless superseded by services such as the now mature COTRAC service.
However, as airspace requirements and aircraft equipage increase, more aircraft are
eligible for data services.




                                         61
                                   COCR Version 2.0



4 OPERATIONAL, SAFETY, AND SECURITY
  REQUIREMENTS
This section provides the operational and safety requirements for ATS data
communications services and information security requirements for ATS and AOC
data communications services.

Note: A safety assessment was not performed for the AOC services.

4.1 Operational Requirements

4.1.1 Service Level Operational Assessment
Table 4-1 and Table 4-2 provide operational assessment for each ATS service for
Phase 1 and Phase 2 respectively. The column headers are defined as follows:
       Service: The acronym for the ATS service.
       Integrity: The required integrity to make the service usable.
       Continuity: The required continuity to make the service usable.
       Availability (Provision): The required service availability to make the service
       usable.
       Availability (Use): The required availability when using the service to make
       the service usable.

  Service             Continuity       Integrity      Availability     Availability(Use)
                                                      (Provision)
  ACL                    .99             10-2            .999                .993
  ACM                    .99             10-2            .999                .993
  A-EXEC                  -               -                -                   -
  AIRSEP                  -               -                -                   -
  AIRSEP SURV             -               -                -                   -
  AMC                    .99             10-2            .999                .993
  ARMAND                 .99             10-2            .999                .993
  C&P ACL                .99             10-2            .999                .993
  C&P SURV               .99             10-2            .999                .993
  COTRAC                  -               -                -                   -
  D-ALERT                .99             10-2            .993                .993
  D-ATIS                 .99             10-2            .999                .993
  DCL                    .99             10-2            .999                .993
  D-FLUP                 .99             10-2            .999                .993
  DLL                    .99             10-2            .999                .993
  D-ORIS                 .99             10-2            .999                .993
  D-OTIS                 .99             10-2            .999                .993
  D-RVR                  .99             10-2            .999                .993
  DSC                    .99             10-2            .999                .993
  D-SIG                  .99             10-2            .999                .993
  D-SIGMET               .99             10-2            .999                .993
  D-TAXI                 .99             10-2            .999                .993
  DYNAV                  .99             10-2            .999                .993



                                          62
                                 COCR Version 2.0

   Service          Continuity       Integrity      Availability       Availability(Use)
                                                    (Provision)
   FLIPCY              .99             10-2            .999                  .993
   FLIPINT             .99             10-2            .999                  .993
   ITP ACL             .99             10-2            .999                  .993
   ITP SURV            .99             10-2            .999                  .993
   M&S ACL             .99             10-2            .999                  .993
   M&S SURV            .99             10-2            .999                  .993
   PAIRAPP ACL          -               -                -                     -
   PAIRAPP SURV         -               -                -                     -
   PPD                 .95             10-2             .99                   .99
   SAP                 .99             10-2            .999                  .993
   SURV                .99             10-2            .999                  .993
   TIS-B               .99             10-2            .999                  .993
   URCO                .99             10-2            .993                  .993
   WAKE                .99             10-2            .993                  .993

                    Table 4-1: Phase 1 Operational Assessment

ATC Service       Continuity         Integrity       Availability of      Availability of Use
                                                       Provision
ACL                  .9995              10-5             .99995                  .9999
ACM                   .999              10-5              .9995                   .999
A-EXEC              .99999              10-7           .9999995                 .99999
AIRSEP               .9995              10-5             .99995                  .9999
AIRSEP SURV          .9995              10-5             .99995                  .9999
AMC                   .995              10-3               .999                   .993
ARMAND                .999              10-5              .9995                   .999
C&P ACL               .999              10-5              .9995                   .999
C&P SURV              .999              10-5              .9995                   .999
COTRAC               .9995              10-5             .99995                  .9999
D-ALERT               .999              10-5               .999                   .999
D-ATIS                .999              10-5              .9995                   .999
DCL                   .999              10-5              .9995                   .999
D-FLUP                .999              10-5              .9995                   .999
DLL                   .999              10-5              .9995                   .999
D-ORIS                .999              10-5              .9995                   .999
D-OTIS                .999              10-5              .9995                   .999
D-RVR                 .999              10-5              .9995                   .999
DSC                   .999              10-5              .9995                   .999
D-SIG                 .999              10-5              .9995                   .999
D-SIGMET              .999              10-5              .9995                   .999
D-TAXI                .999              10-5              .9995                   .999
DYNAV                 .999              10-5              .9995                   .999
FLIPCY                .999              10-5              .9995                   .999
FLIPINT              .9995              10-5             .99995                  .9999
ITP ACL               .999              10-5              .9995                   .999
ITP SURV              .999              10-5              .9995                   .999
M&S ACL               .999              10-5              .9995                   .999
M&S SURV              .999              10-5              .9995                   .999
PAIRAPP ACL           .999              10-5              .9995                   .999
PAIRAPP SURV          .999              10-5              .9995                   .999
PPD                   .999              10-3               .999                   .993
SAP                   .999              10-5              .9995                   .999



                                        63
                                  COCR Version 2.0

ATC Service          Continuity         Integrity      Availability of   Availability of Use
                                                         Provision
SURV                   .9995              10-5            .99995               .9999
TIS-B                     -                -                  -                   -
URCO                    .999              10-5              .999                .999
WAKE                    .999              10-5              .999                .999

                       Table 4-2: Phase 2 Operational Assessment


4.2 Operational Safety Requirements
The hazard severity levels and resulting safety requirements for some of the Phase 1
ATS services are specified in [2]. These services are DLIC (DLL), ACM, ACL,
AMC, DCL, DSC, D-ATIS, and FLIPCY. These Phase 1 safety requirements from
[2] have extended to similar Phase 1 services not explicitly called out in [2].

This section specifies the Phase 2 ATS safety requirements. To determines these
requirements, an operational safety assessment was conducted for each of the of eight
ATS service categories. (See Section 2.2 for a listing of the service categories.) The
most stringent safety requirements for any service within a service category
determined the safety requirements for that category.

Note: The Operational Safety Assessment (OSA) was limited to hazards caused by the
communication link; hazards outside of the communication portion of a given service,
due to the Controller, and the Flight Crew were considered out-of-scope.

This section is organized as follows:
        The safety methodology used to perform the operational safety assessment is
        documented in Section 4.2.1.
        A summary of the operational safety hazards, severity, and safety objectives
        are provided in Section 4.2.2.
        The safety assessment for each ATS service is provided in Section 4.2.3.

4.2.1 Safety Methodology
The operational safety assessment identifies potential hazards that may arise during
the use of the assessed service. The effects and consequences encountered as a result
of such hazards are then established and evaluated.

The safety hazard effect was ranked using The FAA’s Safety Management System
Manual (SMS version 1.1) severity and likelihood definitions [14] and
EUROCONTROL’s Safety Regulatory Requirement (ESARR 4) Set 1 Severity
Indicators [15].

Table 4-3 outlines the hazard effects and the standardised classification scheme used
to describe the severity of the ATS services hazards.




                                           64
                                       COCR Version 2.0


Effect On                                           Hazard Class
↓
              5 No Safety        4 Minor (MN)       3 Major (MJ)       2 Hazardous         1 Catastrophic
              Effect (NO)                                              (HZ)                (CS)
General                          Does not           Reduces the        Reduces the         Total loss of
                                 significantly      capability of      capability of       system control
                                 reduce system      the system or      the system of       such that:
                                 safety.            operators to       the operator’s
                                 Required           cope with          capability to
                                 actions are        adverse            cope with
                                 within             operating          adverse
                                 operator’s         conditions to      conditions to
                                 capabilities       the extent that:   the extents
                                 Includes:                             that:
Air Traffic   Slight increase    Slight             Reduction in       Reduction in        Collisions with
Control       in ATC             reduction in       separation as      separation as       other aircraft,
              workload           ATC                defined by a       defined by a        obstacles, or
                                 capability, or     low/moderate       high severity       terrain
                                 significant        severity           operational
                                 increase in        operational        error, or a total
                                 ATC workload       error, or          loss of ATC
                                                    significant
                                                    reduction in
                                                    ATC capability
Flying        - No effect on     - Slight           - Significant      - Large             Outcome would
Public        flight crew        increase in        increase in        reduction in        result in:
                                 workload           flight crew        safety margin
              - Has no safety                                                              - Hull loss
                                                    workload           or functional
              effect             - Slight
                                                                       capability          - Multiple
                                 reduction in       - Significant
              - Inconvenience                                                              fatalities
                                 safety margin      reduction in       - Serious or
                                 or functional      safety margin      fatal injury to
                                 capabilities       or functional      small number
                                                    capability
                                 - Minor illness                       - Physical
                                 or damage          - Major illness,   distress/excessi
                                                    injury, or         ve workload
                                 - Some
                                                    damage
                                 physical
                                 discomfort         - Physical
                                                    distress




                            Table 4-3: Description of Hazard Severity

Each class of hazard can be tolerated to a certain degree. For example, hazards of
Class 5 can occur with more frequency than hazards of Class 4, due to the reduced
severity of a Class 5 hazard. Since hazards can rarely be eliminated with complete
certainty, even Class 1 hazards can be tolerated if they are extremely rare Safety
Objectives have been defined to quantify and categorise the degree of tolerance in
terms of a safety objective for each hazard class, as shown in Table 4-4.




                                                   65
                                          COCR Version 2.0


  Hazard Class                 Safety Objective             Definition
  5 No Safety Effect           Frequent                     =>1 occurrence in 10-3 per flight hour
  4 Minor                      Probable                     =<1 occurrence in 10-3 per flight hour
  3 Major                      Remote                       =<1 occurrence in 10-5 per flight hour
  2 Hazardous                  Extremely Remote             =<1 occurrence in 10-7 per flight hour
  1 Catastrophic               Extremely Improbable         =<1 occurrence in 10-9 per flight hour

                              Table 4-4: Safety Objective Definitions

 The result of the safety assessment is a set of safety requirements. The requirements
 are procedures, equipment, and/or functional or environmental imperatives that must
 be implemented to reduce (i.e., mitigate) the probability of hazards in order to meet
 the associated Safety Objectives.

 4.2.2 Summary of the ATS Services Operational Safety Assessments
 At the highest level the ATS services operational safety hazards are 1) loss of service,
 and 2) hazardously misleading information. Loss of service is defined the lack of
 availability of a service when it is required. Hazardously misleading information
 consists of undetected corrupted messages, undetected mis-delivered messages,
 undetected late or missing messages and undetected out-of-sequence messages.

 The safety analyses were based on the operational use of the services as described in
 Sections 2 and 3, in conjunction with the operational environment characteristics and
 conditions described in Sections 3.2.1 and 3.4.1. Results of these analyses may
 require updating as operating concepts, system requirements, and supported services
 evolve. The safety assessments were used to determine the operational performance
 requirements.     Validated (complete and accurate) safety and performance
 requirements for communication services making use of the FRS (both air and
 ground) will need to occur prior to operational use. Table 4-5 and Table 4-6 and
 provides a summary of the hazard severity and consequent safety objective for the
 two high-level safety hazards for each of the eight ATS service categories in Phase 1
 and Phase 2.

 Note: Severity levels for DLL are not specified; but are levied on the service using the
 DLL information.

Service Category                          Loss of Service                Hazardously Misleading
                                                                              Information
                               Severity      Safety Objective       Severity     Safety Objective
Data Communication             5 (ACM)       Frequent              4 (ACM)       Probable
Management Services (DCM)
Clearance/ Instruction         5             Frequent               3            Remote
Services (CIS)
Flight Information Services    4             Probable               3            Remote
(FIS)
Advisory Services (AVS)        5             Frequent               4            Probable



                                                  66
                                         COCR Version 2.0


Service Category                         Loss of Service             Hazardously Misleading
                                                                          Information
                              Severity      Safety Objective   Severity     Safety Objective
Flight Position/ Intent/      5             Frequent           3            Remote
Preferences Service (FPS)
Emergency Information         5             Frequent           3            Remote
Services (EIS)
Delegated Separation          5             Frequent           3            Remote
Services (DSS)
Miscellaneous Services        N/A                              N/A
(MCS)

      Table 4-5: ATS Phase 1 Operational Safety Assessment Hazard Severity and Safety
                                        Objectives


Service Category                         Loss of Service             Hazardously Misleading
                                                                          Information
                              Severity      Safety Objective   Severity     Safety Objective
Data Communications           4 (ACM)       Probable           3 (ACM)      Remote
Management Services (DCM)
Clearance/ Instruction        3             Remote             2            Extremely Remote
Services (CIS)
Flight Information Services   4             Probable           2            Extremely Remote
(FIS)
Advisory Services (AVS)       3             Remote             2            Extremely Remote
Flight Position/ Intent/      3             Remote             2            Extremely Remote
Preferences Service (FPS)
Emergency Information         4             Probable           3            Remote
Services (EIS)
Delegated Separation          3             Remote             2            Extremely Remote
Services (DSS)
Miscellaneous Services        1             Extremely          1            Extremely
(MCS)                                       Improbable                      Improbable

      Table 4-6: ATS Phase 2 Operational Safety Assessment Hazard Severity and Safety
                                        Objectives

 4.2.3 Service Level Safety Assessment
 Table 4-5 and Table 4-6 provide safety assessment for each ATS service for Phase 1
 and Phase 2 respectively. The column headers are defined as follows:
          Service: The acronym for the ATS service.
          Integrity: The safety effect when an undetected error occurs.
          Continuity: The safety effect when communications fails once started.




                                                 67
                                        COCR Version 2.0


           Availability of Provision: The safety effect when unable to communicate to
           all aircraft.
           Availability of Use: The safety effect when unable to communicate with one
           aircraft.

Service                Continuity             Integrity       Availability of    Availability of Use
                                                                Provision
ACL                      Major             No safety effect   No safety effect    No safety effect
ACM                      Major             No safety effect   No safety effect    No safety effect
A-EXEC                      -                     -                  -                    -
AIRSEP                      -                     -                  -                    -
AIRSEP SURV                 -                     -                  -                    -
AMC                      Minor             No safety effect   No safety effect    No safety effect
ARMAND                   Major             No safety effect   No safety effect    No safety effect
C&P ACL                  Major             No safety effect   No safety effect    No safety effect
C&P SURV                Hazardous              Minor              Minor                Minor
COTRAC                      -                     -                  -                    -
D-ALERT                  Major             No safety effect   No safety effect    No safety effect
D-ATIS                   Major             No safety effect   No safety effect    No safety effect
DCL                      Major             No safety effect   No safety effect    No safety effect
D-FLUP                   Minor             No safety effect   No safety effect    No safety effect
DLL                      Major             No safety effect   No safety effect    No safety effect
D-ORIS                   Major             No safety effect   No safety effect    No safety effect
D-OTIS                   Minor             No safety effect   No safety effect    No safety effect
D-RVR                    Minor             No safety effect   No safety effect    No safety effect
DSC                      Major             No safety effect   No safety effect    No safety effect
D-SIG                    Minor             No safety effect   No safety effect    No safety effect
D-SIGMET                 Minor             No safety effect   No safety effect    No safety effect
D-TAXI                   Minor             No safety effect   No safety effect    No safety effect
DYNAV                       -                     -                  -                    -
FLIPCY                   Major             No safety effect   No safety effect    No safety effect
FLIPINT                  Major             No safety effect   No safety effect    No safety effect
ITP ACL                  Major             No safety effect   No safety effect    No safety effect
ITP SURV                Hazardous              Minor              Minor                Minor
M&S ACL                  Major             No safety effect   No safety effect    No safety effect
M&S SURV                Hazardous              Minor              Minor                Minor
PAIRAPP ACL                 -                     -                  -                    -
PAIRAPP SURV                -                     -                  -                    -
PPD                      Major             No safety effect   No safety effect    No safety effect
SAP                      Major             No safety effect   No safety effect    No safety effect
SURV (ATC)              Hazardous              Minor              Minor                Minor
TIS-B                   Hazardous              Minor              Minor                Minor
URCO                        -                     -                  -                    -
WAKE                        -                     -                  -                    -


                                Table 4-7: Phase 1 Safety Assessment




                                                  68
                                  COCR Version 2.0


Service          Continuity             Integrity        Availability of   Availability of Use
                                                           Provision
ACL                Major                Hazardous          Hazardous             Major
ACM                Minor                  Major              Major               Minor
A-EXEC          Catastrophic           Catastrophic       Catastrophic        Catastrophic
AIRSEP             Major                Hazardous          Hazardous             Major
AIRSEP SURV        Minor                Hazardous            Major               Minor
AMC                Minor                  Major              Major               Minor
ARMAND             Minor                 Minor          No safety effect    No safety effect
C&P ACL            Minor                  Major              Major               Minor
C&P SURV           Major                Hazardous            Minor               Minor
COTRAC             Major                Hazardous          Hazardous             Major
D-ALERT            Major                  Major              Minor               Minor
D-ATIS             Minor                Hazardous            Major               Minor
DCL                Major                Hazardous          Hazardous             Major
D-FLUP             Minor                  Major         No safety effect    No safety effect
DLL                Minor                Hazardous            Major               Minor
D-ORIS             Minor                Hazardous            Major               Minor
D-OTIS             Minor                Hazardous            Major               Minor
D-RVR              Minor                Hazardous            Major               Minor
DSC                Major                Hazardous          Hazardous             Major
D-SIG              Minor                Hazardous            Minor               Minor
D-SIGMET           Minor                Hazardous            Minor               Minor
D-TAXI             Major                Hazardous          Hazardous             Major
DYNAV          No safety effect           Minor         No safety effect    No safety effect
FLIPCY             Major                Hazardous          Hazardous             Major
FLIPINT            Major                Hazardous          Hazardous             Major
ITP ACL            Minor                  Major              Major               Minor
ITP SURV           Major                Hazardous            Minor               Minor
M&S ACL            Minor                  Major              Major               Minor
M&S SURV           Major                Hazardous            Minor               Minor
PAIRAPP ACL        Major                Hazardous            Minor               Minor
PAIRAPP SURV     Hazardous              Hazardous            Minor               Minor
PPD            No safety effect           Minor         No safety effect    No safety effect
SAP                Minor                  Major              Major               Minor
SURV (ATC)         Major                Hazardous            Major               Major
TIS-B                 -                     -                   -                   -
URCO               Major                  Major              Minor               Minor
WAKE               Major                Hazardous            Minor               Minor


                          Table 4-8: Phase 2 Safety Assessment




                                           69
                                  COCR Version 2.0


4.3 Operational Information Security Requirements
This section specifies the operational information security requirements for the FRS
following a logical, risk-based approach based against business goals.

This section contains a summary of the security analysis performed to derive security
requirements, focusing on its most pertinent aspects. Complete details of the security
analysis can be found in [11].

The security requirements developed apply to both voice and data when a new radio
frequency (RF) link is used. It is expected that existing procedural means will
continue to be used to help mitigate security concerns in existing voice links.

The security threat severity categories used have been aligned as far as possible with
the safety hazard classes defined in Section 4.2.1. Use of identical definitions is not
possible because security considers impacts other than safety impacts, for example
financial impacts and impacts of business needs.

4.3.1 Business Goals for Information Security
The business goals for information security of the Future Communications
Infrastructure are proposed as follows:
       Safety: The FCI must sufficiently mitigate attacks, which contribute to safety
       hazards. See Section 4.2.2 for a discussion of safety hazards.
       Flight regularity: The FCI must sufficiently mitigate attacks, which
       contribute to delays, diversions, or cancellations to flights.
       Protection of business interests: The FCI must sufficiently mitigate attacks
       which result in financial loss, reputation damage, disclosure of sensitive
       proprietary information, or disclosure of personal information.
The business goals must be met in a manner that is cost-effective in terms of total cost
of ownership (including development costs, set-up costs, operating costs including
communication overhead, and support costs) and without allowing security itself to
reduce the safety of the system (for example by denying service to aircraft that are
unable to authenticate their identity).

4.3.2 Process to Determine Security Requirements
Information security concerns the protection and defence of information and
information systems. It aims to ensure an appropriate level of confidentiality,
integrity, and availability of information in the face of deliberate attacks.

The evolutionary, attack-response nature of information security means that it is
important to follow a defined process in order to develop security requirements so that
the motivation for requirements is well understood and the analysis can be revisited
and revised as attacks change. The process used to develop security requirements for
the FRS is summarised in Figure 4-1.




                                          70
                                   COCR Version 2.0


                                      Security
                                   categorisation



             Risk               Applicable policies          Architectural
          assessment             and regulations               issues and
                                  identification              assumptions
                                                             determination



                                Security objectives                External criteria
                                 characterisation                 including business
                                                                        needs


                                     Security
                                  requirements
                                  determination



                   Figure 4-1: Information Security Requirement Process

The initial step, security categorisation, provides an initial assessment of the intrinsic
sensitivity of the information being handled by the system and acts to focus efforts
during the remainder of the process (e.g., evaluation of a threat severity).

Next, the risk assessment described in Section 4.3.3 analyses the threats to the system,
their likelihood, and potential impact. Mitigating these threats to an acceptable level
is the main driver during security requirement determination. Concurrently,
applicable policies and regulations are identified, and architectural issues and
assumptions are determined in Section 4.3.4. The focus is on areas that may need to
be considered during security requirement determination.

Subsequently security objectives are characterised. These objectives summarise the
results of the previous process steps and act as an opportunity to input external criteria
such as business drivers into the process.

Finally the security requirements themselves are derived in Section 4.3.6, based
primarily on the security objectives and the results of the risk assessment.

4.3.3 Risk assessment
Risk assessment is a crucial component of the information security requirements
development process. Mitigating risk to an acceptable level is one of the main goals
of the security requirements of a system. Mitigating risk to an acceptable level can
only be achieved with an accurate understanding the system risk.

Risk assessment consists of two steps: threat identification, described in
Section 4.3.3.1, and assessment of threat likelihood and threat severity, described in
Section 4.3.3.2.




                                              71
                                    COCR Version 2.0


4.3.3.1 Threat Identification
The main threats to the FCI are listed in Table 4-9.

Threat Identifier       Threat Description
T.DENIAL                System resources may become exhausted due to system error, non-
                        malicious user actions, or denial-of-service (DoS) attack.
                        An attacker floods a communications segment of the FCI with injected
T.DENIAL.FLOOD
                        messages in order to reduce the availability of the FCI.
                        An attacker injects malformed messages into a communications segment of
T.DENIAL.INJECT
                        the FCI in order to reduce the availability of the FCI.
                        An attacker injects deliberate RF interference into an RF communication
T.DENIAL.INTERFERE
                        segment of the FCI in order to reduce the availability of the FCI.
T.ENTRY                 An individual other than an authorised user may gain access via technical
                        or non-technical attack for malicious purposes.
                        An attacker delays/deletes/injects/modifies/re-directs/re-orders/replays or
T.ENTRY.ALTER           otherwise alters messages on a communications segment of the FCI in
                        order to reduce the integrity of the FCI.
T.ENTRY.                An attacker eavesdrops on messages on a communications segment of the
                        FCI in order to reduce the confidentiality of the FCI.
EAVESDROP
T.ENTRY.                An attacker impersonates a user of the FCI in order to reduce the
                        confidentiality or integrity of the FCI, or simply to gain free use of the FCI.
IMPERSONATE

                            Table 4-9: FCI High-Level Threats

4.3.3.2 Threat Likelihood and Threat Severity
An initial assessment of threat likelihood and threat severity is provided in Table
4-10. The assessment assumes that the FCI contains no specific security controls or
intrinsic security mitigations (such as the inherent mitigation of deliberate RF
interference by certain spread spectrum radio systems).

Threat likelihood is ranked as “unlikely”, “likely”, or “highly likely” based on its
potential for realisation. Two factors are used to determine the threat likelihood:
        Motivation: A ranking of how strong the motivation is to realise the threat.
        A value in the range 1-3 is assigned to motivation, with 3 representing strong
        motivation and 1 representing weak motivation.
        Required capabilities: A ranking of how much financial and technical
        capability is required to realise the threat. A value in the range 1-3 is assigned
        to required capabilities, with 3 representing a low requirement, and 1
        representing a high requirement.
Threat likelihood values are determined by multiplying the motivation and required
capabilities values – a result of 1 to 3 corresponds to “unlikely”, 4 to 6 corresponds to
“likely”, and 7 to 9 corresponds to “highly likely”.

Threat severity is ranked based on the potential impact of the threat if it is realised,
using the following categories:


                                               72
                                            COCR Version 2.0


               None: There is no perceivable impact on safety, flight regularity, or business
               interests.
               Low: There is a limited adverse effect on safety, flight regularity, or business
               interests.
               Medium: There is a serious adverse effect on safety, flight regularity, or
               business interests.
               High–Severe: There is a severe adverse effect on safety, flight regularity, or
               business interests.
               High–Catastrophic: There is a catastrophic effect on safety, flight regularity,
               or business interests.
      To calculate severity, potential impacts on safety, flight regularity, and business needs
      are considered, and a value in the range 1-5 assigned to each, with 1 being the most
      serious impact and 5 being the least serious impact. Threat severity is then
      determined based on the maximum of the three values assigned, with a maximum
      value of 1 corresponding to “high – catastrophic”, 2 corresponding to “high – severe”,
      etc.

      The information security assessment in Table 4-10 is necessarily only a preliminary
      assessment at this early stage in the development of the FCI. The assessment will
      need to be regularly revisited and revised in order to ensure that it remains up-to-date
      with attack innovations and development decisions.


                                     Likelihood                                   Severity
Threat Identifier       Motivation     Required      Overall   Safety       Flight       Business
                                                                                                    Overall
                                      Capabilities                        Regularity      Needs
T.DENIAL
                            3              2         Likely       2           3              3      High -
T.DENIAL.FLOOD
                                                                                                    Severe
                            3              2         Likely       2           3              3      High -
T.DENIAL.INJECT
                                                                                                    Severe
T.DENIAL.                   3              3         Highly       2           3              3      High -
INTERFERE                                            likely                                         Severe

T.ENTRY
                            3              2                      1           4              2      High -
T.ENTRY.ALTER                                        Likely                                         Catastro
                                                                                                    phic
T.ENTRY.                    3              3         Highly       5           5              2      High -
                                                     likely                                         Severe
EAVESDROP

T.ENTRY.                    3              2         Likely       1           4              2      High -
                                                                                                    Catastro
IMPERSONATE                                                                                         phic
Motivation               1 = weak, 3 = strong                  Severity        1 = most serious
Required capabilities    1 = high, 3 = low                                     5 = least serious

                                Table 4-10: Threat Likelihood and Severity


                                                     73
                                  COCR Version 2.0


4.3.4 Service Level Threat Severity Assessment
Table 4-11 and Table 4-12 provide the information security service level threat
severity assessment for ATS and AOC services, respectively. The column headers are
defined as follows:
       Service: The acronym for the service name.
       Confidentiality: This column represents the relative operational impact of
       violation of confidentiality.
       Integrity: This column represents the relative operational impact of corruption
       of the integrity.
       Availability: This column represents the relative operational impact of the
       loss of use/provision of the service.
The threat severity categories (e.g., high and medium) are defined in Section 4.3.3.2.




                                          74
                                COCR Version 2.0


Service                 Confidentiality            Integrity         Availability
ACL                          Low                 High-Severe         High-Severe
ACM                          None                High-Severe         High-Severe
A-EXEC                       Low               High-Catastrophic   High-Catastrophic
AIRSEP                       Low                 High-Severe         High-Severe
AIRSEP SURV                  Low                 High-Severe         High-Severe
AMC                          None                    Low               Medium
ARMAND                       Low                     Low                 Low
C&P ACL                      Low                 High-Severe         High-Severe
C&P SURV                     Low                 High-Severe           Medium
COTRAC                       Low                 High-Severe         High-Severe
D-ALERT                     Medium               High-Severe         High-Severe
D-ATIS                       None                High-Severe           Medium
DCL                          None                High-Severe         High-Severe
D-FLUP                       None                  Medium                Low
DLL                          None                High-Severe         High-Severe
D-ORIS                       None                  Medium                Low
D-OTIS                       None                High-Severe           Medium
D-RVR                        None                High-Severe             Low
DSC                          Low                 High-Severe           Medium
D-SIG                        None                  Medium                Low
D-SIGMET                     None                High-Severe           Medium
D-TAXI                       Low                 High-Severe           Medium
DYNAV                        Low                 High-Severe           Medium
FLIPCY                       Low                 High-Severe           Medium
FLIPINT                      Low                 High-Severe         High-Severe
ITP ACL                      Low                 High-Severe         High-Severe
ITP SURV                     Low                 High-Severe           Medium
M&S ACL                      Low                 High-Severe         High-Severe
M&S SURV                     Low                 High-Severe           Medium
PAIRAPP ACL                  Low                 High-Severe         High-Severe
PAIRAPP SURV                 Low                 High-Severe           Medium
PPD                          Low                     Low                 Low
SAP                          Low                   Medium                Low
SURV                         Low                 High-Severe           Medium
TIS-B                        Low                 High-Severe           Medium
URCO                         None                  Medium              Medium
WAKE                         None                High-Severe         High-Severe

          Table 4-11: Information Security Threat Severity for ATS Services




                                          75
                                   COCR Version 2.0


    Information Type       Confidentiality         Integrity           Availability
    AOCDLL                      None              High-Severe             High
    CABINLOG                    Low                  Low                  Low
    ENGINE                      Low                 Medium              Medium
    FLTLOG                     Medium                Low                  Low
    FLTPLAN                     Low               High-Severe             High
    FLTSTAT                    Medium                Low                  Low
    FREETXT                    Medium                Low                  Low
    FUEL                        Low                  Low                  Low
    GATES                       Low                  Low                  Low
    LOADSHT                    Medium             High-Severe             High
    MAINTPR                    Medium               Medium                Low
    MAINTRT                    Medium               Medium                Low
    NOTAM                       None                Medium              Medium
    OOOI                        Low                  Low                  Low
    POSRPT                      Low                 Medium              Medium
    SWLOAD                      Low                  Low                  Low
    TECHLOG                    Medium               Medium              Medium
    UPLIB                      Medium             High-Severe           Medium
    WXGRAPH                     Low                 Medium              Medium
    WXRT                        None                Medium              Medium
    WXTEXT                      Low                 Medium                Low

             Table 4-12: Information Security Threat Severity for AOC Services

4.3.5 Architectural Issues and Assumptions
There are a wide variety of security controls or countermeasures and it is necessary to
consider various architectural issues in order to determine which controls should be
used to protect the FCI.

Controls based on cryptography and encryption can be applied at a variety of protocol
layers. One important question is which layer or layers of the FCI should include
cryptographic protection. The answer to this question will clarify the extent to which
controls impinge on the specification of the FRS.

In addition, procedural controls such as voice read-back and waveform controls such
as frequency hopping can be used to mitigate certain threats. Redundancy can be
built into the provision of any part of the FCI, through duplication of elements such as
radios, and alternate network paths. A firewall can be placed at any network
interconnection, and apply rules for packet filtering based on parameters such as
originator and destination address.
The properties of these controls are summarised in Table 4-13.



                                             76
                                       COCR Version 2.0



                     Involves               Example                  Good for
Procedural           Human users            Voice readback           T.ENTRY.ALTER
controls
End-to-end           End systems            Aeronautical             T.ENTRY.ALTER
cryptographic                               Telecommunications
                                                                     T.ENTRY.EAVESDROP
protection                                  Network (ATN)
                                            Security, S/MIME,        T.ENTRY.IMPERSONATE
                                            SSL/TLS
Network level        Boundary               IPSec                    T.ENTRY.ALTER
cryptographic        Intermediate Systems
                                                                     T.ENTRY.EAVESDROP
protection           (BIS)
                                                                     T.ENTRY.IMPERSONATE
Link level           Radio, logical         Wireless LAN, GSM        T.DENIAL.FLOOD
cryptographic        characteristics        security measures
                                                                     T.DENIAL.INJECT
protection
                                                                     T.ENTRY.ALTER
                                                                     T.ENTRY.EAVESDROP
                                                                     T.ENTRY.IMPERSONATE
Waveform             Radio, RF              Spread spectrum          T.DENIAL.FLOOD
controls             characteristics
                                                                     T.DENIAL.INTERFERE
Redundancy           Second radio system    VHF voice alternate      T.DENIAL.FLOOD
                     (same or different     radio site (ground),
                                                                     T.DENIAL.INTERFERE
                     technology)            spare channels
Firewall             Routers                COTS firewall products   T.DENIAL.FLOOD
                                                                     T.DENIAL.INJECT

                            Table 4-13: Properties of Security Controls

The conclusions of the architectural discussion are:
           Cryptographic protection appears to be the preferred approach to mitigate
           T.ENTRY.ALTER, T.ENTRY.EAVESDROP, and
           T.ENTRY.IMPERSONATE.
           Cryptographic protection at the link layer, network layer, or application layer
           can be used to mitigate T.ENTRY.ALTER, and T.ENTRY.IMPERSONATE.
           There are trade-offs involved in deciding which protocol layer to protect. For
           example, application layer protection may be preferred from a security
           perspective since it secures the packet end-to-end. But link layer protection
           may be preferred from a cost perspective since a single secure channel can be
           used to protect a large number of services.
           Cryptographic protection at the link layer, network layer, or application layer
           can also be used to mitigate T.ENTRY.EAVESDROP. However since only a
           small number of services require mitigation of T.ENTRY.EAVESDROP and
           encryption could affect the safety of ATS services, it is expected that end-to-
           end cryptographic protection will be used in this case.
           One control that mitigates T.DENIAL.INJECT is link level cryptographic
           protection. This would impact the FRS specification. Use of a firewall to


                                                77
                                 COCR Version 2.0


       selectively filter received data is an alternative, which would not impact the
       FRS specification.
       A system configuration, which involves radio set and channel redundancy may
       be a cost effective way to mitigate T.DENIAL.INTERFERE and
       T.DENIAL.FLOOD, since such redundancy is already expected to be required
       to address safety issues associated with equipment failure.

4.3.6 Information Security Requirements
This section specifies the information security requirements developed based on the
analysis that has been performed. First, security requirements for the FCI are
developed, and then security requirements for the FRS are extrapolated based on the
FCI requirements.

The FCI security requirements are specified in Table 4-14.




                                         78
                                       COCR Version 2.0


Requirement Id   Requirement                                             Associated Threats
R.FCI-SEC.1a     The FCI shall support reliability and robustness to     T.DENIAL.FLOOD
                 mitigate denial of service attacks when providing
                                                                         T.DENIAL.INJECT
                 services with “high – severe” or “high –
                 catastrophic” availability ranking.                     T.DENIAL.INTERFERE
R.FCI-SEC.1b     The FCI should support reliability and robustness to    T.DENIAL.FLOOD
                 mitigate denial of service attacks when providing
                                                                         T.DENIAL.INJECT
                 services with “medium” availability ranking.
                                                                         T.DENIAL.INTERFERE
R.FCI-SEC.2a     The FCI shall support message authentication and        T.DENIAL.INJECT
                 integrity to prevent message alteration attacks when
                                                                         T.ENTRY.ALTER
                 providing services with “high – severe” or “high –
                 catastrophic” integrity ranking.                        T.ENTRY.IMPERSONATE
R.FCI-SEC.2b     The FCI should support message authentication and       T.DENIAL.INJECT
                 integrity to prevent message alteration attacks when
                                                                         T.ENTRY.ALTER
                 providing services with “medium” integrity ranking.
                                                                         T.ENTRY.IMPERSONATE
R.FCI-SEC.3a     The FCI shall support encryption to mitigate            T.ENTRY.EAVESDROP
                 eavesdropping when providing services with “high –
                 severe” confidentiality ranking.
R.FCI-SEC3b      The FCI should support encryption to mitigate           T.ENTRY.EAVESDROP
                 eavesdropping when providing services with
                 “medium” confidentiality ranking.
R.FCI-SEC.4a     The FCI shall support entity authentication to          T.ENTRY.ALTER
                 mitigate impersonation attacks when providing
                                                                         T.ENTRY.IMPERSONATE
                 services with “high – severe” or “high –
                 catastrophic” integrity ranking.
R.FCI-SEC.4b     The FCI should support entity authentication to         T.ENTRY.ALTER
                 mitigate impersonation attacks when providing
                                                                         T.ENTRY.IMPERSONATE
                 services with “medium” integrity ranking.
R.FCI-SEC.5      The operation of the FCI security function shall not
                 diminish the ability of the FCI to operate safely and
                 effectively.

                     Table 4-14: FCI Information Security Requirements

 Specific FRS information security requirements have derived from the FCI
 information security requirements are specified in Table 4-15.




                                                 79
                                    COCR Version 2.0


 Requirement Id   Requirement                                                    Associated FCI
                                                                                 Requirements
 R.FRS-SEC.1a     The FRS shall provide a measure of resistance against          R.FCI-SEC.1
                  deliberate insertion of RF interference when providing
                  services with “high – severe” or “high – catastrophic”
                  availability ranking.
 R.FRS-SEC.1b     The FRS should provide a measure of resistance against         R.FCI-SEC.1
                  deliberate insertion of RF interference when providing
                  services with “medium” availability ranking.
 R.FRS-SEC.2a     The FRS shall support message authentication and               R.FCI-SEC.2
                  integrity as an option to prevent message alteration attacks
                                                                                 R.FCI-SEC.5
                  when providing services with “high – severe” or “high –
                  catastrophic” integrity ranking.
 R.FRS-SEC.2b     The FRS should support message authentication and              R.FCI-SEC.2
                  integrity as an option to prevent message alteration attacks
                                                                                 R.FCI-SEC.5
                  when providing services with “medium” integrity ranking.
 R.FRS-SEC.3a     The FRS shall support entity authentication as an option to    R.FCI-SEC.4
                  mitigate impersonation attacks when providing services
                                                                                 R.FCI-SEC.5
                  with “high – severe” or “high – catastrophic” integrity
                  ranking.
 R.FRS-SEC.3b     The FRS should support entity authentication as an option      R.FCI-SEC.4
                  to mitigate impersonation attacks when providing services
                                                                                 R.FCI-SEC.5
                  with “medium” integrity ranking.

                   Table 4-15: FRS Information Security Requirements

Note: The A-EXEC service raises new security problems because it is the first
communications service introducing a "high - catastrophic" confidentiality, integrity,
or availability ranking. Providing sufficient security for this service requires further
research.




                                               80
                                                COCR Version 2.0



  5 PERFORMANCE REQUIREMENTS
  An Operational Performance Assessment (OPA) is normally conducted to determine
  the performance a system or service must achieve. OPA results typically include
  determination of the availability, integrity, and transaction times. These performance
  requirements are driven both by operational needs and safety requirements. In
  addition to the OPA, other assessments (e.g., information security) may be conducted
  to determine other communication performance requirements.

  Performance assessments start with an end-to-end context and allocate performance
  requirements to humans, systems and or subsystems. The OPA begins with Required
  Communication Performance (RCP) and allocates these requirements to humans and
  technical components (e.g., equipment). The term Required Communication
  Technical Performance (RCTP) refers to the allocation to the technical components.

  This section provides the technical communication performance requirements for the
  COCR voice and data communication services. The COCR technical communication
  performance requirements are based on a combination of prior safety work, subject
  matter expertise, and performance assessments.

  Note: Although both voice and data requirements are provided, allocated FRS
  requirements are only developed for data communications.

  The communication loading analysis in Section 6 uses allocated FRS performance
  requirements in the Section to estimate FRS capacity requirements. Although the
  loading analysis evaluates a reasonable worst case scenario for service utilization,
  there is not an instance of use for every service in every domain listed herein.

  5.1 Voice Requirements
  Table 5-1 and Table 5-2 provide the voice performance requirements for ATS and
  AOC communication, respectively. Performance values are based on information in
  [53], [44] and input from subject matter experts. The quality of the voice must be
  sufficient to meet the operational requirement in the airspace where it is used. Quality
  includes user acceptability and intelligibility.

Service Type                                             Party-line                                     Broadcast
Domain                   APT               TMA                  ENR             ORP                       ALL
                                                                                              AOA
Density               HD       LD       HD       HD        HD         LD     HD       LD                  ALL
Call Establishment
                     100 ms   100 ms   100 ms   100 ms    100ms    100 ms   100 ms    20 s    100 ms       20 s
Delay

Voice Latency        130 ms   130 ms   130 ms   130ms     130 ms   130 ms   130ms    485 ms   130 ms      485 ms
AP                   0.99999 0.99999 0.99999 0.99999 0.99999 0.99999 0.99999 0.99999          0.99999     0.999
AU                   0.99998 0.99998 0.99998 0.99998 0.99998 0.99998 0.99998 0.99998          0.99998     0.998


                              Table 5-1: ATS Voice Performance Requirements




                                                           81
                                   COCR Version 2.0


             Service Type         Selective Addressed   Party-line/Broadcast
             Domain                      ALL                   ALL
             Density                     ALL                   ALL
             Call Establishment          20 s                   20 s
             Delay
             Voice Latency              485 ms                485 ms
             AP                         0.999                  0.999
             AU                         0.998                  0.998

                    Table 5-2: AOC Voice Performance Requirements


5.2 Data Requirements
This section provides the overall RCTP requirements for ATS and AOC data
communication services and the allocated FRS technical performance requirements.

5.2.1 RCTP Requirements
This section summarizes the requirement methodologies, provides technical data
communication requirements for Phase 1 and Phase 2 ATS and AOC services, and
provides supporting requirement information.

5.2.1.1 RCTP Methodology

5.2.1.1.1   Phase 1 ATS Service Requirement Methodology
The Phase 1 ATS performance requirements are primarily drawn from previous
service performance assessments (i.e., [2] and [55]). For services not covered in
previous assessments, performance requirements are based on:
       Performance requirements for comparable services
       Subject matter expertise

5.2.1.1.2   Phase 2 ATS Service Requirement Methodology
An OPA was performed on the communication portion of each of the Phase 2 ATS
services described in Section 2.2. The scope of the OPA does not include
performance requirements for airborne and ground automation functions such as route
generation, depiction, loading, conflict and out-of-conformance detection, and the
generation of alerts.

To determine the communication performance requirements the more stringent of the
safety objectives and operational requirements for each parameter was used. The
operational requirements are driven by the type of exchange (e.g., trajectory change,
general information) and the domain in which the service was offered. The safety
objectives for the Phase 2 ATS service categories are listed in Table 4-6. The OPA
results are provided in Table 5-5.

The following comments apply to the Phase 2 ATS OPA.


                                            82
                                        COCR Version 2.0


       The SURV, TIS-B and WAKE requirements are based on [5], [56], and [57].
       The integrity requirements are determined from the hazard severity
       classification contained in the Hazardously Misleading Information column
       for each of the ATS services categories as shown in Table 4-6.
       The availability of provision (AP) requirements are determined from the
       hazard severity classification contained in the Loss of Service column for each
       of the ATS services categories as shown in Table 4-6.

5.2.1.1.3   AOC Service Requirement Methodology
The AOC service requirements are based on a high level performance assessment and
subject matter expertise.

5.2.1.2 RCTP Performance Values
Table 5-4, Table 5-5 and Table 5-6 provide performance requirements for data
communications.

                                     Update Interval (secs)               Update Interval (secs)
                                     95% Confidence Level                 95% Confidence Level
                     Service               Phase 1                              Phase 2

                               APT   TMA     ENR    ORP       AOA   APT   TMA ENR        ORP       AOA

             C&P SURV           -       3      3      3        -     -       3      3      3        -

             ITP SURV           -       3      3      3        -     -       3      3      3        -

             M&S SURV           -       3      3      3        -     -       3      3      3        -

             PAIRAPP SURV                      -      -        -    2*      2*      -      -        -

             AIRSEP SURV        -       -      -      -              -       -      -      -       5*

             SURV (ATC)         2       5     10      10             2       5      5      5       5**

             TIS-B              2       5     10      10       -             -      -      -        -

             WAKE               2       5     10      -        -     2       5      5      -


                       Table 5-3: ATS Broadcast Service Update Intervals




                                                     83
                                                     COCR Version 2.0

                                                                                           Continuity   Integrity           Availability
                          Expiration Time                       Latency
                                                                                            RCTP         RCTP                 RCTP
        Service          RCTP (ET – 1 way)                  RCTP (TT95- 1 way)
                                                                                           (per inst)   (per inst)            (pFH)

                  APT    TMA    ENR    ORP     AOA   APT    TMA     ENR       ORP    AOA     CUIT         IUCT         AP              AU

ACL               10.0   10.0   10.0   75.0     -     8.0   8.0         8.0   60.0    -      0.9953      1.0E-5       0.999           0.9934

ACM               10.0   10.0   10.0   75.0     -     8.0   8.0         8.0   60.0    -      0.995       1.0E-5       0.999           0.993

A-EXEC              -     -      -       -      -      -     -           -     -      -        -            -           -                  -

AIRSEP              -     -      -       -      -      -     -           -     -      -        -            -           -                  -

AIRSEP SURV         -     -      -       -      -      -     -           -     -      -        -            -           -                  -

AMC               10.0   10.0   10.0     -      -     8.0   8.0         8.0    -      -      0.995       1.0E-3       0.999           0.993

ARMAND              -     -     30.0     -      -      -     -      20.0       -      -      0.995       1.0E-5       0.999           0.993

C&P ACL             -    20.0   20.0   75.0     -      -    12.0    12.0      60.0    -      0.995       1.0E-5       0.999           0.993

C&P SURV            -    6.0    6.0     6.0     -      -    2.0         2.0   2.0     -      0.9995      1.0E-7       0.999           0.999

COTRAC              -     -      -       -      -      -     -           -     -      -        -            -           -                  -

D-ALERT           20.0   20.0   20.0   75.0     -    12.0   12.0    12.0      60.0    -      0.995       1.0E-5       0.999           0.993

D-ATIS            15.0   15.0   15.0   90.0     -    10.0   10.0    10.0      60.0    -      0.995       1.0E-5       0.999           0.993

DCL               30.0    -      -       -      -    20.0    -           -     -      -      0.995       1.0E-5       0.999           0.993

D-FLUP            30.0    -      -       -      -    20.0    -           -     -      -      0.995       1.0E-3       0.999           0.993

DLL               20.0   20.0   20.0   100.0    -    12.0   12.0    12.0      60.0    -      0.995       1.0E-5       0.999           0.993

D-ORIS              -    15.0   15.0   90.0     -      -    10.0    10.0      60.0    -      0.995       1.0E-5       0.999           0.993

D-OTIS            15.0   15.0   15.0   90.0     -    10.0   10.0    10.0      60.0    -      0.995       1.0E-5       0.999           0.993

D-RVR             15.0   15.0   15.0   90.0     -    10.0   10.0    10.0      60.0    -      0.995       1.0E-5       0.999           0.993

DSC                 -     -     60.0   72.0     -      -     -      50.0      60.0    -      0.995       1.0E-5       0.999           0.993

D-SIG             30.0   30.0    -       -      -    20.0   20.0         -     -      -      0.995       1.0E-5       0.999           0.993

D-SIGMET          15.0   15.0   15.0   90.0     -    10.0   10.0    10.0      60.0    -      0.995       1.0E-5       0.999           0.993

D-TAXI            20.0   20.0    -       -      -    12.0   12.0         -     -      -      0.995       1.0E-5       0.999           0.993

DYNAV               -     -      -       -      -      -     -           -     -      -        -            -           -                  -

FLIPCY            40.0   40.0   40.0   80.0     -    30.0   30.0    30.0      60.0    -      0.995       1.0E-5       0.999           0.993

FLIPINT           40.0   40.0   40.0   80.0     -    30.0   30.0    30.0      60.0    -      0.995       1.0E-5       0.999           0.993

ITP ACL             -     -      -     75.0     -      -     -           -    60.0    -      0.995       1.0E-5       0.999           0.993

ITP SURV            -    6.0    6.0     6.0     -      -    2.0         2.0   2.0     -      0.9995      1.0E-7       0.999           0.999

M&S ACL             -    20.0   20.0     -      -      -    12.0    12.0       -      -      0.995       1.0E-5       0.999           0.993

M&S SURV            -    6.0    6.0     6.0     -      -    2.0         2.0   2.0     -      0.9995      1.0E-7       0.999           0.999

PAIRAPP ACL         -     -      -       -      -      -     -           -     -      -        -            -           -                  -

PAIRAPP SURV        -     -      -       -      -      -     -           -     -      -        -            -           -                  -

PPD               40.0   40.0   40.0   80.0     -    30.0   30.0    30.0      60.0    -      0.995       1.0E-5       0.999           0.993

SAP                 -    15.0   15.0     -      -      -    10.0    10.0       -      -      0.995       1.0E-5       0.999           0.993

SURV (ATC)         4.0   10.0   20.0   20.0     -     1.2   2.0         2.0   2.0     -     0.99995      1.0E-7      0.999995        0.9999

TIS-B              4.0   10.0   20.0   20.0     -     1.2   2.0         2.0   2.0     -     0.99995      1.0E-7      0.999995        0.9999

URCO                -     -      -       -      -      -     -           -     -      -        -            -           -                  -

WAKE                -     -      -       -      -      -     -           -     -      -        -            -           -                  -


                         Table 5-4: Phase 1 ATS RCTP Performance Requirements




   3
       For the ORP domain, the continuity requirement is 0.999.
   4
       For the ORP domain, the availability of use requirement is 0.999.


                                                                   84
                                                     COCR Version 2.0

                                                                                            Continuity   Integrity             Availability
                          Expiration Time                       Latency
                                                                                             RCTP         RCTP                   RCTP
        Service          RCTP (ET – 1 way)                  RCTP (TT95- 1 way)
                                                                                            (per inst)   (per inst)              (pFH)

                  APT    TMA    ENR    ORP    AOA    APT    TMA     ENR       ORP    AOA      CUIT         IUCT           AP              AU

ACL               6.25   6.25   6.25   20.0   6.25    3.0   3.0         3.0   12.5   3.0      0.9995      1.0E-7        0.99999          0.999

ACM               6.25   6.25   6.25   20.0   6.25    3.0   3.0         3.0   12.5   3.0      0.9995      1.0E-7        0.99999          0.999

A-EXEC             -      2.0   2.0    2.0     -       -    1.65    1.65       -      -     0.9999999     1.0E-9      0.999999999      0.9999999

AIRSEP             -       -     -      -     9.75     -      -          -     -     5.0     0.9995       1.0E-7        0.99999          0.999

AIRSEP SURV        -       -     -      -     10.0     -      -          -     -     2.0      0.9995      1.0E-7        0.99999          0.999

AMC               10.0   10.0   10.0    -     30.0    8.0   8.0         8.0    -     20.0     0.995       1.0E-3         0.999           0.993

ARMAND             -       -    17.0    -      -       -      -     10.0       -      -       0.995       1.0E-3         0.999            0.99

C&P ACL            -     9.75   9.75   20.0    -       -    5.0         5.0   12.5    -       0.9995      1.0E-7        0.99999          0.999

C&P SURV           -      6.0   6.0    6.0     -       -    2.0         2.0   2.0     -       0.9995      1.0E-7         0.999           0.999

COTRAC             -     9.75   9.75   20.0   9.75     -    5.0         5.0   12.5   5.0      0.9995      1.0E-7        0.99999          0.999

D-ALERT           9.75   9.75   9.75   20.0   9.75    5.0   5.0         5.0   12.5   5.0      0.9995      1.0E-5        0.99999          0.999

D-ATIS            9.75   9.75   9.75   30.0   30.0    5.0   5.0         5.0   20.0   20.0     0.995       1.0E-7         0.999            0.99

DCL               30.0     -     -      -      -     20.0     -          -     -      -       0.9995      1.0E-7        0.99999          0.999

D-FLUP            9.75   9.75   17.0   30.0   30.0    5.0   5.0     10.0      20.0   20.0     0.995       1.0E-3         0.999            0.99

DLL               6.25   9.75   17.0   30.0   30.0    3.0   5.0     10.0      20.0   20.0     0.9995      1.0E-7        0.99999          0.999

D-ORIS             -     9.75   9.75   30.0   30.0     -    5.0         5.0   20.0   20.0     0.995       1.0E-7         0.999            0.99

D-OTIS            9.75   9.75   9.75   30.0   30.0    5.0   5.0         5.0   20.0   20.0     0.995       1.0E-7         0.999            0.99

D-RVR             6.25   6.25   9.75   30.0   30.0    3.0   3.0         5.0   20.0   20.0     0.995       1.0E-7         0.999            0.99

DSC                -       -    30.0   20.0   30.0     -      -     20.0      50.0   20.0     0.9995      1.0E-7        0.99999          0.999

D-SIG             17.0   17.0    -      -      -     10.0   10.0         -     -      -       0.995       1.0E-7         0.999            0.99

D-SIGMET          9.75   9.75   9.75   30.0   30.0    5.0   5.0         5.0   20.0   20.0     0.995       1.0E-7         0.999            0.99

D-TAXI            9.75   9.75    -      -      -      5.0   5.0          -     -      -      0.9995       1.0E-7        0.99999          0.999

DYNAV              -       -    17.0   30.0    -       -      -     10.0      20.0    -       0.995       1.0E-3         0.999            0.99

FLIPCY            9.75   9.75   9.75   20.0   9.75    5.0   5.0         5.0   12.5   5.0      0.9995      1.0E-7        0.99999          0.999

FLIPINT           9.75   9.75   9.75   20.0   9.75    5.0   5.0         5.0   12.5   5.0      0.9995      1.0E-7        0.99999          0.999

ITP ACL            -     9.75   9.75   20.0    -       -    5.0         5.0   12.5    -       0.9995      1.0E-7        0.99999          0.999

ITP SURV           -      6.0   6.0    6.0     -       -    2.0         2.0   2.0     -       0.9995      1.0E-7         0.999           0.999

M&S ACL            -     9.75   9.75   20.0    -       -    5.0         5.0   12.5    -       0.9995      1.0E-7        0.99999          0.999

M&S SURV           -      6.0   6.0    6.0     -       -    2.0         2.0   2.0     -       0.9995      1.0E-7         0.999           0.999

PAIRAPP ACL        -     9.75    -      -      -       -    5.0         5.0    -      -       0.9995      1.0E-7        0.99999          0.999

PAIRAPP SURV      4.0     4.0    -      -      -      1.2    1.2         -     -      -      0.99995      1.0E-7         0.999           0.999

PPD               17.0   17.0   17.0   30.0   30.0   10.0   10.0    10.0      20.0   10.0     0.995       1.0E-3         0.999            0.99

SAP                -     9.75   9.75    -      -       -    5.0         5.0    -      -       0.9995      1.0E-7        0.99999          0.999

SURV (ATC)        4.0    10.0   10.0   10.0   10.0    1.2   2.0         2.0   2.0    2.0     0.99995      1.0E-7       0.999995         0.9999

TIS-B              -       -     -      -      -       -      -          -     -      -         -            -             -                  -

URCO              9.75   9.75   9.75   20.0   9.75    5.0   5.0         5.0   12.5   5.0      0.9995      1.0E-5        0.99999          0.999

WAKE              4.0    10.0   10.0    -      -      1.2   2.0         2.0    -      -       0.9995      1.0E-7         0.999           0.999


                       Table 5-5: Phase 2 ATS RCTP Performance Requirements (ATS)




                                                                   85
                                                     COCR Version 2.0

                                                                                          Continuity   Integrity       Availability
                        Expiration Time                         Latency
                                                                                           RCTP         RCTP             RCTP
       Service         RCTP (ET – 1 way)                    RCTP (TT95- 1 way)
                                                                                          (per inst)   (per inst)        (pFH)

                 APT   TMA    ENR        ORP   AOA   APT    TMA     ENR     ORP    AOA      CUIT         IUCT        AP           AU

AOCDLL                                               30.0   30.0    30.0    60.0   60.0                 1.0E-7      0.999         0.99

CABINLOG                                             60.0    -          -    -      -                   1.0E-3      0.999         0.99

ENGINE                                               60.0   60.0    60.0    120.0 120.0                 1.0E-4      0.999         0.99

FLTLOG                                               60.0    -          -    -      -                   1.0E-3      0.999         0.99

FLTPLAN                                              30.0   30.0    30.0    60.0   60.0                 1.0E-7      0.999         0.99

FLTSTAT                                              30.0   30.0    30.0    60.0   60.0                 1.0E-3      0.999         0.99

FREETXT                                              60.0   60.0    60.0    120.0 120.0                 1.0E-3      0.999         0.99

FUEL                                                 60.0   60.0    60.0    120.0 120.0                 1.0E-3      0.999         0.99

GATES                                                30.0   30.0    30.0    60.0   60.0                 1.0E-3      0.999         0.99

LOADSHT                                              30.0   30.0        -    -      -                   1.0E-7      0.999         0.99
                               Not                                                          Not
MAINTPR                                              30.0   30.0    30.0    60.0   60.0                 1.0E-4      0.999         0.99
                             Available                                                    Available
MAINTRT                                              60.0   60.0    60.0    120.0 120.0                 1.0E-4      0.999         0.99

NOTAM                                                60.0   60.0    60.0    120.0 120.0                 1.0E-7      0.999         0.99

OOOI                                                 30.0    -          -    -      -                   1.0E-3      0.999         0.99

POSRPT                                               60.0   60.0    60.0    120.0 120.0                 1.0E-4      0.999         0.99

SWLOAD                                               60.0   60.0    60.0    120.0 120.0                 1.0E-9      0.999         0.99

TECHLOG                                              60.0    -          -    -      -                   1.0E-4      0.999         0.99

UPLIB                                                60.0   60.0    60.0    120.0 120.0                 1.0E-7      0.999         0.99

WXGRAPH                                              30.0   30.0    30.0    60.0   60.0                 1.0E-7      0.999         0.99

WXRT                                                 30.0   30.0    30.0    60.0   60.0                 1.0E-7      0.999         0.99

WXTEXT                                               30.0   30.0    30.0    60.0   60.0                 1.0E-7      0.999         0.99


                             Table 5-6: AOC RCTP Performance Requirements

  5.2.1.3 RCTP Supporting Information

  5.2.1.3.1        One-Way and Two-Way Transaction Requirements
  OPA results only provide two-way technical transaction and expiration times that start
  with an initial message and end with an associated closing operational response. Not
  all operational responses are closing responses, e.g., standby does constitute a closure
  response. Thus, these assessments are necessarily limited to two-way dialogs.

  For a one-way service (e.g., AMC, FLIPINT report), the service latencies should be
  specified. In addition, the use of expiration time and continuity parameters for one-
  way services can be used to provide another constraint on timing performance (in
  addition to a 95th percentile latency).

  The RCTP tables provide one-way latencies and expiration times. For two-way
  services, the one-way latencies and expiration timers are one-half the two-way times.
  For these services, the performance requirements are met when the two-way times are
  met. For example, the Phase 1 ACL service has a latency of 8 seconds. If the two-
  way 95th percentile transaction time is 16 seconds or less, the OPA performance
  requirement is met. For example, initiating message has a transit delay of 10 seconds
  and the closure response has a transit delay of 6 seconds, the ACL technical
  transaction time requirement is met.


                                                                   86
                                 COCR Version 2.0


5.2.1.3.2    Broadcast Requirements
Broadcast services have performance parameter definitions that are analogous but not
identical to two-way operational exchanges. The following performance parameter
definitions and assumptions apply to the SURV, TIS-B and WAKE services in Table
5-3 through Table 5-6.
       Update Interval: This is the time interval within which there is a percentile
       probability of receiving at least one report update.
       Expiration Time: The expiration time is the maximum time between updates
       beyond which a service interruption is declared. It has been set as twice the
       update interval shown in Table 5-3.
       Latency: For SURV, one-way latency is the time taken from the reception of
       the navigational signal (e.g., GNSS) by an aircraft antenna to the output of
       positional information at a Controller position or on an aircraft CDTI. It
       includes the reception of the raw navigational signal, processing of it to
       determine position, transmission of the position information, reception, and
       processing by the surveillance processing system on the ground or in another
       aircraft. For TIS-B, it is the time taken from the input to the surveillance
       source to the display on an aircraft CDTI. For WAKE, it is the time taken
       from sensor(s) output to delivery to the WAKE information processing system.
       Continuity: This is the probability that a system will continue to perform its
       required function without unscheduled interruption, assuming that the system
       is available when the procedure is initiated.

5.2.2 FRS Requirements
The FRS data performance requirements are allocated based on the overall end-to-end
technical data communication requirements.

This section describes the following:
       FRS Boundary Point Description – the boundary point used for the allocation
       of data performance requirements
       Allocation methodology and assumptions
       FRS Allocated Performance Values

5.2.2.1 FRS Boundary Point Description
ATM services are described in an operational context and requirements apply to the
service as a whole including communication systems, automation systems, procedures
and human participation. Ground end points (Controllers, automation systems)
connect to airborne end points (Flight Crew, flight automation systems) via a set of
one or more networks and/or communication systems. The FRS is a system in the
end-to-end communication chain.

The FRS Boundary Point can be described in terms of both physical and logical
perspectives. There are some physical aspects that remain constant regardless of the
technology selection or implementation approach. For example, there will be FRS
communication equipment in the aircraft and on the ground. Other physical aspects


                                         87
                                 COCR Version 2.0


are very technology specific, e.g., the immediate physical interface for the FRS
equipment (examples include T1, RS-232, and proprietary hardware interfaces).
From a logical point of view, the FRS boundary can be illuminated by describing
functions that lie on either side of the interface.

In order to allocate performance requirements to the FRS, one must first define the
interface boundary for the FRS.

5.2.2.1.1   Addressed FRS Boundary Point Description
Since communication networks typically involve multiple communication layers, the
FRS boundary can be described within the context of a communication protocol stack.

The COCR has defined the logical interface to the FRS subnetwork at the boundary
between the internetworking and intranetworking layers of the reference protocol
stack. While the COCR does not specify a required reference protocol stack, Figure
5-1 provides an illustration showing the boundary point within several example
protocol stacks.




                      Figure 5-1: FRS Boundary Point Examples

From a functional point of view, the FRS addressed performance requirements span
the following functional blocks: subnetwork interface function, subnetwork layer,
data link layer, ground and airborne FRS radio units, antennas and RF media.

From a physical point of view, the logical FRS boundary points will likely be located
in the Air-Ground Router (a ground unit) and Airborne Router. Since a ground router
might not be co-located with the FRS radio equipment, it is important to note that
performance contributions associated with such a remote connection (e.g., delays,
availability, integrity) are specifically excluded from the FRS allocated performance
requirements.

5.2.2.1.2   Broadcast FRS Boundary Point Description
For services that can be implemented without a network protocol stack (e.g., TIS-B,
WAKE, SURV), the boundary point is defined at the mobile communication
equipment interface, e.g., radio interface.



                                         88
                                   COCR Version 2.0


5.2.2.2 FRS Allocation Assumptions
Typically, the allocation of performance to communication segments (or systems) is
based, at least in part, on the ability of the particular segment to meet the requirement.
Most safety and performance work has allocated requirements to the ground and
airborne segments with the boundary point at the aircraft antenna. However, this
segment boundary does not align with the boundaries of interest for the FRS. Part of
the FRS system lies within the ground segment and the other part within the airborne
segment. The FRS allocation is made using the end-to-end technical performance
numbers while considering the ATS/Airborne segment allocations made in prior
safety work.

The allocation process used for air-air and AOC services is the same as that used for
ATS services in that the ability of each component, segment or system to meet the
allocated requirement is considered.

The following subsections provide detailed information on the assumptions and
rationale used for allocating latency, integrity, and availability requirements to the
FRS.

5.2.2.2.1    Latency
The RCTP one-way latency requirement is specified in terms of a probability, e.g., a
95% percentile delay. As defined in [13], a statistical analysis should be conducted in
order to properly allocate the performance parameters between system segments
and/or components. Much of the prior allocation work has used an algebraic
allocation methodology, possibly because the statistical distribution of events was not
well characterised.

If statistical allocations were made instead of algebraic ones, the 95% allocation for
each subsystem/component would be larger (assuming use of any one of a number of
common distributions, e.g., normal, exponential, lognormal, Poisson, which might be
applied to message delays for typical systems). Thus, the algebraic allocations are
more restrictive than a statistical allocation method. This more restrictive method can
still result in ‘valid’ allocations if, for example, the resultant allocations are deemed as
reasonable and acceptable by associated stakeholders. For [2], these algebraic
allocations were internationally accepted.

For most services, the COCR assumes a statistical allocation of latency based on a
Poisson distribution. The allocation among system components is done using mean
(average) delay values.

For data services that are characterised as air-ground (includes AOC services), the
major segments in the end-to-end connection include: the ground end/host system
automation segment, the ground network segment, the FRS segment, the airborne end
system (the airborne equipment external to the FRS - refer to the FRS Boundary Point
discussion). The percentage allocations for each of these segments are 25%, 25%,
40%, and 10%, respectively. Details of the allocation process are given in Appendix
E.




                                            89
                                  COCR Version 2.0


For the SURV (all types), WAKE and TIS-B data services, the FRS allocation is
assumed to be 33% for high performance services (e.g., PIARAPP SURV) and 60%
for the remaining services. These allocations are based on [5] and assume a broadcast
service FRS boundary point.

Note: Since the statistical distribution of the air-air delays is not well known, an
algebraic allocation is used.

The allocation percentages for Phase 1 and Phase 2 are the same.

5.2.2.2.2    Integrity
Integrity requirements on the FRS were calculated based on the assumption that it
must contribute no more than 50% of the errors. This generous allocation is made to
the FRS because of significantly higher data error rates associated with RF
transmission.

5.2.2.2.3    Availability
Availability requirements on the FRS were calculated based on the assumption that it
must contribute no more than 50% of the errors. This generous allocation is made to
the FRS because of the impact of interference on operational availability. If it were
not for interference, the allocation to the FRS would be much lower since the
expected inherent availability (equipment performance) is not significantly different
from other communication equipment.

5.2.2.2.4    Continuity & Expiration Time
For most services, continuity and expiration time requirements on the FRS were
calculated by arithmetically allocating 80% of the expiration time to the FRS and
80% of the continuity to the FRS. It is assumed that most unexpected interruptions to
the transaction are due to RF conditions. In addition, the use of an arithmetic
allocation is more appropriate when allocating delays with high confidence levels,
since unpredictable delays may arise from systematic effects such as anomalies in
coverage or handoffs, which are not readily susceptible to purely statistical treatment.

Note: The allocation of continuity and expiration time are the subject of continuing
discussion and refined values are possible in future documents.

5.2.2.2.5    Update Interval
Note: The update interval for broadcast services is not allocatable to communication
segments, e.g., the FRS.

5.2.2.3 FRS Performance Values
Table 5-7, Table 5-8, and Table 5-9 provide the performance requirements for the
FRS.




                                          90
                                                    COCR Version 2.0

                                                                                          Continuity   Integrity            Availability
                          Expiration Time                      Latency
                                                                                           RCTP         RCTP                  RCTP
        Service          RCTP (ET – 1 way)                 RCTP (TT95- 1 way)
                                                                                          (per inst)   (per inst)             (pFH)
                  APT    TMA    ENR    ORP    AOA   APT    TMA     ENR       ORP    AOA     CUIT         IUCT          AP              AU
ACL                8.0   8.0    8.0    60.0    -     3.8   3.8         3.8   26.5    -      0.9965      5.0E-6       0.9995          0.99656

ACM                8.0   8.0    8.0    60.0    -     3.8   3.8         3.8   26.5    -      0.996       5.0E-6       0.9995          0.9965

A-EXEC              -     -      -      -      -      -     -           -     -      -        -            -            -                  -
AIRSEP              -     -      -      -      -      -     -           -     -      -        -            -            -                  -
AIRSEP SURV         -     -      -      -      -      -     -           -     -      -        -            -            -                  -
AMC                8.0   8.0    8.0     -      -     3.8   3.8         3.8    -      -      0.996       5.0E-4       0.9995          0.9965

ARMAND              -     -     24.0    -      -      -     -          9.2    -      -      0.996       5.0E-6       0.9995          0.9965

C&P ACL             -    16.0   16.0   60.0    -      -    5.7         5.7   26.5    -      0.996       5.0E-6       0.9995          0.9965

C&P SURV            -    4.8    4.8    4.8     -      -    1.2         1.2   1.2     -      0.9996      5.0E-8       0.9995          0.9995
COTRAC              -     -      -      -      -      -     -           -     -      -        -            -            -                  -
D-ALERT           16.0   16.0   16.0   60.0    -     5.7   5.7         5.7   26.5    -      0.996       5.0E-6       0.9995          0.9965

D-ATIS            12.0   12.0   12.0   72.0    -     4.7   4.7         4.7   26.5    -      0.996       5.0E-6       0.9995          0.9965
DCL               24.0    -      -      -      -     9.2    -           -     -      -      0.996       5.0E-6       0.9995          0.9965

D-FLUP            24.0    -      -      -      -     9.2    -           -     -      -      0.996       5.0E-4       0.9995          0.9965

DLL               16.0   16.0   16.0   80.0    -     5.7   5.7         5.7   26.5    -      0.996       5.0E-6       0.9995          0.9965

D-ORIS              -    12.0   12.0   72.0    -      -    4.7         4.7   26.5    -      0.996       5.0E-6       0.9995          0.9965
D-OTIS            12.0   12.0   12.0   72.0    -     4.7   4.7         4.7   26.5    -      0.996       5.0E-6       0.9995          0.9965
D-RVR             12.0   12.0   12.0   72.0    -     4.7   4.7         4.7   26.5    -      0.996       5.0E-6       0.9995          0.9965

DSC                 -     -     48.0   57.6    -      -     -      22.2      26.5    -      0.996       5.0E-6       0.9995          0.9965

D-SIG             24.0   24.0    -      -      -     9.2   9.2          -     -      -      0.996       5.0E-6       0.9995          0.9965

D-SIGMET          12.0   12.0   12.0   57.6    -     4.7   4.7         4.7   26.5    -      0.996       5.0E-6       0.9995          0.9965

D-TAXI            16.0   16.0    -      -      -     5.7   5.7          -     -      -      0.996       5.0E-6       0.9995          0.9965

DYNAV               -     -      -      -      -      -     -           -     -      -        -            -            -                  -
FLIPCY            32.0   32.0   32.0   64.0    -    13.6   13.6    13.6      26.5    -      0.996       5.0E-6       0.9995          0.9965

FLIPINT           32.0   32.0   32.0   64.0    -    13.6   13.6    13.6      26.5    -      0.996       5.0E-6       0.9995          0.9965

ITP ACL             -     -      -     60.0    -      -     -           -    26.5    -      0.996       5.0E-6       0.9995          0.9965

ITP SURV            -    4.8    4.8    4.8     -      -    1.2         1.2   1.2     -      0.9996      5.0E-8       0.9995          0.9995
M&S ACL             -    16.0   16.0    -      -      -    5.7         5.7    -      -      0.996       5.0E-6       0.9995          0.9965

M&S SURV            -    4.8    4.8    4.8     -      -    1.2         1.2   1.2     -      0.9996      5.0E-8       0.9995          0.9995
PAIRAPP ACL         -     -      -      -      -      -     -           -     -      -        -            -            -                  -
PAIRAPP SURV        -     -      -      -      -      -     -           -     -      -        -            -            -                  -
PPD               32.0   32.0   32.0   32.0    -    13.6   13.6    13.6      26.5    -      0.996       5.0E-6       0.9995          0.9965

SAP                 -    12.0   12.0    -      -      -    4.7         4.7    -      -      0.996       5.0E-6       0.9995          0.9965

SURV (ATC)         3.2   8.0    16.0   16.0          0.4   1.2         1.2   1.2     -     0.99996      5.0E-8      0.9999975        0.99995
TIS-B              3.2   8.0    16.0   16.0    -     0.4   1.2         1.2   1.2     -     0.99996      5.0E-8      0.9999975        0.99995
URCO                -     -      -      -      -      -     -           -     -      -        -            -            -                  -
WAKE                -     -      -      -      -      -     -           -     -      -        -            -            -                  -


                          Table 5-7: Phase 1 ATS FRS Performance Requirements




   5
       For the ORP domain, the FRS continuity requirement is 0.9995.
   6
       For the ORP domain, the FRS availability of use requirement is 0.9995.


                                                                  91
                                                     COCR Version 2.0

                                                                                           Continuity   Integrity             Availability
                          Expiration Time                       Latency
                                                                                            RCTP         RCTP                   RCTP
        Service          RCTP (ET – 1 way)                  RCTP (TT95- 1 way)
                                                                                           (per inst)   (per inst)              (pFH)

                  APT    TMA    ENR    ORP    AOA    APT    TMA     ENR       ORP    AOA      CUIT        IUCT           AP              AU

ACL               5.0    5.0    5.0    16.0   5.0     1.4   1.4         1.4   5.9    1.4     0.9996      5.0E-8       0.999995         0.9995

ACM               5.0    5.0    5.0    16.0   5.0     1.4   1.4     1.4       5.9    1.4     0.9996      5.0E-8       0.999995         0.9995

A-EXEC             -     1.6    1.6    1.6     -       -    0.74    0.74       -      -    0.99999992   5.0E-10      0.9999999995    0.99999995

AIRSEP             -      -      -      -     7.8      -      -          -     -     2.4     0.9996      5.0E-8       0.999995         0.9995

AIRSEP SURV        -      -      -      -     8.0      -      -          -     -     1.2     0.9996      5.0E-8       0.999995         0.9995

AMC               8.0    8.0    8.0     -     24.0    3.8   3.8         3.8    -     9.2     0.996       5.0E-4        0.9995          0.9965

ARMAND             -      -     13.6    -      -       -      -         4.7    -      -      0.996       5.0E-4        0.9995           0.995

C&P ACL            -     7.8    7.8    16.0    -       -    2.4         2.4   5.9     -      0.9996      5.0E-8       0.999995         0.9995

C&P SURV           -     4.8    4.8    4.8     -       -    1.2         1.2   1.2     -      0.9996      5.0E-8        0.9995          0.9995

COTRAC             -     7.8    7.8    16.0   7.8      -    2.4         2.4   5.9    2.4     0.9996      5.0E-8       0.999995         0.9995

D-ALERT           7.8    7.8    7.8    16.0   7.8     2.4   2.4         2.4   5.9    2.4     0.9996      5.0E-6       0.999995         0.9995

D-ATIS            7.8    7.8    7.8    24.0   24.0    2.4   2.4         2.4   9.2    9.2     0.996       5.0E-8        0.9995           0.995

DCL               24.0    -      -      -      -      9.2     -          -     -      -      0.9996      5.0E-8       0.999995         0.9995

D-FLUP            7.8    7.8    13.6   24.0   24.0    2.4   2.4         4.7   9.2    9.2     0.996       5.0E-4        0.9995           0.995

DLL               7.8    7.8    13.6   24.0   24.0    1.4   2.4         4.7   9.2    9.2     0.9996      5.0E-8       0.999995         0.9995

D-ORIS             -     7.8    7.8    24.0   24.0     -    2.4         2.4   9.2    9.2     0.996       5.0E-8        0.9995           0.995

D-OTIS            7.8    7.8    7.8    24.0   24.0    2.4   2.4         2.4   9.2    9.2     0.996       5.0E-8        0.9995           0.995

D-RVR             5.0    5.0    7.8    24.0   24.0    1.4   1.4         2.4   9.2    9.2     0.996       5.0E-8        0.9995           0.995

DSC                -      -     24.0   16.0   24.0     -      -         9.2   22.2   9.2     0.9996      5.0E-8       0.999995         0.9995

D-SIG             13.6   13.6    -      -      -      4.7   4.7          -     -      -      0.996       5.0E-8        0.9995           0.995

D-SIGMET          7.8    7.8    7.8    24.0   24.0    2.4   2.4         2.4   9.2    9.2     0.996       5.0E-8        0.9995           0.995

D-TAXI            7.8    7.8     -      -      -      2.4    2.4         -     -      -      0.9996      5.0E-8       0.999995         0.9995

DYNAV              -      -     13.6   24.0    -       -      -         4.7   9.2     -      0.996       5.0E-4        0.9995           0.995

FLIPCY            7.8    7.8    7.8    16.0   7.8     2.4   2.4         2.4   5.9    2.4     0.9996      5.0E-8       0.999995         0.9995

FLIPINT           7.8    7.8    7.8    16.0   7.8     2.4   2.4         2.4   5.9    2.4     0.9996      5.0E-8       0.999995         0.9995

ITP ACL            -     7.8    7.8    16.0    -       -    2.4         2.4   5.9     -      0.9996      5.0E-8       0.999995         0.9995

ITP SURV           -     4.8    4.8    4.8     -       -    1.2         1.2   1.2     -      0.9996      5.0E-8        0.9995          0.9995

M&S ACL            -     7.8    7.8    16.0    -       -    2.4         2.4   5.9     -      0.9996      5.0E-8       0.999995         0.9995

M&S SURV           -     4.8    4.8    4.8     -       -    1.2         1.2   1.2     -      0.9996      5.0E-8        0.9995          0.9995

PAIRAPP ACL        -     7.8     -      -      -       -     2.4        2.4    -      -      0.9996      5.0E-8       0.999995         0.9995

PAIRAPP SURV      3.2    3.2     -      -      -      0.4    0.4         -     -      -     0.99996      5.0E-8        0.9995          0.9995

PPD               13.6   13.6   13.6   24.0   24.0    4.7   4.7         4.7   9.2    4.7     0.996       5.0E-4        0.9995           0.995

SAP                -     7.8    7.8     -      -       -    2.4         2.4    -      -      0.9996      5.0E-8       0.999995         0.9995

SURV (ATC)        3.2    8.0    8.0    8.0    8.0     0.4   1.2         1.2   1.2    1.2    0.99996      5.0E-8       0.9999975        0.99995

TIS-B              -      -      -      -      -       -      -          -     -      -        -            -             -                  -

URCO              7.8    7.8    7.8    16.0   7.8     2.4   2.4         2.4   5.9    2.4     0.9996      5.0E-6       0.999995         0.9995

WAKE              3.2    8.0    8.0     -      -      0.4   1.2         1.2    -      -      0.9996      5.0E-8        0.9995          0.9995


                          Table 5-8: Phase 2 ATS FRS Performance Requirements




                                                                   92
                                                     COCR Version 2.0

                                                                                          Continuity   Integrity        Availability
                        Expiration Time                         Latency
                                                                                           RCTP         RCTP              RCTP
       Service         RCTP (ET – 1 way)                    RCTP (TT95- 1 way)
                                                                                          (per inst)   (per inst)         (pFH)

                 APT   TMA    ENR        ORP   AOA   APT    TMA     ENR     ORP    AOA      CUIT         IUCT        AP            AU

AOCDLL                                               13.6   13.6    13.6    26.5   26.5                 5.0E-8      0.9995        0.995

CABINLOG                                             26.5    -          -    -      -                   5.0E-4      0.9995        0.995

ENGINE                                               26.5   26.5    26.5    51.7   51.7                 5.0E-5      0.9995        0.995

FLTLOG                                               26.5    -          -    -      -                   5.0E-4      0.9995        0.995

FLTPLAN                                              13.6   13.6    13.6    26.5   26.5                 5.0E-8      0.9995       0.9995

FLTSTAT                                              13.6   13.6    13.6    26.5   26.5                 5.0E-4      0.9995        0.995

FREETXT                                              26.5   26.5    26.5    51.7   51.7                 5.0E-4      0.9995        0.995

FUEL                                                 26.5   26.5    26.5    51.7   51.7                 5.0E-4      0.9995        0.995

GATES                                                13.6   13.6    13.6    26.5   26.5                 5.0E-4      0.9995        0.995

LOADSHT                                              13.6   13.6        -    -      -                   5.0E-8      0.9995        0.995
                               Not                                                          Not
MAINTPR                                              13.6   13.6    13.6    26.5   26.5                 5.0E-5      0.9995        0.995
                             Available                                                    Available
MAINTRT                                              26.5   26.5    26.5    51.7   51.7                 5.0E-5      0.9995        0.995

NOTAM                                                26.5   26.5    26.5    51.7   51.7                 5.0E-8      0.9995        0.995

OOOI                                                 13.6    -          -    -      -                   5.0E-4      0.9995        0.995

POSRPT                                               26.5   26.5    26.5    51.7   51.7                 5.0E-5      0.9995        0.995

SWLOAD                                               26.5   26.5    26.5    51.7   51.7                5.0E-10      0.9995        0.995

TECHLOG                                              26.5    -          -    -      -                   5.0E-5      0.9995        0.995

UPLIB                                                26.5   26.5    26.5    51.7   51.7                 5.0E-8      0.9995        0.995

WXGRAPH                                              13.6   13.6    13.6    26.5   26.5                 5.0E-8      0.9995        0.995

WXRT                                                 13.6   13.6    13.6    26.5   26.5                 5.0E-8      0.9995        0.995

WXTEXT                                               13.6   13.6    13.6    26.5   26.5                 5.0E-8      0.9995        0.995


                  Table 5-9: FRS Allocated Data Performance Requirements (AOC)




                                                                   93
                                 COCR Version 2.0



6 COMMUNICATION LOADING ANALYSES
6.1 Introduction
This section provides an estimate of the FRS communication load associated with
ATS and AOC services. The purpose of the loading estimate is to facilitate
operational service evaluation and FRS technology assessment. Although this
estimate is based on one set of reasonable assumptions, an equally reasonable but
alternate set of assumptions may result in a different estimate.

The first major assumption divides the loading analysis into three major pieces:
       Voice Loading Analysis
       Addressed Data Loading Analysis
       Broadcast Data Loading Analysis
Section 6.2 documents the detailed assumptions used in each of the three FRS loading
analyses. The section includes assumptions about broadcast versus addressed data
service implementations, the aggregation and prioritization of information flows,
operational volumes, user quantities, operational service utilization rates, message
sizes, equipage, and other related information.

Each analysis estimates the information transfer rate needed for each operational
volume. It should be clearly understood that the analyses contained in this section are
intended to be technology independent. The capacity requirements are intended to
provide a sense of overall information transfer rates and not the required RF bit
transmission rates.    Since coverage volumes associated with communication
technologies can be varied, the COCR uses operational volumes. Two types of
operational volumes are defined: a service volume and a transmission volume.
Service volumes are used for addressed communication. Transmission volumes are
used for broadcast communication. A transmission volume is based on operational
need and not on technology capabilities. Once loading estimates are established for
an operational volume, traffic rates and capacities for communication technology
coverage volumes can be developed.

The Voice Loading Analysis is presented in Section 6.3. The analysis estimates the
utilization of the party line voice channel for a service volume. The voice utilization
rates are moderated based on anticipated data utilization rates. While use of data
communications reduces voice channel occupancy, this analysis insures that the
increase in air traffic per sector/position can still be accommodated by the existing
party line channel. While the COCR does not require any new voice services, this
section provides voice access rates and durations which can be used to assess alternate
voice service technologies.

The Addressed Data Loading Analysis is presented in Section 6.4. This analysis
provides the estimated communication load associated with addressed data
communications in a service volume. Various combinations of information flows are
analyzed. ATS and AOC traffic load is evaluated separately and together. Uplink
and downlink transmissions are evaluated separately and together. A queueing



                                          94
                                 COCR Version 2.0


model, service classes, and service priorities are assumed to estimate the required
information transfer rate.

The Broadcast Data Loading Analysis is presented in Section 6.5. This analysis looks
at broadcast communication loading associated primarily with surveillance services,
e.g., SURV, TIS-B and WAKE. This analysis assumes a shared channel and uses a
transmission volume.

Each analysis includes a description of the estimating methodology, the estimated
communication load, and an analysis of the results.

6.2 Loading Analyses Assumptions
The communication loading analyses are based on a number of assumptions. The
assumptions are grouped into two major sets:
       Operational and Environmental Assumptions: These include service usage
       information in an operational context. Information on equipage and number of
       users is provided. These assumptions are independent of communication
       technology.
       Communication Implementation Assumptions:                  These include
       implementation assumptions necessary to estimate communication loading.
       Assumptions are made about whether a service uses an addressed or broadcast
       implementation. Information on network management, classes of service,
       message quantities, and message sizes are provided.
The next two sections provide details on each set of assumptions.

6.2.1 Operational and Environmental Assumptions
The following operational and environmental assumptions are used by one or more of
the communication loading analyses.
       Operational Volume:        Operational volumes provide the context for
       identifying the number of users and for developing service usage information.
       Two types of services volumes are defined: service volumes and transmission
       volumes.
       Service Instances: The service instances represent the typical number of
       times a service is used within an operational volume.
       Flight Duration per Service Volume: The flight durations for each service
       volume are provided. The service instances and flight duration per service
       volume are used to develop average message arrival rates. Average message
       arrival rates are used within the Addressed Data Loading Analysis.
       Equipage and Voice/Data Utilisation:          Service utilisation rates are
       dependent on whether users are equipped to use a particular service.
       Number of Users: The Peak Instantaneous Aircraft Count (PIAC) represents
       worst case number of users for a given operational volume. The number of
       Daily Operations per Domain is also provided.



                                         95
                                 COCR Version 2.0


6.2.1.1 Operational Volumes
An operational volume (OV) is a defined operational area in which services are
provided. Operational volumes are defined within each of the airspace domains. The
COCR defines two types of operational volumes:
       Service Volume (SV): A volume of airspace that aligns with ATC
       sector/position control boundaries. For all domains except the APT, it is a
       volume of airspace in which all aircraft are controlled by a single Controller
       position. For the APT, the service volume encompasses all APT airspace
       sectors/positions in the domain. Although the volume boundaries align with
       controlled airspace, the COCR evaluates all types of communication in this
       area including flight information services, controller-pilot communication, and
       aircraft-provided state/intent data. Service volumes provide the operational
       context for addressed services.
       Transmission Volume (TV): A volume of airspace that is based on range or
       distance. Transmission volumes are most applicable for broadcast services,
       because broadcasted services reach all users within the range of the broadcast.
       In the COCR, ranges are based on operational need and not the capabilities of
       a particular technology.
While these volumes have an operational context, the volume may or may not be well
matched to a particular communication technology. The designated operational
coverage (DOC) for a particular technology will be dependent on the characteristics
of that technology, e.g., power, frequency, bit rate. The aim is to identify a
communication ‘density’ requirement for each coverage volume independent of
communications technology. By combining the operational volumes into typical
DOC for technologies the communication requirement can be obtained per DOC.
Knowledge of the deployment of operational volumes is important and sufficient
details need to be provided to enable technology choices to be matched to the
communication requirement.

6.2.1.1.1    Service Volumes
A typical flight may cross several airspace domains including APT, TMA, ENR, ORP
and/or AOA.

In the case of the Airport service volume, the entire domain was used as the volume
rather than a single position; thus, this volume includes the clearance/ramp position,
the ground position, and the tower/runway position. The airport service volume
equates to a cylinder, 10 miles in diameter, from ground to an altitude of 5,000 feet.

The sizes of service volumes for Phase 1 are equivalent to control positions/sectors in
existence today. Use of the new operational services in Phase 1 will allow higher
numbers of aircraft to be serviced in the same volume. For Phase 2, it is assumed the
TMA, ENR and ORP service volumes are about three times the size used in Phase 1.

Note: In the En Route domain, an ATSU will have more than 1 sector, but a given
aircraft will only fly through 1 sector in each ATSU due to the size expansion.




                                          96
                                    COCR Version 2.0


As these types of airspace can vary widely in their requirements depending on the
level of air traffic, for each service volume a typical high-density and low-density
example was defined. The autonomous service volume is the only volume that does
not include high and low density examples.

6.2.1.1.2      Transmission Volumes
Transmission volumes apply to broadcasted services. The COCR defines two types
of transmission volumes:
       Domain-Based Volume: These volumes assume each domain is separate and
       independent from the others. In other words, while the TMA and ENR
       domains may overlap from a transmission range standpoint, the analysis
       assumes the transmissions from an aircraft in the TMA but near the boundary
       of ENR do not interfere with transmissions in the ENR domain.
       Fixed Range Volume: These volumes do not consider domain boundaries
       and are based sole on transmission range. The COCR only considers fixed
       range volumes that span the APT, TMA, and ENR domains.
Table 6-1 describes the transmission ranges for each volume.


            Transmission                         Range (NM)
              Volume          APT        TMA        ENR        ORP       AOA
      Air-Air SURV              5         60         100           100    100
      Air-Ground SURV           5         100        200           200     -
      100 NM Fixed Range                  100                       -      -
      150 NM Fixed Range                  150                       -      -

                           Table 6-1: Transmission Volume Ranges

6.2.1.2 Service Instances
Table 6-2 to Table 6-4 provide the expected number of usage instances for ATS and
AOC data services in Phase 1 and Phase 2.

For ATS instances, usage is provided on a per aircraft per service volume basis except
for the A-EXEC and AMC services (see ** in tables) which are provided on a per
ATSU basis (not per aircraft). To translate these services into a per aircraft per
service volume basis, one must know the number of aircraft, i.e., operations, that are
served by the ATSU over the applicable timeframe (e.g., one year or one week). See
Section 6.2.1.5.3 for the number of operations per ATSU.

For Phase 2, Table 6-3 also provides two columns to present service instance
applicability for each of the two types of data communications equipped aircraft, i.e.,
basic data communications (Type I) and COTRAC equipped (Type II), as described
in Section 6.2.1.4. For example, the ARMAND service continues to be used by basic
data communications equipped aircraft in Phase 2. However, this service is typically
not used by COTRAC equipped aircraft in Phase 2, because COTRAC functionality
supersedes the need to use this service.



                                            97
                                               COCR Version 2.0


Note: In Phase 2 sector sizes have become larger than Phase 1. In the ENR domain,
an ATSU will have more than 1 sector, but a given aircraft will only fly through 1
sector in each ATSU due to the size expansion.

For the AOC instances, it is assumed that the number of instances is the same in
Phase 1 and Phase 2; however, the number of messages per instance and/or the
message sizes may be different in each phase.

Service                      APT                        TMA                        ENR                      ORP
ACL                  1 (in ground position),      2 per sector, both           5 per domain              2 per domain
                       both departure and        departure and arrival
                              arrival
ACM                    3 per domain (1 in         1 per sector, both            1 per sector              1 per sector
                      each position), both       departure and arrival
                      departure and arrival
A-EXEC                           -                          -                         -                         -

AIRSEP                          -                           -                         -                         -
AIRSEP SURV                     -                           -                         -                         -
AMC**                1 per ATSU, per week        1 per ATSU, per week      1 per ATSU, per week                0
(per ATSU)
ARMAND                         0                           0               1 per domain, arrival               0
                                                                                   only
C&P                            0                           0                   1 per domain              1 per domain
C&P SURV                       0                           0                  Once every 3 s            Once every 3 s
COTRAC                          -                           -                         -                         -
D-ALERT              1 per aircraft per year     1 per aircraft per year   1 per aircraft per year   1 per aircraft per year
D-ATIS (Arrival)               0                  1 per domain arrival      1 per domain arrival               0
                                                   for 70% of aircraft       for 70% of aircraft
D-ATIS (Departure)   1 (in ramp position),                 0                         0                         0
                      departure only for
                        70% of aircraft
DCL                  1 (in ramp position),                 0                         0                         0
                        departure only
D-FLUP               1 (in ramp position),                 0                         0                         0
                        departure only
DLL                  1 (in ramp position),                 0               1 per domain 30% of       1 per domain, 30% of
                        departure only                                            the time                  the time
D-ORIS                        0                            0                   1 per domain              1 per domain
D-OTIS               1 (in ramp position),        1 per domain, arrival    1 per domain for 30%                0
                      departure only for             only for 30% of             of aircraft
                        30% of aircraft                  aircraft
D-RVR                1 (in ramp position),       1 per domain, 30% of      1 per domain, 30% of                0
                       30% of the time,          the time during arrival   the time during arrival
                        departure only
DSC                           0                            0                   1 per domain              1 per domain
D-SIG                 1 (in ramp position),      1 per domain, arrival               0                         0
                         departure only                   only
D-SIGMET              1 (in ramp position),      1 per domain, 30% of      1 per domain, 30% of      1 per domain, 30% of
                        30% of the time,            the time during               the time                  the time
                         departure only                  arrival
D-TAXI               1 (in ground position),     1 per domain, arrival               0                         0
                       both departure and                 only
                              arrival
DYNAV                            -                          -                         -                         -
FLIPCY               1 (in ramp position),           1 per domain,             1 per domain              1 per domain
                        departure only               departure only
FLIPINT              1 (in ramp position),            1 per domain              1 per ATSU                6 per sector
                        departure only
ITP                           0                            0                         0                   1 per domain




                                                         98
                                                         COCR Version 2.0


      Service                           APT                       TMA                            ENR                         ORP
      ITP SURV                             0                            0                           0                  Once every 3 s
      M&S                                  0               1 per domain arrival         1 per domain arrival                  0
                                                                   only                         only
      M&S SURV                             0                  Once every 3 s               Once every 3 s                     0
      PAIRAPP ACL                          -                            -                           -                         -

      PAIRAPP SURV                         -                            -                           -                         -
      PPD                        1 (in ramp position),      1 per domain, both              1 per domain                1 per domain
                                    departure only         departure and arrival
      SAP (Contract                       0                    1 per ATSU                      1 per ATSU                     0
      Establishment)
      SAP (Periodic Report)                0                  Once every 10 s             Once every 10 s                     0
                                                                                          30% of the time
      SURV (ATC)                    Once every 2 s            Once every 5 s              Once every 10 s              Once every 10 s
      TIS-B                         Once every 2 s            Once every 5 s              Once every 10 s                     -
      URCO                                 -                            -                           -                         -
      WAKE                                 -                            -                           -                         -


                                Table 6-2: Phase 1 ATS Service Instances per Aircraft

                       Type7                                                                                                          AOA
Service                                  APT                     TMA                    ENR                    ORP
                       I   II                                                                                                     (Type II only)

ACL                    X   X        Type I&II: 1 (in       Type I&II: 2 per         Type I: 5 per           Type I: 2 per                0
                                 ground position), both       sector, both             domain                  domain
                                  departure and arrival      departure and          Type II: 1 per          Type II: 1 per
                                                                 arrival               domain                  domain
ACM                    X   X       3 per domain (1 in      1 per sector, both        1 per sector            1 per sector           1 per domain
                                  each position), both       departure and                                                        (in buffer zone)
                                  departure and arrival          arrival
A-EXEC**               -   X                0                1 per year per         1 per year per                0                      0
(per ATSU)                                                       ATSU                  ATSU
AIRSEP                 -   X               0                        0                      0                      0                2 per domain

AIRSEP                 -   X               0                        0                      0                      0               Once every 5 s
SURV
AMC**                  X   X     1 per week per ATSU         1 per week per         1 per week per                0                      0
(per ATSU)                                                       ATSU                   ATSU

ARMAND                 X   -               0                        0               1 per domain,                 0                      0
                                                                                     arrival only
C&P ACL                X   -               0                        0               1 per domain            1 per domain                 0
C&P SURV               X   -               0                        0              Once every 3 s           Once every 3 s               0
COTRAC8                -   X      1 (in ramp position)       1 per domain,           1 per sector            1 per sector         1 per domain in
                                     departure only          departure only                                                       the buffer zone
D-ALERT                X   X     1 per aircraft per year    1 per aircraft per     1 per aircraft per   1 per aircraft per               0
                                                                  year                    year                year
D-ATIS                 X   X               0                1 per domain on        1 per domain on              0                        0
(Arrival)                                                   arrival for 30%         arrival for 30%
                                                               of aircraft             of aircraft
D-ATIS                 X   X      1 (in ramp position),             0                       0                     0                      0
(Departure)                      departure only for 30%
                                        of aircraft
DCL                    X   -      1 (in ramp position),             0                      0                      0                      0
                                     departure only



      7
        Type I aircraft have basic data link equipage. Type II aircraft have COTRAC equipage. An ‘X’ in
      the column indicates the instances are applicable to that type of aircraft. A ‘-‘ in the column indicates
      the instances are not applicable for that type of aircraft.
      8
        For Type II aircraft, 75% of the COTRAC exchanges are WILCO’d and 25% of them require a
      negotiation. When COTRAC is not available, aircraft will use Phase 1 services.


                                                                   99
                                                 COCR Version 2.0


                 Type7                                                                                                  AOA
Service                            APT                    TMA                  ENR                  ORP
                 I   II                                                                                             (Type II only)

D-FLUP           X   X      1 (in ramp position),            0                    0                    0                   0
                               departure only
DLL              X   X      1 (in ramp position),            0             1 per domain,        1 per domain,         1 per domain
                               departure only                             30% of the time      30% of the time      (in buffer zone)
D-ORIS           X   X               0                       0             1 per domain         1 per domain                0
D-OTIS           X   X      1 (in ramp position),      1 per domain,      1 per domain for             0                   0
                           departure only for 70%     arrival only for     arrival for 70%
                                  of aircraft         70% of aircraft         of aircraft
D-RVR            X   X      1 (in ramp position),      1 per domain,        1 per domain,              0                   0
                              30% of the time,       30% of the time,     30% of the time,
                               departure only           arrival only         arrival only
DSC              X   -                 0                      0             1 per domain        1 per domain               0
D-SIG            X   X      1 (in ramp position),     1 per domain,               0                    0                   0
                               departure only          arrival only
D-SIGMET         X   X      1 (in ramp position),     1 per domain,        1 per domain         1 per domain               0
                              30% of the time,       30% of the time,     30% of the time      30% of the time
                               departure only          arrival only
D-TAXI           X   X     1 (in ground position),    1 per domain,               0                    0                   0
                            departure and arrival      arrival only
DYNAV            -   X                0                     0             1 per domain for     1 per domain for            0
                                                                           30% of aircraft      30% of aircraft
FLIPCY           X   -      1 (in ramp position),     1 per domain,         1 per domain         1 per domain              0
                               departure only         departure only
FLIPINT          X   X      1 (in ramp position),      1 per domain         1 per ATSU           1 per ATSU           1 per domain
                               departure only                                                                       (in buffer zone)
ITP ACL          X   -               0                1 per domain,        1 per domain         1 per domain                0
                                                       arrival only
ITP SURV         X   -               0                Once every 3 s      Once every 3 s       Once every 3 s              0

M&S ACL          X   -               0                1 per domain,        1 per domain                0                   0
                                                       arrival only
M&S SURV         X   -               0                Once every 3 s      Once every 3 s               0                   0
PAIRAPP          -   X               0                 1 per domain               0                    0                   0
                                                     arrival only, 20%
                                                         of the time
PAIRAPP          -   X        Once every 2 s          Once every 2 s              0                    0                   0
SURV
PPD              X   X      1 (in ramp position),     1 per domain,        1 per domain         1 per domain               0
                               departure only         departure and
                                                          arrival
SAP (Contract    X   -               0                 1 per ATSU           1 per ATSU                 0                   0
Establishment)
SAP (Periodic    X   -               0               Once every 10 s      Once every 10 s              0                   0
Report)                                                                   30% of the time
SURV             X   X        Once every 2 s          Once every 5 s      Once every 5 s       Once every 5 s       Once every 5 s
TIS-B            -   -                -                      -                    -                    -                   -
URCO             -   X     1 per aircraft per year   1 per aircraft per   1 per aircraft per   1 per aircraft per          0
                                                           year                 year                 year
WAKE             X   X        Once every 2 s          Once every 5 s       Once every 5 s               -                  -


                          Table 6-3: Phase 2 ATS Service Instances per Aircraft




                                                           100
                                               COCR Version 2.0



                                                     PHASE 1/2                                                 PHASE 2
Service
                      APT                    TMA                       ENR                  ORP                  AOA
AOCDLL            1 per ramp dep                0                        0              1 per domain                0

CABINLOG          1 per ramp arr                0                        0                    0                     0

ENGINE                   0                1 per domain         1 per domain (when             0                     0
                                                                 cruise altitude is
                                                                     reached)

FLTLOG            1 per ramp arr                0                        0                    0                     0

FLTPLAN           1 per ramp dep                0                   1 per domain        1 per domain          1 per domain

FLTSTAT                  0                      0                   1 per domain        1 per domain          2 per domain

FREETEXT                 0                      0                   2 per domain        2 per domain          1 per domain

FUEL                     0                1 per domain              2 per domain        2 per domain          2 per domain

GATES                    0                      0               1 at top of descent           0                     0

LOADSHT           2 per ramp dep       1per domain, arrival              0                    0                     0
                                              only

MAINTPR                  0                      0               1 per domain for      1 per domain for      1 per domain for
                                                                  5% of flights         5% of flights         5% of flights

MAINTRT                  0                      0                   2 per domain        2 per domain          2 per domain

NOTAM             1 per ramp dep                0                   2 per domain        2 per domain                0

OOOI                1 ramp dep                  0                        0                    0                     0
                   1 rwy takeoff
                   1 rwy landing
                     1 ramp arr

POSRPT                   0                Every 15 min              Every 15 min        Every 15 min          Every 15 min

SWLOAD            1 per ramp dep                0                        0                    0                     0

TECHLOG           1 per ramp dep                0                        0                    0                     0

UPLIB             1 per ramp dep                0                        0                    0                     0

WXGRAPH           1 per ramp dep                0                   Every 20 min        Every 40 min          Every 20 min

WXRT            Takeoff: 1 rpt every    Climb/descend: 1        Climb/descend: 1      Cruise: 1 rpt every   Cruise: 1 rpt every
                        6s                rpt every 60s          rpt every 60s9             3 min                 3 min
                                                                Cruise: 1 rpt every
                                                                      3 min

WXTEXT            1 per ramp dep                0                   2 per domain        2 per domain          1 per domain


                             Table 6-4: AOC Service Instances per Aircraft10




  9
    In TMA domain, there is no cruise portion (aircraft are either climbing or descending). In the ER
  domain Phase 1, assume ½ the time aircraft are in climb/descend and the remaining ½ aircraft are in
  cruise mode. In Phase 2 leave the time for climb/descend the same and increase the cruise time to fit
  the sector duration time.
  10
     Abbreviations: dep = departure, arr = arrival, rpt = report, rwy = runway


                                                              101
                                           COCR Version 2.0


    6.2.1.3 Flight Duration per Service Volume
    The flight duration per service volume were estimated in tandem with evaluation of a
    typical flight profile. The number of sectors and ATSUs traversed in each domain
    were also estimated. Table 6-5 provides a summary of this information.


             Phase                    APT
Type                                                            TMA           ENR          ORP         AOA
             Density    Ramp         Ground           Tower
                            3690 s (dep) [61.5 min]           486 s (dep)    5400 s
             P1-HD
                            1290 s (arr) [21.5 min]           848 s (arr)    [1.5 hr]     15300 s
                                                                                                       N/A
                            2310 s (dep) [38.5 min]           378 s (dep)    5400 s      [4.25 hr]
             P1-LD
Domain                       630 s (arr) [10.5 min]            660 (arr)     [1.5 hr]
Flight
Time                        2790 s (dep) [46.5 min]           388 s (dep)    4920 s
             P2-HD
                            1110 s (arr) [18.5 min]           678 s (arr)   [1.35 hr]     15300 s     5400 s
                            1410 s (dep) [23.5 min]           302 s (dep)    4920 s      [4.25 hr]    [1.5 hr]
             P2-LD
                              570 s (arr) [9.5 min]            528 (arr)    [1.35 hr]
             P1-HD                     3                          2             8
#Sectors/                                                                                    6         N/A
Positions    P1-LD        2 (ramp & ground combined)              1             6
Traversed    P2-HD                     3                          2             5
per Flight                                                                                   4           1
             P2-LD        2 (ramp & ground combined)              1             4
#ATSUs
Traversed     ALL                      1                          1             4            2         N/A
per Flight
                         2700 s                                               675 s
                                     720 s (dep)              243 s (dep)
             P1-HD        (dep)                       270 s                  [11.25
                                     480 s (arr)              424 s (arr)
                       540 s (arr)                                            min]        2550 s
                                                                                                       N/A
                         1800 s                                                          [42.5 min]
                                     360 s (dep)              378 s (dep)     900 s
Sector/      P1-LD        (dep)                       150 s
Position                             240 s (arr)               660 (arr)    [15 min]
                       240 s (arr)
Flight
Time                     1800 s
                                     720 s (dep)              194 s (dep)     984 s
             P2-HD        (dep)                       270 s                               3825 s      5400 s
                                     480 s (arr)              339 s (arr)   [16.4 min]
                       360 s (arr)
                                                                                          [63.75       [90
                       900 s (dep)   360 s (dep)              302 s (dep)    1230 s        min]        min]
             P2-LD                                    150 s
                       180 s (arr)   240 s (arr)               528 (arr)    [20.5 min]

              Table 6-5: Phase 1 and 2 Flight Durations and Sectors/ATSUs Traversed

    The APT service volume was split into flight duration for each position
    (clearance/ramp, ground, and tower/runway), as was the case for PIACs and service
    instances. Different durations were assigned, based on whether the aircraft was in
    departure mode or arrival mode in the APT for a particular flight. While the flight
    durations for the ground and tower positions are the same in Phase 1 and Phase 2, it is
    expected that the clearance/ramp flight duration will be shorter in Phase 2 due to more
    efficient turn-around.


                                                   102
                                    COCR Version 2.0


For the TMA and ENR domains, it is assumed that domain flight times in Phase 2 are
reduced due to better planning and the use of 4D trajectories which provide more
direct routing. For the ENR domain, the Phase 2 sector sizes have become larger than
Phase 1, thereby reducing the number of sectors traversed. An ENR ATSU will have
a number of sectors, but a given aircraft will only fly through 1 sector (on average)
due to the sector size expansion.

6.2.1.4 Equipage and Voice/Data Utilisation
Table 6-6 provides assumptions for data communications equipage and ATS voice vs.
data service utilisation. For loading purposes, it is assumed that 100% of the aircraft
in all domains are equipped to support AOC data communication and that AOC voice
communication is so limited that it does not contribute to system loading.

                  Phase      APT          TMA          ENR          ORP        AOA
% Data              1         75%          75%         75%          80%          -
communications
Equipage            2         85%          85%         100%         100%       100%

% Services          1         60%          60%         40%           5%          -
conducted using
Voice               2         15%          15%          5%           1%         1%


             Table 6-6: ATS Service Equipage and Voice/Data Utilisation Rate

The data communications equipage percentages reflect the assumed number of
aircraft with some form of data communications equipage. It is anticipated that there
may be two levels of data communications functionality. While the link technology
itself is assumed to be the same for all equipped aircraft, some of the aircraft will
continue to support only Phase 1 types of services in Phase 2 APT and TMA domains.

It is also anticipated that 20% of the data communications equipped aircraft in these
domains have basic equipage, i.e., do not support COTRAC, DYNAV, URCO,
PAIRAPP, AIRSEP, and A-EXEC and are referred to as Type I aircraft in the loading
analysis. Of the remaining 80%, 75% will provide simple WILCO responses to the
COTRAC message while 25% negotiate the COTRAC utilising the message sequence
structure for COTRAC described in Section 2. These latter aircraft are referred to as
Type II aircraft.

The difference in the ENR/ORP/AOA versus TMA/APT data communications
equipage figures in Table 6-6 is from the belief that in Phase 2, ENR/ORP/AOA
airspace is assumed to mandate data communications equipage. In TMA/APT, some
unequipped aircraft will continue to operate mixed in with data communications
equipped aircraft due to business case considerations. These unequipped aircraft
remain in the TMA for the cruise phase of flight. Some high density TMAs will be
classified as mandatory equipage during peak periods. The net TMA equipage is
assumed to be 85%.

While Table 6-6 provides the anticipated equipage and data utilisation percentages
(on average), the addressed and broadcast data loading analyses assume 100% for all
service volumes in order to generate worst case loading result. It also should be noted


                                          103
                                 COCR Version 2.0


that the ATS and AOC data instances provided in Section 6.2.1.2 already take the
voice/data utilisation into account. The voice loading analysis uses both the data
communications equipage and ATS voice vs. data service utilisation rates to estimate
voice loading.

6.2.1.5 Number of Users
This section includes information on:
       Service Volume PIACs
       Transmission Volume PIACs
       Daily Operations Per Domain
Most service instances are provided on a per aircraft basis. The service instances per
aircraft are multiplied by the service volume PIACs to get the total instances per
service volume. Instances for two services are provided on an ATSU basis, i.e., A-
EXEC and AMC. The daily operations per ATSU are provided in order to derive the
associated message arrival rates.

6.2.1.5.1    Service Volume PIACs
The service volume PIACs are based on projections produced by two separate
computer-based air traffic models as well as some estimates from subject matter
experts to account for new airspace types (e.g., the AOA) and projected growth in
sectors not accounted for in the referenced computer models. This section first
introduces the computer models and the model predictions. It subsequently provides
the final estimated/extrapolated service volume PIACs.

Two separate computer models were used to estimate PIACs for airspace volumes in
Phase 1 and Phase 2. These were:
       EUROCONTROL’s System for Traffic Assignment and Analysis at a
       Macroscopic Level (SAAM) tool which can simulate air traffic and provide
       data about the traffic through specified airspace volumes. See Appendix A for
       a description of SAAM.
       The MITRE Corporation’s Center for Advanced Aviation System
       Development Mid Level Model uses a traffic demand forecasting known as
       the Terminal Area Forecast (TAF), which is a compilation of scheduled airline
       flights growth. TAF baseline data is benchmarked for 2004 by the FAA. TAF
       is further refined through the observations of the Enhanced Traffic
       Management System to determine unscheduled traffic. The model provides
       PIAC counts for 2004, 2013 and 2020. The PIAC counts for 2030 are
       extrapolated. See Appendix B for further details.
These two models complemented each other. The SAAM model is constrained by the
growth in airport traffic and can supply information on all ‘flow-control sectors’
throughout the European Civil Aviation Conference (ECAC).

The Mid-Level Model (MLM) supplied information on aircraft numbers operating in
En Route sectors over the United States (U.S.) in the 2020 timeframe based on current
practices. The National Airspace System (NAS) MLM modelling concept was to


                                         104
                                       COCR Version 2.0


move the additional traffic to satellite airports. This is consistent with the U.S. Next
Generation Air Transportation System (NGATS) vision [6]. Complete modelling to
simulate the full 3 times traffic growth scenario and the concepts for 2025 were not
completed. U.S. concepts also included the addition of thousands of Micro jets and
UASs.

The operational concept in Phase 2 assumes that sector sizes are three times larger in
the TMA, ENR, and ORP domains. This growth in service volume sizes could not be
directly modelled in the SAAM and MLM models. However, three adjacent sectors
were combined into one larger sector to estimate the Phase 2 PIAC. The SAAM
model uses ‘flow sectors’; those used in the calculations approximated to ATC control
sectors. The MLM NAS sectors are based upon actual control sectors. These aspects
are discussed further in Section 7.

Peak instantaneous aircraft counts (PIACs) were predicted for the years 2020 and
2030 using the SAAM and MLM models. The PIACs for the various service volumes
are given in Table 6-7. Neither the SAAM nor the MLM could model the airport
surface domain therefore this domain was treated separately using a number of
sources. The airport domain in a busy U.S. airport was used as the basis for
requirements.

The AOA service volume PIAC was estimated at 20% of the traffic density projected
for the Phase 2 high density ENR service volume. Note: The AOA service volume is
significantly larger than the ENR service volume.

Scenario   Date             APT               TMA               ENR                  ORP          AOA
                      HD          LD    HD       LD        HD         LD        HD         LD
ECAC       2020        -          -      16         14     24         24        -          -       -
NAS        2020       200         12     -          -      41          -        10         5       -
                                                                           11
ECAC       2030        -          -      44         39     45         59        -          -       -
NAS        2030       290         19     -          -      95          -        34         18     70

                              Table 6-7: Service Volume PIACs

For the APT service volume, additional details about the distribution of aircraft
amongst the three control positions must be known since many of the instances of
service usage are specific to a particular control position. Table 6-8 summarises the
number of aircraft assumed to be in the clearance/ramp, ground, and tower positions
in Phase 1 and Phase 2.




11
  The PIAC for the ECAC ENR LD volume is larger than the HD volume, but the size of the service
volume is much larger resulting in an overall lower density – see Section 7.


                                               105
                                    COCR Version 2.0


                                             Phase 1                    Phase 2
               APT Position
                                       HD              LD          HD             LD
               Clearance/Ramp          134             4           194            7
               Ground                  48              3           70             4
               Tower                   18              5           26             8
               Total                   200             12          290            19

                        Table 6-8: Airport Controller Position PIACs

While not currently included within the loading analyses, it is important to note that in
the airport environment, communication is necessary among a wide range of users in
addition to the aircraft, e.g., surface vehicles. The FRS should have capacity to
support this requirement although not necessarily in the same radio spectrum as
aircraft. Table 6-9 provides the expected number of airport surface vehicles for Phase
1 and 2. Table 6-10 provides the number of the types of vehicles for a high-density
airport.

                                             Phase 1                    Phase 2
               APT
                                       HD              LD          HD             LD
               Surface Vehicles         32             4           32             8

                       Table 6-9: Airport Surface Vehicle Peak Counts


                  Vehicle Type                              Number of Vehicles
                  Busses                                           12
                  De-icing Trucks                                   2
                  Snow Trucks                                       8
                  Airport Operations                                6
                  Security and Fire Trucks                          4
                  Total                                            32

                           Table 6-10: Types of Surface Vehicles

6.2.1.5.2    Transmission Volume PIACs
Table 6-11 provides PIACs for Phase 1 and Phase 2 transmission volumes. PIACs are
based on the required transmission range associated with each service.




                                              106
                                              COCR Version 2.0

                                         Phase 1 PIAC                                    Phase 2 PIAC
         Services
                         APT      TMA         ENR       ORP    AOA      APT        TMA      ENR         ORP   AOA

C&P SURV                  -       125         250        3      -        -         160       320        14     -
ITP SURV                  -       125         250        3      -        -         160       320        14     -
M&S SURV                  -       125         250        3      -        -         160       320        14     -
PAIRAPP SURV              -        -           -         -      -        6         18         -          -     -
AIRSEP                    -        -           -         -      -        -          -         -          -    12
AIRSEP SURV               -        -           -         -      -        -          -         -          -    36
SURV                     232      300         850        3      -       322        400      1100        14     -
TIS-B (note 1)           232      300         850        3      -        -          -         -          -     -
WAKE                      -        -           -         -      -       26         400      1100        14     -
100 NM Fixed Range       475      300         250        -      -       600        400       320         -     -
150 NM Fixed Range       700      600         500        -      -       900        800       640         -     -

                               Table 6-11: Transmission Volume PIACs

The APT and ORP PIACs for SURV and TIS-B are based on the aircraft and surface
vehicle PIACs described in Section 6.2.1.5.1.

The PAIRAPP PIAC is assumed to involve 20% of the arriving aircraft. The
PAIRAPP service is used by aircraft on (or being sequenced to) final approach. The
intended use of PAIRAPP is not completely compatible with the transmission volume
boundaries selected for the air-air data loading analysis. The operation begins in the
TMA domain and continues through the APT domain. The figures above are based
on 20% of the arrival PIACs described in Section 6.2.1.5.1 with the total rounded up
to the next even number.

For the AIRSEP PIAC, it is assumed that 50% of the aircraft in the AOA domain are
clustered in an area with a 200 NM diameter. This yields a total PIAC of 36 within a
100 NM radius. It is assumed that one-third of the aircraft are conducting AIRSEP
communication at any one point in time.

For the remaining volumes, the Phase 1 PIACs are estimated and the Phase 2 PIACs
are based on an annual growth rate of 2.5% over a 10-year period.

6.2.1.5.3           Daily Operations Per ATSU
Table 6-12 and Table 6-13 provide the daily operations (number of aircraft serviced in
a 24-hour period) per ATSU in Phase 1 and Phase 2, respectively. The Phase 2 daily
operations are derived from the Phase 1 values by assuming a 2.5% annual growth
rate over a ten-year period.

                                                                         En Route
                        Density        Airport          TMA         (40 sector domain)
                        High            1800            3000              12000
                        Low              50             300                  400

                          Table 6-12: Phase 1 Daily Operations per ATSU




                                                        107
                                 COCR Version 2.0


                                                         En Route
                  Density     Airport     TMA       (40 sector domain)
                High           2304       3840            15360
                Low             64         384             512

                    Table 6-13: Phase 2 Daily Operations per ATSU

6.2.2 Communication Implementation Assumptions
The following communication implementation assumptions are used by one or more
of the loading analyses.
       Addressed and Broadcast Services: Some operational services may be
       implemented via addressed and/or broadcasted communication services. The
       service implementation assumptions are described.
       Network Management Services: While transparent to end user operations,
       the FRS is assumed to be part of a network for addressed communications.
       The network requires connection and routing communication. This traffic is
       anticipated to flow over the FRS; therefore, assumptions about this traffic are
       described.
       Service Message Quantities and Sizes: Each instance of a data service may
       involve one or more messages that are exchanged between parties. For voice
       communication, the instance may involve series of voice transmissions, e.g., a
       Controller issues an instruction and the Flight Crew provides a confirmation
       reply. Data communications involve an analogous series of messages. Each
       message is assumed to include application data, network overhead, error check
       bits, and/or security data. Message quantities and sizes are described.
       Communication Classes of Service: Performance characteristics such as
       service priority and latency requirements drive system capacity requirements.
       Faster transaction times typically result in higher communication loading rates.
       The addressed loading analysis assumes that operational services are grouped
       into categories that are assigned a communication class of service (COS) and
       that each COS is assigned a priority relative to the others. The COS categories
       are defined and each operational service is mapped into an associated COS.

6.2.2.1 Addressed and Broadcasted Services
Many of the operational services described in Section 2 can be implemented via
addressed and/or broadcast communication services. It has been assumed that the
TIS-B, WAKE and SURV (all types) services are implemented via broadcast. It has
been assumed that the addressed portion of the AIRSEP service has been
implemented via a broadcast communication services (see Section 6.5 for details).
All remaining services are assumed to be implemented using addressed
implementations.

Note: The SAP service as well as all of the FIS services could be implemented via
broadcast communication services. The broadcast loads for these services and the
potential reductions in addressed communication load are not evaluated in the COCR



                                         108
                                        COCR Version 2.0


6.2.2.2 Network Management Services (NET)
Network management services are used to establish and maintain connections
between each pair of aircraft and ground systems. The loading analysis assumes that
there are two network management services — network connection and network
keep-alive. This section describes the services and provides the instances of use per
aircraft.

6.2.2.2.1    Network Connection (NETCONN)
A network connection is established between each pair of aircraft and ground systems
before ATS or AOC data services can be provided between aircraft and ground
entities. It is normally maintained between the aircraft system and a ground system
for the entire length of the flight.

A connection establishment may be initiated by the aircraft or ground system. When
the aircraft flies into the service area of the next ground system, it may have to
establish a new connection with a next ground system and release a connection with
the previous ground system.

The network connection service is a point-to-point service. It is normally used in all
phases of the flight in all domains.

6.2.2.2.2    Network Keep-Alive (NETKEEP)
Once a connection is established, network keep-alive messages are exchanged
between the aircraft and ground systems when there is no traffic for a period of time
to maintain the status of the connection.

The network keep-alive service is a point-to-point service. It is normally used in all
phases of flight in all domains.

6.2.2.2.3    NET Service Instances
Table 6-14 provides the assumed service utilization for the addressed data loading
analysis.

Note: For purposes of estimating load, an Aeronautical Telecommunications Network
(ATN) protocol stack is used. The COCR does not specify or require a particular
network stack.

                                               PHASE 1/2                                 PHASE 2
Service
                    APT                  TMA               ENR             ORP              AOA
NETCONN           1 (in ramp),             0            1 per domain    1 per domain      1 per domain
                 departure only                                                         (in buffer zone)

NETKEEP          1 per 30 mins        1 per 30 mins     1 per 30 mins   1 per 30 mins     1 per domain
                                                                                        (in buffer zone)


                                 Table 6-14: NET Service Instances




                                                  109
                                 COCR Version 2.0


6.2.2.3 Message Quantities and Sizes
Table 6-15 to Table 6-17 provide the average number of message quantities and sizes
per service instance for ATS, AOC and NET services, respectively. For addressed
services, message sizes are provided for the uplink and downlink directions. For
broadcasted services, the message size is the transmitted message size.

For addressed messages, the message quantities and sizes are based on a number of
referenced sources for some services and engineering estimates for the newer
services, see [37], [38] and [40]. The messages include overheads associated with the
network, integrity and security.

Note: For purposes of estimating load, the addressed message sizes assume an ATN
protocol stack is used. The COCR does not specify or require a particular network
stack.

The DLL and AOCDLL messages include 72 octets for network overhead and 4
octets for integrity. The security overhead for both types of messages include key
exchanges and the overhead size varies based on the assumed number of applications
supported. It is assumed that the DLL service supports 3 applications and the
AOCDLL service supports 2 applications.

The AIRSEP message size is assumed to be a derivative of that used for the COTRAC
service, since it is the air-air version of the same function. However, the quantity of
information exchanged is smaller due to the smaller time horizons. The COTRAC is
a complete trajectory while the AIRSEP only addresses the part of the trajectory
needed to resolve the air-air conflict. Only a transmit message size is provided for
AIRSEP because the loading analyses assume this addressed operational service is
transmitted over a broadcasted communication service. See Section 6.5 for details.

The remaining addressed messages include includes 72 octets for network overhead, 4
octets for integrity overhead, and 1 octet for security overhead. Note: It is assumed
that the security authentication value can be XORed with the integrity checksum to
save bandwidth. Encryption adds overhead to the logon message, but not to the other
application messages.

For broadcast messages, the SURV message size is assumed to be 34 bytes, i.e., the
message size associated with UAT technology transmissions per RTCA DO-282A.
This is the worst case message size associated with current air-air broadcast
technologies. The WAKE message size is assumed to be the same as SURV.

Note: For some of the services, the average message quantities and sizes have been
refined for Version 2.0 of the COCR and application level logical acknowledgements
(LACKs) have been removed.

                                          Uplink               Downlink
           Services
                                     Qty x Size (bytes)     Qty x Size (bytes)
           ACL                             2 x 93                 2 x 93
           ACM                            1 x 126                 1 x 88
           A-EXEC                         1 x 600                1 x 100
           AIRSEP                                     6 x 497



                                         110
                       COCR Version 2.0


                               Uplink                 Downlink
Services
                          Qty x Size (bytes)       Qty x Size (bytes)
AMC                             1 x 89                    0x0
ARMAND                         1 x 260                   1 x 88
C & P ACL                       2 x 93                   2 x 93
ITP SURV                                    1 x 34
COTRAC (Interactive)          3 x 1969                 4 x 1380
COTRAC (Wilco)                2 x 1613                 2 x 1380
D-ALERT                         1 x 88                 1 x 1000
D-ATIS (Arrival)               5 x 100                   3 x 93
D-ATIS (Departure)             3 x 101                   2 x 96
DCL                            1 x 117                   2 x 88
D-FLUP                         5 x 190                  3 x 129
DLL                            1 x 491                  1 x 222
D-ORIS                         9 x 478                   3 x 93
D-OTIS                        11 x 193                  3 x 107
D-RVR                          4 x 116                  3 x 121
DSC                             3 x 96                   4 x 87
D-SIG                         4 x 1340                  3 x 129
D-SIGMET                       4 x 130                  3 x 129
D-TAXI                         2 x 132                   1 x 98
DYNAV                          1 x 515                   1 x82
FLIPCY                         1 x 105                  1 x 173
FLIPINT                        1 x 143                 1 x 2763
ITP ACL                         2 x 93                   2 x 93
ITP SURV                                    1 x 34
M&S ACL                         2 x 93                   2 x 93
M&S SURV                                    1 x 34
PAIRAPP ACL                     2 x 93                   2 x 93
PAIRAPP SURV                                1 x 34
PPD                            1 x 105                  1 x 277
SAP (Contract Setup)            2 x 95                  2 x 100
SAP (Report)                     0x0                    1 x 107
SURV (ATC)                                  1 x 34
TIS-B                                       1 x 34
URCO                            1 x 98                   1 x 82
WAKE                                        1 x 34

    Table 6-15: ATS Message Quantities and Sizes per Instance




                              111
                                   COCR Version 2.0


                                   Phase 1                                    Phase 2
Service                 Uplink             Downlink                Uplink             Downlink
                   Qty x Size (bytes)   Qty x Size (bytes)    Qty x Size (bytes)   Qty x Size (bytes)
AOCDLL                  2 x 413               2 x 148              2 x 413              2 x 148
CABINLOG                 0x0                  1 x 477                0x0                1 x 477
ENGINE                   1 x 88               1 x 727               2 x 88              2 x 727
FLTLOG                   0x0                  2 x177                 0x0                2 x 177
FLTPLAN                 17 x 285              17 x 90              9 x 968              9 x 92
FLTSTAT                  0x0                  1 x 157                0x0                1 x 157
FREETEXT                1 x 377               1 x 377              1 x 377              1 x 377
FUEL                     0x0                  3 x127                 0x0                3 x 127
GATES                   1 x 589                0x0                 1 x 589               0x0
LOADSHT                 2 x 913               2 x 93               2 x 913              2 x 93
MAINTPR                 4 x 133               4 x 133              4 x 233              4 x 233
MAINTRT                  5 x 88               5 x 127               5 x 88              5 x 127
NOTAM                   3 x 265               2 x 134              4 x 287              2 x 134
OOOI                     0x0                  1 x 117                0x0                1 x 117
POSRPT                   1 x 88               1 x 338               1 x 88              1 x 338
SWLOAD                  2 x 4077               0x0                 6 x 4077              0x0
TECHLOG                  1 x 88               1 x 477               1 x 88              1 x 477
UPLIB                   4 x 4077              4 x 88              24 x 4077             24 x 88
WXGRAPH                 6 x 4246              6 x 93              5 x 21077             6 x 93
WXRT                     0x0                  1 x103                 0x0                1 x 103
WXTEXT                  5 x 680               2 x 103              5 x 680              2 x 103

              Table 6-16: AOC Message Quantities and Sizes per Instance


                                         Uplink                 Downlink
             Services
                                    Qty x Size (bytes)       Qty x Size (bytes)
             NETCONN                     2 x 154                  2 x 148
             NETKEEP                     1 x 93                   1 x 93

              Table 6-17: NET Message Quantities and Sizes per Instance

6.2.2.4 FRS Data Class of Service
This section describes the categories of communication services, i.e., classes of
service, that may be used to support the operational services while meeting
performance requirements previously outlined. The COS categories described herein
are not prescriptive, as other communication classes or groupings of operational
services exist that still meet operational service requirements.




                                             112
                                  COCR Version 2.0


One of the benefits of grouping similar services into a COS category is that the
number of items to manage is reduced. COS definition is a useful step in estimating
the communication load. With a reduced set of classes, a particular service may not
match exactly one class definition. In such a case, the service was placed in the next
highest performance class that meets the service requirement.

Because the NET services are required to support ATS and AOC services, they are
normally assigned the class of service with the highest priority.

6.2.2.4.1    Assumptions
The following assumptions were used during the definition of service classes.
       It is assumed that NET services have the highest priority, ATS services have
       the next highest priority and AOC services have the lowest priority.
       The total number of classes per service volume is limited to a maximum of 6.
       The NET services are allocated 1 class, the ATS services are allocated up to 3
       classes, and the AOC services are allocated up to 2 classes. While the number
       of classes per service volume is limited to 6, a different subset may be used
       between service volumes; hence, the number of classes in the master list is
       greater than 6.
       Class categories were chosen to maintain clear boundaries between ATS and
       AOC services (in order to facilitate separate links for these services, if desired).
       In addition, air-ground services are kept separate from air-air services, voice
       services are kept separate from data services, and addressed services are kept
       separate from broadcast services.
       For air-ground services, it is assumed that latency and priority are drivers for
       COS categorisation, at least more so than security, integrity, and/or
       availability requirements. An alternate approach would be to develop classes
       that differentiate based on availability requirements.
       For air-air services, both latency and availability were discriminators for
       developing service classes.

6.2.2.4.2    COS Categories
Table 6-18, Table 6-19 and Table 6-20 present the class categories for air-ground
addressed data, air-air addressed data, and broadcasted data, respectively.




                                          113
                                            COCR Version 2.0


COS          ET       TD95-FRS    CUIT-FRS     IUCT-FRS      AP-FRS        AU-FRS     Service Type
        Reserved
                                                                                        NET Data
DG-A     (rsvd)          9.8        rsvd       5.0E-8         rsvd          rsvd
DG-B         1.6        0.74     0.99999992 5.0E-10       0.9999999995   0.99999995
DG-C         5.0         1.4       0.9996      5.0E-8       0.999995       0.9995
DG-D         7.8         2.4       0.9996      5.0E-8       0.999995       0.9995
DG-E         8.0         3.8       0.996       5.0E-6        0.9995        0.9965
                                                                                      ATS. A-G Data
DG-F         12.0        4.7       0.996       5.0E-8        0.9995        0.9965
DG-G         24.0        9.2       0.996       5.0E-6        0.9995        0.9965
DG-H         32.0       13.6       0.996       5.0E-6        0.9995        0.9965
DG-I         57.6       26.5       0.996       5.0E-6        0.9995        0.9965
DG-J                    13.6                   5.0E-8        0.9995        0.995
          Not                       Not
DG-K                    26.5                   5.0E-10       0.9995        0.995      AOC A-G Data
        available                 available
DG-L                    51.7                   5.0E-10       0.9995        0.995

                    Table 6-18: Air-Ground Addressed COS Categories (Type DG)


COS          ET       TD95-FRS    CUIT-FRS     IUCT-FRS      AP-FRS        AU-FRS     Service Type
DA-A         rsvd       rsvd        rsvd        rsvd          rsvd          rsvd      rsvd
DA-B         7.8         2.4       0.9996      5.0E-8       0.999995       0.9995     AIRSEP

                      Table 6-19: Air-Air Addressed COS Categories (Type DA)


COS          ET       TD95-FRS    CUIT-FRS     IUCT-FRS      AP-FRS        AU-FRS     Service Type
DB-A         3.2         0.4      0.99996      5.0E-8        0.9995        0.9995
                                                                                      SURV A-A
DB-B         4.8         1.2       0.9996      5.0E-8        0.9995        0.9995
                                                                                      Data
DB-C         8.0         1.2       0.9996      5.0E-8       0.999995       0.9995
DB-D         3.2         1.2      0.99996      5.0E-8      0.9999975      0.99995
                                                                                      SURV (ATC)
DB-E         8.0         1.2      0.99996      5.0E-8      0.9999975      0.99995     TIS-B
                                                                                      WAKE
DB-F         16.0        1.2      0.99996      5.0E-8      0.9999975      0.99995

                          Table 6-20: Broadcast COS Categories (Type DB)

 6.2.2.4.3          Class Assignments
 Table 6-21, Table 6-22, and Table 6-23 contain COS assignments for ATS, AOC and
 NET services, respectively.




                                                   114
                                COCR Version 2.0


                             Phase 1                                  Phase 2
Service
               APT    TMA     ENR      ORP        AOA   APT    TMA     ENR      ORP    AOA
ACL            DG-E   DG-E    DG-E     DG-I        -    DG-C   DG-C    DG-C     DG-F   DG-C
ACM            DG-E   DG-E    DG-E     DG-I        -    DG-C   DG-C    DG-C     DG-F   DG-D
A-EXEC          -      -        -       -          -     -     DG-B    DG-B      -      -
AIRSEP          -      -        -       -          -     -      -        -       -     DA-B
AIRSEP SURV     -      -        -       -          -     -      -        -       -     DB-C
AMC            DG-E   DG-E    DG-E     DG-I        -    DG-D   DG-D    DG-D      -     DG-G
ARMAND          -      -      DG-G      -          -     -      -      DG-D      -      -
C&P ACL         -     DG-E    DG-E     DG-I        -     -     DG-D    DG-D     DG-F    -
C&P SURV        -     DB-B    DB-B     DB-B        -     -     DB-B    DB-B     DB-B    -
COTRAC          -      -        -       -          -    DG-D   DG-D    DG-D     DG-F   DG-D
D-ALERT        DG-E   DG-E    DG-E     DG-I        -    DG-D   DG-D    DG-D     DG-F   DG-D
D-ATIS         DG-E   DG-E    DG-E     DG-I        -    DG-D   DG-D    DG-D     DG-G   DG-G
DCL            DG-G    -        -       -          -    DG-D    -        -       -      -
D-FLUP         DG-G    -        -       -          -    DG-D   DG-D    DG-D     DG-H   DG-H
DLL            DG-E   DG-E    DG-E     DG-I        -    DG-C   DG-D    DG-D     DG-G   DG-G
D-ORIS          -     DG-E    DG-E     DG-I        -     -     DG-D    DG-D     DG-G   DG-G
D-OTIS         DG-E   DG-E    DG-E     DG-I        -    DG-D   DG-D    DG-D     DG-G   DG-G
D-RVR          DG-E   DG-E    DG-E     DG-I        -    DG-C   DG-C    DG-D     DG-G   DG-G
DSC             -      -      DG-H     DG-I        -     -      -      DG-D     DG-H   DG-G
D-SIG          DG-G   DG-G      -       -          -    DG-F   DG-D      -       -      -
D-SIGMET       DG-E   DG-E    DG-E     DG-I        -    DG-D   DG-D    DG-D     DG-G   DG-G
D-TAXI         DG-E   DG-E      -       -          -    DG-D   DG-D      -       -      -
DYNAV           -      -        -       -          -     -      -      DG-D     DG-G    -
FLIPCY         DG-H   DG-H    DG-H     DG-I        -    DG-D   DG-D    DG-D     DG-F   DG-D
FLIPINT        DG-H   DG-H    DG-H     DG-I        -    DG-D   DG-D    DG-D     DG-F   DG-D
ITP ACL         -      -        -      DG-I        -     -     DG-D    DG-D     DG-F    -
ITP SURV        -      -        -      DB-B        -     -     DB-B    DB-B     DB-B    -
M&S ACL         -     DG-E    DG-E      -          -     -     DG-D    DG-D     DG-F    -
M&S SURV        -     DB-B    DB-B      -          -     -     DB-B    DB-B     DB-B    -
PAIRAPP ACL     -      -        -       -          -    DG-D   DG-D      -       -      -
PAIRAPP SURV    -      -        -       -          -    DB-A   DB-A      -       -      -
PPD            DG-H   DG-H    DG-H     DG-I        -    DG-D   DG-D    DG-D     DG-G   DG-D
SAP             -     DG-E    DG-E      -          -     -     DG-D    DG-D      -      -
SURV (ATC)     DB-D   DB-E    DB-F     DB-F        -    DB-D   DB-E    DB-E     DB-E   DB-E
TIS-B          DB-D   DB-E    DB-F     DB-F        -     -      -        -       -      -
URCO            -      -        -       -          -    DG-D   DG-D    DG-D     DG-F   DG-D
WAKE           DB-D   DB-E    DB-F      -          -    DB-D   DB-E    DB-E      -      -


                        Table 6-21: ATS COS Assignments



                                            115
                                        COCR Version 2.0



                                                         Phase 1 & 2
                       Service                                               AOA
                                        APT     TMA         ENR    ORP        12


                       AOCDLL           DG-J     DG-J       DG-J   DG-K      DG-K
                       CABINLOG         DG-K         -        -         -     -
                       ENGINE           DG-K    DG-K       DG-K    DG-L      DG-L
                       FLTLOG           DG-K         -        -         -     -
                       FLTPLAN          DG-J     DG-J       DG-J   DG-K      DG-K
                       FLTSTAT          DG-J     DG-J       DG-J   DG-K      DG-K
                       FREETXT          DG-K    DG-K       DG-K    DG-L      DG-L
                       FUEL             DG-K    DG-K       DG-K    DG-L      DG-L
                       GATES            DG-J     DG-J       DG-J   DG-K      DG-K
                       LOADSHT          DG-J     DG-J         -         -     -
                       MAINTPR          DG-J     DG-J       DG-J   DG-K      DG-K
                       MAINTRT          DG-K    DG-K       DG-K    DG-L      DG-L
                       NOTAM            DG-K    DG-K       DG-K    DG-L      DG-L
                       OOOI             DG-J         -        -         -     -
                       POSRPT           DG-K    DG-K       DG-K    DG-L      DG-L
                       SWLOAD           DG-K    DG-K       DG-K    DG-L      DG-L
                       TECHLOG          DG-K         -        -         -     -
                       UPLIB            DG-K    DG-K       DG-K    DG-L      DG-L
                       WXGRAPH          DG-J     DG-J       DG-J   DG-K      DG-K
                       WXRT             DG-J     DG-J       DG-J   DG-K      DG-K
                       WXTEXT           DG-J     DG-J       DG-J   DG-K      DG-K

                                 Table 6-22: AOC COS Assignments


                                                         Phase 1 & 2
                       Service                                               AOA
                                        APT     TMA         ENR        ORP    13


                       NETCONN          DG-A    DG-A       DG-A    DG-A      DG-A
                       NETKEEP          DG-A    DG-A       DG-A    DG-A      DG-A

                                 Table 6-23: NET COS Assignments

6.2.2.4.4        Class of Service Implications
The following comments apply to the COS service assignments:

12
     The AOA domain is only applicable in Phase 2.
13
     The AOA domain is only applicable in Phase 2.


                                                 116
                                 COCR Version 2.0


       The ground network may be common for all domains and it may provide a
       limited set of priority levels. If a reduced set of classes is required, many
       more service categories may need to be placed into the next highest
       performance category. This typically will result in a higher addressed
       communication load for the FRS.

6.3 Voice Loading Analysis
The voice loading analysis provides estimated seconds of active talk time per hour for
the party line service in each of the service volumes. Additional information
regarding the number of transmissions per hour is also provided. Only ATS
Controller/pilot voice communication is analysed as there is insufficient information
to characterise AOC voice communication. The voice loading associated with
broadcast channels such as for ATIS, VOLMET, and AWOS is 100%.

6.3.1 Methodology
The estimated seconds per hour of active Push to Talk (PTT) time and the instance
information is developed using the following steps:
       A survey of existing voice studies was conducted to determine the average
       number of transmissions per aircraft (#tx/ac) per service volume and the
       average duration of each transmission (#sec/tx) [19]. For comparison with
       data communications loading, the number of instances per aircraft
       (#instances/ac) is also estimated. An instance contains a sequence of related
       voice transmissions.
       The total number of seconds of voice per hour per service volume
       (#sec/hr/SV) is calculated using the metrics from the voice study survey in
       tandem with PIAC, flight times per service volume (SV), data
       communications equipage rates, and voice/data utilisation rates presented in
       Section 6.2.1.4. The loading analysis uses an average flight time for volumes
       that specify both arrival and departure aircraft durations.
       The total number of seconds of voice per hour per position (#sec/hr/position)
       is calculated from the number of positions per service volume (#positions/SV).
       In addition, the occupancy and number of transmissions per hour per position
       (#tx/hr/position) is calculated.
Unlike the other services volumes, the APT is comprised of multiple types of voice
positions, i.e., ramp/clearance, ground, and tower. High-density airports may contain
multiple instances of a particular type of position, e.g., two ground positions. Low-
density airports do not require all three position types and may combine the
ramp/clearance and ground positions. Since the referenced voice studies only provide
data for ground and tower positions only these two positions are considered in the
voice loading analysis. Accordingly, the PIAC and flight times used here correspond
to these two positions. Further, it is assumed that for the high density airport, two
ground positions and one tower position are required to handle the PIAC traffic. The
FRS would need to support separate party-line channels for each position.




                                         117
                                              COCR Version 2.0


   6.3.2 ATS Voice Transmission Characteristics
   The voice transmission characteristics per service volume are based on a survey of
   studies [19] that evaluate both typical and worst-case conditions for various airspace
   domains assuming limited or non-existent use of data communications. The ORP
   service volume values were estimated because of limited or non-existent reference
   data. The number of seconds per aircraft includes only active PTT time. The number
   of instances per aircraft in each service volume has been calculated by dividing the
   number of transmissions by the estimated number of transmissions required per
   instance. The APT number of transmissions and transmission duration are for ground
   and tower positions only.

                     Parameter               APT           TMA      ENR       ORP
                     #tx/ac                  16.5           6.8      8.8        3
                     #sec/tx                   3            2.8      3.3       3.3
                     #sec/ac                 49.5          19.0     29.0       9.9
                     #tx/instance              2             2       2.8       2.8
                     #instances/ac            8.3           3.4      3.1       1.1

              Table 6-24: ATS Voice Transmission Characteristics per Service Volume

   6.3.3 Service Volume Results
   Table 6-25 and Table 6-26 provide the estimated ATS voice communication load for
   Phase 1 and Phase 2, respectively. Explanatory material on the tables is provided
   immediately after the tables.

                                      APT              TMA                  ENR                  ORP
        PHASE 1                                                     NAS    ECAC-
                                HD          LD      HD       LD     -HD     HD       LD     HD     LD
#tx/ac                          16.5        16.5     6.8      6.8    8.8     8.8      8.8     3      3
#sec/tx                           3          3       2.8      2.8    3.3     3.3      3.3    3.3    3.3
#sec/ac                         49.5        49.5    19.0     19.0   29.0    29.0     29.0    9.9    9.9
PIAC                             66          8       16       14     41      24       24     10      5
% ac (voice only ac)            25%         25%     25%      25%    25%     25%      25%    20%    20%
% voice util (data
                                60%         60%     60%      60%    40%     40%      40%    5%         5%
communications ac)
flight duration/SV (#sec)       870         450     334       519   675     675      900    2550   2550
#sec/hr/ac                       205        396     206       132   155     155      116    14         14
#sec/hr/SV (voice only ac)      3380        792     822       462   1588    929      697    28         14
#sec/hr/SV (data
                                6083        1426    1480      832   1905   1115      836     6         3
communications ac)
#sec/hr/SV (total)              9463        2218    2302     1294   3493   2044      1533   34         17
#positions/SV                     3          2        1       1       1     1         1      1          1
#sec/hr/position                3154        1109    2302     1294   3493   2044      1533   34         17
# tx/hr/position                1051        739     822      462    1058   620       465    10          5
occupancy/position              88%         31%     64%      36%    97%    57%       43%    1%         0%

                             Table 6-25: Phase 1 Voice Communications Load



                                                      118
                                              COCR Version 2.0



                                      APT                TMA                ENR                  ORP
          PHASE 2                                                    NAS    ECAC-
                                HD          LD     HD         LD     -HD     HD     LD     HD          LD
#tx/ac                          16.5        16.5   6.8         6.8   8.8     8.8    8.8     3          3
#sec/tx                          3           3     2.8         2.8   3.3     3.3    3.3    3.3         3.3
#sec/ac                         49.5        49.5   19.0       19.0   29.0    29.0   29.0   9.9         9.9
PIAC                             96         12     44          39    95      45     59     34          18
% ac (voice only ac)            15%         15%    15%        15%    0%      0%     0%     0%          0%
% voice util (data
                                15%         15%    15%        15%    5%      5%     5%     1%          1%
communications ac)
flight duration/SV (#sec)       870         450    267        415    984     984    1230   3825    3825
#sec/hr/ac                      205         396    257        165    106     106    85      9          9
#sec/hr/SV (voice only ac)      2950        713    1698       966     0       0      0      0          0
#sec/hr/SV (data
                                2507        606    1443       821    505     239    251     3          2
communications ac)
#sec/hr/SV (total)              5457        1319   3140       1788   505     239    251     3          2
#positions/SV                    3           2      1          1      1       1      1      1          1
#sec/hr/position                1819        659    3140       1788   505     239    251     3          2
# tx/hr/position                606         440    1122       638    153     72     76      1          1
occupancy/position              51%         18%    87%        50%    14%     7%     7%     0%          0%

                             Table 6-26: Phase 2 Voice Communications Load

    The airport PIACs and flight duration above reflect the sum of the ground and tower
    positions. The resulting #sec/hr/SV values are for combined ground and tower
    positions.

    The following notes provide information on the calculations used in the tables above.
             The #sec/hr/ac is calculated by dividing the #sec/ac by the flight duration.
             The #sec/hr/SV (voice only ac) is calculated by multiplying the #sec/hr/ac
             times the voice only aircraft count (i.e., PIAC x voice only percentage).
             The #sec/hr/SV (voice utilisation by data communications ac) figures are
             calculated by multiplying #sec/hr/ac times the data communications aircraft
             count times the voice utilisation percentage.
             The total #sec/hr/SV is the sum of the previous two calculations.
             The #tx/hr/position by dividing the total #sec/hr/position by the #sec/tx.

    6.3.4 Analysis of Results
    For Phase 1, the occupancy numbers are large compared to typical occupancy rates
    for some domains. This difference can be primarily attributed to the use of PIAC data
    instead of average aircraft counts (or aircraft per hour figures). Nonetheless, it is



                                                        119
                                 COCR Version 2.0


useful to look at PIAC-based loading to get a sense of worst case conditions
especially when those worst case conditions are close to actual peak conditions. For
example in the APT domain, the Los Angeles Airport [18] measured occupancy rates
of 68% for a peak activity period spanning 1 hour. Note that if 4 positions were
assumed for the APT, i.e., two ground and two towers, the occupancy rate would drop
to 66%. In the TMA domain, the New York TRACON arrival sectors have
experienced 81% occupancy over a period of 1 hour [45]. In the ENR domain, the
Vocalise study [35] has shown occupation rates over 77% over a 5 minute period and
near 60% over a 15 minute period.

For Phase 2, the data communications equipage and utilization rates are key factors
that will allow the PIAC to grow while still allowing the voice channel to support the
service volume.

6.4 Addressed Data Loading Analysis
The addressed communication loading analysis provides an estimate of the
communication load for addressed data communications. Separate and combined
communication loads are estimated for ATS and AOC traffic. Separate and combined
communication loads are estimated for uplink (UL) and downlink (DL) traffic. In
addition, results are provided for all aircraft in the service volume and for a single
aircraft using a dedicated channel.

The varied aggregations provide flexibility in the assessment of potential FRS
technologies.

Note: The air-air addressed portion of the AIRSEP service has been excluded from
the addressed communication loading analysis, because it is the only addressed
service that is not air-ground. It instead has been included with the other air-air
services in the broadcast communication loading. See Section 6.5 for details. Thus,
this addressed loading analysis is an air-ground addressed communication loading
analysis.

6.4.1 Methodology
The addressed communication loading analysis uses a non-preemptive queuing model
to estimate addressed communication loads. A two step process was used to develop
the addressed communication loading estimate.
       Traffic Model: A traffic model was developed to use as an input to the
       queuing model. The service instances (see Section 6.2.1.2), service volume
       flight durations (see Section 6.2.1.3) and service volume PIACs (see Section
       6.2.1.5.1 and 6.2.1.5.3) were used to derive message arrival rates. The
       addressed services were identified (see Section 6.2.2.1 and 6.2.2.2). Each
       service was assigned to a queue in accordance with the FRS COS assignments
       (see Section 6.2.2.4). The individual service arrival rates and message sizes
       (see Section 6.2.2.3) were used to calculate the queue message arrival rates
       and sizes.
       Queuing Model: A non-pre-emptive priority queuing model was used to
       develop the capacity requirements. In the model, messages in higher priority


                                         120
                                       COCR Version 2.0


             queues (e.g., classes of service) are serviced before messages in lower priority
             queues. Once the server in the model has begun to transmit a message from
             any particular priority queue, it continues to transmit the message even if a
             higher priority message should arrive during transmission. Given a selected
             information transfer rate, the queuing model predicts the 95th percentile delay
             for the largest service message within each queue. The model is run
             iteratively until all queues meet the required latency performance.
   Details of the model and the methodology to employ it, can be found at Appendix C.

   Note: All of the results in this section assume 100% data equipage within the service
   volume in order to obtain a reasonable worst case communication load.

   While the model produces detailed results, these detailed figures imply a level of
   precision that is not appropriate given the approximate nature of the many of the
   input assumptions. Hence, all results have been rounded.

   6.4.2 Service Volume Results
   Table 6-27 provides the estimated addressed communication load for high density and
   low density Phase 1 service volumes within each airspace domain. Table 6-28 and
   Table 6-29 provide the results for Phase 2 service volumes with and without the A-
   EXEC service, respectively.


                           APT SV         TMA SV              ENR SV            ORP SV
     PHASE 1                                                                                    AOA
                                                        HD     HD
                         HD      LD      HD     LD                     LD      HD      LD
                                                        EU     U.S.
Separate        UL        5       4       4      4       4       4      4       1          1     -
  ATS
                DL        8       7       8      8       7       8      7       3          3     -
              UL&DL       9       7       8      8       8       8      8       3          3     -
Separate        UL        20      8       2      2       15     15      15      5          5     -
  AOC
                DL        4       1       1      1       1       2      1       1      0.4       -
              UL&DL       20      8       2      2       15     15      15      5          5     -
Combined        UL        20      8       4      4       15     15      15      5          5     -
ATS&AOC
                DL        8       7       8      8       7       8      7       3          3     -
              UL&DL       30      8       8      8       15     20      15      5          5     -

           Table 6-27: Phase 1 Addressed Communication Load (kilobits per second [kbps])




                                               121
                                     COCR Version 2.0


                          APT SV        TMA SV             ENR SV           ORP SV
     PHASE 2                                                                               AOA
                                                     HD     HD
                        HD     LD      HD     LD                    LD     HD       LD
                                                     EU     U.S.
Separate       UL        30     20     30     30      30     30     30     15         15    20
  ATS
               DL        30     30     30     30      30     30     30     20         20    30
             UL&DL       40     30     40     40      30     40     30     20         20    30
Separate       UL       150     40      2      2      60    100     70     30         30    70
  AOC
               DL        7      2       3      3      2      3       2      1         1     2
             UL&DL      200     40      4      4      60    150     80     30         30    80
Combined       UL       150     40     30     30     150    200     150    40         30   100
ATS&AOC
               DL        30     30     30     30      30     30     30     20         20    30
             UL&DL      200     40     40     40     150    200     150    40         30   100

            Table 6-28: Phase 2 Addressed Communication Load (kbps) – with A-EXEC


                          APT SV        TMA SV             ENR SV           ORP SV
     PHASE 2                                                                               AOA
                                                     HD     HD
                        HD     LD      HD     LD                    LD     HD       LD
                                                     EU     U.S.
Separate       UL        30     20     30     30      30     30     30     15         15    20
  ATS
               DL        30     30     30     30      30     30     30     20         20    30
             UL&DL       40     30     40     40      30     40     30     20         20    30
Separate       UL       150     40      2      2      60    100     70     30         30    70
  AOC
               DL        7      2       3      3      2      3       2      1         1     2
             UL&DL      200     40      4      4      60    150     80     30         30    80
Combined       UL       150     40     30     30      80    150     90     40         30   100
ATS&AOC
               DL        30     30     30     30      30     30     30     20         20    30
             UL&DL      200     40     40     40      80    150     90     40         30   100

           Table 6-29: Phase 2 Addressed Communication Load (kbps) – without A-EXEC

   6.4.3 Single Aircraft Results
   Table 6-32 provides the estimated Phase 1 addressed communication load for a single
   aircraft assuming the use of an individual, dedicated channel. Table 6-31 and Table
   6-30 provide the results for Phase 2 with and without the A-EXEC service,
   respectively.




                                             122
                                       COCR Version 2.0


                            APT SV         APT SV         TMA SV       TMA SV
       PHASE 1                                                                    ENR SV      ORP SV
                             Dep            Arr            Dep          Arr
Separate        UL               4            1             1            4          4           1
ATS
                DL               7            7             7            7          7           3
                UL&DL            7            7             7            7          7           3
Separate        UL               8          0.3             0.3          2          8           4
AOC
                DL               1            1             1            1          1          0.4
                UL&DL            8            1             1            2          8           4
Combined        UL               8            1             1            4          8           4
ATS&AOC
                DL               7            7             7            7          7           3
                UL&DL            8            7             7            7          8           4

            Table 6-30: Phase 1 Addressed Communication Load (kbps) – Single Aircraft


                         APT SV      APT SV        TMA           TMA
     PHASE 2                                                             ENR SV    ORP SV      AOA
                          Dep         Arr         SV Dep        SV Arr
 Separate        UL         20         3            20            20         20         15      20
   ATS
                 DL         30         10           30            30         30         20      30
               UL&DL        30         10           30            30         30         20      30
 Separate        UL         40        0.3           0.3           2          40         20      20
   AOC
                 DL         1          1            1             1          1          0.4     0.4
               UL&DL        40         1            1             2          40         20      20
Combined         UL         40         3            20            20         40         20      30
ATS&AO
                 DL         30         10           30            30         30         20      30
   C
               UL&DL        40         10           30            30         40         20      40

  Table 6-31: Phase 2 Addressed Communication Load (kbps) – Single Aircraft with A-EXEC




                                                  123
                                  COCR Version 2.0


                         APT SV     APT SV         TMA      TMA
       PHASE 2                                                      ENR SV   ORP SV     AOA
                          Dep        Arr          SV Dep   SV Arr
  Separate       UL         20         3            20       20       20       15           20
    ATS
                 DL         30        10            30       30       30       20           30
              UL&DL         30        10            30       30       30       20           30
  Separate       UL         40        0.3          0.3       2        40       20           20
    AOC
                 DL          1         1            1        1        1        0.4          0.4
              UL&DL         40         1            1        2        40       20           20
 Combined        UL         40         3            20       20       40       20           30
 ATS&AOC
                 DL         30        10            30       30       30       20           30
              UL&DL         40        10            30       30       40       20           40

 Table 6-32: Phase 2 Addressed Communication Load (kbps) – Single Aircraft without A-
                                     EXEC

6.4.4 Analysis of Results

6.4.4.1 General Comments
Following are general comments data loading analysis:
       Model Validation: Although the model used is based on reasonable
       assumptions and formulas, both the model and its application in this loading
       analysis need to be validated.
       Note: The model has iterated since Version 2.0 of the COCR. The two
       changes are described in Appendix C. While the iterated model provides the
       best estimate available of the required information transfer rate, it is not a
       detailed simulation based on a particular implementation. The model is used
       for estimating purposes only and actual loading results may vary.
       Data Compression Impacts: The results are based on the size of messages
       arriving at the FRS boundary. Consequently compression techniques that
       could be employed to reduce the number of bits sent over the physical link
       have not been taken into account as the COCR is technology independent.
       Collisions and Media Access Delays: The model does not include RF
       collisions, retransmissions due to bit errors, or RF media access delays (e.g.,
       waiting for the next available slot).
       bps per Aircraft: An important conclusion of the loading work done thus far
       is that the increase in transfer rate requirements is not linear with the increase
       in aircraft; hence, one cannot reasonably use a bits per second
       (bps)/aircraft number in tandem with aircraft count to predict required
       bit rates. Many of the low density and high density service volumes have the
       same estimated capacity requirement. The reason for the non-linearity resides
       in the projected occupancy of the link. In many cases, the message latency
       requirements drive the information transfer rate rather than the quantity
       of information. Thus, the link may not always be actively transmitting
       messages.


                                            124
                                COCR Version 2.0


      Message Sizes, Quantities and Latencies: It should be restated that the
      results rely on a number of input assumptions (e.g., message sizes and number
      of messages per transaction) and use performance figures based on a high
      level operational hazard assessment. Loading results are sensitive to these
      assumptions (refer to Section 6.2 for a list of assumptions). The one-way
      latency requirements were applied to each one-way message. Future work is
      required to complete detailed safety and performance work for each individual
      service and to refine message sizes and/or sequences in greater detail.
       Note: While Version 2.0 has incorporated additional safety and performance
       information, future standards work will continue to refine message sizes
       and/or sequences.
      Driving COS Category: In all cases, one of the several queues (i.e., classes
      of services) in the aggregate flow drives the required information transfer rate.
      In other words, only one of the categories has a 95% predicted delay that is
      equivalent to the COS category delay requirement. The other COS categories
      have predicted delays that are less than the COS category delay requirement.
      Further, it is not necessarily the highest performance (priority) category that
      ends up being the driving COS category. Sometimes the middle and low
      priority queues are the driving queues because the message size to delay ratios
      may be larger for these queues. Typically, changes to non-driving queues
      have lower impact and result in less significant changes in the required
      information transfer rates. It is also interesting to note that while the
      system/network service messages were assigned the highest priority, in
      general, the associated queue (Type DG-A) was not identified as the driving
      COS queue category.
      COS Category Definitions: It should be noted that alternative COS category
      definitions (and the resulting difference in placement of operational services)
      may significantly impact information transfer rate requirements. For example,
      a reduction in the number of categories in the master list may result in the up-
      levelling of a number of services which, in turn, may increase the required
      information transfer rate.
      Message Segmentation: The assumed message sizes were not adjusted to
      consider packet size limitations common with networks; that is, message
      segmentation was not assumed. It is anticipated that the results might be
      somewhat affected if this was taken into account. For example, if a large
      lower priority message was segmented, it would allow a higher priority
      message to be inserted in the data flow before the transmission of the lower
      priority message is completed.

6.4.4.2 Specific Comments
The following are comments that apply to one or more of the results in the above
tables:
      A-EXEC Service: The A-EXEC Service is a performance driver in the
      Phase 2 ENR service volume.
       Note: The use of rounding and changes in the model to use maximum message
       sizes has reduced the difference in Version 2.0 between results with and


                                        125
                                 COCR Version 2.0


       without A-EXEC. Notwithstanding, the A-EXEC service is still a performance
       driver in the Phase 2 ENR service volume.
       Capacity in Phase 2: The increase in capacity requirements in Phase 2 for
       the Airport Domain can be attributed in part to increased message sizes and
       reduced latencies.

6.5 Broadcast Data Loading Analysis
The broadcast data loading analysis provides an estimate of the needed information
transfer rate within a defined transmission volume.

Note: The addressed portion of the AIRSEP service has been included in the
broadcast communication loading analysis. It has been assumed that this addressed
operational service is transmitted using broadcast communication service, e.g., an
addressed message is provided to the FRS, the FRS broadcasts the addressed
message, and only the FRS addressee receives/processes the message.

Broadcast ranges are based on operational requirements for data transfer between
users. Air-air transfers have shorter range requirements than air-ground transfers. For
example, the C&P SURV range in the ENR domain is 100 NM and the ATC SURV
range is 200 NM in the same domain. Data transfers for air-ground applications can
be supported by a set of networked ground transmitters/receivers; so, the aircraft
transmission doesn’t necessarily need to meet the full range.

The objective of the loading analysis is to estimate the required information transfer
rate that must be supported by the FRS. As such, it does not consider the impacts of
transmission collisions (common with ‘unorganised’ broadcast technology) or media
access delays or scheduling overhead (common with ‘organised’ shared-media access
technologies).

A simple model was used to develop the capacity requirements. Only worst case
transmission volume densities are evaluated.

The following sections provide a brief description of the methodology, loading
analysis results, and an analysis of the results.

6.5.1 Methodology
The estimated information transfer rate is for each broadcast service is calculated
by multiplying the PIAC (see Section 6.2.1.5.2) by the message size (see Section
6.2.2.3) and dividing the result by the FRS latency requirement (see Section 6.2.2.4).
Results are provided for domain-based transmission volumes and fixed range
transmission volumes (see Section 6.2.1.1.2).

For the APR, TMA and ENR domains in Phase 1, the totals for the domain-based
transmission volumes are the sum of the SURV and TIS-B loads. For same domains
in Phase 2, the totals are the sum of the SURV, WAKE, and PAIRAPP totals. The
C&P, ITP, M&S SURV broadcast loads are excluded from the totals because they are
redundant with the SURV broadcasts.




                                         126
                                COCR Version 2.0


6.5.2 Transmission Volume Results
Table 6-33 and Table 6-34 provide the Phase 1 results for the domain-based and fixed
range transmission volumes, respectively. Table 6-35 and Table 6-36 provide the
Phase 2 results.




                                        127
                                                                                                          COCR Version 2.0



                                                                                                                                                                                      Msg
                                   Update rate (s)                              Range (NM)                        Latency FRS (s) TD95                       PIAC                     Size       Information Transfer Rate (kbps)
      Services                                                                                                                                                                       (bytes)

                     APT     TMA       ENR      ORP      AOA      APT     TMA      ENR     ORP     AOA     APT    TMA     ENR      ORP   AOA    APT   TMA    ENR     ORP    AOA       ALL      APT    TMA     ENR     ORP     AOA

C&P SURV               -       -         3         3      -                 -      100     100        -      -      -      1.2     1.2    -      -     -     250      3       -       34         -      -      57      0.7      -
ITP SURV               -       -         -         3      -                 -       -      100        -      -      -       -      1.2    -      -     -       -      3       -       34         -      -       -     0.7       -
M&S SURV               -       3         3           -    -                60      100       -        -      -     1.2     1.2      -     -      -    125    250      -       -       34         -     28      57       -       -
PAIRAPP SURV           -       -         -           -    -         -       -       -        -        -      -      -       -       -     -      -     -       -      -       -        -         -      -       -       -       -
AIRSEP                 -       -         -           -    -         -       -       -        -        -      -      -       -       -     -      -     -       -      -       -        -         -      -       -       -       -
AIRSEP SURV            -       -         -           -    -         -       -       -        -        -      -      -       -       -     -      -     -       -      -       -        -         -      -       -       -       -
SURV                   2       5        10         10     -         5     100      200     200        -     0.4    1.2     1.2     1.2    -     232   300    850      10      -       34       158     68     193     2.3       -
TIS-B (note 1)         2       5        10           -    -         5     100      200       -        -     0.4    1.2     1.2      -     -     232   300    850      -       -       34       158     68     193       -       -
WAKE                   -       -         -           -    -         -       -       -        -        -      -      -       -       -     -      -     -       -      -       -        -         -      -       -       -       -
                                                                                                                                                                    TOTAL (kbps)               316     136    386     2.3       -

Note 1 – TIS-B is a special case in that the age of the surveillance data could be older than the update rate.


                                                              Table 6-33: Phase 1 Broadcast Information Transfer Rate – Separate Domains

                                                                                                                                                       Msg
                                                                                                                                                              Information Transfer
                                                              Update rate (s)            Range (NM)         Latency FRS (s) TD95         PIAC          Size                             TOTAL
                                        Services                                                                                                                   Rate (kbps)
                                                                                                                                                      (bytes)

                                                         APT      TMA      ENR     APT       TMA   ENR      APT    TMA     ENR     APT   TMA    ENR   ALL     APT    TMA     ENR        TOTAL

                                Range 100 NM              2         5       10     100       100   100      0.4     1.2    1.2     475   300    250    68     646     136    113           895
                                Range 150 NM              2         5       10     100       100   100      0.4     1.2    1.2     700   600    500    68     952     272    227           1,451


                                                                 Table 6-34: Phase 1 Broadcast Information Transfer Rate – Fixed Range




                                                                                                                   128
                                                                                  COCR Version 2.0


                                                                                                                                                            Msg
                    Update rate (s)                        Range (NM)                     Latency FRS (s) TD95                        PIAC                  Size Information Transfer Rate (kbps)
   Services                                                                                                                                                 bytes
               APT TMA ENR ORP AOA APT TMA ENR ORP AOA APT TMA ENR ORP AOA APT TMA ENR ORP AOA ALL                                                                  APT TMA ENR ORP AOA

C&P SURV        -   -     3         3   -             -       100    100     -       -      -     1.2    1.2      -      -     -      320      14      -     34      -     -    73    3.2     -
ITP SURV        -   3     3         3   -            60       100    100     -       -     1.2    1.2    1.2      -      -    160     320      14      -     34      -    36    73    3.2     -
M&S SURV        -   3     3         -   -            60       100       -    -       -     1.2    1.2     -       -      -    160     320       -      -     34      -    36    73     -      -
PAIRAPP SURV   2    2      -        -   -       5    60        -        -    -      0.4    0.4     -      -       -      4    10       -        -      -     -       3     7     -     -      -
AIRSEP          -   -      -        -   -       -     -        -        -   100      -      -      -      -      2.4     -     -       -        -     12    497      -     -     -     -     20
AIRSEP SURV     -   -      -        -   5       -     -        -        -   100      -      -      -      -      1.2     -     -       -        -     36     34      -     -     -     -      8
SURV           2    5     5         5   -       5    100      200    200     -      0.4    1.2    1.2    1.2      -     322   400 1100         34      -     34     219   91    249   7.7     -
TIS-B           -   -      -        -   -       -     -        -        -    -       -      -      -      -       -      -     -       -        -      -     -       -     -     -     -      -
WAKE           2    5     5         -   -       5    100      200       -    -      0.4    0.4    1.2     -       -     26    400 1100                 -     34      18   272   249    -      -
                                                                                                                                              TOTAL (kbps)          239   370   498   7.7    28


                                            Table 6-35: Phase 2 Broadcast Information Transfer Rate – Separate Domains


                                                                                                                              Msg           Information
                                                                                     Latency FRS (s)
                                         Update rate (s)           Range (NM)                                    PIAC         Size         Transfer Rate      TOTAL
                         Services                                                         TD95
                                                                                                                              bytes            (kbps)          (kbps)
                                        APT TMA ENR           APT TMA ENR           APT TMA ENR          APT TMA ENR ALL              APT TMA ENR

                    Range 100 NM        2       5     10       100    100   100     0.4     0.4    1.2   600     400    320    68      816     544    145        1,407
                    Range 150 NM        2       5     10       100    100   100     0.4     0.4    1.2   900     800    640    68     1,224 1,088 290            2,602


                                              Table 6-36: Phase 2 Broadcast Information Transfer Rate – Fixed Range




                                                                                           129
                                  COCR Version 2.0



6.5.3 Analysis of Results
As noted in the introductory paragraphs, the analysis looks at potential information
transfer rates and thus does not include the impacts of transmission collisions, media
access delays and/or scheduling/message overhead. For UAT, the message overhead
includes synchronization and forward error correction (FEC) bits that would increase the
overall message size by 76%. For ‘unorganised’ broadcast technologies, the collision
rate increases with increasing message transmission densities. For these technologies,
increasing transmission rates are met with diminishing returns. It is reasonable to
assume that for these technologies the required RF transmission rates would, at least,
need to be double that of the values reflected in the tables above for the higher message
density transmission volumes.




                                          130
                                   COCR Version 2.0



7 CONCLUSIONS
7.1 Overall
This final version of the COCR has been developed primarily to estimate the
requirements for a future communication system and to enable selection of supporting
communications technologies. To achieve this, a requirements-driven approach was
taken to assess air-ground and air-air data and voice ATS and AOC communications i.e.,
safety and regularity of flight communications needed to support future concepts.
Several rounds of stakeholder consultations were conducted to ensure agreement on the
process which was followed. Wide distribution of earlier versions of the COCR was
provided via national and international forums. The technical requirements for a Future
Radio System were determined from the operational requirements, independent from any
specific technology. This approach ensures that the communications requirements were
based on the needs rather than being driven by technology.

Two main phases of ATM developments were considered. The first phase (Phase 1)
represents an increasing use of data communications, but is essentially similar to current
tactical management of aircraft. Concepts in Phase 2 represent a paradigm shift towards
more intervention by exception principles. It includes use of trajectory management,
greater information exchange between aircraft and ground systems to achieve better
airspace utilisation and user preferred trajectories. In addition, autonomous operations
take place in some parts of the airspace. The concepts were drawn from the ICAO and
regional implementation plans. In particular, concepts emerging from SESAR in Europe
and NextGen in the United States were included where information was available.

Having identified the concepts and underlying service requirements, the amount of
communication traffic generated in representative operational volumes was then
calculated. As part of this process, it was decided to define volumes of airspace in
which the services were required. Service Domains used were airport, terminal
manuevering area, en route (continental), oceanic, remote, polar and autonomous
operations areas. Definitions of these airspace types are given in the document. Safety
and information security requirements were undertaken as part of the determining the
requirements. The growth in traffic was also taken into account using prediction tools.

Throughout the period considered voice communication was considered to be available
at all times. However the general trend is that voice will reduce and only be used where
tactical ATM invention is required or for unusual or emergency situations.

7.2 Global Applicability
The regional applicability of the concepts described in the two phases will be dependent
on airspace capacity limitations. Consequently, the introduction of all or some of the
services described in each phase will depend on the density of traffic and associated
business cases.




                                           131
                                          COCR Version 2.0


  7.3 Results
  The document contains a range of parameters on which the suitability of communication
  systems can be assessed. They include performance requirements such as continuity,
  integrity and availability, safety and security requirements and capacity.

  A model was developed to determine the required capacity of the FRS to handle the
  traffic generated by the ATS and AOC services. A number of options for the queuing
  model were considered and the final option implemented used a single non-pre-emptive
  queue supporting ATS and AOC. ATS and AOC requirements were also determined
  independently. Other ways of using the raw data identified in this document can be
  envisaged and may be useful when reviewing specific technologies as part of the
  assessment process. Worse case conditions were assumed so that the requirements were
  not underestimated.

  The most stringent FRS allocated data requirements are highlighted in Table 7-1.

Service    Service      Confidentiality                  Latency (sec)                Integrity   Availability
&           Type                                                                                  Of Provision
                                                                                        FRS
Phase                                     APT     TMA        ENR     ORP       AOA
                                                                                                      FRS
ATS       Broadcast        Medium          0.4     1.2        1.2        1.2    -      5.0E-8      0.9999975
Phase 1
          Addressed        Medium          3.8     3.8        3.8    26.5       -      5.0E-6        0.9995

ATS       Broadcast        Medium          0.4     1.2        1.2        1.2   1.2     5.0E-8      0.9999975
Phase 2
          Addressed        Medium          1.4    0.74       0.74        5.9   1.4    5.0E-10     0.9999999995

AOC       Addressed        Medium         13.60   13.60     13.60    26.50     26.5   5.0E-10        0.9995
1+2

                      Table 7-1: Most Stringent FRS Allocated Data Requirements

  The A-EXEC service is a driving service. It has the fastest latency requirement and a
  very high availability requirement.

  A model was developed to determine the required capacity of the FRS to handle the
  traffic generated by the ATS and AOC services. A number of options for the queuing
  model were considered, and the final option implemented used a single non-pre-emptive
  queue supporting ATS and AOC. ATS and AOC requirements were also determined
  independently. Other ways of using the raw data identified in this document can be
  envisaged and may be useful when reviewing specific technologies as part of the
  assessment process. Worse case conditions were assumed so that the requirements were
  not underestimated.




                                                  132
                                     COCR Version 2.0


                         APT SV         TMA SV              ENR SV             ORP SV
   Addressed
                                                                                           AOA
Communication Load                                    HD     HD
                       HD      LD      HD     LD                     LD      HD      LD
                                                      EU     U.S.

ATS&AOC     Phase 1     30      8       8      8       15     20      15      5       5         -
 UL&DL      Phase 2    200      40     40      40     150     200    150     40      30     100

             Table 7-2: Most Stringent FRS Addressed Communication Load (kbps)

  In Phase 2, the reduced latencies and large message sizes for new services (e.g.
  COTRAC) have resulted in significantly larger communication load.

  Some sensitivity analysis was carried out on the results and it was noted that the capacity
  requirements do not increase linearly with aircraft density. In some cases, the latency
  had the greatest effect on capacity. Under these conditions not all the capacity was used
  therefore doubling the aircraft to be supported did not double the capacity requirements.

  7.4 Observations

  7.4.1 Safety assessment methodology
  Considerable effort was undertaken in carrying out safety assessments of the new
  services in the context of the two phases to determine the effects on the FRS. The
  COCR team reviewed and applied existing safety assessments done by other
  organisations to determine the requirements on the FRS. The task was therefore made
  more difficult due to the need to understand the different approaches adopted.

  7.4.2 Advanced ATS Services
  In reviewing future concepts, some very advanced services were identified which
  Stakeholders believed would be implemented within the timeframe of the COCR. One
  such service is A-EXEC. During the safety assessment, it became apparent that the
  service requires extremely high latency, integrity and availability requirements. These
  requirements make evolution to the environment defined for its use subject to further
  consideration. Of particular concern is automatic execution of flight manoeuvres
  without pilot involvement.

  7.4.3 AOC Services
  The COCR team acquired as much information as possible on the future plans for use of
  AOC services. The services identified were understood to be those that commercial
  airspace users are either using or plan to use in the future. If a major expansion of AOC
  services takes place, this could considerably increase the communication requirements.

  7.5 Areas for Further Consideration
  The following areas were identified for further consideration.
          Refinement of the safety assessment process.



                                             133
                           COCR Version 2.0

Performance assessment methodology against operational use e.g., a given
instance of the ACL service could include several one-way transits needing to
take place within the RCP to close the operational uplink and downlink.
During the timeframe of the FCS, future concepts used to derive the FCS
requirements were still evolving. Re-assessment of the final versions of those
concepts may change the requirements that a given technology must support.
The results of this study highlight the need for continuing collaboration between
the parties.
Update of Peak Instantaneous Aircraft Counts allowing for new traffic demand
models that have come into existence since this work was started, especially in
the TMA domain.
Refinements in the operational scenarios to more fully include UAS, VLJ, and
General Aviation aircraft and their needs in the timeframes discussed.
Refinement of the voice requirements and subsequent voice loading analysis.
During the study, AOC communication requirements were developed using the
best information available. This form of communication is known to have
progressed significantly during the study and should be reassessed.




                                  134
COCR Version 2.0




APPENDICES




      135
                                    COCR Version 2.0


Appendix A             STATFOR AND SAAM OVERVIEW
A.1 Description of the Air Traffic Statistics and Forecast Service
The Air Traffic Statistics and Forecast (STATFOR) service was established by the
EUROCONTROL Agency and has been active since 1967. The objective of the
STATFOR service is to provide statistics and forecasts on air traffic in Europe and to
monitor and analyse the evolution of the Air Transport Industry.

The STATFOR service of statistics and forecasts is discussed and reviewed by the
STATFOR User Group, a body of European forecasting and statistics experts that meets
regularly. The terms of reference of the User Group include methodological and
practical aspects of statistics and forecasting as well as an exchange of views and
information on the current and possible future situation of air traffic, and on activities in
National Administrations, International Organizations and elsewhere in the field of
statistics and forecasting.

Currently, STATFOR’s two main products are monthly statistics, and an annual
medium-term forecast.

A.2 Description of the System for Traffic Assignment and Analysis at a
    Macroscopic Level (SAAM)
SAAM is an integrated system for wide or local design evaluation, analysis, and
presentation of Air Traffic Airspace/TMA scenarios.

A.2.1 Background
EUROCONTROL develops and operates a set of tools in order to assess quantitative
information in support of development at Europe’s airports, on air routes and the
airspace system. SAAM is being used in the context of Airspace Management and
Navigation activities to perform strategic traffic flow organisation, route network and
airspace optimisation, analysis and presentation.         These features support the
development of the EUROCONTROL Airspace Strategy for the ECAC states.

SAAM can operate on an area the size of ECAC or at the detailed level of an airport, and
is able to process a large quantity of data: hundreds of sectors, millions of cells, several
days of traffic. It can be used for preliminary surveys, for testing and analysing various
options and for preparing a scenario that can be exported to fast-time or realtime
simulators. Its powerful “what if” functions associated with presentational capabilities
make SAAM an ideal tool for understanding, experimenting, evaluating and presenting
European Airspace proposals and future ATC concepts.

A.2.2 Modelling
Airspace structure design and the processing of traffic trajectories are fully mastered and
linked together in SAAM. Users can create/change/design both air traffic route
networks and airspace volumes. At any time full 4-D trajectories can be generated
(based on traffic demand, route network, aircraft performance) and intersected with
airspace volumes. By default, SAAM will choose the best trajectory option (shortest
path and optimal profile performance), but operational rules can be applied such as flight



                                            136
                                    COCR Version 2.0

level constraints (arrival, departure, cruising) and/or reserved or restricted route network
segments.

In order to help optimise airspace structures, the user can request the traffic demand be
optimally and automatically distributed on the structure at the lowest cost, while
respecting operational rules, thus revealing structural weaknesses of airspace areas. This
function makes use of advanced linear programming techniques, embedded in the SOP
model and developed in the EUROCONTROL Airspace Management and Navigation
(AMN) Unit. SIDs and STARs can be portrayed for different cases, possibly with
terrain data to help understand and improve TMA organisation.

A.2.3 Analysis
Different sources of data can be selected for analysis and comparisons: Central Flow
Management Unit (CFMU) flight plan, imported radar data, or simply the data coming
out from the SAAM modelling tools.

Many queries can be combined and applied on the 4-D traffic trajectories. For instance,
the user can request flight trajectories based on departures, arrivals, route points,
companies, sectors crossed, aircraft type, etc.

Various analyses can be performed on loaded airspace structures. The number of flights
on route network points, route network segments, airspace volume and three dimensional
(3-D) density cells can be filtered and displayed accordingly. Graphs showing variations
and comparisons of airspace load, entry rate, and conflict, for each hour of the day are
easily produced. In the same manner, Controller workload graphs can be provided
rapidly using a validated analytical formula. Capacity figures for newly designed sectors
can be advantageously derived using the analytical formulas.

Route length extension, fuel consumption, delays, route charges, etc., can be launched
independently, and results can be summarised and mixed to give a global economic
indicator of a scenario.

A.2.4 Visualization/Presentation
The importance of visually pinpointing problems and graphically presenting possible
solutions was recognised from the beginning. Therefore, SAAM is entirely built on a 2-
D/3-D/4-D Geographical Information System (GIS) with the possibility of generating
time-based animations. To add more realism, SAAM can also manage and generate
stereo information (with specific hardware-like stereo glasses).

All modelling and analysis activities are integrated in this GIS platform and fully benefit
from the 3-D visualisation, animation and stereo. For instance a user can design a
specific airspace of interest in 3-D to check interaction while aircraft are flying on their
3-D trajectories. Images/animations are interactively panned, zoomed, and rotated with
the mouse. The camera location and/or “look at” point can be moved or linked to a
flying object.

Objects such as aircraft, airspace volumes, points or lines, can be moved, set on/off, or
have their graphical attributes (e.g., colour or size) smoothly changed based on time
events managed through the animations. For example, this feature is commonly used to



                                            137
                                  COCR Version 2.0

demonstrate the benefits of Flexible Use of Airspace (FUA) project. Several 3-D
aircraft models are available and can be imported from the classical “3ds” format.

Users can add titles and bitmaps to their design. Pictures/animations can be grouped into
a SAAM presentation file that can be run manually or in standalone mode. If preferred,
a SAAM presentation can be recorded in a standard “avi” movie file.




                                          138
                                   COCR Version 2.0


Appendix B            MID LEVEL MODEL DESCRIPTION
B.1 Introduction
Modelling is the technique of building an imitative representation of the functioning of a
real or proposed system by means of the functioning of another. The key power of
modelling is the ability to model the behaviour of the real system as time progresses, and
study the results to gain insights into its behaviour.

Computer modelling involves the need for some sort of software to represent the
proposed system. The Mid-Level-Model (MLM) is a software model of the National
Airspace System (NAS), developed by The MITRE Corporation’s Center for Advanced
Aviation System Development (CAASD), to study system-wide effects to the NAS for
specific scenarios. MLM software is data driven; the model is specified based on user-
defined and default data items.

B.2 Discrete Event Simulation
MLM is built around the principles of discrete event simulation. Discrete event
simulation requires the presence of two key factors:
       Model Software
       Mechanisms for time advance

B.2.1 Model Software
Model Software: Model software is made up of entities. Entities are tangible elements
found in the real world with respect to the system being modelled. Each identified entity
exhibits a very specific functional behaviour of the system that is being modelled and
plays a very specific role within the system. The aggregation of the functional behaviour
of the individual entities represents the functional capability of the system as a whole.

There are two types of entities. They are:
       Input Entity: These are inputs to the modelled system and in the modelling
       world better referred to as “temporary entities”. Input entities get very often
       confused with user customizable system configurable parameters (discussed
       below). The easiest way to recognize the input entity(ies) to a system is to
       identify the entity(ies) whose absence from the system will produce no insights
       to the working of the system. Input entities are temporary as they exist only for
       short durations and are only created on an as need basis and at very specific times.
       They cause fluctuations in the system output, especially when the system or
       components within the system are subject to different boundary conditions.
       These entities could also exhibit different types of functionality in which case the
       fluctuations to the system can be studied for different kinds of input.
       Permanent Entity: Permanent entities exhibit specific functional behaviour
       within the system being modelled. They typically exist through the entire
       simulation run time and are created when the system comes up and are destroyed
       only when the system itself shuts down or at the exhaustion of the inputs. They
       have the unique quality of being able to facilitate or inhibit the flow of a
       temporary entity as the temporary entity traverses the system. To study the


                                             139
                                    COCR Version 2.0

       behaviour of a system, either permanent entities are calibrated for varying
       boundary conditions while maintaining constant input or permanent entities are
       maintained at constant values while changing the input characteristics.
System Configurable Parameters: These are parameters that are user configurable and
are used to alter the default functionality or threshold of the individual entities or the
system as a whole. If the software provides it, users use this capability to configure the
system for different scenarios to study the similarities or fluctuations in the system
output, due to the effect of the interaction between input entities and permanent entities.

In the NAS the input entities are flights, and the permanent entities are airports, sectors,
air traffic Controllers (ATCs), and communications, navigation, and surveillance (CNS)
systems. The flights, airports, sectors, ATCs, and CNS systems comprise the NAS
system. The flight entities enter the NAS and requests the services from the permanent
entities to complete the flight. Routing, weather, and traffic flow management (TFM)
are functional components that affect the performance of the system as a whole by
imposing specific kinds of boundary conditions on the system entities.

MLM, which models the NAS, has one input entity, the Flight entity. Flight entities have
the capability to change its functional behaviour based on the type of the aircraft for the
specific flight. The number of flights into MLM can also be varied. MLM implements
Airport and Sector as permanent entities. Their services are requested by the flight
object to complete a simulated flight. MLM provides system configuration parameters
to customize routing, weather, and TFM functionality that can be used by the analyst to
modify the boundary conditions of the flights, airports and sector entities for specific
studies.

B.2.2 Mechanisms for Time Advance
The “mechanism for time advance” is provided by the SLX environment. Time is
advanced based on the next event and not based on time slicing. With the next event, the
model is advanced to the time of the next significant event. Hence if nothing is going to
happen in the next few minutes, SLX will move the model forward by few minutes in
one go and run the first event that is scheduled for that time. Advancing time in this
fashion is efficient and allows for speedy evaluations. SLX is also the modelling tool
which provides a language definition and compiler capability to develop the model.

B.3 MLM High Level Software Architecture
The Mid-Level-Model software architecture is an actor-based model. An actor is an
entity (input or permanent) that models a very specific functional behaviour of the
system. In actor-based model architecture, each actor is driven by user-supplied
scripts/data that controls the behaviour of the actor. In the absence of a script or user
data, the actor follows a default approach. There are three types of actors:
       Requesting Actors: These actors asks for clearance from the authority actor to
       execute the next executable source code step.
       Authority Actors: These actors typically hold resources that need to be
       acquired by the requesting actor. If the resource is unavailable the requesting
       actor is made to wait till the resource is available. Authority actors from time to



                                            140
                                   COCR Version 2.0

       time may switch roles and become requesting actors especially if they need to
       obtain the resources from other actors.
       Passive Actors: These actors do not hold any resources that a requesting actor
       or authority actor uses and is not called upon by any of the other actors to
       complete a instance. These actors are called by the system on a periodic basis.
       They are used merely for monitoring purposes and for modifying configurations
       when thresholds are met and for user input detection.
The predominant MLM actors are:
       Flight Actor: This actor is designed as a requesting actor and is the input
       entity into the system. There exists one flight actor for every flight entering the
       system. Sub-functionality provided by the flight actor is pushback-times and
       taxi-out-time.
       Airport Actor: This actor is designed as an authority actor and holds several
       key resources before a flight can traverse the system. The resources being
       modelled by Airport are:
       •   Push Back
       •   Taxi Out
       •   Departure Queue (Runaway)
       •   Arrival Queue (Runaway)
       •   Taxi In
       •   Gate Clearance
       Sector Actor: This actor is designed as an authority actor. This actor provides
       clearance delivery as a flight traverses from one sector to another. There is one
       such actor for every defined sector in the NAS. This actor also models the
       following:
       •   <Airport>_dep (queue modelling the departure terminal airspace for every
           modelled airport)
       •   <Airport>_arr (queue modelling the arrival terminal airspace for every
           modelled airport)
       Statistics Actor: The statistics actor is a passive actor and its role is to collect
       metrics of interest as the simulation unfolds.
       Animation Actor: The animation actor is a passive actor and its role is to
       generate output for the Proof software (an external animation package) on a
       periodic basis with data from the model.
Figure B.3-1 is an illustration of the relationship between the various actors within the
MLM system as well as the functionality. As mentioned earlier, each actor can be
controlled through various user supplied parameters. The box identified as “MLM
System Configuration Parameters” is not an actor, but is merely a file which is read in
by MLM and sets the input and output specifications.




                                           141
                                       COCR Version 2.0



       Flight                         Airports                                        Sectors

   Pushback Proc       Pushback Mgr

   Taxi Out Proc       Taxi Out Mgr
                                                  Runaway
                                                                            Terminal Airspace
   Runaway Proc                                  Departure Q
                                                                           <Arpt>_dep Q
   Terminal Proc                                                                                En Route Sectors

                                                                                                En Route Mgr
   En Route Proc


   Terminal Proc                                                           <Arpt>_arr Q


   Runaway Proc
                                                     Arrival Q


   Taxi In Proc        Taxi In Mgr

   Gate Req Proc
                       Gate Req Mgr




      Routing Fn.       Statistics       Animation          GDP, GSP Fn.              MIT Fn.




                                                       MLM System
                                                       Configurable
                                                       Parameters


                    Figure B.3-1: MLM High Level Software Architecture

B.4 MLM Applied to the COCR
The role of MLM in development of the COCR is two-fold:
         Provide a crosscheck of Peak Instantaneous Aircraft Counts (PIACs) as derived
         by the EUROCONTROL SAAM Model.
         Provide PIACs for the U.S. NAS for specific milestones in the 2004-2030
         timeframe.
The process followed mirrors that of the SAAM tool, however, the goal was primarily to
obtain PIACs only for En Route, as Oceanic, Terminal and Surface results will require
MLM adaptation beyond the scope of expected work on COCR v1.0.

We asked the MLM modellers to perform runs of existing scenarios for 2004, 2013,
2020 and then to use regression analysis for 2030 PIACs. What was achieved was a
distribution of En Route PIACs for all NAS sectors, from which a maximum sector
PIAC could be identified. While doing so, it became apparent that, in the longer term,
the primary European concept to dealing with increased demand was to spread the
additional traffic out across the day. In the United States, the concept is to move the
additional traffic to satellite airports. This is consistent with the Joint Planning and
Development Office’s vision for the NextGen.

U. S. concepts also include the addition of thousands of Micro jets and Unmanned Aerial
Systems.


                                                 142
                                 COCR Version 2.0

NAS sectors are based upon strict geographic control principles. It is expected that
PIACs obtained through this process would become the basis for determining capacity of
future, larger sized sectors.

MLM Results were consistent with SAAM results in the En Route service domain
through 2020, but differ significantly after 2020. It was therefore felt that the COCR
should reflect both sets of results.




                                         143
                                   COCR Version 2.0


Appendix C            QUEUING MODEL DESCRIPTION
C.1 INTRODUCTION
This appendix describes the priority queuing analysis used to calculate the required
channel capacities for the Future Radio System (FRS) based on the allocated FRS delay
requirements defined in the Future Communications Study (FCS) Communications
Operating Concepts and Requirements (COCR) document.

The priority queuing analysis is a technique for estimating channel capacity to meet the
FRS delay requirements for a given message and aircraft traffic loads. Priority queuing
analysis may not take into account the details of the network protocols and the technical
implementations of the FRS. The accuracy of the results depends on the assumptions
built into the model and the inputs to the model.

This appendix is organized as follows:
       Section C.1 Introduction
       Section C.2 Data Channel Capacity Requirement Analysis Process and Inputs:
       This section describes data channel capacity requirement analysis process, inputs,
       and some assumptions made in the analysis.
       Section C.3 Data Channel Capacity Priority Queuing Analysis: This section
       describes the priority queuing models and the analysis process.
       Section C.4 Priority Queuing Analysis Basics: This section presents the basics of
       priority queuing analysis.

C.2 DATA CHANNEL CAPACITY REQUIREMENT ANALYSIS PROCESS
    AND INPUTS
Figure C-1 gives an overview of the service volume data channel capacity requirement
analysis process. It consists of inputs that define the problem, a process for solving the
problem, and the desired output.




                                           144
                                   COCR Version 2.0


   Inputs                     Process                            Output
   (Problem definition)       (for solving the problem)          (Desired result)
 Service volume Network
 Management, ATS and
 AOC service instances
 per aircraft
                                                           Required Data Throughput
 Flight duration in service     Priority-Queueing Analysis Without Subnetwork
 volume                         Using Microsoft Excel      Overhead for Service Volume


 PIAC per service volume


 Service volume T(95)




  Figure C-1: An Overview of Service Volume Data Channel Requirement Analysis Process

As seen in Figure C-1, there are 4 inputs that define the problem:
   1. The service volume Air Traffic Service (ATS) and Aeronautical Operational
      Communications (AOC) message traffic between each pair of aircraft and ground
      systems
   2. Average flight duration in service volume
   3. Peak Instantaneous Aircraft Count (PIAC) in each service volume
   4. The Required Communications Technical Performance (RCTP) for the messages,
      i.e., 95th percentile FRS end-to-end delay TT(95)

C.2.1 ATS and AOC Traffic
The ATS and AOC traffic describe the statistics for each application service in a service
volume including uplink and downlink message sizes and service instances.

C.2.2 Flight Duration in Each Position/Sector
Flight durations apply to both low and high-density positions/sectors and to arrival and
departure phases of flight. Flights durations are used with service instances to derive the
message arrival rates that are used in the requirement analysis.

C.2.3 PIACs
PIACs in each high and low-density service volume (position/sector) in each domain
have been used in accordance with the selected values in the main document. PIACs are
used with the per aircraft message traffic defined in the data loading tables to derive the
total message traffic in a service volume.




                                           145
                                   COCR Version 2.0


C.2.4 Data Communications Equipage
The PIAC represents the maximum number of aircraft in a position/sector. Of this
number, a percentage of aircraft is equipped for data communications service. This
percentage multiplied by the PIAC would represent the maximum number of aircraft that
use the data communications service in a position/sector.

C.2.5 Percentage Departure
In the airport and TMA domains, a distinction is made between departing and arriving
aircraft because they may use different data communications services and have different
service instances. In the analysis process, it is assumed that a certain percentage of data
communications equipped aircraft are departure aircraft and the remainder arriving
aircraft. The mix of departing and arriving aircraft produces the aggregate data traffic
for a position/sector.

C.3 DATA CHANNEL CAPACITY PRIORITY QUEUING ANALYSIS

C.3.1 Definitions
The following are the definitions and descriptions of most of the symbols used in this
section.




                                           146
                           COCR Version 2.0


Symbol    Definition/Description
ATS       Air Traffic Service
AOC       Aeronautical Operational Control
λAGi      Message arrival rate Air-to-Ground for priority i
λGAi      Message arrival rate Ground-to-Air for priority i
λGAAGi    Message arrival rate Ground-to-Air and Air-to-Ground for priority i
ULD Msg   Departure-aircraft UpLink Message size for a given priority
ULD λ     Departure-aircraft UpLink message arrival rate per aircraft for a given priority
ULD λT    Departure-aircraft UpLink message arrival rate for a service volume
          (position/sector) for a given priority
DLD Msg   Departure-aircraft DownLink Message size for a given priority
DLD λ     Departure-aircraft DownLink message arrival rate per aircraft for a given
          priority
DLD λT    Departure-aircraft DownLink message arrival rate for a service volume
          (position/sector) for a given priority
ULA Msg   Arrival-aircraft UpLink Message size for a given priority
ULA λ     Arrival-aircraft UpLink message arrival rate per aircraft for a given priority
ULA λT    Arrival-aircraft UpLink message arrival rate for a service volume
          (position/sector) for a given priority
DLA Msg   Arrival-aircraft DownLink Message size for a given priority
DLA λ     Arrival-aircraft DownLink message arrival rate per aircraft for a given
          priority
DLA λT    Arrival-aircraft DownLink message arrival rate for a service volume
          (position/sector) for a given priority
SiMsg     Service i Message size for a given priority
SiI       Service i Instance for a given priority
Msg       Aggregate message size for a given priority
I         Aggregate instance for a given priority
λ         Message arrival rate for a given priority
UL Msg    UpLink Message size for mixed departure and arrival for a given priority
UL λT     UpLink message arrival rate for mixed departure and arrival for a service
          volume (position/sector) for a given priority
DL Msg    DownLink Message size for mixed departure and arrival for a given priority
DL λT     DownLink message arrival rate for mixed departure and arrival for a service
          volume (position/sector) for a given priority
MsgT      Aggregate uplink and downlink Message size for mixed departure and arrival
          for a given priority
λT        Aggregate uplink and downlink message arrival rate for mixed departure and
          arrival for a service volume (position/sector) for a given priority




                                    147
                                             COCR Version 2.0


C.3.2 Priority Queuing Analysis Models
This section presents the queuing analysis models used to obtain the results.

C.3.2.1 ATS and AOC Traffic on the Same Channel
In this set of models, ATS and AOC traffic share 1 single queue. 2 separate models
were developed ─ separate channels for uplink and downlink traffic and shared channel
for uplink and downlink traffic. Figure C-2 shows the first model that uses 2 separate
channels for ATS and AOC traffic ─ 1 uplink and 1 downlink.
                                                                       Air-to-Ground
                                                    ATS λAG1   ATS λAG2 ATS λAG3 ATS λAG4 AOC λAG1 AOC λAG2




                Separate Uplink Channel




                        Server
                                                                             Server




                                                                                      Separate Downlink Channel




 ATS λGA1   ATS λGA2 ATS λGA3 ATS λGA4 AOC λGA1 AOC λGA2

                    Ground-to-Air

     Figure C-2: Combined ATS and AOC Traffic Separate Uplink and Downlink Channels
Figure C-3 shows the second model that uses 1 channel for uplink and downlink ATS
and AOC traffic.




                                                       148
                                 COCR Version 2.0


 ATS λGA1


 ATS λAG1


 ATS λGA2


 ATS λAG2


 ATS λGA3


 ATS λAG3                                             Shared Channel
                                                      Uplink and Downlink Traffic
                                         Server
 ATS λGA4


 ATS λAG4


 AOC λGA1



 AOC λAG1


 AOC λGA2


 AOC λAG2


        Figure C-3: Shared Channel for ATS and AOC Uplink and Downlink Traffic

C.3.2.2 Separate ATS and AOC Channels

In this set of models, ATS and AOC traffic use separate channels. 2 separate models
were developed ─ separate channels for uplink and downlink traffic and combined
channels for uplink and downlink traffic. Figure C-4 shows the first model that uses 4
separate channels for ATS and AOC traffic ─ 1 ATS uplink, 1 AOC uplink, 1 ATS
downlink, and 1 AOC downlink.




                                         149
                                                    COCR Version 2.0

                                                                                       Air-to-Ground
                                                                    ATS λAG1   ATS λAG2 ATS λAG3 ATS λAG4        AOC λAG1AOC λAG2



  Separate ATS Uplink Channel         Separate AOC Uplink Channel




                Server                         Server
                                                                                   Server                           Server




                                                                Separate ATS Downlink Channel               Separate AOC Downlink Channel




   ATS λGA1   ATS λGA2 ATS λGA3 ATS λGA4     AOC λGA1AOC λGA2

                      Ground-to-Air


        Figure C-4: Separate ATS and AOC and Separate Uplink and Downlink Channels
Figure C-5 shows the second model that uses 1 channel for uplink and downlink ATS
traffic and 1 channel for uplink and downlink AOC traffic.
     ATS λGA1


     ATS λAG1


     ATS λGA2

                                                                                         Separate ATS Channel
     ATS λAG2                                                                            Uplink and Downlink Traffic
                                                           Server
     ATS λGA3


     ATS λAG3



     ATS λGA4


     ATS λAG4


     AOC λGA1

                                                                                         Separate AOC Channel
     AOC λAG1                                                                            Uplink and Downlink Traffic
                                                           Server
     AOC λGA2


     AOC λAG2



 Figure C-5: Separate ATS and AOC Channels with Combined Uplink and Downlink Traffic




                                                                150
                                    COCR Version 2.0


C.3.3 Traffic Model Development
Figure C-6 shows the 2-phase priority queuing analysis process for a mixed aircraft
arrival and departure environment in a service volume. The first phase is the traffic
model development phase, and the second phase is the priority queuing analysis phase.
The first phase which is discussed in more detail later includes developing traffic
statistics for departure and arrival aircraft based on data loading tables. The queuing
analysis which is also discussed in more detail later consists of analysis for separate
uplink and downlink channels and shared uplink and downlink channel.

                        Develop traffic statistics                Develop traffic statistics
                        for departure aircraft based              for arrival aircraft based
                        Data loading table                        Data loading table
     Develop
     Traffic Model


                                          Perform queueing analysis for
                                          Mixed departure and arrival
                                          For separate uplink and downlink
                                          Channels

 Perform Priority
 Queueing Analysis
                                           Perform queueing analysis for
                                           Mixed departure and arrival
                                           For shared uplink and downlink
                                           Channel


   Figure C-6: Priority Queuing Analysis Process for a Mixed Arrival and Departure Service
                                          Volume

C.3.3.1 Departure Aircraft
Figure C-7 shows a 2 part traffic model development process for departure aircraft ─ per
aircraft and per service volume.




                                            151
                                      COCR Version 2.0


                  Per Aircraft
                  Sort services into similar priorities
                  For each Priority
                  Develop departure uplink message statistics
                             ? Uplink average message size,ULD Msg
                             ? Uplink message arrival rate, ULD ?
                  Develop departure downlink message statistics
                             ? Downlink average message size, DLD Msg
                             ? Downlink average arrival rate, DLD ?




 Per Service Volume
 For each Priority
 Develop departure uplink message statistics
            ? Uplink average message size, ULD Msg
            ? Uplink message arrival rate, ULD ?T = PIAC * Equipage * Percent Departure * ULD ?
 Develop departure downlink message statistics
            ? Downlink average message size, DLD Msg
            ? Downlink average arrival rate, DLD ?T = PIAC * Equipage * Percent Departure * DLD ?



            Figure C-7: Departure Aircraft Traffic Statistics Development Process

The per aircraft process consists of developing departure and arrival aircraft message
traffic based on departure and arrival message traffic in ATS and AOC data loading
tables. The services in the data loading tables are sorted by priority. For each priority,
departure uplink and downlink traffic statistics are developed. The departure uplink
statistics consists of the following:
       Uplink average message size, ULD Msg
       Uplink message arrival rate, ULD λ
The departure downlink statistics consists of the following:
       Downlink average message size, DLD Msg
       Downlink message arrival rate, DLD λ
The per service volume traffic model is based on the per aircraft departure and arrival
traffic, PIAC, equipage, and the departure and arrival mix. For each priority, departure
uplink and downlink traffic statistics are developed. The departure uplink statistics
consists of the following:
       Uplink average message size, ULD Msg
       Uplink message arrival rate, ULD λT = PIAC * Equipage * Percent Departure *
       ULD λ
The departure downlink statistics consists of the following:
       Downlink average message size, DLD Msg




                                              152
                                            COCR Version 2.0

        Downlink message arrival rate, DLD λT = PIAC * Equipage * Percent Departure
        * DLD λ

        Aggregate Message Size and Arrival Rate

Figure C-8 shows the methods for calculating the aggregate message size, instance, and
message arrival rate for each priority. The service message size and instance are
represented by SiMsg and SiI respectively.

 Calculate aggregate message size from service message sizes
              N                     N
  Msg = ∑ ( S i Msg * S i I ) / ∑ S i I
              i =1                  i =1

 Calculate aggregate instance from service instances
        N
  I = ∑ Si I
       i =1

 Calculate average message arrival rate
 λ = I/Flight Duration


 Figure C-8: Methods for Calculating Aggregate Message Size, Instance, and Arrival Rate for
                                      Each Priority

C.3.3.2 Arrival Aircraft
Figure C-9 shows a 2 part traffic model development process for arrival aircraft ─ per
aircraft and per service volume.

                             Per Aircraft
                             Sort services into similar priorities
                             For each Priority
                             Develop arrival uplink message statistics
                                          ? Uplink average message size, ULA Msg
                                          ? Uplink message arrival rate, ULA ?
                             Develop arrival downlink message statistics
                                          ? Downlink average message size, DLA Msg
                                          ? Downlink average arrival rate, DLA ?




 Per Service Volume
 For each Priority
 Develop arrival uplink message statistics
              ? Uplink average message size, ULA Msg
              ? Uplink message arrival rate, ULA ?T = PIAC * Equipage * (100 - Percent Departure) * ULA ?
 Develop arrival downlink message statistics
              ? Downlink average message size, DLD Msg
              ? Downlink average arrival rate, DLA ?T = PIAC * Equipage * (100 - Percent Departure) * DLA ?




                     Figure C-9: Arrival Aircraft Traffic Statistics Development Process




                                                     153
                                    COCR Version 2.0


C.3.4 Queuing Analysis Process

C.3.4.1 Mixed Departure and Arrival for Separate Uplink and Downlink Channels
Figure C-10 shows the queuing analysis process for mixed departure and arrival service
volume for separate uplink and downlink channels. The process consists of developing
separate uplink and downlink traffic statistics and performing queuing analysis to
calculate the required uplink and downlink channel capacities.

          Develop uplink and downlink traffic statistics
          for mixed departure and arrival




 Perform priority queueing analysis
          ─ Calculate required uplink channel capacity
          ─ Calculate required downlink channel capacity

 Figure C-10: Queuing Analysis Process for Mixed Departure and Arrival for Separate Uplink
                                 and Downlink Channels

       Traffic Statistics for Mixed Departure and Arrival Service Volume

Figure C-11 shows the procedure for calculating the uplink and downlink traffic
statistics for mixed departure and arrival service volume.

 Develop Uplink Statistics
             ─ Uplink message size
               UL Msg = (ULD Msg * ULD λT + ULA Msg * ULA λT)/(ULD λT + ULA λT)
             ─ Uplink message arrival rate
               UL λT = ULD λT + ULA λT
 Develop Downlink Statistics
             ─ Downlink message size
               DL Msg = (DLD Msg * DLD λT + DLA Msg * DLA λT)/(DLD λT + DLA λT)
             ─ Downlink message arrival rate
               DL λT = DLD λT + DLA λT


Figure C-11: Procedure for Calculating the Uplink and Downlink Traffic Statistics for a Mixed
                           Departure and Arrival Service Volume

C.3.4.2 Mixed Departure and Arrival for Shared Uplink and Downlink Channel
Figure C-12 shows the procedure for calculating the shared uplink and downlink channel
capacity for mixed departure and arrival service volume. The process consists of using
the previously developed uplink and downlink statistics in the analysis.


                                            154
                                   COCR Version 2.0


     Use Uplink and Downlink Statistics, e.g.,UL Msg, DL Msg, UL λT, DL λT




 Perform priority queueing analysis
            ─ Calculate required shared uplink and downlink channel capacity using
              uplink and downlink statistics


  Figure C-12: Procedure for Calculating Channel Capacity for Uplink and Downlink Traffic
                                 Sharing the Same Channel

C.3.5 Priority Queuing Analysis Procedure
Figure C-13 shows a priority queuing analysis procedure. It requires a traffic model and
the required 95th percent end-to-end delay as inputs.

                              Start

        Aggregate random message lengths, li,
        arrival rates, λi, for priority i uplink ATS and
        AOC messages
                                            2
        Calculate second moments X i


                 Enter a PIAC
                 Select a suitably low initial
                 uplink channel capacity CU


                       µi = CU/li
                       Calculate T(95)Q
                       For each priority                   Select a higher uplink
                                                           channel capacity CU


                       Are T(95)Q < T(95)         No
                         for priority i
                         messages?

                                   Yes
                               End

                    Figure C-13: A Priority Queuing Analysis Procedure




                                            155
                                                           COCR Version 2.0


C.4 PRIORITY QUEUING ANALYSIS BASICS
Figure C-14 shows a priority queuing system with different classes of arrivals that have
their own separate queues waiting for service by a single server. The different classes, A
through K, have different arrival rates, λA through λK, and priorities, A being the highest
and K the lowest. The messages in the higher priority queues are serviced ahead of
those in the lower priority queues. The messages in each class are serviced at rates µA
through µK. We assume a non-pre-emptive priority scheme where a message in service
is allowed to complete its service even if a higher priority message is waiting.
                                             Arrival                Waiting                   Servicing         Departure


                          Class A
                                                     λA


                          Class B                                                             µA
                                                     λB
                                                                                             µB        Server
                                                                                             µC
                          Class C                                                                 µK
                                                     λC



                          Class K
                                                     λk
                                                                       TWi                             TSi

                                                                              TQi



                        Figure C-14: Delay Analysis by Priority Queuing Method

The following are the definitions used in this paper and depicted in Figure C.4:

          Average class i message waiting time –                                    T   Wi



          Average class i message service time – T S i
                                                                                             =TW +T S
          Average class i message queuing delay – T Qi                                                   i       i



                                                          λi
                                             ρ       =
                                                               µi
          Class i utilisation –                  i


          λi is the message arrival rate for class i messages
          µi is the message service rate for class i messages
Assuming a single-server M/G/1 queuing system, i.e., the arrivals are memory-less
(Poisson) and service times have general distributions, the average waiting time, T W , for
                                                                                                                            i
                                   14
the class i messages is

                        ∑
                            n
                                   λi X i2
Tw i =                      i =1
         2(1 − ρ1 − ... − ρ i -1 )(1 − ρ1 − ... − ρ i ) (1)

Where:

14
     D. Bertsekas and R. Gallager, Data Networks, Prentice-Hall, 1987.


                                                                          156
                                                                COCR Version 2.0

    2
X   i
         is the second moment of the service time T S
                                                                             i




The following are the equations for calculating the second moments for the exponential
and constant distributions.

                                2            2                                          2        1
Exponential:                X           =             (7)               Constant:   X       =            (8)
                                            µ                                                   µ
                                                  2                                                  2




Note: For COCR Version 2.0, the second moment of the service time is assumed to be
the variance in the COCR service message sizes plus the average message size squared
divided by the selected capacity value. Version 1.0 queuing results assumed an
exponential distribution.

The average queuing time, T Q , for the ith priority message is
                                                            i




             1
TQ i =           + TWi
          µi                  (2)

Note: The term, 1/µi represents the message send time. COCR Version 1.0 results used
the average send time for average message in the queue. COCR Version 2.0 uses the
send time associated with the worst case COCR service assigned to the queue. This is
the COCR service with the largest message size. Individual COCR service latencies are
not insured unless the worst case COCR service size is used for the message send time.

From (1), the average waiting time for the highest priority message,                                      T    WA
                                                                                                                    , is


           ∑
                                    2
                        λ
                     n

         =           i =1 i   X     i
                                            (3)
T   WA
                 2(1 − ρ A )

The average queuing time for the highest priority message,                                  T   QA
                                                                                                     is

                 1
T        =            + T W (4)
    QA
             µA                 A




The rth percentile of the queuing time, T(r)Q, can be derived from the average queuing
time TQ as follows:

             100
T(r) Q = ln(        )TQ
            100 - r     (5)

For example, the 95th percentile of the queuing time, T(95)Q is

               100
T(95) Q = ln(         )TQ
             100 - 95     (6)




                                                                      157
                                    COCR Version 2.0


Appendix D                DEFINITIONS
Air Traffic Control        An airspace area of defined horizontal and vertical dimensions for
Sector                     which a Controller or group of Controllers (e.g., executive and
                           planning Controller) has air traffic control responsibility.
Air traffic                The aggregation of the airborne functions and ground-based
management                 functions (air traffic services, airspace management and air traffic
                           flow management) required to ensure the safe and efficient
                           movement of aircraft during all phases of operations. (ICAO PANS-
                           ATM)
Air traffic                A system that provides ATM through the collaborative integration
management system.         of humans, information, technology, facilities and services,
                           supported by air, ground and/or space-based communications,
                           navigation and surveillance.
Availability (inherent)    Probability that the equipment comprising the system is operational
                           and conforms to specifications, excluding planned outages and
                           logistics delays.
Availability of use        Availability of use is the probability that the communication system
(AU)                       between the two parties is in service when it is needed (DO-264).
                           The time a system is not available while repairs are underway
                           (logistics delay, MTTR, etc.) reduces availability of use.
Availability of            Availability of provision is the probability that communication with
provision (AP)             all aircraft in the area is in service (DO-264).
Call Establishment         The total time taken between the PTT action by the User and the
Delay                      time for the squelch to operate in the receiver (of the party being
                           called). (EUROCAE WG67-1)
Continuity                 Probability that a transaction will be completed having meet
                           specified performance (assuming the system was available when the
                           transaction is initiated). The value for the continuity parameter is
                           based on the acceptable probability of detected anomalous
                           behaviours of the communication transaction. Detected anomalous
                           behaviours include, but are not limited to (ICAO RCP Manual Draft
                           v4):
                                • Late transactions;
                                • Lost messages or transactions that cannot be recovered
                                    within the expiration time
                                • Duplicate messages or transactions that are forwarded and/or
                                    used; and
                                • Uncorrected detected message errors.
Integrity (IUCT)           Integrity is the acceptable rate of transactions that are completed
                           with an undetected error (DO-264). Undetected errors include, but
                           are not limited to (ICAO RCP Manual Draft v4):
                                • Undetected corruption of one or more messages within the
                                    transaction;
                                • Undetected misdirection of one or more messages within the
                                    transaction;
                                • Undetected delivery of message in an order that was not
                                    intended;
                                • Undetected delivery of a message after the communication


                                            158
                               COCR Version 2.0


                               transaction time; and
                          • Undetected loss of service or interruption in a
                               communication transaction.
Primary Means of      Primary Means: In today's environment, the normal means of
Communication         communicating is via voice. Established standards acknowledge
                      this distinction in that data communications remain as an alternate or
                      supplemental means of communicating. Alternate means of
                      communications are neither required, nor are they used as a means
                      of certification by U.S. authorities. In the future, this relationship
                      will be reversed as the performance of data communications
                      required for normal operations will be improved to such an extent
                      that it will be deemed the only means for some services.
OAT and GAT Traffic   In many parts of Europe where a division of labour is used, the
                      military Controller is collocated with the Controllers in charge of
                      civil traffic-they may be in the same room, sitting right next to each
                      other. In other locations, the military Controller works out of a
                      facility that is physically separate from where his civil counterparts
                      work. In either case, the military and civil Controllers work behind
                      the scenes with each other to de-conflict the two types of traffic.

                      OAT and GAT

                      This division of labour is the root of the OAT and GAT "systems"
                      which are found in parts of Europe. Simply put, the GAT system is
                      designed to accommodate civil IFR traffic or military IFR traffic
                      that chooses to abide by the procedures established for civil IFR
                      traffic. This GAT system is managed by a network of civil
                      Controllers while the OAT system is designed to accommodate
                      military traffic only and is managed by a network of military
                      Controllers using discrete frequencies.

                      It is important to emphasize that suitably equipped military aircraft
                      are given the option of filing as either OAT or GAT, but civil
                      aircraft are not allowed this same option as they are required to file
                      as GAT.
PIAC                  Peak instantaneous aircraft count, the highest number of aircraft in a
                      selected volume during the selected window of time
Push to Talk (PTT)    The physical action taken by the ‘User’ in operating his/her
                      transmitter key. The general term ‘User’ refers to a pilot or
                      Controller. The term ‘key’ is used to denote any type of device
                      including buttons, levers, foot switches, computer mouse and
                      LCD/plasma panel segments, etc. (EUROCAE WG67-1)
PTT Delay             This is the delay arising from the need to operate a transmitter
                      remotely and would be nil if the User was actually physically
                      located in the same place as the transmitter. (EUROCAE WG67-1)
Receiver Activation   The total time taken for a receiver to have recognised the presence
Delay                 of a radio signal of designed minimum quality causing the squelch
                      to operate. (EUROCAE WG67-1)
Reliability           See Availability (inherent)
Service Instance      A set of one or more messages and/or transactions associated with


                                       159
                                  COCR Version 2.0


                       completing a objective. For example, a Flight Crew request
                       followed by a Controller clearance followed by a Flight Crew
                       acknowledgement would constitute a single service instance that
                       contains three messages and two transactions.
Technical delay, one   Time required by the system to deliver a message, beginning with
way                    user action to send the message, and ending upon notification of
                       recipient of message receipt. Typically accounts for half of a
                       transaction.
Technical delay, two   Time required by the system to deliver a message, beginning with
way                    user action to send the message, and ending upon notification by
                       initiating user of reply receipt, excluding any user response time.
                       Typically, that part of TT(95) allocated to system.
Transaction            A two-way operational communication process (e.g., Controller and
                       pilot, pilot and pilot, or Controller and Controller. It contains the
                       outgoing request message, the Controller or pilot response time and
                       the incoming response message. Communications exchanges that
                       have multiple responses, i.e., the STANDBY, followed by the
                       operational response, are treated as two transactions. (DO-264)
Transaction Time (TT) The transaction time is the time needed by a pilot and a Controller to
                       exchange a pair of messages. This time represents the sum of the
                       delivery time of incoming and outgoing messages and the Controller
                       or pilot response time. (DO-264, Annex C.3.1.5.1)
Transmitter Activation The total time taken between the PTT action by the User and the
Delay.                 time that the transmitter has attained its designed operating power
                       (EUROCAE WG67-1)
95% Transaction Time The time before which 95% of the transactions are completed. (DO-
(TT95)                 264)
TT(95)RCTP             95% of transactions are completed with a technical delay, two way
                       with this time
TT(95)RCTP, one way 95% of transactions are completed with a technical delay, one way
                       within this time
Voice Access Delay     The one-way user-to-user delay starting with the voice initiation
                       event (e.g., PTT signal event) and ending with audio appearing at
                       the remote end of the link, but excluding any human response times.
Voice Channel Setup    Time needed for by the system to establish a path between users,
Delay                  prerequisite for voice access and communications.
Voice Latency          The one-way user-to-user voice delay between analogue system
                       interfaces (HMIs) after the audio path has already been established.
User                   A person who employs the services provided by the system.
                       Typically a member of the aircraft cockpit crew, a member of the air
                       traffic management team or flight operations personnel.




                                         160
                                  COCR Version 2.0


Appendix E            FRS LATENCY ALLOCATION
The COCR FRS technical latency allocation is intended to include the SNDCF
processing latency, the radio processing latency (both air and ground), the RF-based
transmission latency (this is the latency associated with the channel RF-bit transmission
rate), and any RF-based media access delays. It is important to note that the FRS
boundary has been chosen to be the SNDCF interface (a logical, stack-based boundary)
rather than a physical interface. The FRS technical latency is allocated from the overall
system RCTP transaction time, TT95-RCTP.

E.1 Latency Allocation Methodology
The steps below describe the methodology for allocating the latency requirements to the
FRS.

   1. Start with the TTRCP requirement.
   2. Allocate the TTRCP between the technical and human elements using an algebraic
      allocation, i.e., TT95-RCP = TT95-RCTP + TT95-HUMAN.
   3. Allocate the two-way TT95-RCTP into two one-way pieces, TD95-RCTP using the
      statistical allocation method described in Section 3.2 assuming that each one-way
      piece contributes equally to the two-way delay. Alternatively, an algebraic
      allocation could be made at this step.
   4. Assuming estimated allocation percentages, statistically allocate the one-way
      delay among the ATSU, CSP, FRS, and External Airborne systems. Note: This
      step does not directly use the ground and airborne allocations of from prior work,
      since the FRS spans both the ground and airborne domains.
   5. Evaluate the resultant statistically allocated figures for practically and
      reasonableness using a best effort attempt to equally distribute the difficulty in
      meeting the allocation. For example, it might be very difficult for FRS to met
      delays given the high likelihood of RF interference (a problem that the ATSU,
      CSP, and External Airborne equipment does not need to deal with). As another
      example, the processing requirements in the ATSU might be much greater (to
      authenticate security certificates) than the processing requirements in the FRS.
      The idea is to make a best effort at balancing the allocations such that a
      subsystem is not unfairly burdened.
   6. As needed return to Step 3 above until a reasonable set of allocations is
      produced.
It is practical to develop the allocation percentages using the service with the most
stringent TTRCP requirement. The reasonableness test can then be applied for worst
cast conditions. The resulting allocations can be applied to services with larger (less
stringent) TTRCP requirements with the assumption that the allocations will also be
reasonable.

E.2 Statistical Allocation
A Poisson distribution is assumed for transaction times. Poisson distributions are
commonly used to model message delays in queuing delay analyses. The allocation




                                          161
                                    COCR Version 2.0

among system components is done using mean (average) delay values. The steps below
describe the statistical allocation process:

   1. Calculate the mean delay time using the 95% time and assuming a Poisson
      distribution.
       Note: A Poisson distribution calculator is available at:
       http://calculators.stat.ucla.edu/cdf/poisson/poissoncalc.php
   2. Allocate the mean using the desired allocation percentages. If a component is
      allocated 10% of the mean, the component allocation is 0.1 times the system
      mean.
   3. Calculate the 95% delay time for each of the components using the component
      mean delay value and assuming a Poisson distribution.
For example, assume a total 95% system delay of 10 seconds wherein the system
consists of 3 components to be allocated 10%, 30% and 60% of the delay. First, you
would obtain the mean system delay. Using the Poisson calculator (see link above), the
system mean delay is 6.17 seconds. The mean delay allocations to the three components
are 0.61, 1.85, and 4.31 seconds, respectively. Note: Values are truncated rather than
rounded. Using the Poisson calculator and these mean values, the 95% delay values are
1.5, 3.8 and 7.4 seconds. Note: The sum of these three numbers are greater than 10
seconds, but the statistical allocation accounts for the fact that these three 95% delays do
not happen at the same time. The system 95% delay is still 10 seconds.

E.3 Allocation Guidance
In reality, the allocation to the FRS should be based on what can reasonably be achieved.
Annex E of DO-264 [43] provides guidance on allocation states:

      Consideration should be given as to the reasonableness and practicability of the
      considerations and assumptions (be they procedural, functional, performance,
      environmental, etc.). In particular, is the human component being unduly relied
      upon? A reasonableness check could be to relate the intended system architecture
      with the existing architecture, for example data-link replacing voice
      communication path to ensure that the safety objectives of the new technology are
      not significantly different from the existing technology, given similar mitigation
      and similar hazard category.
To that end, it is useful to review a number of prior assessments and associated
assumptions, limitations, and notes. Some of these assessments were presented in
Section 2.0 of this document and some of the information is newly introduced below.
       Recent VHF Digital Link (VDL)-2 simulation studies conducted to evaluate
       European capacity requirements have assumed a VDL-2 round trip delay of 8
       seconds, i.e., TTVDL2 = 8 seconds [46]. This represents a 50% algebraic
       allocation to the VDL-2 subnet. Note that this study has assumed a limited set of
       COCR-defined operational services and looked primarily at an En Route
       deployment of VDL-2.
       A MITRE study [50] evaluated VDL-3 delays and estimated 95% uplink and
       downlink one-way delays of 0.8 and 5 seconds, respectively. This delay data
       assumes 18 aircraft and a defined Terminal Domain Message Traffic Model.


                                            162
                                  COCR Version 2.0


       Note: The traffic load in this model was significantly higher than that used in
       [46].
       The system specification for the U.S. National Build 1.2 for Controller-Pilot Data
       Link Communication (CPDLC) requires an automation 95% delay time of 5
       seconds (delay between Controller initiation and providing the message to the
       FAA Telecommunication Infrastructure, FTI, ground network).
These examples are technology specific; thus, should only be used to consider (not
drive) FRS allocations.

E.4 FRS Latency Allocation
We start with step 3 in the proposed approach (see Section 3.1) given that the
operational subject matter experts have already developed TD95 performance numbers
for the end-to-end data communications. For Phase 1, the most stringent requirement is
for ACL/ACM, so will start the allocation process with a TD95 = 8. Using the Poisson
calculator, the mean one-way delay time (TDMEAN) is 4.695 seconds.

For the FRS, we will allocate this mean figure to the ATSU (e.g., automation), the CSP
(e.g., network), the FRS, and the external aircraft (XAIR) equipment (e.g., FMS). The
initial allocation percentage numbers for each component is 25%, 25%, 40% and 10%.
These percentages are based on the following rationale:
       The FRS has the most restrictive transmission rate. Traditionally, the bit rates on
       the RF links are significantly less than that of the ground network. In addition,
       the RF link is subject to interference and is much more error prone than ground
       links, which will likely require the FRS system to retransmit many more
       messages than other components. Some reports have indicated that the present
       ACARS system looses on average 6% of the transmissions. Thus the FRS
       allocation is large in comparison to other components. The 40% allocation is
       similar to the 50% allocation assumed in [46]. A slightly smaller allocation is
       assigned, since the future end systems will likely require additional processing
       (security certificate processing). In addition, a smaller allocation adds a degree
       of conservatism.
       The DO-290 algebraic allocation to the airborne domain resulted in TD95-AIR of
       2 seconds. From Boeing [49], the external equipment (other than VDR and
       CMU), the delay was estimated as 0.5 seconds. This represents about 6% of the
       system delay. Given that the FRS boundary is within the CMU, the assumed
       initial allocation will be a bit larger to account for CMU processing. Thus, the
       initial allocation of 10%.
       The remaining delay is allocated equally between the ATSU and the CSP, i.e.,
       25% each.
Using these component allocations and a system mean delay of 4.695 seconds, the mean
delays for the ATSU, CSP, FRS and XAIR are 1.17375, 1.17375, 1.878, and 0.4695
seconds respectively. Using the Poisson calculator and truncating to the nearest tenth of
a second, the associated 95% delays are 2.6, 2.6, 3.8, and 1.2 seconds respectively.
These allocations seem reasonable.




                                          163
                                 COCR Version 2.0

While it might be desirable to increase the FRS allocation, it would need to be at the
expense of the other allocations. The ATSU delay is already about 50% faster than
previously specified performance requirements for data communications automation,
i.e., 2.6 seconds versus 5.0 seconds.




                                         164
                                    COCR Version 2.0


     Appendix F         REFERENCE LIST
 Ref #             Document Title                        Author  Doc Ref             Date
1      ICAO Global ATM Operational Concept        ICAO         Doc 9750
                                                               AN/963
2     Safety and Performance Requirements         RTCA/EUROCAE RTCA DO-
      Standard for Air Traffic Data Link Services              290/
      in Continental Airspace                                  EUROCAE
                                                               ED-120
3     Operational Requirements for Air/Ground EUROCONTROL AGC ORD-01
      Co-operative Air Traffic Services
4     Roadmap for the Implementation of Data      European
      Link Services in European Air Traffic       Commission
      Management (ATM: Non ATS
      Applications)
5     Minimum Aviation System performance         RTCA                 DO-242A
      Standards for Automatic Dependent
      Surveillance – Broadcast
6     Next Generation Air Transportation System   U.S. Department of               December
      Integrated Plan (NGATS)                     Transportation                   2004
7     National Airspace System Concept of         RTCA
      Operations and Vision for the Future of
      Aviation
8     EUROCONTROL ATM Operating Concept           EUROCONTROL
      Volume 1, Concept of Operations, Year
      2011
9     ATM Implementation Roadmap – Short and      IATA                             15
      Medium Term – Release Version 1.0                                            October
                                                                                   2004
10    EUROCONTROL Air/ground data volumes         EUROCONTROL                      July 2000
      in Europe - version 0.B
11    Security Analysis Supporting the            EUROCONTROL/                     September
      Communications Operating Concept and        FAA                              2005.
      Requirements for the Future Radio System
12    EUROCONTROL/FAA Principles of               EUROCONTROL/                     19 June
      Operation for the Use of Airborne           FAA                              2001
      Separation Assurance Systems Version: 7.1
13    Guidelines for Approval of the Provision    RTCA/EUROCAE RTCA DO-
      and Use of Air Traffic Services Supported                264/
      by Data Communication                                    EUROCAE
                                                               ED-78A
14    FAA Safety Management System (SMS)          FAA          ASD-100-
      Manual                                                   SSE-1
15    EUROCONTROL Safety Regulatory               EUROCONTROL
      Requirement (ESARR 4) Set 1 Severity
      Indicators
16    COCR working paper AOC Transactions per K De Vito                COCR-PSG-
      Flight Domain                                                    KD-09


                                           165
                                    COCR Version 2.0


 Ref #                Document Title                      Author         Doc Ref    Date
17     “Dallas/Fort Worth International Airport    Buondonno, K. and DOT/FAA/CT July 2003
       Perimeter Taxiway Demonstration”            Price, K           -TN03/19
18     “Los Angeles International Airport Runway NASA Ames            FFC-LAX- May 9,
       Incursion Studies, Phase I Baseline         Research Center    R001       2001
       Simulation”
19     FCS Operational Concept and Requirements K De Vito                        March
       Group: A Voice Study Survey                                               2005
       Characterizing Voice Channel Access by
       Airspace Domain
20     Project EMERTA WP2-NGSS Study               Project EMERTA                March
       Synthesis Report                                                          2001
21     PSG FRS Latency Allocation Proposal         Performance Sub
                                                   Group (PSG)
22     PSG Node Analysis - Nodes and               PSG
       Operational Service Connectivity
23     PSG Large Airspace Volume Loading           PSG
       Proposal
24     PSG Queuing and Loading Assumptions         PSG
25     PSG ATN Stack Message Traffic Estimate PSG
       (Network Layer)
26     Voice Channel Impacts due to ASAS           K De Vito                     March
       Application Usage                                                         2005
27     Next Generation Satellite Communication P Platt                           October
       System - Mission Requirements                                             2003
28     One Sky Global ATM V1 2005+ - A             IATA
       strategy for Future ATM
29     Time Required for Transmission of Time - Kim M Cardosi
       Critical ATC Messages in an En Route
       Environment
30     Communications Concepts - For FCOCR         FAA                           July 2005
       Meeting July 26th 2005
31     Operational Concepts of Required            ICAO
       Communication Performance
32     ATN Project ATN Implementation Task         EUROCONTROL DED6/ATN/A July 1998
       Force DRAFT ATN Scenario Definition                            TNI-
                                                                      TF/DOC/25
33     Modelling the Other Half of the Flow        S. Bradford, M.
                                                   Rodgers, W.
                                                   Colligan
34     “Benefits of Controller-Pilot Data Link ATC Data Link Benefits DOT/FAA/CT September
       Communications in Terminal Airspace”        Study Team,        -96/3,     1996
35     “Etude Vocalise”                            L Gragila          CENA/ICS/R July 2002
                                                                      02-002
36     "MITRE-Sponsored Research: An Analysis Hung, B                            April 2005
       of En Route Domain Air Traffic Control
       Voice Transcripts"
37     AOC Message Volumes v0.2                    PSG


                                           166
                                     COCR Version 2.0


 Ref #             Document Title                         Author         Doc Ref       Date
38     PSG FIS Message Sizes v0.2                   PSG
39     FRS Loading Associated with Security         FAA                              August
                                                                                     2005
40     ATS Message Sizes (UNICAST) v0.2             PSG
41     Centre Sectors                               Harry Eberlin
42     NAS VHF Spectrum Survey Results                                               20
                                                                                     September
                                                                                     2005
43     Next Generation Air/Ground              RTCA                    DO 284
       Communications System (NEXCOM)
       Safety and Performance Requirements
       (SPR)
43a    Next Generation Air/Ground              RTCA                    DO 284 -
       Communications System (NEXCOM)                                  Change 1
       Safety and Performance Requirements
       (SPR) - Change 1
44     ICAO Annex 10 - Vol 3                   ICAO
45     Terminal Radar Approach Control:        Prinzo &                DOT/FAA/A October
       Measures of Voice Communications System McClellan               M-05/19   2005
       Performance
46     EUROCONTROL VDLM2 Capacity Study EUROCONTROL
47     ICAO PANS-OPS                           ICAO                    Doc 4444
48     ICAO Annex 11                           ICAO
49     Boeing Aircraft Delays                  Boeing
50     “A Simulation Study of the VDL Mode 3   Brian T. Hung,                        14-16
       Poll Scheduling Algorithm and Site      MITRE/CAASD                           October
       Diversity”, 22nd DASC, Indianapolis, IN                                       2003
51     COTRAC Operational Safety Assessment EUROCONTROL                              8 March
       Report                                                                        2006
52     Baseline S&M OSA Worksheet                                      050726B
53     Draft VoIP ATM System Operational and EUROCAE WG67                            14
       Technical Requirements                                                        February
                                                                                     2007
54     Concept of Operations for the Next           Joint Planning and DRAFT 5       February
       Generation Air Transportation System         Development        Version 1.2   28, 2007
                                                    Office (JPDO)
55     Safety and Performance Standard for Air      RTCA/EUROCAE DO-nnn              April 25,
       Traffic Data Link Services in Oceanic and                       (PU-24)       2007
       Remote Airspace (Oceanic SPR Standard)
56     Safety, Performance & Interoperability    RTCA                  DO-303        December
       Requirements Document for the ADS-B                                           13, 2006
       Non-Radar-Airspace (NRA) Application
57     Minimum Aviation System Performance       RTCA                  DO-289        December
       Standards (MASPS) for Aircraft                                  Change 1      13, 2006
       Surveillance Applications (ASA), Change 1



                                              167
                                   COCR Version 2.0


Appendix G RELATIONSHIP OF THE RESULTS TO A
  REAL WORLD ENVIRONMENT
G.1 Introduction
The requirements of the FRS have been derived in the above sections independently
from any specific technology or geographic location. Whilst this does not constrain the
choice of technology, Appendix G provides realistic examples of how the generic
requirements can be used in a practical way. The examples are not meant to be
prescriptive, but just indicate how the results could be applied to estimate PIACs
accounting for sector growth from Phase 1 to 2; to estimate PIACs for airspace volumes
corresponding to the service volumes associated with particular technologies and to
generally assess the application to modern, networked communications which might be
devoid of geographic constraints. For example, one variation of this approach, not
covered, could employ PIAC distributions derived from volumes associated with
existing En Route sectors to allow assessment of large area volumes typically associated
with satellite-based communications.

Two practical applications of the approach are documented in this chapter.
       Example One addresses application of the COCR in the ECAC
       Example Two addresses application to the U.S. NAS
Other approaches can be adopted drawing on the raw data which were used to feed the
queuing model used in the loading calculations as discussed in Section 6.

G.2 Aircraft Density Calculation
In order to provide for consistency in results which could be applied anywhere in ICAO,
a standard density measure was defined. Since it is expected that service volumes will
still apply, even in the Phase 2 timeframe, the density was defined as:

Aircraft Density in Service Volume = Service Volume PIAC/Service Volume in nm3

G.3 Example One (ECAC SV Density Calculations)
EUROCONTROL developed and operates a set of tools in order to assess quantitative
information in support of development at Europe’s airports, on air routes and the
airspace system. One such tool is System for Traffic Assignment and Analysis at a
Macroscopic Level (SAAM). SAAM is an integrated system for wide or local design
evaluation, analysis, and presentation of Air Traffic Airspace/TMA scenarios. Details of
the SAAM tool are given in Appendix A.

G.3.1 Modelling ECAC Airports, Terminal Areas and En Route Airspace
In reviewing the SAAM results a range of PIACs were noted for the service volumes
used in the model. It was identified that the sectors were of different volume and
therefore the number alone did not give an indication of traffic density. Consequently the
number of aircraft per unit volume was derived to compare air traffic densities.

The volume of the SAAM service volumes was calculated using the lat-long co-
ordinates and height based on spherical geometry mathematics.


                                           168
                                   COCR Version 2.0


G.3.2 ECAC Traffic Density Process and Results

G.3.2.1 Typical Application in a ECAC TMA
The results shown in Table 6-8 apply to a typical busy TMA sector, in this case a
London TMA sector (EGTTWEL) around 2020. The sector starts around 5000 ft up to
FL200. The size and shape of the sector changes with altitude. The results are therefore
representative of information flowing through that test volume sector in the timeframe.

Although the study is technology independent, to illustrate how the results may be
applied to assessing technology, the following figures have been produced. In practice a
typical line-of-sight (LOS) communication system will have a designated operational
coverage volume much larger than a sector. Typically at 5000 ft the theoretical radio
horizon would be 87 NM and 194 NM at FL200 (assuming ground antenna at 0 ft).

G.3.3 ECAC Super Sector Density Calculation
The density number of the EGTTWEL test sector can be used to estimate the PIAC for
the volume corresponding to several TMA sectors. The real PIAC for EGTTWEL and
two adjacent sectors was calculated using SAAM and compared with the approach of
applying the density number of EGTTWEL to the volume of the 3 sectors. It was found
that the resulting PIAC numbers are similar, as long as the density numbers are used for
the same type of sector (high density TMA, low density TMA, high density En Route,
low density En Route).

The results obtained for the test sector need to be applied to a different airspace volume
dependant on the technology considered.

G.4 Example Two (U.S. NAS En Route SV Density Calculation)
The NAS example was limited in that only En Route modelling was available.
Therefore NAS results shown are strictly for the En Route domain.

G.4.1 Modelling NAS En Route
The results for the NAS were derived from an analysis of all existing En Route control
sectors using 2004 FAA benchmark demand as applied within the Mid Level Model
(MLM). The traffic was grown across NAS En Route sectors using existing Terminal
Area Forecast (TAF) based demand scenarios. U.S. modellers performed runs of
existing MLM scenarios for 2004, 2013, 2020 and then used regression analysis to
obtain a 2030 PIAC distribution. The distributions developed are found to be similar to
those for the ECAC calculation and for consistency the values shown in

G.4.2 NAS Traffic Density Process and Results
A similar process to that outlined above for the ECAC was used to achieve aircraft
density. The En Route HD sectors for Phase 1 and 2 were identified by picking the
sector with the highest PIAC distributions associated with Figure G-1. Atlanta Centre
En Route arrival sector 19 had the highest PIAC in 2020, and was therefore chosen as
the Phase 1 HD sector. Using an FAA tool, the spatial co-ordinates and lower and upper
altitude floors of HD sector 19 were obtained. From this information, the volume and



                                           169
                                    COCR Version 2.0

density of Sector 19 was calculated based on spherical geometry mathematics as in the
ECAC calculation. Results are contained in Table G-1.

            Sector Name             PIAC   Volume (nm3)      Aircraft per nm3
            En Route HD (ZTL 019)     41         7300            0.0056

                Table G-1: Phase 1 NAS En Route Sector Density Calculation

G.4.3 NAS Super Sector Density Calculation
Sectors typical of 2030 operations are expected to be on the order of three times larger
than current sectors. Since PIACs are not necessarily proportional to volume, separate
PIACs for these ‘Super Sectors’ were developed. Table G-2 and underlying data
showed a maximum sector PIAC of 52 aircraft in 2030 in the Atlanta Centre sector
ZTL019. This was identified as the NAS En Route HD sector for Phase 2. Adjacent
sectors to the En Route HD sector were chosen from those closest horizontally and
vertically. The result was ZTL 016 and 020. These three sectors are actual En Route
arrival sectors feeding the Atlanta Hartsfield Airport. Aggregating these three sectors
resulted in an approximation of a sector three times the size of today’s sectors. The
PIACs in 2030 for these sectors are shown in Table G-2. The following formulas were
used to aggregate the three sectors.

ZTL 016 PIAC + ZTL 19 PIAC + ZTL 20 PIAC = HD Super Sector PIAC

ZTL016 volume + ZTL019 volume + ZTL020 volume = HD Super Sector Volume

Using these formulas, an aggregate PIAC of 95 and Volume of 31,996 nm3 was obtained
for a 2030 HD Super Sector.

        Sector Name            PIAC           Volume (nm³)       Aircraft per nm³
        En Route (ZTL 16)      22             9816               0.0022
        En Route HD (ZTL 19)   52             7300               0.0071
        En Route (ZTL 20)      21             14880              0.0014
        Super Sector           95             31996              0.0029

             Table G-2: Phase 2 NAS En Route Super Sector Density Calculation

G.4.4 Mapping the NAS En Route Super Sector
The selected HD Super Sector is highlighted on a map of NAS En Route sectors in
Figure G-1, and Figures G-2 and G-3 show additional detail on the three sectors
aggregated to represent the 2030 HD Super Sector.




                                           170
                 COCR Version 2.0




          Figure G-1: NAS En Route Sectors



                           ZTL
                          FL200

                                                                                        ZTL460
                                                                                           1
                                                                   ZTL450
                                                                      1                   ZTL470        ZTL290
                                             ZTL410                            ZTL440        1             1
                                                1                                 1
                                                                                                 ZTL470 300
                                                                                                    2 ZTL
                                                ZTL380            ZTL490                                  1
                                  ZTL050           1                 1           ZTL310
                                     1                                              1
                                                                  ZTL160
                     ZTL120                    ZTL380 380
                                                   ZTL               1
                        1                  ZTL040 2 040
                                                 ZTL 3
                              ZTL040
                                 1            2ZTL210 210
                                                    3
                                                    ZTL
                                                  2    3                    ZTL240
                ZTL140                                                         1
                   1                                              ZTL190
                                  ZTL090                 ZTL210      1
                                     1                      1

                 ZTL130
                    1

                                                                            ZTL            016/019




Figure G-2: NAS 2005 En Route Sectors ZTL 016 and 019




                                   171
            COCR Version 2.0


                ZTL FL240



                                                                                  ZTL430
                                                                                     1

                                                                                           ZTL330
                                                      ZTL390                                  1
                                         ZTL370          1
                                            1                   ZTL500
                                ZTL060                             1
                                   1                                     ZTL320
                                                                            1

                                             ZTL030   ZTL320
                       ZTL030                   2        2
                          1
                                                                   ZTL 200
                                                       ZTL220          1
                                                          1
                                   ZTL100
              ZTL110                  1
                 1



                                                                                  ZTL 020




Figure G-3: NAS 2005 En Route Sector ZTL 020




                                172
                   Data Comm Market Survey
                       Industry Meetings
                          Fact Sheet
                             March 26, 2008

-              s
    The FAA’intent is to open an on-going dialogue w/ industry on innovative
    business models to provide the Data Comm service. We expect this process to
    be iterative, so multiple meetings with individual companies are anticipated.
    The initial session will be structured, but informal follow-on sessions may be
    scheduled to pursue items of mutual interest which surface during the initial
    session.

-   The FAA will host one-on-one meetings with individual companies; we
    recommend a limit of 6 company attendees for the initial discussion. The
    FAA will be represented by the Program Manager, Contracting Officer,
    Acquisition Lead, and business and technical advisors.

-   The company will submit a meeting request along with a draft agenda
    covering the items in the RFI and other topics of interest. The FAA will
    provide a revised agenda along with confirmation of the meeting date.

-   The FAA will allocate 4 hours for the initial meeting. The meeting will begin
    with a presentation session of up to 2 hours; the FAA will provide a brief
    overview and response to company questions from the agenda. The company
    will present their viewpoint on the questions in the RFI, and other information
    which they want to share with the FAA. Company presentations should be
    limited to 90 minutes. The presentations will be followed by a break for
    Government caucus, and conclude with open discussion.

-   We intend to make available weekly meeting times (for example, Tuesday
    afternoons and Thursday mornings) which will be available on a first-
    come/first-serve basis. We will advise interested parties of these meeting
    times as soon as they are available; initial meetings will occur in April and
    currently anticipate completion of the open discussion period by June.

-   In most instances, initial meetings will be at FAA headquarters; subsequent
                                                   s
    meetings may be elsewhere (e.g. a company’facility) if logistical concerns
    make it more suitable.

-   As noted above, we anticipate that there will be a formal exchange covering
    the agenda topics (presentations, supplemented as necessary by backup
    information), followed by a break and informal discussion.

								
To top