New ATM Requirements Future Communications, – C-Band …...New ATM Requirements - Future...

New ATM Requirements – Future Communications, C-Band and L-Band Communications Study AeroMACS ATC/AOC Segregation Report SE2020 TO 0008 (TORP 1240) Task 3.1 Contract # DTFAWA-10-D-00028 Final Report Revision: 1.1 Date: January 28, 2013

Prepared for: Federal Aviation Administration

Attn: Brent Phillips

Prepared by: ITT Exelis

12930 Worldgate Drive Herndon, Virginia 20170-6008 USA

New ATM Requirements - Future Communications, C-Band and L-Band Communications Study January 28, 2013

AeroMACS ATC/AOC Segregation Report Final Report

PREFACE This Federal Aviation Administration (FAA) contractor report summarizes and documents the work performed to support C-band Aeronautical Mobile Airport Communications System (AeroMACS) technical and standards development activities.

This work is performed under the FAA SE2020 contract Task Order (TO) 0008 (TORP 1240), based on direction provided by the FAA Work Plan in Support of Action Plan 30 (AP-300 New ATM Requirements – Future Communications - and Coordination Plan 4.4 (CP 4.4) – Data Link Technologies as a follow-on to the FAA/EUROCONTROL Cooperative Research Agreement (Action Plan 17 (AP−17)), commonly referred to as the Future Communications Study (FCS).

2



Revision Record Revision Description Date Entered By

0.1 In-progress Report 10/31/12 Ward Hall 0.2 Draft Final Report 12/14/12 Ward Hall 1.0 Final Report 12/28/12 Ward Hall 1.1 Final Report - Updated 01/28/13 Natalie Zelkin

3



EXECUTIVE SUMMARY This document presents the results of the activities supporting AeroMACS standards development under Task 3.1 of the SE2020 TO 0008, Contract Year 2. This report builds on activities and the reports submitted to the FAA in 2011 and early 2012 documenting the work performed in Year 1. The current phase of Exelis work is being performed in close cooperation with the FAA, NASA, Honeywell, and EUROCONTROL.

The overall goal of AeroMACS standardization activities is to develop an international AeroMACS standard to assure global interoperability of future communications systems. Exelis is supporting the FAA in AeroMACS standardization. Task 3.1 focused on developing and assessing the requirements for, and methods of, segregating different AeroMACS services.

Precedence exists in providing different services (i.e. both Air Traffic Control (ATC) services and Airline Operational Control (AOC) services) on the same link (e.g. the FAA’s Data Comm program). This report discusses FAA policy and operational issues for sharing of the AeroMACS network and provides analysis and test results of features that are available to implement effective sharing of network resources with non-FAA applications.

In general, two primary methods of assuring data segregation are available: 1) implementation of multiple independent networks and 2) the use of a single network using traffic-handling features available within the AeroMACS profile. The method chosen has implications on network performance and architecture.

From the policy perspective, AeroMACS system operated by a single communications carrier would be allowed to provide both AOC and ATC data communications services, as long as the FAA continues to operate its own ATC voice communications system on the airport surface. It is expected that the FAA will continue to operate its ATC voice communications system for the foreseeable future for all flight domains.

From the spectrum perspective, AeroMACS can transport ATC and AOC traffic across AeroMACS with segregation and prioritization with two primary methods. The first method is to implement two networks that are physically separate and occupy separate portions of the AeroMACS spectrum. The second method utilizes a single network that occupies a single set of channels and depends on network control methods for traffic segregation and prioritization. Use of a common network for ATC, AOC, and lower-priority traffic depends on the use of methods for data segregation and the use of traffic priority settings that will assure the on-time delivery of high-priority critical data. AeroMACS scheduling features allow establishing priority handling of critical data.

The ability of AeroMACS to segregate and prioritize traffic was analyzed using the Cleveland prototype network1 in a series of tests evaluating the following capability areas:

1) Service Prioritization - control scheduling and network priority for traffic from multiple services

1 The AeroMACS prototype network built at the NASA Glenn campus and the Cleveland Hopkins airport (CLE) is a full data network containing two base stations and eight fixed-site subscriber stations. Central servers for Connectivity Service Network (CSN) functions contain a secure network router, Network Management System (NMS) and Authentication, Authorization, and Accounting (AAA) functions.

4



2) Segment Differentiation - segregate and maintain traffic segregation from multiple operational segments like ATC and AOC operations

3) Mixed Traffic Types – simultaneous handling of multiple traffic types (continuous, burst, time-critical) using the UDP and TCP protocols

4) Preemption of Services – use of Quality of Service (QoS) and network priority settings to assure that low priority traffic (Best Effort) will be sacrificed to assure on-time delivery of higher-priority traffic in congested network conditions

5) Network entry in congested conditions – use of QoS settings to assure that mobile stations that are carrying high-priority traffic can enter the AeroMACS network and establish a service flow

Overall, supported by policy and operational decisions, the tests validated that AeroMACS technology offers methods for data segregation and prioritization enabling the co-existence of AOC/ATC traffic on the same network. Additionally, the tests validated our understanding of system behavior given the settings selected for the AeroMACS Profile.

Results of the analyses presented in this report were translated into recommended inputs to Minimum Operational Performance Standards (MOPS) and Standards and Recommended Practices (SARPs) documents being developed by the RTCA SC-223 and ICAO ACP WG-S respectively. Additionally, the results of the analyses could be used to support development of the Guidance Material/Technical Manual.

It is expected that AeroMACS standards development will continue well beyond 2012. Europe is expected to conduct AeroMACS SARPs validation activities and lead the development of the Technical Manual/Guidance Material. The U.S. will closely monitor and actively participate in standardization activities.

Contingent on Year 3 funding, Exelis will continue providing support to the FAA AeroMACS related work under the TO 0008.

5



Contents Preface ......................................................................................................................................................... 2

Executive Summary ....................................................................................................................................... 4

1. Background ........................................................................................................................................... 8

2. Document Overview .............................................................................................................................. 9

3. ScoPE .................................................................................................................................................... 9

4. AeroMACS Security Analysis and Standards Development Support -Segregation and Transport of ATC and AOC Data ............................................................................................................................................. 10 4.1. Introduction ........................................................................................................................................... 10 4.2. Policy and Operational Issues ................................................................................................................ 10 4.3. Introduction to Technical Analysis ........................................................................................................ 10 4.4. Data Segregation and Transport Methods ............................................................................................ 12

4.4.1 Multiple or Single AeroMACS Network ...................................................................................... 12 4.4.2 Potential ATC/AOC Spectrum Allocations Based on Operational Scenarios ............................. 14 4.4.3 Priority Methods in AeroMACS .................................................................................................. 16

4.5. Assessment of Methods for Segregation of Different Services in CLE Test Bed. .................................. 20

5. Conclusion ........................................................................................................................................... 32

6. Follow on Work .................................................................................................................................... 33

6



Table of Figures Figure 1. WiMAX Forum Reference Architecture .................................................................................................... 13 Figure 2. Multiple Operator Network Illustration ................................................................................................... 14 Figure 3. Channel Allocation Within AeroMACS Spectrum ..................................................................................... 15 Figure 4. Potential Additional Channel Allocation within AeroMACS Spectrum ..................................................... 15 Figure 5. Notional Dual Network Channel Assignments ......................................................................................... 16 Figure 6. Example Traffic Scheduling and Priority ................................................................................................... 20 Figure 7. CLE Test Configuration.............................................................................................................................. 22 Figure 8. VLAN Data Segregation Test ..................................................................................................................... 26 Figure 9. VLAN Throughput Rate Measurement ..................................................................................................... 30

Table of Tables Table 1. Potential AeroMACS Uses .......................................................................................................................... 11 Table 2. AeroMACS QoS Properties ......................................................................................................................... 16 Table 3. AeroMACS QoS Properties ......................................................................................................................... 22 Table 4. CLE Test Descriptions ................................................................................................................................. 23 Table 5. CLE Service Prioritization Tests .................................................................................................................. 24 Table 6. CLE Segment Differentiation Tests ............................................................................................................ 25 Table 7. CLE Mixed Traffic Type Tests ..................................................................................................................... 27 Table 8. Preemption of Services Test Summary ...................................................................................................... 28 Table 9 Test Bed AeroMACS Network Equipment .................................................................................................. 38

7



1. BACKGROUND During the past six years ITT Exelis has performed multiple phases of technology assessment, systems engineering and testing for future C-band and L-band Air/ to Ground (A/G) communications systems to be used for Air Traffic Control (ATC). This work has been a joint effort between the FAA and EUROCONTROL under cooperative research Action Plan (AP-17), also known as the Future Communications Study (FCS). The Study was initiated in anticipation of the increased demand for data communications coming from both FAA NextGen and European Single European Sky ATM Research (SESAR) programs. As part of its FCS activities, Exelis provided specific recommendations for the Future Communications Infrastructure (FCI) technologies to be used for Air Traffic Management (ATM), for operations in the aeronautical Very High Frequency (VHF) band, C-band, L-band, and satellite bands. These recommendations have been endorsed by the FAA, EUROCONTROL, and the International Civil Aviation Organization (ICAO).

Follow-on research and technology development recommended by the FAA was included in the "NextGen Implementation Plan 2010." The implementation plan included a Fiscal Year (FY) 10 Solution Set Work Plan for C-band and L-band future communications research under the title "New Air Traffic Management (ATM) Requirements."

In January 2010, the FAA approved a Project Level Agreement (PLA FY10_G1M 02-02) entitled "New ATM Requirements - Future Communications," to support the FY10 portion of that Solution Set Work Plan. The Plan included updates to the concepts of use, requirements, and architecture for both a new C-band airport surface wireless communications system and a new L-band en route communications system. It also included activities for the completion of the C-band Aeronautical Mobile Airport Communications System (AeroMACS) validation measurements, interference assessments for enhanced AeroMACS performance, and monitoring of EUROCONTROL's development of the L-band Digital Aviation Communications System (LDACS) to support en route operations.

A PLA for FY11 was developed and approved to continue the work titled "New ATM Requirements - Future Communications;" and a PLA for FY12 entitled the “Flight and State Date Management – Future Communications Infrastructure” followed, to provide the foundation to support the FAA and EUROCONTROL efforts to produce data communications solutions with global interoperability. The Plan called for a continuation of the work previously performed by Exelis that focused on resolving outstanding technical issues to support AeroMACS Minimum Operational Performance Standards (MOPS) development; conducting multiple tests using the National Aeronautics and Space Agency (NASA) Cleveland AeroMACS Test bed to validate Air Traffic Control (ATC) mobile communications on the airport surface; and continuing the ongoing assessment of the proposed LDACS system to ensure that the system satisfies the FAA's future communications needs.

Exelis work was guided by the FAA Work Plan in Support of AP-30 New ATM Requirements – Future Communications and Coordination Plan 4.4 (CP 4.4) – Data Link Technologies, follow on cooperative research to AP-17. The proposed AP-30 and CP 4.4 ensure coordinated development of FCI to help enable the advanced ATM concepts of operation (ConOps) envisioned for both NextGen in the United States and the SESAR program in Europe.

This phase of Exelis work has been performed in close cooperation with the FAA, NASA, Honeywell, and EUROCONTROL under the SE2020 contract, Task Order (TO) 0008 (TORP 1240) and is being conducted over three years. This document presents the results of the activities supporting AeroMACS standards development under Task 3.1 of TO 0008. The Period of Performance (PoP) for the entire three year TO is 19 August 2011

8



through 18 August 2014. The PoP for the Contract Year 2 tasks is 19 August 2012 through 18 August 2013. The reports on activities related to LDACS development under Task 4 and other AeroMACS standards development under Tasks 3.3 and 3.2 of TO 0008 are being submitted as separate documents. These reports build on the activities and reports submitted to the FAA in 2011 and early 2012 documenting the work performed in Contract Year 1.

2. DOCUMENT OVERVIEW The remainder of this document is organized as follows:

Section 3 of this document presents the scope of Task 3.3.

Section 4 discusses FAA policy and operational issues for sharing of the AeroMACS network and provides analysis and test results of features that are available to implement effective sharing of network resources with non-FAA applications.

Section 5 refers to future AeroMACS technical and standards development support.

Abbreviations used throughout the document are defined in Appendix A.

3. SCOPE The overall goal of AeroMACS standardization activities is to develop an international AeroMACS standard to assure global interoperability of future aeronautical communications systems. Exelis is supporting the FAA in AeroMACS standardization. Task 3.1 focuses on developing and assessing the requirements for, and methods of, segregating different AeroMACS services. Precedence exists in providing different services (i.e. both Air Traffic Control (ATC) services and Airline Operational Control (AOC) services) on the same link (e.g. the FAA’s Data Comm program). Accordingly, the activities on this task included:

• Identifying and defining potential ATC/AOC spectrum allocations based on operational scenarios

o Investigating means for accommodating the co-existence of multiple AeroMACS operators (i.e. Datalink Service Providers (DSPs)) within same airport/coverage area, specifically a method for aircraft access to both AOC & ATC data if services are separated over different channels and the aircraft carries a single radio

• Defining rules for spectrum sharing for aircraft access to AOC and ATC data

• Developing and assessing requirements for, and methods of, segregating different services in the CLE Test Bed

o Service Prioritization

o Segment Differentiation

o Mixed Traffic Types

o Preemption of Services

o Network entry in congested conditions

The results of the analysis and testing are presented in Section 4 of this report.

9



4. AEROMACS SECURITY ANALYSIS AND STANDARDS DEVELOPMENT SUPPORT -SEGREGATION AND TRANSPORT OF ATC AND AOC DATA

4.1. Introduction

This section discusses methods of implementing AeroMACS that will provide reliable broadband communications support of airport surface applications. Section 4.2 discusses FAA policy and operational issues for sharing of the AeroMACS network, while the remainder of Section 4.3 provides analysis and test results of features that are available to implement effective sharing of network resources with non-FAA applications.

4.2. Policy and Operational Issues

Title 14, Section 121.99 of the Code of Federal Regulations establishes the requirement of independence between AOC communications (e.g. with an air carrier dispatch office) and ATC communications:

a) “Each certificate holder conducting domestic or flag operations must show that a two-way communication system, or other means of communication…, is available over the entire route. The communications may be direct links or via an approved communication link that will provide reliable and rapid communications under normal operating conditions between each airplane and the appropriate dispatch office, and between each airplane and the appropriate air traffic control unit.

b) Except in an emergency, for all flag and domestic kinds of operations, the communications systems between each airplane and the dispatch office must be independent of any system operated by the United States.”

The key portion of that regulation, for the purposes of this report, centers in (b), which establishes the requirement of independent AOC and ATC communications systems. Recently, as a consequence of the FAA’s Data Communications Program Office’s interest in allowing the provision of both AOC voice/data communications and ATC data communications by the same communications carrier, the FAA’s Chief Counsel for Regulations rendered an opinion that this would satisfy the independence requirement of 121.99(b), as long as the FAA continues to maintain and operate a separate and independent ATC voice communications system.2

Thus, for the purposes of this study, an AeroMACS system operated by a single communications carrier would be allowed to provide both AOC and ATC data communications services, as long as the FAA continues to operate its own ATC voice communications system on the airport surface. It is expected that the FAA will continue to operate its ATC voice communications system for the foreseeable future for all flight domains.

4.3. Introduction to Technical Analysis

AeroMACS is a communications technology that provides an IP network capable of simultaneously supporting ATC and AOC application traffic. Methods for data privacy and priority are desirable for assurance of delivery of

2 Federal Aviation Administration Memorandum, July 15, 2008, Data-link Communications Provided for an Air Carrier and the FAA by the Same Contractor

10



critical data in a timely and controlled manner. AeroMACS has Quality of Service (QoS) and priority setting features that provide data assurance. Mechanisms guarantee quality by giving real-time data priority over non-real-time data. QoS ensures high quality performance for inelastic services (i.e VTC, VOIP, Streaming Media etc.) that require a certain level of bandwidth to function without delay, error, jitter, dropped packets and out of order delivery.

Priority establishment serves a primary purpose according to ICAO Document 98803 on ATN priority. Traffic priority ensures that high priority safety-related data is not delayed by low priority non-safety data, in particular, when the network is overloaded with low priority data.

Table 1 lists potential usage of AeroMACS to enable communications for certain applications4. This table and the associated Operations Concept document show that a variety of ATC and AOC applications could use AeroMACS for data transfer to and from the aircraft during all phases of airport surface operation. The correct use of AeroMACS features and settings for traffic security, priority and on-time delivery is essential for support of these applications with high reliability.

Table 1. Potential AeroMACS Uses

Airport Surface Communication Application

ADS-C Airport Surface Map CM CPDLC D-FIS (includes OTIS, ATIS, NOTAM, VOLMET, AIB,METAR, TAF, SIGMET, RVR, HZWX) EFB Application updates Flight Plan Ground/Ground links (e.g. MultiLateration GSs, ADS-B GSs)

Load Sheet Log Book(s) transfer OOOI SWIM

3 MANUAL ON DETAILED TECHNICAL SPECIFICATIONS FOR THE AERONAUTICAL TELECOMMUNICATION NETWORK (ATN) using ISO/OSI standards and protocols, ICAO Doc 9880-AN/46608 4 AeroMACS Operations Concept, prepared for ICAO ACP WG-S 2nd Meeting, Canada, Montreal, 23-26 October 2012

11



Airport Surface Communication Application

TIS Vehicle ADS (non-movement area) VOIP Weather (graphical or textual)

4.4. Data Segregation and Transport Methods

4.4.1 Multiple or Single AeroMACS Network

Two primary methods of assuring data segregation are available for AeroMACS: 1) implementation of multiple independent networks and 2) the use of a single network using traffic-handling features available within the AeroMACS profile. The method chosen has implications on network performance and architecture that will be examined in this section.

Two or more networks need to be installed at an airport to implement segregation of ATC and AOC traffic for the independent network method. This method provides absolute separation of traffic over AeroMACS air links by not intermixing traffic on the same network. However, this absolute traffic segregation has the following associated costs:

1) Duplicative ground hardware investment in base station, Access Service Network (ASN), and Connectivity Service Network (CSN) equipment.

2) Segmented spectrum allocations to support multiple networks.

3) Dual AeroMACS radio functions for aircraft avionics implemented either as dual, concurrent-operation radios or a means to manually select between networks using a single radio

4) Inflexibility to allocate air link resources to ATC traffic at the expense of lower-priority AOC traffic under stressed network conditions

5) Increased potential for MSS feeder link interference because of emissions from multiple networks The use of multiple independent networks has the following advantages/benefits:

1) Segregation of service traffic through AeroMACS

2) Simplified interfaces for multiple Network Access Providers (NAP’s)

The WiMAX Network Reference Architecture provides a flexible framework that can accommodate a variety of AeroMACS deployment scenarios. Network architectures for single or multiple NAPs and single or multiple network service providers (NSPs) are accommodated in the framework.

Relationships between NAPs and NSPs and the assignment of network functions at a single airport are illustrated in Figure 1. Multiple NAPs could be implemented in an AeroMACS network for the purpose of isolating types of traffic. For example, one NAP could be implemented to handle critical ATC data with a second NAP handling less critical traffic for AOC and airport operations. Dedicated base station hardware, ASN gateway server hardware and software, and spectrum allocations are required to implement each NAP. Spectrum bandwidth limitations

12



make one NAP installation per airport desirable and greater than two NAP installations per airport impractical for multi-sector Base Station (BS) installations. Multiple NSP installations at an airport are more practical to implement in terms of resources because instantiation of a NSP requires a CSN server and software can be served by a single NAP. NSPs can be responsible for differing applications. However, multiple NSPs will need to support and respond to over-all policies for service provisions and QoS assignments.

BS

BS

ASNGateway

BS

BS

ASNGateway

CSN

CSN

NSP 1

NSP 2

NAP 1

NAP 2

R3

R3

R3

R3

Figure 1. WiMAX Forum Reference Architecture

Figure 2 provides a notional illustration of how the WiMAX Forum reference architecture could support airport services. Multiple mobile and fixed-position Subscriber Stations (SSs) are supported with access to the AeroMACS network by one or multiple NAPs. Access is provided to multiple operators through one or more NSPs. NSPs can be located either at the airport or a remote location. An AeroMACS-equipped airplane may visit an airport where its carrier has not established services as an NSP. Business relationships can be established where AeroMACS service would be made available by one of the local NSPs present at the airport. The NSP that provides this service to a visiting airplane is called the “Away NSP” while the “Home NSP” provides service to its own subscribers.

13



Figure 2. Multiple Operator Network Illustration

Network security is an important consideration when determining the architecture for multiple NSPs. AeroMACS security studies are occurring within the ICAO Aeronautical Communications Panel (ACP) WG-S at present that will impact and add details of operation to the multiple operator architecture.

4.4.2 Potential ATC/AOC Spectrum Allocations Based on Operational Scenarios

From the spectrum perspective, AeroMACS can transport ATC and AOC traffic across AeroMACS with segregation and prioritization with two primary methods. The first method is to instantiate two networks that are physically separate and occupy separate portions of the AeroMACS spectrum. The second method utilizes a single network that occupies a single set of channels and depends on network methods for traffic segregation and prioritization. Each of these methods will be examined in the following paragraphs.

First, methods for allocating the world-wide assigned spectrum of 5091 to 5150 MHz to multiple networks will be examined in this section. The allocation of eleven, 5 MHz AeroMACS channels is illustrated notionally in Figure 3. Channel center frequencies are placed on 5 MHz frequency increments beginning at 5095 MHz. The upper-most channel is centered at 5145 MHz, which provides a 2.5 MHz guard band at the upper AM(R)S band edge to suppress out-of-band emissions. The lowest channel, centered at 5095 MHz, provides less guard band but may be permissible because the spectrum below this channel is allocated for aviation use.

14



5091 MHz 5150 MHz

Other Aviation

Allocation

Non-Aviation

Allocation

Current AM(R)S Allocation for AeroMACS

Figure 3. Channel Allocation Within AeroMACS Spectrum

The 5091 to 5150 MHz AeroMACS spectrum was authorized on a world-wide basis for AM(R)S surface communications during the World Radiocommunications Conference (WRC) in 2007. Use of additional spectrum between 5000 and 5030 MHz may be authorized on a regional basis. An additional five AeroMACS channels may be usable in some regions as defined in Figure 4.

5000 MHz 5030 MHz

Other Aviation

Allocation

Non-Aviation

Allocation

Potential AM(R)S Allocation

Figure 4. Potential Additional Channel Allocation within AeroMACS Spectrum

AeroMACS systems that support a large geographic area and handle high traffic volumes may be implemented with base stations having sectorized coverage where the region around a base station is divided into sectorized coverage through use of directive antennas and an AeroMACS transceiver for each antenna. Two antennas and two transceivers could support a sector in a Multiple-Input, Multiple Output (MIMO) system. Nearby sector transceivers could be placed on differing channel frequencies to avoid cross interference that would limit channel capacity. Deployment of multiple networks at an airport would maximize their channel capacity if sectors avoid overlapping in frequency for overlapping coverage regions.

A single airport network that segregates traffic from different segments with networking methods will be able to use all eleven of the channels shown in Figure 3 and potentially the five channels of Figure 4 available to support traffic volume and provide geographic coverage. However, the spectrum must be divided when two or more networks are implemented.

A notional channel assignment supporting two networks is illustrated in Figure 5. Here, a portion of the available channels are assigned to an ATC-specific network and the remaining channels are assigned to a network carrying traffic from AOC and other applications. Split channel allocations are illustrated for the

15



currently-authorized 5091 to 5150 MHz spectrum and the 5000 to 5030 MHz spectrum that may be assigned to AeroMACS on a regional basis. The number of channels reserved for an ATC-specific network will depend on the expected traffic volume and the required geographic coverage area.

Figure 5. Notional Dual Network Channel Assignments

4.4.3 Priority Methods in AeroMACS

Use of a common network for ATC, AOC, and lower-priority traffic depends on the use of methods for data segregation and the use of traffic priority settings that will assure the on-time delivery of high-priority critical data. This section examines the scheduling features of AeroMACS that are available to establish priority handling of critical data.

The IEEE 802.16 Media Access Layer (MAC) used by AeroMACS is connection oriented. Traffic within service flows between SSs and BSs is handled according to a set of QoS parameters known as a QoS class. Each QoS class includes parameters such as traffic priority, maximum sustained traffic, minimum sustained traffic, and maximum latency. A number of different bandwidth-request mechanisms are specified in the IEEE 802.16 standard. Table 2 lists five QoS service classes that are available in AeroMACS and the properties of each class.

Table 2. AeroMACS QoS Properties

QoS Service

Scheduling Parameters Scheduling Method Properties

UGS Unsolicited Grant Service

Maximum sustained rate

Maximum latency tolerance

Maximum Jitter tolerance

Fixed bandwidth is always granted based on Minimum Reserved Rate with Unsolicited grant

Real-time service flows

Fixed-size data packets

Periodic basis

ertPS

Enhanced Real-time Poling Service

Minimum reserved rate



Jitter tolerance

Non-periodic basis Real-time service flows

Variable-size data packets

16



QoS Service

Scheduling Parameters Scheduling Method Properties

Traffic priority

rtPS Real-time Poling Service




Traffic priority

Periodic unsolicited Unicast Poll. Interval can be specified or BS will use scheduler.

Real-time service flows


Periodic basis

nrtPS

Non-real-time Poling Service



Traffic priority

Unicast Poll of period <1 second and Broadcast poll

Non-real time services


Periodic basis

BE Best Effort


Traffic priority

Broadcast Poll

(Contention based) or piggyback a request on out-going PDU

Best effort traffic

The QoS classes listed in Table 2 vary by their methods for scheduling traffic flows. The QoS scheduling process establishes traffic priority through the AeroMACS air interface. In addition, AeroMACS provides a setting in each Service Data Unit (SDU) for network priority outside of AeroMACS.

A publication by IEEE shows the functions available to implement QoS that reside within the AeroMACS BS and Subscriber Station (SS) Media Access Control (MAC) layer5. Traffic is queued into downlink or uplink queues in SDUs for transmission. The BS downlink scheduler queues downlink SDUs for transmission on a frame-by-frame basis according to the status of the queues and a set of QoS rules. The BS also controls access to the medium in the uplink direction by allocating uplink bandwidth to each SS according to SS reported demand. An uplink scheduler in the BS estimates the residual backlog at each uplink connection and allocates future uplink grants according to the respective set of QoS parameters and the virtual status of the queues. An uplink scheduler residing in the SS distributes the bandwidth allocated by the BS across multiple users and schedules SDUs for transmission.

5 C.Cicconetti, L.Lenzini, E.Mingozzi, C.Eklund, “Quality of service support in IEEE 802.16 networks”, IEEE Network, Vol. 20, Issue 2, Mar./April 2006

17



The algorithm that governs the scheduling of traffic for transmission must meet QoS requirements. A key issue is allocation of resources among users to meet QoS constraints and at the same time maximize throughput. The IEEE 802.16 standard does not specify resource allocation or SS admission control mechanisms, but instead, the choice of scheduling algorithm is left to the equipment supplier.

Several scheduling algorithms have been developed and are available for use in AeroMACS, including the Round Robin (RR), Weighted Round Robin (WRR), and the Deficit Fair Priority Queue (DFPQ) algorithms6. A brief description of each algorithm follows:

Round Robin (RR) – Fairly assigns bandwidth allocations to all user connections one-by-one. In RR, allocations may be made for connections that have nothing to transmit which penalizes overall system throughput. RR does not assure QoS for different service classes and therefore is not suitable for AeroMACS use without modification.

Weighted Round Robin (WRR) – Modifies the RR algorithm by using weights in terms of queue length and packet delay to adjust for QoS throughput and delay requirements. Idle connections are skipped and only active connections are serviced.

Deficit Fair Priority Queue (DFPQ) – Queues are defined for uplink and downlink directions and the service classes of rtPS, nrtPS, and BE. This algorithm distributes the available bandwidth among the service flows. Highest priority queues will be serviced first until the assigned bandwidth is allocated, after which lower priority queues will have the chance to be served. The queues are ordered according to the service classes with, for example, rtPS > nrtPS > BE. Within each service class, downlink transmission has a higher priority than uplink transmission. The scheduler might interrupt servicing the rtPS queue and start servicing the BE queue even if there are still packets in the rtPS queue. As a result, these packets will expire if their deadlines expire or if there is no more available bandwidth.

Many scheduling algorithms that govern BS and SS scheduling are available. Figure 6 illustrates a logical scheduling and priority-setting method similar to DFPQ where high-priority queues are serviced first. This figure illustrates, for example, that SDUs tagged with the Unsolicited Grant Service (UGS) QoS are sent to the physical layer for transmission before lower-priority SDUs. Additional algorithms can be applied to allocate traffic to queues of the same service class. Also illustrated is the SDU information regarding how the traffic should be prioritized outside of the AeroMACS air link with 1-7 priority settings.

The AeroMACS hardware manufactured by Alvarion and installed in the Cleveland prototype test bed has a scheduling algorithm that affected the test results to be discussed later in this report. Results were obtained using BS and SS firmware version 1.8, which implements a traffic scheduling algorithm called “Proportional Rate Fair Scheduling.”7 This algorithm is an example of what one equipment provider implemented to meet its intended market segment. Alvarion provides the following description of their algorithm:

6 H. Safa, S. Khayat, “A Distributed Scheduling Algorithm for Mobile WiMAX Networks”, 2011 International Conference on Selected Topics in Mobile and Wireless Networking (iCost), Page(s): 94 – 99, 2011 7 BreezeMAX® Extreme Product Release 1.8 GA Release Note, Alvarion®, November 2011

18



Proportional Rate Fair Scheduling - Supporting the option of automatic down scaling of the service commissioned to CPEs (SSs) in case their modulation drops below the configured modulation threshold. The main reason for such requirements is in the case of loaded sectors (reaching full frame utilization) in which subscribers with lower modulations affect the entire sector performance (since it takes a longer period of time for it to satisfy the Maximum Information Rate (MIR), consuming longer air time). The configurable parameters include:

• The threshold MCS – CPEs (SSs) connected at lower rate Modulation and Coding Scheme (MCS) than the threshold would have their services scaled (sector level parameter)

• Scaling factor – controlling the “slope” of the scaling (sector level parameter)

• Individual CPEs (SSs) can be excluded from the scaling – i.e. CPEs (SSs) subject to higher Service Level Agreement (SLA) can be excluded from the scaling mechanism such that regardless to their modulation they would be aimed to receive their full commissioned service

• Minimal PFS correction – Leveraging the mechanism of the Proportional Fairness Scheme (PFS), this feature automatically limits the services to CPEs (SSs) with the lowest modulation (QPSK ½ MIMO A) to 4Mbps and thus improves and tunes their service and packet flow to their air link conditions.

19



Figure 6. Example Traffic Scheduling and Priority

As discussed earlier, AeroMACS equipment suppliers have the freedom to develop and implement the scheduling algorithms that will best serve their intended markets but within the constraints of meeting the QoS requirements defined in the IEEE 802.16 standard. The AeroMACS profile supports the requirement to meet QoS operation while not defining the exact scheduling algorithm. However, the aviation community may wish to constrain the scheduling algorithm choice at a later time in order to force more consistent and predictable performance among multiple avionics and ground equipment providers. The community may also wish to map expected ATC and AOC services to the available QoS classes in order to standardize priority assignments.

4.5. Assessment of Methods for Segregation of Different Services in CLE Test Bed.

The ability for AeroMACS to segregate and prioritize traffic was evaluated using the Cleveland prototype network in a series of tests. The tests evaluated the following capability areas:

1) Service Prioritization - control scheduling and network priority for traffic from multiple services

20



2) Segment Differentiation - segregate and maintain traffic segregation from multiple operational segments like ATC and AOC operations

3) Mixed Traffic Types – simultaneous handling of multiple traffic types (continuous, burst, time-critical) using the UDP and TCP protocols

4) Preemption of Services – use of QoS and network priority settings to assure that low priority traffic (Best Effort) will be sacrificed to assure on-time delivery of higher-priority traffic in congested network conditions

5) Network entry in congested conditions – use of QoS settings to assure that mobile stations that are carrying high-priority traffic can enter the AeroMACS network and establish a service flow

The AeroMACS prototype network built at the NASA Glenn campus and the Cleveland Hopkins airport (CLE) is a full data network containing two base stations and eight fixed-site subscriber stations. Central servers for CSN functions contain a secure network router, Network Management System (NMS) and Authentication, Authorization, and Accounting (AAA) functions8.

Traffic segregation tests used a base station and two subscriber stations as illustrated in Figure 7. The AeroMACS network was configured to operate with three VLANS to evaluate a method for traffic isolation. Each VLAN was assigned a segment of traffic to represent ATC, AOC, and Control traffic as follows:

• ATC traffic assigned to VLAN 90

• AOC traffic assigned to VLAN 80

• Logistics control traffic assigned to VLAN 54

The AeroMACS test network configuration and VLAN assignments are illustrated in Figure 7. Three Single Board Computers (SBC’s) are used to generate test traffic. A SBC located at Building 110 (B110) receives traffic that represents logistics control. A network switch at the B110 SS is set up for port tagging the traffic for VLAN 54.

Two SBCs at the Consolidated Maintenance Facility building (CMF) receive test traffic representing ATC and AOC traffic carried over VLANS 90 (ATC) and 80 (AOC). Traffic in the three VLANS pass through Aircraft and Firefighter’s building (ARFF) BS sector 2-3.

Network switches at the SSs and in B110 are configured for port tagging to establish traffic routing in the three VLANS. With this configuration, two VLANS (90 and 80) are carried simultaneously over the CMF-to-BS air link, and the ARFF BS sector 2-1 carries traffic from three VLANS simultaneously.

The AeroMACS prototype network is set to operate as Layer 2 (Ethernet IP) for these tests because VLANS are Layer 2 constructs. Operating as Layer 2 implements the Ethernet Convergence Sublayer (eth.cs) in the AeroMACS radio Media Access Control (MAC) layer. At this time, eth.cs MAC capability is optional in the RTCA

8 Hall, Edward, Magner, James: C-Band Airport Surface Communications System Standards Development. Phase II Final Report. Volume 2: Test Bed Performance Evaluation and Final AeroMACS Recommendations, NASA/CR-2011-216997/VOL2, 2011 http://ntrs.nasa.gov/

21

http://ntrs.nasa.gov/



and EuroCAE draft AeroMACS profile although it is required for implementation of VLANS for data segregation for joint ATC and AOC networks.

B110 SS

CMF SS

•Represents Aircraft

•Represents Port Authority

SBC for Logistics Traffic test end point

SBC for ATC traffic testendpoint

BTS 2-3(ARFF)

VLAN 54(Logistics)

VLAN 90(ATC)

SBC for AOC traffic test endpoint

VLAN 80(AOC)

iPerf Client for Logistics Data Flow

iPerf Client for ATC data flow

iPerf Client for AOC data flow

VLAN 90(ATC)

VLAN 80(AOC)

VLAN 54(Logistics) • 3 VLANS

• 3 QoS• 2 Traffic types

AeroMACS Air Links

Backhaul

SecureRouter

Sw

itch

Sw

itchS

witch

Figure 7. CLE Test Configuration

In addition to the establishment of VLANS, three service flows were established within the AeroMACS service to establish QoS and priority settings for the simulated traffic from ATC, AOC, and Logistics services. These settings are summarized in Table 3.

Table 3. AeroMACS QoS Properties

Traffic Service

VLAN Channel

Assigned QoS

Assigned Network Bandwidth

ATC 90 nrtPS 6-54 Mbps

AOC 80 nrtPS 1.5-7 Mbps

Logistics 54 BE 0-1 Mbps

22



The eleven network tests listed in Table 4 were performed to evaluate the five listed traffic segregation and priority criteria. A purpose and description is provided in the table for each test.

Table 4. CLE Test Descriptions

Purpose Description

Segment Differentiation Tests VLAN privacy by placing traffic simulating ATC, AOC, and Control traffic on VLANS 90, 80, and 54 individually

Mixed Traffic Types Mixed UDP and ATC protocol traffic types in high-priority ATC and AOC VLANS (90 and 80)

Mixed Traffic Types Mixed UDP and ATC protocol traffic types in high- and low-priority ATC and Control VLANS (90 and 54)

Service Prioritization Mixed Traffic Types

Traffic prioritization in congested network conditions with mixed UDP and TCP traffic

Service Prioritization Mixed Traffic Types

Test #4 with high-priority VLANS 90 and 80 differentiated with nrtPSbandwidth definitions

Preemption of Services Mixed Traffic Types

Congested network tests with high- and low-priority ATC and Control VLANS (90 and 54)

Preemption of ServicesMixed Traffic Types

Reference tests for traffic in single VLAN


Traffic prioritization in congested network conditions with mixed UDP and TCP traffic using all three VLANS


Congested network tests with ATC, AOC and Control VLANS (90, 80 and 54) with mixed traffic types

Segment Differentiation Tests VLAN privacy by placing traffic simulating ATC, AOC, and Control traffic on VLANS 90, 80, and 54 simultaneously

Network entry in congested conditions

SS network entry times under congested network conditions

The above tests were conducted in the five capability areas with the CLE prototype AeroMACS network configured according to Figure 7. Highlights of test results for each capability area are discussed below.

Service Prioritization – Capability Area #1 Description: Based on Test 10A, described in Table 5. Three traffic streams were established simultaneously in three VLANS for the purpose of testing correct service prioritization operation. The aggregate traffic rate of 7 Mbps is below the channel capacity of the service BS sector 2-3. Table 5 lists resulting link performance showing that high-quality links are supported for all three levels of service prioritization, indicated by low levels of percent dropped packets, out of order packets, and jitter. The delivered payloads are commensurate with the expected average traffic rate for the test time period. As expected, higher jitter statistics occurred for low-priority traffic BE traffic on VLAN 54. Overall, the results show proper operation for a BS sector channel operating below capacity with three concurrent levels of traffic priority and three established VLANs.

23



Table 5. CLE Service Prioritization Tests

VLAN # 54 80 90 54 80 90Service Ctl AOC ATC

QoS BE nrtPS nrtPSTest # Trial(s) BW (Mbps) 0-1 1.5-7.0 6.0-54.010A 11 Protocol (UDP/TCP) UDP UDP UDP No. Iterations 1 1 1

Set Rate (Mbps) 0.50 2.00 3.50 Rate Avg.(Mbps) 0.50 2.00 3.50 Set Period (S) 180 180 300 Period Avg.(S) 180 180 300

Out of Order Pkts. 0 4 6Pkts. Sent 7655 30611 89287

Dropped Pkts. 0 8 30% Dropped 0.00% 0.03% 0.03%Jitter (mS) 2.753 1.624 1.911

Payload (Mbytes) 10.700 42.900 125.000

Test Conditions Test Results

Segment Differentiation – Capability Area #2 Description: Based on Test #10B, described in Table 6 . Three traffic streams were established simultaneously in three VLANS for the purpose of testing traffic segregation. The test was designed to show that traffic stream content is visible only within their assigned VLAN. Properties of the test traffic streams are described below and in Table 6

• Test traffic stream #1 sent through VLAN 90 to represent ATC traffic using UDP protocol at 4.5 Mbps and QoS of non-real-time poling service (nrtPS).

• Test stream #2 sent through VLAN 54 to represent Logistics Control traffic using UDP protocol at 0.5 Mbps and Best Effort (BE) QoS.

• Test stream #3 sent through VLAN 80 to represent AOC traffic using UDP protocol at 2 Mbps and nrtPS QoS

24



Table 6. CLE Segment Differentiation Tests

VLAN # 54 80 90 54 80 90Service Ctl AOC ATC

QoS BE nrtPS nrtPSTest # Trial(s) BW (Mbps) 0-1 1.5-7.0 6.0-54.0

10B 9 Protocol (UDP/TCP) UDP UDP UDP No. Iterations 1 1 1 Set Rate (Mbps) 0.50 2.00 4.50 Rate Avg.(Mbps) 0.50 2.00 4.50

Set Period (S) 180 180 300 Period Avg.(S) 180 180 300Out of Order Pkts. 0 10 4

Pkts. Sent 7654 30613 114791Dropped Pkts. 0 22 95

% Dropped 0.00% 0.07% 0.08%Jitter (mS) 5.748 3.468 2.130

Payload (Mbytes) 10.700 42.900 161.000


Execution: Traffic flow through the three VLANs identified in Figure 7 was verified. ATC traffic was started first and set to run for 5 minutes. The AOC and Logistics traffic streams were started at the one-minute mark after the ATC data started. Both were set to run for 3 minutes. The performance data was recorded.

The next step that verified traffic segregation within a VLAN was completed by establishing traffic through one VLAN route at a time to verify that this traffic could not be observed outside of the established VLAN connection. The three Iperf client traffic sources to the right of the secure router in Building 110, shown in Figure 8, were activated one at a time. For each activated VLAN, a laptop computer located in the CMF Building was sequentially connected to all active switch ports to test for connectivity with the three Iperf Clients in B110.

25



B110 SS

CMF SS

•Represents Aircraft

•Represents Port Authority

SBC for Logistics Traffic test end point

BTS 2-3(ARFF)

VLAN 54(Logistics)

VLAN 90(ATC)

VLAN 80(AOC)

iPerf Client for Logistics Data Flow

iPerf Client for ATC data flow

iPerf Client for AOC data flow

VLAN 90(ATC)

VLAN 80(AOC)

VLAN 54(Logistics) • 3 VLANS

• 3 QoS• 2 Traffic types

AeroMACS Air Links

Backhaul

SecureRouter

Sw

itch

Sw

itchS

witch

Building 110

VLAN 54(Logistics)

CMF Building Figure 8. VLAN Data Segregation Test

Results: The original test with three VLANS activated with traffic operated as expected with traffic delivered to the remote end points through AeroMACS. Correct VLAN operation was verified when each VLAN was activated individually with traffic and all switch ports in the CMF building were probed. The remote laptop PC was able to establish a connection and a traffic flow when switch ports of the same VLAN were probed, and no connection or traffic flow occurred when mismatched VLAN channels were probed.

Mixed Traffic Types – Capability Area #3

Description: Based on Test #8. Three traffic streams are established to flow simultaneously with one stream per VLAN. The established flows are a mixture of QoS and IP protocol. Test results show that AeroMACS channel capacity and quality of link is maintained when carrying mixed traffic types.

Test #8 uses the following three traffic flows:

• Test traffic stream #1 sent through VLAN 90 to represent ATC traffic using UDP protocol at 6 Mbps and QoS of non-real-time poling service (nrtPS).

• Test stream #2 sent through VLAN 54 to represent Logistics Control traffic using TCP protocol and Best Effort (BE) QoS.

• Test stream #3 sent through VLAN 80 to represent AOC traffic using TCP protocol and nrtPS QoS

AOC and Logistics Control traffic are assigned to use TCP protocol. TCP is a guaranteed-delivery protocol so it will transfer at the fastest rate that it can achieve within the limits set by the services granted. The ATC traffic is assigned the nrtPS QoS that provides higher-priority scheduling than the BE Logistics Control traffic.

ATC and AOC traffic are both assigned nrtPS QoS. However, the traffic is differentiated by the committed bandwidth setting; ATC with 6.0 to 54 Mbps and AOC with 1.5 to 7.0 Mbps bandwidth. Traffic is also differentiated through use of UDP protocol for ATC and TCP protocol for AOC traffic.

26



Channel capacity for traffic rate will not be exceeded because the ATC traffic with UDP protocol is assigned a rate below the expected 8 Mbps channel capacity and the two additional traffic flows are assigned TCP protocol.

Table 7. CLE Mixed Traffic Type Tests

VLAN # 54 80 90 54 80 90 Tota

l Ban

dwid

t

Service Ctl AOC ATCQoS BE nrtPS nrtPS

Test # Trial BW (Mbps) 0-1 1.5-7.0 6.0-54.08 1,2,3,4,5 Protocol (UDP/TCP) TCP TCP UDP No. Iterations 5 5 5

Set Rate (Mbps) n/a n/a 6.00 Rate Avg.(Mbps) 0.060 2.07 6 8.13 Set Period (S) 180 180 300 Period Avg.(S) 180.36 180.28 300.00

Out of Order Pkts. n/a n/a 2Pkts. Sent n/a n/a 153058.60

Dropped Pkts. n/a n/a 67.40% Dropped n/a n/a 0.04%Jitter (mS) n/a n/a 1.86

Payload (Mbytes) 1.32 44.56 214.60


Execution: The ATC test traffic is launched first and is set to run for 5 minutes (300 seconds). AOC traffic is launched at the 1 minute mark, closely followed within approximately 2 seconds by start of the Logistics Control traffic, with both set to run for 3 minutes (180 seconds).

Results: High-priority ATC traffic is reliably delivered across AeroMACS while the lower-priority traffic is adjusted according to the total channel capacity of 8.13 Mbps. ATC traffic is reliably delivered using UDP protocol in the presence of two simultaneous TCP streams.

Preemption of Services – Capability Area #4 Description: Based on Test #6, Table 8. Test traffic stream #1 is sent through VLAN 90 to represent ATC traffic using UDP protocol initially at 6 Mbps rate and non-real-time poling service (nrtPS) QoS. Test stream #2 is sent through VLAN 54, representing Logistics Control traffic, using TCP protocol initially at 1 Mbps and Best Effort (BE) QoS.

Simultaneous use of UDP and TCP protocols tests the behavior of mixed data types. Test trials with increasing traffic rates on the VLANS explore the effects of QoS on preemption of services. It is expected that higher-priority ATC traffic, set to nrtPS QoS, will be delivered with priority over Logistics traffic that is assigned BE QoS.

Execution: ATC traffic is set to run for 5 minutes (300 seconds) and begins first. The Logistics traffic is set to run for 3 minutes (180 seconds) and starts 1 minute after ATC traffic starts. Therefore, ATC traffic has no competition for network resources for the first minute. ATC data continues for the final minute after Logistics traffic finishes. This test sequence is performed at three traffic rates to test prioritization.

Results: Table 8 summarizes the Preemption of Services test conditions and results. Tests are listed in three groups as 6A, 6B, and 6C. Test 6A used an aggregate traffic rate below the AeroMACS link capacity, while 6B and

27



6C used progressively higher rates in congested network conditions where the test traffic rate exceeds the AeroMACS link capacity.

Table 8. Preemption of Services Test Summary

VLAN # 54 80 90 54 80 90 Tota

l Ban

dwid

th

Service Ctl AOC ATCQoS BE nrtPS nrtPS

Test # BW (Mbps) 0-1 1.5-7.0 6.0-54.06A Protocol (UDP/TCP) TCP TCP UDP No. Iterations 5 0 5 Set Rate (Mbps) n/a n/a 6.00 Rate Avg.(Mbps) 0.96 n/a 6.00 6.96

Set Period (S) 180 300 Period Avg.(S) 180.86 n/a 300.00Out of Order Pkts. 0 n/a 0

Pkts. Sent n/a n/a 153062Dropped Pkts. n/a n/a 105

% Dropped n/a n/a 0.07%Jitter (mS) n/a n/a 2.7

Payload (Mbytes) 20.6 n/a 214.000

6B Protocol (UDP/TCP) TCP TCP UDP No. Iterations 5 0 5Set Rate (Mbps) n/a n/a 8.00 Rate Avg.(Mbps) 0.14 n/a 7.99 8.13 Set Period (S) 180 300 Period Avg.(S) 184.48 n/a 300.00

Out of Order Pkts. n/a n/a 2Pkts. Sent n/a n/a 204080



6C Protocol (UDP/TCP) TCP TCP UDP No. Iterations 5 0 5Set Rate (Mbps) n/a n/a 10.00 Rate Avg.(Mbps) 0.010 n/a 8.14 8.15 Set Period (S) 180 300 Period Avg.(S) 202.5 n/a 300.00

Out of Order Pkts. 0 n/a 0Pkts. Sent n/a n/a 255085.80




28



Test 6A results: ATC data transferred at an average rate of 6.0 Mbps, matching the set rate for the test. The total data transfer was 214 Mbytes with a packet loss rate of .07%, which is under the 1% threshold considered to be the limit for a well-performing UDP channel. Logistics data transferred at an average of .96 Mbps (maximum rate was set for 1 Mbps). The total Logistics data transferred was 20.6 Mbytes. These rates and total transfers are consistent with a channel that is operating below its capacity.

Test 6B results: Tests are repeated with ATC traffic rate increased to 8 Mbps while the Logistics traffic rate remained 1 Mbps. ATC traffic at 8 Mbps is near channel capacity by itself. These test trials resulted in ATC traffic throughput rate increasing to 7.99 Mbps and a total payload transfer of 286 Mbytes. The packet loss rate increased slightly to 0.17%, which is still an acceptable rate for a UDP link. However, the Logistics traffic with BE QoS was not able to sustain the 1 Mbps rate; averaging 0.14 Mbps instead. The total payload transfer over the length of the test was limited to 3 Mbytes. These results clearly show that high-priority ATC traffic was transferred without impact, while lower-priority Logistics data rate was sacrificed for the ATC traffic.

Test 6C results: Tests are repeated with ATC traffic rate having an additional increase to 10 Mbps which exceeds the expected AeroMACS channel capacity. The Logistics traffic rate remained 1 Mbps. These test trials resulted in ATC traffic throughput rate increasing to 8.14 Mbps and a total payload transfer of 291 Mbytes. The achieved rate of 8.14 Mbps indicates that the intended traffic rate of 10 Mbps exceeds channel capacity and resulted in a 18.5% packet loss rate. In addition, the BE Logistics traffic reduced to 0.010 Mbps average rate and total payload transfer was reduced to 0.33 Mbytes. These results show that traffic continued to be transferred when high-priority ATC traffic exceeded channel capacity, and that ATC traffic was again given priority over Logistics BE traffic which was severely restricted.

Figure 9 illustrates graphically the throughput rate of a high-priority ATC traffic stream as lower-priority AOC and Logistics Control traffic is added, which overloads the channel. ATC traffic is established in VLAN 90 at 6 Mbps, AOC traffic is added to VLAN 80 at 2 Mbps, and Logistics Control traffic is added to VLAN 54 at 1 Mbps one-minute into the test through the BTS 2-3 channel. The aggregate traffic exceeds the 8.1 Mbps capacity of BTS 2-3. The ATC traffic is shown to maintain the original 6 Mbps throughput rate as the overloaded condition develops one-minute into the test in time slot #3 and is maintained as the overload condition ends 3-minutes later after time slot #12.

29



0.0

1.0

2.0

3.0

4.0

5.0

6.0

7.0

1 2 3 4 5 6 7 8 9 10 11 12 13 14

Aver

age

Tim

e Sl

ot T

hrou

igho

ut R

ate,

Mbp

s

Time Slot #

VLAN 90

VLAN 80

VLAN 54

Figure 9. VLAN Throughput Rate Measurement

Network entry in congested conditions – Capability Area #5

Description: Based on Test #5. Traffic from three SSs is established through BTS sector 2-3. These streams are set to overload the channel to create congested network conditions. Traffic was added from a fourth SS. The fourth SS was forced to disconnect from the network and re-enter by the normal scan process. This test demonstrated that the fourth SS is able to re-enter the network under congested conditions.

The test used the following four traffic flows that exceeded sector capacity:

• Test traffic stream #1 sent through VLAN 90 to represent ATC traffic using UDP protocol at 6 Mbps and QoS of non-real-time poling service (nrtPS).

• Test stream #2 sent through VLAN 54 to represent Logistics Control traffic using UDP protocol at 0.5 Mbps and Best Effort (BE) QoS.

• Test stream #3 sent through VLAN 80 to represent AOC traffic using UDP protocol at 5 Mbps and nrtPS QoS.

• Test stream #4 sent though VLAN 54 to represent a SS forced to re-join the network in congested conditions. This SS was granted BE service QoS.

30



The location of the 4th SS guaranteed that it could only join the intended sector of BTS2-3, allowing a full scan of the 5095 to 5150 MHz range. Two sets of trials were conducted, first with only the BTS 2-3 sector frequency in the SS scan table, followed by trails having the scan table populated for a full 5095 to 5145 MHz scan in 5 MHz steps.

Execution: Test traffic flows from three SSs (ATC, AOC, and Logistics traffic) were established and flowed continuously through BTS2-3. The 4th SS was connected with normal management traffic and was later forced to disconnect from and re-enter the network using Network Management Software (NMS). Network re-entry involved a frequency scan according to the SS scan table to re-locate BTS2-3. The normal authentication and authorization negotiations between the SS and BS/ASN-GW/AAA occurred. AAA log entries documented times that disconnect and re-connect occurred. Three trials of 12 tests each were completed to assess the average time that required for the SS to re-enter the network.

Results:

The following average re-entry times were measured with a single scan table entry:

• First set having 12 trials – average re-entry time was 22.22 seconds. The results include attempts to join that were not successful and the SS continued the scan process until successful re-entry occurred.

• Second set having 12 trials – average re-entry time was 14.92 seconds. All SS attempts to re-enter were successful on the first attempt.

• Third set having 13 trials – Conducted with no added network traffic (except for control traffic). The average time for re-entry was 15.15 seconds.

The following average re-entry times were measured with eleven scan table entries for scanning from 5095 to 5145 MHz:

• Congested network: 3 trials – average re-entry time was 107 seconds.

• Control traffic only (non-congested network) – average re-entry time was 105.3 seconds.

These tests showed that an SS with no prior knowledge of BS center frequencies could do a full scan table scan and join the network in under 2 minutes. Time to join was similar whether the network was operating at capacity or when lightly loaded.

It was noted by observing the test that the SS scan table would be scanned once, followed by erasure of scan measurements, and then scanned a second time with measurements recorded. This behavior added to the time needed to join the network but may serve a useful purpose in the scan process.

31



5. CONCLUSION The ability for AeroMACS to segregate and prioritize traffic was evaluated using the Cleveland prototype network in a series of tests. The tests evaluated the following capability areas:

1) Service Prioritization - control scheduling and network priority for traffic from multiple services. The results show proper operation for a BS sector channel operating below capacity with three concurrent levels of traffic priority and three established VLANs.

2) Segment Differentiation - segregate and maintain traffic segregation from multiple operational segments like ATC and AOC operations. The test showed that traffic stream content is visible only within their assigned VLAN.

3) Mixed Traffic Types – simultaneous handling of multiple traffic types (continuous, burst, time-critical) using the UDP and TCP protocols. Test results show that AeroMACS channel capacity and quality of link is maintained when carrying mixed traffic types. High-priority ATC traffic was reliably delivered across AeroMACS while the lower-priority traffic was adjusted according to the total channel capacity of 8.13 Mbps. ATC traffic was reliably delivered using UDP protocol in the presence of two simultaneous TCP streams.

4) Preemption of Services – use of QoS and network priority settings to assure that low priority traffic (Best Effort) will be sacrificed to assure on-time delivery of higher-priority traffic in congested network conditions. Test results clearly show that high-priority ATC traffic was transferred, while lower-priority Logistics data rate was sacrificed for the ATC traffic.

5) Network entry in congested conditions – use of QoS settings to assure that mobile stations that are carrying high-priority traffic can enter the AeroMACS network and establish a service flow. The tests showed that an SS with no prior knowledge of BS center frequencies could do a full scan table scan and join the network in under 2 minutes. Time to join was similar whether the network was operating at capacity or when lightly loaded.

Overall, supported by policy and operational decisions, the tests validated that AeroMACS technology offers methods for data segregation and prioritization enabling the co-existence of AOC/ATC traffic on the same network. Additionally, the tests validated our understanding of system behavior given the settings selected for the AeroMACS Profile.

32



6. FOLLOW ON WORK Results of the analysis presented in this report were translated into inputs to MOPS and SARPs documents being developed by the RTCA SC-223 and ICAO ACP WG-S respectively. Additionally, the results of the analyses could be used to support development of the Guidance Material/Technical Manual.

AeroMACS development should continue well beyond 2012. Europe is expected to conduct AeroMACS SARPs validation activities and lead the development of the Technical Manual/Guidance Material. The U.S. will closely monitor and actively participate in standardization activities.

It should be noted that follow on work is expected to include extensive validation activities. While preliminary evaluation of SARPs requirements was performed during its development, a more detailed evaluation of achievability of some of the requirements needs to be conducted.

Contingent on Year 3 funding, Exelis will continue providing support to the FAA AeroMACS related work under the TO 0008.

33



APPENDIX A: ACRONYMS AND ABBREVIATIONS This appendix identifies acronyms and abbreviations used throughout this document.

AAA Authentication, Authorization, and Accounting

ADS Aeronautical Dependent Surveillance

ADS-B Aeronautical Dependent Surveillance - Broadcast

ADS-C Aeronautical Dependent Surveillance - Contract

A/G Air to Ground

AeroMACS Aeronautical Mobile Aircraft Communications System

AIB Airport Information Bulletin

AM(R)S Aeronautical Mobile (Route) Service

AP–17, -30 Action Plan 17, 30

AOC Airline Operational Control

ARFF Aircraft and Firefighter’s

ASN Access Service Network

ASN-GW Access Service Network - Gateway

ATC Air Traffic Control

ATIS Automatic Terminal Information Service

ATM Air Traffic Management

ATN Aeronautical Telecommunications Network

BE Best Effort

BS Base Station

BTS Base Transceiver Station

CM Communications Management

ConOps Concepts of Operation

CPDLC Controller Pilot Data Link Communications

CPE Customer Premises Equipment

CSN Connectivity Service Network

D-FIS Data Link Flight Information Services

DFPQ Deficit Fair Priority Queue

34



EFB Electronic Flight Bag

ertPS enhanced real-time Poling Service

eth.cs ethernet Convergence Sublayer

EUROCAE European Organisation for Civil Aviation Equipment

EUROCONTROL European Organisation for the Safety of Air Navigation

FAA Federal Aviation Administration

FCI Future Communications Infrastructure

FCS Future Communications Study

FY Fiscal Year

GS Ground Stations

HZWX Hazardous Weather

ICAO International Civil Aviation Organization

IEEE Institute of Electrical & Electronics Engineers, Inc.

IP Internet Protocol

IPS Internet Protocol Suite

LDACS L-band Digital Aviation Communications System

LTE Long Term Evolution

MAC Media Access Control

METAR Aviation Routine Weather Report Service

MIMO Multiple Input, Multiple Output

MOPS Minimum Operational Performance Standards

NAP Network Access Provider

NASA National Aeronautics and Space Administration

NMS Network Management System

NOTAM Notice to Airmen

nrtPS non-real time Poling Service

NSP Network Service Provider

OOOI Out-Off-On-In

OTIS Operational Terminal Information Service

35



PDU Protocol Data Unit

PFS Proportional Fairness Scheme

PLA Project-Level Agreement

PoP Period of Performance

QoS Quality of Service

rtPS real-time Poling Service

RR Round Robin

RVR Runway Visual Range

SARPs Standards and Recommended Practices

SBC Single Board Computer

SDU Service Data Unit

SESAR Single European Sky ATM Research

SIGMET Significant Meteorological Information

SLA Service Level Agreement

SS Subscriber Station

SWIM System Wide Information Management

TAF Terminal Aerodrome Forecast

TCP Transmission Control Protocol

TIS Traffic Information System

TO Task Order

TORP Task Order Request for Proposal

U.S. United States

UDP User Datagram Protocol

UGS Unsolicited Grant Service

VHF Very High Frequency

VLAN Virtual Local Area Network

VoIP Voice over Internet Protocol

VOLMET Meteorological information for aircraft in flight (ICAO definition)

VTC Video Teleconferencing

36



WG Working Group

WRC World Radiocommunications Conference

WRR Weighted Round Robin

37



APPENDIX B: TEST EQUIPMENT

Table 9 lists the AeroMACS Test Bed equipment used to execute the task. The table includes government furnished well as ITT owned equipment.

Table 9 Test Bed AeroMACS Network Equipment9

Location Item# (Master)

Description Manufacture Model Serial Number/Version

Aircraft Service Hanger

325-1 Weatherproof Enclosure

HyperLink Technologies

NB141207-1HF 9975779000

325-1-1 Single Board Computer

Octagon 2050-PC-104 MAC: 00:20:0b:01:5a:c0

325-1-1-1

Compact Flash Memory 2GB Industrial CF

Transcend HV4719 None

325-1-1-1a

Software Open Source Linux Slackware V10

325-1-1-1b

Software –Endpoint Client for

IxChariotTM for x86 32 bit

Ixia V1.0 n/a

325-1-3 5 Port Industrial Ethernet Managed

data switch

Sixnet SLX-5MS

325-1-11 Power Supply for Alvarion®

AeroMACS ODU

PS1065 A30912119795

325-2 AeroMACS ODU Alvarion® Extreme 5000 7861398

325-2-1 Software Alvarion® n/a 1.5.1.16

C Terminal 451-1 Weather proof Enclosure


NB141207-1HF 9975784000


Octagon 2050-PC-104 MAC: 00:20:0b:01:5a:ca

9 Acronyms are defined in Appendix A.

38





451-1-1-1



451-1-1-1a


451-1-1-1b



Ixia n/a V1.0

451-13 5 Port Industrial Ethernet Managed

data switch

Sixnet SLX-5MS-1 MAC: 00:24:98:1a:f4:5e

451-1-11 Power Supply for AeroMACS ODU

Alvarion® PS1065 A30912119780



Glycol Tanks

401-1 Weather proof Enclosure


NB141207-1HF 9975782000



401-1-1-1



401-1-1-1a

Software – Open Source Linux Slackware V10

401-1-1-1b

Software –Endpoint Client for IxChariot

for x86 32 bit

Ixia V1.0 n/a


data switch

Sixnet SLX-5MS-1 MAC: 00:24:98:1a:f3:b6

401-1-11 Power Supply for AeroMacs ODU

Alvarion® PS1065 A30912119778

401-2 AeroMacs ODU Alvarion® Extreme 5000 7861394

401-2-1 Software Alvarion® n/a V1.5.1.16

39





Snow Barn 375-1 Weather proof Enclosure


NB141207-1HF 9975776000


Octagon 2050-PC-104 MAC: 00:20:0b:01:5a:d4

375-1-1-1



375-1-1-1a


375-1-1-1b


IxChariotTM Ixia for x86 32 bit

n/a V1.0


data switch



Alvarion® PS1065 A30912119759



Aircraft Lighting Service Facility



NB141207-1HF 9975777000



426-1-1-1



426-1-1-1a


426-1-1-1b



Ixia n/a V1.0


Sixnet SLX-5MS-1 MAC: 00:24:98:1a:f3:e6

40





data switch

426-1-11 Power Supply for AeroMacs ODU

Alvarion® PS1065 A30912119775

426-2 AeroMacs Outdoor Unit (ODU)

Alvarion® Extreme 5000 7861405


Consolidated Maintenance

Facility



NB141207-1HF 9975018000



350-1-1-1



350-1-1-1a


350-1-1-1b



Ixia n/a V1.0


data switch

Sixnet SLX-5MS-1 MAC: 00:24:98:1a:ef:9e


AeroMACS ODU

PS1065 A30912119763



NASA Building 4

(roof)



NB141207-1HF 9975775000



203-1-1-1



41





203-1-1-1a


203-1-1-1b



Ixia n/a V1.0


data switch

Sixnet SLX-5MS-1 MAC: 00:24:98:1a:e9:7e


Alvarion® PS1065 No tag



NASA Building 500



NB141207-1HF 9975017000


Octagon 2050-PC-104 MAC: 00:20:0b:01:5a:da

301-1-1-1



301-1-1-1a


301-1-1-1b



Ixia n/a V1.0


data switch



Alvarion PS1065 n/a



42





Aircraft Rescue Fire

Fighting 101-1

Cabinet ITT n/a 9985487000

101-1 Lambda PS Rack Lambda THR4 082887100937

101-1-1 Lambda PS Module Lambda TH200048 Not available

101-5 Backhaul IDU Trango Giga Plus 9980030000

101-9 PS for BTS ODU (-Alvarion® 55v,1.27A)

0525B5570 No Tag

101-10 PS for BTS ODU (-55v,1.27A)

Alvarion® 0525B5570 No Tag

101-11 PS for BTS ODU (-55v,1.27A)

Alvarion® 0525B5570 No Tag

101-14 SBC Enclosure ITT n/a No tag



101-14-1-1



101-14-1-1a

Software

Open Source Linux Slackware V10.0

101-14-1-1b



Ixia n/a V1.0

101-18 Data Switch Avaya/Nortel Baystack 470-48T Not Obtained

102-1 Backhaul Cable Beldon LMR400 No tag

102-2 Backhaul ODU Trango Giga Plus Not Obtained

102-3 AeroMacs BTS2-1 Alvarion® 9985527000 00:10:e7:e2:57:1a

102-4 AeroMacsBTS2-2 Alvarion® 9985525000 00:10:e7:e2:57:1c

102-5 AeroMacsBTS2-3 Alvarion® 9985526000 00:10:e7:e2:56:91

102-6 2’ Dish Antenna for Backhaul

RadioWaves HP-11G 24332

102-10 Ballast Roof Mount Tessco 48544 9981055000

43





102-11 POE Surge Suppressors

Transtector ALPV-ALVR No tag





102-14 GPS receiver Trimble High Gain Not Obtained



NASA Building 110

(inside)

1-1 Core Equipment Cabinet

ITT n/a 9981037000

1-1-5 Lambda PS Rack Lambda TH4 No tag

1-1-5-1 Lambda PS Module -48Vdc

Lambda TH120048 9985778000

1-1-5-2 Lambda PS Module -48Vdc

Lambda TH120048 9985778000

1-1-8 Avaya Router Avaya ERS5600 Not Obtained

1-1-9 Server hardware Microsoft Not Obtained Not Obtained

1-1-9-1 Software – Alepo AAA

Alepo 16e AAA Server w/IPAM

License # 42000926

1-1-9-2a Software – Alvaristar

Alvarion® Infrastructure (NMS Core)

V4.5.0.47.Patch

1-1-9-2b Software – Alvaristar

Alvarion® BreezeMAX® Extreme Device Driver (1.5

V1.5.0.31.Beta

1-1-10 Server hardware Not Obtained Not Obtained Not Obtained

1-1-10-1 NM Software Alvaricraft 4.8 Alvaricraft

1-1-12 Backhaul #2 IDU Giga Plus 8480484 Giga Plus

1-1-13 Backhaul #1 IDU Tlink-Giga-11 8280219 Tlink-Giga-11

1-1-14 Data switch Lynksys SD216 Not Obtained

1-1-15 LAP Top Computer Latitude 2005192000 Latitude

44





1-1-15-1 Software – IxChariotTM

Console

Chariot n/a 7.10 EA

1-1-22 SBC Enclosure ITT n/a No tag

1-1-22-1 Single Board Computer


1-1-22-1-1



1-1-22-1-1a

Software Open Source Linux Slackware V10.0

1-1-22-1-1b



Ixia n/a V1.0

1-1-26 Spare AeroMACS ODU

Alvarion® XTRM-SU-0D-1D-4.9-UL-A 950307 Radio Remote SN

7861407

Tagged as NASA property

NASA Building 110

(on roof)

2-1 2’ Dish Antenna for Backhaul BH1

Trango AD11G-2-S1 n/a

2-2 2’ Dish Antenna for Backhaul BH2

RadioWaves A-2-11-A n/a

2-3 Backhaul ODU Trango Trango Giga Plus R06113728

2-4 Backhaul ODU Trango Tlink-Giga-11 9975259000

2-5 RF Cable from BH1 IDU to BH1

ODU

Alvarion® Supplied

LMR400 n/a

2-6 RF Cable from BH2 IDU to BH2

ODU

Alvarion® Supplied

LMR400 n/a

2-7 Backhaul Mono Pole Assembly

Tessco 9981055000

ARV1 601-1 Weather proof Enclosure


NB141207-1HF 997578000

45






Octagon 2050-PC-104 MAC: 00:20:0b:01:5a:xx

601-1-1-1



601-1-1-1a

Software - OS

Open Source Linux Slackware V10.0

601-1-1-1b


IxChariotTM Ixia

X86 n/a

for x86 32 bit


PS1065 1234565000

AeroMACS SS ODU

601-2 AeroMacs ODU Alvarion® Extreme 5000 9998010000


601-6 Antenna A Huber-Suhner SWA2459/360/20/V_2 Marked #1

601-7 Antenna B Huber-Suhner SWA2459/360/20/V_2 Marked #2

601-8 YellowFin™ Mobile WiMAX

Berkeley Varitronics

YellowFinTM PN0093-T-WY

SN300909

46

New ATM Requirements Future Communications, – C-Band …...New ATM Requirements - Future...

Documents

Transcript of New ATM Requirements Future Communications, – C-Band …...New ATM Requirements - Future...