Edward Hall and James Isaacs

ITT Corporation Electronic Systems, Fort Wayne, Indiana 

Natalie Zelkin and Steve Henriksen

ITT Corporation Information Systems, Herndon, Virginia 

C-Band Airport Surface Communications 

System Standards Development

Phase I Final Report

NASA/CR—2010-216324

December 2010

SAA3–978–1
NASA STI Program . . . in Profi le

Since its founding, NASA has been dedicated to the 

advancement of aeronautics and space science. The 

NASA Scientifi c and Technical Information (STI) 

program plays a key part in helping NASA maintain 

this important role.

The NASA STI Program operates under the auspices 

of the Agency Chief Information Offi cer. It collects, 

organizes, provides for archiving, and disseminates 

NASA’s STI. The NASA STI program provides access 

to the NASA Aeronautics and Space Database and 

its public interface, the NASA Technical Reports 

Server, thus providing one of the largest collections 

of aeronautical and space science STI in the world. 

Results are published in both non-NASA channels 

and by NASA in the NASA STI Report Series, which 

includes the following report types:

• TECHNICAL PUBLICATION. Reports of 

completed research or a major signifi cant phase 

of research that present the results of NASA 

programs and include extensive data or theoretical 

analysis. Includes compilations of signifi cant 

scientifi c and technical data and information 

deemed to be of continuing reference value. 

NASA counterpart of peer-reviewed formal 

professional papers but has less stringent 

limitations on manuscript length and extent of 

graphic presentations.

• TECHNICAL MEMORANDUM. Scientifi c 

and technical fi ndings that are preliminary or 

of specialized interest, e.g., quick release 

reports, working papers, and bibliographies that 

contain minimal annotation. Does not contain 

extensive analysis.

• CONTRACTOR REPORT. Scientifi c and 

technical fi ndings by NASA-sponsored 

contractors and grantees.

• CONFERENCE PUBLICATION. Collected 

papers from scientifi c and technical 

conferences, symposia, seminars, or other 

meetings sponsored or cosponsored by NASA.

• SPECIAL PUBLICATION. Scientifi c, 

technical, or historical information from 

NASA programs, projects, and missions, often 

concerned with subjects having substantial 

public interest.

• TECHNICAL TRANSLATION. Englishlanguage translations of foreign scientifi c and 

technical material pertinent to NASA’s mission.

Specialized services also include creating custom 

thesauri, building customized databases, organizing 

and publishing research results.

For more information about the NASA STI 

program, see the following:

• Access the NASA STI program home page at 

http://www.sti.nasa.gov

• E-mail your question via the Internet to help@

sti.nasa.gov

• Fax your question to the NASA STI Help Desk 

at 443–757–5803

• Telephone the NASA STI Help Desk at

 443–757–5802

• Write to:

 NASA Center for AeroSpace Information (CASI)

 7115 Standard Drive

 Hanover, MD 21076–1320
Edward Hall and James Isaacs

ITT Corporation Electronic Systems, Fort Wayne, Indiana 

Natalie Zelkin and Steve Henriksen

ITT Corporation Information Systems, Herndon, Virginia 

C-Band Airport Surface Communications 

System Standards Development

Phase I Final Report

NASA/CR—2010-216324

December 2010

SAA3–978–1

National Aeronautics and

Space Administration

Glenn Research Center

Cleveland, Ohio 44135

Prepared under Contract NNC05CA85C
Available from

NASA Center for Aerospace Information

7115 Standard Drive

Hanover, MD 21076–1320

National Technical Information Service

5301 Shawnee Road

Alexandria, VA 22312

Trade names and trademarks are used in this report for identifi cation 

only. Their usage does not constitute an offi cial endorsement, 

either expressed or implied, by the National Aeronautics and 

Space Administration.

Level of Review: This material has been technically reviewed by expert reviewer(s).

This report contains preliminary fi ndings, 

subject to revision as analysis proceeds.
NASA/CR—2010-216324 iii

Preface

 

1

With a possible future extension into the 5000- to 5030-MHz band, pending a decision at the World 

Radiocommunications Conference in 2012.

This National Aeronautics and Space Administration (NASA) Contractor Report summarizes and 

documents the work performed to develop system standards for the proposed C-band (5091- to 

5150-MHz1

) airport surface communications system. This report documents the work done in Phase I. It 

was delivered to NASA on December 19, 2009, under the fiscal year 2009 project-level agreement.

This work was completed under the NASA Aerospace Communication Systems Technical Support 

(ACSTS) contract, based on direction provided by the Federal Aviation Administration project-level 

agreement (PLA FY09_G1M.02-02v1) for “New ATM Requirements—Future Communications” as a 

follow-on to the FAA/EUROCONTROL (European Organisation for the Safety of Air Navigation)

Cooperative Research Agreement (Action Plan 17 (AP−17)), commonly referred to as the Future 

Communications Study. 

NASA/CR—2010-216324 v

Executive Summary

ES.1 Introduction 

This report is being provided as part of the NASA Glenn Research Center Aerospace Communication 

Systems Technical Support (ACSTS) Contract (NNC05CA85C), Task 7: “New ATM Requirements—

Future Communications, C-Band and L-Band Communications Standard Development.” 

Task 7 is separated into two distinct subtasks—each aligned with specific work elements and 

deliverable items identified in the Federal Aviation Administration’s (FAA) project-level agreement 

(PLA) and with the FAA fiscal year 2009 New ATM Requirements—Future Communications Project and 

spending plan for these subtasks. 

The purposes of subtask 7−1, and the subjects of this report, are the definitions of the concepts of use 

(ConUse), high-level system requirements, and architecture; the performance of supporting system 

analyses; the development of test and demonstration plans; and the establishment of operational capability 

in support of C-band aeronautical data communications standards to be advanced in both international 

(International Civil Aviation Organization, ICAO) and national (RTCA) forums. 

The future C-band (5091 to 5150 MHz1

) airport surface communication system is referred to as the 

Aeronautical Mobile Airport Communications System (AeroMACS).

Assumptions and constraints for this report follow:

• The 5091- to 5150-MHz spectrum allocation for AeroMACS use at the World 

Radiocommunications Conference (WRC−2007) is provisioned only for use on the airport 

surface. This allocation is within the aeronautical mobile (route) service (AM(R)S) band. 

Therefore, AeroMACS applications are constrained to mobile applications on the airport surface. 

This is interpreted to include communications for nonmobile (i.e., fixed) applications provisioned 

within a mobile AeroMACS network that support the safety and regularity of flight.

• The proposed AeroMACS is assumed to provide an increase in overall air-to-ground (A/G) 

communications systems capacity by utilizing the new spectrum (i.e., in addition to existing very 

high frequency, VHF).

• The scope of this ConUse and requirements report includes airport surface A/G air traffic control 

(ATC) communications and ground-to-ground (G/G) communications.

• AeroMACS will be designed specifically for data communication. 

• This report assumes that the data communications system developed as part of the FAA Data 

Communications Program (Data Comm) will precede an AeroMACS implementation and 

deployment. 

• Although some critical services could be supported, AeroMACS systems will also target 

noncritical services, such as weather advisory and aeronautical information services implemented 

as part of an airborne System Wide Information Management (SWIM) program. 

• AeroMACS is to be designed and implemented in a manner that will not disrupt other existing 

services operating in the C-band. Additional interference research and testing will determine if 

any operational constraints are to be imposed, such as limiting the number of users, the time of 

the day, the duration, and so on.

ES.2 ConUse

A process recommended in the “National Airspace System: System Engineering Manual” (SEM, 

Ref. 1) was adopted as a guide in developing ConUse and requirements for the proposed system. 

Figure ES–1 summarizes the steps.
NASA/CR—2010-216324 vi

Figure ES–1.—ConUse development process. Acronyms are defined in Appendix A.

ES.2.1 Identify Operational Needs for a New System 

Operational needs for a new system are supported by describing the current system and its associated 

problems and capability shortfalls. “System Requirements Document, Next Generation Air/Ground 

Communications (NEXCOM)” provides a good description of the FAA’s current analog A/G voice 

communications system used for ATC (Ref. 2). 

The Next Generation Air Transportation System (NextGen) concept of operations (ConOps) 

summarizes the current attributes (and associated constraints) of the voice-based A/G communications 

system as follows (Ref. 3):

• Limited data communications for air traffic management (ATM) and operational control

• Limited access to real-time weather and aeronautical data

• Voice communications routine for ATM

• Analog voice

• Analog weather information display systems

• A/G and G/G communications

• Loss of communications due to beyond line-of-sight (BLOS) aircraft position (e.g., over the 

ocean)

• Individual ground systems for each information type brought to the flight deck

• Point-to-point aircraft communications based on ATC sectors

There are several principal shortcomings of the current A/G voice communications system, including 

lack of automation, limited or no data communications availability, aging infrastructure, technology 

limitations, and spectrum saturation. The resulting operational problems, if not addressed, could lead to 

service degradation and limit the introduction of new or expanded services. These, in turn, could 

potentially compromise safety of operation and increase operating costs. Saturation of spectrum is the 

problem specifically mitigated by the introduction of a new C-band system (AeroMACS); the other 

operational problems would also be mitigated with AeroMACS. 

Current G/G communications on the airport surface are conducted predominantly over a combination 

of wire and optical fiber cabling and a limited number of point-to-point line-of-site radio links. 

The limitations imposed by the current G/G communications infrastructure could result in restrictions 

in the deployment of new ATM services, resulting in the following service limitations (Ref. 4).

Identify Operational 

Need for a New 

System

• Describe Current 

A/G 

Communication 

System

• Describe Current 

airport surface 

G/G 

Communications 

Systems

• Current System 

Operational 

Environments

• Current Systems 

Scope and 

Capability 

Shortfalls

Provide Proposed 

System Justification

• Potential 

Benefits of New 

Systems

• Operational 

Shortfalls 

Addressed by 

Data Comm

Program

• Description of 

Desired Change

• Change Priorities 

and Road Maps

• Assumptions and 

Constraints

Define Proposed 

System

• Objectives and 

Scope

• Proposed 

System in 

context of NAS 

EA Operational 

View

• System 

Description

• Operational 

Environment

• Frequency and 

Technology – Environment, 

Requirements 

and Limitations

• Users

• Operational 

Policies and 

Constraints

Define ConUse

• Use of the 

Proposed 

System for 

Airport

• Data Link 

Messages 

Examples

• Operational 

Scenarios 
NASA/CR—2010-216324 vii

• Limited ATM (e.g., traffic) information on the flight deck

Limited data shared among stakeholders for collaborative decision making (CDM) processes 

• Information sharing in support of operational security performed manually instead of 

electronically 

• Not all stakeholders able to access data they need 

• Stakeholders unable to use custom data sources

ES.2.2 Provide Proposed System Justification

Rather than being a National Airspace System (NAS) service itself, G/G and A/G communications 

are enablers of NAS services. It is important to note that the FAA’s “Final Program Requirements for 

Data Communications” (Ref. 5) recognizes that “the scope of the mission shortfalls identified herein [is] 

broader than will be addressed solely by a data communications capability.” Because of the limitations 

and constraints of implementing data communications using very high frequency digital link (VDL) 

Mode 2 over a congested aeronautical VHF band, the FAA’s Data Comm Program will focus principally 

on implementing the most critical air traffic services (ATS). This will provide opportunities for 

AeroMACS systems to augment data communications on the airport surface by enabling communications 

of less critical and essential ATSs to address the shortfalls listed. Even though each of the shortfalls listed 

above are meant to be addressed to some extent by Data Comm using VDL Mode 2, there are 

opportunities to overcome these shortfalls to an even greater extent during the later program segments of 

Data Comm (e.g., late Segment 2 and Segment 3) using link technologies such as AeroMACS with 

greater bandwidth capabilities, which could augment the benefits already attained through the earlier 

VDL Mode 2 Data Comm segment implementations (i.e., Segments 1 and 2) by providing a broader 

scope of services. 

ES.2.3 Define Proposed System and ConUse

Some FAA objectives defined in the FAA’s NextGen portfolio are based on the requirement to 

support future air traffic growth. AeroMACS will be designed and developed to help meet those 

objectives in part by expanding the data communications capacity in the airport surface domain. Global 

harmonization is being ensured by developing the proposed AeroMACS component of the FRS as a 

collaborative effort of the U.S. and European partners.

As recommended by the Future Communications Study (FCS) technology assessment, the proposed 

airport surface communications system (i.e., AeroMACS) is based on the Institute of Electrical and 

Electronics Engineering (IEEE) 802.16 standard and its extension, IEEE 802.16e-2005 (Ref. 6), and will 

be implemented in the aeronautical C-band (5091 to 5150 MHz). A new standards profile for airport 

applications is currently being developed within an RTCA special committee (SC–223) to operate in the 

C-band and make use of the scaling properties inherent in the IEEE 802.16e standard.

2

The proposed AeroMACS could provide supplemental means to the ATC communications required 

by the operating rules (e.g., VHF voice communications) in continental airspace (albeit on the airport 

surface) and will adhere to the data link characteristics noted in the “Safety and Performance 

Requirements Standard for Air Traffic Data Link Services in Continental Airspace (Continental SPR 

Standard)” (Ref. 7). 

This report focuses on the ATS and advisory data services that are defined in the communications 

operating concept and requirements (COCR) and are not expected to be provided by Data Comm through 

Segment 2. The following list shows the proposed candidates for AeroMACS:

• Flight information services

o Data link operational terminal information service (D−OTIS) 

 2

Specifically, IEEE 802.16-2009 will provide the basis of ongoing profile selection.
NASA/CR—2010-216324 viii

o Data link surface information and guidance (D−SIG) 

o Flight plan consistency (FLIPCY) 

o System access parameters

o Pilot preferences downlink (PPD)

• Weather advisory service

o Data link significant meteorological information (D−SIGMET)

• Emergency information service

o Urgent contact (URCO)—if in conjunction with other more routine services

Additional data services that may be provided via AeroMACS may be identified as NextGen and 

Single European Sky ATM Research (SESAR) progress. In addition, an AeroMACS could provide the 

means for A/G data transfer on the airport surface to support the FAA SWIM program.

Table ES–1 lists the operational scenarios and concepts envisioned for the midterm NextGen airport 

surface flight phase. Although most, if not all, of these concepts are currently envisioned for Data Comm, 

they are technology independent and, thus, equally valid for an AeroMACS implementation.

TABLE ES–1.—NEXT GENERATION AIR TRANSPORTATION SYSTEM (NextGen) 

MIDTERM OPERATIONAL CONCEPTS FOR THE AIRPORT SURFACE PHASE

Phase of flight NextGen midterm communications operational concept (from Ref. 8)

Flight planning Access to flight planning information will be available to authorized users via a secure network 

and will include a publish/subscribe capability so that users can receive automatic updates when 

conditions change along the proposed flight path.

Push back, taxi, and 

departure

As the time for the flight approaches, the final flight path agreement will be delivered as a data 

message to pilots who access the agreement before beginning the flight.

Table ES–2 illustrates the potential operational use of the proposed AeroMACS based on the COCR 

services previously identified as potential applications (Ref. 9).

TABLE ES–2.—USE OF THE PROPOSED AeroMACS IN THE AIRPORT FLIGHT DOMAIN

[Acronyms are defined in Appendix A.]

Operational services Airport domain phases

Predeparture airport 

domain

Departure taxi airport 

domain

Arrival airport 

domain

Arrival taxi 

airport domain

Flight information services D–OTIS

D–RVR

D–SIG

D–SIGMET

D–OTIS

D–RVR

D–SIG

D–SIGMET

D–OTIS

D–RVR

D–SIG

D–RVR

D–SIG

Flight position, flight intent, and 

flight preferences services

PPD

FLIPCY

WAKE

PPD

FLIPCY

WAKE

PPD

FLIPCY

WAKE

PPD

FLIPCY

WAKE

Emergency information service URCO URCO URCO URCO

Services suitable for Airborne 

SWIM (generally weather 

advisory and aeronautical 

information services)

Aviation Digital Data Service (ADDS), AWOS Data Acquisition Service (ADAS), 

Expanded Terminal and Tower Data Service, General Information Message Distribution 

Service, Information Display System (IDS) Data Service, NextGen Network Enabled 

Weather (NNEW) service,a NOTAM distribution service, TMA Flight Data Service, 

WARP/WINS NEXRAD service a

It is possible that the information provided through the NNEW service could range from advisories for routine forecasts 

though safety-critical transmission of certain hazardous weather warning messages, which might limit the extent to which this 

service could be provided over commercial links. This requires further investigation.
NASA/CR—2010-216324 ix

ES.3 AeroMACS System Requirements

A middle-out approach was adopted to identify the high-level requirements applicable to AeroMACS. 

In this approach, the top-down functional requirements were derived from the ConUse and the associated 

functional capabilities. In parallel with that process, a bottom-up assessment of existing requirements in 

relevant documents such as the NAS SR−1000 (Refs. 10 and 11), the COCR (Ref. 12), and Data Comm 

performance requirements and their applicability to the current needs for AeroMACS was performed. 

AeroMACS could provide a communication link to transfer surveillance and weather information, 

facilitate flight and resource management, enhance CDM, and enable the exchange of aeronautical 

information in the future NAS. The tables in Appendix B document the select RTCA NAS ConOps 

(Ref. 13) found applicable to the proposed AeroMACS.

3

The desired AeroMACS functional capabilities have been derived from the identified NAS ConOps 

presented in Appendix B and mapped to (1) high-level aeronautical A/G and G/G communication 

functions and (2) specific COCR ATS services. Table ES–3 lists the AeroMACS high-level functional 

capabilities and presents this mapping. This encompasses a top-down approach to the development of 

functional requirements.

TABLE ES–3.—MAPPING AeroMACS FUNCTIONALITY TO THE NATIONAL AIRSPACE

SYSTEM (NAS) CONCEPTS OF OPERATION (ConOps)

[Acronyms are defined in Appendix A.]

Desired AeroMACS 

capabilities

NAS ConOps references (Ref. 13) Functional 

hierarchy reference

Communications 

operating concept and 

requirements (COCR) 

air traffic services 

(ATS) 

Enable air-to-ground 

(A/G) and ground-toground (G/G) 

communications for 

fixed-to-mobile as well as 

fixed-to-fixed services.

S-1; S-3; S-4;

W-2; W-3; W-8; W-9; W-10; W-12; W-13; 

W-14; W-15;

FM-1; FM-6; FM-8; FM-12; FM-14; FM-15; 

FM 17; FM-23;

A-2; A-6; A-12; A-15

C.1.1.1.2

C.1.1.2.2

C.1.1.4.1

D–OTIS

D–RVR

D–SIG

D–SIGMET

FLIPCY

WAKE

PPD

Support addressed 

communication for 

delivery of information to 

individual and multiple 

users

S-1;

W-10;

FM-6; FM-8

C.1.1.1.2

C.1.1.2.2

C.1.1.4.1

D–OTIS

D–RVR

D–SIG

D–SIGMET

FLIPCY

PPD

Support broadcast 

communication for 

delivery of information to 

multiple users

S-1; S-4;

W-2; W-3; W-12; W-14;

FM-8;

A-12

C.1.1.1.2

C.1.1.2.2

C.1.1.4.1

D–OTIS

D–RVR

D–SIG

D–SIGMET

WAKE

Support delivery of realtime information in a 

timely manner

S-1; S-3;

W-16;

FM-1; FM-2; FM-9; FM-10; FM-12; FM-15; 

FM-18; FM-25; FM-26;

RM-3; RM-7;

A-4; A-7; A-11

D-RVR

D-SIG

D–SIGMET

FLIPCY

WAKE 

PPD

 3

Although the RTCA document describes the NAS evolution in terms of three time periods—near (up to 2005), mid 

(2005 through 2010), and far (beyond 2010)—most concepts identified in the document are found applicable for the 

proposed AeroMACS, which will necessarily be implemented beyond 2010.
NASA/CR—2010-216324 x

TABLE ES–3.—MAPPING AeroMACS FUNCTIONALITY TO THE NATIONAL AIRSPACE

SYSTEM (NAS) CONCEPTS OF OPERATION (ConOps)

[Acronyms are defined in Appendix A.]

Desired AeroMACS 

capabilities

NAS ConOps references (Ref. 13) Functional 

hierarchy reference

Communications 

operating concept and 

requirements (COCR) 

air traffic services 

(ATS) 

Enable demand, periodic, 

and event communication

S-1;

W-12

All services 

Accommodate a wide 

range of data types (e.g.,

surveillance reports, 

weather raw data and 

products, flight profiles, 

etc.) to support common 

situational awareness

S-3;

W-2; W-3;

A-1; A-5

All services

Support multiple qualityof-service (QoS) 

provisions

All services

Support authentication of 

users and controlled 

access to NAS 

information (security)

W-1 All services

Provide support of both

Federal Aviation 

Administration (FAA) 

and non-FAA ground 

users

S-1;

FM-12; FM-14; FM-20;

A-11

Avoid single points of 

failure

RM-6 All services

Provide a scalable 

solution

All services

Provide standards-based 

solution

All services

High-level AeroMACS functional requirements were then constructed from the functional 

capabilities as shown in Table ES–4.

TABLE ES–4.—AeroMACS HIGH-LEVEL FUNCTIONAL REQUIREMENTS

System functions AeroMACS high-level functional requirements

Enable air-to-ground (A/G) and ground-toground (G/G) communications for fixed-tomobile as well as fixed-to-fixed services.

The system shall enable ground-to-air (G/A) communication for fixed-tomobile users.

The system shall enable G/A communication for mobile-to-mobile users.

The system shall enable A/G communication for fixed-to-mobile users.

The system shall enable A/G communication for mobile-to-mobile users.

Support addressed communication for delivery 

of information to individual and multiple 

users.

The system shall support addressed communications to individual users.

The system shall support addressed communications to multiple users.

Support broadcast communication for delivery 

of information to multiple users.

The system shall support broadcast communication to multiple users.
NASA/CR—2010-216324 xi

TABLE ES–4.—AeroMACS HIGH-LEVEL FUNCTIONAL REQUIREMENTS

System functions AeroMACS high-level functional requirements

Support delivery of real-time information in a 

timely manner.

The system shall support delivery of real-time information in a timely manner.

Enable demand, periodic, and event 

communication.

The system shall enable demand communication.

The system shall enable periodic communication.

The system shall enable event communication.

Accommodate a wide range of data types (e.g., 

surveillance reports, weather raw data and 

products, flight profiles, etc.) to support 

common situational awareness.

The system shall accommodate a wide range of data types (e.g., surveillance 

reports, weather raw data and products, flight profiles, etc.) to support common 

situational awareness.

Support multiple QoS provisions. This functional capability points toward performance requirements.

Support authentication of users and controlled 

access to National Airspace System (NAS) 

information (security).

The system shall support authentication of users (security).

The system shall support controlled access to NAS information (security).

Provide support of both Federal Aviation 

Administration (FAA) and non-FAA ground 

users.a

The system shall support FAA ground users.

The system shall support non-FAA ground users.

Avoid single points of failure. The system shall avoid single points of failure.

Provide a scalable solution. The system shall provide a scalable solution.

Provide a standards-based solution. The system shall provide standards-based solution. a

To support increasing collaboration among NAS users, the proposed system shall accommodate a wide range of NAS users by 

accepting NAS data from NAS data sources, both internal and external to the FAA. Users may include aircraft, airline operation 

centers, service providers, FAA users, and other Government agencies. 

Although the top-down approach employs the classic “clean-sheet” system engineering process, the 

bottom-up approach addresses how the AeroMACS fits into the existing environment. 

Functions identified in the NAS SR−1000 document—plan flights, monitor flights, control traffic, 

support flight operations, monitor NAS operations, and plan NAS usage—cut across all the AeroMACS 

capabilities shown in Table ES–4.

The functional requirements applicable for an AeroMACS operating on the airport surface (shown in 

Table ES–5) were extracted from the NAS requirements specified in the NAS SR−1000. Unless 

specifically stated otherwise, these could apply to A/G or G/G communications, for fixed-to-mobile or 

fixed-to-fixed applications.

TABLE ES–5.—NATIONAL AIRSPACE SYSTEM (NAS) FUNCTIONS

NAS functions Communication requirementsa

Plan flights Evaluate flight 

conditions 

The NAS shall disseminate the status of special use airspace to users. (08760)

The NAS shall disseminate weather information to users to support flight planning.

(27150)

The NAS shall disseminate aeronautical information to users to support flight planning. 

(27160)

Manage flight plans The NAS shall disseminate flight information to users. (00010)

The NAS shall disseminate flight plan information to users via external data 

interfaces.(00410)

The NAS shall disseminate flight plan information to users via air-ground data 

communications. (00970)

The NAS shall disseminate flight data summaries to users. (00070)

The NAS shall disseminate flight plans to users. (02160)

The NAS shall disseminate flight plan clearances to users. (02900)
NASA/CR—2010-216324 xii

TABLE ES–5.—NATIONAL AIRSPACE SYSTEM (NAS) FUNCTIONS

NAS functions Communication requirementsa

Monitor 

flights

Collect aircraft 

navigation information 

(collect dependent 

surveillance 

information)

The NAS shall retrieve actual flight information. (10000)

The NAS shall acquire actual flight information from aircraft outside of independent 

surveillance coverage. (03320)

Monitor aircraft status The NAS shall respond to emergency transmission received via radio communications. 

(12600) 

The NAS shall respond to emergency transmissions received via data link. (12620)

The NAS shall disseminate essential information on missing aircraft. (13130)

Report (disseminate) 

aircraft status

The NAS shall display position information, to specialists, for aircraft that were detected 

independent of aircraft equipage in qualifying aerodromes. (24530)

The NAS shall transmit conflict-free flight path recommendations to expedite resolution 

of emergency situations. (12820)

The NAS shall disseminate aircraft flight information for each controlled aircraft to 

specialists. (02720)

The NAS shall disseminate the current location for each participating aircraft to ATCSCC 

[air traffic control system command center] Specialists. (10940)

The NAS shall disseminate the current location for each participating aircraft to Traffic 

Management Coordinators. (10980)

Control 

traffic

Address active aircraft 

conflicts

The NAS shall disseminate recommended collision avoidance maneuvers to users. 

(03690)

Control aircraft The NAS shall disseminate aeronautical information to users via air-ground data 

communications. (07440)

Coordinate traffic 

control distribution

The NAS shall acquire pilot reports (PIREP). (05530)

The NAS shall disseminate weather advisories via direct specialist to pilot 

communications. (09290)
NASA/CR—2010-216324 xiii

TABLE ES–5.—NATIONAL AIRSPACE SYSTEM (NAS) FUNCTIONS

NAS functions Communication requirementsa

Support flight 

operations

Manage weather 

information

The NAS shall maintain communication links adequate to avoid user delay in gaining 

access. (07090)

The NAS shall disseminate weather information to users continuously. (07110)

The NAS shall disseminate current weather effect along the users proposed flight 

path.(07470)

The NAS shall disseminate forecast weather in effect along the users proposed flight path. 

(07480)

The NAS shall disseminate intensity levels of weather by route of flight to users. (08260)

The NAS shall disseminate intensity levels of weather by geographic area to users. 

(08300)

The NAS shall disseminate weather advisories to users in response to a request. (09300)

The NAS shall broadcast the latest approved aerodrome conditions on communications 

media accessible by aircraft on the ground. (09340)

The NAS shall broadcast the latest approved terminal area conditions on communications 

media accessible by aircraft on the ground. (09360)

The NAS shall respond to user requests for weather information from NAS facilities 

through common carrier communications networks. (09370)

The NAS shall disseminate selected weather information directly to appropriately 

equipped aircraft. (09420)

The NAS shall provide flexible and convenient access to required weather information to 

users. (19380)

Operate navigation 

aidsb

The NAS shall disseminate navigational accuracy correction values for supplemental 

navigation systems to users. (17040)

The NAS shall disseminate correction values for navigational aids to users. (16790)

The NAS shall disseminate available supplemental terminal navigation guidance 

information error correction values to users. (14820)
NASA/CR—2010-216324 xiv

TABLE ES–5.—NATIONAL AIRSPACE SYSTEM (NAS) FUNCTIONS

NAS functions Communication requirementsa

Monitor NAS 

operations

Monitor NAS flight 

operations

The NAS shall disseminate future delay advisories in effect along the users proposed 

flight path. (07500)

The NAS shall disseminate traffic advisories upon user request. (09120)

The NAS shall provide traffic advisories to aircraft on the surface. (30270)

Maintain NAS 

infrastructure

The NAS shall disseminate airway usage information to users. (00030)

The NAS shall disseminate route usage information to users. (00050)

The NAS shall disseminate aeronautical information to users via external data interfaces. 

(07430)

The NAS shall disseminate aeronautical information per user request. (07130)

The NAS shall disseminate aeronautical information upon user request continuously. 

(07340)

The NAS shall disseminate aeronautical data for a maximum of 8 specified locations per 

request. (07400)

The NAS shall disseminate the status of supplemental navigation systems to users. 

(17010)

The NAS shall disseminate status of supplemental navigation systems to users. (16770)

The NAS shall disseminate flow control information to users via external data interfaces. 

(07920)

The NAS shall disseminate derived restrictions to the user. (11700)

The NAS shall disseminate alternate courses of action relative to flight restrictions to 

users. (11790)

The NAS shall disseminate terrain information compliant with terrain, ground and 

obstacle information accuracy requirements, to users upon request. (03900)

The NAS shall disseminate manmade obstacle information compliant with terrain, ground 

and obstacle information accuracy requirements, to users upon request. (03940)

The NAS shall disseminate ground information compliant with terrain, ground and 

obstacle information accuracy requirements, to users upon request. (25520)

The NAS shall disseminate filtered terrain information to users. (25560)

The NAS shall disseminate filtered ground information to users. (25570)

The NAS shall disseminate filtered manmade obstacle information to users. (25580)

Plan NAS 

usage

Plan traffic flow The NAS shall disseminate preferred route information at least 24 hours prior to it 

becoming effective. (07280)

The NAS shall disseminate military air traffic control plans related to national 

emergencies. (16140)

The NAS shall disseminate flow control information to users via external data interfaces. 

(07920)

The NAS shall disseminate interfacility traffic flow plans. (11970)

The NAS shall disseminate derived restrictions to the user. (11700)

The NAS shall disseminate derived alternative courses of action to the user. (11720)

The NAS shall determine flight restrictions for specific aircraft. (11760)

The NAS shall disseminate flight restrictions to users. (11770)

The NAS shall disseminate alternate courses of action relative to flight restrictions to 

users. (11790)

Assess traffic flow 

performance

The NAS shall disseminate reports on equipment performance. (18870)

The NAS shall disseminate reports on maintenance activities. (18880)

The NAS shall disseminate reports on equipment repair activities. (18890)

a

Numbers in the table correspond to communication requirements in the NAS SR–1000 (Ref. 10). b

These services are typically provided via satellite communication (SATCOM) but could be provided via a ground-based system.
NASA/CR—2010-216324 xv

Performance requirements were derived to define system capabilities based on the developed 

functional requirements and considering the propagation characteristic of the C-band. This report 

summarizes the NAS performance requirements found to be relevant to the proposed AeroMACS as

documented in the NAS SR−1000 (Ref. 10). Note that these are high-level NAS requirements that do not 

specify how they should be implemented.

Typically high-level requirements are technology independent. Perhaps unique to the development of 

the AeroMACS requirements is the identification a priori, by virtue of the extensive FCS technology 

assessment, of the recommended technology by which AeroMACS will be implemented, that is, 

IEEE 802.16e. This allows the identification and development of quite specific requirements depending 

on the desired application or service to be provided. The report provides a preliminary approach for 

identifying and developing AeroMACS requirements in the context of the IEEE 802.16e broadband 

communications standard, and its characteristics.

Although actual parameters will depend on the architecture of the communication network, the size of 

the network, and the provisions for redundant communication support, typical performance parameters for 

the physical and link layer requirements for individual communication services are presented in 

Table ES–6. 

TABLE ES–6.—COMMUNICATION SERVICE REQUIREMENTS

[Acronyms are defined in Appendix A.]

Communication

service

Example airport

application

Quality of service 

(QoS) class

Performance

parameters

Typical 

values

Supported

by IEEE 

802.16e

Low to medium 

speed point-to-point 

data link 

Backup for sensor cable 

link (i.e., weather 

sensor)

nrtPS Data rate

PER

Delay

Jitter

100 kbps

1.0×10–3

1 sec

100 μsec

Yes

High-speed pointto-point data link Backbone-linking base 

station (BS); link to 

relay gateway node in 

remote area

UGS Data rate

PER

Delay

Jitter

1 Mbps

1.0×10–3

100 msec

100 nsec

Yes

Point-to-multipoint 

broadcast data

Scheduled broadcast of 

weather info, NOTAM

nrtPS Data rate

PER

Delay

Jitter

200 kbps

1.0×10–3

1 sec

<1 μsec

Yes

Point-to-point 

command and 

control data

Remote operation of 

ADS–B ground station

rtPS Data rate

PER

Delay

Jitter

200 kbps

1.0×10–6

100 msec

<1 μsec

Yes

Command and 

control 

network

Operation of surface 

devices at remote airport 

Best effort Data rate

PER

Delay

Jitter

200 kbps

1.0×10–4

200 msec

<10 μsec

Yes

Digital voice 

network

Provide N circuits for 

ATC or AOC operations

rtPS;

ERT–VR service

Data rate

PER

Delay

Jitter

10 kbps × N

1.0×10–3

100 msec

<100 μsec

Yes

Point-to-point video 

link

Airport surveillance; 

robotic vehicle 

UGS Data rate

PER

Delay

Jitter

600 kbps

1.0×10–3

200 msec

<10 μsec

Yes
NASA/CR—2010-216324 xvi

TABLE ES–6.—COMMUNICATION SERVICE REQUIREMENTS

[Acronyms are defined in Appendix A.]

Communication

service

Example airport

application

Quality of service 

(QoS) class

Performance

parameters

Typical 

values

Supported

by IEEE 

802.16e

Basic mobile Handoff control for 

voice; low-speed data 

sessions

UGS Data rate

PER

Delay

Jitter

200 kbps

1.0×10–3

200 msec

<10 μsec

Yes

Multimedia CDM rtPS Data rate

PER

Delay

Jitter

1 Mbps 

1.0×10–3

100 msec

<10 μsec

Yes

ES.4 Architectural Description and Initial Test Bed Requirements

The initial AeroMACS system architecture is based on the IEEE 802.16e-2005 communications 

standard that was recently incorporated into the IEEE 802.16-2009 standard (Ref. 14). 

The primary mode for operation of an IEEE 802.16e-based system is a point-to-multipoint architecture. 

The standard is Internet Protocol (IP) based and provides secure connectivity between users and services. 

Figure ES–2 depicts a wireless point-to-multipoint system in an airport context. 

Figure ES–2.—Airport point-to-multipoint communications service. Acronyms are defined in 

Appendix A.

The system architecture framework can be applied at all airport locations. Deploying an AeroMACS 

architecture solution at a particular airport requires several tradeoffs to obtain the best performance, 

including the 

• Location and number of base stations (BSs)

• Number of antenna sectors to employ per BS

Wireless Cable

Asset Tracking

Data Services

ASR

RTR/RCAG

Vehicle

ADS-B

Station

ADS-B

Station

Security

ASR

VOR

LCGS

ATCT

Airport 

Intranet

Airport 

Intranet

Backbone

High speed link

ASN

ASN

BS

BS

Vehicle

MS

MS

MS

SS

SS

SS

SS

SS

SS

SS

SS : Subscriber Station

MS: Mobile Station

BS: Base Station 

ASN: Access Service Network

Wireless Cable

Asset Tracking

Data Services

ASR

RTR/RCAG

Vehicle

ADS-B

Station

ADS-B

Station

Security

ASR

VOR

LCGS

ATCT

Airport 

Intranet

Airport 

Intranet

Backbone

High speed link

ASN

ASN

BS

BS

Vehicle

MS

MS

MS

SS

SS

SS

SS

SS

SS

SS

Wireless Cable

Asset Tracking

Data Services

ASR

RTR/RCAG

Vehicle

ADS-B

Station

ADS-B

Station

Security

ASR

VOR

LCGS

ATCT

Airport 

Intranet

Airport 

Intranet

Backbone

High speed link

ASN

ASN

BS

BS

Vehicle

MS

MS

MS

SS

SS

SS

SS

SS

SS

SS

SS : Subscriber Station

MS: Mobile Station

BS: Base Station 

ASN: Access Service Network
NASA/CR—2010-216324 xvii

• Type of backhaul system to support the access service network (ASN)

• Number of subscriber station (SS) terminals that can be serviced by a BS

A design process, including a site survey, coverage model, spectrum analysis, and capacity analysis, 

provides a formal method of adapting the standard architecture to each airport. Components will vary by 

airport because of differences in size, layout, and applications.

Table ES–7 lists the parameters that must be included in design tradeoffs for an AeroMACS network.

TABLE ES–7.—AeroMACS NETWORK DESIGN TRADEOFFS

Design 

tradeoff 

category

Parameters Considerations and system tradeoff parameters

Base station 

(BS)

Mounting placement Total network data throughput

Line-of-sight/non-line-of-sight (LOS/NLOS) coverage area

Low-level blockage avoidance

Number of BS and base 

transceiver station (BTS) sectors

BS throughput

Channel bandwidth and available spectrum

Multiple input, multiple output 

(MIMO) order

BS cell-radius requirements

Transmitter (Tx) power

NLOS and blocked-path performance

Multipath mitigation

Mobility dropouts

Interference to out-of-band users will be decreased by MIMO because total 

radiated power can be reduced.

Antenna polarization Cross-polarized versus spatially separated antennas

Maximum cell range Number and placement of BSs

BTS sector and subscriber station (SS) Tx power

Controlled-pattern antennas Use beam steering and beam-shape adaptation to increase throughput and 

avoid interference. 

Frequency band 5091- to 5150-MHz aeronautical mobile (route) service (AM(R)S) band 

approved during the 2007 World Administrative Radio Conference (WARC 

2007).

Addition of 5000- to 5030-MHz band is under consideration.

Spectrum co-user interference 

(i.e., Globalstar satellite)

BTS sector antenna patterns control direction of radiation.

Use minimum BTS sector and SS Tx power to achieve required data 

throughput over coverage area.
NASA/CR—2010-216324 xviii

TABLE ES–7.—AeroMACS NETWORK DESIGN TRADEOFFS

Design 

tradeoff 

category

Parameters Considerations and system tradeoff parameters

SS Mounting height Avoid low-level structural and temporary blockages.

MIMO order Tx power

NLOS and blocked-path performance

Multipath mitigation

Mobility dropout avoidance

Antenna polarization Cross-polarized versus spatially separated antennas

Maximum cell range Tx power

NLOS and blocked-path performance

Multipath mitigation

Mobility dropouts

Frequency band Controlled and set by BTS sector connection

SS must have matching frequency capability.

Spectrum co-user interference 

(i.e., Globalstar satellite)

BTS sector antenna patterns control the direction of radiation.

Use minimum BTS sector and SS Tx power to achieve required data 

throughputs over coverage area.

Channel 

bandwidth

Throughput rate Highest throughput application sets the minimum channel bandwidth.

Mobility performance A wider bandwidth enables better channel equalization and better tracking of 

multipath variations during mobility.

Multipath performance Better equalization of short-path multipath with wider channel bandwidths

Efficient use of spectrum Number of channels that fit within the 59-MHz allocated AM(R)S spectrum

Co-interference There are fewer options for nonoverlapping frequency reuse in a large 

number of cells with wide channel bandwidths.

Hardware limitations 20-MHz channel bandwidth requires fast digital processing and may not be 

implemented by a particular hardware supplier.

Modulation Adaptive or fixed Fixed modulation requires the use of lowest order modulation and lowest data 

throughput; higher order modulation will cause dropouts during mobility.

Modulation rates Use of all specified options maximizes data throughput for fixed and mobile 

SSs.

Forward error correction (FEC) 

coding rate

Use of all specified options maximizes data throughput for fixed and mobile 

SSs.

BTS power 

class

Fade margin Fade margin allowance is set during network design to establish link 

reliability.

Co-interference Minimize Tx power to stay below the detection threshold of another BTS 

sector in a frequency reuse layout.

Spectrum co-user interference 

(i.e., Globalstar satellite feeder 

uplinks)

Minimize Tx power to reduce interference to co-users of the spectrum.

Range Tx power affects the signal-to-noise ratio and modulation rate at the outer 

edge of cell coverage.

LOS and NLOS operation Fade margin allowance increases for NLOS operation.

Mobile operation Fade margin allowance increases for NLOS operation.

Power amplifier power-output 

limitations

Orthogonal-frequency-division multiplexing (OFDM) modulation has a high 

peak-to-average ratio, making high Tx power expensive.
NASA/CR—2010-216324 xix

TABLE ES–7.—AeroMACS NETWORK DESIGN TRADEOFFS

Design 

tradeoff 

category

Parameters Considerations and system tradeoff parameters

SS power 

class

Fade margin Fade margin allowance is set during network design to maintain link 

reliability.

Co-interference Minimize Tx power to stay below the detection threshold of another BTS 

sector in a frequency reuse layout.

Spectrum co-user interference 

(i.e., Globalstar satellite uplinks)

Minimize Tx power to reduce interference to co-users of the spectrum.

Range Tx power affects signal-to-noise ratio and modulation rate from the outer 

edge of cell coverage.

LOS and NLOS operation Fade margin allowance increases for NLOS operation.

Mobile operation Fade margin allowance increases for mobile operation.

Power amplifier power-output 

limitations

OFDM modulation has a high peak-to-average ratio, making high power 

expensive.

Media 

Access 

Control 

(MAC) layer 

and physical 

layer

Maximum mobile speed 120 km/hr is a value derived from other specified parameters and provides 

guidance about achievable maximum speed.

The communications operating concept and requirement (COCR) is 160 kn 

(296 km/hr)

Institute of Electrical and Electronics Engineering (IEEE) 802.16 

specification does not directly support COCR 160-kn requirement. A 

cost/benefit analysis is needed to assess the benefits of achieving this speed.

Repeater operation

(IEEE 802.16j)

IEEE 802.16j is a potential future amendment to IEEE 802.16 standard

BS repeater functionality may provide fill-in coverage in shadow areas with 

minimal added radiation and interference.

Transmitter/receiver 

time-division duplex 

(TDD)/frequency-division 

duplex (FDD) mode

C-band AM(R)S spectrum allocation width does not support cost-effective 

FDD operation.

Quality of 

service 

(QoS)

Time delay Services such as voice, and command and control applications will require 

guarantees on maximum time delay allowed.

Time jitter Services that are sensitive to jitter are to be identified. The use of frame 

buffering should be considered for each sensitive application.

Message priority Safety and reliability requirements will help specify message priorities. 

Scheduling The scheduling algorithm will take message priority into account along with 

QoS requirements.

Message integrity Security and message integrity guarantees will depend on the type of QoS 

service flow selected. 
NASA/CR—2010-216324 xx

ES.5 Test Bed Performance Evaluation 

Developing an AeroMACS solution based on the IEEE 802.16e standard requires detailed analysis, 

simulation, and test measurements on actual airport surfaces. An AeroMACS test bed will aid in 

validating requirements and act as a prototype deployment. Such a communications, navigation, and 

surveillance (CNS) test bed has been installed and is running at NASA Glenn and the adjacent Cleveland 

Hopkins International Airport (CLE) in Cleveland, Ohio. This so-called NASA−CLE CNS Test Bed is 

designed to implement many of the AeroMACS features and requirements that support modern data 

communications at an operational airport to help verify the performance of AeroMACS and validate some 

of the ConUse. 

Figure ES–3 shows the placement of the AeroMACS network on Glenn property and the adjacent 

CLE airport surface.

Figure ES–3.—NASA–CLE CNS Test Bed base station, backhaul, and core server locations. Acronyms are defined 

in Appendix A.
NASA/CR—2010-216324 xxi

The test bed network uses two BSs, one on Glenn property (Building 4) and another on airport 

property on top of the Aircraft Rescue and Fire Fighting (ARFF) building. These BSs are linked to core 

servers located in Glenn Building 110 by microwave data backhaul radios operating outside of the 

AM(R)S spectrum. Fixed-location SSs are located at two positions on Glenn property (Buildings 4 and 

500) and six positions on airport property. Tests are planned that will include mobility with vehicle- and 

aircraft-mounted SSs.

Expected AeroMACS link performance for fixed-position SSs was analyzed using the Cellular Expert 

analysis program developed by HNIT−BALTICFOOT.4 Results are shown in Figure ES–4 on the basis of 

highest achievable modulation rate across the airport surface. Except for where links are physically 

shadowed by obstructions, the analysis predicts that the highest data throughput modulation rate 

supported by the IEEE 802.16e standard will be achieved across a significant majority of the 

airport surface.

Figure ES–4.—Received signal strength indication (RSSI) plot for 17-dBi directional subscriber station mounted at 

12 ft. Acronyms are defined in Appendix A.

 4

http://www.hnit-baltic.lt/. 
NASA/CR—2010-216324 xxii

The testing and evaluation of the IEEE 802.16e network can be grouped into two sets:

(1) Baseline performance tests within the project scope that will be reported in this document

(2) A set of tests designed to support development of an aviation profile and to evaluate the support 

of FAA applications

Eleven baseline performance network test cases have been defined to establish basic operating 

capability, including security with authentication and encryption, data throughput and channelization, 

quality-of-service (QoS) data prioritization, mobility, and reliability during extended operation.

Table ES–8 presents a collection of test cases designed to evaluate AeroMACS parameters in the 

airport environment. The “Design tradeoff category” column defines broad parameter categories, whereas 

the “Parameters” column lists detailed parameters within the category. The “Evaluation test” column 

describes test conditions for exploring the tradeoff space of a category. 

TABLE ES–8.—EXPERIMENTS AND TEST PLAN TRADEOFF SPACE

Design tradeoff 

category

Parameters Evaluation test

Base station (BS) Mounting placement Analyze or simulate

Verify analysis or simulation model

Survey signal strength across airport surface

Determine line of sight (LOS) and non line of sight (NLOS)

Number of BSs and base 

transceiver station (BTS) sectors

Analyze, considering coverage area and composite throughput

Multiple input, multiple output 

(MIMO) order

Test without MIMO

Test with up to 2×2 MIMO

Test with N×N MIMO

Test with LOS and NLOS or blockage

Antenna polarization Evaluate internal cross-polarization antennas versus external 

spatially separated antennas

Maximum cell range Extend with Media Access Control (MAC) changes within 

Institute of Electrical and Electronics Engineering (IEEE) 

802.16e specification

Evaluate IEEE 802.16m amendment

Controlled-pattern antennas Test with advanced BTS sector antennas

Identify and evaluate steerable multibeam antennas

Frequency band Analyze minimum spectrum versus needed throughput

Spectrum co-user interference 

(i.e., Globalstar satellite)

Analyze

Subscriber station 

(SS)

Mounting height Analyze 

MIMO order Test without MIMO

Test with up to 2×2 MIMO

Test with N×N MIMO

Antenna polarization Evaluate internal cross-polarization antennas versus two 

external single-polarization antennas

Maximum cell range Extend with MAC changes within IEEE 802.16e specification

Evaluate IEEE 802.16m amendment

Frequency band Analyze minimum spectrum versus needed throughput

Test frequency reuse methods including N = 1 (all sectors on 

same center frequency)

Spectrum co-user interference 

(i.e., Globalstar satellite)

Analyze on the basis of power class requirements and 

frequency reuse method
NASA/CR—2010-216324 xxiii

TABLE ES–8.—EXPERIMENTS AND TEST PLAN TRADEOFF SPACE

Design tradeoff 

category

Parameters Evaluation test

Channel bandwidth Throughput rate Test mixed mobile SS and fixed SS traffic including

• Sources of highest expected data rate

• Channel bandwidths of 5, 10, and 20 MHz

Mobility performance Test mobility throughput over speed range and cell radius 

including

• Multiple mobile SS

• Channel bandwidths of 5, 10, and 20 MHz

Multipath performance Evaluate performance in terminal area

Evaluate mobile performance in building areas

Efficient use of spectrum Evaluate multiple mobile SS operation concurrent with fixed 

SS of differing data streams

Hardware limitations Test throughput versus expected at 20-MHz bandwidth

Modulation Adaptive or fixed Measure mobility throughput measurements across cell radius 

with fixed high and low modulation rates

Modulation rates Compare measured versus expected throughput versus 

modulation coding rate, including

• Ranges from cell center to cell edge

• LOS and NLOS

Forward error correction (FEC) 

coding rate

Compare measured versus expected throughput versus error 

coding rate, including

• Ranges from cell center to cell edge

• LOS and NLOS

BTS power class Fade margin allowance Test long-term LOS throughput

Conduct mobility tests in NLOS and high-multipath conditions

Co-interference Test throughput versus power between isolated sectors at the 

same center frequency in a frequency-reuse system

Spectrum co-user interference 

(i.e., Globalstar satellite feeder 

uplinks)

Analyze interference on the basis of minimum power required 

to provide coverage across airport surface

Range Determine cell radius versus number of BSs

Power amplifier power-output 

limitations

Analyze

SS power class Fade margin allowance Test long-term LOS throughput

Conduct mobility tests in NLOS and high-multipath conditions

Spectrum co-user interference 

(i.e., Globalstar satellite uplinks)

Analyze interference on the basis of minimum power required 

to provide coverage across the airport surface

Range Determine cell radius versus the number of BSs

Power amplifier power-output 

limitations

Analyze

MAC layer and 

physical layer (PHY)

Maximum mobile speed Conduct high-speed mobility tests for throughput and dropouts

Repeater operation

(IEEE 802.16j)

Test IEEE-802.16j-enabled BS when available for filling in 

poor coverage areas, including

• Outside cell radius

• NLOS regions

Transmitter/receiver time-division 

duplex (TDD)/frequency-division 

duplex (FDD) mode

Analyze
NASA/CR—2010-216324 xxiv

TABLE ES–8.—EXPERIMENTS AND TEST PLAN TRADEOFF SPACE

Design tradeoff 

category

Parameters Evaluation test

Quality of service 

(QoS)

Time delay Measure end-to-end time delay through AeroMACS network 

from SS input through communication, navigation, and 

surveillance (CNS) output port for all five QoS levels

Time jitter Measure end-to-end time jitter through AeroMACS network 

from SS input through CNS output port for all five QoS levels

Message priority Test high QoS and best-effort traffic

Test until throughput overload

Verify that high QoS priority is maintained

Scheduling Test high QoS and best-effort traffic

Measure statistics of scheduling accuracy

Measure scheduling performance as throughput is increased to 

overload

Message integrity Test high QoS and best-effort traffic

Test continuous and burst traffic

Verify packet error rate and that there are no dropped packets 

for high QoS traffic

Initial network performance data were collected to assess the data throughput capacity of links 

between Glenn Building 500 and the two BS sectors located at Glenn Building 4. Test data streams were 

generated by Ixia Chariot5 software hosted on the single-board computers at each end of the link. The 

results shown in Table ES–9 are for the downlink (DL: BS to SS) and the uplink (UL: SS to BS) 

directions. The measured throughput exceeded the manufacturer’s estimated rates in all cases.

TABLE ES–9.—AeroMACS NASA–CLE TEST BED LINK TEST RESULTS

BTS sector Measured DL

throughput, 

Mbps

Expected DL

throughput, 

Mbps

Measured UL

throughput, 

Mbps

Expected UL

throughput, 

Mbps

BTS1_1 6.82 6.5 5.4 4.0

BTS1_2 6.54 6.5 4.19 4.0

ES.6 Specification Recommendations

NAS growth and improvement will provide continued safety, efficiency, and reliability to the flying 

public. The AeroMACS solution is designed to help increase airports’ capacity for departures and 

arrivals, as well as the safety and efficiency of surface movement, the security and flexibility of airport 

surface operations, and the situational awareness for airport surface users and stakeholders. AeroMACS 

will also help reduce delays, fuel consumption, and emissions. Finally, AeroMACS will be developed in 

cooperation with the European Organisation for the Safety of Air Navigation (EUROCONTROL) to 

advance the establishment of global standards and interoperability to effectively and efficiently enable 

rapid and thorough airport improvements as new applications augment and replace legacy systems.

Special committee SC–223 was established within the RTCA aviation industry consortium to 

establish standards for AeroMACS. The principal products of this special committee are a set of system 

profile recommendations to be delivered in September 2010 and a Minimum Operational Performance 

Standards (MOPS) document to be delivered in September 2011. EUROCONTROL established a similar 

 5

http://www.ixiacom.com. 
NASA/CR—2010-216324 xxv

work group, WG−82, that is chartered to develop an AeroMACS profile. SC–223 and WG−82 will work 

cooperatively to develop a common profile document that will be provided as recommendations for 

consideration by ICAO. 

Sets of system parameter profiles have been recommended for AeroMACS within this study. These 

profiles are based on the existing IEEE 802.16e standard. System profile parameter values were selected 

within the IEEE 802.16e standard to maximize the reuse of commercial off-the-shelf Worldwide 

Interoperability for Microwave Access (WiMAX) hardware and software. In addition, parameter options 

are included that give the system designer flexibility to accommodate the applications and environment 

that will be unique to each airport. Table ES–10 summarizes key parameter selections for the five profile 

areas that are defined in the IEEE 802.16e standard and that are recommended for an AeroMACS 

standard profile. The five profile areas listed in the table correspond to the five profile areas that 

distinguish mobile WiMAX profiles. A working group within RTCA SC–223 is tasked with further 

developing the AeroMACS profile and deciding whether parameters are mandatory or optional to 

implement.

TABLE ES–10.—SUMMARY OF FINAL RECOMMENDATIONS FOR AeroMACS PROFILE

Profile area Key parameter selections

Radiofrequency and radio parameters

Frequency band, MHz

Channel bandwidths, MHz

Channel center frequencies

5091 to 5150 

5, 10, and 20

See Table 38

Power class

Maximum downlink transmitter (Tx) power

Maximum uplink Tx power

6.3.4—Unchanged from IEEE 802.16(e)

6.3.4—Unchanged from IEEE 802.16(e)

Duplex mode—time-division duplex (TDD) 

or frequency-division duplex (FDD) TDD

Physical layer

M-ary quadrature amplitude modulation 

(QAM) range

Coding options

Multiple input, multiple output (MIMO)

Performance profiles—minimum performance defined in IEEE 802.16(e) and

Table 35 for 5-MHz channels

Table 36 for 10-MHz channels

Table 37 for 20-MHz channels

Media Access Control (MAC) layer

Automatic repeat request

Security protocols

Mobile protocols

Quality-of-service (QoS) options

Mesh options

All parameters unchanged from IEEE 802.16(e)

NASA/CR—2010-216324 xxvii

Contents

Preface .........................................................................................................................................................iii

Executive Summary ...................................................................................................................................... v

ES.1 Introduction................................................................................................................................. v

ES.2 ConUse........................................................................................................................................ v

ES.2.1 Identify Operational Needs for a New System............................................................. vi

ES.2.2 Provide Proposed System Justification ....................................................................... vii

ES.2.3 Define Proposed System and ConUse......................................................................... vii

ES.3 AeroMACS System Requirements ............................................................................................ix

ES.4 Architectural Description and Initial Test Bed Requirements.................................................xvi

ES.5 Test Bed Performance Evaluation............................................................................................. xx

ES.6 Specification Recommendations............................................................................................ xxiv

1.0 Introduction .......................................................................................................................................... 1

1.1 Background................................................................................................................................. 1

1.2 Systems Overview ...................................................................................................................... 2

1.3 Document Overview ................................................................................................................... 3

2.0 ConUse and Requirements Development Processes............................................................................ 4

3.0 ConUse ................................................................................................................................................. 8

3.1 ConUse Development Process.................................................................................................... 8

3.2 Operational Needs....................................................................................................................... 8

3.2.1 Current Airport Surface Communications Systems...................................................... 9

3.2.2 Current System Operational Environments................................................................. 12

3.2.3 Current System Users.................................................................................................. 17

3.2.4 Current System Scope and Capability Shortfalls........................................................ 17

3.3 New Airport Surface Communications Systems Justification .................................................. 20

3.3.1 Potential Benefits of New Airport Surface Communications Systems....................... 20

3.3.2 Operational Shortfalls Addressed by Data Comm...................................................... 22

3.3.3 Description of Desired Changes.................................................................................. 23

3.3.4 Change Priorities and Roadmaps................................................................................ 24

3.3.5 Assumptions and Constraints for AeroMACS............................................................ 25

3.4 Proposed AeroMACS Systems................................................................................................. 26

3.4.1 Objectives and Scope .................................................................................................. 26

3.4.2 Proposed System Description: AeroMACS ................................................................ 32

3.4.3 AeroMACS Frequency and Technology: Environment, Requirements, and 

Limitations.................................................................................................................. 32

3.4.4 User Impact................................................................................................................. 33

3.4.5 Operational Policies and Constraints.......................................................................... 34

3.5 AeroMACS ConUse ................................................................................................................. 34

3.5.1 RTCA National Airspace System Concepts of Operation Guidance .......................... 34

3.5.2 Data Comm Operational Scenarios............................................................................. 35

3.5.3 Proposed Services for AeroMACS ............................................................................. 36

3.5.4 Next Generation Air Transportation System Communications Operational Concepts39

3.5.5 AeroMACS Operational Services and Scenarios Derived from the Communications 

Operating Concept and Requirements ........................................................................ 40

4.0 AeroMACS System Requirements..................................................................................................... 43

4.1 AeroMACS Functional Requirements Development Process .................................................. 43

4.1.1 AeroMACS Functional System Requirements—Top-Down Approach ..................... 43

4.1.2 AeroMACS Functional System Requirements—Bottom-Up Approach..................... 47

4.2 AeroMACS Performance Requirements................................................................................... 51
NASA/CR—2010-216324 xxviii

4.2.1 National-Airspace-System-Level Performance Requirements Applicable to 

AeroMACS ................................................................................................................. 51

4.2.2 Communications Operating Concept and Requirements (COCR) Performance 

Requirements Applicable to AeroMACS.................................................................... 54

4.3 Other AeroMACS Requirements.............................................................................................. 54

4.3.1 Spectrum Requirements Applicable to AeroMACS ................................................... 54

4.3.2 User Requirements Applicable to AeroMACS ........................................................... 55

4.3.3 Regulatory Requirements Applicable to AeroMACS................................................. 56

4.3.4 Safety and Security Requirements Applicable to AeroMACS ................................... 56

4.4 Guidance for the Development of AeroMACS Requirements Based on IEEE 802.16e .......... 56

4.4.1 Introduction................................................................................................................. 56

4.4.2 Classes of Communications Services for AeroMACS................................................ 57

4.4.3 Developing AeroMACS Service Quality-of-Service Requirements Based on IEEE 

802.16e........................................................................................................................ 58

4.4.4 Quality of Service Support of AeroMACS Communication Services........................ 59

5.0 Architectural Description and Initial Test Bed Requirements............................................................ 61

5.1 Initial Surface Communications System Architecture.............................................................. 61

5.2 Overview................................................................................................................................... 61

5.3 IEEE 802.16 Network Architecture .......................................................................................... 62

5.4 Physical System Architecture and Design Process................................................................... 65

5.4.1 Introduction................................................................................................................. 65

5.4.2 Airport AeroMACS Network Design Process............................................................ 65

5.4.3 Coverage Model.......................................................................................................... 65

5.4.4 Spectrum Analysis ...................................................................................................... 66

5.4.5 Capacity Analysis ....................................................................................................... 66

5.5 Test Bed Architecture ............................................................................................................... 69

5.5.1 Test Bed Objectives.................................................................................................... 70

5.5.2 Test Bed Approach...................................................................................................... 70

6.0 Test Bed Performance Evaluation...................................................................................................... 71

6.1 Test Bed Implementation.......................................................................................................... 71

6.2 Simulation, Emulation, and Testing Results and Evaluation.................................................... 78

6.2.1 Network Simulation Evaluation Results..................................................................... 78

6.2.2 Network Test and Evaluation Results......................................................................... 83

6.2.3 Network Evaluation Test Plan .................................................................................... 95

6.2.4 Network Evaluation Test Results................................................................................ 99

6.3 Initial Input to Aeronautical Mobile Specific IEEE 802.16 Design Specification ................. 101

6.3.1 AeroMACS Standard Profile .................................................................................... 101

6.3.2 System Profile Definition Method ............................................................................ 102

6.3.3 System Profile Definitions........................................................................................ 102

6.3.4 AeroMACS Power Class Profiles............................................................................. 103

6.3.5 AeroMACS Media Access Control Profiles ............................................................. 103

6.3.6 AeroMACS System Physical Layer Profiles ............................................................ 104

6.3.7 Basic Physical Layer (PHY) Profile for the AeroMACS 5-MHz Channel............... 104

6.3.8 Basic Physical Layer (PHY) Profile for AeroMACS 10-MHz Channel................... 105

6.3.9 Basic Physical Layer (PHY) Profile for AeroMACS 20-MHz Channel................... 105

6.3.10 AeroMACS Radiofrequency Profiles ....................................................................... 106

7.0 Final Requirements and Specifications Recommendations for the C-Band System....................... 107

7.1 Final Performance Requirements Recommendations............................................................. 107

7.2 Final Input to Aviation-Specific IEEE 802.16 System Design Specifications....................... 109

Appendix A.—Acronyms and Abbreviations........................................................................................... 111
NASA/CR—2010-216324 xxix

Appendix B.—RTCA National Airspace System Concept of Operations Applicable to the 

Proposed Aeronautical Mobile Airport Communications System (AeroMACS) ............................ 123

Appendix C.—Hierarchical Diagrams of Functional Requirements ........................................................ 131

References................................................................................................................................................. 138

Bibliography ............................................................................................................................................. 141

List of Figures

Figure ES–1.—ConUse development process. Acronyms are defined in Appendix A...............................vi

Figure ES–2.—Airport point-to-multipoint communications service. Acronyms are defined in 

Appendix A. ...................................................................................................................................... xvi

Figure ES–3.—NASA–CLE CNS Test Bed base station, backhaul, and core server locations. 

Acronyms are defined in Appendix A................................................................................................ xx

Figure ES–4.—Received signal strength indication (RSSI) plot for 17-dBi directional subscriber 

station mounted at 12 ft. Acronyms are defined in Appendix A.......................................................xxi

Figure 1.—Communications systems covered by this ConUse document (slightly altered version 

of Figure 1−1 in Ref. 7)........................................................................................................................ 2

Figure 2.—National Airspace System (NAS) engineering concept document hierarchy (Ref. 19). 

Acronyms are defined in Appendix A.................................................................................................. 4

Figure 3.—Requirements management process flow (Ref. 25). Acronyms are defined in 

Appendix A. ......................................................................................................................................... 6

Figure 4.—AeroMACS ConUse and system requirements development flow chart. Acronyms are 

defined in Appendix A. ........................................................................................................................ 7

Figure 5.—ConUse development process. Acronyms are defined in Appendix A....................................... 8

Figure 6.—Current en route air-to-ground (A/G) communications system (Ref. 26). Acronyms are 

defined in Appendix A. ...................................................................................................................... 10

Figure 7.—Typical remote transmitter/receiver (RTR) site configuration (Ref. 27). ATCT, air 

traffic control tower............................................................................................................................ 11

Figure 8.—System View 2 (SV–2) command and control detailed air-to-ground communications 

view for 2009 to 2010 (Ref. 29). Acronyms are defined in Appendix A........................................... 13

Figure 9.—System view 2 (SV–2) 2009 to 2010 data flow views (Ref. 29). Acronyms are defined 

in Appendix A. ................................................................................................................................... 16

Figure 10.—Current National Airspace System air-to-ground communications operational 

problems. ............................................................................................................................................ 18

Figure 11.—Operational capabilities of Data Comm (Ref. 41). Acronyms are defined in 

Appendix A. ....................................................................................................................................... 23

Figure 12.—Evolution overview of aeronautical mobile communications (Ref. 42; note that this 

schedule is subject to change). Acronyms are defined in Appendix A. ............................................. 24

Figure 13.—Federal Aviation Administration communications roadmap (Ref. 43). Acronyms are 

defined in Appendix A........................................................................................................................ 25

Figure 14.—Next Generation Air Transportation System (NextGen) operational view in 2025 

(Ref. 45). Acronyms are defined in Appendix A. .............................................................................. 27

Figure 15.—System view 2 (SV–2) Next Generation Air Transportation System (NextGen) 2025 

rollup data flow view (Ref. 49). Acronyms are defined in Appendix A. ........................................... 31

Figure 16.—Communication system capacity demand and user base changes. ......................................... 33

Figure 17.—Airborne System Wide Information Management (SWIM) and other Next 

Generation Air Transportation System (NextGen) Programs (Ref. 53). Acronyms are 

defined in Appendix A. ...................................................................................................................... 37

Figure 18.—Air-to-ground data link management and aircraft participation in System Wide 

Information Management (SWIM) (slightly modified from Ref. 55). Copyright Thales Air 

Systems; used with permission. Acronyms are defined in Appendix A. ........................................... 38
NASA/CR—2010-216324 xxx

Figure 19.—System Wide Information Management (SWIM) execution by segments (Ref. 53). 

Acronyms are defined in Appendix A................................................................................................ 39

Figure 20.—Typical National Airspace System (NAS) flight profile and air traffic services (ATS) 

functions (Ref. 5)................................................................................................................................ 39

Figure 21.—High-level hierarchy of C-band communications system. Acronyms are defined in 

Appendix A. ....................................................................................................................................... 43

Figure 22.—Airport point-to-multipoint communications service. Acronyms are defined in 

Appendix A. ....................................................................................................................................... 61

Figure 23.—IEEE 802.16e IP-based network architecture. (Based on Fig. 2.3 in Ref. 61.) ...................... 62

Figure 24.—Network interfaces and functions. Acronyms are defined in Appendix A............................. 64

Figure 25.—NASA–CLE CNS Test Bed base station, backhaul, and core server locations. 

Acronyms are defined in Appendix A................................................................................................ 72

Figure 26.—NASA–CLE CNS Test Bed subscriber station locations and links. Acronyms are 

defined in Appendix A. ...................................................................................................................... 73

Figure 27.—NASA–CLE CNS Test Bed base transceiver station (BTS) and subscriber station 

(SS) outdoor units............................................................................................................................... 75

Figure 28.—Glenn’s mobile test vehicle: THEVAN.................................................................................. 77

Figure 29.—Viking S–3 mobile platform. .................................................................................................. 77

Figure 30.—Cleveland Hopkins International Airport with building footprints highlighted. 

Primary CPE refers to customer premise equipment—referred to as subscriber stations (SSs) 

in other places in this document. Acronyms are defined in Appendix A........................................... 79

Figure 31.—Received signal strength indication (RSSI) plot for 17-dBi directional subscriber 

station mounted at 12 ft. Acronyms are defined in Appendix A........................................................ 80

Figure 32.—Received signal strength indication (RSSI) plot for 17-dBi directional subscriber 

station mounted at 25 ft. Acronyms are defined in Appendix A........................................................ 81

Figure 33.—Connection map for each subscriber station based on received signal strength 

indication (RSSI). Acronyms are defined in Appendix A.................................................................. 82

Figure 34.—Connection map for each subscriber station based on nearest base transceiver station 

(BTS) sector. ...................................................................................................................................... 83

Figure 35.—Base transceiver station (BTS) sectors, Global Positioning System (GPS) receivers, 

and data backhaul installation at Glenn Building 4............................................................................ 85

Figure 36.—Base transceiver station (BTS) and data backhaul equipment rack at Glenn’s 

Building 4........................................................................................................................................... 86

Figure 37.—Subscriber station and enclosure at Glenn’s Building 500..................................................... 87

Figure 38.—Internal electronics of subscriber station enclosure................................................................ 88

Figure 39.—11-GHz backhaul radio outdoor units at Glenn’s Building 4 and Building 110. ................... 89

Figure 40.—11-GHz backhaul radio outdoor units at Glenn Building 110 with links to Glenn 

Building 4 base station (BS) and to Cleveland Hopkins International Airport’s (CLE) 

Airport Rescue and Firefighting (ARFF) building............................................................................. 90

Figure 41.—Aircraft Rescue and Firefighting (ARFF) building base station on observation deck 

roof. .................................................................................................................................................... 91

Figure 42.—Detailed view of base station at Aircraft Rescue and Firefighting (ARFF) building. 

Acronyms are defined in Appendix A................................................................................................ 92

Figure 43.—Core server equipment in Glenn’s Building 110, Room 310. Acronyms are defined in 

Appendix A......................................................................................................................................... 93

Figure 44.—IEEE 802.16e core network diagram. Acronyms are defined in Appendix A........................ 94

Figure 45.—High-level view of C-band communications system (adapted from Ref. 67). ..................... 131

Figure 46.—Decomposition of use of C-band communications system to transmit/receive 

messages (adapted from Ref. 67). .................................................................................................... 131

Figure 47.—Decomposition of transceive fixed-to-mobile message (adapted from Ref. 67). ................. 132

Figure 48.—Decomposition of transceive mobile-to-fixed message (adapted from Ref. 67). ................. 133
NASA/CR—2010-216324 xxxi

Figure 49.—Decomposition of transceive fixed-to-fixed message (adapted from Ref. 67). .................... 133

Figure 50.—Generic decomposition of transceive data message (adapted from Ref. 67)........................ 133

Figure 51.—Generic decomposition of initiate data message (adapted from Ref. 67)............................. 134

Figure 52.—Generic decomposition of process data message for sending (adapted from Ref. 67)......... 134

Figure 53.—Generic decomposition of send data message (adapted from Ref. 67)................................. 134

Figure 54.—Generic decomposition of process received data message (adapted from Ref. 67).............. 134

Figure 55.—Generic decomposition of deliver data message (adapted from Ref. 67)............................. 135

Figure 56.—Generic decomposition of provide failure processing (adapted from Ref. 67)..................... 135

Figure 57.—Decomposition of operate C-band communications system (adapted from Ref. 67). .......... 135

Figure 58.—Decomposition of monitor C-band communications system (adapted from Ref. 67). ......... 136

Figure 59.—Decomposition of maintain C-band communications system (adapted from Ref. 67)......... 136

Figure 60.—Decomposition of configure C-band communications system (adapted from Ref. 67). ...... 137

List of Tables

TABLE ES–1.—NEXT GENERATION AIR TRANSPORTATION SYSTEM (NextGen) 

MIDTERM OPERATIONAL CONCEPTS FOR THE AIRPORT SURFACE PHASE..................viii

TABLE ES–2.—USE OF THE PROPOSED AeroMACS IN THE AIRPORT FLIGHT DOMAIN .......viii

TABLE ES–3.—MAPPING AeroMACS FUNCTIONALITY TO THE NATIONAL AIRSPACE 

SYSTEM (NAS) CONCEPTS OF OPERATION (ConOps)..............................................................ix

TABLE ES–4.—AeroMACS HIGH-LEVEL FUNCTIONAL REQUIREMENTS..................................... x

TABLE ES–5.—NATIONAL AIRSPACE SYSTEM (NAS) FUNCTIONS .............................................xi

TABLE ES–6.—COMMUNICATION SERVICE REQUIREMENTS..................................................... xv

TABLE ES–7.—AeroMACS NETWORK DESIGN TRADEOFFS .......................................................xvii

TABLE ES–8.—EXPERIMENTS AND TEST PLAN TRADEOFF SPACE.........................................xxii

TABLE ES–9.—AeroMACS NASA–CLE TEST BED LINK TEST RESULTS...................................xxiv

TABLE ES–10.—SUMMARY OF FINAL RECOMMENDATIONS FOR AeroMACS 

PROFILE.......................................................................................................................................... xxv

TABLE 1.—AIRPORT SURFACE SYSTEMS THAT COULD BE SUPPORTED BY 

AeroMACS......................................................................................................................................... 11

TABLE 2.—MAPPING AIR-TO-GROUND VOICE COMMUNICATIONS FUNCTIONS 

TO NATIONAL AIRSPACE SYSTEM (NAS) SERVICE CAPABILITIES (REF. 31).................. 14

TABLE 3.—CURRENT SHORTFALLS RELATED TO AIRPORT SURFACE AIR-TO-GROUND 

VOICE COMMUNICATIONS........................................................................................................... 19

TABLE 4.—COMMUNICATION ALLOCATION BETWEEN VOICE AND DATA 

LINK (D/L) ........................................................................................................................................ 21

TABLE 5.—NEXT GENERATION AIR TRANSPORTATION SYSTEM (NextGen) 

MIDTERM OPERATIONAL CONCEPTS FOR THE AIRPORT SURFACE ................................ 40

TABLE 6.—USE OF THE PROPOSED AeroMACS IN THE AIRPORT FLIGHT DOMAIN ............... 40

TABLE 7.—EXAMPLE AeroMACS DATA LINK MESSAGES ............................................................ 41

TABLE 8.—EXAMPLE OPERATIONAL SCENARIOS......................................................................... 42

TABLE 9.—MAPPING AeroMACS FUNCTIONALITY TO THE NATIONAL AIRSPACE 

SYSTEM (NAS) CONCEPTS OF OPERATION (ConOps)............................................................. 44

TABLE 10.—AeroMACS HIGH-LEVEL FUNCTIONAL REQUIREMENTS ....................................... 46

TABLE 11.—MAPPING RELEVANT NATIONAL AIRSPACE SYSTEM (NAS) 

COMMUNICATIONS FUNCTIONS TO NAS SERVICE CAPABILITIES (REF. 31).................. 47

TABLE 12.—NATIONAL AIRSPACE SYSTEM (NAS) FUNCTIONS ................................................. 48

TABLE 13.—NATIONAL AIRSPACE SYSTEM (NAS) PERFORMANCE REQUIREMENTS .......... 51

TABLE 14.—AeroMACS DATA REQUIREMENTS............................................................................... 54

TABLE 15.—NATIONAL AIRSPACE SYSTEM (NAS) SPECTRUM REQUIREMENTS

APPLICABLE TO THE PROPOSED AeroMACS........................................................................... 55
NASA/CR—2010-216324 xxxii

TABLE 16.—AVIATION USER REQUIREMENTS ............................................................................... 55

TABLE 17.—IEEE 802.16e QUALITY OF SERVICE CATEGORIES AND DEFINING 

PARAMETERS ................................................................................................................................. 59

TABLE 18.—COMMUNICATION SERVICE REQUIREMENTS ......................................................... 59

TABLE 19.—SELECTED IEEE 802.16e NETWORK INTERFACE DEFINITIONS............................. 63

TABLE 20.—AeroMACS NETWORK DESIGN TRADEOFFS .............................................................. 67

TABLE 21.—BACKHAUL RADIOFREQUENCY ASSIGNMENTS ..................................................... 73

TABLE 22.—NASA–CLE CNS TEST BED 5-MHz CHANNEL-FREQUENCY 

ASSIGNMENTS................................................................................................................................ 74

TABLE 23.—NASA–CLE CNS TEST BED 10-MHz CHANNEL-FREQUENCY 

ASSIGNMENTS................................................................................................................................ 74

TABLE 24.—GENERAL RADIO SPECIFICATIONS............................................................................. 75

TABLE 25.—5100-MHz BASE TRANSCEIVER STATION SPECIFICATIONS.................................. 76

TABLE 26.—C-BAND SUBSCRIBER STATION SPECIFICATIONS ................................................. 76

TABLE 27.—BASE TRANSCEIVER STATION (BTS) SECTOR CONFIGURATIONS AT 

NASA GLENN AND CLEVELAND HOPKINS INTERNATIONAL AIRPORT (CLE) ............... 79

TABLE 28.—BASE STATION SECTOR CHANNEL-FREQUENCY ASSIGNMENTS FOR 

ANALYSIS ........................................................................................................................................ 80

TABLE 29.—EXPERIMENTS AND TEST PLAN TRADEOFF SPACE................................................ 97

TABLE 30.—AeroMACS PARAMETER SETTINGS AFFECTING THROUGHPUT ........................ 100

TABLE 31.—AeroMACS NASA–CLE TEST BED LINK TEST RESULTS ........................................ 101

TABLE 32.—IEEE 802.16 STANDARD PROFILE FEATURE SETS.................................................. 102

TABLE 33.—AeroMACS PROFILE DEFINITIONS ............................................................................. 102

TABLE 34.—AeroMACS POWER CLASSES ....................................................................................... 103

TABLE 35.—BASIC PHY PROFILE FOR AeroMACS 5-MHz CHANNEL ........................................ 104

TABLE 36.—BASIC PHY PROFILE FOR AeroMACS 10-MHz CHANNEL ...................................... 105

TABLE 37.—BASIC PHY PROFILE FOR AeroMACS 20-MHz CHANNEL ...................................... 105

TABLE 38.—RADIOFREQUENCY PROFILE LIST FOR AeroMACS C-BAND ............................... 106

TABLE 39.—AeroMACS C-BAND RADIOFREQUENCY PROFILE LIST........................................ 107

TABLE 40.—SUMMARY OF FINAL RECOMMENDATIONS FOR AeroMACS PROFILE............. 109

TABLE 41.—THE ROLE OF SURVEILLANCE INFORMATION—RTCA NATIONAL 

AIRSPACE SYSTEM (NAS) CONCEPT OF OPERATIONS (ConOps) APPLICABLE TO 

THE PROPOSED AeroMACS ........................................................................................................ 123

TABLE 42.—THE ROLE OF WEATHER INFORMATION—RTCA NATIONAL AIRSPACE 

SYSTEM (NAS) CONCEPT OF OPERATIONS (ConOps) APPLICABLE TO THE 

PROPOSED AeroMACS ................................................................................................................. 124

TABLE 43.—IDENTIFICATION OF THE ROLE OF FLIGHT MANAGEMENT 

INFORMATION—RTCA NATIONAL AIRSPACE SYSTEM (NAS) CONCEPT OF 

OPERATIONS (ConOps) APPLICABLE TO THE PROPOSED AeroMACS............................... 125

TABLE 44.—IDENTIFICATION OF THE ROLE OF AERONAUTICAL INFORMATION—

RTCA NATIONAL AIRSPACE SYSTEM (NAS) CONCEPT OF OPERATIONS 

(ConOps) APPLICABLE TO THE PROPOSED AeroMACS ........................................................ 127

TABLE 45.—IDENTIFICATION OF THE ROLE OF RESOURCE MANAGEMENT 

INFORMATION—RTCA NATIONAL AIRSPACE SYSTEM (NAS) CONCEPT OF 

OPERATIONS (ConOps) APPLICABLE TO THE PROPOSED AeroMACS............................... 129
NASA/CR—2010-216324 1

1.0 Introduction

1.1 Background 

During the past 4 years, the NASA Glenn Research Center and ITT Corporation have conducted a 

three-phase technology assessment for the Federal Aviation Administration (FAA) under a joint FAA–

European Organisation for the Safety of Air Navigation (EUROCONTROL) Cooperative Research 

Action Plan (AP–17), also known as the Future Communications Study (FCS). NASA/ITT provided a 

system engineering evaluation of candidate technologies for the future communications infrastructure 

(FCI) to be used in air traffic management (ATM). Specific recommendations for data communications 

technologies in the very high frequency (VHF), C, L, and satellite bands, and a set of follow-on research 

and implementation actions have been endorsed by the FAA, EUROCONTROL, and the International 

Civil Aviation Organization (ICAO). In the United States, the recommendations from AP–17 are reflected 

in the Joint Planning and Development Office’s (JPDO) “Next Generation Air Transportation System, 

Integrated Plan” (Ref. 15) and are represented in the “National Airspace System (NAS) Infrastructure 

Roadmaps” (Ref. 16). 

Action Plan 30 (AP–30), a proposed follow-on cooperative research to AP–17, is expected to start in 

fiscal year 2010 (FY10) to ensure coordinated development of FCI to help enable the advanced ATM 

concepts of operation (ConOps) envisioned for both the Next Generation Air Transportation System 

(NextGen) in the United States and EUROCONTROL’s Single European Sky ATM Research program in 

Europe. Follow-on research and technology development recommended by ITT and Glenn 

and endorsed by the FAA was included in the FAA’s NextGen Implementation Plan 2009. The 

plan was officially released at the NextGen Web site (http://www.faa.gov/about/initiatives/nextgen/) on 

January 30, 2009. The implementation plan includes a FY09 solution set work plan for C-band and 

L-band future communications research in the section, “New Air Traffic Management (ATM) 

Requirements.”

On February 27, 2009, the FAA approved a project-level agreement (PLA FY09_G1M.02-02v1) for 

“New ATM Requirements—Future Communications,” to perform the FY09 portion of the FAA’s 

solution-set work plan; this includes the development of concepts of use (ConUse), requirements, and 

architecture for both a new C-band airport surface wireless communications system and a new L-band 

terrestrial en route communications system. The work described in this report covers ITT’s portion of the 

project-level agreement tasks related to C-band airport surface wireless communications development.

This report is being provided as part of the Glenn Contract NNC05CA85C, Task 7: “New ATM 

Requirements—Future Communications, C-Band and L-Band Communications Standard Development.” 

Task 7 is separated into two distinct subtasks, each aligned with specific work elements and deliverable 

items identified in the FAA’s project-level agreement and with the FAA FY09 spending plan for these 

subtasks. The purpose of subtask 7–1, and the subject of this report, is to define the C-band airport surface 

ConUse, systems performance requirements, and architecture in a future C-band (5091 to 5150 MHz6

) 

air-to-ground (A/G) communication system referred to as the Aeronautical Mobile Airport 

Communications System (AeroMACS).

 6

With a possible future extension into the 5000- to 5030-MHz band, pending a decision at the World 

Radiocommunications Conference in 2012.
NASA/CR—2010-216324 2

1.2 Systems Overview

Systems covered by this document provide the following airport surface communications services 

shown within the dashed red boxes in Figure 1.

Figure 1.—Communications systems covered by this ConUse document (slightly altered version of Figure 1−1 in 

Ref. 7).

Operator System Element

Ground – Ground

Wired Communication

Communication

Services

Ground - Ground

Wireless

Communication

Interface to

Communication

Services

End System

Fixed

Surface Mobile System Element

End System

(Mobile)

Interface to

Communication

Services

Surface Fixed System Element

Operator System Element

Ground – Ground

Wired Communication

Communication

Services

Ground - Ground

Wireless

Communication

Interface to

Communication

Services

ATS

End System Fixed

Surface Fixed System Element

End System

(Fixed)

Interface to

Communication

Services

Air Traffic Service Provider 

(ATSP) System Element

Air Traffic Service Provider 

(ATSP) System Element

Air Traffic Service Unit (ATSU)

Operator System Element

Air Traffic Service Provider (ATSP) System Element

Controller

Air Traffic Service Unit (ATSU)

Flight Crew

Ground – Ground

Communication

Communication

Services

Air - Ground

Communication

Procedures

(Flight Deck)

Procedures

(ATSU)

HumanMachine

Interface

Interface to

Communication

Services

End System

(ATSU)

Aircraft System Element

End System

(Aircraft)

HumanMachine

Interface

Interface to

Communication

Services
NASA/CR—2010-216324 3

• Air traffic services (ATS) A/G flight safety communications between fixed ATS provider (ATSP) 

system elements and an aircraft

• ATS ground-to-ground (G/G) communications between fixed ATSP system elements (e.g., to 

provide connectivity between the components of a NAS surveillance system).

• G/G communications between fixed and mobile operator (e.g., airline) system elements (e.g., to 

provide connectivity for aeronautical operational or administrative messages supporting the 

operation or maintenance of facilities provided for the regularity of aircraft operations as 

described in Ref. 17).

On the ground, these systems typically consist of radio ground station subsystems—including radios, 

antennas, cabling, power systems, environmental systems, towers, monitoring and control functionality, 

and other systems to provide wireless communications services; networking subsystems to provide G/G 

communications service connectivity to end systems and users; and usually some centralized functionality 

to monitor and control system operations and performance. Aircraft and other mobile components include 

radio equipment, antennas, and associated cabling.

1.3 Document Overview

This document is organized as follows:

• Section 1.0 provides background system information and describes the document scope, 

organization, and references. 

• Section 2.0 presents the ConUse and the processes for developing the requirements. 

• Section 3.0 is devoted to the ConUse of the proposed AeroMACS. After describing the ConUse 

development process, it presents the operational need for AeroMACS by describing current A/G 

and G/G communications systems and their associated problems and capability shortfalls. 

Section 3.3 shows the potential benefits of the new systems and describes the desired changes. 

The proposed system is then described. ConUse are presented, along with references to RTCA’s 

NAS concept of operations (ConOps) guidance documents and descriptions of FAA’s Data 

Communications Program (Data Comm) operational scenarios, NextGen operational concepts, 

and AeroMACS operational concepts based on the airport surface flight domain as well as those 

derived from the communications operating concept and requirements (COCR). 

• Section 4.0 presents AeroMACS system requirements. It describes the development process for 

system requirements and presents results for the “middle-out” approach.

• Section 5.0 describes preliminary systems performance requirements and an initial network 

architecture.

• Section 6.0 describes modifications to the NASA Glenn/Cleveland Hopkins International Airport 

(NASA–CLE) Communications, Navigation, and Surveillance (CNS) Test Bed to add Institute of 

Electrical and Electronics Engineering (IEEE) 802.16 (Ref. 18) capability and testing and 

evaluation results using simulation, emulation, and or test bed tests. It also provides initial data to 

be input to the aeronautical mobile-specific IEEE 802.16 design specifications.

• Section 7.0 provides concluding requirements and specification recommendations for use by 

standards-setting bodies.

• Appendix A defines acronyms and abbreviations used in this report.

• Appendix B summarizes the RTCA NAS ConOps applicable to the proposed AeroMACS. 

• Appendix C provides hierarchical diagrams of the functional requirements for the AeroMACS 

C-band communication system. 
NASA/CR—2010-216324 4

2.0 ConUse and Requirements Development Processes

ConUse are part of a hierarchy of documents that capture concepts related to the NAS. As defined in 

the FAA’s NAS System Engineering Manual (SEM), there are two general types of concepts documents 

associated with system engineering in the NAS: ConOps and ConUse. ConOps describe “what is 

expected from the system, including its various modes of operation and time-critical parameters” 

(Ref. 19), whereas a ConUse is “an extension of a higher level ConOps with an emphasis on a particular 

NAS system and its operating environment” (Ref. 19). Figure 2 depicts the three hierarchical levels of 

concept documents typically used in the NAS and defined in the SEM: two levels of ConOps and the 

ConUse. 

Figure 2.—National Airspace System (NAS) engineering concept document hierarchy (Ref. 19). 

Acronyms are defined in Appendix A.
NASA/CR—2010-216324 5

These three levels can be summarized as follows:

• NAS-level ConOps comprise “a high-level narrative of the user community’s desired change with 

some performance indicators. The document indicates from the user’s perspective the desired 

end-state for respective systems in the NAS. It often uses various operational scenarios to 

illustrate the desired operational concept” (Ref. 19).

• Service-level ConOps provide “conceptual insight into a particular service of the NAS.” These 

give “more detail and in-depth information about the desired operations within the service” 

(Ref. 20).

• ConUse are extensions of the NAS-level ConOps and a particular service-level ConOps, “with an 

emphasis on a particular NAS system and its operating environment.” ConUse are more detailed 

and substantial, but they still express “the user’s needs regarding a specific system within the 

NAS” (Ref. 20).

NAS-level and similar level international ConOps driving this ConUse and its associated 

requirements include RTCA’s “National Airspace System: Concept of Operations and Vision for the 

Future of Aviation” (Ref. 13), the “Concept of Operations for the Next Generation Air Transportation 

System” (Ref. 4), and the ICAO’s “Global Air Traffic Management Operational Concept” (Ref. 21). At 

the next lower layer, EUROCONTROL’s “Operating Concept of the Mobile Aviation Communication 

Infrastructure Supporting ATM Beyond 2015” (Ref. 22) was used with the service-level ConOps—

“Communications Operating Concept and Requirements for the Future Radio System” (Ref. 12)—to 

provide reference guidance for A/G operating concepts and requirements directly applicable to this 

ConUse. On a similar level to this ConUse, but with a different scope and intended for different services, 

are the operating concepts and requirements presented in “Data Communications Safety and Performance 

Requirements” (Ref. 23) and “Final Program Requirements for Data Communications” (Ref. 5). 

It should be noted that the ConOps and ConUse documents just referenced relate primarily to the 

provision of safety-critical A/G air traffic control (ATC) communications services; however, they also are 

applicable to the provision of airport surface G/G communications links that support other NAS safety 

critical services, such as surveillance, weather, flight planning, and aeronautical information. NAS 

ConOps applicable to the provision of aeronautical operational and administrative messages over G/G 

communications systems and supporting the regularity of flight operations are not available for reference, 

perhaps because NAS ConOps typically apply to the provision and operation of safety-critical services. 

The ConUse and performance requirements described in this document apply to a future airport 

surface-band (5091- to 5150-MHz6

) communication system referred to as AeroMACS that will provide 

A/G and G/G communications services similar in scope to those described in the “FCI Aeronautical Data 

Services Definition Task Report” (Ref. 9) as well as other services shown in Figure 1. The 2009 FCI 

report follows from the previous FCS technology evaluation study (Ref. 24), which identified the IEEE 

802.16e standard (Ref. 18) as the recommended candidate for further development because it best meets 

the FCS technology assessment criteria and is designed for the C-band spectrum, which is a 

recommended band for supporting new data link communications capabilities for airport surface 

communications. 
NASA/CR—2010-216324 6

Typically, the development of concepts documents and requirements for new systems for the NAS are 

based on the process depicted in Figure 3, which illustrates the top-down iterative process and general 

relationships among concepts, requirements, and architectures. Because many, if not most, NAS systems 

are not entirely new, but rather, evolutionary improvements of existing NAS systems, a top-down process 

is not always sufficient. Instead, a “middle-out” approach is taken. This is a combination of a top-down 

process, which takes into account new concepts and missions needs, and a bottoms-up approach, which 

takes into account existing concepts, systems, and requirements. Figure 4 shows the middle-out approach 

adopted for the ConUse and requirements developed for AeroMACS. As shown in the figure, operational 

concepts and requirements of higher level concepts documents flow down to this document, providing 

high-level guidance and direction in the form of required functions and flows for the services of interest, 

namely A/G and G/G communications services. In addition to this top-down process, a bottom-up process 

of identifying and evaluating specific concepts and requirements developed for specific communications 

systems, such as Data Comm, Next Generation Air/Ground Communication (NEXCOM), and Link 

2000+, along with appropriate NAS System Requirements (SR−1000, Refs. 10 and 11) and IEEE 802.16e 

requirements (Ref. 18), was employed for this document. 

Figure 3.—Requirements management process flow (Ref. 25). Acronyms are defined in Appendix A.
NASA/CR—2010-216324 7

Figure 4.—AeroMACS ConUse and system requirements development flow chart. Acronyms 

are defined in Appendix A.

FAA OSED for the Future 

Comm. System

NextGen

ConOps

EUROCONTROL’s Operating 

Concept of the Mobile Aviation 

Comm, Infrastructure 

Supporting ATM beyond 2015

FAA Final Program 

Requirements for Data Comm.

RTCA NAS 

ConOps Vision 

for the Future 

of Aviation

COCR v2.0

Global ATM 

Operational 

Concept Document 

(ICAO 9854)

FAAData

Comm

Program 

Requirements

Functional Analysis: 

Identifying Specific Functions 

Necessary to Enable these 

Concepts of Use

COCR

V2.0

(Performance

Requirements)

ICAO 9869 RCP Manual

RTCA DO-264

RTCA DO-290

Other System/Service Level ConOps/ConUse

NAS Level ConOps

NAS-SR 1000

System Requirements 

Bottom-up Assessment

Combined System 

Requirements

System Requirements 

Top-Down Assessment

ICAO/RTCA

A/G

SARPs/

MASPS

NEXCOM

SRD

ConUse

Development

IEEE 

802.16e2005/2009
NASA/CR—2010-216324 8

3.0 ConUse

3.1 ConUse Development Process

A process recommended in the NAS system engineering manual (SEM, Ref. 1) was used as a guide in 

developing ConUse for the proposed AeroMACS. Figure 5 summarizes the steps. The following sections 

describe the findings for each of the steps shown in the figure.

Figure 5.—ConUse development process. Acronyms are defined in Appendix A.

3.2 Operational Needs

This section defines the operational needs for AeroMACS by describing current and planned airport 

surface communications systems and their associated problems and capability shortfalls. Though not a 

current system, the planned data communications networks services A/G data communications system 

being developed under the FAA’s Data Comm Program is discussed here because it is expected to be 

implemented before an AeroMACS system is likely to be implemented for airport surface A/G 

communications. Data Comm should mitigate many of the current operational problems and shortcomings while leaving room for AeroMACS to provide additional gains in overcoming current A/G 

communications problems and shortcomings. 

Identify Operational 

Need for a New 

System

• Describe Current 

A/G 

Communication 

System

• Describe Current 

airport surface 

G/G 

Communications 

Systems

• Current System 

Operational 

Environments

• Current Systems 

Scope and 

Capability 

Shortfalls

Provide Proposed 

System Justification

• Potential 

Benefits of New 

Systems

• Operational 

Shortfalls 

Addressed by 

Data Comm

Program

• Description of 

Desired Change

• Change Priorities 

and Road Maps

• Assumptions and 

Constraints

Define Proposed 

System

• Objectives and 

Scope

• Proposed 

System in 

context of NAS 

EA Operational 

View

• System 

Description

• Operational 

Environment

• Frequency and 

Technology –

Environment, 

Requirements 

and Limitations

• Users

• Operational 

Policies and 

Constraints

Define ConUse

• Use of the 

Proposed 

System for 

Airport

• Data Link 

Messages 

Examples

• Operational 

Scenarios 
NASA/CR—2010-216324 9

3.2.1 Current Airport Surface Communications Systems

3.2.1.1 Current Air-to-Ground Communication System

The “System Requirements Document, Next Generation Air/Ground Communications (NEXCOM)” 

provides a good description of the FAA’s current analog A/G voice communications system used for 

ATC (Ref. 2):

The current A/G Communications System for ATC consists of voice-based networks that use 

DSB-AM [double-sideband amplitude-modulation] radios and operate in the 117.975 to 137 

Megahertz (MHz) VHF band for civil aircraft and the 225- to 400-MHz UHF [ultra-high-frequency] 

band for military aircraft. The radios operate with the same frequency used for controller-to-pilot 

(uplink, UL) and pilot-to-controller (downlink, DL) transmissions in a simplex “push-to-talk” mode. 

There is a dedicated, non-interconnected radio network for each operational environment (En Route, 

Terminal, airport surface, and flight service). In the event of a control facility power loss, engine 

generators provide back-up power. In the event of equipment failure, A/G communications are 

provided Back-Up Emergency Communications (BUEC) in the En route, Emergency 

Communications System (ECS) in the large TRACONS [terminal radar approach control facilities] 

and portable transceivers in the smaller TRACONS and Air Traffic Control Towers (ATCT).

The current A/G communications system architecture is roughly the same for all operational 

environments. The specific equipment used in the A/G communications string can differ among the 

various facilities. Different control facility types have different voice switches, with each type of 

switch having a unique interface.
NASA/CR—2010-216324 10

Figure 6 shows this system for en route A/G communications. Similar architectures are in place for 

terminal area and airport surface area A/G communications. Figure 7 depicts a typical remote 

transmitter/receiver (RTR) site configuration used for A/G communications for the Terminal Area and for 

the airport surface. Appendix A of the NEXCOM System Requirements Document provides a good, 

detailed description of the current A/G voice communications architecture and facilities.

Figure 6.—Current en route air-to-ground (A/G) communications system (Ref. 26). Acronyms are defined in 

Appendix A.
NASA/CR—2010-216324 11

Figure 7.—Typical remote transmitter/receiver (RTR) site configuration (Ref. 27). ATCT, air 

traffic control tower.

3.2.1.2 Current Airport Surface Ground-to-Ground Communication Systems

Current G/G communications on the airport surface are conducted predominantly over a combination 

of wire and optical fiber cabling and a limited number of point-to-point line-of-sight (LOS) radio links. 

Most often, airport surface systems are interconnected by direct telecommunications services, including 

underground cable systems implemented by the airport.

Shielded, twisted-pair copper lines carry low-data-rate and voice communications between fixed 

locations. Fiber-optic cables perform a similar function but have expanded bandwidth capability. Point-topoint radio links can handle narrow to wide data bandwidths without the use of difficult-to-install 

underground cables.

G/G communications handle data exchanges between a wide variety of applications on the airport 

surface. Table 1 lists examples of present and future applications that require G/G communications.

TABLE 1.—AIRPORT SURFACE SYSTEMS THAT COULD BE SUPPORTED BY AeroMACS

Service Airport Surface Systems Supported

Sensor data collection/ dissemination for 

situational awareness

Multilateration (MLAT) Airport Surface Detection Equipment, Model X

Automatic dependent surveillance—broadcast (ADS–B) ground sites

Air surveillance radar

Airport lighting systems

Network-enabled weather data; automated surface observation systems 

(ASOS), low-level wind shear alert system, Terminal Doppler Weather 

Radar, Integrated Terminal Weather System, icing

Cable/Telco replacement and 

augmentation

Backup and primary alternative to cabled connections

Extend cable loop infrastructure to remote surface assets

Temporary fixed-asset connection during surface construction or service 

restoration

Remote transmitter/receivers (RTRs)
NASA/CR—2010-216324 12

3.2.2 Current System Operational Environments

According to the SEM (Ref. 28), the operational environment of a system consists of

the conditions in which the mission or function is planned and carried out. Operational conditions are 

human-created conditions involving operations such as air traffic density, communication congestion, 

and workload. Part of the operational environment may be described by the type of operation (air 

traffic control, air carrier, general aviation); phase [of flight] (ground taxiing, takeoff, approach, 

en route, transoceanic, landing); or rules governing the operation (Instrument Flight Rules versus 

Visual Flight Rules).

Rather than being a NAS service itself, G/G and A/G communications are enablers of NAS services 

and provide the following functionality (Ref. 11):

Communications enables the NAS to exchange information with users, specialists, ATC facilities, and 

other Government agencies. Communications enables air traffic control operations within the NAS by 

employing appropriate technologies to exchange voice and data. This information is transported over 

land lines and wireless connectivity utilizing government and commercial assets. Communications 

defines how data is moved across the NAS to accomplish flight planning, control functions and 

navigation services for ground and space based systems. This enabler provides end-to-end service to 

pilots to include disseminating and coordinating the flight plan and defines how controllers provide 

service throughout the flight while coordinating with other facilities and government agencies. The 

communications enabler supports collaboration between users and specialists for traffic 

synchronization and flow services. Communications support the exchange of navigation and 

surveillance information across the NAS. Information includes electronic signals emanating from ILS 

[instrument landing system], VOR [VHF omnidirectional range] and space based systems and aircraft 

transmitted beacon code data.

Reference 29, which gives an as-is system view 2 (SV–2) of the NAS, describes how NAS interfaces, 

as identified in Reference 30 (NAS SV–1) are supported by physical media.

Pertinent information about communications systems, communications links, and communications 

networks is presented as a pictorial view of system interactions and telecommunications service 

characteristics along with implementation technologies. The as-is SV–2 views were developed depicting 

an overall telecommunications infrastructure and providing separate views for five information flow 

areas:

• Surveillance

• Weather

• Command and control

• Flight data

• Aeronautical information
NASA/CR—2010-216324 13

3.2.2.1 Current Air Traffic Control Air-to-Ground Communications System Operational 

Environments

Figure 8 presents an overview chart depicting an SV–2 telecommunications view and associated data 

for the command and control functional flow area. Note that the “Terminal Voice” link depicted in the 

figure also would include airport surface voice communications between aircraft on the ground and radio 

equipment (typically RTR sites, as shown in Figure 8) serving ATCTs.

Figure 8.—System View 2 (SV–2) command and control detailed air-to-ground 

communications view for 2009 to 2010 (Ref. 29). Acronyms are defined in Appendix A.

Specifically, A/G communications is mainly used for communications between air traffic controllers 

or specialists on the ground and manned aircraft pilots to enable the following required NAS functions 

(Ref. 10)

7

:

• Manage flight plans (plan flights)

• Monitor aircraft status (monitor flights)

• Control aircraft (control traffic)

• Manage weather information (support flight operations)

• Maintain NAS infrastructure (monitor NAS operations)

• Plan traffic flow (plan NAS usage)

• Assess traffic flow performance (plan NAS usage)

For the most part, these functions are currently implemented in the NAS via voice communications; 

though the NAS SR−1000 (Ref. 10) includes requirements for some functions that explicitly designate 

data communications as the means of A/G communications and other requirements that do not specify the 

A/G communications type.

 7

In the listing, the subfunction is shown, followed by the parent function in parentheses. 
NASA/CR—2010-216324 14

The NAS functions listed above are needed to provide several of the NAS service capabilities defined 

in the NAS SR−1000. Table 2 provides a mapping of NAS-level functions to the NAS service capabilities 

enabled by those functions. An “x” at a row-column intersection in the table indicates that the particular 

function in that row is needed to provide the NAS service capability in that column. Of particular interest 

for this report are the functions that can be enabled by A/G voice communications to provide specific 

NAS service capabilities. For example, A/G voice communications is used to implement some of the 

functionality needed to manage flight plans in support of the flight-planning service capability. This A/G 

voice-communications-specific mapping is indicated by the blue boxes in the table. Thus, as shown in the 

table, A/G communications is needed to support the following NAS service capabilities (denoted with 

blue boxes in the service “Capability” row):

• Flight planning

• Separation assurance

• Advisory services

• Traffic flow management

• Emergency services

• Infrastructure and information management

TABLE 2.—MAPPING AIR-TO-GROUND VOICE COMMUNICATIONS FUNCTIONS

TO NATIONAL AIRSPACE SYSTEM (NAS) SERVICE CAPABILITIES (REF. 31)

[Acronyms are defined in Appendix A.]
NASA/CR—2010-216324 15

Some of the NAS service capabilities listed earlier, such as separation assurance and A/Gcommunications-enabled flight planning service capability, are considered to be safety critical for the 

NAS. Because of the need to support such NAS critical services, A/G voice communications latency and 

availability performance requirements are fairly stringent. Typically, this has resulted in requirements for 

0.99999 availability and an end-to-end latency of 250 msec8 for the most critical voice communications 

services. 

For continental airspace, A/G voice communications is provided in the terminal maneuvering area 

(TMA), en route, and in airport surface domains, with the current architecture as described in 

Section 3.2.1. Voice communications is used for all phases of flight: that is, from gate to gate.

3.2.2.2 Current Airport Surface Ground-to-Ground Communications System Operational 

Environments

Besides the various NAS service capabilities and functions enabled by A/G communications for 

command and control as described in the preceding section, numerous surveillance, weather, and 

aeronautical data NAS services are supported by systems operating on the airport surface. For the most 

part, these systems are interconnected by direct telecommunications services, including underground 

cable systems implemented at the airport. The NAS services potentially supported by systems operating 

on the airport surface are indicated by red dashed boxes in Figure 9. 

 8

This performance value for end-to-end A/G voice communications latency was provided in earlier versions of NAS 

SR−1000, but is not in current versions. 
Figure 9.—System view 2 (SV–2) 2009 to 2010 data flow views (Ref. 29). Acronyms are defined in Appendix A

SV-2 Surveillance View: 2009-2010* SV-2 Weather View: 2009-2010

SV-2 Aeronautical 

2009-

ARSR-1/2

ARSR-3/4

Military

Beacon

Beacon SSR

Mode-S

NASA/CR—2010-216324 16 
NASA/CR—2010-216324 17

3.2.3 Current System Users

The users of the current VHF A/G and G/G communications systems include the following:

(1) Scheduled air transport carriers (including international, trunk, regional, commuter, and air 

freight carriers)

(2) Nonscheduled air carriers

(3) General aviation (including operators of turbine-powered and reciprocating–engine aircraft)

(4) Operators of unpowered aircraft (including gliders and lighter-than-air aircraft)

(5) Operators of various military aircraft

(6) Operators of certain ground and maritime vehicles (e.g., airport service vehicles and those 

vehicles coordinating in a search-and-rescue mission)

(7) ATS providers

(8) Aeronautical operational control (AOC) service providers (Ref. 32)

3.2.4 Current System Scope and Capability Shortfalls

3.2.4.1 Current Air Traffic Control Air-to-Ground Communications System Scope and 

Capability Shortfalls

The objectives of the current A/G communications system are consistent with the provisions of the 

NAS service capabilities and performance requirements listed in Section 3.2.2.1. Currently, they are 

characterized by (Ref. 33), “high availability, low end-to-end latencies, the ability to convey human 

feelings, flexibility of dialogue, provision of a party-line, and use for nonroutine, time critical, or 

emergency situations.”

Some of these characteristics actually offer an advantage to voice communications as compared to 

data communications; however, there are several disadvantages of voice communications that motivate 

the need for data communications for many applications.

The NextGen ConOps has summarized the current attributes (and associated constraints) of the voicebased A/G communications system as follows (Ref. 3):

• Limited data communications for ATM and operational control

• Limited access to real-time weather and aeronautical data

• Voice communications routine for ATM

• Analog voice

• Analog weather information display systems

• A/G and G/G communications

• Loss of communications due to beyond line-of-sight (BLOS) aircraft position (e.g., over the 

ocean)

• Individual ground systems for each information type brought to the flight deck

• Point-to-point aircraft communications based on ATC sectors

Currently continental A/G voice communications systems operate over the VHF and UHF 

aeronautical mobile (route) service (AM(R)S) frequency bands, and the scope of operation is constrained 

to be radio LOS, which dictates the need for networks of ground radio stations to provide radiofrequency 

(RF) coverage for the entire airspace volume for which the NAS service is to be provided. 
NASA/CR—2010-216324 18

Figure 10 summarizes several principal shortcomings of the current A/G voice communications 

system, including lack of automation, limited or no data communications availability, aging infrastructure, technology limitations, and spectrum saturation. The resulting operational problems, if not 

addressed, could lead to service degradation and limit the introduction of new or expanded services. 

These, in turn, could potentially compromise safety of operation and increase operating costs. 

Figure 10.—Current National Airspace System air-to-ground communications operational problems.

Though saturation of spectrum is highlighted in red as the problem specifically mitigated by the 

introduction of a new C-band system (AeroMACS); the other operational problems would also be 

mitigated with AeroMACS. 

As the NAS evolves to achieve the JPDO’s and FAA’s NextGen vision and ConUse, many of the 

transformational services and planned operational improvements will be enabled via data communications. Unfortunately, the current A/G communications system lacks data communications capability for 

ATS. In moving toward NextGen, this shortcoming will become more acute and will lead to several 

significant shortfalls in safety, capacity, efficiency, and productivity. As part of the investment analysis 

process for Data Comm, a fairly comprehensive list of these shortfalls has been developed. These are 

repeated in Table 3 to specifically identify the shortfalls that Data Comm intends to address.

It is important to note that the “Final Program Requirements for Data Communications” (Ref. 5) 

recognizes that “the scope of the mission shortfalls identified herein is broader than will be addressed 

solely by a data communications capability.” Because of the limitations and constraints of implementing 

data communications using very high frequency digital link (VDL) Mode 2 over a congested aeronautical 

VHF band, Data Comm will focus principally on implementing the most critical ATSs. This provides 

opportunities for AeroMACS systems to augment data communications on the airport surface by enabling 

communications of less critical and essential ATSs to address the shortfalls listed in Table 3.

Lack of 

automation

Dependency on 

human interface

Opportunities for errors. 

Increased use of human resources

Safety may be 

compromised. 

Potential cost 

increase.

Limited to no 

data/info 

availability on a 

plane

Decisions made 

on the ground

Potential for less than optimum 

decisions being made. 

Inefficient use of ground resources.

Safety may be 

compromised. 

Potential cost 

increase.

Aging 

infrastructure

Need for repairs.

Limited introduction of new 

applications

Safety may be 

compromised. 

Potential cost 

increase.

Technology 

limitations

Limited 

introduction of 

new services and 

applications

Inefficient use of resources. Missed 

opportunities to increase safety and 

capacity

Safety may be 

compromised. 

Potential cost 

increase.
NASA/CR—2010-216324 19

Even though Data Comm means to use VDL Mode 2 to address, to some extent, each of the shortfalls 

in Table 3, there are opportunities to overcome these shortfalls to even a greater extent during the later 

program segments of Data Comm (e.g., late Segment 2 and Segment 3) using link technologies such as 

AeroMACS with greater bandwidth capabilities, which could augment the benefits already attained 

through the earlier VDL Mode 2 Data Comm segment implementations (i.e., Segments 1 and 2) by 

providing a broader scope of services. 

TABLE 3.—CURRENT SHORTFALLS RELATED TO AIRPORT SURFACE AIR-TO-GROUND VOICE COMMUNICATIONS

[From a subset of the shortfalls described in Ref. 34.]

Safety shortfalls

Situations conducive to producing errors, confusion, and read-back and hear-back errors arising from voice congestion and voice 

communication quality

No alternative means to enable A/G communication support for contingency plans when the primary voice communication is not 

available 

Capacity shortfalls

Inability to rapidly and accurately communicate complex clearances containing multiple latitude/longitude-defined route 

elements

Inefficient dissemination of airspace congestion, weather advisory, and NAS infrastructure status information

Inefficient communication of complete departure clearances and revisions necessitated by traffic management initiatives

Inability to provide for the maximum efficient use of the airspace and strategic plans by adjusting individual flights to reduce 

contention for resources and ensure that 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

Efficiency and productivity shortfalls

Inability to support airspace user operational requirements, utility, performance, and other flight operations preferences—

Avionics and airframe manufacturers need consistent global communication capability requirements.

Inability to exchange user-preferred trajectories in real time; 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

No synchronization between onboard 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 would increase predictability for 

flights and allow aircraft operators to reduce costs, optimize flight routes, improve utility, and reduce dependency on voice 

communications.

No integration of A/G communications with other aspects of the automation environment—

Instructions to and requests from airspace users must be independently exchanged via voice A/G 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 automate many repetitive and time-consuming tasks; precludes labor resources from focusing on more productive 

tasks.

No capabilities inherent in modern, network-based communications; therefore, less efficient dynamic resource management
NASA/CR—2010-216324 20

3.2.4.2 Current Airport Surface Ground-to-Ground Communications Systems Scope and 

Capabilities Shortfalls

The existing airport communications infrastructure lacks the flexibility for reconfiguration and for 

accepting new services because of its limited bandwidth and interface capabilities. In addition, many 

control, signal, and communications cables serving FAA facilities at major airports are 25 to 30 years old. 

In many cases, the cables are badly deteriorated, lack remote maintenance monitoring functions, and do 

not provide redundant paths for critical functions. Underground cables are also at risk from inadvertent 

“cable cuts.” It is expensive to deploy and maintain underground cabling as a replacement for existing 

cables or an expansion for new services. 

The limitations imposed by the current G/G communications infrastructure could result in restrictions 

in the deployment of new ATM services, resulting in the following service limitations (Ref. 4):

• Limited ATM (e.g., traffic) information on the flight deck

• Limited data shared among stakeholders for collaborative decision making (CDM) processes 

• Information sharing in support of operational security performed manually instead of 

electronically 

• Not all stakeholders able to access data they need 

• Stakeholders unable to use custom data sources

3.3 New Airport Surface Communications Systems Justification

3.3.1 Potential Benefits of New Airport Surface Communications Systems

3.3.1.1 Potential Benefits of New Airport Surface Air-to-Ground Air Traffic Control 

Communications Systems

The NextGen ConOps states that transforming the ATM system in NextGen is “necessary because of 

the inherent limitations of today’s system, including limits driven by human cognitive processes and 

verbal communications” (Ref. 35). Likewise, the joint EUROCONTROL/FAA FCS conducted for AP–17 

concluded that “in the longer term, a paradigm shift will occur in the operating concept and the prime 

mode of communication exchanges will be based in data exchanges rather than voice communications as 

it is today” (Ref. 36). 

The following excerpts (Ref. 37) from JPDO’s NextGen ConOps comprehensively describe NextGen 

A/G network services. These excerpts are repeated here because they effectively communicate the full 

envisioned scope, benefits, and advantages of these services and the importance of data communications 

in enabling them: 

With the transformed role of the flight crew and flight deck in NextGen, data communications are 

critical to ensuring that data is available for flight deck automation (i.e., avionics to support flight 

crew decision making). ... Data communications are also needed to provide real-time data to the 

ANSP [air navigation service provider] on the operational aspects of flights. In certain defined 

airspace, data communications are the primary means of communicating clearances, routine 

communications, and 4DT [four-dimensional trajectory: latitude, longitude, altitude, and time] 

agreements between the ANSP and flight deck. ... Voice communications are used to supplement 

data communications for tactical situations and for emergencies to augment procedural responses or 

risk mitigations. Voice communications are used to communicate with lesser-equipped aircraft in 

appropriate airspace. ...

One of the key transformations is that air-ground voice communications are no longer limited by the 

assigned frequency-to-airspace sector mapping. This allows greater flexibility for developing and 

using airspace/traffic assignments in all airspace. Communications paths, including both voice and 
NASA/CR—2010-216324 21

data, are controlled by an intelligent network. Communications between the ANSP and the flight deck 

are established when the flight is activated and are maintained continuously and seamlessly. This 

capability is linked to the flight data management function so that the system automatically manages 

who has authority to interact with the flight deck based on the type of agreement being negotiated or 

information being exchanged. Labor-intensive transfers of control and communication are automated. 

Data and voice communications are automatically transferred in the flight deck as the aircraft moves 

between ANSPs.

Data communications are central to TBO [trajectory-based operations], including the use of 4DTs 

(pushback and taxi inclusive) for planning and execution on the surface, automated trajectory analysis 

and separation assurance, and aircraft separation assurance applications that require flight crew 

situational awareness of the 4DTs and short-term intent of surrounding aircraft.

In addition, as indicated above, there is increased sharing of improved common data between the 

flight deck, operator, and ANSP. In classic airspace where data communications will be available but 

not required, information exchange can take place with data communications for participating aircraft 

to provide an operational advantage. Common data includes ATC clearances, current and forecast 

weather, hazardous weather warnings, notices to airmen (NOTAMs), updated charts, current charting, 

special aircraft data, and other required data. Data communications also include weather observations 

made by the aircraft that are automatically provided to ANSPs, weather service providers, and flight 

operators for inclusion in weather analysis and forecasts. Each of these data communications 

functions are managed by required communications performance (RCP) standards.

The trend toward 2015 and beyond features a decreasing use of voice, with data becoming the 

primary communication link. This is shown in Table 4, which illustrates a projected allocation between 

voice and data communications during this period. As suggested by the table, on the airport surface, voice 

would remain the primary mode of communications for low delay and high availability pilot-ATC 

exchanges, with a data link used as a primary service for other messages and data-intensive services such 

as graphical weather. In all domains, voice communication would remain a backup for any data service.

TABLE 4.—COMMUNICATION ALLOCATION BETWEEN VOICE AND DATA LINK (D/L)

[Information from Ref. 38.]

Airport surface

Primary Backup

Pilot-controller 

dialog

Emergency messages Voice D/L

Tactical clearances Voice and some D/L Voice and D/L

Strategic clearances D/L Voice

Information messages D/L Voice

Other 

exchanges and 

broadcasts

Pilot-pilot dialog Voicea D/L

Flight information exchange D/L Voice

Air traffic management exchange D/L Voice

Information broadcast D/L Voice

Air-to-air surveillance D/L a

No specific requirement identified except current Traffic Information Broadcast by Aircraft (TIBA) procedure.

Although a gradual addition of data communications to the existing VHF voice systems should 

accommodate capacity requirements in the near term to midterm, additional spectrum is required to 

provide enough capacity to satisfy a growing demand for data communications in the far term. An 

AeroMACS built to augment VHF voice and data communications systems already in place, including 
NASA/CR—2010-216324 22

those implemented as part of Data Comm, would increase overall communications system capacity, thus 

relieving congestion and allowing for the introduction of additional services. 

3.3.1.2 Potential Benefits of New Airport Surface Ground-to-Ground Communications Systems

The benefits of a new broadband and networked airport surface G/G communications system are 

similar to those enabled by improved A/G communications in that common data can readily be provided 

to the flight planners and the flight deck. Current NAS modernization and the future NextGen air traffic 

system will increase the demands for CNS information sharing and standardization among stakeholders. 

An AeroMACS could provide the following benefits:

• Standardized ATM information (e.g., surveillance and weather information) provided to the 

ANSP, flight deck, and aircraft operators9

• Information sharing among security stakeholders, facilitating collaboration, risk management, and 

decision making

• Reliable and secure integration of voice, video, and data at all airport surface locations

• System Wide Information Management (SWIM) networked integration of data sources and users

• Flexible, expandable, and affordable delivery of needed information and services, independent of 

user physical location

• Reduced VHF spectrum congestion 

3.3.2 Operational Shortfalls Addressed by Data Comm

The FAA intends for Data Comm to significantly mitigate the safety, capacity, efficiency, and 

productivity shortfalls described in Table 3. It is anticipated that Data Comm will support the following 

improvements in airspace use and capacity (Ref. 39):

• Improved airspace use and capacity

• A more efficient A/G information and clearances exchange mechanism

• An additional means of communication between flight crews and controllers

• Reduced congestion on the voice channels

• Reduced operational errors and flight crew deviations resulting from misunderstood clearances 

and read-back errors

• Trajectory-based operations

• Reduced controller and flight crew workload 

 9

G/G communications would provide connectivity between weather and surveillance sensors and associated network 

equipment, while an A/G link would provide the end product (e.g., weather or surveillance data) to the aircraft. 
NASA/CR—2010-216324 23

Data Comm is planned to be implemented in three segments (Ref. 40; see Figure 11):

• The first segment will facilitate data communications deployment and introduce initial 4–D 

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.

Figure 11.—Operational capabilities of Data Comm (Ref. 41). Acronyms are defined in Appendix A.

An AeroMACS implementation in the United States might follow or overlap Segment 2 (VDL 

Mode 2 implementation) and enable additional services and operational capabilities not covered by VDL 

Mode 2 for Data Comm. Figure 11 depicts the planned capabilities for Data Comm and, for comparison, 

the European planned deployment of data communications capabilities. Those operational capabilities and 

the associated services shown in the figure for Segment 3, for example, the services needed to provide 

widespread 4–D agreements (on the airport surface), might benefit from a higher performance technology 

implementation like AeroMACS. In addition to potentially augmenting the critical data communications 

services provided by VDL Mode 2 for Data Comm, AeroMACS could enable new noncritical services.

3.3.3 Description of Desired Changes

3.3.3.1 Desired Changes for Air-to-Ground Air Traffic Control Communications Systems

Data Comm will provide data communications as an enhancement to and potential replacement of 

A/G voice communications as the primary A/G link in an ATC operational environment. This additional 

mode of communications will contribute to improvements in airspace use and capacity. An AeroMACS 

system could further reduce congestion on VHF voice channels and increase A/G communications 

capacity on the airport surface by offering spectrum for additional services not offered by Data Comm.
NASA/CR—2010-216324 24

With Data Comm and AeroMACS, the overall A/G information exchange could become more dynamic 

and efficient, potentially reducing operational errors and improving safety.

For airport surface A/G ATC communications, AeroMACS is not proposed to replace any current 

systems or services; rather, it is proposed to augment them. Furthermore, it is assumed that the critical 

services proposed for implementation by Data Comm as an addition and/or replacement of voice 

communication will be in place by the time AeroMACS is implemented.

The proposed AeroMACS is being designed to limit interference to the existing services and operations in 

the C-band. No operational changes are expected for C-band incumbent systems.

3.3.3.2 Desired Changes for Airport Surface Ground-to-Ground Communications Systems

The desired changes for G/G communications have many similarities to the changes desired for A/G 

communications by contributing to improvements in airspace use and capacity. Deployment of 

AeroMACS for G/G information exchange would augment and/or replace existing airport surface G/G 

communications systems by providing more flexible data exchange—new communications nodes could 

be added much more quickly and at significantly reduced costs in comparison to changes to the current 

cabled systems. Communications would become more dynamic and efficient, potentially reducing 

operational errors and improving safety. 

3.3.4 Change Priorities and Roadmaps

Figure 12 demonstrates how the C-band system development fits into the FCS proposed 

communications evolutional roadmap for European and U.S. ATM (as envisioned in 2007). 

Figure 12.—Evolution overview of aeronautical mobile communications (Ref. 42; note that this schedule is subject to 

change). Acronyms are defined in Appendix A.
NASA/CR—2010-216324 25

Figure 13 depicts the proposed C-band (and L-band) communications systems far-term strategy as 

part of the NAS Enterprise Architecture Communication Infrastructure Roadmap.

Figure 13.—Federal Aviation Administration communications roadmap (Ref. 43). Acronyms are defined in Appendix A.

3.3.5 Assumptions and Constraints for AeroMACS

Assumptions and constraints for this document follow:

• The 5091- to 5150-MHz spectrum allocation provisioned for AeroMACS at the World 

Radiocommunications Conference (WRC–07) is only for use on the airport surface. This 

allocation is within the AM(R)S band. Therefore, AeroMACS applications are constrained to 

mobile applications on the airport surface. This is interpreted to include communications for 

nonmobile (i.e., fixed) applications that support the safety and regularity of flight.

• The proposed AeroMACS is assumed to provide an increase in overall A/G communications 

systems capacity by utilizing the new spectrum (i.e., not VHF).

• As mentioned earlier, the scope of this ConUse and requirements document includes airport 

surface A/G ATC communications and G/G communications.

• AeroMACS will be designed specifically for data communication. 

• As noted earlier, this document assumes that the data communications system developed as part 

of Data Comm will precede an AeroMACS implementation and deployment. 
NASA/CR—2010-216324 26

• Although some critical services could be supported, AeroMACS systems will also target 

noncritical services, such as weather advisory and aeronautical information services implemented 

as part of an Airborne SWIM program. 

• AeroMACS is to be designed and implemented in a manner that will not disrupt other existing 

services operating in the C-band. Additional interference research and testing will determine if 

any operational constraints are to be imposed, such as limiting the number of users, the time of 

the day, duration, and other parameters.

The economic feasibility of AeroMACS systems may be evaluated as part of Phase II of Task 7. 

3.4 Proposed AeroMACS Systems

3.4.1 Objectives and Scope

Consistent with the need to overcome the specific current communications system problems and 

shortfalls discussed earlier, the two primary general drivers for a future radio system are (1) “to provide 

an appropriate communications infrastructure to support future air traffic growth” and (2) “to provide a 

consistent global solution to support the goal of seamless air traffic management” (Ref. 44). Some FAA 

objectives defined in the FAA’s NextGen portfolio are based on the requirement to support future air 

traffic growth. AeroMACS will be designed and developed to help meet those objectives in part by 

expanding the data communications capacity in the airport surface domain. Global harmonization is being 

ensured by developing the proposed AeroMACS component of the FRS as a collaborative effort of the 

U.S. and European partners.
NASA/CR—2010-216324 27

3.4.1.1 AeroMACS as Part of the Next Generation Air Transportation System

Figure 14 illustrates the proposed NextGen operational view 1 (OV−1) in 2025, listing six of the 

seven solution sets of the FAA’s NextGen portfolio.10 AeroMACS could fulfill part of the proposed 

NextGen vision by supporting implementation of the following solution sets:

• Initiate trajectory-based operations

• Increase arrivals and departures at high-density airports

• Improve collaborative ATM

Figure 14.—Next Generation Air Transportation System (NextGen) operational view in 2025 (Ref. 45). Acronyms are 

defined in Appendix A.

 10The seventh solution set, not shown in the figure, is “safety, security, and environment.”
NASA/CR—2010-216324 28

The following three subsections briefly describe the specific operational improvements (OIs) that 

could be enabled by AeroMACS for these three solution sets.11

Initiate trajectory-based operations (excerpts from Ref. 46)

OI 101103—Provide Interactive Flight Planning From Anywhere: Flight planning activities are 

accomplished from the flight deck as readily as any location. Airborne and ground automation 

provide the capability to exchange flight planning information and negotiate flight trajectory contract 

amendments in near real-time.

OI 104121—Automated Negotiation/Separation Management: Trajectory management is 

enhanced by separation management automation that negotiates with properly equipped aircraft and 

adjusts individual aircraft Four-Dimensional Trajectories (4DTs) to provide efficient trajectories, 

manage complexity, and ensure separation assurance.

OI 104126—Trajectory-Based Management—Gate-To-Gate: All aircraft operating in high 

density airspace are managed by Four Dimensional Trajectory (4DT) in En Route climb, cruise, 

descent, and airport surface phases of flight to dramatically reduce the uncertainty of an aircraft's 

future flight path in terms of predicted spatial position (latitude, longitude, and altitude) and times 

along points in its path.

Integrating separation assurance and traffic management time constraints (e.g., runway times of 

arrival, gate times of arrival), this end state of 4DTbased capability calculates and negotiates 4DTs, 

allows tactical adjustment of individual aircraft trajectories within a flow, resolves conflicts, and 

performs conformance monitoring by Air Navigation Service Providers (ANSPs) to more efficiently 

manage complexity, ensure separation assurance, and enhance capacity and throughput of highdensity airspace to accommodate increased levels of demand. This will be enabled by the trajectory 

exchange through data communications, as well as many new surface automation and 3D (x, y, and 

time) trajectory operations. 

Increase arrivals and departures at high-density airports (excerpts from Ref. 47)

OI 102153—Limited Simultaneous Runway Occupancy: Runway capacity is increased through 

the allowance of more than one aircraft on the runway, at a given time, for specific situations.

OI 104117— Improved Management of Arrival/Surface/Departure Flow Operations: This 

Operational Improvement (OI) integrates advanced Arrival/Departure flow management with 

advanced Surface operation functions to improve overall airport capacity and efficiency. Air 

Navigation Service Provider (ANSP) automation uses arrival and departure-scheduling tools and four 

dimensional trajectory (4DT) agreements to flow traffic at high-density airports. Automation 

incorporates Traffic Management Initiatives (TMIs), current conditions (e.g., weather), airport 

configuration, user provided gate assignments, requested runway, aircraft wake characteristics, and 

flight performance profiles. ANSP, flight planners, and airport operators monitor airport operational 

efficiency and make collaborative real-time adjustments to schedules and sequencing of aircraft to 

optimize throughput.

OI 104125—Integrated Arrival/Departure and Surface Traffic Management for Metroplex: 

Metroplex traffic flow is more efficiently managed through arrival/departure and surface scheduling 

automation, integrated with all available constraint information, including weather impacts, 

optimizing traffic throughput by eliminating potential gaps in unused capacity, thereby increasing 

regional/metroplex capacity. 

Data communications is a key element of super-density operations, allowing the Air Navigation 

Service Provider (ANSP) to maximize access for all traffic, while adhering to the principle of giving 

advantage to those aircraft with advanced capabilities.

 11These descriptions are extracted from the NAS Enterprise Architecture web portal (https://nasea.faa.gov). 
NASA/CR—2010-216324 29

OI 104206—Full Surface Traffic Management with Conformance Monitoring: Efficiency and 

safety of surface traffic management is increased, with corresponding reduction in environmental 

impacts, through the use of improved surveillance, automation, on-board displays, and data link of 

taxi instructions. 

Equipped aircraft and ground vehicles provide surface traffic information in real-time to all 

parties of interest.

OI 104208—Enhanced Departure Flow Operations: Enhancements to surface traffic 

management incorporate taxi instructions, surface movement information, and aircraft wake category 

to enhance departure flow operations. Clearances are developed, delivered, monitored and provided in 

graphical or textual format that is used by the flight deck display to support taxi, takeoff and 

departure flows in all conditions. At high-density airports clearances and amendments, requests, NAS 

status, airport flows, weather information, and surface movement instructions are issued via data 

communications. 

Surface decision support and management systems use ground and airborne surveillance and a 

scheduling and sequencing system to develop and maintain schedules of departing aircraft within a 

defined time horizon. Information is sent to participating aircraft and the air navigation service 

provider via data communications or voice and adjustments are made to push back times, taxi 

instructions, etc. to maintain schedules.

OI 104209—Initial Surface Traffic Management: Departures are sequenced and staged to 

maintain throughput. ANSP automation uses departure-scheduling tools to flow surface traffic at 

high-density airports. Automation provides surface sequencing and staging lists for departures and 

average departure delay (current and predicted).

ANSP automated decision support tools integrate surveillance data. This includes weather data, 

departure queues, aircraft flight plan information, runway configuration, expected departure times, 

and gate assignments. 

Improve collaborative air traffic management (excerpts from Ref. 48) 

OI 101102—Provide Full Flight Plan Constraint Evaluation with Feedback: Timely and 

accurate national airspace system (NAS) information enables users to plan and fly routings that meet 

their objectives. Constraint information that impacts the proposed route of flight is incorporated into 

air navigation service provider (ANSP) automation, and is available to users. Examples of constraint 

information include special use airspace status, SIGMETS [data link significant meteorological 

information], infrastructure outages, and significant congestion events.

OI 103305—On-Demand NAS Information: National Airspace System (NAS) and aeronautical 

information will be available to users on demand. NAS and aeronautical information is consistent 

across applications and locations, and available to authorized subscribers and equipped aircraft. 

Proprietary and security sensitive information is not shared with unauthorized agencies/individuals. 

OI 105207—Full Collaborative Decision Making: Timely, effective, and informed decisionmaking based on shared situational awareness is achieved through advanced communication and 

information sharing systems. 

Stakeholder decisions are supported through access to an information exchange environment and 

a transformed collaborative decision making process that allows wide access to information by all 

parties (whether airborne or on the ground), while recognizing privacy and security constraints. 

Decision-makers request information when needed, publish information as appropriate, and use 

subscription services to automatically receive desired information through the net-centric 

infrastructure service.
NASA/CR—2010-216324 30

3.4.1.2 AeroMACS Operational Environment for Next Generation Air Transportation System

Along with the “as-is” SV–2 views of the NAS developed by the FAA Air Traffic Organization 

(ATO) planning organization, such as shown in Figure 9, were a series of separate “to-be” views for 

2025. Figure 15 presents an SV–2 2025 rollup data flow view for the proposed NAS. The figure was 

annotated with labels and dashed red boxes to highlight the five NAS information flow areas that may be 

enabled by AeroMACS:

• Surveillance

• Weather

• Flight information

• Command and control

• Aeronautical information
Figure 15.—System view 2 (SV–2) Next Generation Air Transportation System (NextGen) 2025 rollup data flow view (Ref. 49). 

defined in Appendix A

Data Flows:

.

• Flight Information

• Command and Control

• Aeronautical

• Weather Data Flows

• Surveillance Data Flows

• Surveillance Data Flows

NASA/CR—2010-216324 31
NASA/CR—2010-216324 32

3.4.2 Proposed System Description: AeroMACS

As noted earlier, the FCS technology assessment recommended a system based on the IEEE 802.16 

standard and its extension, IEEE 802.16e-2005 (Refs. 6 and 18) implemented at the aeronautical C-band 

as the preferred technology to implement a future airport surface communications system (i.e., 

AeroMACS). The waveforms described in IEEE 802.16e standard are very flexible and scalable to handle 

a wide range of communication services. The Worldwide Interoperability Microwave Access (WiMAX) 

Forum, an industry consortium that promotes the use of wideband wireless systems based on a carefully 

selected and agreed upon subset of the IEEE 802.16 standards, has developed several profile applications 

that will be supported by device manufacturers. A new standards profile for airport applications is 

currently being developed within an RTCA special committee (SC–223) to operate in the C-band (5091 to 

5150 MHz) and make use of the scaling properties inherent in IEEE 802.16e standard.12 IEEE 802.16e 

standard defines the waveform capabilities needed for various uses. It has considerable flexibility at the 

physical and Media Access Control (MAC) layers that will lead to a number of tradeoffs in adapting this 

type of waveform to the needs of an AeroMACS. Some of the tradeoffs to be considered follow:

• Bandwidth (capacity) versus number of base stations (BSs)

• Allocation methodology for mapping channel assignments 

• Number of power control levels

• Allocation of capacity for voice circuits 

The proposed AeroMACS could provide supplemental means for the ATC communications required 

by the operating rules (e.g., VHF voice communications) in continental airspace (albeit on the airport 

surface) and will adhere to the data link characteristics noted in the “Safety and Performance 

Requirements Standard for Air Traffic Data Link Services in Continental Airspace (Continental SPR 

Standard)” (Ref. 7). 

3.4.3 AeroMACS Frequency and Technology: Environment, Requirements, and Limitations

The following observations regarding airport surface communications and the suitability of the 

aeronautical C-band resulted from the “Future Aeronautical Communication Infrastructure Technology 

Investigation” (Ref. 24):

• The propagation conditions to some extent determine which band is able to support which types 

of volume. The airport surface is best served by short range systems operating in the C-band 

because of the attenuation conditions at this frequency.

• There is capacity that is not utilized in the aeronautical C-band (5000 to 5010 MHz, 5010 to 

5030 MHz, and/or 5091 to 5150 MHz). Because of severe path-loss problems, this band is most 

applicable to the airport surface where the distances are relatively short. Some concepts for 

surface management communications require substantially higher data rates than are needed in 

other airspace domains and may warrant a specific technology solution.

• For the aeronautical C-band (5000 to 5010 MHz, 5010 to 5030 MHz, and/or 5091 to 5150 MHz), 

IEEE 802.16e is extremely well matched to the aeronautical surface in terms of capability and 

performance.

o This technology is designed to work in this band and initial IEEE 802.16e performance 

evaluations in the modeled aeronautical microwave-landing-system band channel show 

favorable results

o Private service providers have shown interest in the IEEE 802.xx family of wireless protocols 

(favorable business case that may be driven by factors beyond ATS and AOC communications, and may involve private service providers, including airport authorities)

 12Specifically, IEEE 802.16–2009 will provide the basis of ongoing the profile selection. 
NASA/CR—2010-216324 33

These conclusions help to drive the AeroMACS ConUse and system requirements presented in this 

document.

3.4.4 User Impact

Users of the system will include service providers and airspace users (on the airport surface) of A/G 

and G/G communications:

• Safety and regularity of flight—addressed by air traffic controllers and NAS specialists on the 

ground and flight crews in aircraft at the airport 

• Commercial data transfer related to airline operations and provisions of services to passengers 

The introduction of AeroMACS is expected to increase communications system capacity, thus 

allowing the addition of new services and expanding the user base. Figure 16 illustrates the effect of the 

new system on the user base.

It should be noted that the relationship between the capacity demand and changes in the user base can 

be viewed as a repeating cycle of events. The proposed introduction of an AeroMACS will increase the 

overall capacity of the system and open up opportunities for addition of data services not provided under 

Data Comm. Many of those, most notably services associated with the Airborne SWIM Program, would 

provide for wider system use. Not only more users would be expected to take advantage of the new data 

communications capabilities, the types of users allowed to participate would increase as well. 

As more data services are introduced and become part of day-to-day operations, the demand for 

additional services, and therefore capacity, is expected to grow. The availability of a new frequency band, 

such as C-band, in addition to the VHF frequencies supporting the existing voice and data communications services, will alleviate long-term capacity problems.

Figure 16.—Communication system capacity demand 

and user base changes. 

The expanded use of advanced technologies in general and of AeroMACS in particular, along with 

increased capacity, is expected to improve aviation safety and enhance operational efficiency for NAS 

users. The continued migration from a NAS based on a ground infrastructure and voice communication to 

a system that encompasses both ground and airborne components and utilizes the exchange of digital data 

as the primary type of communication, will (Ref. 50)

Introduction 

of new 

services

Wider user 

base

Change in 

type and 

number of 

users 

Need for 

more data 

services

Increased 

system 

capacity
NASA/CR—2010-216324 34

...support the human in doing what they do best—choosing alternatives and making decisions, while 

the technology accomplishes what it can do best—the acquisition, compilation, evaluation and 

exchange of information. 

NextGen communications systems will enable users to play a more active role in each of the NAS 

service areas: 

• NAS management (strategic flow and resource management): SWIM capability will enable 

stakeholders’ access to relevant information. Users will become key participants in the planning 

of traffic flow management and will utilize a comprehensive information exchange process to 

improve flight operations planning according to capacity and traffic conditions to minimize 

congestion and delays. 

• Flight planning and emergency alerting services: Users will have interactive flight planning 

capabilities with an immediate access to real-time data. User-preferred routing will become 

available to properly equipped aircraft for both domestic and international flights. 

• Surface operations: Increased data-exchange capabilities will provide more users at more airports 

with flight clearances, airport information, positions of other aircraft, taxi routes, and weather 

conditions (current, forecast, and hazardous). Users will have improved real-time planning with 

continuous update of the flight profile. 

3.4.5 Operational Policies and Constraints

Operational aspects of aeronautical communications are changing with an increased emphasis on 

safety and cost reduction achieved via increased automation and efficiency, fewer delays, and other 

improvements. 

General issues such as cost, spectrum availability, technology choice, and standards development, as 

well as the logistics of system rollout will all influence operational policies and constraints. 

The NextGen ConOps details operational policy issues that would affect the NextGen system 

(Ref. 51). To support the proposed AeroMACS development and implementation, policies might need to 

be developed and/or revised in the following areas: 

• International and domestic regulations

• Safety management standards

• Processes to streamline certification and reduce costs of aircraft and ground equipment

• Privacy and liability legal concerns related to information sharing, 

• Communications priority and congestion relief (e.g., market-driven versus aircraft type)

• Government role versus private sector role

• Financing and maintenance responsibilities

3.5 AeroMACS ConUse

3.5.1 RTCA National Airspace System Concepts of Operation Guidance

As noted in Section 2.0, the definitions of the AeroMACS ConUse were based on guidance and 

information provided by several higher order ConOps. A key NAS ConOps source driving the 

AeroMACS ConUse was RTCA’s NAS ConOps (Ref. 13). Appendix B presents a comprehensive listing 

derived from Reference 13 of future communications concepts applicable to airport surface operations to 

enable the transfer of the following NAS information types:

• Surveillance

• Weather

• Flight planning
NASA/CR—2010-216324 35

• Aeronautical information

• Resource management

3.5.2 Data Comm Operational Scenarios

Operational scenarios can illustrate how proposed system capabilities could be used in an operational 

environment. The scenarios can demonstrate how the services offered by the new communications system 

could help to

• Minimize operational errors, including those resulting from misunderstood instructions and readback errors

• Improve efficiency 

• Provide further automation of traffic control

• Enable more decisions to be made off the ground

The Data Comm FPR (Ref. 5) lists operational scenarios envisioned to be enabled by the data 

communications system. In general, these scenarios would also be applicable to an AeroMACS 

implementation, especially those presented for Segment 2 and beyond, during which Data Comm VDL 

Mode 2 operational capabilities could be augmented by AeroMACS. Operational scenarios from 

Segments 2 and 3 of Data Comm that are applicable to the airport surface environment follow (Ref. 52).

• Departure Airport (Tower) Scenarios

o (S2,3) Proposed routes including standard routing through traditional airspace, and 4-D 

trajectory based routing for transit through High Performance Airspace are developed and 

loaded into the flight management system via A/G data communications for aircrew review.

o (S2,3) 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.

o (S2,3) 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.

o (S2,3) 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 not only to reroute aircraft, but also to 

reorder aircraft. 

o (S2,3) Enhanced capabilities and increased access to surface data and flight status provide 

traffic management automation with information about the flight’s location, taxi sequence, 

and the departure queues. As a result, the TFM [traffic flow management] automation 

provides departure clearance revisions at an operationally appropriate amount of time in 

advance of the departure.

o (S2,3) Once the aircraft has been cleared for takeoff via voice, data communications manages 

the data communications eligibility transfer to the TRACON position and surface ATC data 

communications cease.

o (S3) In advance of a planned departure, users now file 4D trajectory-based flight plans for 

operations in HPA [high-power amplifier]. Users and air traffic service providers [ATSPs]

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.
NASA/CR—2010-216324 36

• Arrival Airport (Tower) Scenarios

o (S2,3) 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.

o (S3) After the aircraft lands, the tower runway controller confirms the previously provided 

runway exit and directs the flight crew to contact the ground controller. 

3.5.3 Proposed Services for AeroMACS

3.5.3.1 Air Traffic Services

Reference 9 classifies all of the COCR ATS data services as safety critical. It further identifies 

services that are not planned to be implemented by Data Comm through Segment 3 and identifies them as 

possible candidates for implementation via C-band and/or L-band. It must be stressed that both C-band 

and L-band systems are being developed for the future communications infrastructure to accommodate 

the safety and regularity of flight services. These are designed to operate over a protected spectrum for 

aviation, so any COCR ATS could be allowed to be implemented via one or the other of these links (as 

appropriate).

As described earlier, this document focuses on the COCR ATS data services that are not expected to 

be provided by Data Comm through Segment 2, which are proposed as candidates for AeroMACS:

• Flight information services

o Data link operational terminal information service (D–OTIS) 

o Data link surface information and guidance (D–SIG) 

o Flight plan consistency (FLIPCY) 

o System access parameters 

o Pilot preferences downlink (PPD)

• Weather advisory service

o Data link significant meteorological information (D–SIGMET)

• Emergency information service

o Urgent contact (URCO), if in conjunction with other more routine services

Additional data services that may be provided via AeroMACS may be identified as NextGen and 

Single European Sky ATM Research (SESAR) progress.

3.5.3.2 Airborne System Wide Information Management (SWIM) Suitable Services

SWIM, an FAA technology program designed to facilitate the sharing of ATM system information 

(airport operational status, weather information, flight data, status of special-use airspace, and NAS 

restrictions), can be implemented via G/G, A/G, and air-to-air (A/A) communications infrastructure 

components. Each of these components would enable efficient data exchange between authorized users 

in the respective domain. An AeroMACS could provide means for the A/G data transfer on the 

airport surface.

An implementation of AeroMACS would facilitate meeting the primary objective of the SWIM 

Program: that is, to improve the FAA’s ability to manage the efficient flow of information through the 

NAS. When used to enable Airborne SWIM capabilities, an AeroMACS could be designed to ensure that 

its use provides the following desired SWIM features:

• Reduced costs for NAS users to acquire NAS data and exchange information

• Increased shared situational awareness among the NAS user community

• FAA compliant secure data exchange among the NAS user community
NASA/CR—2010-216324 37

Figure 17 shows how Airborne SWIM (with the communication links potentially provided via 

AeroMACS) fits in the overall FAA A/G communications plan and illustrates interactions of SWIM 

elements with the other NextGen programs, such as automatic dependent surveillance—broadcast 

(ADS–B) and Data Comm. 

Figure 17.—Airborne System Wide Information Management (SWIM) and other Next Generation Air 

Transportation System (NextGen) Programs (Ref. 53). Acronyms are defined in Appendix A.

As shown in the figure, AeroMACS links will have lower safety targets when used to provide SWIMrelated services compared with the other data communications services. For example, Figure 17 shows a 

required level of C3 (medium risk) for Data Comm and D/E 4/5 (low risk) for SWIM (see Ref. 54 for 

more information). Although it is anticipated that some Airborne SWIM services could be provided over 

the commercial (i.e., unprotected (non-AM(R)S)) spectrum—as shown in the figure—it is likely that 

other Airborne SWIM services could make use of protected spectrum to support regularity of flight.13

These later services would be suitable targets for an AeroMACS implementation. 

As part of SWIM, AeroMACS would enable the exchange of information between diverse users 

adopting a service-oriented architecture. Services would be offered from individual providers as well as 

centralized providers. 

 13For example, current aeronautical (airline) operational control (AOC) communications is conducted over the 

AM(R)S spectrum to support regularity-of-flight operations rather than safety-of-flight operations. 
NASA/CR—2010-216324 38

Figure 18 shows the A/G and G/G SWIM elements. It depicts Airborne SWIM (potentially provided 

over AeroMACS) as a facilitator of NAS data exchange, such as surveillance, flight, aeronautical, meteorological, air traffic flow and capacity management (ATFCM) scenario, and demand and capacity data.

Figure 18.—Air-to-ground data link management and aircraft participation in System Wide Information 

Management (SWIM) (slightly modified from Ref. 55). Copyright Thales Air Systems; used with 

permission. Acronyms are defined in Appendix A.

These mostly weather advisory and aeronautical information services include

• Aviation Digital Data Service (ADDS)

• AWOS Data Acquisition Service (ADAS) 

• Expanded Terminal and Tower Data Service

• General Information Message Distribution Service

• Information Display System (IDS) Data Service

• NextGen Network Enabled Weather (NNEW) service14

• NOTAM distribution service

• TMA flight data service

• Weather and Radar Processor (WARP)/Weather Information Network Server (WINS) Next 

Generation Radar (NEXRAD) service

 14It is possible that the information provided through the NNEW service could range from the advisory for routine 

forecasts through safety critical information for certain hazardous weather warning messages, which might limit the 

extent to which this might be provided over commercial links. This requires further investigation.
NASA/CR—2010-216324 39

Figure 19 illustrates the introduction of SWIM services over time. Implementation of the proposed 

AeroMACS is likely to overlap with SWIM Segments 3 and 4 when Airborne SWIM is introduced.

Figure 19.—System Wide Information Management (SWIM) execution by segments (Ref. 53). Acronyms are 

defined in Appendix A.

3.5.4 Next Generation Air Transportation System Communications Operational Concepts

Figure 20 shows a typical flight profile and the ATS functions supporting users in each domain.

Figure 20.—Typical National Airspace System (NAS) flight profile and air traffic services (ATS) functions (Ref. 5).
NASA/CR—2010-216324 40

Table 5 lists the operational scenarios and concepts envisioned for the midterm of the NextGen 

airport surface flight phase shown in Figure 20. Although most, if not all, of these concepts are currently 

envisioned for Data Comm, these are technology independent and, thus, equally valid for an AeroMACS 

implementation.

TABLE 5.—NEXT GENERATION AIR TRANSPORTATION SYSTEM (NextGen) MIDTERM OPERATIONAL 

CONCEPTS FOR THE AIRPORT SURFACE

Phase of flight NextGen midterm communications operational concept (from Ref. 8)

Flight planning Access to flight planning information will be available to authorized users via a secure network 

and will include a publish/subscribe capability so that users can receive automatic updates when 

conditions change along the proposed flight path.

Push back, taxi, and 

departure

As the time for the flight approaches, the final flight path agreement will be delivered as a data 

message to pilots who access the agreement before beginning the flight.

3.5.5 AeroMACS Operational Services and Scenarios Derived from the Communications 

Operating Concept and Requirements

3.5.5.1 Potential AeroMACS Operational Services Derived from the Communications 

Operating Concept and Requirements

Operational concepts also can be defined according to the different geographic flight domains. 

Table 6 illustrates the potential operational services suitable for implementation via AeroMACS for the 

airport surface based on the COCR services previously identified as potential applications (Ref. 9).

TABLE 6.—USE OF THE PROPOSED AeroMACS IN THE AIRPORT FLIGHT DOMAIN

[Acronyms are defined in Appendix A.]

Operational services Airport domain phases

Predeparture 

airport domain

Departure taxi

airport domain

Arrival airport 

domain

Arrival taxi 

airport domain

Flight information services D–OTIS

D–RVR

D–SIG

D–SIGMET

D–OTIS

D–RVR

D–SIG

D–SIGMET

D–OTIS

D–RVR

D–SIG

D–RVR

D–SIG

Flight position, flight intent, and flight 

preferences services

PPD

FLIPCY

WAKE

PPD

FLIPCY

WAKE

PPD

FLIPCY

WAKE

PPD

FLIPCY

WAKE

Emergency information service URCO URCO URCO URCO

Services suitable for Airborne SWIM 

(generally weather advisory and 

aeronautical information services)

ADDS, ADAS, Expanded Terminal and Tower Data Service, General Information 

Message Distribution Service, IDS Data Service, NNEW service,a NOTAM 

distribution service, TMA Flight Data Service, WARP/WINS NEXRAD service a

It is possible that the information provided through the NNEW service could range from advisories for routine forecasts 

though safety-critical transmission of certain hazardous weather warning messages, which might limit the extent to which this 

service could be provided over commercial links. This requires furtherer investigation.
NASA/CR—2010-216324 41

Examples of operational messages that could be transmitted over the proposed AeroMACS data link 

in support of the services for the airport surface flight domain are presented in Table 7. The messages are 

grouped according to the information type, as defined by the function identifications (IDs) in Appendix C.

TABLE 7.—EXAMPLE AeroMACS DATA LINK MESSAGES

Information type (including 

corresponding function ID)

Message examples

Transceive air traffic service 

(ATS) to on-ground aircraft 

message

C.1.1.1.2

Contract requesting data

Contract acknowledgements

Operational terminal information service (OTIS) reports, addressed or broadcast 

communications

Operational en route information service (ORIS) reports, addressed or broadcast 

communications

Significant meteorological information (SIGMET) reports, addressed or broadcast 

communications, event basis only

Airport data to be displayed on board (Data Link Surface Information and Guidance, 

D–SIG)

Runway visual range (RVR) information, addressed or broadcast communications

Available alternative routes (dynamic route availability, DYNAV), addressed 

communication

Urgent contact message (URCO), addressed and/or broadcast communications

Transceive on-ground aircraft to 

ATS message

C.1.1.2.2

Requests (i.e., demand, periodic, or event contract) for reports

Contract acknowledgements

Current and periodic position (flight plan consistency, FLIPCY), addressed 

communications

Meteorological data (FLIPCY), addressed communications

Ground speed (FLIPCY), addressed communications

Indicated heading, indicated air speed or match, vertical rate, selected level, and wind 

vector (system access parameters), addressed communications

Broadcast of aircraft wake turbulence (WAKE) characteristics (e.g. aircraft type, weight, 

and flap and speed settings)

Flight limitations (e.g., maximum acceptable flight level) (pilot preferences downlink, 

PPD), addressed communications

Pilot flight preferences (PPD), addressed communications

Flight plan modification requests (e.g., desired route or speed limitations) (PPD),

addressed communications

URCO, addressed and/or broadcast communications
NASA/CR—2010-216324 42

3.5.5.2 AeroMACS Operational Scenarios Derived from the Communications Operating 

Concept and Requirements

Table 8 shows examples of operational scenarios for the proposed AeroMACS according to specific 

services identified earlier (Ref. 9) as proposed AeroMACS applications (services that are not planned to 

be implemented by Data Comm through Segment 2). The scenarios are a subset of those provided in 

COCR Version 2.0.

TABLE 8.—EXAMPLE OPERATIONAL SCENARIOS 

Flight domain Communication scenarios

Pre-departure 

airport domain

• 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 system response provides all 

relevant information for the weather, Automatic Terminal Information Service (ATIS), and field 

conditions, plus the local Notices to Airmen (NOTAMs).

• 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 and guidance (D–SIG) service.

• The flight crew specifies preferences that should be considered by the controllers using the pilot 

preferences downlink (PPD) service.
NASA/CR—2010-216324 43

4.0 AeroMACS System Requirements

4.1 AeroMACS Functional Requirements Development Process

Figure 4 in Section 2.0 presented an overview of the ConUse and system requirements development 

process used for this task. As stated in Section 2.0, a middle-out approach was adopted to identify the 

high-level requirements applicable to AeroMACS. In this approach, the top-down functional requirements 

were derived from the ConUse and the associated functional capabilities. In parallel with that process, a 

bottom-up assessment of existing requirements in relevant documents such as the NAS SR−1000 

(Refs. 10 and 11), the COCR (Ref. 12), and Data Comm performance requirements and their applicability 

to the current needs for AeroMACS was performed. Thus, the top-down approach employs the classic 

“clean-sheet” system engineering process, and the bottom-up approach addresses how AeroMACS fits 

into the existing environment. 

4.1.1 AeroMACS Functional System Requirements—Top-Down Approach

This section presents a top-down determination of functional requirements through (1) a functional 

analysis for generic aeronautical communications systems based on prior work and (2) a functional 

analysis based on the ConUse defined in Section 3.0.

4.1.1.1 Prior Functional Analysis Applicable to AeroMACS 

A functional architecture can be interpreted as a hierarchical arrangement of functions and interfaces 

that represents the complete system from a performance and behavioral perspective (Ref. 1). For its topdown functional analysis, this report leverages prior functional analysis work performed to characterize 

generic aeronautical A/G, G/G, and A/A communications systems: the “National Airspace System 

Communications System Safety Hazard Analysis and Security Threat Analysis” (Ref. 56). Figure 21

depicts the hierarchy at the highest level. Appendix C presents a more complete hierarchical 

decomposition of functions as diagrams and in an outline format derived from this reference document, 

but modified as appropriate for AeroMACS (e.g., A/A functions are deleted). 

Figure 21.—High-level hierarchy of C-band communications system. Acronyms are defined in Appendix A.
NASA/CR—2010-216324 44

4.1.1.2 AeroMACS Concepts-of-Operations-Based Functional Analysis 

AeroMACS could provide a communication link to transfer surveillance and weather information, 

facilitate flight and resource management, enhance CDM, and enable exchange of aeronautical 

information in the future NAS. The tables in Appendix B document the select RTCA NAS ConOps 

(Ref. 13) found to be applicable to the proposed AeroMACS.15

The desired AeroMACS functional capabilities were derived from the identified NAS ConOps 

presented in Appendix B and mapped to (1) the high-level aeronautical A/G and G/G communication

functions described in Section 4.1.1.1 and (2) specific COCR ATS services. Table 9 lists the AeroMACS 

high-level functional capabilities and presents this mapping. This encompasses a top-down approach to 

the development of functional requirements.

TABLE 9.—MAPPING AeroMACS FUNCTIONALITY TO THE NATIONAL AIRSPACE SYSTEM (NAS) CONCEPTS 

OF OPERATION (ConOps)

[Acronyms are defined in Appendix A.]

Desired AeroMACS 

capabilities

NAS ConOps references (Ref. 13) Functional 

hierarchy reference

Communications 

operating concept and 

requirements (COCR) 

air traffic services 

(ATS)

Enable air-to-ground 

(A/G) and ground-toground (G/G) 

communications for 

fixed-to-mobile as well as 

fixed-to-fixed services.

S-1; S-3; S-4;

W-2; W-3; W-8; W-9; W-10; W-12; W-13; 

W-14; W-15;

FM-1; FM-6; FM-8; FM-12; FM-14; FM-15; 

FM 17; FM-23;

A-2; A-6; A-12; A-15

C.1.1.1.2

C.1.1.2.2

C.1.1.4.1

D–OTIS

D–RVR

D–SIG

D–SIGMET

FLIPCY

WAKE

PPD

Support addressed 

communication for 

delivery of information to 

individual and multiple 

users

S-1;

W-10;

FM-6; FM-8

C.1.1.1.2

C.1.1.2.2

C.1.1.4.1

D–OTIS

D–RVR

D–SIG

D–SIGMET

FLIPCY

PPD

Support broadcast 

communication for 

delivery of information to 

multiple users

S-1; S-4;

W-2; W-3; W-12; W-14;

FM-8;

A-12

C.1.1.1.2

C.1.1.2.2

C.1.1.4.1

D–OTIS

D–RVR

D–SIG

D–SIGMET

WAKE

Support delivery of realtime information in a 

timely manner

S-1; S-3;

W-16;

FM-1; FM-2; FM-9; FM-10; FM-12; FM-15; 

FM-18; FM-25; FM-26;

RM-3; RM-7;

A-4; A-7; A-11

D-RVR

D-SIG

D–SIGMET

FLIPCY

WAKE 

PPD

 15Although the RTCA document describes the NAS evolution in terms of three time periods—near (up to 2005), mid 

(2005 through 2010) and far (beyond 2010)—most concepts identified in the document are applicable to the 

proposed AeroMACS, which will necessarily be implemented beyond 2010. 
NASA/CR—2010-216324 45

TABLE 9.—MAPPING AeroMACS FUNCTIONALITY TO THE NATIONAL AIRSPACE SYSTEM (NAS) CONCEPTS 

OF OPERATION (ConOps)

[Acronyms are defined in Appendix A.]

Desired AeroMACS 

capabilities

NAS ConOps references (Ref. 13) Functional 

hierarchy reference

Communications 

operating concept and 

requirements (COCR) 

air traffic services 

(ATS)

Enable demand, periodic, 

and event communication

S-1;

W-12

All services 

Accommodate a wide 

range of data types (e.g.,

surveillance reports, 

weather raw data and 

products, flight profiles, 

etc.) to support common 

situational awareness

S-3;

W-2; W-3;

A-1; A-5

All services

Support multiple qualityof-service (QoS) 

provisions

All services

Support authentication of 

users and controlled 

access to NAS 

information (security)

W-1 All services

Provide support of both 

Federal Aviation 

Administration (FAA) 

and non-FAA ground 

users

S-1;

FM-12; FM-14; FM-20;

A-11

Avoid single points of 

failure

RM-6 All services

Provide a scalable 

solution

All services

Provide standards-based 

solution

All services
NASA/CR—2010-216324 46

High-level AeroMACS functional requirements can then be constructed from the functional 

capabilities in a straightforward manner, as shown in Table 10.

TABLE 10.—AeroMACS HIGH-LEVEL FUNCTIONAL REQUIREMENTS

System functions AeroMACS high-level functional requirements

Enable air-to-ground (A/G) and ground-toground (G/G) communications for fixed-tomobile as well as fixed-to-fixed services.The system shall enable ground-to-air (G/A) communication for fixed-tomobile users.

The system shall enable G/A communication for mobile-to-mobile users.

The system shall enable A/G communication for fixed-to-mobile users.

The system shall enable A/G communication for mobile-to-mobile users.

Support addressed communication for 

delivery of information to individual and 

multiple users.

The system shall support addressed communications to individual users.

The system shall support addressed communications to multiple users.

Support broadcast communication for 

delivery of information to multiple users.

The system shall support broadcast communication to multiple users.

Support delivery of real-time information in a 

timely manner.

The system shall support delivery of real-time information in a timely 

manner.

Enable demand, periodic, and event 

communication.

The system shall enable demand communication.

The system shall enable periodic communication.

The system shall enable event communication.

Accommodate a wide range of data types 

(e.g., surveillance reports, weather raw data 

and products, flight profiles, etc.) to support 

common situational awareness.

The system shall accommodate a wide range of data types (e.g., surveillance 

reports, weather raw data and products, flight profiles, etc.) to support 

common situational awareness.

Support multiple QoS provisions. (This functional capability points toward performance requirements.)

Support authentication of users and 

controlled access to National Airspace 

System (NAS) information (security).

The system shall support authentication of users (security).

The system shall support controlled access to NAS information (security).

Provide support of both Federal Aviation 

Administration (FAA) and non-FAA ground 

users.a

The system shall support FAA ground users.

The system shall support non-FAA ground users.

Avoid single points of failure. The system shall avoid single points of failure.

Provide a scalable solution. The system shall provide a scalable solution.

Provide a standards-based solution. The system shall provide standards-based solution. a

To support increasing collaboration among NAS users, the proposed system shall accommodate a wide range of NAS users 

by accepting NAS data from NAS data sources, both internal and external to the FAA. Users may include aircraft, airline 

operation centers, service providers, FAA users, and other Government agencies. 
NASA/CR—2010-216324 47

4.1.2 AeroMACS Functional System Requirements—Bottom-Up Approach

4.1.2.1 National-Airspace-System-Level Functional Requirements for AeroMACS Services

Functions identified in the NAS SR−1000 (Ref. 10)—plan flights, monitor flights, control traffic, 

support flight operations, monitor NAS operations, and plan NAS usage—cut across all the AeroMACS 

capabilities shown in Table 9. Table 2 in Section 3.2.2.1 mapped NAS-level A/G communication 

functions to NAS service capabilities, highlighting services potentially enabled by A/G voice 

communication. As expected, the NAS functions potentially enabled through an AeroMACS go well 

beyond those shown in Table 2. Consequently, Table 11 highlights the capabilities of the proposed 

AeroMACS enabling NAS functionality specified in the NAS SR−1000. The colored boxes denote 

services potentially enabled by A/G communication, with the blue boxes representing voice and/or data 

communication and the green boxes representing data communication only.

TABLE 11.—MAPPING RELEVANT NATIONAL AIRSPACE SYSTEM (NAS) 

COMMUNICATIONS FUNCTIONS TO NAS SERVICE CAPABILITIES (REF. 31)
NASA/CR—2010-216324 48

In Table 12, functional requirements applicable for an AeroMACS operating on the airport surface 

were extracted from the NAS requirements specified in the NAS SR−1000. Unless specifically stated 

otherwise, these could apply to A/G or G/G communications, for fixed-to-mobile or fixed-to-fixed 

applications.

TABLE 12.—NATIONAL AIRSPACE SYSTEM (NAS) FUNCTIONS

[Numbers in the table correspond to communication requirements in the NAS SR–1000 (Ref. 10).]

NAS functions Communication requirements

Plan flights Evaluate flight 

conditions 

The NAS shall disseminate the status of special use airspace to users. (08760)

The NAS shall disseminate weather information to users to support flight planning.

(27150)

The NAS shall disseminate aeronautical information to users to support flight planning. 

(27160)

Manage flight plans The NAS shall disseminate flight information to users. (00010)

The NAS shall disseminate flight plan information to users via external data 

interfaces.(00410)

The NAS shall disseminate flight plan information to users via air-ground data 

communications. (00970)

The NAS shall disseminate flight data summaries to users. (00070)

The NAS shall disseminate flight plans to users. (02160)

The NAS shall disseminate flight plan clearances to users. (02900)

Monitor 

flights

Collect aircraft 

navigation 

information (collect 

dependent 

surveillance 

information)

The NAS shall retrieve actual flight information. (10000)

The NAS shall acquire actual flight information from aircraft outside of independent

surveillance coverage. (03320)

Monitor aircraft 

status

The NAS shall respond to emergency transmission received via radio communications. 

(12600) 

The NAS shall respond to emergency transmissions received via data link. (12620)

The NAS shall disseminate essential information on missing aircraft. (13130)

Report 

(disseminate) 

aircraft status

The NAS shall display position information, to specialists, for aircraft that were detected 

independent of aircraft equipage in qualifying aerodromes. (24530)

The NAS shall transmit conflict-free flight path recommendations to expedite resolution 

of emergency situations. (12820)

The NAS shall disseminate aircraft flight information for each controlled aircraft to

specialists. (02720)

The NAS shall disseminate the current location for each participating aircraft to ATCSCC 

[air traffic control system command center] Specialists. (10940)

The NAS shall disseminate the current location for each participating aircraft to Traffic 

Management Coordinators. (10980)

Control 

traffic

Address active 

aircraft conflicts

The NAS shall disseminate recommended collision avoidance maneuvers to users. 

(03690)

Control aircraft The NAS shall disseminate aeronautical information to users via air-ground data 

communications. (07440)

Coordinate traffic 

control distribution

The NAS shall acquire pilot reports (PIREP). (05530)

The NAS shall disseminate weather advisories via direct specialist to pilot 

communications. (09290)
NASA/CR—2010-216324 49

TABLE 12.—NATIONAL AIRSPACE SYSTEM (NAS) FUNCTIONS

[Numbers in the table correspond to communication requirements in the NAS SR–1000 (Ref. 10).]

NAS functions Communication requirements

Support 

flight 

operations

Manage weather 

information

The NAS shall maintain communication links adequate to avoid user delay in gaining 

access. (07090)

The NAS shall disseminate weather information to users continuously. (07110)

The NAS shall disseminate current weather effect along the users proposed flight path.

(07470)

The NAS shall disseminate forecast weather in effect along the users proposed flight path. 

(07480)

The NAS shall disseminate intensity levels of weather by route of flight to users. (08260)

The NAS shall disseminate intensity levels of weather by geographic area to users. 

(08300)

The NAS shall disseminate weather advisories to users in response to a request. (09300)

The NAS shall broadcast the latest approved aerodrome conditions on communications 

media accessible by aircraft on the ground. (09340)

The NAS shall broadcast the latest approved terminal area conditions on communications 

media accessible by aircraft on the ground. (09360)

The NAS shall respond to user requests for weather information from NAS facilities 

through common carrier communications networks. (09370)

The NAS shall disseminate selected weather information directly to appropriately 

equipped aircraft. (09420)

The NAS shall provide flexible and convenient access to required weather information to 

users. (19380)

Operate navigation 

aidsa

The NAS shall disseminate navigational accuracy correction values for supplemental 

navigation systems to users. (17040)

The NAS shall disseminate correction values for navigational aids to users. (16790)

The NAS shall disseminate available supplemental terminal navigation guidance 

information error correction values to users. (14820)
NASA/CR—2010-216324 50

TABLE 12.—NATIONAL AIRSPACE SYSTEM (NAS) FUNCTIONS

[Numbers in the table correspond to communication requirements in the NAS SR–1000 (Ref. 10).]

NAS functions Communication requirements

Monitor 

NAS 

operations

Monitor NAS flight 

operations

The NAS shall disseminate future delay advisories in effect along the users proposed 

flight path. (07500)

The NAS shall disseminate traffic advisories upon user request. (09120)

The NAS shall provide traffic advisories to aircraft on the surface. (30270)

Maintain NAS 

infrastructure

The NAS shall disseminate airway usage information to users. (00030)

The NAS shall disseminate route usage information to users. (00050)

The NAS shall disseminate aeronautical information to users via external data interfaces. 

(07430)

The NAS shall disseminate aeronautical information per user request. (07130)

The NAS shall disseminate aeronautical information upon user request continuously. 

(07340)

The NAS shall disseminate aeronautical data for a maximum of 8 specified locations per 

request. (07400)

The NAS shall disseminate the status of supplemental navigation systems to users. 

(17010)

The NAS shall disseminate status of supplemental navigation systems to users. (16770)

The NAS shall disseminate flow control information to users via external data interfaces. 

(07920)

The NAS shall disseminate derived restrictions to the user. (11700)

The NAS shall disseminate alternate courses of action relative to flight restrictions to 

users. (11790)

The NAS shall disseminate terrain information compliant with terrain, ground and 

obstacle information accuracy requirements, to users upon request. (03900)

The NAS shall disseminate manmade obstacle information compliant with terrain, ground 

and obstacle information accuracy requirements, to users upon request. (03940)

The NAS shall disseminate ground information compliant with terrain, ground and 

obstacle information accuracy requirements, to users upon request. (25520)

The NAS shall disseminate filtered terrain information to users. (25560)

The NAS shall disseminate filtered ground information to users. (25570)

The NAS shall disseminate filtered manmade obstacle information to users. (25580)

Plan NAS 

usage

Plan traffic flow The NAS shall disseminate preferred route information at least 24 hours prior to it 

becoming effective. (07280)

The NAS shall disseminate military air traffic control plans related to national 

emergencies. (16140)

The NAS shall disseminate flow control information to users via external data interfaces. 

(07920)

The NAS shall disseminate interfacility traffic flow plans. (11970)

The NAS shall disseminate derived restrictions to the user. (11700)

The NAS shall disseminate derived alternative courses of action to the user. (11720)

The NAS shall determine flight restrictions for specific aircraft. (11760)

The NAS shall disseminate flight restrictions to users. (11770)

The NAS shall disseminate alternate courses of action relative to flight restrictions to 

users. (11790)

Assess traffic flow 

performance

The NAS shall disseminate reports on equipment performance. (18870)

The NAS shall disseminate reports on maintenance activities. (18880)

The NAS shall disseminate reports on equipment repair activities. (18890)

a

These services are typically provided via satellite communication (SATCOM) but could be provided via a ground-based system.
NASA/CR—2010-216324 51

4.1.2.2 National-Airspace-System-Level Functional Requirements for AeroMACS 

Infrastructure

The following is a summary of NAS infrastructure (communications) requirements found applicable 

to the proposed AeroMACS as documented in the NAS SR−1000 (Ref. 10). The list supports the highlevel functional requirements presented in the document.

• The NAS shall provide data channels in the frequency band appropriate for air-ground data 

communications equipment for data communications coverage for both civil and military users. 

(19940)

• The NAS shall automate communications capabilities to reduce specialist and user workload. 

(20210)

• The NAS shall provide air-ground communications continuously... (part of 20330)

• The NAS shall provide reconfiguration of communications capabilities without degradation of 

air-ground voice or data communications. (20380)

• The NAS shall support peak busy hour exchange of data including short-term peaks that may 

occur within the peak hour, with minimal change in the data transmission response times and no 

loss of data. (20760)

• The NAS shall reconfigure communication capabilities to support changes in operating 

responsibilities. (20800)

• The NAS shall provide processing and communications capacities to support the required backup 

capabilities and to meet the response time requirements while maintaining safe separation of all 

aircraft receiving ATC services (i.e., both normal and backup sectors) from the backup facilities. 

(21670)

• The NAS shall provide configurable communications. (32120)

4.2 AeroMACS Performance Requirements

4.2.1 National-Airspace-System-Level Performance Requirements Applicable to AeroMACS

Performance requirements were derived to define system capabilities based on the functional 

requirements developed in preceding sections and considering propagation characteristic of the C-band. 

Table 13 summarizes NAS performance requirements found to be relevant to the proposed AeroMACS as 

documented in the NAS SR−1000 (Ref. 10). Note that these are high-level NAS requirements that do not 

specify how they should be implemented. A/G and G/G communications are considered to be possible 

implementation solutions.

TABLE 13.—NATIONAL AIRSPACE SYSTEM (NAS) PERFORMANCE REQUIREMENTS

[Numbers in the table correspond to performance requirements in Ref. 10.]

NAS function Performance requirement

Control traffic The NAS shall disseminate hazardous weather avoidance recommendations to users within 1 minute of 

request. (08440)

The NAS shall communicate aircraft actions to users within 1 minutes of implementing a weather avoidance 

plan. (08460)

The NAS shall alert participating aircraft to predicted conflicts with obstructions within 10 seconds of 

prediction. (09170)

The NAS shall notify users of non-adherence to ATC clearance within 10 seconds of the detection of the 

deviation. (02010)

The NAS shall alert appropriately equipped users to the collision danger within 10 seconds after the 

prediction is made. (03660)
NASA/CR—2010-216324 52

TABLE 13.—NATIONAL AIRSPACE SYSTEM (NAS) PERFORMANCE REQUIREMENTS

[Numbers in the table correspond to performance requirements in Ref. 10.]

NAS function Performance requirement

Support flight 

operations

The NAS shall disseminate a requested summary of hazardous weather for any airspace in the continental 

United States within a mean response time 3.0 seconds of the request. (08060)

The NAS shall notify users affected by the presence of hazardous weather within 2 minutes of acquisition. 

(08170)

The NAS shall update hazardous weather broadcasts at least once every 30 minutes. (09400)

The NAS shall disseminate automated weather observations once per minute to designated interfaces. 

(05270)

The NAS shall disseminate Terminal area hazardous weather information to users within one minute of 

detection. (06990)

The NAS shall display requested routine weather information to the user within a mean response time of 

3.0 seconds of the request. (23380)

The NAS shall display requested routine weather information to the user within a 99th percentile response 

time of 5.0 seconds of the request. (23390)

The NAS shall display requested routine weather information to the user within a maximum response time 

of 10.0 seconds of the request. (23400)

The NAS shall disseminate a requested summary of hazardous weather for any airspace in the continental 

United States within a 99th percentile response time of 5.0 seconds of the request. (23510)

The NAS shall disseminate a requested summary of hazardous weather for any airspace in the continental 

United States within a maximum response time of 10.0 seconds of the request. (23520)

Monitor NAS 

operations

The NAS shall alert users to a full navigation system failure affecting NAS operations within 10 seconds of 

the failures detection. (17110)

The NAS shall alert users to a partial navigation system failure affecting NAS operations within 10 seconds 

of the failures detection. (17130)

The NAS shall disseminate the results of Traffic Management Coordinator capacity projection requests 

within 99th percentile response time of 5.0 seconds of the request. (10820)

The NAS shall disseminate the results of Traffic Management Coordinator capacity projection requests 

within a maximum response time of 10.0 seconds of the request. (10820)

The NAS shall disseminate the results of Traffic Management Coordinator demand projection requests 

within the 99th percentile response time of 5.0 seconds of the request. (10850)

The NAS shall disseminate the results of Traffic Management Coordinator demand projection requests 

within a maximum response time of 10.0 seconds of the request. (10850)
NASA/CR—2010-216324 53

TABLE 13.—NATIONAL AIRSPACE SYSTEM (NAS) PERFORMANCE REQUIREMENTS

[Numbers in the table correspond to performance requirements in Ref. 10.]

NAS function Performance requirement

Plan NAS usage The NAS shall disseminate requested flow control advisory information to users within a mean response 

time of 3.0 seconds of the request. (07890)

The NAS shall disseminate scheduled flight activity information in military special use airspace within 

1 minute of request. (08900)

The NAS shall disseminate requested delay advisory information to users within a mean response time of 

3.0 seconds of the request. (07900)

The NAS shall alert users not more than 10 seconds after any failures of navigation guidance affecting 

operations within the NAS. (16810)

The NAS shall alert users not more than 10 seconds after any failures of portions of navigation guidance 

affecting operations within the NAS. (16820)

The NAS shall alert users within 10 seconds, of failures to navigation guidance that affect operations. 

(17150)

The NAS shall alert users within 10 seconds, of failures to portions of navigation guidance that affect 

operations. (09590)

The NAS shall assure ground-air transmission time for data messages not exceed 6 seconds. (20090)

The NAS shall provide retrievable air-ground data messages within 30 minutes and from “off-line” storage 

within 60 minutes. (20270)

Individual air-ground data messages shall be retrievable from “off-line” storage within 5 minutes of a 

request by authorized NAS personnel. (20280)

The NAS shall strive to restore critical system service to users/specialists within 6 seconds of failure 

(22900)

The NAS shall strive to restore essential system service to users/specialists within 10 minutes of failure. 

(22910)

The NAS shall disseminate requested aeronautical information to users within a mean response time of 

3.0 seconds of the request. (23580)

The NAS shall disseminate requested aeronautical information to users within a 99th percentile response 

time of 5.0 second of the request. (23590)

The NAS shall disseminate requested aeronautical information to users within a maximum response time of 

10.0 seconds of the request. (23600)

The NAS shall disseminate requested flow control advisory information to users within a 99th percentile 

response time of 5.0 seconds of the request. (23950)

The NAS shall disseminate requested flow control advisory information to users within a maximum 

response time of 10.0 seconds of the request. (23960)

The NAS shall disseminate requested delay advisory information to users within a 99th percentile response 

time of 5.0 seconds of the request. (23970)

The NAS shall disseminate requested delay advisory infozrmation to users within a maximum response time 

of 10.0 seconds of the request. (23980)
NASA/CR—2010-216324 54

4.2.2 Communications Operating Concept and Requirements (COCR) Performance 

Requirements Applicable to AeroMACS

The performance requirements shown in Table 14 resulted from the operational performance 

assessment conducted as part of the COCR (Ref. 12). That assessment determined the performance that a 

system or service must achieve and led to a determination of the availability, integrity, and transaction 

times. Performance requirements were driven by operational needs and safety requirements as well as 

other assessments (e.g., information security) to determine overall communication performance 

requirements.

The more stringent of the safety objectives and operational requirements for each parameter was used 

to determine the communication performance requirements. The operational requirements are driven by 

the type of exchange (e.g., trajectory change and general information) and the domain in which the 

service was offered. 

Values in Table 14 are based on COCR ATS future radio system performance requirements (Ref. 57) 

for the select services with the most stringent requirements presented. For example, the WAKE service is

a driving service for defining the latency requirements in the airport, TMA, and en route domains. 

Performance requirements should be revisited at a later stage in the system development process to 

reflect the most current ConUse and services selection. 

TABLE 14.—AeroMACS DATA REQUIREMENTS

Service type Confidentiality Latency,

sec

Integrity Availability of 

provision

Airport

Addressed Medium 0.4 5.0×10–8 0.999995

Broadcast Medium 1.4 5.0×10–8 0.999995

4.3 Other AeroMACS Requirements

4.3.1 Spectrum Requirements Applicable to AeroMACS

One of the main objectives of the proposed AeroMACS system is to increase communications system 

capacity. A channel plan will be developed driven by frequency availability to support broadband 

services. 

The proposed system should provide seamless operations around the globe. International standards 

are being developed to achieve full interoperability. 
NASA/CR—2010-216324 55

Table 15 summarizes NAS spectrum requirements applicable to the proposed AeroMACS as 

documented in the NAS SR−1000 (Ref. 10).

TABLE 15.—NATIONAL AIRSPACE SYSTEM (NAS) SPECTRUM

REQUIREMENTS APPLICABLE TO THE PROPOSED AeroMACS

[Numbers in the table correspond to performance requirements in the NAS SR–1000 (Ref. 10).]

Category Performance requirement

Secure Spectrum with 

the Federal Aviation 

Administration (FAA)

The NAS shall secure and protect national radio spectrum for the FAA and the US Aviation 

community. (32470)

The NAS shall coordinate national spectrum allocation programs. (19190)

The NAS shall establish new systems spectrum development activities compatible with projected 

national use. (19290)

Secure frequency for 

the FAA

The NAS shall establish national frequency allocation programs. (19170)

The NAS shall establish new systems frequency development activities compatible with current 

national use. (19230)

The NAS shall establish new systems frequency development activities compatible with projected 

national use. (19270)

Secure international 

spectrum

The NAS shall establish new systems spectrum development activities compatible with current 

national use. (19250)

The NAS shall comply with national standards to avoid the interference of new systems with existing 

systems. (19310)

The NAS shall coordinate national spectrum management assistance programs. (19210)

The NAS shall disseminate en route navigational guidance such that ambiguities in guidance 

information have a minimal impact on NAS operations. (13960)

Manage international 

spectrum

The NAS shall comply with international standards to avoid the interference of new systems with 

existing systems. (32090)

4.3.2 User Requirements Applicable to AeroMACS

Table 16 summarizes aviation user requirements based on those documented in Reference 58 and 

found to be potentially applicable to AeroMACS. 

TABLE 16.—AVIATION USER REQUIREMENTS

The system shall be capable of supporting all categories of users including the following (Ref. 58):

1. Scheduled air transport carriers (including international, trunk, regional, commuter and air freight carriers)

2. Nonscheduled air carriers

3. General Aviation (GA) (including operators of turbine-powered and reciprocating–engine aircraft) Scheduled air transport 

carriers (including international, trunk, regional, commuter and air freight carriers)

4. Nonscheduled air carriers

5. General Aviation (GA) (including operators of turbine-powered and reciprocating–engine aircraft)

6. Rotorwing Aircraft (including helicopters and gyrocraft)

7. Unpowered aircraft (including gliders and lighter-than-air)

8. Military aircraft

9. Certain ground and maritime vehicles (e.g., airport service vehicles, those vehicles coordinating in a search-and-rescue 

mission)

The new system shall satisfy any data communications requirements for use in any authorized category of communications 

service including ATS, AOC, and AAC.

The avionics equipment shall communicate with any compatible ground system. The new system shall be capable of 

implementation and operation anywhere in the world.
NASA/CR—2010-216324 56

4.3.3 Regulatory Requirements Applicable to AeroMACS

The following list summarizes regulatory requirements based on those documented in Reference 32

and found to be potentially applicable to AeroMACS. 

• The system shall comply with AM(R)S spectrum allocation requirements.

• The system shall comply with the U.S. ATS and AOC service rules and regulations.

• The system shall comply with the U.S. Federal aviation regulations.

• The system shall support the requirements for message priority capability.

4.3.4 Safety and Security Requirements Applicable to AeroMACS

A fundamental safety requirement is that new communications systems shall not cause degradation in 

safety when compared with the existing communications systems. The overall objective is to improve 

safety. A C-band initial safety and security analysis and the associated requirements applicable to 

AeroMACS are covered in separate documents (Refs. 54 and 59).

4.4 Guidance for the Development of AeroMACS Requirements Based on IEEE 802.16e

The preceding sections presented high-level functional and performance requirements applicable to 

AeroMACS that encompass most of the known A/G and G/G communications services for mobile-tofixed and fixed-to-fixed applications on the airport service. They should be considered high (NAS) level 

guidance in the development of specific system requirements necessary for any particular service for 

which AeroMACS is proposed to implement. 

Typically high-level requirements are technology independent. Perhaps unique to the development of 

the AeroMACS requirements is the identification a priori, by virtue of the extensive FCS technology 

assessment, of the recommended technology by which AeroMACS will be implemented, that is, IEEE 

802.16e. This allows the identification and development of quite specific requirements depending on the 

desired application or service to be provided. The following sections provide a preliminary approach for 

identifying and developing AeroMACS requirements in the context of the IEEE 802.16e broadband 

communications standard and its characteristics.

4.4.1 Introduction

The applications discussed in Section 3.0 require the support of several types of communication 

services. Much of the initial requirements analysis work was done in the COCR study (Ref. 12), which 

conducted analysis to specify requirements for continuity, integrity, availability of provision, and 

availability of use for various ATS communication services. The services analyzed were primarily 

narrowband services, but the study indicated the level of performance that would be needed by a 

wideband service as well. 

An initial safety analysis was carried out for future airport surface communication systems that 

considered the possibility of wideband communication systems (Ref. 54). This analysis dealt with various 

aspects of hazards and safety risks relative to ConUse and provided initial top-level risk assessments. 

Safety risk assessments deal with the criticality of communication services and the ability of these 

services to maintain levels of performance in operation. The results from a safety and reliability analysis 

will help determine link performance requirements and the level of redundancy needed in the 

communication system. In addition, a safety analysis will help determine the monitoring and maintenance 

intervals needed for the communication system and the supporting network management functions. 

Security levels and services also are considered in developing requirements that can be applied at the 

link/MAC and physical layers. At the physical layer, transmission security may be required to prevent 

unauthorized monitoring or spoofing of the transmitted signals. At the MAC layer, low-level 

authentication and identification may be needed. Security above the link and local network layers will 

include message encryption and higher level authentication services. 
NASA/CR—2010-216324 57

These are important inputs to developing a quality-of-service (QoS) protocol/policy and physical 

layer requirements for AeroMACS. 

4.4.2 Classes of Communications Services for AeroMACS

The applications described in Section 3.0 require communication services to perform their functions. 

The following subsections give brief descriptions of classes of communication services that may be 

required. For this discussion, a “point” is a central source or user of data, and “multipoint” means that the 

data traffic is sent to multiple users. This does not refer to the AeroMACS network architecture of a 

central BS (point) servicing multiple subscriber stations (SSs—multipoint).

4.4.2.1 Low-to-Medium-Speed Point-to-Point Data Link 

This link transports data from a sensor or ground station to a processing or monitoring unit. Data rates 

are low to moderate (<200 kilobits per second (kbps)). These links can be part of a polling network where 

several links are tied to the central station. 

4.4.2.2 High-Speed Point-to-Point Data Link 

A high-speed data link can be used to link sensors that produce high-speed data to a central processor, 

or to link multisensor network access points or a subnetwork to a larger network. Data rates ≥200 kbps 

are needed. 

4.4.2.3 Point-to-Multipoint Broadcast Data 

This type of communication service enables the multicast or broadcast of scheduled or priority 

messages to a large group of users or a selected subset of users (multipoint). Data updates and critical 

messages will have low to moderate data transmission rates (<200 kbps).

4.4.2.4 Point-to-Point Command and Control Data 

This type of service is for near-real-time control of a device or system. It relies on short-turnaround 

feedback from the device being controlled. Control of runway lighting is one example for this type of 

service. The command UL and feedback link are low rate (<100 kbps), but they require low error rates. 

The UL may carry higher data rates (e.g., video at <2 megabit per second (Mbps)) and can tolerate higher 

error rates than the control link. 

4.4.2.5 Voice Network

Digital voice networks have several advantages over analog voice circuits. For example digital voice 

circuits can be encrypted. However, they have requirements on maximum delay corresponding to the 

human response times (typically less than 200 msec one way). This usually dictates a time-division 

multiple-access (TDMA) system to guarantee maximum delay time. Capacity requirements will depend 

on the number of voice circuits used. 

4.4.2.6 Video Link

Depending on the resolution and frame rates needed for an application, video transmission can require 

significant capacity, typically on the order of 1 Mbps for a single link. Thus, a relatively small number of 

video circuits per BS sector (in comparison to a voice circuit) are likely to be supported in a multiservice 

communication system. 
NASA/CR—2010-216324 58

4.4.2.7 Multimedia

Multimedia services combining voice, data, and video can require a large amount of communication 

resources depending on how the services are combined for use. For CDM, voice plus data (graphics) may 

be all that is needed. An example would be an application like Net Meeting. The addition of video to 

CDM will require a significant increase in demand for capacity from the network. 

4.4.2.8 Basic Mobile

This class of communication service requires the necessary QoS and network functions for handoff 

between BS sectors to support basic voice and data services.

4.4.2.9 Enhanced Mobile 

This class of mobile service provides increased capacity to handle interactive applications such as 

CDM while on the move. 

4.4.3 Developing AeroMACS Service Quality-of-Service Requirements Based on IEEE 802.16e

Developing a QoS function for a modern communication system involves three main areas of 

consideration:

(1) Defining a set of QoS parameters and metrics that can be used to monitor and classify 

different grades of communication services

(2) Determining service priorities and preemption if needed

(3) Developing a protocol for managing and scheduling services

The IEEE 802.16e standard includes five QoS categories. These categories use a number of 

performance parameters to quantify performance. The five QoSs included in the IEEE 802.16e standard 

follow:

(1) Unsolicited grant service (UGS) supports fixed-size data packets and allocated capacity. 

Digital voice circuit over the Internet (VoIP) is an example. 

(2) Real-time polling services (rtPS) are designed to support networked video and voice 

applications on a high-speed network that supports multiple streams.

(3) Non-real-time polling service (nrtPS) supports delay-tolerant data streams that transmit at 

periodic intervals, such as file transfers. 

(4) Best-effort service provides a best effort for delivering data packets without guaranteeing 

delivery. This is the type of service normally provided by the Internet. 

(5) Extended real-time variable rate (ERT–VR) service supports real-time applications that can 

have variable packet sizes. Digital voice with silence suppression is an example.
NASA/CR—2010-216324 59

Table 17 relates the five QoS categories to the applications that will benefit from the QoS category 

and the parameters that define each QoS category (Ref. 60).

TABLE 17.—IEEE 802.16e QUALITY OF SERVICE CATEGORIES AND DEFINING PARAMETERS

Defining parameters Unsolicited grant 

service,

UGS

Real-time 

polling 

service,

rtPS

Non-real-time 

polling service,

nrtPS

Extended realtime polling 

service

Best 

effort

Applications

Traffic over T1 or 

E1 lines (T1/E1),

VoIPa without 

silence suppression

Streaming 

audio and 

streaming 

video

FTP and TCPb

applications that 

require a minimum 

data rate

VoIP with 

voice-activity 

detection 

(bursty traffic)

Web 

browsing 

and file 

transfer

Real-time service flow X X X

Fixed-size data packets X X

Scheduled packet transmission X X X

Minimum reserve rate X X

Maximum sustained rate X X X

Maximum latency tolerance X

Time jitter tolerance X X

Traffic priority X X X X

Dynamic traffic allocations X

Unicast polls (guaranteed 

service request opportunities in 

congestion)

X

a

VoIP, digital voice over Internet Protocol.

b

FTP, File Transfer Protocol; TCP, Transmission Control Protocol.

4.4.4 Quality of Service Support of AeroMACS Communication Services

Table 18 shows an analysis of the communications services that were discussed in Section 4.4.2 with 

example airport applications and applicable QoS service classes. Typical values of performance are 

included for data rate, packet error rate (PER), delay (time latency), and time jitter.

TABLE 18.—COMMUNICATION SERVICE REQUIREMENTS

[Acronyms are defined in Appendix A.]

Communication

service

Example airport

application

Quality-of-service 

(QoS) class

Performance

parameters

Typical 

values

Supported

by IEEE 

802.16e

Low-to-mediumspeed point-to-point 

data link 

Backup for sensor cable 

link (i.e., weather 

sensor)

nrtPS Data rate 100 kbps Yes

PER 1.0×10–3

Delay 1 sec

Jitter 100 μsec

High-speed pointto-point data link Backbone-linking BS; 

link to relay gateway 

node in remote area

UGS Data rate 1 Mbps Yes

PER 1.0×10–3

Delay 100 msec

Jitter 100 nsec
NASA/CR—2010-216324 60

TABLE 18.—COMMUNICATION SERVICE REQUIREMENTS

[Acronyms are defined in Appendix A.]

Communication

service

Example airport

application

Quality-of-service 

(QoS) class

Performance

parameters

Typical 

values

Supported

by IEEE 

802.16e

Point-to-multipoint 

broadcast data

Scheduled broadcast of 

weather info, NOTAM

nrtPS Data rate 200 kbps Yes

PER 1.0×10–3

Delay 1 sec

Jitter <1 μsec

Point-to-point 

command and 

control data

Remote operation of 

ADS–B ground station

rtPS Data rate 200 kbps Yes

PER 1.0×10–6

Delay 100 msec

Jitter <1 μsec

Command and 

control 

network

Operation of surface 

devices at remote airport 

Best effort Data rate 200 kbps Yes

PER 1.0×10–4

Delay 200 msec

Jitter <10 μsec

Digital voice 

network

Provide N circuits for 

ATC or AOC operations

rtPS;

ERT–VR service

Data rate 10 kbps × N Yes

PER 1.0×10–3

Delay 100 msec

Jitter <100 μsec

Point-to-point video 

link

Airport surveillance; 

robotic vehicle 

UGS Data rate 600 kbps Yes

PER 1.0×10–3

Delay 200 msec

Jitter <10 μsec

Basic mobile Handoff control for 

voice; low-speed data 

sessions

UGS Data rate 200 kbps Yes

PER 1.0×10–3

Delay 200 msec

Jitter <10 μsec

Multimedia CDM rtPS Data rate 1 Mbps Yes

PER 1.0×10–3

Delay 100 msec

Jitter <10 μsec

These typical performance parameters are for the physical and link-layer requirements for individual 

communication services. The actual values will depend on the architecture of the communication 

network, the size of the network, and the provisions for redundant communication support. The 

performance values shown in the table are typical of the type of communication service offered. For 

example, one-way voice delay is derived from subjective analysis involving human reactions in human 

conversation with push-to-talk communications. Jitter requirements are somewhat dependent on the 

implementation—for example, the extent to which data buffering is used. Packet error rate performance 

typically depends on the use of retransmissions and the size of the message. Future work should refine 

these performance values according to the specific services to be implemented.

The final column of Table 18 is an assessment of whether the requirement is supported by the 

performance of a system that is based on the IEEE 802.16e standard. The communications systems and 

their operating requirements are expected to be supported in all cases that were examined.
NASA/CR—2010-216324 61

5.0 Architectural Description and Initial Test Bed Requirements

5.1 Initial Surface Communications System Architecture

This section describes a system architecture framework for an airport surface communications 

reference model that can be applied at all airport installations. The number of components to be deployed 

will vary according to the size and data capacity needs of the airport. The communication architecture is 

based on the IEEE 802.16 standard for the network functions with the IEEE 802.16e-2005 amendment 

(Ref. 18) for the mobile air interface. 

5.2 Overview

The primary mode for operation on an IEEE 802.16e-based system is a point-to-multipoint 

architecture. Figure 22 depicts a wireless point-to-multipoint system in an airport context. 

In this architecture, SSs, which include fixed and portable nodes, and mobile stations (MSs) are 

wirelessly linked to the BS access points. The BSs are linked to a common access service network (ASN) 

which manages services between BSs. The ASN can include one or more BSs and could be localized to 

one part of the airport (for example, an area assigned to a major carrier). For a small number of BSs, 

distributed ASN functions can be used that are installed at each BS. The ASNs are linked to a 

Connectivity Service Network (CSN) through gateways (not shown in Figure 22). The CSN provides 

access to services on the airport intranet and fire-walled access to the Internet. 

Figure 22.—Airport point-to-multipoint communications service. Acronyms are defined in Appendix A.

Wireless Cable

Asset Tracking

Data Services

ASR

RTR/RCAG

Vehicle

ADS-B

Station

ADS-B

Station

Security

ASR

VOR

LCGS

ATCT

Airport 

Intranet

Airport 

Intranet

Backbone

High speed link

ASN

ASN

BS

BS

Vehicle

MS

MS

MS

SS

SS

SS

SS

SS

SS

SS

SS : Subscriber Station

MS: Mobile Station

BS: Base Station 

ASN: Access Service Network

Wireless Cable

Asset Tracking

Data Services

ASR

RTR/RCAG

Vehicle

ADS-B

Station

ADS-B

Station

Security

ASR

VOR

LCGS

ATCT

Airport 

Intranet

Airport 

Intranet

Backbone

High speed link

ASN

ASN

BS

BS

Vehicle

MS

MS

MS

SS

SS

SS

SS

SS

SS

SS

Wireless Cable

Asset Tracking

Data Services

ASR

RTR/RCAG

Vehicle

ADS-B

Station

ADS-B

Station

Security

ASR

VOR

LCGS

ATCT

Airport 

Intranet

Airport 

Intranet

Backbone

High speed link

ASN

ASN

BS

BS

Vehicle

MS

MS

MS

SS

SS

SS

SS

SS

SS

SS

SS : Subscriber Station

MS: Mobile Station

BS: Base Station 

ASN: Access Service Network
NASA/CR—2010-216324 62

5.3 IEEE 802.16 Network Architecture 

The IEEE 802.16e Network Working Group has developed a network reference model to assist in the 

deployment of IEEE-802.16e-based systems. It is designed to enable interoperability of vendor equipment 

and to provide a structure for the deployment of new systems. The architecture is Internet Protocol- (IP) 

based, meaning it relies on IP addressing to provide secure connectivity between users and access to 

common services. Figure 23 depicts a top level view of this architecture. 

Figure 23.—IEEE 802.16e IP-based network architecture. (Based on Fig. 2.3 in Ref. 61.)

The MS nodes can be anything mobile: aircraft, service vehicles, emergency vehicles, or other 

vehicles. The SS nodes are stationary sites that could be surveillance weather stations, radar sites, or 

operations buildings located on the airport surface. In AeroMACS, MS and SS nodes are both referred to 

as SS. The hardware for both is compliant with the mobile standards, whether physically mobile or 

stationary.

SS nodes are linked through wireless connections to the BS access points. There can be multiple SS 

nodes assigned to a single BS. Mobile SS nodes are transitory and must be serviced by a handoff protocol 

that enables the mobile SS to maintain connected service while moving between access point coverage 

areas. The BSs are connected to an access network that includes a gateway IP router. The access network 

manages the ASN to ensure its proper operation at the physical and MAC levels. This includes the 

management of mobile and stationary SSs operating within the ASN. It also provides access to higher 

level services through the access service network gateway (ASN–GW). The CSN provides connectivity to 

the airport intranet. The airport intranet hosts local IP-based servers which provide various data services 

and applications to authorized airport users.

SS

MS

MS

SS

BS

BS

BS

Access 

Network

Access Service

Network (ASN)

ASN

GW

Connectivity 

Service Network IP

Network

Internet

Airport 

Intranet

Corporate 

networks

MS

R1 R2

R3

R6

SS

MS

MS

SS

BS

BS

BS

Access 

Network

Access Service

Network (ASN)

ASN

GW

Connectivity 

Service Network IP

Network

Internet

Airport 

Intranet

Corporate 

networks

MS

R1 R2

R3

R6
NASA/CR—2010-216324 63

The ASN–GW aggregates subscriber and control traffic from BSs within an access network. It has an 

important role in subscriber management, network optimization, and forwarding of all SS traffic.

The BS nodes identified in this architecture will often have multiple coverage sectors using multiple 

radios, each with a directional transmit/receive antenna. Each radio and antenna pair forming a coverage 

sector is referred to as a base transceiver station (BTS).

The IEEE 802.16e network architecture further defines functional interfaces between the major 

components of the model as listed in Table 19. Eight functional interfaces that are defined within the 

network and between networks are listed in the table. The four interfaces shown in the figure (R1, R2, R3, 

and R6) are defined in Table 19. Three interfaces (R4, R5, and R7) are defined that would apply to 

airports with more than one ASN, gateway (GW), or CSN, such as when multiple service providers are 

present. 

TABLE 19.—SELECTED IEEE 802.16e NETWORK INTERFACE DEFINITIONS

[Acronyms are defined in Appendix A.]

Interface reference 

point

Functional entities Functions

R1 SS and the ASN Implements the air interface (IEEE 802.16e) specifications and may 

additionally include protocols related to the management plane.

R2 SS and CSN Provides authentication, service authorization, IP host configuration 

management, and mobility management. This is only a logical interface 

and not a direct protocol interface between the ASN and CSN.

R3 ASN and CSN Supports AAA [authentication, authorization, and accounting], policy 

enforcement and mobility management. R3 also encompasses the bearer 

plane methods (e.g. tunneling) to transfer IP data between the ASN and 

the CSN.

R4 ASN and ASN A set of control and bearer plane protocols that originate/terminate 

within the ASN that coordinates SS mobility between ASNs.

R5 CSN and CSN A set of control and bearer plane protocols to support mobility between 

networks if multiple networks (airports) are supported by multiple CSNs 

and mobility handoff is needed. 

R6 SS and ASN–GW A set of control and bearer plane protocols for communication between 

the BS and the ASN–GW. Consists of intra-ASN bearer paths and IP 

tunnels for mobility tunnel management. R6 may also be a conduit for 

exchange of MAC states information between neighboring BSs.

R7 ASN–GW–DP and

ASN–GW–EP

An optional set of control plane protocols for coordination between the 

two groups of functions identified in R6.

R8 BS and BS A set of control plane message flows and possibly bearer plane data 

flows between BSs to facilitate fast and seamless handovers.
NASA/CR—2010-216324 64

Figure 24 provides details about the functions that pass through the R1, R3, and R6 interfaces. The 

R2 interface is not indicated in the figure because it deals with services that pass between the SS node 

stations and the CSN. Interface R8 applies if, in the future, local mesh or ad hoc networking between SSs 

is implemented in an amendment to the standard. 

Figure 24.—Network interfaces and functions. Acronyms are defined in Appendix A.

Each airport location can be considered as a small enterprise with data communications occurring in 

the immediate vicinity of the airport property. Because of this, frequency planning for the R1 interface 

can consider only the BS sectors at a single airport unless other airports are within the radio LOS. Plans 

can be made to reuse the BS sector frequency within the C-band allocation within that small enterprise.

Commercial IEEE 802.16e hardware that is presently available can be procured with either a 

centralized ASN–GW or a distributed ASN–GW in which the gateway function is resident in each BS. 

The use of a centralized ASN–GW server versus a distributed function presently depends on the number 

of BSs in a network, with the distributed approach typically supporting up to six BSs. 

The functions at the R3 interface between ASN and CSN can be supported for relatively long 

distances over a secure IP network. One CSN will be able to support multiple small enterprises and could 

potentially support all airport surface communication networks across a national region.

The number of multisector BS sites to be installed at an airport will depend on many factors including 

the physical size of the airport, the expected data load requirements, and factors that affect wireless signal 

propagation such as terrain and building shadowing and the need for high QoS. Network reliability will 

improve with at least two BS visible to each SS for the majority of the coverage area. This will provide 

reliable wireless linkage in the case that one of the available paths between an SS and BS is interrupted by 

an obstruction or hardware failure. Each airport will be somewhat unique in these factors and will require 

customized designs for the placement and quantity of BS sites to provide the needed QoS.
NASA/CR—2010-216324 65

Many options exist to implement a physical R3 interface between an ASN–GW and the CSN that is 

typically located at a central point and can be widely separated from the BSs. Making the R3 connection 

may be complicated by the lack of existing IP network infrastructure in the airport environment. 

Positioning of the BS to achieve airport surface coverage may place it distant from an existing IP-based 

network. A microwave backhaul link may be used to connect BSs to an IP network to avoid the 

installation of cables. Another option is to use an SS to establish an in-band backhaul link to establish a 

limited-bandwidth connection.

5.4 Physical System Architecture and Design Process 

The general network architecture was outlined in Section 5.3. Designing an AeroMACS network at 

an airport will require several tradeoffs to obtain the best performance, including

• Location and number of BSs 

• Number of antenna sectors to employ per BS

• Type of backhaul system to support the ASN

• Number of SS terminals that can be serviced by a BS

The following sections describe the system design process for new airport installations.

5.4.1 Introduction

An essential element in designing and deploying an AeroMACS network is a comprehensive RF 

design. An accurate design will ensure that the deployed wireless network will provide the necessary

coverage, capacity, and reliability, with minimal interference, that satisfies the service requirements. 

Although it is possible to gauge the performance of radio links through theoretical means, real-life 

deployments must take into account variables from the environment to achieve optimal performance and 

minimize coverage holes and RF cochannel interference. 

5.4.2 Airport AeroMACS Network Design Process

The network design process begins with a physical site survey to gather information about the 

deployment location. A site survey provides an opportunity to validate any topography mapping 

information that may be available. It is also used to identify suitable installation locations for AeroMACS 

equipment. A site survey will also provide input to the next three phases of the RF design process: 

(1) Coverage model

(2) Spectrum analysis

(3) Capacity analysis 

5.4.3 Coverage Model

The coverage model requires a map of the site along with coordinates of potential locations for BSs 

and SSs. The coverage model must account for the impact of the environment on the RF transmissions, 

including the effects of the topography, physical obstructions, and foliage. These effects introduce 

propagation delays that have been cataloged in reference models. In addition, clutter models or 

obstruction densities are also modeled in this phase. Clutter models represent the density of obstructions 

in the deployment site. Typical options include rural, urban, and suburban clutter models. An airport 

surface with its relatively open runways and taxi areas and congested terminal areas will be a combination 

of the three models.

In addition to considering site topology and propagation delays, general parameters of the 

AeroMACS solution must be identified. Notable parameters include BS and SS transmit/receive power, 
NASA/CR—2010-216324 66

antenna gains, feeder losses, BS and SS heights, and orthogonal-frequency-division multiple access 

(OFDMA) radio-access-related parameters. In addition, the following are system design parameters:

• Radio access method

• Fade margin

• Antenna sensitivity and diversity

• Cochannel interference margin

• Duplex mode

• Modulation

• Error correction

• UL/DL ratios and throughput

• BS and SS noise figure

• Maximum output/input power

Finally, a link budget must be calculated that specifies the maximum path loss between each BS and 

SS. Receiver sensitivity of the equipment for supported modulation schemes can be obtained from the BS 

and SS vendor data sheets. Characteristics of the BS and SS and information about the placement and 

types of antennas are used to generate an accurate coverage map. 

5.4.4 Spectrum Analysis 

The spectrum analysis phase of radio planning involves analyzing the potential site for interference 

from frequencies that may interfere with the AeroMACS. An analysis involves measuring the maximum 

transmitter signal levels to determine how much energy is present in the surveyed RF band. The spectrum 

analysis can be conducted at ground level, but it is typically conducted from elevated locations including 

rooftops and tower sites at least 50 ft high. 

5.4.5 Capacity Analysis

The capacity analysis involves calculating how much traffic can be supported given the UL/DL ratio 

and the anticipated traffic patterns with the specified bandwidth and modulation scheme. The parameters 

used for capacity calculations include

• Time-division duplexing (TDD) UL/DL ratio

• Mode of operation

• Channel bandwidth

• Subcarrier allocation scheme

• Guard ratio timing

The theoretical physical layer (PHY) throughput calculation per modulation scheme can be calculated 

using the following formula (Ref. 62):

Rb = Rs MC/Rr (1)

where

M modulation gain (2 for quadrature phase-shift keying (QPSK), 4 for 16-quadrature amplitude 

modulation (QAM), and 6 for 64-QAM)

C coding rate (1/2, 3/4, 2/3, or 5/6)

Rr repetition rate (1, 2, 4, or 6)

Rb bit rate

Rs symbol rate
NASA/CR—2010-216324 67

Equation (1) accounts for the pilot overhead but does not account for the signaling overhead, which 

depends on the number of active connections and the service types used. Studies have found that 

signaling overhead may vary from 4 to 10 percent of PHY throughput. Estimating capacity using RF 

design tools takes into consideration the impact of multiple input, multiple output (MIMO) antenna 

schemas to enhance coverage and/or capacity.

Although theoretical and software-based tools provide a baseline for determining the capacity of an 

AeroMACS network, it will be necessary to make minor adjustments once the network has been 

implemented. Such optimization involves selecting appropriate network parameters that will support the 

QoS requirements. A test drive through the deployed network is the final step for collecting network data 

for analysis and optimization.

Table 20 lists many parameters that must be included in design tradeoffs for an AeroMACS network. 

The “Design tradeoff category” column defines broad parameter categories, and the “Parameters” column 

lists in detail the parameters that interrelate during the design process. The “Considerations and system 

tradeoff parameters” column gives recommendations for the system tradeoffs, many of which are unique 

to the airport surface environment. 

TABLE 20.—AeroMACS NETWORK DESIGN TRADEOFFS

Design 

tradeoff 

category

Parameters Considerations and system tradeoff parameters

Base station 

(BS)

Mounting placement Total network data throughput

Line-of-sight/non-line-of-sight (LOS/NLOS) coverage area

Low-level blockage avoidance

Number of BS and base 

transceiver station (BTS) sectors

BS throughput

Channel bandwidth and available spectrum

Multiple input, multiple output 

(MIMO) order

BS cell-radius requirements

Transmitter (Tx) power

NLOS and blocked-path performance

Multipath mitigation

Mobility dropouts

Interference to out-of-band users will be decreased by MIMO because total 

radiated power can be reduced.

Antenna polarization Cross-polarized versus spatially separated antennas

Maximum cell range Number and placement of BSs

BTS sector and subscriber station (SS) Tx power

Controlled-pattern antennas Use beam steering and beam-shape adaptation to increase throughput and 

avoid interference. 

Frequency band 5091- to 5150-MHz aeronautical mobile (route) service (AM(R)S) band 

approved during the 2007 World Administrative Radio Conference (WARC 

2007).

Addition of 5000- to 5030-MHz band is under consideration.

Spectrum co-user interference 

(i.e., Globalstar satellite)

BTS sector antenna patterns control direction of radiation.

Use minimum BTS sector and SS Tx power to achieve required data 

throughput over coverage area.
NASA/CR—2010-216324 68

TABLE 20.—AeroMACS NETWORK DESIGN TRADEOFFS

Design 

tradeoff 

category

Parameters Considerations and system tradeoff parameters

SS Mounting height Avoid low-level structural and temporary blockages.

MIMO order Tx power

NLOS and blocked-path performance

Multipath mitigation

Mobility dropout avoidance

Antenna polarization Cross-polarized versus spatially separated antennas

Maximum cell range Tx power

NLOS and blocked-path performance

Multipath mitigation

Mobility dropouts

Frequency band Controlled and set by BTS sector connection

SS must have matching frequency capability.

Spectrum co-user interference 

(i.e., Globalstar satellite)

BTS sector antenna patterns control the direction of radiation.

Use minimum BTS sector and SS Tx power to achieve required data 

throughputs over coverage area.

Channel 

bandwidth

Throughput rate Highest throughput application sets the minimum channel bandwidth.

Mobility performance A wider bandwidth enables better channel equalization and better tracking of 

multipath variations during mobility.

Multipath performance Better equalization of short-path multipath with wider channel bandwidths

Efficient use of spectrum Number of channels that fit within the 59-MHz allocated AM(R)S spectrum

Co-interference There are fewer options for nonoverlapping frequency reuse in a large 

number of cells with wide channel bandwidths.

Hardware limitations 20-MHz channel bandwidth requires fast digital processing and may not be 

implemented by a particular hardware supplier.

Modulation Adaptive or fixed Fixed modulation requires the use of lowest order modulation and lowest data 

throughput; higher order modulation will cause dropouts during mobility.

Modulation rates Use of all specified options maximizes data throughput for fixed and mobile 

SSs.

Forward error correction (FEC) 

coding rate

Use of all specified options maximizes data throughput for fixed and mobile 

SSs.

BTS power 

class

Fade margin Fade margin allowance is set during network design to establish link 

reliability.

Co-interference Minimize Tx power to stay below the detection threshold of another BTS 

sector in a frequency reuse layout.

Spectrum co-user interference 

(i.e., Globalstar satellite feeder 

uplinks)

Minimize Tx power to reduce interference to co-users of the spectrum.

Range Tx power affects the signal-to-noise ratio and modulation rate at the outer 

edge of cell coverage.

LOS and NLOS operation Fade margin allowance increases for NLOS operation.

Mobile operation Fade margin allowance increases for NLOS operation.

Power amplifier power-output 

limitations

Orthogonal-frequency-division multiplexing (OFDM) modulation has a high 

peak-to-average ratio, making high Tx power expensive.
NASA/CR—2010-216324 69

TABLE 20.—AeroMACS NETWORK DESIGN TRADEOFFS

Design 

tradeoff 

category

Parameters Considerations and system tradeoff parameters

SS power 

class

Fade margin Fade margin allowance is set during network design to maintain link 

reliability.

Co-interference Minimize Tx power to stay below the detection threshold of another BTS 

sector in a frequency reuse layout.

Spectrum co-user interference 

(i.e., Globalstar satellite uplinks)

Minimize Tx power to reduce interference to co-users of the spectrum.

Range Tx power affects signal-to-noise ratio and modulation rate from the outer 

edge of cell coverage.

LOS and NLOS operation Fade margin allowance increases for NLOS operation.

Mobile operation Fade margin allowance increases for mobile operation.

Power amplifier power-output 

limitations

OFDM modulation has a high peak-to-average ratio, making high power 

expensive.

Media 

Access 

Control 

(MAC) layer 

and physical 

layer (PHY)

Maximum mobile speed 120 km/hr is a value derived from other specified parameters and provides 

guidance about achievable maximum speed.

The communications operating concept and requirement (COCR) is 160 kn 

(296 km/hr)

Institute of Electrical and Electronics Engineering (IEEE) 802.16 

specification does not directly support the COCR 160-kn requirement. A 

cost/benefit analysis is needed to assess the benefits of achieving this speed.

Repeater operation

(IEEE 802.16j)

IEEE 802.16j is a potential future amendment to the IEEE 802.16 standard

BS repeater functionality may provide fill-in coverage in shadow areas with 

minimal added radiation and interference.

Transmitter/receiver 

time-division duplex 

(TDD)/frequency-division 

duplex (FDD) mode

C-band AM(R)S spectrum allocation width does not support cost-effective 

FDD operation.

Quality of 

service 

(QoS)

Time delay Services such as voice, and command and control applications will require 

guarantees on maximum time delay allowed.

Time jitter Services that are sensitive to jitter are to be identified. The use of frame 

buffering should be considered for each sensitive application.

Message priority Safety and reliability requirements will help specify message priorities. 

Scheduling The scheduling algorithm will take message priority into account along with 

QoS requirements.

Message integrity Security and message integrity guarantees will depend on the type of QoS 

service flow selected. 

5.5 Test Bed Architecture

The AeroMACS test bed architecture is based on the WiMAX definitions that were outlined in 

Section 5.3. Design of an AeroMACS system requires detailed analysis and simulation as well as test 

measurements on candidate airport surfaces. Test bed measurements carried out on candidate airport 

surfaces should provide sufficient data to calibrate key performance tradeoffs that will be modeled by 

computer simulations. One or more mobile SSs should be part of the test bed experiments to assess UL

and DL performance coverage for initial measurements related to mobile operation.
NASA/CR—2010-216324 70

5.5.1 Test Bed Objectives

The test bed should provide initial quantitative data to aid in the installation of the first phase of an 

IEEE 802.16e-based AeroMACS system at other airports of similar complexity. Specific objectives 

include the following: 

• Assess the full range of aviation profile options for the physical and MAC layer specification, and 

recommend initial values for each parameter in the profile.

• Verify functional operation of the physical and MAC layers within the recommended profile.

• Obtain measurements at various locations on the airport surface to calibrate coverage models for 

the UL and DL systems. The UL is defined as the transmission from the SS to the BS. The DL is 

from the BS. 

• Measure multichannel performance with sectored antennas to support BS location analysis.

• Validate operation of AeroMACS while connected to other airport network systems; for example, 

connected to an airport IP network.

In addition, data collected from a test bed at a specific airport location should be analyzed relative to 

other experimental data from airport measurements. This will help to reinforce conclusions and uncover 

inconsistencies. 

5.5.2 Test Bed Approach

In order to meet the test bed objectives, it is recommended that at least two BSs be utilized that have 

overlapping coverage on the airport surface. In addition, fixed and mobile SSs should be utilized to obtain 

UL and DL coverage data and to be able to evaluate parameter settings under a variety of conditions. 

An AeroMACS system having these considerations and conforming to the architecture described in 

Section 5.3 is now implemented in the NASA–CLE CNS Test Bed. The physical installation is described 

in Section 6.0.
NASA/CR—2010-216324 71

6.0 Test Bed Performance Evaluation

6.1 Test Bed Implementation

The AeroMACS test bed implemented within the NASA–CLE CNS Test Bed is designed to 

implement many of the features that are required to support data communications at an operational 

airport. Two BSs are included to provide coverage redundancy and at least two opportunities for an SS to 

link with a BS. Multiple BTS sectors are implemented at each BS to increase link sensitivity and data 

capacity. The network includes ASN–GW and CSN functions to provide QoS control, user authentication 

and authorization for security, and mobility handoff between multiple BTS sectors.

This section describes the hardware and network layout that is implemented in the NASA–CLE CNS 

Test Bed. Many of the decisions about network layout in Cleveland were driven by the need to use readily 

available mounting structures for the BS and SS sites, the desire to integrate with already-determined test 

bed sensor sites, and the fact that this network is intended for test purposes and does not interact with 

airport operations. 

The design process and system tradeoffs that would be used to design an operational deployment at 

an airport were discussed in Section 5.4. Each SS installation includes an IEEE-802.16e-compliant radio 

transceiver, a single-board computer, a managed Ethernet switch, and power supplies in a weatherproof 

enclosure. The single-board computer hosts a Linux operating system and Ixia Chariot software for 

network performance tests. The Chariot software generates test data streams that are used to test 

communication link capabilities. A test console is located at the core server in Glenn Building 110 to 

coordinate the execution of tests, collect Chariot test results through the network, and compute statistics 

of network performance. Airport sensors, such as the MLAT surveillance remote units, can be connected 

as data sources in place of or in addition to the Chariot software test data streams. A port on the managed 

switch is the interface for IP-based sensors.
NASA/CR—2010-216324 72

Figure 25 shows the placement of the two BS sites and their sectorized coverage in the NASA–CLE 

CNS Test Bed. The BS at Glenn’s Flight Research Building (Building 4) hangar office has two BTS 

sectors that are directed 55° and 200° azimuth from “true north.” The Aircraft Rescue and Firefighting 

(ARFF) building located on airport property has three BTS coverage sectors directed 45°, 185°, and 295° 

from true north. The coverage area of each sector is 90° in azimuth as determined by the –3-dB pattern 

rolloff of the BTS sector antenna. These sector-coverage placements provide a high-degree of redundant 

coverage across the desired coverage area, including the runways, most of the taxiways, and much of the 

ramp areas.

Figure 25.—NASA–CLE CNS Test Bed base station, backhaul, and core server locations. Acronyms are defined in 

Appendix A.
NASA/CR—2010-216324 73

Figure 26 shows the placement of SSs at eight fixed sites. Each of these sites was chosen for their 

co-location with MLAT surveillance equipment already present in the test bed. Each SS can be used to 

wirelessly transport MLAT data to a central surveillance data processor located within the test bed. Each 

fixed SS has LOS to both BSs using directional antenna coverage. 

Figure 26.—NASA–CLE CNS Test Bed subscriber station locations and links. Acronyms are defined in Appendix A.

Data from each BS site is transported to the core server using wireless backhaul links that operate in 

an 11-GHz commercial band. A pair of these microwave radios is used on the roof of Glenn’s Building 

110 (Space Experiments Lab) in full duplex operation between each BS site and the core CSN servers 

located in Building 110. Table 21 shows the frequency assignments for the data backhaul radios.

TABLE 21.—BACKHAUL RADIOFREQUENCY ASSIGNMENTS

[Acronyms are defined in Appendix A.]

Transmitter data radio 

location

Receiver data radio 

location

Frequency 

assignment, 

MHz

CLE ARFF building Glenn Building 110 10 915.0

Glenn Building 4 Glenn Building 110 10 795.0

Glenn Building 110 Glenn Building 4 11 285.0

Glenn Building 110 CLE ARFF building 11 405.0
NASA/CR—2010-216324 74

Each SS installation includes the IEEE-802.16e-compliant radio transceiver, a single-board computer, 

a managed Ethernet switch, and power supplies in a weatherproof enclosure. The single-board computer 

hosts a Linux operating system and Ixia Chariot software for network performance tests. The Chariot 

software generates test data streams that are used to test communication link capabilities. A test console 

located at the core server in Glenn’s Building 110 coordinates the execution of the tests, collects Chariot 

test results through the network, and computes statistics of network performance. The test setup can be 

reconfigured to use data streams from airport sensors, such as the MLAT surveillance remote units, 

instead of Chariot software test data streams. A port on the managed router is the interface for IP-based 

sensors.

As described earlier in this section, five BTS sectors are used in the test bed in order to provide wide 

airport surface coverage and a high degree of link redundancy. The transceiver supporting each coverage 

sector is given a frequency channel assignment. Sector channel bandwidths are selectable to be 5 or 10 

MHz, with 20 MHz available in the future firmware upgrade. 

Sectors having overlapping surface coverage are placed on different channels to avoid co-channel 

interference. Reuse of channel assignments is a possibility for larger-area airport surface deployments 

where not all sectors have overlapping coverage. Deployment of the AeroMACS network in the NASA–

CLE CNS Test Bed is expected to initially use five channels; one per sector, spaced at 5 or 10 MHz 

centers across the 5091- to 5150-MHz spectrum allocation to avoid co-channel interference.

Center frequencies for the five channels are set using the AeroMACS RF profiles defined in Table 22. 

The radios are programmable for either 5- or 10-MHz channel bandwidths and could be upgraded to have 

a 20-MHz channel bandwidth option.

TABLE 22.—NASA–CLE CNS TEST BED 5-MHz 

CHANNEL-FREQUENCY ASSIGNMENTS

5-MHz 

channel

Lower frequency, 

MHz

Center frequency, 

MHz

Upper frequency, 

MHz

1 5092.5 5095 5097.5

2 5097.5 5100 5102.5

3 5102.5 5105 5107.5

4 5107.5 5110 5112.5

5 5112.2 5115 5117.5

Channel frequency assignments for 5- and 10-MHz channel bandwidths for the five sectors of the 

NASA–CLE CNS Test Bed are listed in Table 22 and Table 23. 

TABLE 23.—NASA–CLE CNS TEST BED 10-MHz 

CHANNEL-FREQUENCY ASSIGNMENTS

10-MHz 

channel

Lower frequency, 

MHz

Center frequency, 

MHz

Upper frequency, 

MHz

1 5095 5100 5115

2 5115 5120 5125

3 5125 5130 5135

4 5135 5140 5145

5 5145 5150 5155
NASA/CR—2010-216324 75

C-band AeroMACS hardware units that are installed at BS and SS test bed sites are shown in 

Figure 27. The BTS sector outdoor unit is highly integrated, with each outdoor unit containing two 90° by 

8° sector-coverage antennas for second-order diversity operation and RF and digital circuitry for all radio 

and digital processing functions. The SS outdoor unit is similarly integrated, having two integrated highgain antennas, C-band radios, and digital processing electronics.

Figure 27.—NASA–CLE CNS Test Bed base transceiver 

station (BTS) and subscriber station (SS) outdoor units.

Second-order diversity operation is implemented in each AeroMACS transceiver in a MIMO 

configuration. Each transceiver has 2×2 MIMO: two transmitters and two receivers operating in the 

transmit/receive TDD mode. Each transmitter/receiver pair is connected to one of the two internal 

antennas. The antennas operate in a cross-polarization mode so that two independent propagation paths 

are formed.

The test bed SS transceivers also have two built-in cross-polarized antennas. This case uses 2×1 

MIMO: two receivers and a single transmitter are connected to the antennas to support diversity 

propagation paths.

The general specifications shown in Table 24 apply to the BTS and SS radios installed in the test bed. 

The radios operate in a TDD mode. The IEEE 802.16e-2005 standard specifies adaptive modulation 

coding that sets the modulation level from QPSK to 64−QAM, according to link conditions, in order to 

maximize data throughput rates. The standard specifies multicarrier orthogonal-frequency-division 

multiplexing (OFDM) modulation in the OFDMA mode which enables simultaneous data transfer from/to 

multiple applications through a single SS unit. Forward error correction (FEC) coding is adaptively set for 

coding rates between 1/2 and 5/6 for the chosen modulation level to maximize the data throughput for the 

current link conditions.

TABLE 24.—GENERAL RADIO SPECIFICATIONS

Item Description

Operation mode Time-division duplex (TDD)

Modulation Orthogonal-frequency-division multiplexing (OFDM) modulation, 1024/512 fast Fourier transform 

points, quadrature phase-shift keying (QPSK), 16 quadrature amplitude modulation (QAM), 64−QAM

Access method Orthogonal-frequency-division multiple access (OFDMA)

Forward error 

correction (FEC)

Convolutional turbo coding: 1/2, 2/3, 3/4, and 5/6
NASA/CR—2010-216324 76

Table 25 shows specifications for each single-sector BTS outdoor unit implemented in the NASA–

CLE CNS Test Bed. Each outdoor unit is tunable over a wider frequency range than is needed for the 

present AM(R)S allocation of 5091 to 5150 MHz and supports operation in the 5000- to 5030-MHz 

segment if it is allocated to AM(R)S. Channel bandwidths can be set for 5 or 10 MHz in the initial test 

bed hardware, with a planned upgrade that would include 20-MHz channel bandwidth capability. The 

built-in antennas provide two high-gain directive patterns with orthogonal polarization to support dualchannel second-order diversity MIMO operation for improved link sensitivity. Operating frequency and 

channel bandwidth are controlled by configuration parameters that are set up in the CNS core server by 

the network operator.

TABLE 25.—5100-MHz BASE TRANSCEIVER STATION SPECIFICATIONS

Frequency, GHz................................................................................................... 4.900 to 5.350

Supported bandwidths, MHz ............................................. 5 and 10 (20 after future expansion)

Transmitter (Tx) power range, dBm.....................................................0 to 21 (in 1-dBm steps)

Tx power accuracy, dB.......................................................................................................... ± 1

Maximum input power (at antenna port), dBm

Before saturation............................................................................................................. –50

Before damage ................................................................................................................ –10

Diversity .......................................................................................Second order (multiple input,

multiple output, MIMO)

Antenna pattern .......................................................... 2 by 15 dBi in the 4.9- to 5.9-GHz band, 

90° azimuth by 8° elevation 

sector antenna,

dual-slant ±45° polarization

Height by width by depth, mm ......................................................................510 by 280 by 147

Weight, kg ........................................................................................................................... 10.7

Power source, Vdc......................................................................................................... 40 to 60

Similar to the BTS outdoor unit, the SS outdoor unit is highly integrated with RF and digital 

electronics and a dual-polarization antenna in a single package. The antenna description is provided in 

Table 26. SS unit operating frequency, channel bandwidth, and transmit power level are all controlled by 

the BS it connects to within the network.

TABLE 26.—C-BAND SUBSCRIBER 

STATION SPECIFICATIONS

Polarization ............................................................... Dual slant

Gain, dBi............................................................................... 17

Beamwidths................................. 24° azimuth by 18° elevation
NASA/CR—2010-216324 77

Mobility tests will initially be conducted with an SS installed in Glenn’s Terrestrial Hybrid 

Environment for Verification of Aeronautical Networks (THEVAN, Figure 28) or a similar vehicle. 

SS hardware that has been modified to support an external antenna will be installed. Link coverage will 

be provided with an antenna with omnidirectional azimuth coverage mounted on top of the van. 

Figure 28.—Glenn’s mobile test vehicle: THEVAN.

NASA Glenn’s Viking S3 aircraft (Figure 29) is available for mobility tests and demonstrations in an 

aircraft mobile environment. Tests will be conducted while the aircraft is taxiing on the CLE airport 

surface. Again, modified SS hardware that supports the use of external antennas will be used.

Figure 29.—Viking S–3 mobile platform. 
NASA/CR—2010-216324 78

6.2 Simulation, Emulation, and Testing Results and Evaluation

Evaluation of the C-band IEEE 802.16-based AeroMACS network installed in the NASA–CLE CNS 

Test Bed consists of a study of system tradeoffs, link performance analysis, and performance test 

measurements of the installed network. This report presents an analysis of the test bed configuration layout 

shown in Figure 25 and Figure 26. The test bed was analyzed using the Cellular Expert analysis program 

developed by HNIT–BALTIC. Analysis results are followed by results of over-the-air tests for the same test 

bed configuration along with comparisons between analysis predictions and actual network performance.

6.2.1 Network Simulation Evaluation Results

The Cellular Expert analysis program was used to predict AeroMACS performance for the NASA–

CLE CNS Test Bed installation. This tool can predict data throughput rates that are achievable for 

locations across the airport surface. The program utilizes the parameters of the IEEE 802.16e hardware 

and the radio signal propagation properties, which are affected by antenna mounting heights, ground 

terrain profiles, and shadowing caused by buildings and structures. Results are based on analysis of the 

as-installed bed network and a summary report completed by Alvarion (Internal report: BreezeMAX 

Extreme. Nortel Govt. Solutions. Radio Network Plan Report. Alvarion Technical Report, ITT/FAA, 

Sept. 4, 2009).

The Radio Network Plan included the following simulations and procedures:

• The BS antenna sector pointing was analyzed.

o Azimuth pointing angles were determined manually.

o Antenna down-tilt angles were selected to provide the widest coverage area on the airport 

surface.

• 3D representations of buildings and structures were entered to add accuracy to the coverage 

predictions.

• Plots of signal strength and best sector grids were run after the sectors were arranged.

• Plots were run at 12- and 25-ft SS mounting heights to account for the varying mounting heights 

used in the test bed.

• Channel frequency plans were validated within the available 5100-MHz AeroMACS spectrum.

Figure 30 is an aerial map of the Glenn and CLE properties with building footprints that were 

included in the model highlighted. 
NASA/CR—2010-216324 79

Figure 30.—Cleveland Hopkins International Airport with building footprints highlighted. Primary CPE refers to 

customer premise equipment—referred to as subscriber stations (SSs) in other places in this document. Acronyms 

are defined in Appendix A.

The analysis used the BTS sector and SS performance parameters summarized in Table 25 and 

Table 26. The channel assignments and antenna pointing angles are defined in Table 27. Center frequency 

assignments used for the BTS sectors in the analysis are defined in Table 28. The frequency assignments 

used in the test bed physical implementation were similar to those used in this analysis but were shifted to 

conform to the AeroMACS profile.

TABLE 27.—BASE TRANSCEIVER STATION (BTS) SECTOR CONFIGURATIONS AT

NASA GLENN AND CLEVELAND HOPKINS INTERNATIONAL AIRPORT (CLE)

Base station Location Building Sectora Channel Azimuth,

deg

Tilt,

deg

Height,

m

1 Glenn 4 BTS1_1 F1 55 1 20

1 Glenn 4 BTS1_2 F5 200 1 20

2 CLE ARFFa BTS2_1 F2 45 1 10

2 CLE ARFFa BTS2_2 F4 185 1 10

2 CLE ARFFa BTS2_3 F3 295 1 10

a

Aircraft Rescue and Firefighting building.
NASA/CR—2010-216324 80

TABLE 28.—BASE STATION SECTOR CHANNELFREQUENCY ASSIGNMENTS FOR ANALYSIS

Channel Frequency center,

MHz

F1 5093.5

F2 5103.5

F3 5113.5

F4 5123.5

F5 5133.5

Figure 31 and Figure 32 show plots of DL (BS to SS direction) performance in the coverage area for 

12-ft and 25-ft SS mounting heights, respectively. The eight SS locations are indicated by yellow circles. 

Sensitivities are based on a fade margin of 10 dB. The color scale references the highest order of IEEE 

802.16e waveform modulation that can be supported for the signal level predicted to be present at each 

location. 

Figure 31.—Received signal strength indication (RSSI) plot for 17-dBi directional subscriber station mounted at 12 ft. 

Acronyms are defined in Appendix A.
NASA/CR—2010-216324 81

Figure 32.—Received signal strength indication (RSSI) plot for 17-dBi directional subscriber station mounted at 25 ft. 

Acronyms are defined in Appendix A.

As stated, this analysis and results are based on a fade margin of 10 dB. This value is commonly 

applied to fade margin for fixed LOS microwave links. However, the value for fade margin assigned for 

analysis will affect the reliability of the link. A recommended use of the test bed is to conduct link 

experiments to learn the correct value to apply for a broadband C-band system in the airport environment. 

Analyzing mobile links will require a different fade margin, which should also be validated with test bed 

tests.

A comparison of the plots in Figure 31 and Figure 32 reveals little difference in performance for the 

two SS mounting heights. 64−QAM with an FEC code rate of 5/6, which results in the highest data 

throughput rates, is achievable over the majority of the airport surface. Exceptions to the highest 

modulation rate occur in areas where both BSs are shadowed from the SS by buildings. Varying levels of 

modulation are predicted in these regions, ranging from lower orders of QAM and FEC coding, down 

through QPSK, with small regions with no link support. A region of shadowing is predicted to occur on 

the north side of the airport terminal buildings where LOS to both BSs is blocked by the buildings. In 

design of an operational AeroMACS network, the system designer may choose to locate the airport-side 

BS in a position that will provide more complete coverage in the terminal area, to include an additional 

BS for terminal coverage, or in the future, to make use of repeater stations as specified in the IEEE 

802.16j amendment (Ref. 63) that is currently in development.
NASA/CR—2010-216324 82

A best sector plot is shown in Figure 33. This plot indicates which BTS sector provides the best link 

sensitivity to a SS. The calculations demonstrate that each sector supports at least one SS. For compareson, Figure 34 illustrates the BTS sector that is closest to each SS location. The shadowing effects of 

building structures cause the closest sector to not necessarily be the optimal choice for link performance.

Figure 33.—Connection map for each subscriber station based on received signal strength indication (RSSI). 

Acronyms are defined in Appendix A.
NASA/CR—2010-216324 83

Figure 34.—Connection map for each subscriber station based on nearest base transceiver station (BTS) sector. 

One SS location, the Aviation Services Hangar (ASH) on the CLE property, is on the edge of 

coverage from the BS at Glenn’s Building 4 and is shadowed from the BS at CLE’s ARFF building. 

However, because the SS at this location will be mounted 40 ft above the ground level, it will provide a 

clear LOS view over the airport terminal building to the BS at Glenn’s Building 4. 

6.2.2 Network Test and Evaluation Results

For the AeroMACS network, two BS locations were added to the NASA–CLE CNS Test Bed on 

opposite sides of the airport runways in order to provide wide coverage over the airport surface. Network 

operational redundancy results because each SS typically has both BSs within view and is able to link to 

either BS. An interruption of the established link, caused by blockages or obstructions, will cause the SS 

to use its mobility handoff capability to rapidly reestablish its data flow through the other BS. This 

capability may not be required, depending on the reliability requirements of applications, but it is 

available in the test bed for testing purposes.

For several practical reasons, SS locations were selected to match the sensor sites of the original 

Sensis Corporation MLAT surveillance test bed. These sites provide IP data streams from already 

installed data sensors, provide simplified installation, and have electrical power sources already available 

to power the SSs. In addition to the sensor data sources, a single-board computer is co-located at each SS 

site to provide known data streams for evaluating AeroMACS link performance.

All network hardware planned for initial test bed modifications has been installed at Glenn and CLE 

as described in the following list. Remote unit (RU) designators provided in the following descriptions 
NASA/CR—2010-216324 84

correspond with the RU numbers assigned by Sensis Corp for their original MLAT surveillance test bed 

and can be referenced on the airport layout diagrams (Figure 25 and Figure 26). 

Glenn Installation Sites

• Building 500 roof (RU08)

o SS unit

o Support electronics enclosure for SS with a managed Ethernet switch, single-board computer, 

and power supplies

• Building 4 roof (RU07)

o SS unit

o Support electronics enclosure for SS with a managed Ethernet switch, single-board computer, 

and power supplies

o 11-GHz wideband microwave backhaul link outdoor unit to connect this BS to the core server 

in Building 110

• 80-ft radio tower adjacent to Building 4 (RU07)

o BS with two BTS sectors mounted at 60 ft above the ground level

o Two Global Positioning System (GPS) outdoor units mounted at 66 ft above the ground level 

to support the BTS outdoor units

• Building 4 copier room

o Equipment rack with BTS power supplies, managed Ethernet switch, and microwave 

backhaul link indoor unit and power supply

• Building 110, Room 310 

o Equipment rack with the following CNS and data backhaul functions

– Nortel 4134 secure router

– Authentication, authorization, and accounting (AAA) server

– Network Management System server

– Data backhaul indoor units for links to Building 4 and ARFF building

– Power supplies for servers and backhaul radios 

– Single-board-computer connected to 4134 secure router

Cleveland Hopkins Airport Installation Sites

• ARFF building roof (RU08)

o BS with three BTS sectors mounted on a nonpenetrating roof-mount antenna mast

o Three GPS outdoor units mounted on antenna mast above BTS outdoor units

o 11-GHz wideband microwave backhaul link outdoor unit to connect this BS to the core server 

in Building 110 mounted on the antenna mast

• ARFF building inside observation desk

o Equipment rack with BTS power supplies, managed Ethernet switch, microwave backhaul 

link indoor unit and power supply

• ASH roof (RU01)

o SS mounted to roof-top support beams

o Support electronics enclosure for SS with a managed Ethernet switch, single-board computer, 

and power supplies mounted to roof-top support beams

• Terminal C roof (RU02)

o SS mounted to Sensis equipment rack

o Support electronics enclosure for SS with a managed Ethernet switch, single-board computer, 

and power supplies mounted to Sensis equipment rack

• Glycol Tank support building (RU03)

o SS mounted on external wall facing runways
NASA/CR—2010-216324 85

o Support electronics enclosure for SS with a managed Ethernet switch, single-board computer, 

and power supplies mounted on external-wall-facing glycol tanks

• Snow Barn building (RU04)

o SS mounted near roof line

o Support electronics enclosure for SS with a managed Ethernet switch, single-board computer, 

and power supplies mounted inside of the building

• Approach lighting with sequenced flashing lights (ALSF) tower near ALSF building (RU05)

o SS mounted on tower section

o Support electronics enclosure for SS with a managed Ethernet switch, single-board computer, 

and power supplies mounted on short tower

• Consolidated Maintenance Facility (building RU06)

o SS mounted on roof edge near Sensis antennas

o Support electronics enclosure for SS with a managed Ethernet switch, single-board computer, 

and power supplies mounted inside of building

Figure 35 to Figure 43 are photographs of AeroMACS hardware installations with key components 

highlighted. Figure 35 shows the BS and data backhaul radio outdoor unit at Glenn’s Building 4 (hangar). 

Two BS outdoor units with built-in sector-coverage antennas are mounted 60 ft above the ground level on 

the radio tower that already existed beside Building 4. A GPS outdoor unit is mounted to the tower 6 ft 

above each BTS outdoor unit. GPS signals are used by the BTS outdoor units for precise timing and 

coordination of their transmit/receive operation.

Figure 35.—Base transceiver station (BTS) sectors, Global Positioning System (GPS) receivers, and 

data backhaul installation at Glenn Building 4.
NASA/CR—2010-216324 86

Figure 36 shows the BTS and data backhaul equipment rack that is located in the copier room on the 

second level of Building 4. The Lambda 48-Vdc supply powers the 11-GHz data backhaul indoor unit and 

outdoor unit. Two 55-Vdc power supplies running on 220 Vac are inside the rack that power the BTS 

sector radios through a Power-over-Ethernet (PoE) cable that also carries BS data traffic. 

Figure 36.—Base transceiver station (BTS) and data backhaul equipment rack at Glenn’s Building 4.
NASA/CR—2010-216324 87

Figure 37 shows an SS at Glenn’s Building 500. The SS radio and the SS electronics enclosure are 

mounted to the equipment rack that was installed by Sensis Corp. during the original test bed build. SS 

installations at Glenn’s building 4 and at CLE’s Concourse C are similar: the SS hardware is mounted to 

an existing equipment rack. The other five SS installations use varying methods of mounting SS 

equipment to existing structures.

Figure 37.—Subscriber station and enclosure at Glenn’s Building 500.

In Figure 37 the SS outdoor unit is pointed toward the BS near Glenn’s Building 4. The electronics 

enclosure is mounted on the opposite end of the equipment rack. The remaining enclosures are from the 

original installation and are not related to the AeroMACS network.
NASA/CR—2010-216324 88

Figure 38 shows the internal components of an electronics enclosure during installation. Therefore, 

not all internal cabling is shown in this photograph. Identical electronics enclosures are installed at all SS 

installation sites.

Figure 38.—Internal electronics of subscriber station enclosure.

The SS power supply in the lower right-hand corner of the enclosure runs on 110 Vac and provides 

48 Vdc as PoE. Above the SS power supply is an Ethernet input/output board with a single-board 

computer beneath it. The single-board computer uses a Linux operating system and hosts Chariot test 

software from Ixia. Chariot can be controlled through the network to generate and receive test data 

streams that are used to evaluate AeroMACS link performance. A lightning arrestor for PoE lines to the 

SS is shown in the upper left-hand corner.

The managed Ethernet switch in the upper left-hand corner provides connections for the SS, the 

single-board computer, and up to two other devices that have an IP-based Ethernet interface. Connection 

is with a standard RJ–45 connector. This will be the interface to the MLAT surveillance sensors.

The enclosure includes provisions for environmental control to protect the internal components. A fan 

is visible in Figure 38 that is on a temperature sensor and draws outside air into the enclosure above a set 

temperature. In addition, heating elements are mounted behind the aluminum mounting plate that are 

activated at a set low temperature.
NASA/CR—2010-216324 89

Figure 39 shows the 11-GHz data backhaul radio outdoor unit located on the roof of Glenn’s 

Building 4 during installation. This radio is part of the link that backhauls data with a similar radio on the 

roof of Glenn Building 110. Figure 40 shows the Glenn Building 110 end of this link and a second 

backhaul radio that supports the link to the BS located at CLE’s ARFF building.

Figure 39.—11-GHz backhaul radio outdoor units at Glenn’s Building 4 and Building 110.
NASA/CR—2010-216324 90

Figure 40.—11-GHz backhaul radio outdoor units at Glenn Building 110 with links to 

Glenn Building 4 base station (BS) and to Cleveland Hopkins International 

Airport’s (CLE) Airport Rescue and Firefighting (ARFF) building.
NASA/CR—2010-216324 91

The airport-side BS is located on the roof of the ARFF building observation deck as shown in 

Figure 41 with a closeup view of the antenna mast and mounted components shown in Figure 42. The 

closeup view clearly shows the nonpenetrating roof-mount antenna mast that supports AeroMACS 

outdoor unit components and the 11-GHz backhaul radio that is pointed toward Glenn Building 110. 

Figure 41.—Aircraft Rescue and Firefighting (ARFF) building base station 

on observation deck roof.
NASA/CR—2010-216324 92

Figure 42.—Detailed view of base station at Aircraft Rescue and Firefighting 

(ARFF) building. Acronyms are defined in Appendix A.

Three IEEE-802.16e-compliant AeroMACS BS radios are mounted to the mast: each on a standoff 

arm. The separation of the standoff arms increases RF isolation between units and decreases the potential 

for in-band interference. The 11-GHz backhaul radio with its 2-ft-diameter dish antenna is mounted on 

the mast above the AeroMACS radios. Three GPS outdoor units are mounted on a bar above the backhaul 

radio at the top of the antenna mast. The GPS outdoor units support the three AeroMACS radios for 

precise timing with one GPS outdoor unit connected per radio.
NASA/CR—2010-216324 93

The equipment shown in Figure 43 comprises the network core where data are aggregated from BSs 

and SSs and then disseminated to various data users. The equipment is a combination of power 

management breakers and switches, indoor units for the two data backhaul radios and their power 

supplies, computer servers to host the CNS functional software, and a secure Ethernet router. 

Figure 43.—Core server equipment in Glenn’s Building 110, Room 310. Acronyms are defined in Appendix A.
NASA/CR—2010-216324 94

The network architecture illustrated in Figure 44 can be used to understand the functions of the 

servers and secure router in the core network. The equipment rack (shown in Figure 43) includes one 

server more than is needed to host the CNS functions because one server was found to be able to host 

both the Network Management System (NMS) and the AAA functions. The major CNS functions and 

their corresponding programs are described in the following paragraphs.

Figure 44.—IEEE 802.16e core network diagram. Acronyms are defined in Appendix A.

AlvariStar is a telecommunications-class NMS for managing commercial Mobile WiMAX BSs and 

supports the operation of AeroMACS network BSs without modification. AlvariStar supports common 

network management applications in compliance with telecom industry standards, providing 

comprehensive fault, configuration, performance and security management functionality. It provides 

network surveillance, maintenance, and fault-handling capabilities. AlvariStar is designed to support a 

variety of system architectures ranging from a single-airport size of network where AlvariStar resides on 

a single computer server, to a fully distributed system that would support multiple airports.

Alepo software provides AAA functions for commercial Mobile WiMAX networks and can be used 

to operate an AeroMACS network without modification. When an SS requests entry into the AeroMACS 

network, Alepo refers to a preprogrammed data base, validates the SS identity, and authorizes or rejects 

entry into the network. For SSs that are allowed entry, Alepo determines from its data base the level of 

QoS that the network should provide. Alepo is fully compliant with the IEEE 802.16e and WiMAX 

Network Working Group standards.

VLAN 16

VLAN 2

4134 Secure 

Router 

AlvariStar 

BTS Control

and Alepo AAA

Server #1

Star ACS 

SS Control

Server #2

PC Laptop with 

IxChariot Console

application

7 /8

CLE ARFF Bldg

BTS Sector 1

BTS Sector 2

BTS Sector 3

VLAN 64

VLAN 54

NASA Bldg 4

BTS Sector 1

BTS Sector 2

VLAN 64 

Internet

Ceragon Trango

DHCP application

Access to

Networkk

Ceragon Trango

Ethernet

Switch

7/3

7/2 7/1

Ethernet 

Switch

7 /4

Verizon

(Cradlepoint)

Wireless Router 

0/2

VLAN 54

VLAN 2

11 GHz Data Backhaul
NASA/CR—2010-216324 95

The Star Automatic Configuration Server (StarACS) provides a unified and standardized system for 

managing a variety of SSs. Developed for the commercial WiMAX industry, StarACS will support 

AeroMACS SSs without modification. It provides mass configuration updates, software upgrades, 

maintenance, and troubleshooting of SSs through the network, and integrates with higher-level NMSs.

Figure 44 identifies the interconnections between components of the AeroMACS network that was 

added to the NASA–CLE CNS Test Bed. At the center of the system is the Nortel 4134 secure router that 

enables secure virtual local area network (VLAN) data paths to be established through virtual private 

network (VPN) routes. With this capability, VLAN data channels can be established end-to-end through 

the AeroMACS network from an SS to an Ethernet port on the secure router that is kept private and 

secure from all other VLAN channels.

A data path between the SSs and a port on the 4134 secure router is established on VLAN 54 in order 

to connect the AeroMACS network to the laptop personal computer (PC) that hosts Ixia Chariot test 

software and controls network tests. Additional user IP ports at the secure router can be established for 

data-path connections through the AeroMACS network. 

In addition to the data plane, a control plane is established on a separate VLAN through the 4134 

secure router. In this manner, control traffic from the AlvariStar, Alepo AAA, and StarACS applications 

is segregated through the network on VLAN 16. In addition, VLAN 2 carries traffic over an Internet 

connection to the laptop PC for remote access to the PC. The Internet connection in Cleveland is provided 

by a Verizon modem. The Internet connection is isolated from the rest of the AeroMACS network though 

the use of a VLAN channel to the PC.

A private VLAN data channel will be established through the network to carry data between SSs 

connected to the Sensis Corp. MLAT sensor sites and a data port on the secure router. All MLAT system 

sensor data will be available for MLAT processing with the data transported to the processors over a 

suitable IP-based connection.

6.2.3 Network Evaluation Test Plan

The testing and evaluation of the IEEE 802.16e network can be grouped into two sets:

(1) Baseline performance tests within the project scope that will be reported in this document.

(2) A set of tests designed to support development of an aviation profile and evaluate the support of 

FAA applications

6.2.3.1 Baseline Performance Test Cases

Eleven network tests have been defined to establish the basic operating capability of the IEEE802.16e-based capability that was added to the NASA–CLE CNS Test Bed. The tests establish operating 

capability in the following areas of network operation.

• Security with authentication and encryption

• Data throughput and channelization

• QoS data prioritization

• Mobility at motor vehicle speeds

• Reliability during extended operation

The 11 baseline test cases and their intended objectives follow:

Test case 1—Network entry with authentication and data transfer

The purpose of this test is to verify that a service flow is successfully created when an SS enters the 

network and that the service flow is removed completely when the SS exits the network. This test case 

also verifies that a valid user ID and/or password are required to successfully enter the network. 

Furthermore, this test case verifies that a bidirectional path (UL/DL) is successfully set up after 

network entry.
NASA/CR—2010-216324 96

Test case 2—QPSK throughput, UL and DL

This test case verifies the baseline maximum throughput from LOS within the sector using QPSK 1/2 

modulation. For this test case, LOS will also include near or partial LOS.

Test case 3—16-QAM throughput, UL and DL

This test case verifies the baseline maximum throughput from LOS within the sector using 

16−QAM 1/2 modulation. For this test case, LOS will also include near or partial LOS.

Test case 4—64-QAM throughput, DL

The purpose of this test is to verify the baseline maximum throughput from LOS within the sector 

using 64−QAM 1/2 modulation on DL. For this test case, LOS will also include near or partial LOS.

Test case 5—Sector capacity with multiple SSs

This test demonstrates the operation of multiple SSs within a sector to test the maximum throughput 

capacity of a single sector and the capability of a sector to handle terminal “network entries” in congested

conditions.

Test case 6—Multiple BTS throughput

This test demonstrates the operation of multiple SSs across multiple sectors to test the maximum 

throughput capacity of multiple BTSs and the capability of multiple sectors to handle terminal “network 

entries” in congested conditions.

Test case 7—QoS—DL non-real-time (nRT) prioritization over best effort with two terminals

This is a data prioritization test to verify the handling of data on the DL that has been classified as 

high priority. It will verify that an nRT protocol data stream is prioritized over a best-effort data stream 

when both data types are sent to the same SS. 

Test case 8—QoS—UL nRT prioritization over best effort with two terminals

This is a data prioritization test to verify the handling of data on the UL that has been classified as 

high priority. It will verify that an nRT protocol data stream is prioritized over a best-effort data stream 

when both data types that are sent originate from the same SS. 

Test case 9—Intrasector mobility with link adaptation

This tests the ability to maintain a User Datagram Protocol (UDP) traffic stream while mobile in a 

single BTS sector with link adaptation enabled. This test will demonstrate the network’s ability to switch 

between QPSK, 16−QAM, and 64−QAM using adaptive modulation and coding.

Test case 10—Intersector mobility with link adaptation

This test evaluates BTS handover ability for a mobile SS that moves over multiple sectors and to 

maintain a UDP traffic stream while moving about multiple sectors with link adaptation enabled. This test 

will demonstrate the network’s ability to switch between QPSK, 16−QAM, and 64−QAM using adaptive 

modulation and coding.

Test case 11—Long-term stability test

This is an extended-operation test to verify network stability by periodically sending and receiving 

data bursts.
NASA/CR—2010-216324 97

6.2.3.2 Experiment and Test Plan to Validate Tradeoff Space and Application Support

The NASA–CLE CNS Test Bed, modified to include an AeroMACS communications network, will 

be used to evaluate various combinations of parameters within the IEEE 802.16 standard in order to 

validate the tradeoff space for an AeroMACS profile. The airport surface presents a unique combination 

of areas of open terrain around the runways, which have few obstacles to cause multipath and signal 

diffraction, and terminal and building areas, which have high levels of multipath dispersion and 

diffraction. Added to these contrasting propagation environments is the operation of AeroMACS at the 

upper end of the IEEE 802.16e frequency span of 2 to 6 GHz, where signal wavelengths are shorter and 

multipath effects are increased.

Table 29 presents a collection of test cases designed to evaluate AeroMACS parameters in the airport 

environment. The “Design tradeoff category” column defines broad parameter categories, whereas the 

“Parameters” column lists detailed parameters within the category. The “Evaluation test” column 

describes test conditions for exploring the tradeoff space of a category. 

TABLE 29.—EXPERIMENTS AND TEST PLAN TRADEOFF SPACE

Design tradeoff 

category

Parameters Evaluation test

Base station (BS) Mounting placement Analyze or simulate

Verify analysis or simulation model

Survey signal strength across airport surface

Determine line of sight (LOS) and non line of sight (NLOS)

Number of BSs and base 

transceiver station (BTS) sectors

Analyze, considering coverage area and composite throughput

Multiple input, multiple output 

(MIMO) order

Test without MIMO

Test with up to 2×2 MIMO

Test with N×N MIMO

Test with LOS and with NLOS or blockage

Antenna polarization Evaluate internal cross-polarization antennas versus external 

spatially separated antennas

Maximum cell range Extend with Media Access Control (MAC) changes within 

Institute of Electrical and Electronics Engineering (IEEE) 

802.16e specification

Evaluate IEEE 802.16m amendment

Controlled-pattern antennas Test with advanced BTS sector antennas

Identify and evaluate steerable multibeam antennas

Frequency band Analyze minimum spectrum versus needed throughput

Spectrum co-user interference 

(i.e., Globalstar satellite)

Analyze
NASA/CR—2010-216324 98

TABLE 29.—EXPERIMENTS AND TEST PLAN TRADEOFF SPACE

Design tradeoff 

category

Parameters Evaluation test

Subscriber station 

(SS)

Mounting height Analyze 

MIMO order Test without MIMO

Test with up to 2×2 MIMO

Test with N×N MIMO

Antenna polarization Evaluate internal cross-polarization antennas versus two 

external single-polarization antennas

Maximum cell range Extend with MAC changes within IEEE 802.16e specification

Evaluate IEEE 802.16m amendment

Frequency band Analyze minimum spectrum versus needed throughput

Test frequency reuse methods including N = 1 (all sectors on 

same center frequency)

Spectrum co-user interference 

(i.e., Globalstar satellite)

Analyze on the basis of power class requirements and 

frequency reuse method

Channel bandwidth Throughput rate Test mixed mobile SS and fixed SS traffic including

• Sources of highest expected data rate

• Channel bandwidths of 5, 10, and 20 MHz

Mobility performance Test mobility throughput over speed range and cell radius 

including

• Multiple mobile SS

• Channel bandwidths of 5, 10, and 20 MHz

Multipath performance Evaluate performance in terminal area

Evaluate mobile performance in building areas

Efficient use of spectrum Evaluate multiple mobile SS operation concurrent with fixed 

SS of differing data streams

Hardware limitations Test throughput versus expected at 20-MHz bandwidth

Modulation Adaptive or fixed Measure mobility throughput measurements across cell radius 

with fixed high and low modulation rates

Modulation rates Compare measured versus expected throughput versus 

modulation coding rate, including

• Ranges from cell center to cell edge

• LOS and NLOS

Forward error correction (FEC) 

coding rate

Compare measured versus expected throughput versus error 

coding rate, including

• Ranges from cell center to cell edge

• LOS and NLOS

BTS power class Fade margin allowance Test long-term LOS throughput

Conduct mobility tests in NLOS and high-multipath conditions

Co-interference Test throughput versus power between isolated sectors at the 

same center frequency in a frequency-reuse system

Spectrum co-user interference 

(i.e., Globalstar satellite feeder 

uplinks)

Analyze interference on the basis of minimum power required 

to provide coverage across airport surface

Range Determine cell radius versus number of BSs

Power amplifier power-output 

limitations

Analyze
NASA/CR—2010-216324 99

TABLE 29.—EXPERIMENTS AND TEST PLAN TRADEOFF SPACE

Design tradeoff 

category

Parameters Evaluation test

SS power class Fade margin allowance Test long-term LOS throughput

Conduct mobility tests in NLOS and high-multipath conditions

Spectrum co-user interference 

(i.e., Globalstar satellite uplinks)

Analyze interference on the basis of minimum power required 

to provide coverage across the airport surface

Range Determine cell radius versus the number of BSs

Power amplifier power-output 

limitations

Analyze

MAC layer and 

physical layer (PHY)

Maximum mobile speed Conduct high-speed mobility tests for throughput and dropouts

Repeater operation

(IEEE 802.16j)

Test IEEE-802.16j-enabled BS when available for filling in 

poor coverage areas, including

• Outside cell radius

• NLOS regions

Transmitter/receiver time-division 

duplex (TDD)/frequency-division 

duplex (FDD) mode

Analyze

Quality of service 

(QoS)

Time delay Measure end-to-end time delay through AeroMACS network 

from SS input through communication, navigation, and 

surveillance (CNS) output port for all five QoS levels

Time jitter Measure end-to-end time jitter through AeroMACS network 

from SS input through CNS output port for all five QoS levels

Message priority Test high QoS and best-effort traffic

Test until throughput overload

Verify that high QoS priority is maintained

Scheduling Test high QoS and best-effort traffic

Measure statistics of scheduling accuracy

Measure scheduling performance as throughput is increased to 

overload

Message integrity Test high QoS and best-effort traffic

Test continuous and burst traffic

Verify packet error rate and that there are no dropped packets 

for high QoS traffic

6.2.4 Network Evaluation Test Results

At the time of this writing, the AeroMACS radio link between the SS on the roof of Glenn 

Building 500 and the two BTS sectors at Glenn Building 4 had been evaluated. The link to BTS1_1 sector 

is LOS with a distance of approximately 775 m. The SS is within the main lobe of the BTS1_1 sector 

antenna. For the second link, the SS is behind the BTS1_2 sector outdoor unit and in its antenna side 

lobes. However, the signal strength for the second link was still adequate to support the highest 

modulation level of the 64−QAM, 5/6 code rate. 

Iperf network performance software was used in these tests to simulate traffic across the radio link. 

Iperf is an open-source application that generates Transmission Control Protocol (TCP) and UDP packets 

to measure network performance. 
NASA/CR—2010-216324 100

The following parameters were set for the link tests: 

Service pipe for the SS

• Service type, Ethernet Layer 2

• QoS type, best effort

• Connection time, short

• Committed information rate, 7 Mbps

Test conditions

• Channel bandwidth, 5 MHz

• Received signal strength indication (RSSI), >−70 dBm

• Signal-to-noise ratio, >24 dB

• Modulation, 64−QAM 5/6

• MIMO, 2×2 at BTS sectors, 2×1 at SS

• Test computer hosting Iperf connected to the data interface on the BTS

• Test computer hosting Iperf connected to the SS Ethernet port

• TDD ratio, 60 percent (DL): 40 percent (UL)

Procedure

• Run the Iperf performance software server on the computer at the BTS.

• On the computer connected to the SS, execute a throughput test using the parameters in Table 30.

TCP test—This will simulate upstream and downstream traffic using the File Transfer Protocol

(FTP).

• Server-side, Iperf –s –w64k –il

• Client-side, Iperf –c [Server IP Address] –t60 –w64K –i1 –P2

In total, the parameters listed in Table 30 affect the net data throughput that can be achieved (Ref. 64). 

TABLE 30.—AeroMACS PARAMETER SETTINGS AFFECTING THROUGHPUT

BW Nominal channel bandwidth, 5, 10, or 20 MHz

Nused Number of subcarriers used (data and pilot subcarriers) 

Ndata Number of data subcarriers

n (Over-) Sampling factor, 8/7 or 28/25

G Ratio of cyclic prefix (CP) time to useful time (default G = 1/8) 

NFFT Fast Fourier transform size: smallest power of 2 greater than Nused (512 or 1024)

Fs Sampling frequency, Fx = floor (n × BW/8000) × 8000

Δƒ Subcarrier spacing, Δƒ = Fs/NFFT

Tb OFDM symbol time, Tb = 1/Δƒ

Tg Cyclic prefix (CP) time, Tg = G × Tb

Ts CP–OFDM symbol time transmitter, (Tx) = Tb + Tg = ( 1 + G ) × Tb

M QAM modulation order, 2(QPSK), 4(16−QAM), or 6(64−QAM)

rFEC FEC coding rate, 1/2, 2/3, 3/4, or 5/6

rRep Repetition code rate, 0, 2, 4, or 6
NASA/CR—2010-216324 101

The expected throughput performance under the conditions listed in Table 30 and under other settable 

parameters is estimated by the equipment manufacturer to be 6.5 Mbps in the DL direction from BS to SS 

and to be 4.0 Mbps in the UL direction from SS to BS. The expected values and actual throughput test 

results are compared in Table 31. The measured throughput exceeded the manufacturer’s estimated rates 

in all cases.

TABLE 31.—AeroMACS NASA–CLE TEST BED LINK TEST RESULTS

BTS sector Measured DL

throughput, 

Mbps

Expected DL

throughput, 

Mbps

Measured UL

throughput, 

Mbps

Expected UL

throughput, 

Mbps

BTS1_1 6.82 6.5 5.4 4.0

BTS1_2 6.54 6.5 4.19 4.0

6.3 Initial Input to Aeronautical Mobile Specific IEEE 802.16 Design Specification

The IEEE 802.16 standard (Ref. 65) defines system profiles that list sets of features that apply to 

particular implementation cases. The IEEE 802.16e amendment (Ref. 18) adding mobility also amended 

the system profile. For this reason, the IEEE 802.16 standard and the IEEE 802.16e amendment must be 

used together to create the AeroMACS profile. In this report, the IEEE 802.16 standard plus the IEEE 

802.16e amendment is referred to as IEEE 802.16(e).

6.3.1 AeroMACS Standard Profile

The IEEE 802.16 profiles to be evaluated here are limited in scope to functions of the MAC and PHY

reference model layers. In addition to these, profiles defined by the WiMAX Forum include parameters 

from higher-level reference layers. These added parameters define network and security functions, for 

example.

Features listed in the IEEE 802.16 standard and the IEEE 802.16e amendment are listed as 

“mandatory” or “optional” for use. Profiles do not change the “mandatory” status of features listed as 

such in the standard. Features listed as “optional” in the standard may be listed as “required” or 

“conditionally required” in a profile. Any “optional” feature in the standard that does not appear in a 

certain profile is “optional” for the profile. For this reason, absence of a feature in a specific 

implementation does not affect conformance to the profile. Optional features will be implemented as 

specified in the standard (Ref. 65).

Four system profiles are used to define sets of features that are a subset of IEEE 802.16 according to 

these four classes:

(1) Wireless municipal area network, single carrier (WirelessMAN-SC, 10 to 66 GHz)

(2) WirelessMAN and wireless high-speed unlicensed metropolitan area networks, single carrier 

access (WirelessMAN-SCa and WirelessHUMAN-SCa)

(3) WirelessMAN and WirelessHUMAN, OFDM (WirelessMAN-OFDM and WirelessHUMANOFDM)

(4) WirelessMAN and WirelessHUMAN, OFDMA (WirelessMAN-OFDMA and WirelessHUMANOFDMA)
NASA/CR—2010-216324 102

Table 32 examines the suitability of these four system profile feature sets for AeroMACS.

TABLE 32.—IEEE 802.16 STANDARD PROFILE FEATURE SETS

Profile set Evaluation as basis for AeroMACS profile

1. WirelessMAN-SC (10 to 66 GHz) Incorrect frequency range for AeroMACS operating in C-band

2. WirelessMAN-SCa and WirelessHUMAN-SCa Lacks the support for mobility needed for AeroMACS

3. WirelessMAN-OFDM and WirelessHUMAN-OFDM Lacks support for the mobility needed for AeroMACS (This is 

the profile for “Fixed WiMAX”.)

4. WirelessMAN-OFDMA and WirelessHUMANOFDMACorrect profile to use as basis for an AeroMACS profile; 

supports C-band, mobility, and multiple-use access

The WirelessMAN-OFDMA and WirelessHUMAN-OFDMA (profile 4) defines a wireless system 

with support for mobility. These are the feature-sets used by the WiMAX Forum to define Mobile 

WiMAX wireless service profiles and will be the basis for an AeroMACS profile. This not only provides 

the desired mobility performance, it allows equipment vendors to adapt commercially available off-the 

shelf hardware with minimum modifications. 

Note that in IEEE 802.16e, the WirelessMAN and WirelessHUMAN specification classes are 

contained in a common profile set. These specification classes are separated into separate profile sets in 

the IEEE 802.16-2009 standard. This report remains consistent as an analysis of the IEEE 802.16e 

standard and uses the combined class description.

6.3.2 System Profile Definition Method

The process for developing specification-level profile recommendations follows:

(1) Begin with system profiles defined in the IEEE 802.16-2004 standard and the IEEE 802.16e-2005 

amendment.

(2) Identify parameters in the system profile that must change to support C-band AeroMACS 

operation. The center-frequency definition is an example.

(3) Compare the resulting C-band system profile to requirements flowed down from ConUse and 

system studies, and identify areas that are not supported, if any.

(4) Recommend additional changes to the system profile or recommend areas for further research 

into parameters that will better meet requirements while examining the cost of requiring 

additional hardware changes.

6.3.3 System Profile Definitions

This subsection defines recommended profiles for systems operating with AeroMACS air interfaces. 

Any feature not mandatory or conditionally mandatory for a profile is optional for the profile except 

where otherwise forbidden by the IEEE 802.16(e) standard. Optional features shall be implemented as 

specified in the standard. Design consideration comments are provided in each subsection to provide 

guidance for operation within the ranges of parameters that are offered within the profiles. 

Table 33 defines four profiles for AeroMACS. AeroMACS_profM1 applies to all channel 

bandwidths. AeroMACS_profP1 to AeroMACS_profP3 apply to specific channel bandwidths.

TABLE 33.—AeroMACS PROFILE DEFINITIONS

Identifier Description

AeroMACS_profM1 Basic packet point-to-multipoint Media Access Control (MAC) profile

AeroMACS_profP1 Basic physical layer (PHY) profile for 5-MHz channel 

AeroMACS_profP2 Basic PHY profile for 10-MHz channel

AeroMACS_profP3 Basic PHY profile for 20-MHz channel
NASA/CR—2010-216324 103

Note that 5-MHz channels are not included in the IEEE 802.16(e) standard but are included in the 

WiMAX Forum profile. These channels are incorporated in the AeroMACS standard recommendation 

because the 5-MHz channel is the lowest multiple of the center frequency fc step and because it provides 

for more efficient use of the AeroMACS spectrum than wider channel bandwidths do. In addition, the 

5-MHz center frequency fc step size was chosen to be consistent with the IEEE 802.16e standard for 

5000-MHz unlicensed bands. This will facilitate hardware reuse by vendors. 

Although 5-MHz channel bandwidths will limit PHY and MAC performance in mobile and highmultipath environments and will limit the maximum data throughput available to each subscriber, the 

larger channel bandwidths will impair a system designer’s ability to efficiently use the 5091- to 5150-

MHz approved spectrum and the potential 5000- to 5030-MHz expansion band.

6.3.4 AeroMACS Power Class Profiles

The power class profiles recommended for AeroMACS correspond with those stated in Section 12.4.1 

of the IEEE 802.16 standard. A power class profile contains the classes of SSs (fixed-position and 

mobile) used in a system. A power class profile may contain transmitters from more than one class, with 

the profile indicating the highest power class permitted. The recommended power classes are listed in 

Table 34.

TABLE 34.—AeroMACS POWER CLASSES

Class Transmit power

dBm

1 17 ≤ PTx, max < 20

2 20 ≤ PTx, max < 23

3 23 ≤ PTx, max < 30

4 30 ≤ PTx, max

The power ratings PTx, max associated with these classes are the maximum average output power 

ratings at which the appropriate transmitter requirements in Section 8.4.12 of IEEE 802.16(e) are met.

Network system designers should use the following design considerations to minimize 

AeroMACS inference with coexisting in-band services:

• For mobile SSs, select the number of BSs and their placement to enable low power class 

operation of MSs within their roaming area.

• For fixed-site SSs, specify the use of high-directivity, high-gain fixed-site antennas to minimize 

the SS power class. 

• Use diversity propagation MIMO antenna systems for increased sensitivity with lower power 

class operation.

6.3.5 AeroMACS Media Access Control Profiles

The OFDMA_ProfM1 profile in Section 12.4.2 of the IEEE 802.16(e) standard is recommended for 

use in AeroMACS without modification. This MAC profile specifies mobile operation for WirelessMANOFDMA and WirelessHUMAN-OFDMA air interfaces. In particular,

• Using the OFDMA_ProfM1 profile without modification maximizes the reuse of commercial offthe-shelf hardware that is available for nearby licensed bands. Reuse of the profile gives system 

designers the flexibility to tailor performance for the airport environment with the parameter 

options that are available.
NASA/CR—2010-216324 104

• MAC parameters provide for mobile operation. The maximum speed supported in commercial 

Mobile WiMAX is generally on the order of 120 km/hr. However, the actual maximum speed 

depends on many factors, including the frequency of operation. Greater maximum speeds are 

possible with changes in MAC parameters at the expense of performance in other areas such as 

data throughput. Future studies regarding adjustments to MAC parameters are needed to 

accommodate increased mobility speeds. Studies must include a cost/benefit analysis to weigh 

changes in other performance parameters against the benefit of operation at increased 

operating speed.

• The IEEE 802.16m amendment planned for future release will include MAC modifications that 

will increase the maximum operating speed above that of IEEE 802.16e.

6.3.6 AeroMACS System Physical Layer Profiles

This subsection defines PHY profiles for systems operating with the AeroMACS air interfaces. We 

recommend that IEEE 802.16(e) PHY profiles be used without modification for all features except for 

FDD PHYs. FDD transmissions require the use of two separate channels; one for UL and the other for 

DL. These channels require adequate frequency separation so that the transmitter does not desensitize the 

receiver, which needs to operate simultaneously. Practical FDD systems separate the transmit and receive 

channels by at least 3 percent (Ref. 66), which exceeds the C-band AM(R)S allocation of 59 MHz.

The following PHY profile definitions define the minimum performance required for each channel 

bandwidth. These requirements are in addition to the minimum performance requirements needed for all 

profiles, as defined in Table 413 of the IEEE 802.16(e) specification.

6.3.7 Basic Physical Layer (PHY) Profile for the AeroMACS 5-MHz Channel 

A system implementing the AeroMACS_profP1 shall meet the minimum performance requirements 

listed in Table 35 (derived from the IEEE 802.16(e) specification).

TABLE 35.—BASIC PHY PROFILE FOR AeroMACS 5-MHz CHANNEL

[Acronyms are defined in Appendix A.]

Capability Minimum performance

Channel bandwidth, MHz 5

Operation mode Licensed AM(R)S 

C-band operation

Bit error rate (BER) performance threshold (BER = 10–6 if using all subchannels BS/SS)a Greater than or equal to

QPSK 1/2, dBm –85

QPSK 3/4, dBm –82

16−QAM 1/2, dBm –78

16−QAM 3/4, dBm –75

64−QAM 2/3 (if 64−QAM supported), dBm –71

64−QAM 3/4 (if 64−QAM supported), dBm –69

Reference frequency tolerance

BS

SS to BS synchronization tolerance, Hz

≤ ±2×10–6

≤22.5

Frame duration code setb {2, 4, 5} a

Add to sensitivity 10×log10 (number of subchannels in the BS receiver). b

See Table 232 of the IEEE 802.16(e) standard (Ref. 18).
NASA/CR—2010-216324 105

6.3.8 Basic Physical Layer (PHY) Profile for AeroMACS 10-MHz Channel 

A system implementing AerMACS_profP2 shall meet the minimum performance requirements listed 

in Table 36 (derived from the IEEE 802.16(e) specification).

TABLE 36.—BASIC PHY PROFILE FOR AeroMACS 10-MHz CHANNEL

[Acronyms are defined in Appendix A.]

Capability Minimum performance

Channel bandwidth, MHz 10

Operation mode Licensed AM(R)S Cband operation

Bit error rate (BER) performance threshold (BER = 10–6 if using all subchannels BS/SS)a Greater than or equal to

QPSK 1/2, dBm –82

QPSK 3/4, dBm –79

16−QAM 1/2, dBm –75

16−QAM 3/4, dBm –72

64−QAM 2/3 (if 64−QAM supported), dBm –68

64−QAM 3/4 (if 64−QAM supported), dBm –66

Reference frequency tolerance

BS

SS to BS synchronization tolerance, Hz

≤ ±2×10–6

≤55

Frame duration code setb {2, 4, 5} a

Add to sensitivity 10×log10 (number of subchannels in the BS receiver). b

See Table 232 of the IEEE 802.16(e) standard (Ref. 18).

6.3.9 Basic Physical Layer (PHY) Profile for AeroMACS 20-MHz Channel 

A system implementing AeroMACS_profP3 shall meet the minimum performance requirements 

listed in Table 37 (derived from the IEEE 802.16(e) specification).

TABLE 37.—BASIC PHY PROFILE FOR AeroMACS 20-MHz CHANNEL

[Acronyms are defined in Appendix A.]

Capability Minimum performance

Channel bandwidth, MHz 20

Operation mode Licensed AM(R)S 

C-band operation

Bit error rate (BER) performance threshold (BER = 10–6 if using all subchannels BS/SS)a Greater than or equal to

QPSK 1/2, dBm –79

QPSK 3/4, dBm –76

16−QAM 1/2, dBm –72

16−QAM 3/4, dBm –69

64−QAM 2/3 (if 64−QAM supported), dBm –65

64−QAM 3/4 (if 64−QAM supported), dBm –63

Reference frequency tolerance

BS

SS to BS synchronization tolerance, Hz

≤ ±2×10–6

≤ 110

Frame duration code setb {2, 4, 5}

a

Add to sensitivity 10×log10 (number of subchannels in the BS receiver). b

See Table 232 of the IEEE 802.16(e) standard (Ref. 18).
NASA/CR—2010-216324 106

6.3.10 AeroMACS Radiofrequency Profiles

This subsection defines proposed RF profiles for the AeroMACS air interfaces. Table 38 defines the 

RF channels for informative purposes. The channels shall be calculated using Equation (2):

Fstart + n • Δfc for all n in Nrange (2)

where

Fstart start frequency for the specified band

Δfc center frequency step

Nrange range of values for the n parameter

TABLE 38.—RADIOFREQUENCY PROFILE LIST FOR AeroMACS C-BAND

Radiofrequency profile Channel 

bandwidth, 

MHz

Center 

frequency step,a

Δfc,

MHz

Uplink 

(UL) start 

frequency,

Fstart, 

MHz

Downlink (DL) 

start 

frequency,b

Fstart,

MHz

Range of 

values for n, 

Nrange

AeroMACS_ProfR1 5 5 5000 N/A {19, 20, ..., 37}

AeroMACS_ProfR2 10 5 5000 N/A {20, 21, ..., 36}

AeroMACS_ProfR3 20 5 5000 N/A {21, 22, ..., 35}

AeroMACS_ProfR4c 5 5 5000 N/A {1, 2, ..., 5}

AeroMACS_ProfR5c 10 5 5000 N/A {1, 3, ..., 5}

AeroMACS_ProfR6c 20 5 5000 N/A {2, 3, ... 4} a

The minimum center frequency step Δfc is 5 MHz to match the IEEE 802.16(e) standard for the 5000-MHz frequency 

bands. The center frequency step Δfc of 5 MHz requires that the minimum channel bandwidth be 5 MHz and that 

channel bandwidths increase in multiples of 5 MHz.

b

DL Fstart = UL Fstart in a TDD system. c

Use of a profile is dependent on International Telecommunications Union (ITU) authorization.
NASA/CR—2010-216324 107

7.0 Final Requirements and Specifications Recommendations for the 

C-Band System

7.1 Final Performance Requirements Recommendations

Table 39 relates AeroMACS technical parameters, requirement source for each parameter, and the 

profile parameter area that is directly impacted. When a technical parameter is indicated as only 

impacting airport system design, the parameter will be finalized during the system design process for a 

new airport installation. For example, the number of BTS sectors to be used at a specific airport will be 

determined in the system design process using the range of settings that are available within the 

AeroMACS profile parameters. 

TABLE 39.—AeroMACS C-BAND RADIOFREQUENCY PROFILE LIST

Design tradeoff 

category

Technical parameters Affected process

IEEE 802.16e profile parameter area

Airport 

system 

design

Radiofrequency/

radio

Power 

class

Duplex 

mode

Physical 

(PHY)

design

Media 

Access 

Control 

(MAC)

design

Base station Placement/location/height x

Number of base 

transceiver station (BTS) 

sectors

x

Multiple input, multiple 

output (MIMO) order

x x x x x

Antenna polarization x

Maximum cell range x x

Controlled-pattern 

antennas

x x

Frequency band x x x

Spectrum co-user 

interference (i.e., 

Globalstar satellite)

x

Subscriber 

station

Mounting height x

MIMO order x x x

Antenna polarization x

Maximum cell range x x

Frequency band x x

Spectrum co-user 

interference (i.e., 

Globalstar satellite)

x

Channel 

bandwidth

Throughput rate x x

Mobility performance x x

Multipath performance x

Efficient use of spectrum x

Co-interference x

Hardware limitations x

Modulation Adaptive or fixed x x

Modulation rates x x

Forward error-correction 

(FEC) coding rate

x x
NASA/CR—2010-216324 108

TABLE 39.—AeroMACS C-BAND RADIOFREQUENCY PROFILE LIST

Design tradeoff 

category

Technical parameters Affected process

IEEE 802.16e profile parameter area

Airport 

system 

design

Radiofrequency/

radio

Power 

class

Duplex 

mode

Physical 

(PHY)

design

Media 

Access 

Control 

(MAC)

design

BTS power 

class

Fade margin x

Co-interference x

Spectrum co-user 

interference (i.e., 

Globalstar satellite 

uplinks)

x x

Range x

Line-of-sight (LOS) and 

non-line-of-sight (NLOS) 

operation

x x

Mobile operation x x

Power amplifier poweroutput limitations

x x

SS power class Fade margin x

Co-interference x

Spectrum co-user 

interference (i.e.,

Globalstar satellite 

uplinks)

x x

Range x

LOS and NLOS operation x

Mobile operation x

Power amplifier poweroutput limitations

x x

(MAC and 

PHY layers

Maximum mobile speed x

Repeater operation

(IEEE 802.16j)

x x

Transmitter/receiver timedivision duplex 

(TDD)/frequency-division 

duplex (FDD) mode

x

Quality of 

service (QoS)

Time delay x x x

Time jitter x x x x x

Message priority x

Scheduling

Message integrity x x x x x

However, the number of BSs is not an AeroMACS profile parameter because it will be highly 

dependent on airport geographic size and the assessment of total data throughput for the network. Other 

parameters, such as frequency band, do impact the AeroMACS profile parameter area in the areas of RF 

radio design and duplex mode.

The PHY and MAC designs will accommodate the system design space to a degree with the range of 

parameter settings that are within the profile. If an application requires a level of performance that cannot 

be met with PHY and MAC parameters within the profile, a redesign will need to occur that will move the 

AeroMACS hardware further away from being a simple modification to a commercial off-the-shelf 
NASA/CR—2010-216324 109

WiMAX. For example, requiring greater mobile speeds than can be provided with commercial off-theshelf WiMAX hardware will require a redesign of the PHY and MAC layers.

7.2 Final Input to Aviation-Specific IEEE 802.16 System Design Specifications

Table 40 summarizes the key parameter selections that are recommended for an AeroMACS standard 

profile. The five profile areas listed in Table 40 correspond with the five profile areas that distinguish 

mobile WiMAX profiles.

TABLE 40.—SUMMARY OF FINAL RECOMMENDATIONS FOR AeroMACS PROFILE

Profile area Key parameter selections

Radiofrequency and radio parameters

Frequency band, MHz

Channel bandwidths, MHz

Channel center frequencies

5091 to 5150 

5, 10, and 20

See Table 38

Power class

Maximum downlink transmitter (Tx) power

Maximum uplink Tx power

6.3.4 —Unchanged from IEEE 802.16(e)

6.3.4 —Unchanged from IEEE 802.16(e)

Duplex mode (time-division duplex (TDD) or frequency-division 

duplex (FDD)) TDD

Physical layer

M-ary quadrature amplitude modulation (QAM) range

Coding options

Multiple input, multiple output (MIMO)

Performance profiles—minimum performance 

defined in IEEE 802.16(e) and

Table 35 for 5-MHz channels

Table 36 for 10-MHz channels

Table 37 for 20-MHz channels

Media Access Control (MAC) layer

Automatic repeat request

Security protocols

Mobile protocols

Quality-of-service (QoS) options

Mesh options

All parameters unchanged from IEEE 802.16(e)

Special committee SC–223 was established within the RTCA aviation industry consortium to 

establish standards for AeroMACS. The principal products of this special committee are a set of system 

profile recommendations to be delivered in September 2010 and a Minimum Operational Performance 

Standards (MOPS) document to be delivered in September 2011. EUROCONTROL established a similar 

work group, WG−82, that is chartered to develop an AeroMACS profile. SC–223 and WG−82 will work 

cooperatively to develop a common profile document that will be provided as recommendations for 

consideration by ICAO. 

NASA/CR—2010-216324 111

Appendix A.—Acronyms and Abbreviations 

This appendix identifies acronyms and abbreviations used throughout this document. 

A/A air to air

A/C aircraft

A/G air to ground

AAA authentication, authorization, and accounting

ACARS Aircraft Communications Addressing and Reporting System

ACSTS Aerospace Communication Systems Technical Support contract

ADAS AWOS Data Acquisition System

ADDS Aviation Digital Data Service

ADS–B automatic dependent surveillance—broadcast

ADS–C automatic dependent surveillance—contract

ADSx automatic dependent surveillance—next generation 

AEEC Airlines Electronic Engineering Committee 

AeroMACS Aeronautical Mobile Aircraft Communications System

AFB Air Force base

AFSS Automated Flight Service Station

A–G air to ground

AIM Aeronautical Information Management

AISR Aeronautical Information System Replacement

ALS airport lighting system

ALSF approach lighting with sequenced flashing lights

AM(R)S aeronautical mobile (route) service

AMS(R)S aeronautical mobile satellite (route) service

ANSP air navigation service provider

AOC aeronautical operational control

AP–17, –30 Action Plan 17, 30

ARCTR aeronautical center in Oklahoma City, Oklahoma

ARFF Aircraft Rescue and Firefighting building (at Cleveland Hopkins International

Airport)

ARINC Aeronautical Radio Incorporated

ARSR air route surveillance radar
NASA/CR—2010-216324 112

ARTCC air route traffic control center

ARTS Automated Radar Terminal System

ASDE–X Airport Surface Detection Equipment—Model X

ASH Aviation Services Hangar

ASN access service network

ASN–GW access service network gateway

ASN–GW–DP access service network gateway—decision point

ASN–GW–EP access service network gateway—enforcement point

ASOS automated surface observation systems

ASR airport surveillance radar

ATC air traffic control

ATCSCC air traffic control system command center

ATCT air traffic control tower

ATFCM air traffic flow and capacity management

ATIS Automatic Terminal Information Service

ATM air traffic management

ATN aeronautical telecommunications network

ATO Air Traffic Organization

ATS air traffic services

ATSP air traffic service provider

ATSU air traffic services unit

AWIPS Advanced Weather Interactive Processing System

AWOS Automated Weather Observing System

AZ azimuth

BASOP base operations

BER bit error rate

BLOS beyond line of sight

BS base station

BTS base transceiver station

BUEC backup emergency communications

C&P crossing and passing

CANRAD Canadian Radars

CDA Continuous Descent Arrivals or Continuous Descent Approach
NASA/CR—2010-216324 113

CDM collaborative decision making

CDTI cockpit display of traffic information 

CIWS Corridor Integrated Weather System

CLE Cleveland Hopkins International Airport, Cleveland, Ohio

CMF Consolidated Maintenance Facility

CNS communication, navigation, and surveillance

COCR communications operating concept and requirements

COM communications

ConOps concepts of operation

ConUse concepts of use

CP cyclic prefix

CPDLC controller pilot data link communications

CPE customer premise equipment (same as subscriber station)

CSN Connectivity Service Network

CTA Controlled Time of Arrival

D/L data link

dATIS (D–ATIS) Digital Automatic Terminal Information Service

DC data communications

DCG data communications gateway

DCS data communications system

DFU display functional unit

DHCP Dynamic Host Configuration Protocol

DHS Department of Homeland Security

DINS Defense Internet NOTAM (Notice to Airmen) services

DL downlink—base station to subscriber station data-flow direction

DME distance measuring equipment

DoD Department of Defense

D–OTIS data link operational terminal information service

D–RVR data link runway visual range

D–SIG data link surface information and guidance

D–SIGMET data link significant meteorological information

DSB AM double-sideband amplitude modulation

DSR dynamic source routing
NASA/CR—2010-216324 114

DSS decision support system

D–TAXI (D-Taxi) data link taxi clearance 

DTS Dedicated Telecom Services

DYNAV dynamic route availability

EA enterprise architecture

ECG En Route Communications Gateway

ECS emergency communications systems

ERAM En Route Automation Modernization

ERIDS En Route Information Display System

ERT–VR extended real time—variable rate

ES Extended Squitter

ETVS Enhanced Terminal Voice Switch

EUR Europe

EUROCAE European Organization for Civil Aviation Equipment

EUROCONTROL European Organisation for the Safety of Air Navigation

F&F flight and flow

FAA Federal Aviation Administration

FANS–1/A+ Future Air Navigation System—1/A+ version

FBWTG FAA Bulk Weather Telecommunications Gateway

FCI future communications infrastructure

FCS Future Communications Study

FDD frequency-division duplex

FEC forward error correction

FFT fast Fourier transform

FLIPCY flight plan consistency

FMS flight management system

FOC Flight Operations Center

FPR Final Program Requirements

FRS future radio system

FTP File Transfer Protocol

FY fiscal year

G/A general aviation

G/G ground to ground
NASA/CR—2010-216324 115

GA general aviation

GBT ground-based transceiver

GI general information

GIS geographical information system

Glenn Glenn Research Center

GPS Global Positioning System

GS ground station

GSC ground station controller

GTWY gateway

GW gateway

HCS host computer system

HF high frequency

HPA high-power amplifier

IAP Internet Access Point

ICAO International Civil Aviation Organization 

ID identification

IDS Information Display System

IEEE Institute of Electrical and Electronics Engineering

ILS instrument landing system

IP Internet Protocol

Iperf network testing tool

ITP In-Trail Procedure

ITU International Telecommunications Union

ITWS Integrated Terminal Weather System

JPDO Joint Planning and Development Office

LCGS low-cost ground surveillance

LINK 2K+ European SESAR (Single European Sky ATM Research) program

LLWAS Low-Level Wind Shear Alert System

LOC localizer

Loc location

LOS line of sight

LRR long-range radar

M&S merging and spacing
NASA/CR—2010-216324 116

MAC Media Access Control

M-ary digital transmission of two or more bits at a time

MASPS minimum aviation system performance standards

MIMO multiple input, multiple output

MITRE CAASD MITRE Corporation’s Center for Advanced Aviation System Development

MLAT multilateration

MM middle marker

Mode S Mode Select secondary surveillance Beacon System

MOPS Minimum Operational Performance Standards

MS mobile station

NADIN National Airspace Data Interchange Network

NAS National Airspace System

NASA–CLE NASA Glenn Research Center and Cleveland Hopkins 

International Airport

NASAD NAS architecture document

NASCR NASA Common Reference System

NAS–SR National Airspace System—System Requirements

NAV navigation

NAVAIDS navigation aids

NDB nondirectional radio beacon

NEXCOM Next Generation Air/Ground Communications

NEXRAD Next Generation Radar

NextGen Next Generation Air Transportation System

NFU National Weather Service Filter Unit

NIPRNET Nonclassified Internet Protocol Router Network

NIWS NAS Integrated Web Services

NLOS non line of sight

NMS Network Management System

NNCC National Network Control Centers

NNEW NextGen Network Enabled Weather

NOAA National Oceanic and Atmospheric Administration

NOTAM Notice to Airmen

nRT non real time
NASA/CR—2010-216324 117

nrtPS non-real-time polling service

NWS National Weather Service

O&M operations and maintenance

OAS Oceanic Automation System

ODU outdoor unit

OFDM orthogonal-frequency-division multiplexing

OFDMA orthogonal-frequency-division multiple access

OI operational improvement

OM outer marker

Ops IP operations IP

Ops operations

OPUS Online Positioning User Service

ORIS operational en route information service

OSED Operational Services and Environment Definition

OTIS operational terminal information service

OV–1, OV–2 operational views

PAIRAPP paired approach

PC personal computer

PER packet error rate

PHY physical

PIREP pilot report

PLA project-level agreement

PoE Power over Ethernet

PPD pilot preferences downlink

PRM Precision Runway Monitor

PSN packet switched network

PV6 plan view 6

QAM quadrature amplitude modulation

QoS quality of service

QPSK quadrature phase-shift keying

RAPCO Radar Approach Control

RASP Regional ADAS (Automated Weather Observation Station Data Acquisition System) 

Service Processor
NASA/CR—2010-216324 118

RCAG remote communications air to ground

RCE radio control equipment

RCE–C RCE at control site

RCE–R RCE at remote (transmitter/receiver) site

RCO remote communication outlet

RCP required communication performance

RDVS Rapid Deployment Voice Switch

RE&D research, engineering and development

RF radiofrequency

RRM radio resource management

RSSI received signal strength indication

RTCA RTCA, Inc. (founded as Radio Technical Commission for Aeronautics)

rtPS real-time polling service

RTR remote transmitter/receiver

RU remote unit

RUC rapid update cycle

RVR runway visual range

Rx receiver

SAMS Special Use Airspace Management System

SARPs standards and recommended practices

SATCOM satellite communications

SC single carrier; special committee

SCa single carrier access

SCS Sensor Control Subsystem (ADAS, AWOS Data Acquisition System)

SE system engineering

SEM system engineering manual

SESAR Single European Sky ATM Research

SIGMET significant meteorological information

SITA Société Internationale de Télécommunications Aéronautiques

SOA service-oriented architecture

SOAMOM service-oriented architecture messaging oriented middleware

SOC Service Operations Center

SOCC Security Operations Control Center
NASA/CR—2010-216324 119

SONET synchronous optical networking

SPR safety and performance requirement

SR system requirement

SRD system requirements document

SRR short-range radar

SS subscriber station

SSR secondary surveillance radar 

StarACS Star Automatic Configuration Server (for WiMAX (Worldwide Interoperability 

Microwave Access) networks)

STARS Standard Terminal Automation Replacement System 

surv surveillance

SV–1, SV–2 system views

SWIM System Wide Information Management

SYSCO system-supported coordination

TACAN tactical air navigation

TAP/CDA Tailored Arrival Procedure/Continuous Descent Approach (Arrival)

TBO trajectory-based operations

TCP transmission control protocol

TDD time-division duplex

TDLS tower data link system

TDMA time-division multiple access

TDWR Terminal Doppler Weather Radar

TFDM Tower Flight Data Manager

TFM traffic flow management

TFR temporary flight restrictions

THEVAN Terrestrial Hybrid Environment for Verification of Aeronautical Networks

TIBA Traffic Information Broadcast by Aircraft

TM Traffic Management

TMA terminal maneuvering area

TRACO facility type for TRACON

TRACON Terminal Radar Approach Control Facility

TVS Terminal Voice Switch

TWIP Terminal Weather Information for Pilots 
NASA/CR—2010-216324 120

Tx transmitter

UAT universal access transceiver

UDP User Datagram Protocol

UGS unsolicited grant service

UHF ultra-high frequency

UL uplink—subscriber station to base station data-flow direction

URCO urgent contact

VCS Voice Communications System

VDL very high frequency digital link

VHF very high frequency

VLAN virtual local area network

VoIP digital voice over Internet Protocol

VOLPE John A. Volpe National Transportation Systems Center

VOR very high frequency (VHF) omnidirectional range

VPN virtual private network

VSCS Voice Switching and Control System

WAAS Wide Area Augmentation System

WAKE wake vortex

WARC World Administrative Radio Conference (now World Radiocommunication 

Conference)

WARP Weather and Radar Processor

WiMAX Worldwide Interoperability Microwave Access

WINS Weather Information Network Server

WirelessHUMAN wireless high-speed unlicensed municipal area network

WirelessMAN wireless municipal area network

WJHTC William J. Hughes Technical Center

WMD wake mitigation departure

WMS wide-area master station

WMSCR Weather Message Switching Center Replacement

WRC World Radiocommunication Conference

WRS WAAS (wide-area augmentation system) reference stations

WTWD Wake Turbulence Mitigation for Departures 

Wx weather
NASA/CR—2010-216324 121

4–D four dimensional (latitude, longitude, altitude, and time)

4DLINK proposal for the next data link package that targets initial four-dimensional 

trajectories and airport services (This capability fits in Implementation Package 2 as 

identified by the Single European Sky ATM Research (SESAR) Master Plan.)

4DT four-dimensional trajectory (latitude, longitude, altitude, and time)

NASA/CR—2010-216324 123

Appendix B.—RTCA National Airspace System Concept of Operations

Applicable to the Proposed Aeronautical Mobile Airport

Communications System (AeroMACS)

AeroMACS could provide a communication link to transfer surveillance and weather information, 

facilitate flight and resource management, and enable exchange of aeronautical information in the future 

NAS. Table 41 to Table 45 document the select RTCA NAS ConOps (Ref. 13) found applicable to the 

proposed AeroMACS. 

In addition to the relevant section number, the “Relevant text” column presents the specific text from 

the NAS ConOps document pertaining to the identified type of information being exchanged and/or 

service provided. The “Relevant text” in these tables is copyrighted by RTCA, Inc., and is being used 

with permission.16

TABLE 41.—THE ROLE OF SURVEILLANCE INFORMATION—RTCA NATIONAL AIRSPACE SYSTEM (NAS) 

CONCEPT OF OPERATIONS (ConOps) APPLICABLE TO THE PROPOSED AeroMACS

ID NAS ConOps 

section

Relevant text (Ref. 13)

S-1 1.5.2 Traffic information collected by surveillance systems is transmitted to properly equipped aircraft. 

Thus equipped users have position information of appropriate aircraft available to support flight 

deck decisions.

S-2 1.5.3 

2nd bullet 

Enhanced CNS [communications, navigation, and surveillance] systems and automation in 

aircraft complement automation aids on the ground permitting more autonomous operations. This 

improved autonomy combined with greater ability to share information permits workload to be 

distributed between service provider and operator in a balance appropriate for the operations 

being conducted.

S-3 4.1.3 Accurate airport environmental information, including traffic, permits appropriately equipped 

aircraft to navigate on the airport surface with almost no forward visibility.

S-4 4.2.2 The proliferation of CDTI [cockpit display of traffic information] avionics and supporting ground 

infrastructure takes place in this time frame. The ground system that receives aircraft position 

reports also broadcasts traffic information and a complete set of graphical and text weather 

products ... Safety is enhanced by situation displays that depict airborne and surface traffic as 

well as aerodrome information.

S-5 4.3.2

1st paragraph 

... In addition, ground-based surveillance data is shared with users as a safety enhancement for 

preventing incursions.

S-6 5.1.3

2nd paragraph 

Virtually all aircraft are equipped to provide position and intent information, and to receive 

position and intent data from other aircraft.

 16The complete RTCA NAS ConOps (and other RTCA documents) may be purchased from RTCA, Inc., 1828 L St., 

N.W., Suite 805, Washington, DC 20036 (202–833–9339, http://www.rtca.org). 
NASA/CR—2010-216324 124

TABLE 42.—THE ROLE OF WEATHER INFORMATION—RTCA NATIONAL AIRSPACE SYSTEM (NAS) 

CONCEPT OF OPERATIONS (ConOps) APPLICABLE TO THE PROPOSED AeroMACS

ID NAS ConOps 

section 

Relevant text (Ref. 13)

W-1 1.4

2nd bullet 

In addition to this pool of common information, SWIM [System Wide Information Management] 

provides context-sensitive information to NAS elements that require the information. (This 

includes flight deck access to the information, such as weather and resource status.) 

W-2 1.5.2

9th bullet 

A SWIM system is developed by the service provider to distribute timely and consistent 

information across the NAS for both user and service provider planning ... The system serves as 

an avenue for greater exchange of electronic data and information between users and service 

providers including... - Dynamic information including but not limited to current and forecast 

weather, radar summaries, hazardous condition warnings, information on updated airport and 

airspace capacity constraints Temporary Flight Restrictions (TFR), and Special Use Airspace 

(SUA).

W-3 1.5.3

6th bullet 

There are continued advancements in the scope and accuracy of the weather information available 

to the service provider and use throughout the NAS, including automatic simultaneous broadcast 

of hazardous weather alerts for wind shear, turbulence, microburst, gust fronts; and areas of 

precipitation, lightning, icing, and low cloud ceilings and visibility. SWIM provides access to this 

information to all service providers and to participating aircraft via data link. Improved weather 

information integrated into DSSs and disseminated via data link reduces encounters with 

hazardous weather.

W-4 2.1.1 TFM [traffic flow management] service providers monitor traffic, weather, and infrastructure. ... 

Improved information exchange among users and service providers enables shared insight about 

weather, demand, and capacity constraints which enhances the users understanding of NAS status 

and TFM initiatives. 

W-5 2.2.1

1st paragraph

Users have access to an increasing amount of NAS information including airport status and 

acceptance rate, composite weather information developed collaboratively by the FAA and users 

to assure a common projection of future weather.

W-6 3.1.2

1st paragraph

A common Geographical Information System (GIS) format is used to store all NAS information 

including terrain, obstacle, weather, and navigation, surveillance and communication coverage 

information. This information is available via SWIM to all service providers and users.

W-7 3.2.1 

4th paragraph

Data link-equipped users load the flight plan directly into the Flight Management System (FMS). 

The user obtains a complete weather briefing for the proposed route via the FOC [Flight 

Operations Center] computer. In addition, system-wide information is obtained via the FOC 

SWIM interface.

W-8 3.2.3

3rd paragraph

Greater use of electronic flight planning, navigation database updates and weather briefing 

services via SWIM results in the routine transfer of preflight planning data to the flight deck. 

Dynamic safety-critical (e.g. turbulence, icing) and other flight plan is data linked directly to 

aircraft for use during flight.

W-9 4.1.1

2nd paragraph

The introduction of data-linked meteorological information improves overall situational 

awareness. Properly equipped aircraft receive graphical weather information via data link, 

including current observations, pilot reports, hazardous phenomena in both graphic and text 

format, and winds aloft information.

W-10 4.1.2

3rd paragraph

Clearances, airport information, and weather conditions (e.g., current, forecast, hazardous) are 

provided over data link to more users at more airports. 

W-11 4.1.2

4th paragraph

The system provides access to airport environmental information, arrival, departure, and taxi 

schedules, airborne and surface surveillance information, flight information, ATIS [Automatic 

Terminal Information System] and other weather information, and TFM initiatives. 

W-12 4.1.3

1st paragraph

Hazardous weather alerts are automatically and simultaneously broadcast to aircraft via data link 

and service providers via SWIM.

W-13 4.2.1

1st paragraph

Many users continue to use Aircraft Communications Addressing and Reporting System 

(ACARS) as a source of data linked information. ATIS and other weather information are 

received via data link or by voice. 

W-14 4.2.2

3rd paragraph

The ground system that receives aircraft position reports also broadcasts traffic information and a 

complete suite of graphical and text products, including precipitation/lightning, icing, low 

ceiling/visibility maps, surface hazards, and wind shear and turbulence information, as well as 

site-specific weather reports and forecasts. Safety is enhanced through the use of situation 

displays that depict airborne and surface traffic as well as aerodrome information.
NASA/CR—2010-216324 125

TABLE 42.—THE ROLE OF WEATHER INFORMATION—RTCA NATIONAL AIRSPACE SYSTEM (NAS) 

CONCEPT OF OPERATIONS (ConOps) APPLICABLE TO THE PROPOSED AeroMACS

ID NAS ConOps 

section 

Relevant text (Ref. 13)

W-15 4.3.1

1st paragraph

SWIM and ACARS enhance the service provider’s ability to provide data products such as 

NOTAMs [Notices to Airmen] and meteorological information to the airport vicinity. Although 

weather information and advisories continue to be available via traditional means, there is 

increased use of automation to collect and package the information and increased use of data link 

to disseminate routine and hazardous weather and traffic information.

W-16 4.3.2

1st paragraph

SWIM provides access to weather and information via data link to flight crews, allowing them to 

develop near-real-time picture of the surrounding environment. SWIM and data link also expedite 

the service provider’s task of providing data products such as NOTAMs and meteorological 

information for the airport vicinity when changed or needed [b]y the user.

TABLE 43.—IDENTIFICATION OF THE ROLE OF FLIGHT MANAGEMENT INFORMATION—RTCA NATIONAL 

AIRSPACE SYSTEM (NAS) CONCEPT OF OPERATIONS (ConOps) APPLICABLE TO THE PROPOSED AeroMACS

ID NAS ConOps 

section

Relevant text (Ref. 13)

FM-1 1.5.2

9th bullet

A SWIM [System Wide Information Management] system is developed to distribute timely and 

consistent information....[Including]: - Flight information on each flight, including the filed 

flight profile and all amendments, first movement of the aircraft, wheels-up, position data in 

flight, touchdown time, gate or parking assignment, and engine shutdown.

FM-2 1.5.2

13th bullet

The flight planning system accommodates all uses of the airspace as the flight profile evolves to 

include real time SUA [Special Use Airspace] operations scheduling information. 

FM-3 1.5.2

14th bullet

By integrating all airspace management systems, the NAS achieves the technical goal of 

providing in a timely manner the airspace necessary to execute the flight profile. The ATM [air 

traffic management] system manages airspace based on each user's needs, including proximity 

to the user’s base of operations. As a result, more airspace, including special use, is made 

available to more users with increased efficiency.

FM-4 2.2.1 

1st paragraph 

Users have access to an increasing amount of NAS information, including airport status and 

acceptance rate and composite weather information developed collaboratively by the FAA 

[Federal Aviation Administration] and users to ensure a common projection of future weather. 

Improved individual support capabilities use investigative operations and develop individual 

strategies to mitigate demand-capacity imbalances and their effect on the individual user fleets. 

Sharing strategies with the ATCSCC [air traffic control system command center] allows service 

providers to evaluate conditions based on user intention rather than published schedules.

FM-5 2.2.2 

1st paragraph 

With the increasing ability to maintain common situation awareness, users plan flight profiles 

that consider known constraints and provide the best advantage to their operations. 

FM-6 2.2.2

2nd paragraph 

... In addition, the flight planning system expands to offer users the opportunity to provide 

alternative profiles for flights. These alternative profiles are tested on a continuing basis as trial 

plans that are selected if conditions do not develop as foreseen. 

FM-7 2.2.3

1st paragraph 

...Within that constraint and allocation, the NAS has the ability to conduct a SYSCO [systemsupported coordination] auto-negotiation of the flight profile to best meet the user's need within 

that user’s NAS resource allocation. The systems interactively re-plan each flight against both 

current constraints and any ancillary problems that arise through the execution of the initiative. 

FM-8 3

1st bullet 

Elements of SWIM are used to obtain and distribute flight-specific data and aeronautical 

information, including international coordination of planned flight trajectory.

FM-9 3

6th bullet 

Real-time trajectory updates reflect more realistic departure times, resulting in more accurate 

traffic load predictions, and increased flexibility due to the imposition of fewer restrictions.

FM-10 3

2nd bullet 

As the information available through SWIM increases, a more collaborative role for users 

evolves based on the access to accurate real-time NAS information for improved flight planning. 

Examples of this information include current and predicted SUA status, infrastructure status, 

traffic density, and prevailing TFM [traffic flow management] initiatives.
NASA/CR—2010-216324 126

TABLE 43.—IDENTIFICATION OF THE ROLE OF FLIGHT MANAGEMENT INFORMATION—RTCA NATIONAL 

AIRSPACE SYSTEM (NAS) CONCEPT OF OPERATIONS (ConOps) APPLICABLE TO THE PROPOSED AeroMACS

ID NAS ConOps 

section

Relevant text (Ref. 13)

FM-11 3

3rd bullet

Decision support suites are available for both interactive preflight planning with the service 

provider as well as changes by the pilot and/or dispatcher during the course of the flight.

FM-12 3.1.1

3rd paragraph 

There is real-time sharing of system demand and the virtual ATM information, enabling service 

providers to collaboratively interact with the user and to mutually develop solutions to problems.

FM-12 3.1.2 

2nd paragraph 

Flight plan information is incorporated into the flight profile. This profile can be as simple as the 

user’s preferred path or as detailed as a time-based trajectory that includes the user’s preferred path 

and preferred climb and descent profiles. The climb and descent profiles may include extended 

periods of continuous change. This is similar in nature to a discretionary clearance (climb or

descent) but is part of the flight planning process and, ultimately, the approved flight profile. This 

negotiated profile is available both to the user and to service providers across the NAS.

FM-13 3.1.2 

4th paragraph 

At the completion of the planning process, the user supplies the service provider with both the 

flight profile that best balances the NAS constraints and the user’s preferred flight profile. This 

information, including any subsequent changes, is available electronically to all service 

providers until the termination of the flight.

FM-14 3.1.3

1st and 2nd 

paragraph 

Interactive flight planning capabilities with immediate access to real-time data are fully 

implemented and are available throughout the flight to the flight deck, FOC [Flight Operations 

Center], and service provider. User-preferred routing is available to all properly equipped 

aircraft for both domestic and international flights. Controlled Times of Arrival (CTA) are the 

primary method for regulating flows in the planning, tactical, and strategic timeframes.

The flight profile evolves with changes to operations to allow greater flexibility in user 

preferences, including the planning and filing of parabolic flight profiles.

FM-15 3.2.1 

2nd paragraph 

The TFM information network enables a two-way exchange of real-time information. Using 

flight plan information, flow managers determine when either airport or airspace demand is 

predicted to exceed capacity, thereby warranting some type of flow management initiative. NAS 

users receive information about projected areas of concern and revise their plans on a real-time 

basis.

FM-16 3.2.1 

4th paragraph 

Data link-equipped users load the flight plan directly into the aircraft Flight Management 

System (FMS). The user obtains a complete weather briefing for the proposed route via the FOC 

computer. In addition, system-wide information is obtained through the FOC SWIM interface.

FM-17 3.2.2

1st paragraph 

SWIM ensures a continuously updated information base of NAS items, including service

constraints and infrastructure status. The flight planner uses this data to prepare a flight profile 

by performing a probe for the user-preferred route against the known system constraints. User 

DSSs [decision support systems] using information available via SWIM analyze the route that 

most closely balances user preferences and constraints. The use of CTAs [Controlled Times of 

Arrival] continues to expand across NAS resources. As conditions change during the planning 

phase or during the flight, the user is notified, and he/she is able to interactively determine the 

impact of the changes on the flight and modify the flight profile as desired.

FM-18 3.2.2

2nd paragraph 

The status of active and proposed flights, as well as real-time updates to reflect more realistic 

departure times (e.g., the latest planned departure times) are available to users. .... SWIM and 

SYSCO [system-supported coordination] facilitate more effective CDM [collaborative decision

making] between the FOC and service provider. ...

FM-19 3.2.2

4th paragraph 

Users without an FOC capability access the same flight data used by all other system users and 

service providers via appropriate devices. They are able to enter a command and be transferred 

to a service provider for clarification of the information. Depending on the user’s equipment, 

this dialog is by voice or through electronic messaging. For users equipped with data link, the 

capability exists to load a flight profile directly into the aircraft FMS [flight management 

system]. Other users can store the flight profile information on disk and upload it into the 

aircraft’s avionics for use.

FM-20 3.2.2

9th paragraph 

... SWIM enables domestic and international users and service providers to access flight profiles 

and associated SUA data.

FM-21 3.2.3

1st paragraph 

SWIM and Omni-SYSCO support an interactive flight planning capability for all properly 

equipped users to aid in filing user-preferred departure-to-destination flight profiles. ...
NASA/CR—2010-216324 127

TABLE 43.—IDENTIFICATION OF THE ROLE OF FLIGHT MANAGEMENT INFORMATION—RTCA NATIONAL 

AIRSPACE SYSTEM (NAS) CONCEPT OF OPERATIONS (ConOps) APPLICABLE TO THE PROPOSED AeroMACS

ID NAS ConOps 

section

Relevant text (Ref. 13)

FM-22 3.3.2 

1st and 2nd 

paragraphs 

SWIM information improves the user’s ability to create a flight profile, which facilitates the 

automatic generation of a flight profile containing either the user’s preferred flight path or a 

more detailed time-based trajectory within the known ATM system constraints. Potential 

problems are automatically displayed to the planner for reconciliation. Upon filing, the flight 

profile is updated, as necessary, along with all affected projections of NAS demand.

As conditions change, SWIM (in concert with SYSCO) allows the planner to access information 

used to determine the impact of the changes on the flight. Intelligent agents are introduced in 

this period to identify the best alternatives in light of ATM system changes and user preferences. 

SWIM information is available to all users and service providers until the termination of the 

flight. Information such as runway preferences and aircraft weight or information to support 

flight following can be added during the planning phase or during flight.

FM-23 4.1.2 

3rd paragraph 

Clearances, airport information, and weather conditions (e.g. current, forecast, hazardous) are 

provided over data link to more users at more airports. Taxi routes and positions of other aircraft 

are data linked and displayed in appropriately equipped aircraft. The receipt of taxi routes over 

data link relieves communication frequency congestion. Pilot situational awareness and safety 

are enhanced with an integrated display of the aircraft’s position, taxi route, and hazards.

FM-24 4.1.2 

4th paragraph 

Access to real-time data for surface movement DSSs makes for an increasingly integrated NAS. 

.... The system provides access to airport environmental information; arrival, departure, and taxi 

schedules; airborne and surface surveillance information; flight information; ATIS [Automatic 

Terminal Information System] and other weather information; and TFM initiatives. ...

FM-25 4.1.2

5th paragraph 

On taxi out, the flight’s time-based trajectory is updated in SWIM, and projections are made 

based on prevailing traffic conditions. 

FM-26 4.3.1 

4th paragraph 

...the service provider’s ability to plan surface movement improves as timely traffic information 

becomes available. .... Both the initial values and subsequent adjustments are incorporated into 

the surface management information system to ensure consistency and an integrated approach 

across systems

TABLE 44.—IDENTIFICATION OF THE ROLE OF AERONAUTICAL INFORMATION—RTCA NATIONAL 

AIRSPACE SYSTEM (NAS) CONCEPT OF OPERATIONS (ConOps) APPLICABLE TO THE PROPOSED AeroMACS

ID NAS ConOps 

section

Relevant text (Ref. 13)

A-1 1.5.2

9th bullet

A SWIM [System Wide Information Management] system is developed by the service provider to 

distribute timely and consistent information across the NAS ...including...

Static data, such as electronic navigation data, maps, charts, airport facility guides, and published 

Notices to Airmen (NOTAMs) is available directly from the Internet as well as various 

intranets...

Dynamic information, including, but not limited to, current and forecast weather,

radar summaries, hazardous condition warnings, information on updated airport

and airspace capacity constraints, Temporary Flight Restrictions (TFR), and Special Use Airspace 

(SUA) schedules.

Flight information...

Schedule information...

A-2 1.5.2

12th bullet

Traffic information collected by surveillance systems is transmitted to properly equipped 

aircraft...to support flight deck decisions.

A-3 1.5.3

2nd bullet 

Enhanced CNS [communication, navigation, and surveillance] systems and automation in aircraft 

complement automation aids on the ground, permitting more autonomous operations. This 

improved autonomy, combined with greater ability to share information, permits the workload to 

be distributed between the service provider and user in a balance appropriate for the operations 

being conducted.
NASA/CR—2010-216324 128

TABLE 44.—IDENTIFICATION OF THE ROLE OF AERONAUTICAL INFORMATION—RTCA NATIONAL 

AIRSPACE SYSTEM (NAS) CONCEPT OF OPERATIONS (ConOps) APPLICABLE TO THE PROPOSED AeroMACS

ID NAS ConOps 

section

Relevant text (Ref. 13)

A-4 1.5.3

4th bullet 

Seamless communications and coordination, coupled with information accessible through SWIM, 

allow real-time reassignment of airspace between facilities to meet contingencies such as 

equipment outages.

A-5 2.2.1 

1st paragraph 

Users have access to an increasing amount of NAS information including airport status and 

acceptance rate, ...

A-6 3

1st bullet 

Elements of SW[I]M are used to obtain and distribute flight-specific data and aeronautical 

information, including international coordination of flight trajectory.

A-7 3.1.1 

3rd paragraph 

There is real time sharing of system demand and the virtual ATM [air traffic management] 

information... User flight planning systems account for system constraints such as flow 

restrictions, hazardous weather, SUA and infrastructure outages.

A-8 3.1.2 

1st paragraph 

A NASCR [NAS Common Reference System] and index that incorporates a common 

Geographical Information System (GIS) format is used to store all NAS information including 

terrain, obstacle, weather, and navigation, surveillance and communication coverage information. 

This information is available via SWIM to all service providers and users.

A-9 3.1.2 

3rd paragraph 

To generate the flight profile, users access current and predicted weather, traffic density, 

restrictions, and SUA status information ...

A-10 3.2.2 

9th paragraph 

SWIM enables domestic and international users and service providers to access flight profiles and 

associated SUA data.

A-11 4.1.2 

4th paragraph 

Access to real-time data for surface movement DSSs [decision support systems] makes for an 

increasingly integrated NAS. The surface management information system facilitates coordination 

between decision makers at all levels of the airport operation—service provider, flight crews, 

FOC [Flight Operations Center], ramp, airport operator, and airport emergency centers. The 

system provides access to airport environmental information; arrival, departure, and taxi 

schedules; airborne and surface surveillance information; flight information; ATIS [Automatic 

Terminal Information Service] and other weather information; and TFM [traffic flow 

management] initiatives. This data sharing allows service providers to coordinate local operations 

with airline ramp and airport operators, thus improving overall airport operations.

A-12 4.1.3 

1st paragraph 

.... Using data link, pilots receive ATIS-type messages with Runway Visual Range (RVR), 

braking action and surface condition reports, current precipitation, runway availability, and wake 

turbulence and wind shear advisories. Hazardous weather alerts are automatically and 

simultaneously broadcast to aircraft via data link and service providers via SWIM.

A-13 4.2.1 

2nd paragraph 

Airport maps are electronically available to properly equipped users

A-14 4.2.2 

3rd paragraph 

The proliferation of CDTI [cockpit display of traffic information] avionics and supporting ground 

infrastructure takes place in this time frame. The ground system that receives aircraft position 

reports also broadcasts radar-derived traffic information and a complete set of graphical and text 

products ... Safety is enhanced by situation displays that depict airborne and surface traffic as 

well aerodrome information.

A-15 4.3.1 

1st paragraph 

SWIM and ACARS [Aircraft Communications Addressing and Reporting System] enhance the 

service provider’s ability to provide data products such as NOTAMs [Notices to Airmen] and 

meteorological information for the airport vicinity. Although weather information and advisories 

continue to be available via traditional means, there is increased use of automation to collect and 

package the information and increased use of data link to disseminate routine and hazardous 

weather and traffic information.
NASA/CR—2010-216324 129

TABLE 45.—IDENTIFICATION OF THE ROLE OF RESOURCE MANAGEMENT INFORMATION—RTCA NATIONAL 

AIRSPACE SYSTEM (NAS) CONCEPT OF OPERATIONS (ConOps) APPLICABLE TO THE PROPOSED AeroMACS

ID NAS ConOps 

section

Relevant text (Ref. 13)

RM-1 1.5.2

16th bullet 

By taking advantage of advanced information and communications capabilities, airspace 

design and underlying sector configurations are no longer constrained by the current 

geographic boundaries, particularly in high altitude. Tools and procedures are in place for 

frequent evaluation (up to several times a day) of the airspace structure and anticipated traffic 

flows, with adjustments made accordingly. This increased flexibility permits changes to the 

configuration of air traffic facilities.

RM-2 1.5.3

2nd bullet

Enhanced CNS [communications, navigation, and surveillance] systems and automation in 

aircraft complement automation aids on the ground permitting more autonomous operations. 

This improved autonomy combined with greater ability to share information permits the 

workload to be distributed between service provider and user in a balance appropriate for the 

operations being conducted.

RM-3 1.5.3

4th bullet 

Seamless communications and coordination, coupled with information accessible through 

SWIM [System Wide Information Management], allow real-time reassignment of airspace 

between facilities to meet contingencies such as equipment outages.

RM-4 1.5.3

7th bullet 

There are continued improvements in the collection and processing of NAS infrastructure 

data. These data are used to prioritize and schedule NAS infrastructure activities

RM-5 1.5.3

8th bullet 

NAS infrastructure assets (e.g., radars, communications, etc.) are assigned/reassigned 

dynamically to mitigate infrastructure problems as well as in response to changes in 

sectorization and airspace assignment. All NAS resources are registered in the NAS Common 

Reference System (NASCR), and monitored and managed through SWIM.

RM-6 2.5.3 ... NAS infrastructure assets are assigned/reassigned dynamically to mitigate infrastructure 

problems as well as to respond to changes to in sectorization and airspace assignment. SWIM 

provides access to all NAS management and resource information. The redundancy in the 

NAS is applied expeditiously to maintain flow and reduce operational impact

RM-7 3.1.1 

3rd paragraph

There is real-time sharing of system demand and the virtual ATM information, enabling 

service providers to collaboratively interact with the user and to mutually develop solutions to 

problems. ... User flight planning systems account for system constraints such as flow 

restrictions, hazardous weather, SUA and infrastructure outages.

RM-8 5.3.2 

7th paragraph 

Data from SWIM allows service providers to monitor traffic demand, NAS infrastructure 

status, and other conditions in order to allocate resources, including changes in staffing. 

Service providers also update the NAS about the available capacity of airport and surrounding 

airspace resources and the current status of SUA. This facilitates more effective collaboration 

with FOCs [Flight Operations Center] and improved formulation of TFM [traffic flow 

management] agreements.

NASA/CR—2010-216324 131

Appendix C.—Hierarchical Diagrams of Functional Requirements 

This appendix contains the functional analysis of the AeroMACS C-band communication system 

presented as a series of hierarchical diagrams (Figure 45 to Figure 60). The “C” preceding all of the 

numerical functional levels represents “C-band.” 

The analysis and diagrams were adapted from the National Airspace System Communications System 

Safety Hazard Analysis and Security Threat Analysis document (Ref. 67). 

Solid blocks in the diagrams represent system functions that are part of the C-band system scope 

assumptions, and background blocks show NAS functions that are not currently part of the C-band 

functionality. 

Figure 45.—High-level view of C-band communications system (adapted from Ref. 67).

Figure 46.—Decomposition of use of C-band communications system to transmit/receive messages (adapted from 

Ref. 67).

C.1.1 Use C-Band 

Communications System 

(Transmit/Receive Messages)

C.1.1.1.1 

Transceive 

Fixed to 

Airborne 

Mobile 

Message

C.1.1.2.1

Transceive 

Airborne 

Mobile to 

Fixed 

Message

C.1.1.1.2 

Transceive 

Fixed to 

On-ground 

Mobile 

Message

C.1.1.1 

Transceive 

Fixed to 

Mobile 

Message

C.1.1.3

Transceive 

Mobile to Mobile

Message

C.1.1.2

Transceive 

Mobile to 

Fixed 

Message

C.1.1.4

Transceive 

Fixed to Fixed 

Message

C.1.1.2.2

Transceive 

On-ground 

Mobile to 

Fixed 

Message

C.1.1.4.1

Transceive 

Fixed to 

Fixed 

Message
NASA/CR—2010-216324 132

Figure 47.—Decomposition of transceive fixed-to-mobile message (adapted from Ref. 67).

C.1.1.1.2 .1

Transceive 

Fixed to On-ground 

Aircraft Message

C.1.1.1.2 .2

Transceive 

Fixed to On-ground 

Vehicles Message

C.1.1.1.2 

Transceive 

Fixed to 

On-ground 

Mobile 

Message

C.1.1.1.2.1.1

Transceive 

Fixed to Onground Aircraft 

Voice Message

C.1.1.1.2.1.2

Transceive 

Fixed to Onground Aircraft 

Data Message

C.1.1.1 

Transceive 

Fixed to 

Mobile 

Message

C.1.1.1.2.2.1

Transceive 

Fixed to Onground Vehicle 

Voice Message

C.1.1.1.2.2.2

Transceive 

Fixed to Onground Vehicle 

Data Message

C.1.1.2.2 .1

Transceive 

On-ground Aircraft 

to Fixed Message

C.1.1.2.2 .2

Transceive 

On-ground Vehicles 

to Fixed to Message

C.1.1.2.2 

Transceive 

On-ground 

Mobile to 

Fixed 

Message

C.1.1.2.2.1.1

Transceive 

On-ground 

Aircraft to 

Fixed Voice 

Message

C.1.1.2.2.1.2

Transceive 

On-ground 

Aircraft to 

Fixed Data 

Message

C.1.1.2 

Transceive 

Mobile to 

Fixed 

Message

C.1.1.2.2.2.1

Transceive 

On-ground 

Vehicle to 

Fixed Voice 

Message

C.1.1.2.2.2.2

Transceive 

On-ground 

Vehicle to 

Fixed Data 

Message

Figure 48.—Decomposition of transceive mobile-to-fixed message (adapted from Ref. 67).
NASA/CR—2010-216324 133

Figure 49.—Decomposition of transceive 

fixed-to-fixed message (adapted from 

Ref. 67).

Figure 50.—Generic decomposition of transceive data message (adapted from Ref. 67).

C.1.1.x.x.x.2.1

Initiate Data 

Message

C.1.1.x.x.x.2.2

Process Data 

Message for 

Sending

C.1.1.x.x.x.2.3

Send Data 

Message

C.1.1.x.x.x.2

Transceive Data 

Message

C.1.1.x.x.x.2.5

Deliver Data 

Message

C.1.1.x.x.x.2.4

Process Received 

Data Message

C.1.1.4

Transceive 

Fixed to Fixed 

Message

C.1.1.4.1

Transceive 

Fixed to 

Fixed 

Message

C.1.1.4.1.1.1

Transceive 

Fixed to Fixed 

Voice Message

C.1.1.4.1.1.2

Transceive 

Fixed to Fixed 

Data Message

C.1.1.4.1.1

Transceive 

Fixed to 

Fixed 

Message
NASA/CR—2010-216324 134

Figure 51.—Generic decomposition of initiate data message (adapted from Ref. 67).

Figure 52.—Generic decomposition of process data message for sending (adapted from Ref. 67).

Figure 53.—Generic decomposition of send data message (adapted from Ref. 67).

Figure 54.—Generic decomposition of process received data message (adapted from Ref. 67).

C.1.1.x.x.x.2.1

Initiate Data Message

C.1.1.x.x.x.2.1.1

Access 

Communication 

System

C.1.1.x.x.x.2.1.2

Authenticate 

Message Source

C.1.1.x.x.x.2.1.3

Provide Message

C.1.1.x.x.x.2.1.4

Indicate Receipt

C.1.1.x.x.x.2.1.5

Timestamp 

Message

C.1.1.x.x.x.2.1.6

Specify Routing 

Requirements

C.1.1.x.x.x.2.1.7

Indicate Sender

C.1.1.x.x.x.2.1.8

Provide Failure 

Processing

C.1.1.x.x.x.2.2

Process Data Message 

for Sending

C.1.1.x.x.x.2.2.1

Encode Message

C.1.1. x.x.x.2.2.2

Packetize 

Message

C.1.1.x.x.x.2.2.3

Compress 

Message

C.1.1.x.x.x.2.2.4

Checksum

C.1.1.x.x.x.2.2.5

Provide Failure 

Processing

C.1.1.x.x.x.2.3.1

Apply Routing

C.1.1.x.x.x.2.3.2

Transmit Message

C.1.1.x.x.x.2.3.5

Provide Failure 

Processing

C.1.1.x.x.x.2.3

Send Data 

Message

C.1.1.x.x.x.2.3.3

Transport 

Message

C.1.1.x.x.x.2.3.4

Receive Message

C.1.1.x.x.x.2.4.1

Timestamp 

Message

C.1.1.x.x.x.2.4.2

Decode Message

C.1.1.x.x.x.2.4.3

Reconstitute 

Packetized 

Message

C.1.1.x.x.x.2.4.4

Decompress Message

C.1.1.x.x.x.2.4.5

Confirm Checksum

C.1.1.x.x.x.2.4.6

Provide Failure 

Processing

C.1.1.x.x.x.2.4

Process Received 

Data Message
NASA/CR—2010-216324 135

Figure 55.—Generic decomposition of deliver data message (adapted from Ref. 67). 

Figure 56.—Generic decomposition of provide failure processing (adapted from Ref. 67). 

Failure-detection subfunctions

• Authentication failures

• Function unavailability

• Message unintelligible or garbled

• Message inaudible

• Message or message components missing or faulty

• Invalid or incorrect message components

• Checksum failures

• Invalid recipient

Figure 57.—Decomposition of operate C-band communications system 

(adapted from Ref. 67). 

C.1.1.x.x.x.2.5.1

Communication 

System

C.1.1.x.x.x.2.5.2

Authenticate 

Message Source

C.1.1.x.x.x.2.5.4

Indicate Incoming 

Message

C.1.1.x.x.x.2.5.5

Present Message

C.1.1.x.x.x.2.5.6

Provide Failure 

Processing

C.1.1.x.x.x.2.5.3

Provide Message 

Source

Also terminate

C.1.1.x.x.x.2.5

Deliver Data 

Message

C.1.1.x.x.x.2.x.x

Provide Failure 

Processing

C.1.1.x.x.x.2.x.x.1

Detect Failure

C.1.1.x.x.x.2.x.x.2

Determine Correction C.1.1.x.x.x.2.x.x.3

Determine Indication

C.1.1.x.x.x.2.x.x.4

Archive Information

C.1.2 Operate C-Band 

Communications System

C. 1.2.2 

Maintain C-Band 

Communications 

System 

C. 1.2.3 

Configure C-Band 

Communications 

System 

C. 1.2.1 

Monitor C-Band 

Communications 

System 
NASA/CR—2010-216324 136

Figure 58.—Decomposition of monitor C-band 

communications system (adapted from Ref. 67).

Figure 59.—Decomposition of maintain C-band communications system (adapted from Ref. 67).

C. 1.2.2 

Maintain L-Band 

Communications 

System 

C. 1.2.2.2 

Perform 

Corrective 

Maintenance

C. 1.2.2 .1

Perform 

Preventive 

Maintenance

C. 1.2.2 .1.4

Determine 

Correction

C. 1.2.2 .1.3

Determine 

Indication

C. 1.2.2.1.2 

Recognize Event

C. 1.2.2.1.1

Provide Logistics 

Support

C. 1.2.2 .1.5

Archive 

Information

C. 1.2.2 .2.4

Execute 

Correction

C. 1.2.2 .2.3

Determine 

Indication

C. 1.2.2.2.2 

Detect Anomaly

C. 1.2.2.2.1

Provide Logistics 

Support

C. 1.2.2 .2.5

Archive 

Information
NASA/CR—2010-216324 137

Figure 60.—Decomposition of configure C-band communications system (adapted from Ref. 67). 

C. 1.2.3 .1

Determine 

Capacity

C. 1.2.3 

Configure L-Band 

Communications 

System 

C. 1.2.3.2 

Configure 

Communications 

Path

C. 1.2.3.3 

Configure 

Security

C. 1.2.3 4

Configure 

Parameters

These are the 

parameters that are 

not done in 

communications 

path or security

C. 1.2.3 .2.3

Disseminate 

Contact/Resource 

Information

C. 1.2.3.2.2 

Assign Resources

C. 1.2.3 .2.1

Determine 

Available 

Resources

C. 1.2.3 .3.3

Disseminate 

Security 

Information

C. 1.2.3.3.2 

Apply Security 

Resources

C. 1.2.3 .3.1

Determine 

Security Situation
NASA/CR—2010-216324 138

References

1. National Airspace System: System Engineering Manual. Version 3.1, Federal Aviation 

Administration ATO Operations Planning, June 6, 2006. 

2. System Requirements Document, Next Generation Air/Ground Communications (NEXCOM) 

Version 2.0. FAA–E–2958, FAA, Oct. 22, 2003, App. A, p. A–1.

3. Concept of Operations for the Next Generation Air Transportation System. Version 2.0, Joint 

Planning and Development Office, June 13, 2007, table 4–2, p. 4–4.

4. Concept of Operations for the Next Generation Air Transportation System. Version 2.0, Joint 

Planning and Development Office, June 13, 2007.

5. Final Program Requirements for Data Communications, FAA, May 13, 2009.

6. Fistas, Nikos; Phillips, Brent; and Budinger, James: Future Communications Study—Action Plan 17. 

Final Conclusions and Recommendations Report, DASC2007–4B6, 200.

7. Safety and Performance Requirements Standard for Air Traffic Data Link Services in Continental 

Airspace (Continental SPR Standard). RTCA DO–290, 2004.

8. FAA’s NextGen Implementation Plan 2009. NextGen Integration and Implementation Office, 

Washington, DC, Revised Feb. 10, 2009.

9. FCI Aeronautical Data Services Definition Task Report. 2043–0001, ITT Corp., Mar. 31, 2009. 

10. National Airspace System, System Requirements Specifications. NAS SR–1000, Revision B 

(Functional View), NAS Architecture 6, FAA/DOT, June 2008. 

11. SR1000 Requirements, FAA NAS Architecture 6, FAA/DOT, June 2008. 

12. Communications Operating Concept and Requirements for the Future Radio System. COCR 

Version 2.0, EUROCONTROL/FAA, 2007.

13. National Airspace System: Concept of Operations and Vision for the Future of Aviation. First ed., 

RTCA, Washington, DC, 2002.

14. IEEE Standard for Local and Metropolitan Area Networks, Part 16: Air Interface for Broadband 

Wireless Access Systems. IEEE 802.16-2009, 2009. http://standards.ieee.org/getieee802/802.16.html

15. Next Generation Air Transportation System, Integrated Plan. Version 1.0, Joint Planning and 

Development Office (JPDO)/DOT, Dec. 12, 2004. 

http://www.jpdo.gov/library/NGATS_v1_1204r.pdf

16. National Airspace System (NAS) Infrastructure Roadmaps. FAA. https://nasea.faa.gov/products/ir/

main Last updated Apr 29, 2010

17. Aeronautical Telecommunications: International Standards and Recommended Practices and 

Procedures for Air Navigation Services. Vol. II, annex 10, International Civil Aviation Organization, 

Montreal, Quebec, 2001.

18. Amendment to IEEE Standard for Local and Metropolitan Area Networks—Part 16: Air Interface for 

Fixed Broadband Wireless Access Systems—Physical and Medium Access Control Layers for 

Combined Fixed and Mobile Operation in Licensed Bands. IEEE 802.16e-2005, Feb. 28, 2006. 

http://standards.ieee.org/getieee802/802.16.html

19. National Airspace System: System Engineering Manual. Version 3.1, Federal Aviation 

Administration ATO Operations Planning, June 6, 2006, p. 4.4–29.

20. National Airspace System: System Engineering Manual. Version 3.1, Federal Aviation 

Administration ATO Operations Planning, June 6, 2006, p. 4.4–30.

21. Global Air Traffic Management Operational Concept. ICAO Document 9854, 2005.

22. Operating Concept of the Mobile Aviation Communication Infrastructure Supporting ATM Beyond 

2015. EUROCONTROL WP3—Synthesis Report, no. 1.0, 2002.

23. Data Communications Safety and Performance Requirements. Draft E, FAA Evaluation Release, 

FAA, Apr. 30, 2009.

24. Gilbert, Tricia, et al.: Future Aeronautical Communication Infrastructure Technology Investigation.

NASA/CR—2008-215144, 2008.
NASA/CR—2010-216324 139

25. National Airspace System: System Engineering Manual. Version 3.1, Federal Aviation 

Administration ATO Operations Planning, June 6, 2006, p. 4.3–5. 

26. System Requirements Document, Next Generation Air/Ground Communications (NEXCOM) 

Version 2.0. FAA–E–2958, FAA, Oct. 22, 2003, App. A, p. A–4.

27. System Requirements Document, Next Generation Air/Ground Communications (NEXCOM) 

Version 2.0. FAA–E–2958, FAA, Oct. 22, 2003, App. A, p. A–9.

28. National Airspace System: System Engineering Manual. Version 3.1. Federal Aviation 

Administration ATO Operations Planning, June 6, 2006, p. 4.7–6.

29. AS–IS System View (SV–2)—Existing and Near-Term (2009–2010) Telecommunications 

Infrastructure. Presented by ATO–W, Telecommunications Services Group (TSG), NAS Enterprise 

Architecture Conference. June 24, 2009.

30. Stratoti, Stephen D.: NAS Enterprise Architecture, NextGen 2025 System Interface Description 

SV–1p, System Context, FAA, June 24, 2009.

31. National Airspace System, System Requirements Specifications. NAS SR–1000, Revision B 

(Functional View), NAS Architecture 6, FAA/DOT, June 2008, Table 1, p. 19 (annotated). 

32. VHF Air-Ground Communications System Improvements Alternatives Study and Selection of 

Proposals for Future Action. RTCA DO–225, 1994.

33. Communications Operating Concept and Requirements for Future Radio System. 

EUROCONTROL/FAA COCR Version 2.0, 2007, p. 21.

34. Final Program Requirements for Data Communications, FAA, May 13, 2009, pp. 1–2 to 1–5. 

35. Concept of Operations for the Next Generation Air Transportation System. Version 2.0, Joint 

Planning and Development Office, June 13, 2007, p. 2–1.

36. Action Plan 17 Future Communications Study—Final Conclusions and Recommendations Report. 

Version 1.1, EUROCONTROL/FAA Memorandum of Cooperation, 2007, p. 4.

37. Concept of Operations for the Next Generation Air Transportation System. Version 2.0, Joint 

Planning and Development Office, June 13, 2007, p. 4–6.

38. Operating Concept of the Mobile Aviation Communication Infrastructure Supporting ATM Beyond 

2015. EUROCONTROL WP3—Synthesis Report, no. 1.0, 2002, p. 10.

39. Final Program Requirements for Data Communications, FAA, May 13, 2009, p. 1–1.

40. Final Program Requirements for Data Communications, FAA, May 13, 2009, pp. 1–1 to 1–2.

41. Anderson, Gregg: Data Communications, How We Want to Fly! Data Link Users Forum, FAA, 

Feb. 3, 2010, p. 9.

42. Action Plan 17 Future Communications Study—Final Conclusions and Recommendations Report. 

Version 1.1, EUROCONTROL/FAA Memorandum of Cooperation, 2007, p. 12.

43. Phillips, Brent; and Budinger, James: NextGen Air/Ground Communications Research, An Overview 

for FAA/John Marksteiner. FAA and NASA Glenn Research Center, Aug. 26, 2009.

44. Communications Operating Concept and Requirements for Future Radio System. 

EUROCONTROL/FAA COCR Version 2.0, 2007, p. 15.

45. NAS EA 2025 OV–1 & OV–2: Operational Context. MITRE/CAASD, FAA NAS EA Conference, 

June 24, 2009.

46. National Airspace System Enterprise Architecture (NAS EA) Portal. Service Roadmap: Initiate 

Trajectory Based Operations, 2010. 

https://nasea.faa.gov/products/roadmap/main/display/14/tab/solutionSet/ Accessed May 5, 2010.

47. National Airspace System Enterprise Architecture (NAS EA) Portal. Service Roadmap: Increase 

Arrivals/Departures at High Density Airports. 2010. 

https://nasea.faa.gov/products/roadmap/main/display/15/tab/solutionSet/ Accessed May 5, 2010.

48. National Airspace System Enterprise Architecture (NAS EA) Portal. Service Roadmap: Improve 

Collaborative ATM, 2010. https://nasea.faa.gov/products/roadmap/main/display/17/tab/solutionSet/

Accessed May 5, 2010.

49. 2025 System View (SV–2). ITT Corp., NAS Enterprise Architecture Conference, June 24, 2009.
NASA/CR—2010-216324 140

50. Concept of Operations for the Next Generation Air Transportation System. Version 2.0, Joint 

Planning and Development Office, June 13, 2007, p. xi.

51. Concept of Operations for the Next Generation Air Transportation System. Version 2.0, Joint 

Planning and Development Office, June 13, 2007, App. D.

52. Final Program Requirements for Data Communications, FAA, Aug. 19, 2009, pp. A–4 to A–20.

53. Hritz, Mike: System Wide Information Management (SWIM). SWIM TIM on Infrastructure and 

Technology, FAA, May 14, 2008.

54. Zelkin, Natalie; and Henriksen, Stephen: C-Band Airport Surface Communications System 

Engineering—Initial High-Level Safety Risk Assessment and Mitigation Document, NASA/

CR—2010-216325, 2010.

55. Delille, Francois: Flight Object, Interoperability and SWIM. Air Traffic Alliance—a New Way of 

Thinking. Thales Air Systems, ICNS 2007 Conference, Herndon, May 1–3, 2007.

56. National Airspace System Communications System Safety Hazard Analysis and Security Threat 

Analysis. Version 1.0, FAA, Feb. 21, 2006.

57. Communications Operating Concept and Requirements for the Future Radio System. COCR Version 

2.0, EUROCONTROL/FAA, 2007, p. 92.

58. Signal-in-Space Minimum Aviation System Performance Standards (MASPS) for Advanced VHF 

Digital Data Communications Including Compatibility With Digital Voice Techniques, RTCA 

DO–224B, 2005, p. 33–37.

59. Initial Assessment of Security Provisions of the IEEE 802.16e-2005 Standard for Airport Surface 

Communication. Internal NASA report, Dec. 22, 2009.

60. Mobile WiMAX—Part I: A Technical Overview and Performance Evaluation. WiMAX Forum, 

Aug. 2006. http://www.wimaxforum.org/technology/downloads/

Mobile_WiMAX_Part1_Overview_and_Performance.pdf

61. Andrews, Jeffrey G.; Ghosh, Arunabha; and Muhamed, Rias: Fundamentals of WiMAX. 

Understanding Broadband Wireless Networking. Prentice Hall Communications Engineering and 

Emerging Technologies Series, Pearson Education, Inc., 2007, Fig. 2.3—IP-Based WiMAX Network 

Architecture.

62. Upase, Bharathi; Hunukumbure, Mythri; and Vadgama, Sunil: Radio Network Dimensioning and 

Planning for WiMAX Networks. Fujitsu Sci. Tech. J., vol. 43, no. 4, 2007, pp. 435–450.

63. Genc, V., et al.: IEEE 802.16J Relay-Based Wireless Access Networks: An Overview. IEEE Wireless 

Communications, vol. 15, no. 5, 2008, pp. 56–63.

64. Heuel, Steffen; and Mellein, Heinz: Mobile WiMAXTM Throughput Measurements Using 

R&S®CMW270, Rohde & Schwarz Application Note 05.2009–1SP10, 2009.

65. IEEE Standard for Local and Metropolitan Area Networks, Part 16: Air Interface for Fixed and 

Broadband Wireless Access Systems. IEEE Std 802.16–2004, pt. 16, 2004.

66. TDD and FDD Wireless Access Systems White Paper. Airspan Networks Inc., 2007.

67. National Airspace System Communications System Safety Hazard Analysis and Security Threat 

Analysis. Version 1.0, FAA, Feb. 21, 2006, App. A.
NASA/CR—2010-216324 141

Bibliography

Biggs, Michael: Spectrum Issues and WRC–07 Preparation. Presented at the 2007 ICNS Conference, 

Session J: Aviation Spectrum, Herndon, VA, 2007.

Budinger, James M.: Technology Assessment of the Future Aeronautical Communications System. 

NASA/CR—2005-213587 (TR04055), 2005.

Coleman, Kelvin: Next Generation Air Transportation System. Presented at the COMSTAC Meeting, 

FAA, Washington, DC, 2008.

Communications Operating Concept and Requirements for the Future Radio System. 

EUROCONTROL/FAA COCR Version 2.0, 2007.

DeGarmo, Matt: Operational Services and Environmental Definition (OSED) for Unmanned Aircraft 

Systems (UAS), Draft, 224–09/SC203–036, RTCA, Inc., Oct. 23, 2009.

Delivering NextGen. FAA Collaborative Air Traffic Management, Jan. 29, 2009.

European Air Traffic Management Master Plan. Ed. 1, 2009.

Fistas, Nikos: Future Aeronautical Communication System—FCI. 9th ICNS Conference, Arlington, VA, 

2009.

Fistas, Nikos: Future Communications Infrastructure: An Update on ECTL Activities. Iris Phase 1 Final 

Presentation Meeting, ESA/ESTEC, 2009.

Gilbert, Tricia, et al.: Identification of Technologies for Provision of Future Aeronautical 

Communications. NASA/CR—2006-214451 (TR06027), 2006.

NAS-Wide Information Services (NWIS) Architecture Development, CNS–ATM TASK 15, TR03010, 

ITT Industries, Advanced Engineering and Sciences, Feb. 22, 2003.

NextGen Mid-Term Implementation Task Force Interim Report. RTCA, Washington, DC, 2009.

Pouzet, Jacky (Head of CoE/CN/COM Unit): Future Aeronautical Communication System—FCI: Update 

on European Activities. DLK Users Forum, Brussels, Belgium, Sept. 2009.

Proposed changes to Annex 16 of 5B/296–E. Preliminary Draft New Report ITU–R M [UAS–SPEC], 

Characteristics of unmanned aircraft systems (UAS) and Spectrum requirements to support their safe 

operation in non-segregated airspaces, Document No. USWP5B09–25, ITU, Aug. 4, 2009.
REPORT DOCUMENTATION PAGE Form Approved 

OMB No. 0704-0188 

The public reporting burden for this collection of information is estimated to average 1 hour per response, including the time for reviewing instructions, searching existing data sources, gathering and maintaining the 

data needed, and completing and reviewing the collection of information. Send comments regarding this burden estimate or any other aspect of this collection of information, including suggestions for reducing this 

burden, to Department of Defense, Washington Headquarters Services, Directorate for Information Operations and Reports (0704-0188), 1215 Jefferson Davis Highway, Suite 1204, Arlington, VA 22202-4302. 

Respondents should be aware that notwithstanding any other provision of law, no person shall be subject to any penalty for failing to comply with a collection of information if it does not display a currently valid OMB 

control number. 

PLEASE DO NOT RETURN YOUR FORM TO THE ABOVE ADDRESS. 

1. REPORT DATE (DD-MM-YYYY)

01-12-2010 

2. REPORT TYPE

Final Contractor Report 

3. DATES COVERED (From - To)

4. TITLE AND SUBTITLE

C-Band Airport Surface Communications System Standards Development 

Phase I Final Report

5a. CONTRACT NUMBER

NNC05CA85C 

5b. GRANT NUMBER

5c. PROGRAM ELEMENT NUMBER

6. AUTHOR(S)

Hall, Edward; Isaacs, James; Zelkin, Natalie; Henriksen, Steve 

5d. PROJECT NUMBER

5e. TASK NUMBER

Task 7 

5f. WORK UNIT NUMBER

WBS 031102.03.03.0677.10 

7. PERFORMING ORGANIZATION NAME(S) AND ADDRESS(ES)

ITT Corporation Information Systems 

12930 Worldgate Drive 

Herndon, Virginia 20170-6008 

8. PERFORMING ORGANIZATION

 REPORT NUMBER

E-17258 

9. SPONSORING/MONITORING AGENCY NAME(S) AND ADDRESS(ES)

National Aeronautics and Space Administration 

Washington, DC 20546-0001 

10. SPONSORING/MONITOR'S

 ACRONYM(S)

NASA 

11. SPONSORING/MONITORING

 REPORT NUMBER

NASA/CR-2010-216324 

12. DISTRIBUTION/AVAILABILITY STATEMENT

Unclassified-Unlimited 

Subject Category: 04 

Available electronically at http://gltrs.grc.nasa.gov 

This publication is available from the NASA Center for AeroSpace Information, 443-757-5802

13. SUPPLEMENTARY NOTES

14. ABSTRACT

This document is being provided as part of ITT’s NASA Glenn Research Center Aerospace Communication Systems Technical Support 

(ACSTS) contract NNC05CA85C, Task 7: “New ATM Requirements--Future Communications, C-Band and L-Band Communications 

Standard Development.” The proposed future C-band (5091- to 5150-MHz) airport surface communication system, referred to as the 

Aeronautical Mobile Airport Communications System (AeroMACS), is anticipated to increase overall air-to-ground data communications 

systems capacity by using a new spectrum (i.e., not very high frequency (VHF)). Although some critical services could be supported, 

AeroMACS will also target noncritical services, such as weather advisory and aeronautical information services as part of an airborne 

System Wide Information Management (SWIM) program. AeroMACS is to be designed and implemented in a manner that will not disrupt

other services operating in the C-band. This report defines the AeroMACS concepts of use, high-level system requirements, and 

architecture; the performance of supporting system analyses; the development of AeroMACS test and demonstration plans; and the 

establishment of an operational AeroMACS capability in support of C-band aeronautical data communications standards to be advanced in 

both international (International Civil Aviation Organization, ICAO) and national (RTCA) forums. This includes the development of system 

parameter profile recommendations for AeroMACS based on existing Institute of Electrical and Electronics Engineering (IEEE) 802.16e2009 standards. 

15. SUBJECT TERMS

Aircraft communication; Wireless communications; Airports; Air traffic control 

16. SECURITY CLASSIFICATION OF: 17. LIMITATION OF

 ABSTRACT

UU 

18. NUMBER

 OF 

 PAGES

173 

19a. NAME OF RESPONSIBLE PERSON

STI Help Desk (email:help@sti.nasa.gov) 

a. REPORT

U 

b. ABSTRACT

U 

c. THIS 

PAGE

U 

19b. TELEPHONE NUMBER (include area code)

443-757-5802 

Standard Form 298 (Rev. 8-98)

Prescribed by ANSI Std. Z39-18