EUROCAE DOCUMENT (ED) (MINIMUM AVIATION SYSTEM PERFORMANCE STANDARDS (MASPS) AeroMACS)

Transcription

1 The European Organisation for Civil Aviation Equipment L Organisation Européenne pour l Equipement de l Aviation Civile EUROCAE DOCUMENT (ED) (MINIMUM AVIATION SYSTEM PERFORMANCE STANDARDS (MASPS) AeroMACS) This document is the exclusive intellectual and commercial property of EUROCAE. It is presently commercialised by EUROCAE. This electronic copy is delivered to your company/organisation for internal use exclusively. In no case it may be re-sold, or hired, lent or exchanged outside your company. ED-xxx [Month Year] Supersedes ED-xxx 102 rue Etienne Dolet Tel: MALAKOFF, France Fax: Web Site: eurocae@eurocae.net

2 EUROCAE DOCUMENT (ED) (MINIMUM AVIATION SYSTEM PERFORMANCE STANDARDS (MASPS) AeroMACS) This document is the exclusive intellectual and commercial property of EUROCAE. It is presently commercialised by EUROCAE. This electronic copy is delivered to your company/organisation for internal use exclusively. In no case it may be re-sold, or hired, lent or exchanged outside your company. ED-xxx [Month Year] Supersedes ED-xxx

3 i FOREWORD 1. This document was prepared jointly by EUROCAE Working Group XX WG title <and RTCA SC-xx title / SAE xx title, and was approved by the Council of EUROCAE on [Day Month Year]. 2. EUROCAE is an international non-profit making organisation in Europe. Membership is open to manufacturers and users of equipment for aeronautics, trade associations, national civil aviation administrations, and, under certain conditions, non-european organisations. Its work programme is principally directed to the preparation of performance specifications and guidance documents for civil aviation equipment, for adoption and use at European and world-wide levels. 3. The findings of EUROCAE are resolved after discussion amongst Members of EUROCAE and in collaboration with RTCA Inc, Washington D.C., and/or the Society of Automotive Engineers (SAE), Warrendale PA, U.S.A., through their appropriate committees. 4. This document supersedes ED-xxx <title> (date). The document has been updated to <main rationale>. As compared with the previous version, the main changes are: <list any significant changes> <For extensive changes, consider the inclusion of a revision history table as an annex to the document.> 5. This document is technically identical to <RTCA DO-xx / SAE xxx> / <Coordination has been achieved with RTCA SC-xxx title / SAE xxx title.> <If applicable, any significant differences between the EUROCAE and RTCA documents should be listed in an annex to the document.> 6. EUROCAE performance specifications and other documents are recommendations only. EUROCAE is not an official body of the European Governments. Its recommendations are valid as statements of official policy only when adopted by a particular government or conference of governments. 7. Copies of this document may be obtained from: EUROCAE 102, rue Etienne Dolet MALAKOFF France Telephone: Fax: eurocae@eurocae.net Website:

4 ii TABLE OF CONTENTS EUROCAE DOCUMENT (ED) (MINIMUM AVIATION SYSTEM PERFORMANCE STANDARDS (MASPS) AEROMACS)... 1 EUROCAE DOCUMENT (ED) (MINIMUM AVIATION SYSTEM PERFORMANCE STANDARDS (MASPS) AEROMACS)... 2 FOREWORD I LIST OF FIGURES... V LIST OF TABLES... VII CHAPTER 1 INTRODUCTION PURPOSE AND SCOPE RELATIONSHIPS TO OTHER DOCUMENTS DESCRIPTION OF THIS DOCUMENT DOCUMENT CONVENTIONS DEFINITIONS REFERENCES CHAPTER 2 AEROMACS NETWORK ARCHITECTURE NETWORK REFERENCE MODEL OVERVIEW REFERENCE POINTS ASN REFERENCE MODEL ASN REFERENCE POINTS CSN REFERENCE MODEL AEROMACS ASN PROFILE FUNCTIONAL REQUIREMENTS ACCESS SERVICE NETWORK (ASN) REQUIREMENTS CORE SERVICE NETWORK (CSN) REQUIREMENTS SERVICE PROVISION REQUIREMENTS FUNCTIONAL ARCHITECTURE BUSINESS ENTITIES (NAP, V-NSP, H-NSP) NETWORK ENTITIES ADDRESSING CONCEPT NETWORK ENTRY AND NAP/NSP SELECTION AIRPORT NETWORK INFRASTRUCTURE BARAJAS AIRPORT NETWORK TOPOLOGY DEPLOYMENT MODELS NSP & NAP DEPLOYMENT MODELS ROAMING SCENARIOS AEROMACS AIRBORNE ARCHITECTURE FOREWORD ON OVERALL AIRCRAFT SYSTEMS ORGANISATION ASSUMPTIONS REGARDING THE INITIAL IMPLEMENTATION OF AIRBORNE AEROMACS SYSTEMS:... 51

5 iii SCENARIO 1-A NEAR TERM INITIAL INSTALLATION OF THE AEROMACS MS IN THE AISD DOMAINS : SCENARIO 2-A MEDIUM TERM INITIAL INSTALLATION OF THE AEROMACS MS IN THE ACD DOMAIN : SCENARIO 2-B MEDIUM TERM INSTALLATION OF THE AEROMACS MS IN BOTH THE ACD AND AISD DOMAINS SCENARIO 3-A LONGER TERM INSTALLATION OF THE AEROMACS MS IN THE ACD DOMAIN SCENARIO 3-B LONGER TERM INSTALLATION OF THE AEROMACS MS IN BOTH THE ACD AND AISD DOMAINS CHAPTER 3 APPLICATIONS OPERATIONAL CONCEPT SERVICE INSTANTIATION CHAPTER 4 AEROMACS OPERATIONAL REQUIREMENTS OPERATING ALTITUDE COVERAGE ATS, AOC AND AIRPORT AUTHORITY SUPPORT REGISTRATION PROCEDURE MOBILITY AND HANDOVER PERFORMANCE MONITORING SYSTEM SUPERVISION CHAPTER 5 AEROMACS TECHNICAL REQUIREMENTS MIN MAX AIRCRAFT, VEHICLE SPEED NETWORK MANAGEMENT SERVICES SUPPORT REGISTRATION PROCEDURE MOBILITY AND HANDOVER SYNCHRONIZATION AND TIMING REQUIREMENTS DATA LATENCY RESIDUAL ERROR RATE SYSTEM SUPERVISION CHAPTER 6 QUALITY OF SERVICE REQUIREMENTS AEROMACS SCHEDULING SERVICES EXTENDED REAL-TIME POLLING SERVICE REAL-TIME POLLING SERVICE NON-REAL TIME POLLING SERVICE BEST EFFORT SERVICE UNSOLICITED GRANT SERVICE CLASSES OF SERVICE CHAPTER 7 SAFETY AND PERFORMANCE REQUIREMENTS SAFETY AND PERFORMANCE REQUIREMENTS FOR THE AEROMACS GROUND INFRASTRUCTURE PERFORMANCE REQUIREMENTS SAFETY REQUIREMENTS APPLICABLE TO THE ACSP DOMAIN... 76

6 iv 7.2 ATC AND AOC THROUGHPUT CHAPTER 8 COVERAGE AND CAPACITY INPUTS TO COVERAGE AND CAPACITY REQUIREMENTS AMOUNT OF GATES AND STANDS AIRPORT AREAS DEFINITIONS AIRPORT VISITING A/C FRAME TYPES AND AIRPORT TRAFFIC MIX AIRCRAFT FRAME ANTENNA HEIGHTS FROM GROUND TRAFFIC MODELLING AND SCENARIO DEFINITION SESAR AIRPORT CATEGORIZATION CHAPTER 9 SYSTEM INTEROPERABILITY AND COMPATIBILITY MULTI-VENDOR INTEROPERABILITY INTERFERENCE ASPECTS CHAPTER 10 RF CELL DIMENSIONING AND PLANNING RF CELL DIMENSIONING COVERAGE ANALYSIS CAPACITY ANALYSIS RF CELL PLANNING CHAPTER 11 SECURITY REQUIREMENTS CHAPTER 12 TEST CASES IPV6 TEST CASES SPECIFICATION TEST CONFIGURATION TESTS DESCRIPTION TC-IPV6-STFUL TC-IPV6-STLESS-VB TC-IPV6-STLESS-BI TC-IPV6-FRAG ETHERNET CS TEST CASES SPECIFICATION TEST CONFIGURATION TESTS DESCRIPTION TC-ETH-CS-IP_RULE TC-ETH-CS-VLAN_RULE TC-ETH-CS-TOS_RULE CONVERGENCE SUBLAYER ESTABLISHMENT TEST CONFIGURATION TESTS DESCRIPTION TC-CS-IPV6_FB TC-CS-ETH_FB AEROMACS BROADCAST / MULTICAST TEST CASES TEST CONFIGURATION TESTS DESCRIPTION TC-MSBS-BASIC TC-MSBS-HO

7 v 12.5 D-TAXI TEST CASES CPDLC_ APPENDIX A ACRONYMS AND GLOSSARY OF TERMS APPENDIX B CAPACITY ANALYSIS B.1 CAPACITY AND COVERAGE ANALYSIS PER CELL B.1.1 HYPOTHESES MADE IN SIMULATIONS B.1.2 ANALYSIS OF RESULTS B.2 CAPACITY ANALYSIS PER AIRPORT B.2.1 OPERATIONAL CONCEPT B.2.2 PROPAGATION AND PHY/MAC LAYER MODEL B.2.3 SCENARIO B.2.4 SCENARIO B.2.5 QOS MODEL B.2.6 HANDOVER CONFIGURATION B.2.7 BACKGROUND TRAFFIC AIR TRAFFIC FIGURES IN MADRID BARAJAS BACKGROUND TRAFFIC MODEL SIMULATION RESULTS A. SCENARIO 1 SIMULATION RESULTS B. SCENARIO 2 SIMULATION RESULTS C. COMPARISON BETWEEN ITERATION 1 AND ITERATION 2 FOR SCENARIO HANDOVER RESULTS APPENDIX C AEROMACS DEPLOYMENT CASE STUDIES C.1 RADIO PLANNING TOOL AND PARAMETERS C.1.1 DEFINITION OF PROPAGATION MEDIA C.1.2 ENVIRONMENTAL MODELS C.1.3 NOTE: REFLECTION IS CONSIDERED IN THE SIMULATIONS IF CLUTTER DATA ARE AVAILABLE.BASE STATIONS & MOBILE STATIONS C.2 CASE STUDY 1: AEROMACS DEPLOYMENT AT BARAJAS AIRPORT C.2.1 GLOBAL RADIO COVERAGE IN BARAJAS AIRPORT (DL) C.2.2 RADIO COVERAGE LIMITED BY THE UPLINK (UL) C.2.3 SIMULATION OF INTRA-SYSTEM INTERFERENCE C.2.4 CONCLUSIONS AND RECOMMENDATION C.3 CASE STUDY 2: AEROMACS DEPLOYMENT AT TOULOUSE AIRPORT C.3.1 GLOBAL RADIO COVERAGE IN TOULOUSE AIRPORT C.3.2 SIMULATION OF INTER-SYSTEM INTERFERENCES IN TOULOUSE APPENDIX D SHARING THE FREQUENCY SPECTRUM WITH OTHER SERVICES APPENDIX E WG-82 MEMBERSHIP IMPROVEMENT SUGGESTION FORM LIST OF FIGURES FIGURE 1: ILLUSTRATION OF REFERENCE POINTS FOR THE MAXIMUM DATA LATENCY... 15

8 vi FIGURE 2: NETWORK REFERENCE MODEL FIGURE 3: ASN REFERENCE MODEL FIGURE 4: WMF ASN PROFILE A FIGURE 5: WMF ASN PROFILE B FIGURE 6: WMF ASN PROFILE C FIGURE 7: OVERALL RELATIONS BETWEEN AEROMACS BUSINESS ENTITIES [10] FIGURE 8: AEROMACS NETWORK ENTITIES FIGURE 9: MAIN FUNCTIONALITIES OF AEROMACS ASN-GW [10] FIGURE 10: AEROMACS AAA AND HA DEPLOYMENT SCENARIO FIGURE 11: ICAO 9896 IPS ADDRESSING STRUCTURE FOR AIRCRAFT ASSIGNMENTS [12] FIGURE 12: BARAJAS TERMINAL MAP OVERVIEW FIGURE 13: BARAJAS MULTISERVICE AIRPORT NETWORK TOPOLOGY FIGURE 14: BARAJAS RADIO NAVIGATION AIDS CABLING INFRASTRUCTURE FIGURE 15: BARAJAS MLAT SYSTEM CABLING INFRASTRUCTURE FIGURE 16: SINGLE NAP - MULTIPLE NSP FIGURE 17: MULTIPLE NAP - SINGLE NSP FIGURE 18: GREENFIELD NAP-NSP FIGURE 19: AEROMACS ROAMING ARCHITECTURE FIGURE 20: ROAMING SCENARIO 1 DATA ACCESS VIA HOME NSP [49] FIGURE 21: ROAMING SCENARIO 2 DATA ACCESS VIA CORRESPONDENT ROUTER (CR) [49] FIGURE 22: AEROMACS SYSTEM INTEGRATION ON A/C SCENARIO 1-A FIGURE 23: AEROMACS SYSTEM INTEGRATION ON A/C SCENARIO 1-B FIGURE 24: AEROMACS SYSTEM INTEGRATION ON A/C SCENARIO 2-A FIGURE 25: AEROMACS SYSTEM INTEGRATION ON A/C SCENARIO 2-B FIGURE 26: SCENARIO 2-B: CONNECTION BETWEEN AEROMACS AND ACD/AISD FIGURE 27: AEROMACS SYSTEM INTEGRATION ON A/C SCENARIO 3-A FIGURE 28: AEROMACS SYSTEM INTEGRATION ON A/C SCENARIO 3-B FIGURE 29: SCENARIO 3-B: CONNECTION BETWEEN AEROMACS AND ACD/AISD FIGURE 30: PHYSICAL SEGREGATION BETWEEN ACD AND AISD FIGURE 31: FLIGHT PHASES AND EVENTS IN APT SURFACE FIGURE 32: SEQUENTIAL EXECUTION OF SERVICES IN ARRIVAL FIGURE 33: SEQUENTIAL EXECUTION OF SERVICES IN DEPARTURE FIGURE 34: DEFINITION AND INTERCONNECTION OF AIRCRAFT, ACSP AND ATSU DOMAIN FIGURE 35: COMPARISON OF AIRPORT PATHLOSS MODELS FIGURE 36: GRAPHICAL PRESENTATION OF TILE IN UL-PUSC ZONE ; SLOT = 6 TILES OVER 3 SYMBOLS FIGURE 37: IPV6 TEST CASES TEST CONFIGURATION FIGURE 38: ETHERNET CS TEST CASES TEST CONFIGURATION FIGURE 39: CS ESTABLISHMENT TEST CASES TEST CONFIGURATION FIGURE 40. BROADCAST/MULTICAST TEST CONFIGURATION ERROR! NO SE PUEDEN CREAR OBJETOS MODIFICANDO CÓDIGOS DE CAMPO. FIGURE 41: END-TO-END TEST CASE CONFIGURATION FIGURE 42: FREQUENCY MASK FIGURE 43: BER AND PER IN FL, LOS CHANNEL ([50], SECTION 4.4) FIGURE 44: BER AND PER IN FL, NLOS CHANNEL [50] FIGURE 45: BER AND PER FOR RL, LOS CHANNEL [50] FIGURE 46: BER AND PER FOR RL, NLOS CHANNEL [50] FIGURE 47: MOBILE ROUTE MR FIGURE 48: MOBILE ROUTE MR

9 vii FIGURE 49: THROUGHPUT & PACKET LOSS WITH ARQ TYPE 1 AND ARQ TYPE 2 (UL) FIGURE 50: CASE 1: THROUGHPUT & PACKET LOSS IN LOS/NLOS (DL) FIGURE 51: CASE 2: THROUGHPUT & PACKET LOSS IN LOS/NLOS (DL) FIGURE 52: CASE 3: THROUGHPUT & PACKET LOSS IN LOS/NLOS (DL) FIGURE 53: SCENARIO 1 ARRIVAL TRAJECTORY FIGURE 54: SCENARIO 1 DEPARTURE TRAJECTORY FIGURE 55: SCENARIO 2 ARRIVAL TRAJECTORY FIGURE 56: SCENARIO 2 DEPARTURE TRAJECTORY FIGURE 57: UL/DL WIMAX FRAME. DATA BURST USAGE IN % FIGURE 58: UL/DL WIMAX FRAME. DATA BURST USAGE IN % FIGURE 59: WIMAX DOWNLINK DATA BURST USAGE. RED=ITERATION2. BLUE=ITERATION FIGURE 60: WIMAX UPLINK DATA BURST USAGE. RED=ITERATION2. BLUE=ITERATION FIGURE 61: HORIZONTAL AND VERTICAL PATTERN FOR BASE STATIONS (H: 3DB BEAMWIDTH = 110 ; V: 3DB BEAMWIDTH = 12 (TBC)) FIGURE 62: PROPOSED CELL PLANNING IN MADRID BARAJAS FIGURE 63: PROPOSED CELL PLANNING IN MADRID BARAJAS CLOSER DISTANCE BETWEEN BS IN HANDOVER FIGURE 64: PROPOSED CELL PLANNING IN MADRID BARAJAS RAMP ONLY FIGURE 65: FOCUS ON BS POSITION AND LABEL ON BARAJAS AIRPORT FIGURE 66: GLOBAL COVERAGE (DL) IN COMPOSITE SERVER DISPLAY: VEHICLES WITH HANT=2M(LEFT) AIRCRAFTS WITH HANT=10M (RIGHT) FIGURE 67: R1S1 COVERAGE FOR HANT=2M(LEFT) AND HANT=10M (RIGHT) FIGURE 68: GLOBAL COVERAGE (LIMITED BY UL) IN COMPOSITE SERVER DISPLAY: VEHICLES WITH HANT=2M (LEFT) AIRCRAFTS WITH HANT=10M (RIGHT) FIGURE 69: R1S1 RADIO COVERAGE (LIMITED BY UL), AIRCRAFTS WITH HANT=10M FIGURE 70: MAP OF CINR INTRA-SYSTEM INTERFERENCE, BASED ON DL COVERAGE FIGURE 71: GLOBAL COVERAGE (DL) IN COMPOSITE SERVER DISPLAY: VEHICLES WITH HANT=2M(LEFT) AIRCRAFTS WITH HANT=10M (RIGHT) FIGURE 72: GLOBAL COVERAGE FOR AIRCRAFTS (HANT = 10M) IN COMPOSITE SERVER DISPLAY: DL COVERAGE (LEFT) DL COVERAGE LIMITED BY UL (RIGHT) FIGURE 73: GLOBAL COVERAGE FOR AIRCRAFTS (HANT = 10M) IN COMPOSITE SERVER DISPLAY: DL COVERAGE LIMITED, NO REFLECTIONS CONSIDERED DOWNTILT FOR BS1 (S1 & S2) HAS BEEN INCREASED FROM 5 TO FIGURE 74: BS2 COVERAGE - AIRCRAFTS WITH HANT=10M, NO REFLECTIONS CONSIDERED DL (LEFT) - DL LIMITED BY UL (RIGHT) FIGURE 75: LOCALIZATION OF AEROMACS BS (IN RED, BS TOWER WITH 2 SECTORS BSS1 AND BSS2) AND TX MLS STATIONS (MLS AZ AND MLS EL IN YELLOW) AND RX MLS STATIONS (RX AZ AND RX EL IN MAGENTA) FIGURE 76: RADIATION PATTERNS ATTACHED TO EACH MLS TRANSMITTING STATION FIGURE 77: SCHEMATIC REPRESENTATION OF TX MLS STATIONS H PATTERNS OVER TOULOUSE AIRPORT FIGURE 78: RADIATION PATTERNS ATTACHED TO EACH MLS RECEIVING STATIONS FIGURE 79: RADIATION PATTERNS OF ANTENNAS ATTACHED TO AEROMACS STATIONS FIGURE 80: THRESHOLD DEGRADATION MAP FOR TX MLS VS. AEROMACS DL COVERAGE - NO REJECTION FIGURE 81: THRESHOLD DEGRADATION MAP FOR TX MLS VS. AEROMACS DL COVERAGE 70 DB REJECTION LIST OF TABLES TABLE 1: POSSIBLE ACTORS FOR NAP/V-NSP/H-NSP FUNCTIONS TABLE 2: NSP ID FORMAT [32]... 39

10 viii TABLE 3: POTENTIAL AEROMACS DEPLOYMENT SCENARIOS TABLE 4: SERVICES EXECUTED DURING DEPARTURE PHASE TABLE 5: SERVICES EXECUTED DURING ARRIVAL PHASE TABLE 6: AEROMACS CLASSES OF SERVICE EXAMPLE [3] TABLE 7: MAPPING OF ATN NETWORK PRIORITY TO MOBILE SUBNETWORK PRIORITY AEROMACS PROPOSAL TABLE 8: ACSP TRANSACTION TIME REQUIREMENTS [40] TABLE 9: ACSP AVAILABILITY REQUIREMENTS [40] TABLE 9: ATC AND AOC REQUIRED THROUGHPUT TABLE 10: A/C SEPARATION MINIMA TABLE 11: AIRFRAME HEIGHTS WITH RESPECT TO GROUND TABLE 12: A/C DWELL TIMES VS A/C AIRPORT OPERATION AREAS TABLE 13: AEROMACS EXPECTED THROUGHPUTS VS MODULATION SCHEMES TABLE 14: SINGLE SECTOR SCENARIO EXCLUDING FOQA [10] TABLE 15: AIRPORT SIZE CATEGORIES ACCORDING TO COCR TABLE 16: AIRPORT CAPACITY LOAD FOR SMALL AIRPORTS (3 OPERATIONS/HOUR) [10] TABLE 17: AIRPORT CAPACITY LOAD FOR SMALL AIRPORTS (3 OPERATIONS/HOUR) CONSIDERING FOQA AS A RAMP SERVICE [10] TABLE 18: AIRPORT CAPACITY LOAD FOR SMALL AIRPORTS (20 OPERATIONS/HOUR) [10] TABLE 19: AIRPORT CAPACITY LOAD FOR MEDIUM AIRPORTS (50 OPERATIONS/HOUR [10] TABLE 20: AIRPORT CAPACITY LOAD FOR LARGE AIRPORTS (100 OPERATIONS/HOUR) [10] TABLE 21: AIRPORT CAPACITY LOAD FOR VERY LARGE AIRPORTS (MORE THAN 100 OPERATIONS/HOUR) [10] 89 TABLE 22: DL LINK BUDGET TABLE 23: UL LINK BUDGET TABLE 24: MAXIMUM COVERAGE RESULTS TABLE 25: SERVICE DATA UNIT DIMENSIONING (BYTES) TABLE 26: PHY LAYER PARAMETERS TABLE 27: MCS SWITCHING THRESHOLDS TABLE 28: BARAJAS PATHLOSS MODELS PARAMETERS TABLE 29: MAIN ARQ PARAMETERS TABLE 30: SECONDARY-LEVEL ARQ PARAMETERS TABLE 31: SIZE OF PDU AND ARQ BLOCKS TABLE 32: ARRIVAL SPEEDS TABLE 33: DEPARTURE SPEEDS TABLE 34: SCENARIO 1 ARRIVAL TRAJECTORY TIMES TABLE 35: CHRONOLOGICAL DESCRIPTION OF SCENARIO 1 ARRIVAL TRAJECTORY TABLE 36: SCENARIO 1 DEPARTURE TRAJECTORY TIMES TABLE 37: CHRONOLOGICAL DESCRIPTION OF SCENARIO 1 DEPARTURE TRAJECTORY TABLE 38: SCENARIO 2 ARRIVAL TRAJECTORY TIMES TABLE 39: CHRONOLOGICAL DESCRIPTION OF SCENARIO 2 ARRIVAL TRAJECTORY TABLE 40: SCENARIO 2 DEPARTURE TRAJECTORY TIMES TABLE 41: CHRONOLOGICAL DESCRIPTION OF SCENARIO 2 DEPARTURE TRAJECTORY TABLE 42: ATN/IPS PRIORITY MAPPING INTO CLASSES PROPOSED BY [12] TABLE 43: COS CLASSIFICATION FOR AIRPORT CAPACITY ANALYSIS TABLE 44: COS CLASSIFICATION FOR AIRPORT CAPACITY ANALYSIS TABLE 45: HANDOVER PARAMETERS TABLE 46: RAMP ARRIVAL BACKGROUND TRAFFIC TABLE 47: RAMP DEPARTURE BACKGROUND TRAFFIC

11 ix TABLE 48: GROUND ARRIVAL BACKGROUND TRAFFIC TABLE 49: GROUND DEPARTURE BACKGROUND TRAFFIC TABLE 50: TOWER ARRIVAL BACKGROUND TRAFFIC TABLE 51: TOWER DEPARTURE BACKGROUND TRAFFIC TABLE 52: UL&DL BACKGROUND TRAFFIC TABLE 53: CELL PLANNING FEATURES USED IN CAPACITY SIMULATIONS TABLE 54: END TO END DELAY PER CLASS OF SERVICE TABLE 55: NET SERVICES RESPONSE TIME TABLE 56: ATC1 SERVICES RESPONSE TIME TABLE 57: ATC2 SERVICES RESPONSE TIME TABLE 58: ATC3 SERVICES RESPONSE TIME TABLE 59: AOC1 SERVICES RESPONSE TIME TABLE 60: AOC2 SERVICES RESPONSE TIME TABLE 61: END TO END DELAY PER CLASS OF SERVICE TABLE 62: NET SERVICES RESPONSE TIME TABLE 63: ATC1 SERVICES RESPONSE TIME TABLE 64: ATC2 SERVICES RESPONSE TABLE 65: ATC3 SERVICES RESPONSE TABLE 66: AOC1 SERVICES RESPONSE TIME TABLE 67: AOC2 SERVICES RESPONSE TIME TABLE 68: SUMMARY OF BS NUMBER AND BACKGROUND TRAFFIC FIGURES PER ITERATION TABLE 69: QOS CONFIGURATION FOR ITERATION 1 AND ITERATION TABLE 70: RESULTS ON PACKET LATENCY FOR ITERATION 1 AND ITERATION 2. SCENARIO TABLE 71: CAPACITY LIMITATIONS IN ITERATION 1 SOLVED IN ITERATION TABLE 72: RESULTS FOR HO PERFORMANCE. CONSECUTIVE BS DISTANCE = 2650 M / 1300 M TABLE 73: WALL ATTENUATION VALUES TABLE 74: WINDOW ATTENUATION VALUES TABLE 75: BS COORDINATES PROPOSED FOR MADRID BARAJAS PLANNING TABLE 76: FREQUENCY RE-USE PLANNING PROPOSAL ERROR! NO SE PUEDEN CREAR OBJETOS MODIFICANDO CÓDIGOS DE CAMPO.TABLE 77: CAPACITY PLANNING FIGURES IN MADRID BARAJAS TABLE 78: CALCULATION OF CELL RANGE (DL IN M) FOR EACH MODULATION SCHEME AND MS CATEGORY (BASED ON R1S1 COVERAGE, NEAR LOS DIRECTION) TABLE 79: CALCULATION OF CELL RANGE (DL IN M) FOR EACH MODULATION SCHEME AND MS CATEGORY (BASED ON R1S1 COVERAGE, NLOS DIRECTION) TABLE 80: DL COVERAGE AND REVERSE COVERAGE TABLE 81: FREQUENCY PLANNING & REUSE FOR INTRA-SYSTEM INTERFERENCE ANALYSIS TABLE 82: ASSUMPTION OF CINR VERSUS MODULATION SCHEMES TABLE 83: BS2 RANGE FOR DL AND DL LIMITED BY UL TABLE 84: AZIMUTH AND ELEVATION TX MLS STATION PARAMETERS TABLE 85: AZIMUT AND ELEVATION RX MLS STATION PARAMETERS TABLE 86: PARAMETERS OF AEROMACS STATIONS ERROR! NO SE PUEDEN CREAR OBJETOS MODIFICANDO CÓDIGOS DE CAMPO.TABLE 87: TD CALCULATION FOR INTERFERENCE ON MLS RECEIVING STATIONS ERROR! NO SE PUEDEN CREAR OBJETOS MODIFICANDO CÓDIGOS DE CAMPO.TABLE 88: TD CALCULATION FOR INTERFERENCE ON AEROMACS BASE STATIONS

12 x

13 PURPOSE AND SCOPE CHAPTER 1 INTRODUCTION This document contains Minimum Aviation System Performance Specification (MASPS) for an Aeronautical Mobile Airport Communication System (AeroMACS). The purpose of this MASPS is to define the system performance requirements and to outline possible implementation options (architectures, use cases) for AeroMACS. In case relevant standards have not yet been developed (like for the IP addressing scheme), this document provides recommendations for further consideration in the appropriate standardisation bodies. In addition to this MASPS, EUROCAE WG-82 has also developed other AeroMACS standards and in particular the AeroMACS Profile (ED-222) and the AeroMACS MOPS (ED-223) jointly with RTCA SC-223. It is also noted that there is currently ongoing AeroMACS related standardisation activities in other groups (such as ICAO WGS, WIMAX Forum AWG and AEEC SAI), which are addressing aspects that may be relevant to the MASPS work such as the IP addressing scheme, the AeroMACS security framework and the AeroMACS network/architecture reference model. If required, future updates of this MASPS will incorporate such material. Chapter 2 of this document provides a high-level description of the network model for AeroMACS including the AeroMACS functional entities and reference points over which interoperability is achieved between functional entities. Then different network implementation architectures for AeroMACS are discussed. This includes the whole end-to-end communication chain and deals with the ground and airborne architectural components as well. In that context the IPv6 addressing scheme included in the ICAO ATN/IPS Manual is described. Chapter 3 describes potential ATC and AOC applications for AeroMACS. Further on it defines scenarios, which have been used to validate performance requirements for AeroMACS. Chapter 4 summarizes AeroMACS operation requirements. Chapter 5 summarizes AeroMACS technical requirements. Chapter 6 provides the QoS requirements for AeroMACS. In addition, a proposal for inclusion in ICAO Annex 10 for the mapping of AeroMACS classes of service over ATN message priority levels is outlined. Chapter 7 gives an overview on the Safety and Performance requirements derived from EUROCAE WG-78 work. Therefore the requirements are based on an end-toend perspective. Regarding the functional entities of AeroMACS as described in Chapter 2 Safety and Performance recommendations are given as well. Chapter 8 addresses specifically the aspects of physical coverage and capacity of the AeroMACS system. Chapter 9 outlines AeroMACS interoperability and compatibility requirements. Chapter 10 provides information related to RF cell dimensioning and planning.

14 12 Chapter 11 outlines AeroMACS Security requirements. Chapter 12 describes a set of system level tests for IPv6, Ethernet CS and multicast and broadcast functions support, as well as an end-to-end test case. The end-to-end test case is similar to the one described in the DLS Community Specification [52] (this specification is defined to prove the interoperability of implemented constituents from an application level perspective). Appendix A outlines the list of acronyms and glossary of terms Appendix B gives more information about a capacity analysis conducted within the SESAR project P Appendix C includes material from SESAR project P related to AeroMACS deployment case studies. Appendix D describes the current status of compatibility issues due to interference between AeroMACS and other radio systems currently in use. Appendix E provides the list of EUROCAE WG-82 members. 1.2 RELATIONSHIPS TO OTHER DOCUMENTS A great part of the material used for the development of the AeroMACS MASPS is based on the outcome of the two SESAR AeroMACS Projects P and P 9.16 which started in 2010 and have completed the technical activities at the end of As far as required this material has been updated in order to reflect required changes since the finalisation and publication of the relevant SESAR deliverables 1.3 DESCRIPTION OF THIS DOCUMENT DOCUMENT CONVENTIONS SHALL The use of the word SHALL indicates a mandated criterion; i.e. compliance with the particular procedure or specification is mandatory and no alternative may be applied. SHOULD The use of the word SHOULD (and phrases such as IT IS RECOMMENDED THAT..., etc.) indicate that though the procedure or criterion is regarded as the preferred option, alternative procedures, specifications or criteria may be applied, provided that the manufacturer, installer or tester can provide information or data to adequately support and justify the alternative. MAY The use of the word MAY indicates that alternative procedures, specifications or criteria are permitted DEFINITIONS Access Service Network (ASN). ASN is defined as a complete set of network functions needed to provide radio access to an AeroMACS subscriber. The ASN provides the following mandatory functions: AeroMACS Layer-2 (L2) connectivity with AeroMACS MS, Transfer of AAA messages to AeroMACS subscriber s Home Network Service Provider (H-NSP) for authentication, authorization and session accounting for subscriber sessions,

15 13 Network discovery and selection of the AeroMACS subscriber s preferred NSP, Relay functionality for establishing Layer-3 (L3) connectivity with a AeroMACS MS (i.e. IP address allocation) In addition to the above mandatory functions, for a portable and mobile environment, an ASN supports the following functions: o ASN anchored mobility, o ASN-CSN tunnelling. ASN comprises network elements such as one or more Base Station(s), and one or more ASN Gateway. While one ASN-GW is generally used, there may be implementations with more than one single ASN-GW in the ASN. Adaptive modulation. A system s ability to communicate with another system using multiple burst profiles and a system s ability to subsequently communicate with multiple systems using different burst profiles. Aerodrome. A defined area on land or water (including any buildings, installations and equipment) intended to be used either wholly or in part for the arrival, departure and surface movement of aircraft. ASN Gateway (ASN-GW). ASN-GW is placed at the edge of ASN and it's the link to the CSN. ASN-GW assists mobility and security in the control plane and handles the IP forwarding. ASN control is handled by ASN-GW and BS. ASN-GW Control plane handles all the radio-independent control and feature set includes authorization, authentication, and accounting (AAA), context management, profile management, service flow authorization, paging, radio resource management, and handover. Data plane feature set includes mapping radio bearer to the IP network, packet inspection, tunnelling, admission control, policing, QoS and data forwarding. ASN-GW has the authenticator and key distributor to implement AAA framework along with AAA relay in order to transmit signals to AAA server wherein the user credentials during network re/entry are verified with EAP authentication. Security context is created during AAA session and keys (MSK and PSK) are generated and shared with BS and MS. AAA module in the ASN-GW provides also flow information for accounting since every single detail about a flow such as transferred or received number of bits, duration, and applied policy is present and directly retrievable from the data plane. ASN-GW is responsible for profile management together with policy function residing in the connectivity network. Profile management identifies the user and its subscribed credentials such as allowed QoS rate, number of flows, type of flows, etc. BS (Base Station). A generalized equipment set providing connectivity, management, and control of the subscriber station (SS). BER (Bit Error Rate). Number of bit errors divided by the total number of transferred bits during a studied time interval measured after error decoder. Burst profile. Set of parameters that describe the uplink (UL) or downlink (DL) transmission properties associated with an interval usage code. Each profile contains parameters such as modulation type, forward error correction (FEC) type, preamble length, guard times, etc. CPDLC. The ATN application Controller Pilot Data Link Communications.

16 14 Connectivity Service Network (CSN). CSN is defined as a set of network functions that provide IP connectivity services to the AeroMACS subscriber(s). A CSN MAY provide the following functions: MS IP address and endpoint parameter allocation for user sessions, Internet access, AAA proxy or server, Policy and Admission Control based on user subscription profiles, ASN-CSN tunnelling support, Inter-CSN tunnelling for roaming, AeroMACS services such as location based services, connectivity for peer-topeer services, provisioning, authorization and/or connectivity to IP multimedia services and facilities to support lawful intercept services. The exact list of AeroMACS services is FFS. CSN MAY comprise network elements such as routers, AAA proxy/servers, user databases. Data transit delay. In accordance with ISO 8348, the average value of the statistical distribution of data delays. This delay represents the subnetwork delay and does not include the connection establishment. Downlink. The transmission direction from the base station (BS) to the subscriber station (SS). FA (Frequency assignment). A logical assignment of downlink (DL) center frequency and channel bandwidth programmed to the base station (BS). GROUND area: airport surface area used when A/C is pushed back and is moving most of the time up to the end of the taxiing phase. Taxiways and parking/stand areas belong to GROUND. HO (Handover). The process in which a mobile station (MS) migrates from the airinterface provided by one base station (BS) to the air-interface provided by another BS. A break-before-make HO is where service with the target BS starts after a disconnection of service with the previous serving BS. Interruption Time: Time between the message indicating the start of the HO (HO_IND) and the message indicating completion of network re-entry (RNG-RSP). During the interruption time the MS is not able to communicate with any BS through a valid Service Flow. Latency. The data latency is defined as the one-way transit time between a packet being available at the IP layer (Tx reference point) in either the MS/ Radio Access Network and the availability of this packet at IP layer (Rx reference point) in the Radio Access Network / MS. Mobility Service Provider (MSP). Instance of an Administrative Domain which may be an ACSP, ANSP, Airline, Airport Authority, government or other aviation organization that operates ATN/IPS mobility.

17 15 FIGURE 1: ILLUSTRATION OF REFERENCE POINTS FOR THE MAXIMUM DATA LATENCY MS (Mobile Station). A station providing connectivity between subscriber equipment and a base station (BS) using the IEEE mobile standard. Network Access Provider (NAP). NAP is a business entity that provides AeroMACS radio access infrastructure to one or more AeroMACS Network Service Providers (NSPs). A NAP implements this infrastructure using one ASN. Network Service Provider (NSP). NSP is a business entity that provides IP connectivity and AeroMACS services to AeroMACS subscribers compliant with the Service Level Agreement it establishes with AeroMACS subscribers. To provide these services, an NSP establishes contractual agreements with one or more NAPs. Additionally, an NSP MAY also establish roaming agreements with other NSPs and contractual agreements with third-party application providers (e.g., ASP or ISPs) for providing AeroMACS services to subscribers. From an AeroMACS subscriber standpoint, an NSP MAY be classified as Home NSP (H-NSP) or Visited NSP (V-NSP). Roaming. Roaming is the capability of wireless networks via which a wireless subscriber obtains network services using a visited network operator s coverage area (NSP). At the most basic level, roaming typically requires the ability to reuse authentication credentials provided/provisioned by the home operator in visited networks, successful user/ms authentication by the home operator. PDU. Packet Data Unit. PUSC. Partial Usage Sub-Channelisation. RAMP area: location at the airport where A/C is stationary and hooked on at the gate/stand. For instance, physical areas like gates belong to RAMP Residual error rate. The ratio of incorrect, lost and duplicate sub-network service data units (SNSDUs) to the total number of SNSDUs that were sent. RF. Radio Frequency. Transaction. One way delivery of an IP layer message. Maximum transaction time or expiration time (defined in OSED [11]). The maximum acceptable time at which the operational communication transactions are required to be completed at probability, corresponding to the Continuity target. As

18 16 the operational validity of the message has expired, this time is referred to as expiration time (ET). Scheduling Service. Scheduling services represent the data handling mechanisms supported by the Media Access Control (MAC) scheduler for data transport on a connection. Each connection is associated with a single scheduling service. A scheduling service is determined by a set of QoS parameters that quantify aspects of its behavior. These parameters are managed using the DSA and DSC message dialogs. SF (Service flow). A unidirectional flow of media access control layer (MAC) service data units (SDUs) on a connection that is providing a particular quality of service (QoS). SN (Subnetwork). The word subnetwork in this document denotes the AeroMACS component of the end-to-end communication network. Subnetwork entry time. The time from when the mobile station starts the scanning for BS transmission, until the network link establishes the connection, and the first network user protocol data unit can be sent. NOTE: It does not include time for self-test or other power up functions. SS (Subscriber Station). A generalized equipment set providing connectivity between subscriber equipment and a base station (BS). SDU(Service data unit). The data unit exchanged between two adjacent protocol layers. On the downward direction, it is the data unit received from the previous higher layer. On the upward direction, it is the data unit sent to the next higher layer. SNSDU(Subnetwork service data unit). An amount of sub-network user data; the identity of which is preserved from one end of a sub-network connection to the other. TDD (Time division duplex). A duplex scheme where uplink (UL) and downlink (DL) transmissions occur at different times but may share the same frequency. TOWER area: airport surface where ground control is handed over to Tower until take-off phase. TOWER area is shortly before the runways. The GROUND controller hands over to the TOWER controller after the aircraft is on its way to the runway. On smaller airports the GROUND + TOWER could not be separated. Uplink. The direction from a subscriber station (SS) to the base station (BS). User (or AeroMACS user). Entity that is unambiguously linked to an MS/SS and involves the functions that are inherent to the MS/SS operation but are out of the IEEE standard, such as authentication, authorization, accounting, QoS policy enforcement, CSN database, service profile parameters, admission control, IP session, NAI domain identification. The term is used to differentiate from AeroMACS device, which is linked to the hardware and a MAC address. Note that the AeroMACS user is different from end-user or application user. 1.4 REFERENCES [1] EUROCONTROL COCR v2.0, Communications Operating Concept and Requirements for the Future Radio System

19 17 [2] SESAR P D01-T1.1A System Analysis For AeroMACS Use, v2.0 (Nov2010) [3] SESAR P D01-T1.1B AeroMACS System Requirements Document, v1.0 (Nov2010) [4] SESAR P D01-T1.4 AeroMACS Functional Architecture Definition", v1.0 (Nov2010) [5] SESAR P D03.2 AeroMACS Profile Definition", v (Feb2012) [6] SESAR P D02.2a Study and characterization of the traffic model in the airport, v (May2011) [7] SESAR P D02.1 AeroMACS Channel Modelling, v1.0 (Jun2011) [8] SESAR P D02.3 Compatibility Study Between AeroMACS and FSS, v1.0 (Jun2011) [9] SESAR P D03.1 AeroMACS Profile Evaluation and Validation", v (Feb2010) [10] SESAR P D04.0 "AeroMACS Deployment & Integration Analysis", v (Abr2014) [11] EUROCAE ED78A, Guidelines for approval of the provision and use of air traffic services supported by data communications [12] ICAO 9896 Manual for the ATN using IPS Standards and Protocols [13] ICAO Annex 14 Aerodromes, Fourth Edition July 2004 [14] ICAO Aerodrome Design Manual Part 6 Frangibility, First Edition 2006 [15] ICAO Airport Planning Manual Part 1 Master Planning, Second Edition 1987 [16] ICAO EUR Frequency Management Manual EUR Doc 11, Edition 2010 [17] Procedimiento Interno para Tramitación y Coordinación de Informes por Servidumbres Aeronaúticas AENA, 2010 [18] C-Band Airport Surface Communications System Standards and Development Phase II Final Report, Volume 1: Concepts of Use, Initial System Requirements, Architecture, and AeroMACS Design Considerations, NASA, 2011 [19] SESAR P D01-T1.5 "Spectrum investigations", v1.0 (Nov2010) [20] IRIG 106, DOCUMENT PART I: TELEMETRY STANDARDS, (APRIL 2011) [21] ITU, 2nd Session of the Conference Preparatory Meeting (CPM) for WRC-12, February [22] WMF-T R010v04-Stage2 Network Architecture: Architecture tenets, Reference Model and Reference Points [23] WMF-T R010v05-Stage3_ Network Architecture: Detailed Protocols and Procedures [24] WMF-T R010v4-Stage3 R6 R8 ASN Anchored Mobility Scenarios [25] SESAR P D08 AeroMACS Safety and Security Analysis, v (Mar2014) [26] SANDRA_R6.2.2: Report on Modeling and Performance Simulations (in work). [27] ICAO Aerodrome Design Manual Part 1 Runways, Third Edition 2006 [28] AOC Datalink Dimensioning Executive Summary, SESAR. [29] ICAO PANS-OPS 8168 [30] NWG-T R010v07-IOT, Mobile interoperability test [31] WMF-T R010v04-Stage2 Network Architecture: Architecture tenets, Reference Model and Reference Points

20 18 [32] WMF-T R010v05-Stage3_ Network Architecture: Detailed Protocols and Procedures [33] SANDRA Project, [34] SANDRA WP6.2.3 Technical Document on PHY Layer Performance V0.2, 23/09/2010, Draft [35] SANDRA Project, DLR, PHY_Results_v4.xls [36] SANDRA WP6.2.4 Discussion paper on MAC simulations, September 2011 [37] WiMAX Forum Application Working Group The WiMAX Forum System Level Simulator NS-2, Release 2.6, March [38] RFC 791 Internet Protocol (September 1981) [39] IEEE , Part 16: Air Interface for Broadband Wireless Access Systems [40] EUROCAE ED-228: Safety and Performance Standard for Baseline 2 ATS Data Communications (Baseline 2 SPR Standard) [41] AOC Datalink dimensioning study, Edition , Ed date Nov 16th, [42] SESAR P9.16 Deliverable D03 AeroMACS Airborne System Requirements and Architecture Dossier [43] ICAO Aeronautical Communications Panel (ACP) WG-S, third meeting, WP-06: MSS Interference Analysis for AeroMACS, July [44] [45] [46] [47] SANDRA D3.5.5 NAMING AND ADDRESSING, v1.0, June 2011 [48] ICAO ACP WG-S/3 WP11 White paper on AeroMACS deployment scenarios and derived requirements, v3.1, October 2013 [49] SANDRA D3.2.1 CONSOLIDATED SANDRA NETWORK AND INTEROPERABILITY ARCHITECTURE, v2.0, March 2012 [50] SANDRA D6.2.1 AEROMACS PROFILE RECOMMENDATION DOCUMENT, Version 2.0, [51] EUROCAE ED-222: AERONAUTICAL MOBILE AIRPORT COMMUNICATIONS SYSTEM (AeroMACS) PROFILE, November 2013 [52] ETSI EN v1.2.1 DLS System; Community Specification for application under the Single European Sky Interoperability Regulation EC 552/2004; Requirements for ground constituents and system testing, April 2012 [53] RFC 2460 Internet Protocol, Version 6 (IPv6) Specification (December 1998) [54] WMF-T R016v01-Stage 2: Architecture Tenets, Reference Model and Reference Points [55] RFC 3315 Dynamic Host Configuration Protocol for IPv6 (DHCPv6) (July 2003) [56] RFC 4862 IPv6 Stateless Address Autoconfiguration (September 2007) [57] AeroMACS PICS, WiMAX Forum: WMF-T R010-v01 [58] ETSI TS v1.3.6 Conformance Testing for the Network Layer of HiperMAN/WiMAX terinal devices; Part 2: Test Suite Structure and Test Purposes (TSS&TP), September 2010 [59] EUROCAE ED-153: GUIDELINES FOR ANS SOFTWARE SAFETY ASSURANCE, August 2009 [60] ICAO Annex 10 Aeronautical Communications - Vol III Communication Systems

21 19 [61] 664P1-1 Aircraft Data Network, Part 1, Systems Concepts and Overview [62] 664P5 Aircraft Data Network, Part 5, Network Domain Characteristics and Interconnection [63] AT4-ECTL-TN#18 Multicast and broadcast support in AeroMACS (October 2014) [64] ICAO WG-S - AeroMACS SARPs (November 2014) [65] NEWSKY Design Document, K. Leconte et al., deliverable 11 of NEWSKY project, v2.1, July 2009 [66] AT4-ECTL-TN#17 IPv6 and Ethernet CS test cases specification for AeroMACS (April 2014)

22 20 CHAPTER 2 AEROMACS NETWORK ARCHITECTURE This chapter describes the functional component organization and operation principles of AeroMACS networks. The chapter is organized as follows: first, the network reference model from WiMAX Forum is described. Second, functional requirements affecting network design and service provision are listed. Third, the main functional entities are specified together with generic operation protocols, for a generic concrete network topology. Then, an example of airport network infrastructure is described as a guidance to find deployment options and points of attachment in the case of an AeroMACS network rollout. Finally, deployment models are proposed where AeroMACS network architecture leaves open aspects, namely: NSP & NAP deployment, airborne architecture and roaming scenarios. 2.1 Network Reference Model Overview The Network Reference Model (NRM) is a general logical representation of the network architecture including AeroMACS based on [22]. The NRM identifies functional entities and reference points over which interoperability is achieved between functional entities. Each of the entities, MS, ASN and CSN represent a grouping of functional entities. MS, ASN and CSN functions MAY be realized in single physical entities. As an alternative approach: MS, ASN and CSN functions MAY be distributed over multiple physical entities. While the grouping and distribution of functions into physical devices within the ASN is an implementation choice, the AeroMACS architecture specification defines one ASN interoperability profile. The intent of the NRM is to allow multiple implementation options for a given functional entity, and yet achieve interoperability among different realizations of functional entities. Interoperability is based on the definition of communication protocols and data plane treatment between functional entities to achieve an overall end-to-end function, for example, security or mobility management. Thus, the functional entities on either side of RP (Reference Point) represent a collection of control and Bearer Plane endpoints. In this setting, interoperability will be verified based only on protocols exposed across an RP, which would depend on the end-to-end function or capability realized (based on the usage scenarios supported by the overall network). The NRM specifies the normative use of protocols over an RP for such a supported capability. If an implementation claims support for the capability and exposes the RP, then the implementation needs to comply with this specification. This avoids the situation where a protocol entity can reside on either side of an RP or the replication of identical procedures across multiple RPs for a given capability.

23 Reference Points FIGURE 2: NETWORK REFERENCE MODEL Figure 2 introduces several interoperability reference points. A Reference Point (RP) represents a conceptual link that connects different functions of different functional entities. RPs are not necessarily a physical interface. These functions expose various protocols associated with an RP. All protocols associated with a RP MAY not always terminate in the same functional entity i.e., two protocols associated with a RP need to be able to originate and terminate in different functional entities. The normative reference points between the major functional entities are in the following subsections Reference Point R1 Reference Point R1 consists of the protocols and procedures between MS and BS as part of the ASN per the air interface (PHY and MAC) specifications (see also ASN reference model outlined in section 2.1.3). Reference point R1 MAY include additional protocols related to the management plane Reference Point R2 Reference Point R2 consists of protocols and procedures between the MS and CSN associated with Authentication, Services Authorization and IP Host Configuration management. This reference point is logical in that it does not reflect a direct protocol interface between MS and CSN. The authentication part of reference point R2 runs between the MS and the CSN operated by the home NSP, however the ASN and CSN operated by the visited NSP MAY partially process the aforementioned procedures and mechanisms. Reference Point R2 MAY support IP Host Configuration Management running between the MS and the CSN (operated by either the home NSP or the visited NSP).

24 Reference Point R3 Reference Point R3 consists of the set of Control Plane protocols between the ASN and the CSN to support AAA, policy enforcement and mobility management capabilities. It also encompasses the Bearer Plane methods (e.g., tunnelling) to transfer user data between the ASN and the CSN. Some of the protocols foreseen on this RP are RADIUS and DHCP. In the following some particular internetworking relationships will be described between ASN and CSN for Sharing an ASN by multiple CSN, Providing service to roaming MS. These examples are described in detail in section AeroMACS Network Architecture Interoperability Scope Reference Point R4 Reference Point R4 consists of the set of Control and Bearer Plane protocols originating/terminating in various functional entities of an ASN that coordinate MS mobility between ASNs and ASN-GWs. R4 is the only interoperable RP between similar or heterogeneous ASNs Reference Point R5 Reference Point R5 consists of the set of Control Plane and Bearer Plane protocols for internetworking between the CSN operated by the home NSP and that operated by a visited NSP ASN Reference Model The ASN defines a logical boundary and represents a convenient way to describe aggregation of functional entities and corresponding message flows associated with the access services. The ASN represents a boundary for functional interoperability with AeroMACS clients, AeroMACS connectivity service functions and aggregation of functions embodied by different vendors. Mapping of functional entities to logical entities within ASNs as depicted in the NRM is informational ASN Decomposition The ASN reference model is illustrated in Figure 3. An ASN shares R1 reference point (RP) with an MS, R3 RP with a CSN and R4 RP with another ASN. The ASN consists of at least one instance of a Base Stations (BS) and at least one instance of an ASN Gateway (ASN-GW). A BS is logically connected to one or more ASN Gateways. The R4 reference point is the only RP for Control and Bearer Planes for interoperability between similar or heterogeneous ASNs. Interoperability between any types of ASNs is feasible with the specified protocols and primitives exposed across R1, R3 and R4 Reference Points. When ASN is composed of an ASN-GWs (where n > 1), Intra ASN mobility MAY involve R4 control messages and Bearer Plane establishment. For all applicable protocols and procedures, the Intra-ASN reference point R4 needs to be fully compatible with the Inter-ASN equivalent.

25 BS Definition FIGURE 3: ASN REFERENCE MODEL The AeroMACS Base Station (BS) is a logical entity that embodies a full instance of the MAC and PHY in compliance with the AeroMACS Specifications and MAY host one or more access functions. A BS instance represents one sector with one frequency assignment. It incorporates scheduler functions for uplink and downlink resources, which will be left for vendor implementation and are outside the scope of this document. Connectivity (i.e., reachability) of a single BS to more than one ASN-GW MAY be required as a redundancy option ASN Gateway Definition The ASN Gateway (ASN-GW) is a logical entity that represents an aggregation of Control Plane functional entities that are either paired with a corresponding function in the ASN (e.g. BS instance), a resident function in the CSN or a function in another ASN. The ASN-GW MAY also perform Bearer Plane routing or bridging function. ASN-GW implementation MAY include redundancy and load-balancing based on radio parameters among several ASN-GWs. ASN-GW implementation MAY include load-balancing based on SLA requirements of the MSs. NOTE: The implementation details are out of scope for this document. For every MS, a BS is associated with exactly one default ASN GW ASN Reference Points Reference Point R6 Reference point R6 consists of the set of control and Bearer Plane protocols for communication between the BS and the ASN-GW. The Bearer Plane consists of intra- ASN data path between the BS and ASN-GW. The Control Plane includes protocols for data path establishment, modification, and release control in accordance with the MS mobility events. R6 also serves as conduit for exchange of MAC states information between neighbouring BSs except when protocols and primitives over R8 are defined. The main protocol used in this interface is an IP-in-IP tunnelling protocol, named GRE (Generic Encapsulation Protocol). This leads to the forwarding and transport of

26 24 Ethernet packets coming from the ASN to CSN. Another mean to achieve that is the end-to-end VLAN service Reference Point R Reference Points ASN Functions Reference Point R8 is not used in real implementation therefore out of scope. Supported capabilities across reference points R1 R5 (based on usage scenarios), and the normative definition of interoperable protocols/procedures for each supported capability is within the scope of AeroMACS Network Architecture specification. Control Plane definition message flows and Bearer Plane data flows for interoperable R6 are within the normative scope of the AeroMACS Network Architecture specification. The normative definition of protocols, messages, and procedures to support ASN functions and capabilities, independent of specific grouping of these capabilities into physical realizations, is within the scope of AeroMACS Network Architecture specification. The functional decomposition is the preferred methodology of AeroMACS Network Architecture without specific reference to any logical or physical network entities. Additionally, only one ASN Profile has been defined in scope of AeroMACS Network Architecture CSN Reference Model CSN internal reference points are out of scope of this specification AeroMACS ASN Profile Profile A A profile maps ASN functions into BS and ASN-GW so that protocols and messages over the exposed reference point are identified. The following text describes the three WMF profiles of an ASN based on the current Stage 2 specifications. These three profiles show three possible implementations of the ASN and do not necessarily mandate a vendor to support all three. AeroMACS ASN SHALL support WiMAX Forum profile C as described below. NOTE 1: The specifications for profiles A and B are provided for information only. NOTE 2: The depiction of a function on either the ASNGW or the BS in the figures below does not imply that the function exists in all manifestations of this profile. Instead, it indicates that if the function existed in a manifestation it would reside on the entity shown. Identification of the ASN profiles was done for the specific goal of providing a bound framework for interoperability among entities inside an ASN. ASN functions are mapped into ASN-GW and BS as shown in Figure 4. Some of the key attributes of Profile A are: HO Control is in the ASN GW. RRC is in ASN GW that allows RRM among multiple BSs. ASN Anchored mobility among BSs is achieved by utilizing R6 and R4 physical connections.

27 Profile B For more details refer to [22]. FIGURE 4: WMF ASN PROFILE A Profile B ASNs are characterized by unexposed intra-asn interfaces and hence intra- ASN interoperability is not specified. However, Profile B ASNs are capable of interoperating with other ASNs of any profile type via R3 and R4 reference points. Inter-ASN anchored mobility is possible via R4.

28 26 For more details refer to [22]. FIGURE 5: WMF ASN PROFILE B Profile C According to Profile C, ASN functions are mapped into ASN-GW and BS as shown in Figure 6. Key attributes of Profile C are: HO Control is in the Base Station. RRC is in the BS that would allow RRM within the BS. An RRC Relay is in the ASN GW, to relay the RRM messages sent from BS to BS via R6. As in Profile A, ASN Anchored mobility among BSs is achieved by utilizing R6 and R4 physical connections.

29 27 FIGURE 6: WMF ASN PROFILE C For more details refer to [22]. 2.2 Functional requirements The scope of this section is to address general requirements related to the access and connectivity network that have impact on an AeroMACS deployment. It deals with elements from the standardized architecture engaged to the AeroMACS deployment and integration with the overall airport system, which are out of the scope of the radio data link specification Access Service Network (ASN) requirements AeroMACS surface data link SHALL operate independently to other access network technology on the backbone or ground side. AeroMACS architecture SHALL NOT preclude inter-technology handovers (HOs). AeroMACS convergence sublayer SHALL support IPv4 CS and IPv6 CS. AeroMACS convergence sublayer MAY support ETH_CS. AeroMACS SHALL route the inbound and outbound IP packets to/from the backbone network according to any of the following matching rules available: Protocol field, IP Masked Source Address parameter, IP Masked Destination Address parameter, Protocol Source Port Range field, Protocol Destination Port Range field, IEEE 802.1Q VLAN ID field, IP Type of Service (DS bytes), and others. AeroMACS architecture SHALL give the means to mitigate security risk propagation from vulnerable AeroMACS ASN elements (mainly ASN-Gateway) to the backbone of the Communication infrastructure Core Service Network (CSN) requirements AeroMACS SHALL use IP radio and ground Internet Protocol (IP) compliant with ICAO 9896 [12].

30 28 AeroMACS SHALL support IPv6. AeroMACS SHALL support IPv4. NOTE: Support of IPv4 is required in order to be interoperable with legacy systems. AeroMACS infrastructure SHALL give support to network addressing for vehicles and aircraft in the home and visited networks without distinction. Mobile IPv6 SHALL be implemented by a Mobility Service Provider (MSP) in compliance with ICAO 9896 standard for communication with aircraft. A MS SHALL get a dynamic IP address. The vehicles which have been allocated the same address SHALL not operate on the same aerodrome. NOTE 1: AeroMACS implements IPv6 addressing architecture as specified in RFC 4291 and uses globally scoped IPv6 addresses. NOTE 2: ATN/IPS MSPs containing AeroMACS networks obtain IPv6 address prefix assignments from their local Internet registry (LIR) or regional Internet registry (RIR). NOTE 3: MSPs obtain a /32 IPv6 address prefix assignment for the exclusive use of AeroMACS MS. MSPs advertise their /32 aggregate prefix to the ATN/IPS. AeroMACS SHALL support multiple NSPs for provisioning ATC/AOC services over the same data link. AeroMACS infrastructure SHALL provide the capability to the subscriber to select the preferred CSN/NSP. ASN-GW SHALL support GRE tunnelling on R6 interface. NOTE: ASN routers support dual network layer stack, tunnelling or protocol conversion, as specified in ICAO Doc 9896, for connecting IPv6 core networks to AeroMACS ASN network which can go over IPv4 stack Service Provision Requirements The network infrastructure SHALL enable provision of ATC services to all equipped aircraft. The network infrastructure SHALL enable provision of AOC services to equipped aircraft. The network infrastructure SHALL enable provision of airport operation related services (communication with the surface vehicles). All NAP and NSP SHOULD be able to support ATC service provision to all aircraft independently from their AOC/AAC contracts. Airlines that do not subscribe any AOC/AAC contract over AeroMACS SHOULD be accepted on NAP and NSP networks for ATC only service provision NOTE: Authentication procedures need to be supported to enable authorization of such services by the ATC service provider to any aircraft that has been authenticated in the Home NSP. All ground networks SHALL advertise to the mobile subscribers the types of service it can provide: ATC, AOC and airport operation. Types of service information advertised by the mobile subscriber SHOULD be updated depending on real-time status of connectivity. All NAP and NSP SHALL have the same authentication mechanism and logon process for aircraft.

31 Functional architecture The Network Reference Model (NRM) addressed in section 2.1, based on WiMAX Forum NWG documentation [23], depicts the normative use of protocols, interfaces (commonly named reference points) and functional entities, and is valid to support the integration of AeroMACS datalink within the backbone and give the corresponding service support. The overall principles followed to specify AeroMACS functional architecture are: Functional decomposition: The proposed architecture allows that required features are decomposed into functional entities. The reference points are means to provide multivendor interoperability. AeroMACS BS multivendor interoperability will be described in section 9.1. For interoperability purposes, special care must be paid to the reference points R1 and R6 of the ASN reference model. Intra ASN mobility will imply full support of R6 control messages Modularity and flexibility: The modularity of the architecture proposed gives means to adapt it to different AeroMACS deployments and the interconnection to the ground infrastructure. As an example, the interconnection of different CSN topologies with just one single access network is permitted. The architecture also eases the scalability of the network in case after initial deployment the number of BSs installed within the airport needs to be increased in order to support more users. Decoupling the access and connectivity services: This architecture enables full mobility with end-to-end QoS and security support making the IP connectivity network independent from AeroMACS radio specification and full PHY/MAC standard. In consequence, this allows for unbundling of access infrastructure from IP connectivity services. Support to a variety of business models: AeroMACS architecture supports the sharing of different aviation business models. The architecture allows a logical separation between the network access provider (NAP), the entity that owns and/or operates the access network, the network service provider (NSP) and the application service providers (ASP). It is expected to have just one single ASN-GW deployed in the airport domain. While one ASN-GW is generally used, there may be implementations with more than one single ASN-GW in the ASN. The reference points can represent a set of protocols to give control and provide management support on the bearer plane. On an overall hypothetic deployment, functional entities here depicted could be matched to more than one physical device. In a similar manner, most of the reference points are left open. The architecture does not preclude different vendor implementations based on different decompositions or combinations of functional entities as long as the exposed interfaces comply with the procedures and protocols specified by WiMAX Forum NWG for the relevant reference points Business entities (NAP, V-NSP, H-NSP) Aviation business model and hence contractual agreements between parties can have an impact on the network topology that supports AeroMACS service provision. Figure 7 depicts the overall contractual case and entities involved on behalf of provisioning services to the subscribers. AeroMACS architecture supports the discovery and selection of one or more accessible NSPs by a subscriber.

32 30 Figure 7: Overall relations between AeroMACS business entities [10] The NAP is the entity that owns and operates the access network providing the radio access infrastructure to one or more NSPs. Correspondingly; the NSP is the entity that owns the subscriber and provides it with IP connectivity and services by using the ASN infrastructure provided by one or more NAPs. A NSP can be attributed as home or visited from the subscriber s point of view. A home NSP maintains service level agreements (SLA), authenticates, authorizes, and charges subscribers. A home NSP can settle roaming agreements with other NSPs, which are called visited NSPs and are responsible to provide some or all subscribed services to the roaming users. Within the aeronautical environment, the following actors could make use of AeroMACS business entities: ANSP (Air Navigation Service Provider) Airport telco operator Airline ACSP (Aeronautical Communication Service Provider), e.g. AVICOM, SITA, ARINC, ADCC New/other global CSP (Communication - Mobility Service Providers) A summary of NAP/V-NSP/H-NSP services and possible actors is depicted in Table 1 below. It is assumed that aircraft mobility will be managed by a central Mobility Service Provider (ACSP or CSP) (ARINC, SITA, others) acting as the H-NSP for aircraft. Table 1: Possible actors for NAP/V-NSP/H-NSP functions Airport telco operator ANSP ACSP CSP Airline NAP x x x x V-NSP x x x x x H-NSP x (for vehicles) x x x x

33 Network entities A foreseeable layout of the AeroMACS network entities is depicted in Figure 8. The functional network entities described here are: Mobile Subscriber (MS), Base Station (BS), ASN Gateway (ASN-GW, comprising DHCP relay, AAA client and FA functions), AAA proxy/server, Home Agent (HA), airborne router (AR) and end systems. Figure 8 presents an example of a high-level functional architecture to support communication with ground vehicles (airport operation) and aircraft (ATC, AOC). In such a case, at the airport, in addition to AeroMACS specific systems (base stations and ASN gateway) AAA server and DHCP server need to be deployed to enable communication with airport vehicles. The airport operator network would thus act as home network for airport vehicles. For ATC and AOC service provision, the airport network would act as visited network, the home network being implemented at regional or global scale for aircraft. The Airport AAA server would thus act as AAA proxy for aircraft relaying authentication and authorization request from the ASN gateway to the Mobility Service Provider (MSP). The MSP is the administrative authority that can operate one or more Home Agents (HA) [12]. Regarding IP connectivity, it is possible that IP addresses will be assigned directly by an H-NSP entity such as the AAA server or a global DHCP. However, the most likely case is that an IP address will be assigned locally to the MS and, in the case of an aircraft with a permanent home address, it will be announced to the network. The ASN gateway would also relay DHCP request to the Aircraft Home network DHCP server. For global connectivity and mobility support, the ASN will rely on a HA operated by an MSP.

34 32 Figure 8: AeroMACS network entities As previously stated, WiMAX Forum NWG has depicted the overall architecture that could support AeroMACS ASN [22]. However, it remains very generic. The open issues not addressed in the literature related to the functional role of required network entities in the aeronautical service network are addressed below. Mobile Station (MS) and Base Station (BS) The MS and BS are specific AeroMACS entities that manage the user and control planes of the physical and medium access layers of the subscriber node and the access network, respectively. Their functions are fully described by IEEE standard [39]. End system Corresponding to IPS host as defined in ICAO 9896 [12], it is the node to which IP packets are explicitly addressed, and acts as an application data origin or destination for its respective domain (ATS or AOC). On-board end systems communicate with end systems on the ground. On-board end systems are directly or indirectly connected to the airborne router (usually running as an application client) or lay in the ground network to which an ASN-GW provides a data path (usually running as an application server). Airborne router The airborne router contains the on-board routing function. It is in charge of route discovery, signalling and policy-based routing configuration. It can support multihoming, in which case it can send and receive packets over different radio interfaces and access networks including AeroMACS. Refer to section 2.6 for the different airborne configuration options. The Airborne Router can also support mobility management functions if performing as a Mobile Router for the on-board end systems applications, as envisaged in [12]. ASN Gateway The main actor on the network topology is the ASN Gateway (ASN-GW), on which rely most of the management and control procedures to support the data link and its interconnection with the backbone. Moreover, the ASN-GW deals with interoperability between AeroMACS manufacturers as well. Figure 9 summarizes the functions attributable to the ASN-GW. One single ASN-GW is expected to be deployed per airport domain. As depicted, main interfaces for the ASN-GW are R6 which connects it to the BSs and R3 which deals with the interconnection to the CSN.

35 33 Figure 9: Main Functionalities of AeroMACS ASN-GW [10] According to AeroMACS Network Architecture Reference Model specified in [4], a generic ASN-GW covers the features/functionalities here drawn. AeroMACS layer 2 (L2) connectivity with MS. Relay functionality for establishing IP connectivity between the MS and the CSN. Network discovery and selection of the AeroMACS subscriber s preferred NSP. Subscriber IP address allocation by querying the DHCP server for network establishment and DHCP DISCOVER messages forwarding. IP forwarding to/from the backhaul via MIP Foreign Agent (FA). In case of supporting IPv6, the ASN-GW SHALL implement Access Router (AR) functionality. Note that this is a CSN function and does not necessarily have to be part of the ASN-GW functions, in which case it may deviate from the reference WiMAX Forum Profile C configuration. Several options for the location of the FA/AR are envisaged, namely: a) physically inside the ASN-GW equipment (as in Profile C) and dedicated to mobility functions only for the MSs in the ASN, b) as a separate entity in the local airport network and dedicated to mobility functions only for the MSs in the ASN, c) as a separate entity in the local airport network and able to mobility functions for any node in the local network, including one or more AeroMACS ASN and other IP end nodes. The FA/AR will not, in any case, operate to provide IP connectivity and mobility functions to other data links other than AeroMACS. Connection Admission Control to ensure service quality and different grades of service commitment and provision. AAA proxy/client. AeroMACS ASN-GW SHALL trigger the exchange of susceptible subscriber information and transfer AAA messages of AeroMACS

36 34 subscriber s Visited NSP for authentication, authorization and accounting to the Home NSP. Context management. Transfer of subscriber credentials (it can store user s profiles or just cache them). Consequently, key distribution between entities. User profile management. After the authorization phase and key exchange, the user profile is handled in order to create corresponding SFs. Data Path establishment and Service Flow Authorization (SFA), CID mapping for control messages. GRE tunnelling SHALL be set to the BSs. ASN-GW creates one data path per SF. Every SF has each different GRE key value. Mobility management and handover control. Some of the most common functions that can be found on a COTS ASN-GW MAY be used but are not required for AeroMACS such as: Radio Resource Management (RRM) is left optional and therefore opened to specific implementations in the future. Paging needed as stated in the profile [51] Load balancing policy. Multicast/Broadcast Control Module (MBS). Location registration. This is left open to AeroMACS deployments and future implementations. An issue to address is how incoming IP packets to AeroMACS from the backbone are managed: IP packets coming from ATS applications SHALL make use of the IP header field DSCP whether they are IPv4 or IPv6 packets (in case of IPv4, it matches with the ToS field of the header. NOTE: On the other hand, IPv6 packets have the DSCP value within the Traffic Class field of the header.). Either ASN-GW or the Access Router SHALL not drop IP packets with a DSCP field distinct from zero. IP packets SHALL be queued in case of congestion and according to the different priorities (RFC 4594 gives a recommendation on service categorization). NOTE: This entity will then read the IP header, maps it to an AeroMACS MAC QoS class and through means of GRE tunnelling, convey that packet to the specific BS to which the MS is attached. AAA proxy/server The AeroMACS CSN of the home NSP SHALL distribute the subscriber s profile to the NAP directly or via the visited NSP. NOTE: One of the main roles of AAA server within the CSN is gathering the access information of all AeroMACS users. NOTE: While local users (handling vehicles) will be managed by a local airport AAA server via the ASN-GW, the most foreseeable scenario is one AAA proxy from the airport operator that sends queries and requests to a global database with all the aircraft operated by the H-NSP that will manage airborne user authentication and policy function (PF). AAA proxy covers the following functionalities: Support roaming when required in case MS connects to V-NSP Simplifies connection to several CSN Security capability allows for logging in of MS locally (e.g. by an ANSP) DHCP server The DHCP server resides in the CSN operated by the Visited or Home NSP. IP address assignment will be done after the MS has performed full network entry. The IP address allocated to an MS MAY be public or private. The IP address allocated to a MS MAY either be a point-of-attachment IP address or an inner-tunnel IP address, according to WiMAX Forum specification [22].

37 35 NOTE: For the basic-connectivity IP service, the IP address is assigned by the CSN. For IP services accessible over an inner-tunnel, the network that terminates the tunnel allocates the IP addresses. Finally the IP allocation for surface vehicles can be done through a local IP pool in order to give dynamically IPs to them. IP mobility It is foreseen that global IPv6 addresses will be assigned to specific aircraft or onboard data link equipment such as AeroMACS. This can be done via static IPs or dynamically via Mobile IP mechanisms. The support of dynamic IP allocation (DHCP) and roaming for aircraft needs the support of global IP mobility and contractual agreements between NSPs or NAPs in order to allow the global identification and operation of airborne devices. Subscriber and HA implement Mobile IPv6 as specified in ICAO Doc 9896 [12]. According to [12], an ATN/IPS MSPs operates one or more home agents (HAs) A Home Agent (HA) SHALL be required at the home network. A secure communication path (e.g. private network tunnel) between ASN-GW to the NSP HA SHALL be required. NOTE: In the visited network, Foreign Agent (FA) or Access Router (AR) stores information of aircraft visiting the network, gives a local IP to the visiting aircrafts and advertises the so called care of address to the HA in order to allow re-routing of AeroMACS datagrams addressed to the MS in the Access Network where it is currently attached. The redirection of an incoming packet to the home network from the visited network where the aircraft is currently in is done through a tunnel established between HA and FA or AR. To complete the support of a moving aircraft into a visited ASN, the MSs SHALL integrate a MIP client. NOTE: MIP suffers from several drawbacks. The main concern would be the big delay that tunnelling between HA and FA/AR introduces. Especially sensitive applications, such as real time, would be affected by this. See Section 2.5 Deployment Models for suggested solutions to optimize routes in a MIP architecture. HA location could vary in a real scenario and can be centralized or decentralized. On the opposite, AAA is expected to act as a proxy only in the V-NSP. This foreseeable scenario is depicted in Figure 10.

38 36 Figure 10: AeroMACS AAA and HA Deployment Scenario AAA framework By default, the IETF RADIUS protocol is supported as the main protocol for AAA purposes. This is an application level protocol, client/server specifically. Therefore: The ASN-GW SHOULD support and implement a RADIUS client. NOTE: BSs are not end-points in RADIUS and therefore are not implementing the RADIUS protocol. PKMv2 will rely on the fact that in AeroMACS user (subscriber) authentication is required. EAP-TLS framework is the defined suite to give support to user authentication. The aircraft router will use X509 certificates for EAP-TLS authentication, using as C/N (Common Name) realm possibly the airline name (as network domains are currently defined by ICAO), or any PKI provider name. The H-NSP AAA server will receive authentication traffic with username realm possibly being the airline this means that the airport Proxy AAA will need to map the realm value with the H-NSP AAA address. Basic and primary connections, which carry management messages, do not cipher, nor authenticate messages. Transport connections can be handled independently and be assigned security associations (SA). SA associates key material and connection, i.e. every CID is mapped to a SAID if it supports security. Every MS must be able to support at least 2 transport SAs according to WiMAX Forum. SAID is updated in the MS by the target BS during handover. Every MS establishes a primary SA with the BS. The rest of SAs are static as they are provisioned by the BS. If a pair BS/MS has no authorization policy, there is no related SA. From the Access Service Network side, the ASN-GW acts as the end-point of the authentication communication flow. In case the ASN-GW hosts the user database, it plays the role of the AeroMACS authenticator. In the case it doesn t, it works as a relay, as a AAA client that forwards queries to the AAA server or the user data base. As previously said ASN-GW makes use of RADIUS protocol to support EAP for either user authentication or service authorization. AAA server is also in charge of checking

39 37 the QoS policy for a given MS and consequently creating a Service Flow Authorization (SFA) as a response to a service flow initiation request from the MS. AAA servers will depend on the core network managed by the service provider. AAA server databases could belong to the Visited Network of each airport; they could belong to the same virtual segment of network as AeroMACS or be held remotely in a different facility of the operator and therefore in another network (namely, the Home Network). IPsec support for the transport of all connections is envisaged. Moreover, the use of VPN tunnelling is encouraged to secure all the connections to the remote elements of the backbone of the network Addressing concept According to ICAO Doc 9896, mobile and fixed nodes make use of IPv6 address structure when communicating over the ATN/IPS [12]. Each ATN/IPS Administrative Domain will require developing an IPv6 addressing plan with a unique address prefix. It is also assumed that local airport users communicate over the ATN network. IETF IPv6 architecture mandates the use of the lower 64 bits of a 128-bit IPv6 address to be used as interface address. This means the upper 64 bits are available to be used as prefixes. Mobility Service Providers (MSP) use the IPv6 address structure in Figure 11 for aircraft assignments. Figure 11: ICAO 9896 IPS addressing structure for aircraft assignments [12] It is noted in [12] that an MSP in the ATN/IPS is an instance of an administrative domain which may be an ACSP, ANSP, airline, airport authority, government or other aviation organization. In addition, each aircraft constitutes a /56 IPv6 end site, which is based on the ICAO 24-bit aircraft address as defined in Annex 10, Volume III, Part I, Appendix to Chapter 9. Furthermore, for onboard services such as ATS and AOC, an aircraft may have either multiple subnets interconnected to a mobile router, multiple MSPs or a combination of both. The segregation between vehicle and aircraft subscribers SHOULD be ensured through the use of different IP ranges in the airport network. NOTE: For safety reasons, this allows the distinction between both types of user by the network and guarantees the possibility to apply different authentication policies. The specific use of IP ranges in an airport network is implementation dependent. Comentado [ACU1]: Nikos to confirm Network entry and NAP/NSP selection Several considerations on the NAP and NSP selection by the MS are given in this section, based on the permitted profile items, WiMAX Forum specifications and deployment models from [48]. Manual or automatic selection is left as an open issue. Overview of network entry An aircraft MS network entry process is as follows: During the scanning process the aircraft needs to be able to determine if it is on a channel of a NAP providing aircraft communication services If the NAP is providing aircraft communication services, the aircraft can either check that its H-NSP is connected or decide to authenticate directly

40 38 If the authentication is successful, it means that the NAP/V-NSP is able to contact the H-NSP. Then the MS can perform NET entry and be allocated a CoA (Care Of Address). MS establishes MIP tunnel to H-NSP Home Agent MS can then be contacted using its Home IP address through the Home Agent at H-NSP In the case of an airport handling vehicle, the node is attached to the local network, and thus the network entry process is largely simplified: During the scanning process the device needs to be able to determine if it is on a channel of a NAP providing airport services. The H-NSP is based locally so the device can perform authentication directly. If authentication is successful, the MS performs NET entry and the H-NSP grants the device a local IP address. Overview of WiMAX Forum description AeroMACS profile allows two discovery procedures: A) NAP discovery gives means to the MS, after scanning and decoding the operator ID element for DL_MAP, to select which BS of a particular operator to connect. This is a very unlikely scenario since the deployment of different AeroMACS access networks will lead to increase the interference to non-aeromacs systems. B) NSP discovery is mandatory in the profile. The MS will dynamically discover all NSPs in the airport during the Network entry procedure. In order to accomplish that, the MS will be listening to the broadcast message with the NSP IDs sent by the BSs (SII-ADV MAC message advertisement). Therfroe: A MS SHOULD have a list of NSPs loaded in its configuration. Please refer to section 4.1 of [32] for a detailed description of NET entry discovery and selection. The most significant 24 bits (MSB 24 bits) of the Base Station ID SHALL be used as Operator ID, which is the NAP Identifier. NOTE: NAP discovery is based on the procedures defined in IEEE standard [39] and out of the scope of this specification. Operator ID/NAP ID allocation and administration method are managed by IEEE Registration authority, which defines the range for global IDs assigned by IEEE and the range for MCC/MNC IDs which can also be used. The field formatting is defined in IEEE standard. In the NAP+NSP deployment case where there is only one NSP associated with the NAP and where no regulatory or deployment reasons compel separate presentation of an NSP identifier, the NAP SHALL set NSP Identifier Flag to a value of 0. NOTE: In this case, when the MS detects the identifier of a NAP, the MS knows the identifier of associated NSP. The MS MAY continue NSP discovery to obtain verbose NSP name of the NSP. NSP ID is formatted as a 24-bit field that follows the format shown in Table 2.

41 39 Table 2: NSP ID format [32] Comentado [schlereth2]: Please get rid of Table In the authentication process described in section of [32], the MS MAY format the NAI (Network Access Identifier) used as an outer identity during EAP exchanges as follows:<routing realms><wimax where: Routing realms: Optionally used. The use of routing realm is described by RFC Example: WiMAX decoration: Optionally used to indicate various MS capability/intent. The WiMAX decoration is extensible. The WiMAX decoration consists of one or more attribute value pairs (avp) separated by the enclosed within curly braces. { avp1 avp2. } where an avp is formatted as: name = value with no spaces before and immediately after the =. The character set used for name and value must be consistent with the character set specified by RFC The name must be alphanumeric with no spaces. Example: {fm=1 xm=3}joe@hnsp.com. Currently there is no specific avp defined. When an aircraft (MS) lands and scans the AeroMACS band, it SHALL select a NAP, and then the NSP. NOTE 1: The way/order in which the channels are scanned and the way the preferred NAP is selected are implementation-dependent. The NAP (operator) selection can rely on the following criteria: Preferred operator (if commercial) NSP support (especially the ability to support ATC flows and other needed flows, AOC at least) NOTE 2: The procedure for NAP selection can be as follows: 1. Select a NAP who is providing Aircraft connectivity 2. Select a NAP who is contracted (might not be compulsory for ATC traffic only) 3. Select the preferred NAP if several are possible (based on airline preferences) 4. Select a NAP who can provide ATC connectivity up to H-NSP 5. Select a NAP who can authenticate the aircraft (by relaying the AAA requests to the H-NSP)

42 40 The previous procedure can be satisfied either by a) analysing the Operator ID (that would be encoded in a specific way), or b) pre-determining channel values/operator IDs in a local aircraft configuration file, or c) analysing the NSP IDs supported by the NAP and select the NAP depending on the NSP ID. It is proposed to define a way to encode the Operator IDs in order to identify ICAO and aircraft-connectivity operators - same proposal for NSP ID (however, it might be difficult to get a range of IDs from IEEE). The MS will need anyway to have locally allowed Operator ID values, allowed channels depending on the location, H-NSP ID and associated realm. The MS can use the H-NSP realm as <routing realm> in authentication process. The ASN can use the H-NSP realm as <routing realm> to route to the proper NSP. The procedures articulated in this note are guidelines for the implementation of NAP/NSP selection algorithms. However, since they are not standardized, the final solution relies on the decision made at system deployment. 2.4 Airport network infrastructure AeroMACS system has to be connected to a network providing ATC and AOC services. From a general point of view, ATC airport network is a combination of several LANs dedicated to data (radar, supervision) and voice (VoIP) which are interconnected via one (or more redundant) router(s). ATC airport network is usually interconnected to the ANSP national network. The AOC network is usually accessible through a CSN. The next sub-section provides as an example deployment of a hypothetical AeroMACS implementation at Barajas Madrid airport, which has been studied for SESAR validation work on AeroMACS. The way AeroMACS network is integrated within airport network depends on the deployment solution Barajas airport network topology A general overview of Barajas airport is shown in Figure 12, in which we can find four terminals; T1, T2, T3, T4 and one satellite terminal; T4S. In order to have an overall idea of Barajas airport dimensions, distances between terminals are included. The most relevant control buildings are also shown; Airport Operation Control Centre, West and North Control Towers located at Terminal 4 and Satellite Terminal 4, and also the South Tower located at Terminal 2.

43 41 Figure 12: Barajas terminal map overview The next paragraphs describe a general overview of the networks deployed at Barajas airport, which could provide the necessary means for the integration of AeroMACS network. Although this subsection is focused only on Barajas airport, general guidelines are listed. Nevertheless, each deployment will need a particular study for the integration solution. Multiservice Airport Network (MAN) The multiservice airport network offers more than access ports and network access equipment is deployed all over the airport (see Figure 13). It is composed of three main networks extending over the terminals (T1-T2-T3, T4 and T4-S) and one more covering the Airport Data Process Centre. All these networks are integrated through a MPLS Core which could manage 40 Gbits/s. The multiservice airport network supports the connectivity with traditional ACSP (e.g. SITA, ARINC...).

44 42 Figure 13: Barajas Multiservice Airport Network Topology The infrastructure provided by the multiservice airport network supplies logical and physical redundancy (network access equipment duplicated) just in Control Towers and Data Process Centre due to its high relevance. Network access equipment supports the integration of AeroMACS system (ASN-GW, BS ) in accordance with Ethernet Standards supporting data services up to 100 Mbps with UTP cabling. The network access locations are situated mainly near airport terminals. It is assumed that some BSs could be deployed just in airport facilities with network access equipment. On the other hand and especially for BSs deployed near runways it is likely that no equipment is available so it would be necessary to make a study in order to reach the network access equipment through e.g. optical fibre infrastructure situated near the BS location. Air Navigation Data Network (ANDN) Barajas ANDN consists of a primary node located at Tower-N, which provides connectivity to all air navigation elements. Secondary nodes, which are connected to the primary one, are located in Tower-S and Tower-N, and outside the airport there is another access point at AENA headquarters (situated few kilometres away from the airport). The Air Navigation Data Network supports the connectivity with traditional ACSP (e.g. SITA, ARINC...). In order to achieve the integration of AeroMACS system in ANDN, apart from the airport infrastructure, there are two main cabling infrastructures deployed at Barajas airport by the Air Navigation Service Provider. The first one is comprised of two optical fibre rings deployed around the four runways which connect the radio navigation aids to the ANDN nodes at Tower-S and Tower-N, although Tower-W is also connected to the ring through twisted pair and optical fibre cabling. Figure 14 depicts it.

45 43 Figure 14: Barajas radio navigation aids cabling infrastructure Circles and squares represent radio navigation aids locations with infrastructure available (optical fibre or twisted pair cable) to connect BSs to air navigation data network nodes. As we can see in the figure above, the number of sites is limited so in many cases, where the BS is far from this infrastructure access points, it will be necessary to deploy the physical communication means between the BS and the connectivity access point. Once the BS reaches the access point (e.g. GP 18L) it may be integrated in the ANDN (E1, E2 interface) or it may make use of the available cabling (e.g. free pairs of optical fibre) or in the last case it could be necessary to install proper physical communication means. The second one consists of four optical fibre rings deployed around the airport for the multi-lateration system (MLAT). As we can see in Figure 15 below (circles represent MLAT stations), the deployment of MLAT system offers High density of sites with infrastructure available to install BSs near terminals (RAMP area). Medium density of sites with infrastructure available to install BSs near runways (GROUND and TOWER areas). Due to the high number of MLAT sites deployed, it is likely that BSs would be placed in these locations, so it would not be necessary to deploy a proper communication means between the BS and the access point to the infrastructure. In the case of MLAT network, AeroMACS system could take advantage just from the cabling infrastructure and it is not likely that AeroMACS system will be integrated in the MLAT network.

46 44 Figure 15: Barajas MLAT system cabling infrastructure 2.5 Deployment models NSP & NAP deployment models This section describes the foreseen deployments of NSP and NAP in an AeroMACS network. Source is [48]. The models affect the number of possible NSPs and NAPs serving a given airport (one vs several) and the business model of the potential AeroMACS service providers. NAP sharing by multiple NSP This deployment model for mobile services in aircraft and vehicles proposes the existence of one Access Service Network per airport (owned and/or operated by a single entity) shared by multiple NSPs over a single NAP. It is also the most costeffective solution to have both ATC and AOC services in the aircraft (using a single antenna and MS), and is in line with future ATN/IPS ground/airborne architecture supporting traffic segregation [12]. AeroMACS allows the existence of multiple Network Service Providers for a given airport, and there is a defined method for the selection of the NSP by a given MS upon Network Entry. This deployment model is the preferred solution by NSP and NAP in order to rationalize infrastructure, ease cell planning at a given airport, and minimize interference on legacy systems (e.g. Globalstar) with probably less Base Stations due to a more efficient use of the spectrum.

47 45 H-NSP n H-NSP p R3 R3 NAP Figure 16: Single NAP - Multiple NSP Several CSNs might share the same ASN. The most common deployment expected is one single ASN within the airport and multiple operators (CSNs) connected. This is the most likely business scenario for AeroMACS. The NAP deploys and provides the access network to ARINC, SITA, AVICOM, etc. and manages the relationship with airports on behalf of the airlines. Airlines could act as H-NSP or have contractual agreements with different H-NSP. In this scenario, ASN-GW will advertise for incoming new MSs on the Access Network that there are different NSPs (see section 2.3), enabling the MS to establish data communication to its NSPs through AeroMACS ASN and relaying them to reach the final airline operator. Single NSP Providing Access through Multiple NAPs This deployment model is foreseen by NSP to extend its coverage at regional scale in relying on local NAP (e.g. extension to several airports by one service provider like SITA or ARINC). H-NSP R3 R3 NAP i NAP j Figure 17: Multiple NAP - Single NSP If one NAP cannot provide full coverage for an NSP in a given area, the NSP can have agreements with multiple NAPs. This model is compatible with the previous one, i.e. multiple NAPs can be serviced by multiple NSPs and vice-versa. There is a difference within this model whether the NAPs served by a single NSP are collocated in the same airport or not. In the first case, the deployment option of placing the sensitive servers needed (mainly AAA and DHCP) locally would be possible, and there would be no need to enable VNP end-to-end connectivity, packet forwarding or relay functions, thus simplifying the rollout and operation of the network. In the latter case, connectivity to the global network would be necessary. Greenfield NAP+NSP This deployment model is foreseen for manufacturers and operator since they let flexibility to NSP to act or not as NAP depending on local issues.

48 46 This model is more suitable to CSPs or ACSPs in areas where they will be allowed to act as NAP. A single NSP, corresponding to the same CSP or ACSP, operates the network. H-NSP H-NSP R3 R3 NAP NAP NAP + Home NSP Figure 18: Greenfield NAP-NSP Thus is to say, SITA, ARINC, NAVICOM could be deploying themselves on the airport ground network side acting as the same entity for the NAP and NSP on the business model. An aircraft coming from a different airport will be served by the same H-NSP. Potential deployment scenarios In a number of regions, the AeroMACS license will be acquired by the Aviation Authority and may be granted to ANSPs directly or to Airport telecom entity or subcontracted for operation to a service provider. In other regions, service providers such as ARINC and SITA could be granted a specific AeroMACS channel for AOC and ATC operations. The most likely deployment scenarios are illustrated in Table 3. Table 3: Potential AeroMACS deployment scenarios Use Case N Description Subscriber NAP V-NSP H-NSP Deployment model 1 Local services Fixed Vehicle Airport telco ANSP ACSP Airport telco ANSP ACSP/CSP Airport telco ANSP ACSP/CSP -Greenfield NAP+NSP 2 Safety and non-safety services on same channels (options Fixed Vehicle Airline A/C Airport telco ANSP ACSP Airport telco ANSP ACSP/CSP Airport (vehicle/fixed) ANSP ACSP/CSP telco -NAP sharing by multiple NSPs -One NSP providing access through multiple NAPs A-B-C) 3 Safety services on specific Fixed Vehicle Airport telco Airport telco ANSP Airport (vehicle/fixed) telco -NAP sharing by multiple NSPs

49 47 channels (options A-C) Airline A/C ANSP ACSP ACSP/CSP ANSP ACSP/CSP -One NSP providing access through multiple NAPs Non-safety services on specific channels (options Vehicle Airline A/C Airport telco ACSP Airline Airport telco ACSP/CSP Airline Airport telco (vehicle) ACSP/CSP Airline B-C) 4 Non-safety services in airline hub (options B- C) Vehicle Airline A/C Airport telco ACSP Airline ACSP/CSP Airline ACSP/CSP Airline -One NSP providing access through multiple NAPs -Greenfield NAP+NSP 5 Safety services managed by ANSP (options A- C) Fixed Vehicle Airline A/C ANSP ANSP ANSP -One NSP providing access through multiple NAPs -Greenfield NAP+NSP Roaming scenarios Roaming is the capability of wireless networks via which a wireless subscriber obtains network services using a visited network operator s coverage area. At the most basic level, roaming typically requires the ability to reuse authentication credentials provided/provisioned by the home operator in the visited network, successful user/ms authentication by the home operator, and a mechanism for billing reconciliation and optionally access to services available over the Internet services. In a possible roaming scenario, an aircraft landing on an airport network is managed by a NSP that is different from the aircraft Home NSP (H-NSP), and thus acting as a Visited NSP (V-NSP). Figure 19 shows the entities participating in roaming. Roaming between NSPs SHALL not be precluded. A single NAP MAY serve multiple MSs using different private and public IP domains owned by different NSPs. A visited NSP MAY have roaming contractual relationship with the subscriber s home NSP. NOTE: The AAA framework in this scenario behaves as described in the corresponding section above, with the Visited NSP providing AAA traffic routing to the home AAA server with means to guarantee the confidentiality and safety of the procedure. The local AAA server can act as an AAA proxy when the network entry process of AeroMACS is triggered.

50 48 Figure 19: AeroMACS roaming architecture The second scenario foreseeable is the use of one single AAA server shared by all the NAPs and out of the H-NSPs. As a consequence, no roaming scenario will occur, whereas the risk of failure and the probability of not completing the network entry and the creation of the data path increase. This has been covered within [25]. Depending on the roaming function of the HA, different roaming mechanisms may be used for data access for data access between communication endpoints that reside in networks managed by different NSPs, as depicted in Figure 20 and Figure 21 [49]. Note that, in order to show different attachment examples in the figures, configuration 1 aircraft is attached to the home network (which is a global network managed by an ACSP or other), while configuration 2 aircraft is attached to a visited network (e.g. a local ACSP in an airport or an ANSP network). The following scenarios are deemed relevant for aviation purposes: Data access via home NSP: This is the classic deployment where the H-NSP manages the HA function which establishes the paths between the Mobile Router (MR) behind the MS on the aircraft and the correspondent nodes (CN) in the ATM ground network. As a consequence, the application flow to the end node is relayed from/to the mobile node care-of-address in the foreign network to the HA and later to the CN. Optimized architecture NEMO (Global HAHA), shown in Figure 20, has been assessed both by NEWSKY [65] and SANDRA [33] projects. Data access via correspondent router: This deployment model is foreseen by NSP to let the opportunity for the mobile node to establish an optimized path directly with the correspondent router (CR). This leads to the benefit to optimize performance and have direct access to the CN in the ATM ground network (which can be located in the local access network), rather than having all traffic flowing to a central HA located in a remote location (shown in Figure 21).

51 49 Figure 20: Roaming scenario 1 Data access via Home NSP [49] Figure 21: Roaming scenario 2 Data access via Correspondent Router (CR) [49] Several technical solutions are under definition to handle Route Optimization ( RO with Mobile IP). One option is the Global HAHA (where local Home agents can be deployed as illustrated in Figure 20), the other corresponds to the use of Correspondent Routers (CR) operated locally by ANSPs. In all cases, a global home agent must be accessible permanently.

52 50 SANDRA project concluded that use of CR versus global HAHA was more appropriate to ATM communications.[49] 2.6 AeroMACS Airborne Architecture The potential AeroMACS airborne system architectures are being agreed in the context of the Airlines Electronic Engineering Committee (AEEC). Within AEEC the Systems Interfaces and Architecture Sub Committee (SAI) is responsible to agree on the AeroMACS airborne architectures to be considered and then develop the required avionics standard supporting the considered architectures. Nevertheless, in order to give an idea on how the eventual airborne AeroMACS system architecture might look like, this section summarizes the outcome of the discussions within the SESAR AeroMACS projects P9.16 and P and the EUROCAE WG-82 group. It provides a list of potential airborne AeroMACS system architectures that have been already identified and are proposed for further consideration and discussion in the AEEC SAI group, in the context of the AEEC work for the AeroMACS avionics standard. Additional options are possible and might be further considered in AEEC if they provide advantages and benefits. In order to identify the options for the airborne AeroMACS system architecture, the available material from SESAR project P9.16 has been used as baseline to develop the proposals shown below, which can be considered as potential ways of implementing AeroMACS onboard allowing for having early benefits from an AeroMACS implementation on one hand and outlining the target architecture, which has to be considered on a long term basis as a final step, on the other hand. The following explanations are based on material described in SESAR Project 9.16 document entitled AeroMACS Airborne System Requirements and Architecture Dossier (SRAD) [42] and discussions in the SESAR AeroMACS projects P and P9.16and the EUROCAE WG82 group Foreword on overall Aircraft systems organisation ARINC-664 has defined a formalized organization of the aircraft systems and airborne networks into so-called aircraft domains. Aircraft domains are served by airborne networks and systems with the same requirements for performance, safety and security. In ARINC664P1-1 [61] and ARINC664P5 [62], it is suggested to group the aircraft computing network into four aircraft domains the Aircraft Control Domain (ACD), the Airline Information Services Domain (AISD), the Passenger Information and Entertainment Services Domain (PIESD), and the Passenger Owned Devices Domain (PODD): The Aircraft Control Domain comprises the systems which control the aircraft from the flight deck and the systems for environmental control, smoke detection and slides and doors management. The Airline Information Services Domain provides operational and airline administrative information to the flight deck and the cabin and maintenance services and to support the passengers. The Passenger Information and Entertainment Services Domain provides the inflight entertainment (i.e., video, audio, gaming), passenger flight information, and access to the Intranet and Internet using built-in terminals including related services like Voice over IP, Short Message Service (SMS), and . The Passenger Owned Devices Domain is a network of those devices that passengers are allowed to bring on board to connect to the passenger information and entertainment services or to one another. To ensure the appropriate level of safety and security, these domains are physically separated by appropriate means. Notably, aircraft control systems are separated from other domains. This strong partitioning results in the introduction of constraints and restrictions for the use of the communication systems by the different airborne data link applications. Typically: Radio communication equipment attached to the ACD are today only accessible to data link applications (typically ATC/AOC) located in the ACD,

53 51 Radio communication equipment attached to the other domains are mainly for applications (typically AOC/AAC/APC) located in these domains. ACD applications have very limited access to these communication means (typically, they can be used in the Air-to-ground direction only by ACD applications), NOTE: The satellite data unit (SDU) is currently an exception to the above typical repartition. The SDU is currently shared between and simultaneously attached to the ACD and the other domains. However, this is tolerated through the application of very strict security requirements and security assurance processes on the equipment, notably for what relates to the segregation of the data flux and to the demonstration that the equipment cannot be used as a backdoor gateway in between the domains. It is important to note that the types of applications that are using AeroMACS radio equipment operating the protected (ITU) AM(R)S band are limited to the ones linked to the safety of life (ATC) and regularity of flight (AOC). This implies that applications in the PIESD and PODD domains are not candidates to be supported by AeroMACS and the use of AeroMACS is only relevant to the ACD and AISD domains Assumptions regarding the initial implementation of Airborne AeroMACS systems: It is commonly assumed that first implementations of AeroMACS in airports and on first aircraft could be deployed from 2016 onwards. AeroMACS will be the first ATN/IPS-compatible Future Communication System that is a candidate for the installation on aircraft. Hence, implementation of the AeroMACS in the Aircraft Control Domain (ACD) would need to be coordinated and come concurrently with other evolutions, such as: 1) An ATN/IPS router will need to be concurrently developed and certified, 2) Security issues pertaining to the interconnection of the ACD with external IP networks will have to be addressed. This can necessitate the development of specific security systems (e.g. firewall/proxy applications), 3) Adaptations at the level of the Airborne ATC applications and/or of the ACARS/ATN router will be needed to allow ATC communications though the AeroMACS. 4) Adaptations at the level of current AOC applications in the ACD will be needed to allow air/ground communications of these application though AeroMACS, 5) Cockpit HMI (Radio Management Panels, Flight Warning) and transverse functions (Central Maintenance System, Configuration Control Systems,..) will be impacted. Given the significant amount of developments that might then be necessary, the introduction of the AeroMACS technology as a first ATN/IPS compatible communication system in the ACD could be very challenging from a technical and business case standpoint. Based on this consideration, six scenarios covering nearterm to mid and long-term perspectives as well as support of different services have been identified. These scenarios are detailed in the sections below Scenario 1-A Near term Initial installation of the AeroMACS MS in the AISD domains : Scenario 1-A assumes that with a near term perspective, an AeroMACS MS could be initially introduced as an additional communication media of the AISD domain, attached to the existing AISD Open IP router, as a complement or alternative technology to the current or coming gatelink technologies (WIFI/GSM/GPRS/EDGE/UMTS/LTE/WIMAX...), Following this scenario, the AeroMACS system could be implemented as a standalone equipment similar to current TWLU equipment, or could be integrated (added) within the current gatelink communication equipment.

54 52 Aircraft Control Domain (ACD) Airline Information Services Domain (AISD) (PIESD) FANS A/B (or C) ATC Applications AOC Applications in ACD AOC Applications in AISD ACARS + ATN Router OpenIP Router (PODD) VHF system HF system SATCOM system Aeromacs system Gatelink system (Wifi / Cellular) Figure 22: AeroMACS system integration on A/C Scenario 1-A Scenario 1-B Near-medium term Initial installation of the AeroMACS MS in the ACD domains : Scenario 1-B assumes, in the short-medium term, the availability of an AeroMACS MS connected to the AISD domain but designed and pre-installed to be hosted in the ACD Domain in preparation of the longer term scenario 3A/B described farther below. In terms of initial capabilities and supported services this AeroMACS MS is the same as the one shown in Scenario 1-A. The difference with Scenario 1-A is that a Scenario 1- B AeroMACS equipment would be designed and possibly pre-installed to be directly interfaced with the ACD airborne network and with peripheral ACD avionics systems. In particular, a Scenario 1-B AeroMACS equipment could be designed with the physical Inputs/Outputs modules (e.g. ARINC 429, AFDX ) necessary to interface with the ACD systems generally involved in the monitoring, control, and maintenance of ACD radio communication systems (e.g. to support possible interfaces with an ACD Radio Management Panel (RMP) or Multi Purpose Display Unit (MCDU), with the Failure Warning Computer (FWC), with the Aircraft Centralized Maintenance System (CMS), and Data Loading and Configuration System, etc ). The equipment would also be designed with provisions to support an interface with the future ATN/IPS router envisioned to be installed in the ACD at a longer term.

55 53 Aircraft Control Domain (ACD) Airline Information Services Domain (AISD) (PIESD) FANS A/B (or C) ATC Applications AOC Applications in ACD AOC Applications in AISD ACARS + ATN Router OpenIP Router (PODD) VHF system HF system SATCOM system Aeromacs system Gatelink system (Wifi / Cellular) Figure 23: AeroMACS system integration on A/C Scenario 1-B Scenario 2-A medium term Initial installation of the AeroMACS MS in the ACD domain : Scenario 2-A assumes that with a medium term perspective, the AeroMACS MS could be initially developed and certified as a more global equipment, providing in the same box the following capabilities: 1) the AeroMACS MS functions, 2) an initial IP router function, 3) a (optional) security function at IP Level, 4) a function allowing the encapsulation of ACARS messages over IP (and AeroMACS) and possibly 5) a function allowing the encapsulation of ATN/OSI messages over IP (and AeroMACS). AeroMACS System Security assures secure Air to Ground and Ground to Air MS-BS communications, implementing authentication (PKMv2), data encryption (AES) and integrity check. On top of this AeroMACS security framework the AeroMACS Box can optionally implement a security capability at IP level (e.g. IPSEC) to improve privacy and integrity of communications. An (optional) Firewall capability, to improve segregation of the ACD domain from the outside IP world, can be also added.

56 54 ACARS + ATN Router OpenIP Router Figure 24: AeroMACS system integration on A/C Scenario 2-A Scenario 2-B medium term installation of the AeroMACS MS in both the ACD and AISD domains In the medium term, the AeroMACS Box onboard could simultaneously be connected to the ACD and the AISD Domains, thanks to its capability to guarantee the needed segregation among ACD and AISD users. This approach is very similar to solutions currently envisaged for easing introduction of/transition to new IP-based satellite communication services in the ACD (Iridium and Inmarsat-SBB). ACARS + ATN Router OpenIP Router

57 55 Figure 25: AeroMACS system integration on A/C Scenario 2-B Being AeroMACS a native-ip system, it would be connected directly to the AISD OpenIP Router. Instead, the connectivity with the ACD COTS ACARS+ATN Router depicted in Figure 25 would be guaranteed by an appropriate SubNetwork Dependent Convergence Function Layer. A similar solution has been already tested and validated under the SANDRA Project [33], allowing interoperability between AeroMACS MSs and COTS ATN/OSI Routers. See Figure 26. A security capability, on top AeroMACS security framework, is expected to be implemented at IP level. The AeroMACS Box security capabilities include: Data Authentication, Cyphering and Integrity check functions, to improve privacy and integrity of communications. A Firewall function to segregate the ACD from the AISD domain, avoiding the Open IP world to access directly to the ACD Domain It has to be noted that the needed Security Requirements to be guaranteed by this Scenario increase the complexity of the AeroMACS MS, providing however the advantage of having a single MS connecting both ACD and AISD Users. ACD ACARS + ATN Router AISD OpenIP Router ATN/OSI Traffic IP Traffic IP -SNDCF ACD User AISD User AeroMACS Terminal SFs SFs Figure 26: Scenario 2-B: connection between AeroMACS and ACD/AISD Scenario 3-A Longer term installation of the AeroMACS MS in the ACD domain Scenario 3-A assumes that in a longer term, when Aircraft will be equipped with ATN/IPS router in the ACD domain, the AeroMACS MS will be developed as a certified (Lev. D) radio-communication system of the ACD domain, attached to the ATN/IPS router.

58 56 Aircraft Control Domain (ACD) Airline Information Services Domain (AISD) (PIESD) FANS A/B (or C) ATC Applications AOC Applications in ACD AOC Applications in AISD ACARS ACARS + ATN Router Routeur AeroIP Routeur Router OpenIP Routeur Router (PODD) VHF system HF system SATCOM system Aeromacs system future SATCOM System (Ka) Extended WACS (Wifi/GSM/ 4G+) Figure 27: AeroMACS system integration on A/C Scenario 3-A Scenario 3-B Longer term installation of the AeroMACS MS in both the ACD and AISD domains Scenario 3-B assumes that in a longer term, when Aircraft will be equipped with ATN/IPS router in the ACD domain, the AeroMACS MS will be developed as a certified (lev. D) radio-communication system of the ACD domain, attached to both the ATN/IPS router and the AISD Open IP router. The needed segregation between ACD and AISD users will be granted by the AeroMACS system and, by IP level security capabilities (as explained in the scenario 2-B) implemented between the ATN/IPS (referred to as AeroIP) and OpenIP routers (outside the AeroMACS MS onboard system). See Figure 28 and Figure 29. Aircraft Control Domain (ACD) Airline Information Services Domain (AISD) (PIESD) FANS A/B (or C) ATC Applications AOC Applications in ACD AOC Applications in AISD ACARS ACARS + ATN Router Routeur AeroIP Routeur Router OpenIP Routeur Router (PODD) VHF system HF system SATCOM system Aeromacs system future SATCOM System (Ka) Extended WACS (Wifi/GSM/ 4G+)

59 57 Figure 28: AeroMACS system integration on A/C Scenario 3-B AeroIP Router OpenIP Router Figure 29: Scenario 3-B: connection between AeroMACS and ACD/AISD The above scenarios define different strategies for implementing an AeroMACS System on aircraft, which would lead to the definition of different airborne AeroMACS System architectures. It is worth underlying that possible combinations of the above Scenarios could also be envisaged. For instance, the possibility to implement both Scenarios 1-A and 3-A, in the Long Term cannot be precluded. This scenario could allow using 2 separated AeroMACS MS devices onboard, using a single antenna thanks to the appropriate branching system. This solution would grant a physical segregation between ACD and AISD domains. See Figure 30.

60 58 AeroIP Router OpenIP Router Figure 30: Physical Segregation between ACD and AISD

61 59 CHAPTER 3 APPLICATIONS This section covers the list of services to be supported by AeroMACS. Service instantiation for an operational landing, turnaround and take off procedure is provided. The description is the basis for simulation results outlined in One step further, QoS figures, continuity, integrity and availability have been proposed. It foresees several QoS levels to support AeroMACS services. In addition, the mapping between different levels of QoS (application, IP and AeroMACS) has been addressed. 3.1 Operational concept This section aims to refine the Traffic Model for AeroMACS developed in [6] by describing the instantiation of the service sequence in time. This is done by defining the operational use of AeroMACS in the departure and arrival phases in airport surface and mapping the service list to the chronological description of these operations. Previous work carried out in [1], [11] and [28] is taken as a reference. When an aircraft executes its complete operation cycle in an airport, both arrival and departure phases are completed. During a given period between these, the aircraft is in turn-around phase, but this is considered just as a physical status of the aircraft and not an operational phase here since it does not define a separation between arrival and departure. Thus, arrival sequence finishes when all the related services are completed. Departure sequence will not start until the previous arrival is correctly finished. This will happen at an undetermined moment between door opening and closure. All the pre-departure sequence and related services are considered as departure. The figure below depicts the time evolution of the operational phases and events considered in this analysis. Time events establish the start and end of the operation periods. Operation periods are executed in specific operational domains (RAMP, GROUND, TOWER), which can be managed by different type of controllers and, as thus, define a different set of executed ATC/AOC/NET services. Figure 31: Flight phases and events in APT surface Time events are explained below: LDT: Landing Time. Event at which the aircraft wheels touch down the runway. LDT : Landing Time for AeroMACS. It stands for the instant at which the aircraft moves below the maximum speed supported by AeroMACS (50 knots)

62 60 IBT: In-Block Time. Event at which the aircraft stops moving at the stand. DO: Doors Open. Disembark can start, arrival phase can finish. DC: Doors Close. Departure phase has already started, boarding has finished. SUR: Start-up Request. Aircraft is ready to block off, waiting for ATSU permission. SUC: Start-up Clearance. ATSU permission delivered. OBT: Off-Block Time. Event at which the aircraft starts moving off the stand. TOT : Take Off Time for AeroMACS. It stands for the instant at which the aircraft is expected to move over the maximum speed supported by AeroMACS (50 knots) TOT: Take Off Time. Event at which the aircraft wheels off the runway. Time periods are explained below: RIP: Runway-In Period. The aircraft moves within and out of the runway after landing. XIP: Unimpeded Taxiing-In Period. Aircraft moves by its own means from the landing runway to the assigned stand. TAP: Turn Around Period. The aircraft stays at the gate and is serviced for post-arrival and pre-departure operations. PBP: Push-Back Period. The aircraft is moved back by a tug from the stand to a position in which it can proceed to taxiing. XOP: Unimpeded Taxiing-Out Period. Aircraft moves by its own means from the stand to the assigned take-off runway. RHOP: Runway Holding and Out Period. It includes the likely Runway Holding (RHP) plus the runway out movement itself. The services included gather the subset of services from [6] deemed applicable in an operational scenario for the airport surface that is covered by AeroMACS system. The service model has not been limited to those used to guarantee safety of life and regularity of flight, but also operational control services have been included in order to test the technology for the support of this traffic and facilitate the future aggregation of services in the same pipeline. Air Traffic Services (ATS) include Air Traffic Control, Flight Information services and Alerting service. These services are provided by Air Traffic Service Units (ATSUs) performing specific ATS services. Communications, navigation and surveillance on the ground and in the aircraft support these ATS services. The ATS categories applicable to airport surface are the following: Data Communications Management Services (DCM). These involve Data Link Logon and ATC Communication Management. Clearance / Instruction Services (CIS). These involve ATC Clearance, Departure Clearance, Data Link Taxi and Common Trajectory Coordination. Flight Information Services (FIS). These involve Data Link Operational Terminal Information Service, Significant Meteorological Information, Runway Visual Range and Surface Information and Guidance. Flight Position / Intent / Preferences Services (FPS). These involve Surveillance, Flight Plan Consistency and Intent, and Pilot Preferences Downlink. Emergency Information Services (EIS). This involves Data Link Alert. In line with EUROCAE WG78, the services can be categorized as follows: Context Management (CM). The functions of CM are Contact, Logon and Update. CM ground systems can be configured to operate either in their domain of responsibility or for a facility outside their domain. Controller Pilot Data Link Communications (CPDLC). The CPDLC functions required are Controller-pilot message exchange function, transfer of data authority function and downstream clearance function. Automatic Dependent Surveillance (ADS-C). The functions of ADS-C include the following functions: demand, event, periodic, cancel contracts and operation in emergency/urgency mode. The ATSUs are capable of requesting different types of

63 61 contracts, and the aircraft system elements are capable of providing ADS-C reports to support the contract requests. Digital Flight Information Services (D-FIS). Flight Information Services is an ATS application by which the flight crew can retrieve operational data from an ATSU System providing flight information services. These encompass meteorological and various other information which can affect the departure, approach and landing flight phases as well as surface operations. Aeronautical Operational Control (AOC) are services that involve data communication between the aircraft and the AOC centre, company or operational staff at an airport. Legacy AOC (L-AOC). This category contains AOC data communication services that are expected to be in use during Phase 1 and Phase 2 and were listed in COCRv2 [1]. Electronic Flight Bag (EFB). This category includes the services that were not part of the COCRv2 [1] document and are operational or foreseen to be operational in the timeframe. EFB is an electronic information management device that replaces current paper-based flight bag by including and updating electronic manuals and documents, automated calculation and navigation tools. The included services can be categorized as EFB hosted services in 2020, however other implementations of the same service on different platforms are also possible. Sporadic (S) services. These are specific L-AOC or EFB services that have a limited instantiation, i.e. they are executed seldom in a departure/arrival phase (instance probability lower than 10% [6]. They involve software or chart update on the FMS system in the aircraft, action that is executed after a given number of flights, with a subsequent high bandwidth transfer. They will be included in a worst-case scenario in which an aircraft requires a complete update of the system. Network Management (NET). These services are used to establish and maintain connections between each pair of aircraft and ground systems. Potential applications in the operational concept will include in the future the accommodation for SWIM data exchanges that could involve new services or an increase in the data payload transmitted over AeroMACS. These services include full 4D trajectory negotiation, WXXM weather data products (METAR, TAF, NEXRAD, PIREP, Terminal Forecast), and AIXM digital NOTAM. The list below indicates the potential multicast and broadcast services envisaged to be transported over AeroMACS [63]: - Flight Information Services (D-ATIS, D-OTIS, D-RVR, D-SIG, D-SIGMET) - TIS-B - NOTAM - Graphical weather information (WXGRAPH) - Airport delay information - Broadcast weather information via SWIM - SURV Below the list of services executed in an orderly and categorized manner is proposed for the analysis in both phases of study (departure and arrival). This list is the basis to build the per-scenario service model defining the chronological execution. Categorization and chronology will also be used to drive the classification of service model applied to quality of service (QoS) politics. Table 4: Services executed during departure phase Operational domain execution Service Category Application FRS data services [1], [28] Application WG78 ATS services [11] Directionality

64 62 Operational domain execution Service Category Application FRS data services [1], [28] Application WG78 ATS services [11] Directionality NETCONN Network connection NET NET - G A/C NETKEEP Network keep-alive NET NET - G A/C DLL Data Link Logon ATC DCM CM 1 G A/C AOCDLL Airport Operational Center Data Link Logon AOC L-AOC - G A/C LOADSHT Load Sheet Request/Transfer AOC L-AOC - G A/C E-CHARTS e-charts Update AOC EFB (S) - G A/C UPLIB Update Electronic Library AOC L-AOC (S) - G A/C SWCONF Software configuration management AOC EFB - G A/C SWLOAD25 Software Loading (Part 25) AOC EFB (S) - G A/C SWLOAD Software Loading AOC L-AOC (S) - G A/C RAMP BRFCD Aircraft Briefing Cards AOC EFB - G A/C ACLOG Aircraft Technical Log Rectification AOC EFB - G A/C TECHLOG Technical Log Book Update AOC L-AOC - G A/C AIRWORTH Airworthiness Statement AOC EFB - G A/C WXTEXT Textual Weather Report AOC L-AOC - G A/C PASSENGER CREW-RPS Passenger Information List/Manifest Crew rotation/planning/scheduling AOC AOC EFB EFB - - G A/C G A/C CREW-BUL Crew Briefings/Bulletins AOC EFB - G A/C CREW-REG Flight Crew Recency Registration AOC EFB - G A/C FLTPLAN Flight Plan Data AOC L-AOC - G A/C NOTAM Company's Notice to Airmen AOC EFB - G A/C COTRAC (interactive) Common Trajectory Coordination ATC CIS CPDLC G A/C 1 This service is named Data Link Initiation (DLIC) in WG78 documentation [11]

65 63 Operational domain execution Service Category Application FRS data services [1], [28] Application WG78 ATS services [11] Directionality EFF Electronic Flight Folder Exchange AOC EFB - G A/C WXGRAPH Graphical Weather Information AOC L-AOC - G A/C CREW-L Crew list AOC EFB - G A/C HANDLING Handling process Monitoring AOC EFB - G A/C CATERING Catering inventory AOC EFB - G A/C BAGGAGE Baggage Loading AOC EFB - G A/C NOTOC Notice to Captain AOC EFB - G A/C LOADDOC Load documentation Acceptance AOC EFB - G A/C PREFLT-INS Pre-Flight Inspection Signoff AOC EFB - G A/C D-OTIS Data Link Operational Terminal Information Service ATC FIS D-FIS G A/C D-SIGMET Data Link Significant Meteorological Information ATC FIS D-FIS 2 G A/C DOOR Aircraft Door movements AOC EFB - G A/C DCL Departure clearance ATC CIS CPDLC G A/C FLOWCON Flow Control (CTOT & Routing) AOC EFB - G A/C FLIPCY Flight Plan Consistency ATC FPS - G A/C FLIPINT Flight Path Intent ATC FPS - G A/C D-RVR D-SIG EFFU TAKEOFF- CALC Data Link Runway Visual Range Data Link Surface Information and Guidance Electronic Flight Folder Update Takeoff Performance Calculation ATC ATC AOC AOC FIS FIS EFB EFB D-FIS G A/C G A/C G A/C G A/C D-FLUP Data Link Flight Update ATC AVS - G A/C PPD Pilot preferences downlink ATC FPS - G A/C 2 This service is included inside Hazardous Weather service (D-HZWX) in WG78 documentation [11]

66 64 Operational domain execution Service Category Application FRS data services [1], [28] Application WG78 ATS services [11] Directionality D-TAXI Data Link Taxi Clearance ATC CIS CPDLC G A/C OOOI Out-Off-On-In AOC L-AOC - G A/C SURV Air Traffic Control Surveillance ATC FPS ADS-C 3 G A/C GROUND TOWER ACL ATC clearance ATC CIS CPDLC 4 G A/C ACM WXRT ATC Communication Management Real Time Weather Reports for Met Office ATC AOC DCM L-AOC CPDLC - G A/C G A/C OOOI Out-Off-On-In AOC L-AOC - G A/C ACM ATC Communication Management ATC DCM CPDLC G A/C Table 5: Services executed during arrival phase Operational domain execution Service Category Application FRS data services [1], [28] Application WG78 ATS services [11] Directionality OOOI Out-Off-On-In AOC L-AOC - G A/C TOWER GROUND NETKEEP Network keep-alive NET NET - G A/C AUTOLAND- REG Autoland Registration AOC EFB - G A/C ACM ATC Communication Management ATC DCM CPDLC G A/C SURV Air Traffic Control Surveillance ATC FPS ADS-C 5 G A/C ACL ATC clearance ATC CIS CPDLC G A/C D-SIG Data Link Surface Information and Guidance ATC FIS - G A/C D-TAXI Data Link Taxi Clearance ATC CIS CPDLC G A/C EFFU Electronic Flight Folder Update AOC EFB - G A/C FLT- Flight Journal Documentation AOC EFB - G A/C 3 Equivalent to Position Report (PR) in WG78 documentation [11] 4 This service is named Clearence Request and Delivery (CRD) in WG78 documentation [11] 5 Equivalent to Position Report (PR) in WG78 documentation [11]

67 65 Operational domain execution Service Category Application FRS data services [1], [28] Application WG78 ATS services [11] Directionality JOURNAL RAMP TECHLOG Technical Log Book Update AOC L-AOC - G A/C CREW-TIME Flight Deck Duty Time Registration AOC EFB - G A/C OOOI Out-Off-On-In AOC L-AOC - G A/C FOQA Data Transfer (DFDR/QAR bulk data download) AOC EFB - G A/C FLTLOG Flight Log Transfer AOC L-AOC - G A/C CABINLOG Cabin Log AOC L-AOC - G A/C ETS-REPORT REFUEL Post flight report required for ETS (Emissions Trading Scheme) Fuel ordering (Tickets) / Fuel Release AOC AOC EFB EFB - - G A/C G A/C ACM ATC Communication Management ATC DCM CPDLC G A/C 3.2 Service instantiation Not all services in departure phase are executed in every operation. As described in [6] services such as E-CHARTS, UPLIB, SWLOAD and SWLOAD25 are assumed to have a low instance probability and a very high load in channel, so different scenarios need to be simulated. In this previous description, a complete set of possible services is depicted. During operations, some services can be executed simultaneously but others need to wait previous services to have finished thus a chronological order of implementation need to be defined. The latter are defined as sequential services that require a correct finalisation of previous services that represent previous necessary actions that involve the pilot and the ATC or AOC operator. This model is depicted in the figures below. NOTE that surveillance (SURV) service has been included in this hypothetical sequence scenario. Although not a primary use of AeroMACS, the data link can be considered an enabler for message exchange between ground and aircraft that supports ADS-C and ADS-B services. As so, this service will be included and simulated in this analysis in order to test the ability of AeroMACS to provide it.

68 66 Figure 32: Sequential execution of services in arrival Figure 33: Sequential execution of services in departure

69 67 CHAPTER 4 AEROMACS OPERATIONAL REQUIREMENTS 4.1 Operating Altitude 4.2 Coverage This section aims to gather worthwhile information that helps to understand the rationale for system characteristics, operational goals and requirements of AeroMACS data link. An operational requirement is a statement of the operational attributes of a system needed for the effective and/or efficient provision of air traffic services to users. Those attributes include the process of ensuring that safety, performance, and interoperability objectives and requirements for the ATS and operating environment are maintained throughout operations [11]. AeroMACS, as a radio data link aimed for airports, is an enabler to enhance the productivity and safety of ATS by optimizing the involvement of controllers, aircrew, airport and airline operators through integrated data communications, improved forms of surveillance and automation. AeroMACS SHALL support data services (NET, ATC, AOC and Airport Authority Communications). AeroMACS SHOULD support voice services. AeroMACS SHALL be available, exclusively, on the airport surface. AeroMACS operating coverage SHALL extend to full airport area. NOTE 1: The foreseen operational area for AeroMACS spans from terminals (RAMP area) to taxiing zones (GROUND and TOWER). NOTE 2: Coverage area is much related to specific deployment cases. A specific deployment design could be performed attending to different means such as capacity required, number of nodes, path loss constraints, clutter distribution within the airport area (forest, water, buildings ) etc. AeroMACS SHALL guarantee full coverage for more stringent services (like NET and ATC) within the whole operational set of zones. NOTE: Mainly those zones are RAMP area (operational turnaround zones) and taxiways. 4.3 ATS, AOC and Airport Authority support AeroMACS SHALL support all ATC data services related to safety and regularity of flight as encountered at airport surface level. AeroMACS SHALL support all AOC data services related to safety and regularity of flight and as encountered at airport surface level. AeroMACS SHALL support airport vehicles services related to safety and regularity of flight. AeroMACS SHALL support airport authority communication exchanges related to safety and regularity of flight. AeroMACS SHOULD support VoIP services for airport operation. NOTE: Currently, it is not intended to support VoIP for ATC applications in Europe. 4.4 Registration procedure 4.5 Mobility and Handover Aircraft device SHALL automatically register and de-register from AeroMACS system without intervention of human agents. AeroMACS SHALL guarantee service availability for vehicles and home/visiting aircrafts within the airport. AeroMACS handover SHALL be transparent for applications. AeroMACS SHALL not jeopardize compliance with continuity of service requirements.

70 68 Service flows connections SHALL be kept and guarantee their continuity without service disruption from the user s point of view. 4.6 Performance monitoring 4.7 System supervision System monitoring SHALL be performed by organizations which operate the AeroMACS system or components. The monitoring capability of the AeroMACS SHALL NOT impede the operation of the AeroMACS system. AeroMACS MAY enable advanced RRM by enabling the collection of reliable statistics over different timescales, including system (e.g., dropped call statistics, BS loading conditions, channel occupancy, RSSI), user (e.g., terminal capabilities, mobility statistics), flow, packet, etc. The safety requirements regarding detection and alert in case of ACSP failures are: The ground system SHALL be capable of detecting ground system failures and configuration changes that would cause the communication service to no longer meet the requirements for the intended function. When the communication service no longer meets the requirements for the intended function, the ground system SHALL support notification capability. The supervision capability of the AeroMACS SHALL NOT impede the working of the AeroMACS system. Information concerning identified problems on AeroMACS data link SHOULD be disseminated to operators and ATS providers to raise awareness and facilitate problem resolution.

71 69 CHAPTER 5 AEROMACS TECHNICAL REQUIREMENTS This section aims to gather technical requirements, which are related to the operational requirements outlined in CHAPTER Min Max aircraft, vehicle speed AeroMACS data link SHALL be able to support every single data transaction related to ATM services while the subscriber speed is lower or equal 50 knots. 5.2 Network Management Services support AeroMACS SHALL support the necessary Network Management services (NET) as required by the supported safety of life and flight regularity services. 5.3 Registration procedure 5.4 Mobility and Handover AeroMACS SHALL give means to create, configure and delete accurately user profiles with different grades of service in the access network AeroMACS maximum network entry time for a MS SHALL be less than 90 s. NOTE: The AeroMACS channels are 5 MHz wide and the applicable band (5002,5 MHz to 5147,5 MHz) has been channelized with reference to the nominal centre frequencies (5005+n*5 MHz with n=0 to 28). The AeroMACS equipment SHALL be able to tune in to authorised frequencies with a resolution of 250 KHz. NOTE 1: While in normal operations the nominal centre frequencies will be used, the 250 KHz step size resolution is foreseen to provide flexibility in interference cases and to allow AeroMACS operations to avoid receiving or causing interference to other systems operating in the band such as MLS, AMT, or other users. NOTE 2: In order to reduce the Net Entry Time, a possible solution is to pre-provision the MS with frequency it can use at the start-up (i.e. at the destination airport). AeroMACS SHALL be capable to operate within the FCI (Future Communication Infrastructure) multilink architecture and associated data links whenever these other FCI data links are available. AeroMACS SHALL support hard handover between BSs. The handover procedure SHALL be initiated by the MS. During handover procedure, ASN-GW SHALL update the AK from the MS to the new serving BS. NOTE: Therefore the whole set of keys is transferred to the BS (TEK) through PKM protocol. The MS SHALL command the BS to destroy current SF and trigger the new BS to create the new SF. AeroMACS SHALL guarantee the transfer of the authorization policy and the mapping of the SA s currently established of the MS triggering the HO. AeroMACS handover interruption time SHALL take no more than 200ms. NOTE: AeroMACS handover interruption time needs to be kept low to guarantee no service disruption within the whole operational turnaround of the aircraft in the airport surface. 5.5 Synchronization and Timing Requirements AeroMACS MS SHALL be able to synchronize at the border of the AeroMACS cell. AeroMACS SHALL perform a resynchronization procedure of the MS after a signal loss. AeroMACS BSs SHALL synchronize using a unique time reference achieving a clock accuracy of at least ±2ppm.

72 Data Latency 5.7 Residual Error Rate 5.8 System supervision The maximum resynchronization time for the MS after signal loss SHALL be less than 10 s. Downlink one-way data latency for NET and ATC services SHALL be < 20 ms. Uplink one-way data latency for NET and ATC services SHALL be < 40 ms. NOTE: Simulation results showed that even 80 ms is sufficient to fulfil the application level requirements as outlined in section on capacity analysis. The residual error rate, to/from subscriber station SHOULD be less than or equal to 5 x 10E-8 per SNSDU. AeroMACS SHALL support VPN and VLAN in case it is required for system supervision purposes. NOTE 1: VLAN could be used to create different VLANs for network segregation, including one VLAN dedicated to management/supervision purposes (separated from user data traffic) on the ground stations. NOTE 2: A VPN could be used for remote access to the ground station device, allowing an administrator to remotely access the device for configuration/management/supervision purposes, and accessing through the management VLAN (not through the data VLAN). AeroMACS SHOULD support SNMP protocol in order to give to the operator of the network the means to supervise the status and get problems reports of the elements of the AeroMACS system. AeroMACS architecture SHOULD integrate a management information base (MIB). AeroMACS BSs and ASN-GW SHOULD implement SNMP agents in order to enable its management. MSs MAY include an SNMP agent. AeroMACS problem resolution SHOULD be easily traced back to the point at which the problem was encountered from the SNMP protocol.

73 71 CHAPTER 6 QUALITY OF SERVICE REQUIREMENTS In a real deployment, a specific mapping of QoS levels SHALL be provided. NOTE: In Appendix B.2.5 one example of IP QoS to AeroMACS QoS map has been described, which has been used for capacity analysis simulations in order to address the mapping of different grade of services to AeroMACS QoS. AeroMACS BS SHALL be capable to establish different dynamic service flows (SF) to the MSs (with different parameters of throughput, jitter, delay, etc.). AeroMACS BS SHALL be able to modify the QoS parameters of a SF according to different traffic patterns and application requirements. AeroMACS SHALL implement different traffic scheduling services in order to accomplish differentiated class of service support. All messages of each transaction SHALL be mapped to one of the existing AeroMACS Class of Services (CoS). 6.1 AeroMACS Scheduling Services IEEE supports 5 scheduling services, which are outlined in the following sub sections Extended Real-Time Polling Service AeroMACS SHALL support ertps NOTE 1: Extended real time Polling Service (ertps) is defined as a real-time service flows that generates variable-sized data packets on a periodic basis. NOTE 2: An example of an ertps based commercial communications application would be VOIP with silence suppression Real-Time Polling Service AeroMACS SHALL support rtps NOTE 1: Real time Polling Service (rtps) is defined as real-time data streams comprising variable-sized data packets that are issued at periodic intervals. NOTE 2: An example of a rtps based commercial communications application would be MPEG Video Non-real Time Polling Service AeroMACS SHALL support nrtps NOTE 1: Non real time Polling Service (nrtps) is defined as delay-tolerant data streams comprising variable-sized data packets for which a minimum data rate is required. NOTE 2: An example of a nrtps based commercial communications application would be FTP with guaranteed minimum throughput Best Effort Service AeroMACS SHALL support BE. NOTE 1: Best Effort Service (BE) is defined as data streams for which no minimum service level is required and therefore can be handled on a space-available basis. NOTE 2: An example of a BE based commercial communications application would be HTTP.

74 Unsolicited Grant Service AeroMACS SHALL support UGS. NOTE 1: Unsolicited Grant Service (UGS) is defined as real-time data streams comprising fixed-size data packets issued at periodic intervals all being delay and delay variance critical. NOTE 2: An example of a UGS based commercial communications application would be E1/T1 transport, or circuit switched voice or VOIP without silence suppression.note 3 : It is expected that in the future there will be no need any longer for circuit switched communications. 6.2 Classes of Service AeroMACS SHALL support at least 6 classes of service. An example of a potential allocation of classes of service for ATC, AOC and NET services is outlined in Table 6. Table 6: AeroMACS classes of service example [3] Classes of Service Subscribers Aircraft Surface vehicles CoS 1 (highest) NET services NET services CoS 2 CoS 3 CoS 4 CoS 5 CoS 6 ATS 1 ATS 2 ATS 3 AOC 1 AOC 2 ATS2 ATS 3 Surface operation ICAO Annex 10 [60] Table 3-2 specifies the mapping of existing mobile subnetworks into the ATN network layer priority level. Table 6 below proposes a new column for AeroMACS subnetwork to be added to the table in order to ensure compliance between AeroMACS classes of service and ATN messages. In Annex 10, priority levels can be changed to numbers in line with the description of the other subnetwork priorities. Note that the mapping only applies to NET and ATS classes of service and not to AOC according to the scope of the Annex 10. Table 7: Mapping of ATN network priority to mobile subnetwork priority AeroMACS proposal Message categories Network/systems management Distress communications Corresponding mobile subnetwork priority (see Note 4) AeroMACS NET ATS1 Rationale Urgent communications ATS1 COCRv2 [1]: The SURV service uses Automatic Dependent Surveillance (ADS) positional information provided by equipped aircraft for separation or monitoring purposes. The SURV service consists of the following types

75 73 High-priority flight safety messages Normal-priority flight safety messages Meteorological communications Flight regularity communications Aeronautical information service messages Network/systems administration Aeronautical administrative messages <unassigned> Urgent-priority administrative and U.N. Charter communications High-priority administrative and State/Government communications Normal-priority administrative communications Low-priority administrative communications and aeronautical passenger communications ATS1 ATS2 ATS3 ATS3 ATS3 NET or ATS3 Not allowed <unassigned> Not allowed Not allowed Not allowed Not allowed of exchanges: - Uplink of contract(s) requesting ADS-C data - Downlink of contract acknowledgements - Downlink of current and predicted position, meteorological data, other flight data (i.e., ADS-C reports) - Aircraft broadcast of position data (i.e., ADS-B reports) AN10 defines this as CPDLC and ADS-C. AN10 defines this as ATIS and AIDC. Correspond to FIS and CM-Contact (or DCM-ACM), respectively. AN10 defines this as METAR. Corresponds to FIS. AN10 defines this as DLIC. Corresponds to CM-Logon (or DCM- DLL). Only AIS service is NOTAM. AN10: Directory service (DIR). A service, based on the ITU-T X.500 series of recommendations, providing access to and management of structured information relevant to the operation of the ATN and its users. Note 3. The term not allowed means that only communications related to safety and regularity of flight are authorized to pass over this subnetwork as defined in the subnetwork SARPs. Same as above Same as above Same as above Same as above

76 74 CHAPTER 7 SAFETY AND PERFORMANCE REQUIREMENTS 7.1 Safety and Performance requirements for the AeroMACS ground infrastructure In order to derive appropriate safety and performance requirements to implement AeroMACS, one can refer to ED-228 [40], which is the Safety and Performance standard for baseline 2 ATS data communications. NOTE: all the following information in this section is based on ED-228. ED-228 notably apportions safety and performance requirements to the ACSP domain, which comprises the ground system supporting the air-ground communications network, and air-ground and ground-ground routers, operated by the ACSP. These requirements are thus relevant to derive requirements on the ASN and CSN (including home and visited CSN in case of roaming operations). Aircraft Procedures Flight Deck Airborne End-System Airborne router Flight crew HMI Airborne radio ASN ATSU Visited CSN Procedures (ATSU) End-System Access router Home CSN ACSP Controller HMI FIGURE 34: DEFINITION AND INTERCONNECTION OF AIRCRAFT, ACSP AND ATSU DOMAIN Requirements coming from ED-228 can be directly applicable to the AeroMACS infrastructure (CSN + ASN) in case AeroMACS would be the only subnetwork supporting datalink services. If not, other sub-networks would be available (e.g VDL Mode 2), ED-228 requirements would have to be apportioned to AeroMACS infrastructure Performance requirements ED-228 expresses Performance requirements based on the following parameters:

77 75 Availability Availability is defined as the probability that the data communication system between the two parties is in service when needed, measured over a period of time. In addition, ED-228 introduces the additional parameters: Unplanned service outage duration (min) or MTTR Maximum number of unplanned service outages Maximum accumulated unplanned service outage time(min/yr) or sum of MTTR Unplanned service outage notification delay (min) Comentado [schlereth3]: It comes from ED-228. Shall we put it into the definition section of the present document or only refer to ED-228 definition? TBD with Anna. Maximum Transaction time This time presents the maximum acceptable time, after which the initiator is required to revert to an alternative procedure. The Maximum Transaction Time is associated with probability, corresponding to the Continuity target. The maximum transaction time is stated as an expiration time (ET) for CPDLC and as Overdue Delivery Time (DT) for ADS-C. Comentado [schlereth4]: It comes from ED-228. Shall we put it into the definition section of the present document or only refer to ED-228 definition? TBD with Anna. Nominal Time The nominal time (TT95%) for the CPDLC application (respectively (DT95%) for the ADS-C application) is defined as the time at which 95 percent of all Transactions, that are initiated, are completed. Comentado [schlereth5]: It comes from ED-228. Shall we put it into the definition section of the present document or only refer to ED-228 definition? TBD with Anna. Continuity and Probability 95% The Continuity is linked with the Maximum Transaction Time, while the Probability95% is associated with the Nominal Time. Comentado [schlereth6]: It comes from ED-228. Shall we put it into the definition section of the present document or only refer to ED-228 definition? TBD with Anna. Integrity Integrity is the probability that a transaction completes with no undetected errors. Comentado [schlereth7]: It comes from ED-228. Shall we put it into the definition section of the present document or only refer to ED-228 definition? TBD with Anna. AeroMACS ACSP (ASN + CSN) SHALL comply with the following ACSP Transaction Time and Availability Requirements: Table 8: ACSP Transaction Time Requirements [40] Maximum ACSP contribution Communication ET (sec) C = 99.9% 18 (two way transaction) TT (sec) C = 95% 10 (two way transaction) Surveillance OT (sec) C = 99.9% 12 (one way transaction) DT (sec) C = 95% 5 (one way transaction) NOTE: these performance requirements are based on most constraining performance labels specified in ED-228 (RCP130 and RSP160).

78 76 Table 9: ACSP Availability Requirements [40] ACSP requirements Availability Maximum Unplanned service outage duration (min) 6 Maximum number of service unplanned outages Maximum accumulated service unplanned outage time(min/yr) Unplanned service outage notification delay (min) NOTE: these performance requirements are based on most constraining performance labels specified in ED-228 (RCP130 and RSP160). ED-228 does not specify any requirement related to Integrity and applicable to the ACSP domain Safety requirements applicable to the ACSP domain Safety requirements applicable to AeroMACS are quite dependent upon overall communication architecture. However, compliance to performance requirements in Table 6 and Table 6 applicable to the ACSP domain ensure compliance with quantitative safety requirements, which would be defined according to ED-228 safety objectives. Software assurance level requirement is also dependent upon the design of the network. Manufacturers MAY implement AeroMACS software for safety critical functions in compliance with SWAL 4 objectives according to ED-153 [59]. 7.2 ATC and AOC throughput ATC: The overall (combined up and downlink) average data load supported by one AeroMACS cell/sector SHALL be at least 0,6kbps (GROUND/TOWER) or 0,2kbps (RAMP). AOC: The overall (combined up and downlink) average data load supported by one AeroMACS cell/sector SHALL be at least 800kbps (GROUND/TOWER) or 1Mbps (RAMP). NOTE: These figures have been yielded from large airport case analysis (typically 50 A/C) and assuming packet sizes (see capacity analysis in Appendix B) as follows: AeroMACS average ATC message size is 190 Bytes. AeroMACS average AOC message size is 278 kbytes.

79 77 Table 10: ATC and AOC required throughput Overall (combined up and downlink) minimum average data load within one cell/sector of GROUND/TOWER OPS domain Overall (combined up and downlink) minimum average data load within one cell/sector of RAMP OPS domain Overall (combined up and downlink) minimum average data load within one cell/sector of GROUND/TOWER OPS domain Overall (combined up and downlink) minimum average data load within one cell/sector of RAMP OPS domain ATC Required Throughput AOC Required Throughput 0,6 kps 0,2 kps 800 kps 1000 kps

80 78 CHAPTER Inputs to Coverage and Capacity Requirements COVERAGE AND CAPACITY AeroMACS Coverage and Capacity requirements depend on many different parameters as listed below. These parameters will be addressed in the following paragraphs. Airport Parameters to be considered are: 1. Airport Terminal Layout type. 2. Airport Parking Layout type. 3. Type of Basic Airport Runway Layout. 4. Airport visiting A/C frame types and corresponding traffic mix (MTOW category: light medium heavy, mixed traffic, etc). 5. Within each airport different areas exist which need to be covered by AeroMACS. However these areas have different capacity needs. 6. Aircraft (MS) antenna heights with respect to ground Amount of Gates and Stands The total airport capacity is also determined by the amount of gates where A/C can be docked as well as the amount of A/C stands which are foreseen at the airport. Hence this factor will also determine the AeroMACS capacity needed at the airport Airport Areas Definitions Under SJU P WA2 a traffic model for airports has been developed [6]. This document follows an identical airport area distribution as developed in [4], which every A/C passes through during either departure or arrival phase of flight. These areas are defined in Appendix B. AeroMACS coverage requirements at an airport are also determined by the size of previously defined areas for this airport Airport visiting A/C frame types and airport traffic mix Because runway capacity has the largest impact on overall airport capacity it is important to notice that for any particular airport considered irrespective of the basic category it belongs to - its runway capacity is also determined by the type of traffic and /or traffic mix this airport is operating. An airport operating many light aircraft will have a larger capacity compared to an identical airport operating mainly heavy (commercial A/C wide bodies 100+ passenger A/C) aircraft. This is because the WAKE VORTEX created by these large aircraft is so large that the interval times between landings (as well as for departures) depend on the A/C size and weight. ICAO mandates separation minima based upon wake vortex categories that are, in turn, based upon the Maximum Take Off Mass (MTOW MTOM) of the aircraft. These minima are categorized as follows: Light MTOW of 7,000 kilograms or less. Medium MTOW of greater than 7,000 kilograms, but less than 136,000 kilograms. Heavy MTOW of 136,000 kilograms or greater. NOTE: a new category named SUPER is created by for very large heavy weight such as A380. During take off phase the following rules are applicable:

81 79 An aircraft of a lower wake vortex category must not be allowed to take off less than two minutes behind an aircraft of a higher wake vortex category. If the following aircraft does not start its take off roll from the same point as the preceding aircraft, this is increased to three minutes. During landing phase the following separation minima apply as indicated in the table below. Table 11: A/C separation minima Super Heavy Preceding aircraft Super Heavy Medium Light Heavy Medium Light Following aircraft Minimum radar separation 4 NM 6 NM 7 NM 8 NM 4 NM 5 NM 5 NM Medium Light 4 NM Aircraft frame antenna heights from ground In order to provide good coverage, it is important to know for some of the most popular commercial aircraft frames the AeroMACS antenna height with respect to the ground surface. The following table provides a short overview of these heights: Table 12: Airframe heights with respect to ground AIRCRAFT FRAME TYPE AeroMACS Antenna height (m) 6 A 318 5,9 A 320 5,91 A ,55 A ,22 A ,74 6 Heights can fluctuate around 0,3 m depending on A/C load conditions.

82 80 A ,09 B /400/500 5,26 B 757 6,24 6,5 B 767 7,16 7,47 B 787 7,63 8,00 B 777 8,46-8,78 B , Traffic Modelling and Scenario Definition TRAFFIC MODELLING: From the Traffic Modelling described in [6] a total estimation has been made for all NET, ATC and AOC services to be delivered on a complete airport. For this estimation, the airport had been divided in the three defined airport areas as specified in [6]. For all these areas, different scenarios were provided in function of the amount of A/C at the airport. SCENARIO DEFINITION: The number of A/Cs stated in each scenario is the average number of A/Cs spread over the airport in a given time t for the simulations. Such an average value includes landing as well as departing A/Cs. Numbers depicted for data rates tables 5-1 and 5-2 in [6] apply to the specific zone indicated in the scenario description. During a second simulation the average load for NET, ATC and AOC had been calculated for a single sector scenario. Once again different scenarios have been provided based on the total amount of A/C at an airport. NOTE: Traffic modelling considered in [6] had FOQA only included in GROUND scenario (UL Traffic). For all other scenarios FOQA had not been included. SCENARIO A/C DWELL TIME RELATIONSHIP: The reader of the traffic analysis should be aware that the number of A/C described in any scenario also has to take into account the average dwell time an A/C stays in the areas described within this document. These dwell times are gathered in the table beneath (see also COCR V2 [1] for airport description). Table 13: A/C Dwell times vs A/C airport operation areas Airport density and area RAMP dwell time in min GROUND dwell time in min TOWER dwell time in min HD Phase 2 Departure 30 m 12 m 4,5 m HD Phase 2 Arrival 6 m 8 m 4,5 m LD Phase 2 Departure 15 m 6 m 2,5 m LD Phase 2 Arrival 3 m 4 m 2,5 m

83 81 Hence it is important to notice that the average amount of time an A/C is residing at an area - as described in the scenarios - is defined by the dwell time at these areas. Because airport capacity is determined in an amount of operations/movements per hour, the dwell times need to be converted or linked to operations per hour. AIRPORT CAPACITY VERSUS SCENARIO INTERPOLATION: Within [6], several airport scenarios have been taken into account to make data load requirements estimation. For this, several scenarios have been worked out but it is clear that they might not all fit exactly all possible existing European airport size. Hence there could be a need to perform some interpolations in between scenarios to match a particular airport. ASSUMPTIONS ON TRAFFIC MIX: Because runway capacity as well as data load requirements depend heavily on the airport traffic mix, it is assumed that the majority of traffic (>95%) visiting the airports belong mainly to commercial aircraft (medium and heavy MTOW) class with few business flights (light), all traffic operating under IFR rules. AeroMACS DL (BS) and UL (A/C or MS) supported Data loads: The following table provides an overview of AeroMACS data throughput capacity for a single cell or sector (DL/UL = 2/1). These figures were drawn beforehand simulations. Table 14: AeroMACS expected throughputs vs modulation schemes MC scheme Downlink [kbps] Uplink [Kbps] QPSK1/ QAM1/ QAM1/ Available data rates are highly dependent on the following factors: 1. Modulation scheme used (see table above). 2. FEC used. 3. RF channel conditions which are varying in time. 4. Distance between A/C (MS) and BS. 5. Actual service flow demand by BS/MS. Therefore the actual data rate AeroMACS is able to support between BS and MS is difficult to establish. Therefore it is assumed that the data rates from the table above can be achieved. These inputs on data load estimations will be used in combination with all other inputs (specially coming from [6]) as defined in the previous paragraph to obtain load and coverage requirements. Single Sector data requirements: From Table 14 combined with scenario, which is providing the data requirements for 20 A/C [6]for the whole airport area in departure mode, up to 20 A/C could be served by a single cell. Table 15: Single Sector scenario excluding FOQA [10] Scenario Average offered load ATC (Kbits/sec) Average offered load AOC (Kbits/sec)

84 82 20 A/C, 4 VC RAMP departure ATC, NET, AOC, EFF, UPLIB, E-CHARTS Overall 0, ,43 (~1,8 MBitps) FL 0, ,49 RL 0,50 248,22 On scenario interpretation it could be assumed that 12 A/C will be in departure mode while 6 A/C would be arriving and another 2 would be within Tower area. European Airport database: In [10]an overview of all small, medium and large airports is provided including amount (not type) of runways, with for each case the amount of commercial movements. COCR V2.0 HD and LD airports; COCR defines airport density in a different way and defines only low and high density volumes for the different airport areas and phases. See table 2-12 Airport Controller Position PIACs in COCR [1]. Table 16: Airport size categories according to COCR APT Position Phase 1 Phase 2 HD LD HD LD Clearance/Ramp Ground Tower Total For this document, the COCR differentiation was found not to be detailed enough. So by refining the airport model and providing better estimations of airport surface data requirements, airports have been split up in small, medium, large and super large airports. AIRPORT OPERATIONS/hr VS PASSENGER TRAFFIC: Airport size is in reality determined by the amount of passengers served on a yearly base and not on amount of operations handled per hour. However airport surface data throughputs are determined by the amount of operations per hour, therefore this last criterion prevails in this study. As can be seen from [10], Europe s largest airport is passenger wise London Heathrow, however Amsterdam Schiphol will be in this study the largest airport needing the highest data throughputs. Hence it is obvious that London will be visited by larger MTOW A/C than Amsterdam which is confirmed by the fact that London is the major European hub for transatlantic flights.

85 SESAR Airport Categorization For this section, FL stands for Forward Link which operationally means data flowing from tower to the A/Cs (also referred as DL or downlink) and RL, Reverse Link that refers to packets going from A/Cs to the tower (also referred as UL or uplink) Small airports (<20mvts/hr) Single Runway- Simple Terminal Small airports are complying with the basic single runway category. Very often these airports belong to the simple terminal category though it can also belong to the satellite or curvilinear category. Comentado [ACU8]: To replace FL/RL by DL/UL Because any airport needs to have at least a single runway, hence it is obvious that many airports exist in Europe having far less than 50 A/C operations per hour. For the single runway airport some subcategories have been worked out all belonging to the small airports category. These subcategories will be differentiated by indicating the amount of A/C operations per hour. In Europe, airports such as KERKIRA, KOS, FUNCHAL, FUERTEVENTURA etc, all match the requirements for small airports Capacity Requirements for airports with 3 operations/hour AeroMACS deployment at airports with 3 operations/hour will be able to serve any aircraft on the airport in a satisfactory manner, seen the small amount of A/C to be served. The scenarios 19 and 20 [6] fulfill these data rate requirements for RAMP arrival and departure. Even though these scenarios cover only 1 A/C, the A/C dwell time foreseen is around 21 minutes per A/C. Even if all A/C would arrive at the same time which is very unlikely for such small airports any AeroMACS deployment will be able to deliver expected data loads under such scenario. Scenarios 19, 20 are conforming to such an airport data needs. Table 17: Airport capacity load for small airports (3 operations/hour) [10] Scenario Scenario 19 (1 A/C, 1 VC) RAMP arrival Scenario 20 (1 A/C, 1 VC) RAMP departure/ ATC,NET,AOC,EFF,UPLIB,Echarts Average load (kbits/s) offered ATC Average offered load AOC (kbits/s) Overall 0,0 0,23 FL 0,0 022 RL 0,0 0,01 Overall 0,04 56,69 FL 0,02 47,64 RL 0,02 9,35 Comentado [cac9]: Doc quality minor note: I think standard notation is kbit/s. In this doc it is written in several ways: Kbit/sec, kbps, etc. Comentado [ACU10R9]: Armin will take care of this during the final editorial revision

86 84 According to the results drawn in [9], GROUND scenarios were raising problems due to the high load provoked by FOQA service. As stated on the conclusions, FOQA service was encouraged to be moved to RAMP area, where presumably, will be higher data rates due to the proximity to the BS. Therefore a recalculation of Table 17 values has to be done in order to introduce FOQA on the capacity analysis for RAMP area. The main considerations taken are shown below in order to achieve the movement of FOQA service from GROUND arrival to RAMP arrival, knowing that simulations cannot be triggered again. According to data yielded on [6] for scenario 9, table A of the appendix, the relative volume of FOQA s packets generated to the rest of the services is 83,38%. On the other hand, table A.9-62 reflects overall data throughput for AOC services. The average data throughput for AOC services that are triggered on the RL is 42898,10kpbs. Hence, 42898,10*0,8338=35768,35kbps. Nevertheless these figures yielded are for a scenario with 100A/Cs. There are no specific figures for a scenario of 1 A/C on GROUND. Therefore, as previously stated, an interpolation ought to be made. Paying attention to data for other scenarios, it is clearly appreciable that data estimations grow linear with the number of aircrafts. In conclusion, we can address it, without losing too much accuracy as a linear interpolation. The value deemed for FOQA service in a RAMP arrival scenario with 1 A/C is 35768,35*(1/100)=357,68kbps. As an immediate consequence of this, the average offered load for AOC traffic on the RL will be 0,23+357,68=357,91kbps. Hereafter all data will be recalculated this way and consequently values from tables of [6] properly amended. Finally Table 17 will develop as follows: Table 18: Airport capacity load for small airports (3 operations/hour) considering FOQA as a RAMP service [10] Scenario Scenario 19 (1 A/C, 1 VC) RAMP arrival with FOQA Scenario 20 (1 A/C, 1 VC) RAMP departure/ ATC,NET,AOC,EFF,UPLIB,Echarts Average offered load ATC (Kbits/sec) Average offered load AOC (Kbits/sec) Overall 0,0 357,91 FL 0,0 0,22 RL 0,0 357,69 Overall 0,04 56,69 FL 0,02 47,64 RL 0,02 9, Coverage Requirements for airports with 3 operations/hour AeroMACS deployment at such an airport would be limited to a single BS location using a sectorized antenna (allowing extended cell coverage). Antenna height is determined by airport AeroMACS equipped A/C type (light or medium). There is probably no need for antenna height above 10 m.

87 85 Existing airport infrastructure is expected to be used (building structure, tower, antenna towers or light poles) in such a way that all gates or stands are covered as well as all airport areas as defined in this document. In this case, AeroMACS cells will be of the macro cell size type (large cells). There is no need for special cell planning studies to determine BS site as terminal infrastructure is likely to be small Capacity Requirements for airports with 20 operations/hour Such airport is likely to comply with scenarios 21 & 22 as provided by [6]. In this case data loads are provided assuming that the first half hour 10 A/C are arriving / departing and the next 10 A/C the next 30 minutes. When comparing data needs from these scenarios and the table providing AeroMACS DL (BS) and UL (A/C or MS) supported Data loads, it is clear that also here a single sectorised BS will fulfill data requirements when no FOQA services are considered at the airport. However when FOQA services over AeroMACS would be made available at such airport a second omnidirectional cell will be needed operating on a different frequency in order to handle the 3 Mbps data load in UL. Considerations previously made on FOQA service have been taken into account and the table values amended. Table 19: Airport capacity load for small airports (20 operations/hour) [10] Scenario Average offered load ATC (Kbits/sec) Average offered load AOC (Kbits/sec) Scenario 21 (10 A/C, 4 VC) RAMP arrival with FOQA Scenario 22 (10 A/C, 4 VC) RAMP departure Overall 0, ,55 FL 0,06 18,32 RL 0, ,23 Overall 0, ,82 (~1 MBit) FL 0,16 902,07 RL 0,24 139, Coverage Requirements for airports with 20 operations/hour The same coverage requirements do exist as for the 3 operations per hour. This is because a single BS data throughput can easily handle the required data loads as provided in the table above. In this case, AeroMACS cells will be of the macro cell size type (large cells). The AeroMACS BS needs to be deployed in such a way that it will provide the highest data throughput (64 QAM modulation scheme at least in the DL) at the RAMP area. 64QAM modulation scheme in UL is optional for implementation.

88 Medium airports (20-60 mvts/hr) Parallel or Open V Runways and Linear Curvilinear Terminals Medium airports can make use of either parallel or open V runway layouts or be based on a mixture of both types. Medium airport is in Europe the largest airport category encountered. Airports such as Geneva, Helsinki, Zagreb, Prague, Paris Le Bourget, Dusseldorf, Hamburg and many others belong to this category Capacity Requirements for airports with 50 operations/hour Medium airports are likely to comply with scenarios 27, 28, 29, 30, 31, 32 as provided by [6]. Considerations previously made on FOQA service have been taken into account and the table values amended. (e.g. for scenario 30, FOQA had been incorrectly introduced in that scenario and counted for the overall AOC traffic on the RL, while it should only be instantiated in GROUND arrival phase. Therefore it must be removed from the figures. As shown on table A of [6], FOQA has a relative volume on the RL of 83,52%. Hence, 5737,92*(1-0,8352)=945,6kbps will be the total amount of traffic for AOC on the RL. Table 20: Airport capacity load for medium airports (50 operations/hour [10] Scenario Scenario 27 (25 A/C, 10 VC) RAMP arrival with FOQA Scenario 28 (25 A/C, 10 VC) RAMP departure Scenario 29 (25 A/C, 10 VC) GROUND arrival without FOQA Scenario 30 (25 A/C, 10 VC) GROUND departure (FOQA is not executed on departure) Scenario 31 (25 A/C, 10 VC) TOWER arrival Scenario 32 (25 A/C, 10 VC) TOWER departure Average offered load ATC (Kbits/sec) Average offered load AOC (Kbits/sec) Overall 0, ,26(~9 Mbit/s) FL 0,19 69,42 RL 0, ,84 Overall 1, ,97 (~2,3 MBit/s) FL 0, ,86 RL 0,60 325,45 Overall 1, ,19(~3 MBit/s) FL 1,14 196,97 RL 0, ,22 Overall 1, ,2 (~1 MBit/s) FL 0,98 95,58 RL 0,07 945,6 Overall 0,58 141,97 FL 0,57 0,0 RL 0,02 141,97 Overall 0,44 287,38 Comentado [cac11]: Should use Mbit/s. I think this is the standard notation. Comentado [ACU12R11]: Armin will take care of this during the final editorial revision

89 Coverage Requirements for airports with 50 operations/hour Most of the medium sized airports in Europe will likely be using AeroMACS for ATC and AOC operations. As can be seen from the scenarios shown above, it is obvious that a single AeroMACS BS is not any longer able to sustain the needed data throughput. Medium airports are expected to deploy multiple BSs locations to cover all airport areas. Generally it is estimated that 3 BS with 3 sectors each will be able to fulfill all AeroMACS data requirements. However there is not a fixed rule for establishing the amount of BS as deployment is highly depending on the terminal structure and rest of airport layout. As the highest throughputs are needed at RAMP area, cell planning will need to provide more capacity in this area. The exact location of the BS needs to be determined by an airport cell planning study which will take into account the terminal and airport infrastructure availability for this particular airport. Curvilinear airport terminals could have special needs in case there is no possibility to install BS antenna on a small tower on the roof of such a terminal. In case of small satellite airport terminals it could be useful to deploy an omnidirectional antenna located at a tower installed on top of the roof (if structurally possible). Tower height will be calculated in such a way that the A/C antenna for the A/C types handled at this airport can be reached by the BS antenna under LOS conditions trying to minimalize RF signal diffraction from roof edges. If it is not possible to install BSs on the roof, BSs could be installed on light poles around the terminal area. Linear terminals do not have any particular deployment need and the most probably good installation conditions will be available on light infrastructure installed along the terminal or on a tower when these are within 200 meters of the gates Large airports (60-100mvts/hr) 3 Runways - 4 Runways and Pier Finger Linear - Curvilinear Terminals Most of the large European airports belong to this airport category. Airports such as Brussels, Paris CDG, Frankfurt, Munich, Milan, Rome, Oslo, Stockholm, Zurich, London Heathrow, Madrid belong to this category. On the terminal site, most of these airports have mixed terminal layouts as most of them are constructed using extensions as part of a historical growth process as airports were not able to be relocated at a completely new site Capacity Requirements for airports with 100 operations/hour Scenarios 3, 4, 5, 6 provided by [6], represent the data load requirements as met at these airports. Considerations previously made on FOQA service have been taken into account and the table values amended. RAMP scenarios data have been taken from Table 47 and Table 48, which refine the original figures adding AOC data traffic

90 88 Table 21: Airport capacity load for large airports (100 operations/hour) [10] Scenario Overall average offered load FL (Kbits/sec) Overall average offered load RL (Kbits/sec) 50 A/C, 10 VC RAMP arrival 50 A/C, 10 VC RAMP departure Scenario 03 (50 A/C, 10 VC) GROUND arrival without FOQA 137, , ,42 496,42 352, ,44 Scenario 04 (50 A/C, 10 VC) GROUND departure (FOQA is not executed on departure) 180, ,7 Scenario 05 TOWER arrival 1,08 279,21 Scenario 06 (50 A/C, 10 VC) TOWER departure 0,88 596, Coverage Requirements for airports with 100 operations/hour Even without the high load AOC services included, it is obvious that multiple sectorised BS s will need to be installed to handle data requirements. At the RAMP area it is likely that AeroMACS will need to rely on microcells (cell coverage in the order of 200 to 300m diameter 16 QAM ). As for any cellular system, AeroMACS data throughput can be increased by creating additional cells within the same coverage area. These microcells will emit less power compared macro cells using lower gain antennas (e.g. 12 dbi), nevertheless the impact on Globalstar interference needs to be addressed properly. Hence microcells will request a more elaborated frequency planning and establishing appropriate cluster and frequency re-use factors will be done during cell planning studies Very Large airports(>100 mvts/hr) 4 Runways and more, Pier Finger Linear - Curvilinear Terminals. Today AMSTERDAM SCHIPHOL is the only airport in Europe handling more than 100 operations per hour handled over 5 runways.

91 Capacity Requirements for airports with more than 100 operations/hour Very large airports are likely to comply to scenarios 7, 8, 9, 10, 11 and 12 as provided by [6]. Considerations previously made on FOQA service have been taken into account and the table values amended. Table 22: Airport capacity load for very large airports (more than 100 operations/hour) [10] Scenario Average offered load ATC (Kbits/sec) Average offered load AOC (Kbits/sec) Scenario 07 (100 A/C, 20 VC) RAMP arrival with FOQA Scenario 08 (100 A/C, 20 VC) RAMP departure service exempted 7 Scenario 09 (100 A/C, 20 VC) GROUND arrival Scenario 10 (100 A/C, 20 VC) GROUND departure (FOQA is not executed on departure) Overall 1, ,32 (~36 Mbit/s) FL 0,78 274,27 RL 1, ,05 Overall 3,20 471,62 FL 1,29 408,09 RL 1,91 63,53 Overall 4, ,33 (~8 Mbit/s) FL 4,19 710,03 RL 0, ,3 Overall 3, ,58 (~3,5 Mbit/s) FL 3,28 312,77 RL 0, ,81 Scenario 11 (100 A/C, 20 VC) TOWER arrival services exempted Scenario 12 (100 A/C, 20 VC) TOWER departure Overall 2,17 538,39 FL 2,11 0,0 RL 0,06 538,39 Overall 1, ,44 (~1 Mbit/s) Coverage Requirements for airports with more than 100 operations/hour Very large airports will have identical coverage requirements as large airports around terminal areas. For GROUND and TOWER areas there may be a need to add one or two additional sectorized BSs to cover all 5 runways with accompanying taxiways. 7 Service exempted means that the really large AOC applications such as EFF, UPLIB, E-CHARTS have not been considered as AOC applications.

92 90 CHAPTER Multi-vendor Interoperability SYSTEM INTEROPERABILITY AND COMPATIBILITY This section covers interoperability requirements that are not covered in other parts of the document or in the AeroMACS MOPS. The objective of this section is to identify additional requirements on the AeroMACS network that are needed to guarantee the interoperability of BS and ASN-GW equipment provided by different vendors in the same ASN, and between the ASN and the CSN General Considerations The network reference model aimed to support AeroMACS access network and its interconnection to the backbone has been previously depicted in section 2.1. In relation to the applicable in AeroMACS profile C of WiMAX Architecture, AeroMACS BSs interoperability SHALL be guaranteed through R6 interface. NOTE: WMF only focus on R1 interface to guarantee for interoperability. Infrastructure interoperability has not been considered by the WMF. Therefore R6 is not in the scope of WMF certification engagement. The architecture SHOULD support interoperability between equipment from different manufacturers within an ASN and across ASNs. Such interoperability SHALL include: BS and backhaul equipment within an ASN. Common functionalities according to what is currently stated down below as requirements between BSs and between BS and ASN-GW from different manufacturers Intra ASN Compatibility (R6) The BS SHALL offer an interoperable interface with an ASN-GW. As mandated on this WiMAX Forum document, GRE SHALL be used as the tunneling protocol for the data plane over R6. NOTE: GRE is an IP-in-IP tunnel. The granularity of the GRE tunnel SHALL be one tunnel per Service Flow (SF). NOTE: The GRE tunnel granularity is left to implementation. In this case, all control resides in the ASN-GW. R6 procedures are detailed below: Packet forwarding in the downlink: ASN-GW has to map incoming traffic from the backbone to a corresponding data path. The protocol has a KEY option that should be applied for provisioning Data Path ID of the tunnel. When a packet destined for an MS arrives, it looks at the IPv4/IPv6 packet header and/or flow ID to determine the service flow ID (SFID) that this packet needs to be mapped on to. The SFID maps to a data path ID. The ASN-GW uses the GRE key associated with the data path ID to forward the IP packet via the GRE tunnel to the BS. IP packets are extracted in the BS out of the GRE packet and forwarded over R1 to the MS. Packet forwarding in the uplink: The way back is equivalent to the one described previously. IP datagrams transmitted upstream over R1 are encapsulated in the BS as user payload in GRE packets and transferred over R6 to the ASN-GW. GRE is not secure because all of R6 bearer message can be attracted without any protection due to GRE protocol but rather is used to differentiate each SF between ASN-GW and BS using a unique GRE key value. Every SF has each different GRE

93 91 key value. This should be the main concern when validating multivendor interoperability, BS implementation of GRE protocol. One advantage of GRE encapsulation is that it allows multiple IP hops to be encapsulated without any need for routing. All packets are de-capsulated at ASN-GW and layer-2 communication is established between CPE and ASN-GW. The R6 functionality required in order to support interoperability are described in [31] as follows: On the BS side: AeroMACS BS SHALL support Data path registration type1 with the following related Information Elements (IE): Data_Path info IE: Data Path Encapsulation Type: GRE Data Path ID: GRE Key Data Path Type: type 1 Operation ID IE: Data Path registration AeroMACS BS SHALL support Data path de-registration for triggering MS network exit with the following related Information Elements (IE): Operation ID IE: Data Path De-registration AeroMACS BS SHALL support HO preparation with the following related Information Elements (IE): Trigger source IE: 16e function entity (RRC and NRM dismissed) in line with [22] para HO optimization IE: enabled or disabled. It is a flag that may skip some phases of network re-entry during HO process. i.e SBC REQ/RSP (profile item 105.2, ), REG REQ/RSP (profile item , ), PKM-TEK (profile item 105.3, 105.4) [5]. AeroMACS BS SHALL support HO action. AeroMACS BS SHALL support HO cancellation. AeroMACS BS SHALL support HO rejection. AeroMACS BS SHALL perform Authentication Relay. AeroMACS BS SHALL forward EAP messages over R6 to the ASN-GW Authenticator with the ASN control data plane protocol. AeroMACS BS SHALL support AK transfer primitives and key reception. AeroMACS BS SHALL support NSP id list. AeroMACS BS SHALL implement the Context functionality. On the ASN-GW side: AeroMACS ASN-GW SHALL perform Authentication and key distribution AeroMACS ASN-GW SHALL support Network Entry signaling. AeroMACS ASN-GW SHALL support Service Flow Authorization. AeroMACS ASN-GW SHALL implement a AAA client in order to allow security policy pulling. AeroMACS ASN-GW SHALL support Data path registration type1. AeroMACS ASN-GW SHALL support Data path deregistration for triggering MS network exit.

94 92 AeroMACS ASN-GW SHALL support HO preparation with the following related Information Elements (IE): SBC context IE in case the field HO_optimization is enabled. In this case, no new capabilities are negotiated with the target BS and the ASN-GW has to forward the ones of the serving BS. The following requirements support AK context retrieval to the target BS. AeroMACS ASN-GW SHALL support HO action. AeroMACS ASN-GW SHALL support HO cancellation. AeroMACS ASN-GW SHALL support HO rejection. AeroMACS ASN-GW SHALL support Context transfer. NOTE: This is related to the notification to the ASN-GW of security policy that is foreseeable to be used by the MS entering the network. AeroMACS ASN-GW SHALL support CMAC key count update. NOTE Upon successful completion of Authentication, the Authenticator (in our case the AAA server) sets the count for the MS to ASN and CSN compatibility (R3) All interfaces to core equipment SHALL be performed through R3 interface (as stated in section 2.3). AeroMACS ASN-GW SHALL forward EAP messages over R3 to the AAA server with the RADIUS protocol. AeroMACS ASN-GW SHALL support Proxy MIPv4 Client. AeroMACS ASN-GW SHALL support MIP registration revocation. AeroMACS ASN-GW SHALL support DHCPv4 Proxy/Relay. AeroMACS ASN-GW SHOULD support MIPv6 Access Router. 9.2 Interference aspects Compatibility of AeroMACS systems with other radio systems operating in the same or adjacent frequency bands is an aspect to be considered. At the time of writing this document, no requirements have yet been derived. An analysis of the current situation in terms of potential coexistence issues due to interference between AeroMACS and other radio systems currently in use (RLAN, BBDR, MLS and AMT) is described in Error! No se encuentra el origen de la referencia..

95 93 CHAPTER 10 RF Cell Dimensioning and Planning This section outlines generic guidelines for RF cell dimensioning (i.e. calculation of number and separation of BS according to link budget and capacity requirements), and RF cell planning (i.e. optimization of BS siting in order to minimize intra-system interference). Calculations in this section use the sensitivity values specified in the AeroMACS SARPs [64] and the required SNR values specified in the AeroMACS MOPS. The recommendations in this chapter are supported by the case study simulations for Barajas and Toulouse airports as described in Appendix C RF Cell Dimensioning Coverage analysis The objective of this section is to specify link budget for different airport areas to be used during radio planning, derived from [7] channel models and allowed output power levels. The objective of this sub-section is to appreciate the difference which could occur between statistical models and deterministic models, which take into account real airport maps (DTM), environment (buildings), co-site situations (co-channel or interferences). Thus LOS and NLOS propagation are differentiated in a real situation, taking into account multipath propagation as well AeroMACS Link Budget A link budget provides a static RF coverage calculation taking into account all parameters which determine such a range, including modulation schemes and FEC. LOS range estimations are based on free space model and AWGN conditions while NLOS ranges are based on DLR MUNICH NLOS model [26]. Because in AeroMACS, the DL and UL operate with different amount of data carriers (sub-channels) under PUSC configuration, a short description is provided on subchannelization. While in the DL all data carriers are used simultaneously to download data to all MS attached to this particular BS in the UL the MS has only a limited amount of sub carriers available whenever a BS is serving multiple MSs at the same time Free space model Both free space and NLOS MUNICH pathloss models have been calculated in the spreadsheet in Table 23. The mathematical formula for free space model and AWGN operating conditions corresponds to: Lp = -32,4-20LOG(f (MHz))-20LOG(d (km)) DLR MUNICH NLOS model As kind of worst case scenario the cell coverage distance has also been calculated using the DLR MUNICH NLOS model used within SANDRA [26]. The mathematical expression for this model corresponds to:

96 94 Lp = A + 10µlog(d) with A = 49,3dB and µ = 2, Airport Model Comparison Both of the models defined above have been used in the link budget as they present the best (free space) as well as the worst channel model (DLR MUNICH NLOS) from all airport channel models developed. The following models (the last 3 typical for airports) have been developed under various projects: 1. Free space model 2. MATOLAK(FAA / USA) or US(LOS) 3. D02.1 (Sesar P channel modelling) or BS1MR1 and BS2MR2 4. DLR MUNICH NLOS A comparison can be found between all 4 models in Figure Figure 35: Comparison of airport pathloss models Numerical values for free space and NLOS MUNICH coverage ranges can be found in the accompanying spreadsheets of the link budget below. BS1MR1 and BS2MR1 are related to two different MS routes as explained in Appendix B. 8 DLR (NLOS) is equivalent to DLR MUNICH NLOS

97 Downlink PUSC Subcarriers are grouped into clusters of 14 contiguous sub-carriers per symbol. A subchannel is a group of two clusters. A slot is one sub-channel over two OFDM symbols. The sub-channels in a DL PUSC zone can also be mapped into larger groups called segments. There can be up to three segments created from these larger sub-channel groupings. Parameters shown in Table 23 and Table 24 are not to be considered as minimum requirements (e.g. antenna gain). These values have been considered as realistic at the time of simulation investigations and might vary depending on the capabilities of the deployed equipment. AeroMACS LINKBUDGET FOR THE DOWNLINK (5 MHz Bandwidth) Modulation Scheme QPSK 1/2 16QAM 1/2 64 QAM 1/2 Link Direction DL (CC) DL (CTC) DL (CC) DL (CTC) DL (CC) DL (CTC) TX Parameters Unit Notes # of antenna elements TX Power per Antenna Element dbm 23,00 23,00 23,00 23,00 23,00 23,00 Tx_Pout = (UL: 125mW) / (DL: 200mW) Maximum TX Antenna Gain dbi 15,00 15,00 15,00 15,00 15,00 15,00 Tx Cable loss db 3,00 3,00 3,00 3,00 3,00 3,00 10m ECOFLEX15 + 0,5 db Connector loss TX EiRP dbm 35,00 35,00 35,00 35,00 35,00 35,00 TX EiRP = TX_Pout + TX_AntGain - TX_CableLoss # of occupied sub-carriers DL -PUSC : 360 data subcarr+ 60 Pilot subcar = 420 subcar NFFT Window size TX EIRP per sub-carrier dbm 8,77 8,77 8,77 8,77 8,77 8,77 System Parameters Required SNR db 5,00 2,90 11,00 8,60 16,00 13,80 Bandwidth MHz 5,00 5,00 5,00 5,00 5,00 5,00 sub-carrier spacing khz 10,94 10,94 10,94 10,94 10,94 10,94 Transmit upper Frequency MHz Margins Non-orthogonality Margin db ESTIMATED SUBCAR ORTHOGONALITY IMPERFECTIONS ( DOPPLER) Inter-cell Interference Margin db Due to frequency reuse Implementation Margin db Safety Margin db Banking Loss Margin db A/C ROAMING ON GROUND RX Antenna Diversity Gain db RX Parameters Maximum RX Antenna Gain dbi Rx Cable loss db 1,8 1,8 1,8 1,8 1,8 1,8 5m ECOFLEX15 + 0,5 db Connector loss Thermal Noise Density@290K dbm/hz No = kto Receiver Noise Figure db Composite Noise Figure db 8,8 8,8 8,8 8,8 8,8 8,8 F = Cable loss + Manufacturer Noise figure RX Sensitivity dbm -86,6-88,7-80,6-83,0-75,6-77,8 S = kt + 10XLOG(BW) + F + all margins Maximum Allowable Path Loss db 127,6 129,7 121,6 124,0 116,6 MAPL = EIRP + Rx antenna gain + 118,8 diversity gain - Sensitivity free space LOS m 11190, , , , , ,19 Lp = -32,4-20LOG(f;10;M Hz)-20LOG(d;10;km) NLOS MUNICH m 1352, ,94 778,20 970,72 491,01 Lp = 49, log(d)

98 96 Table 23: DL Link Budget Uplink PUSC For UL PUSC zone type, four contiguous subcarriers are grouped over three symbols. This grouping is called a tile. Six tiles make a sub-channel. For the UL PUSC, the slot is defined as one sub-channel that occurs over the three symbols. Pilots are incorporated within the slot, their position changing with each symbol. Over the course of one tile, one in three subcarriers is a pilot. Slot time PILOT DATA DATA PILOT DATA DATA DATA DATA PILOT DATA DATA PILOT Freq carriers Figure 36: Graphical presentation of Tile in UL-PUSC zone ; Slot = 6 tiles over 3 Symbols Mobile WiMAX implements uplink sub-channelization which allows the user to transmit over a limited number of sub-carriers (X * 24) thereby boosting the transmit power as the power spectral density is focused on a limited set of sub-carriers. While sub-channelization increases the cell coverage it decreases the data throughput for this user as the number of subcarriers assigned to him has been reduced.

99 97 AeroMACS LINKBUDGET FOR THE UPLINK (5 MHz Bandwidth) Modulation Scheme QPSK 1/2 QPSK 1/2 16QAM 1/2 64QAM 1/2 64QAM 1/2 64QAM 1/2 Link Direction UL (CC) UL (CTC) UL (CC) UL (CTC) UL (CC) UL (CTC) TX Parameters Unit Notes # of antenna elements TX Power per Antenna Element dbm 21,00 21,00 21,00 21,00 21,00 21,00 Tx_Pout = (UL: 125mW) / (DL: 200mW) Maximum TX Antenna Gain dbi 6,00 6,00 6,00 6,00 6,00 6,00 Tx Cable loss db 1,80 1,80 1,80 1,80 1,80 1,80 5m ECOFLEX15 + 0,5 db Connector loss TX EiRP dbm 25,20 25,20 25,20 25,20 25,20 25,20 TX EiRP = TX_Pout + TX_AntGain - TX_CableLoss # of occupied sub-carriers UL PUSC : multiple of 24 subcarriers (1 tile = 4 sc over " symb; 1slot= 6 tiles; 1 subch=24 sc from 1slot) NusedsubCh UL NSubChUL Subchannels possible and 1 used as an assumption NFTT Window size TX EIRP per sub-carrier dbm 11,40 11,40 11,40 11,40 11,40 11,40 System Parameters Required SNR db 5,00 2,90 10,50 8,60 16,00 13,80 Bandwidth MHz 5,00 5,00 5,00 5,00 5,00 5,00 sub-carrier spacing khz 10,94 10,94 10,94 10,94 10,94 10,94 Uplink Sub-Channelization Gain db 12,3 12,3 12,3 12,3 12,3 12,3 Sub-Channelisation gain = -10*log(Nused/Nrequired) Transmit upper Frequency MHz Margins Non-orthogonality Margin db Implementation Margin db Safety Margin db Banking Loss Margin db RX Antenna Diversity Gain db RX Parameters Maximum RX Antenna Gain dbi Rx Cable loss db m ECOFLEX15 + 0,5 db Connector loss Thermal Noise Density@290K dbm/hz No = kto Receiver Noise Figure db Composite Noise Figure db F = Cable loss + Manufacturer Noise figure RX Sensitivity dbm -86,5-88,6-81,0-82,9-75,5-77,7 S = kt + 10XLOG(BW) + F + SNR + all margins Maximum Allowable Path Loss db 126,70 128,80 121,20 123,10 115,70 117,90 free space LOS 10119, , , , , ,19 Lp = -32,4-20LOG(f;10;M Hz)-20LOG(d;10;km) NLOS MUNICH m Lp = 49, log(d) Table 24: UL Link Budget Radio Cell Planning Steps Generally speaking, the radio cell planning is an iterative process, following several main steps summarized below. Step 1: Consolidate customer expectations and local data Range, number of MS, expected data rates, Existing radio systems, power limitations Step 2: Capacity study Derive number of devices Frequency planning Step 3 Coverage and Interference studies (linked to Step 2) Initial radio link budget (first cell dimensioning) Detailed Propagation model Antenna systems, choice of optimized localizations for BS and down tilts Detailed radio coverage analysis

100 98 Step 4 Network optimization Interferers mitigation Tuning This process is unique for each deployment and is common to all the wireless radio technologies Capacity Analysis Capacity is considered as the ability of the system to fulfil a certain degree of accomplishment of requirements defined by the types of service that it enables. It is measured by means of throughput and delay parameters, which can be defined at different levels and scopes according to the boundaries of the system. For this analysis, AeroMACS capacity is compared with the latency and throughput requirements that are needed by the services identified 9. These metrics have been investigated either per service or at MAC layer (i.e. independent on the specific service that runs over the radio medium). For more details see Appendix B. Two types of analysis have been considered: Analysis of the coverage and capacity offered per cell; Study of the overall capacity offered in a whole airport (Madrid Barajas) Capacity and coverage analysis per cell This part of the analysis deals with AeroMACS coverage and capacity capabilities. Taking into account the PHY performance (BER/PER curves) provided by SANDRA project [33] shown in Appendix B.1 and the Barajas path loss model, the maximum possible coverage is evaluated depending on the traffic pattern and the configured retransmission policy (ARQ). By maximum possible coverage the distance at which connections get dropped is meant, because throughput goes to zero; in fact at this distance the PER on the air-interface gets very high, greater than 10E-2, a condition in which communication is severely impacted. An ARQ scheme has been applied to different traffic load conditions (full load, ¼ channel loaded and 1/5 channel loaded) in simulations according to profile specifications. In particular in [9] two possible alternatives are suggested, ARQ type 1 and ARQ type 2. The performance level of each method depends on the specific scenario: ARQ ACK Type 1 presents a reduced feedback overhead when the traffic load is high, while ARQ ACK Type 2 presents the best performance in terms of delays but also showing a relatively low overhead in the feedback channel. Simulation results show that ARQ type 2 is more robust than ARQ type 1 in mediumhigh BER conditions, such as in MCS switching transients and every time channel conditions are harsh (for example when the distance between BS and MS is high). This implies that ARQ type 2 is preferred to ARQ type 1 to better manage these conditions. Comparing the results obtained in the three considered simulation Cases as outlined in more detail in Appendix B it is possible to state that system performance is mainly influenced by two aspects, packet dimension and bandwidth saturation: - if the packet dimension is reduced (Case 3) the probability of receiving wrong packets is lowered, the packet error rate decreases, the retransmissions overhead is reduced, the throughput is higher and more stable for a given distance and the communication range increases - when there is much available bandwidth MCS changes do not reduce the throughput, because more packets can be sent in parallel (Case 2). Conversely if the bandwidth is almost saturated an MCS change halves the throughput and retransmissions overhead limits capacity (Cases 1 and 3) to an extent which 9 At the time of publication of the present document a SPR document covering all of the identified services was not available. As a consequence requirements on service level might change in the future.

101 99 depends on channel impairments and packets length; smaller packet lengths get a benefit from a lower error probability Table 25: Maximum coverage results Maximum coverage (meter) DL UL Full load LOS ARQ ACK Full load LOS ARQ ACK Full load NLOS ARQ ACK /5 traffic- LOS ARQ ACK /5 traffic- NLOS ARQ ACK /4 resources LOS ARQ ACK 2 1/4 resources NLOS ARQ ACK Defining here the maximum coverage as the distance at which the throughput goes to zero for the first time, under all the previously stated hypotheses, we get the results shown in Table 25. As expected NLOS propagation condition is characterized by lower coverage (faster throughput degradation). It can be added that, especially in the LOS case, the maximum coverage of the uplink is slightly more limited than the downlink, even if the PER curves in FL are worse than in RL for SNR greater than about 12.5 db. This is due to the fact that at these distances we are working with signal to noise ratios which are close to that value and the MS has 3 db less maximum power than the BS; considering a shorter cell border where SNRs are higher might yield the opposite conclusion, that the system is downlink limited in coverage, especially in the NLos case Capacity analysis per airport This section evaluates the performance in terms of capacity offered by an AeroMACS system by means of simulation in a modelled airport environment. The approach followed here is different to that used in the previous section, where the study is focused in single AeroMACS cells. In this analysis, the system covers the whole airport area, while a single aircraft is the object of study throughout all the operational stages. For the sake of simplicity, configuration of trajectories and application demands is done by airport domain (e.g. RAMP, GROUND and TOWER). Capacity performance is evaluated through the study of metrics that affect the end-toend availability levels of specific services or Classes of Service (CoS). In addition, specific metrics at MAC layer such as radio packet delay, frame occupation or handover delay deliver information about the performance of the radio link. Results are not given in terms of coverage, which is studied in other sections. This analysis considers instead that the system dimensioning (i.e. number of BSs deployed) is defined in terms of capacity requirements to cover the necessary availability and continuity figures for the services executed on surface. In order to make the analysis as useful and close to reality as possible, a real case airport (Madrid Barajas) has been taken to define the environment. This is a particular case of complex airport type due to the large number of served operations and the large movement area. The air traffic model and mobility model have been extracted

102 RF Cell Planning from real figures that take into account the airport layout and empiric traffic figures. The results have been extracted, however, targeting evaluation metrics that can be considered generic enough to be applied to any airport. Specific cell planning for Barajas is not explained here but is addressed in Appendix C. More details on the capacity analysis can be found in Appendix B. In Appendix B a capacity analysis of an AeroMACS deployment is carried out in an airport situation. An aircraft performing arrival and departure phases has been simulated in a large airport (Madrid Barajas) with a background traffic generated by present aircraft on the surface. Two iterations have been launched in refining the cell planning to cope with the capacity required by the system in the hypothetical case with all the potential identified NET/ATC/AOC services are active. Following this approach, the system has been challenged to its maximum possible capacity level (all possible current and future ATC and AOC services enabled through AeroMACS). A revision of the service list needs to be done by operational stakeholders at deployment stages. It has been shown that AeroMACS can cover the necessary services in this demanding capacity situation if cell planning and QoS configuration are correctly dimensioned. For the services executed when the aircraft is operating in the GROUND and TOWER domains, the system is clearly dimensioned by coverage, however in RAMP more attention needs to be paid to the amount and type of traffic that aircraft turning around will need to generate per sector. Consequently, BS sites in GND/TWR area need to be spaced 2650 m out, while RAMP BSs need to be closer (around 810 m). Regarding QoS, AeroMACS permits a balance to be achieved by means of adjusting the assignation of specific services to real time and non-real time CoS, and assigning a periodic polling rate that guarantees a dedicated data rate depending on the amount of traffic and delay requirements of the aggregated CoS. AeroMACS implementations need to consider the expected data rate for every configured class of service (CoS), in order to guarantee a traffic rate and maximum delay adapted to the requirements of the most stringent services present in each of them. If this aspect is covered, AeroMACS is able to fulfil high throughput (1 Mbps) respecting real time-like delay requirements (80 ms) for an aggregation of different classes of service. See Appendix B for a detailed summary of the system results obtained with different configuration options. Finally it has been shown that AeroMACS fulfils the capacity requirements in terms of handover in the more exigent GROUND and TOWER zones (hence making it also valid for RAMP zone), if a distance between contiguous BS that participate in handover processes of 1300 m is respected (see Appendix B for more details). The reason why GROUND/TOWER zone shows harder conditions for HO execution is twofold: 1) the average cell radius is larger, making the HO happen at a cell edge that is placed further away from the BS at a lower signal level, and 2) the movement pattern of the MS in these zones shows a higher average speed thus suffering from a higher fading attenuation. This demonstrates that an optimized configuration of the AeroMACS cell planning can cope with dynamic behaviours in stringent conditions of terminal speed and link budget with fading. It has to be mentioned that the HO scheme applied is different from what has finally been defined in the AeroMACS Profile. This is because the simulation work supported AeroMACS Profile development and had been finished before final decision on AeroMACS Profile features by RTCA and EUROCAE standardization bodies. Nevertheless simulation results can be considered as worst case scenario, because the HO optimisation is not active. The purpose of this subsection is to identify and provide recommendations for AeroMACS cell planning and for reducing intra and inter-system interference. This will be done based on real example of deployments, on Barajas airport for frequency planning and intra-system interference, and on Toulouse airport for inter-system interference (MLS AeroMACS) which will be studied in Appendix C Case Study 2.

103 101 Because FFR (Fractional Frequency Re-use) is not mandatory in AeroMACS, if any interference appears during a cell planning, an optimization of either the frequency arrangement or BS localization will have to be done in an iterative process. As result of this cell planning process the number of base stations could change. In this case, the planning tool needs to apply an iterative process in order to provide the best solution for any airport and in particular for the deployment within Barajas or Toulouse airports. Considering real cases: Barajas airport (large airport) As no interference has been found on frequency allocation planned, no optimization has been processed. An optimization process could arise for other cases, where frequency availability would be very limited or where area to cover and capacity to achieve is high. The radio coverage is sufficient at this step. A deeper optimization would be useful when real deployment will occur. Toulouse airport (small airport) Cell planning is basic, and focus has been done on inter-system interference analysis (see also Appendix C).

104 102 CHAPTER 11 SECURITY REQUIREMENTS AeroMACS SHALL provide protection against unauthorized entry. AeroMACS SHALL support security control mechanism in order to avoid unauthorized users to reach and get ATC/AOC/NET services and interact with other parts of the infrastructure. NOTE: AeroMACS by means of Access Control mechanisms is able to deal with different types of access control rights. AeroMACS SHALL perform user authentication. NOTE 1: According to ARINC 842, aircraft identification is performed through tail numbering and optionally including ICAO 24-bit ID. This information is included in the AeroMACS user certificate issued for an aircraft MS. NOTE 2: User authentication means software loadable device certificate. In this context, AeroMACS user authentication is understood as the possibility to install a custom certificate from a trusted Certification Authority under management of ICAO, EUROCONTROL, FAA or other organization to authenticate a physical device, while NOTE 3: application user authentication is understood as authentication of an end user at the application that is using the AeroMACS system for communication. Application user authentication is out of the scope of AeroMACS and hence left to implementation. In order to support authentication AeroMACS SHALL support the Public Key Infrastructure utilizing X.509 certificates. AeroMACS MS and AAA server SHALL support EAP-TLS framework. AeroMACS SHALL support mechanisms and procedures to ensure packet integrity and the continuous verification of the sender of the packet. AeroMACS, in order to provide secured communications within the air interface (MS/BS) SHALL implement security association with cryptographic suites. AeroMACS SHALL implement two types of Security Associations: primary and static. NOTE: A Security Association will provide AeroMACS a set of security information by which a secured communication between the MS and the BS is established. The primary SA will enable secured management and data transport connections. The static SA are triggered by the MS when it intends to use a new service and therefore they are dynamically terminated when the data transfer in the service ends. AeroMACS SHALL provide transmission confidentiality. AeroMACS SHALL support AES and CCM-mode Encryption techniques. AeroMACS SHALL implement an authentication client-server protocol for supporting AAA procedures. NOTE: The use of an AAA server will ease other functions like the HA or the HA address in order to accomplish the registration of foreign aircrafts within the visited airport. AeroMACS SHALL give the means to correct billing of data traffic to the respective users (Accounting). NOTE: The implementation of accounting in an AeroMACS deployment scenario will largely depend on the way airport infrastructure will be handled by airport operators. AeroMACS SHALL support the exchange of public certificates between MS and the authorization entities. AeroMACS devices SHOULD present as far as possible, the lowest number of exploitable vulnerabilities.

105 103 NOTE: In case COTS devices are used, public vulnerability databases (e.g. National Vulnerability Database NVD) can be used as they provide updated information on newly discovered vulnerabilities and relative corrective patches. The CVSS scores can be used in order to assess the criticality of a given vulnerability. AeroMACS operators SHOULD use security mechanisms (e.g. Firewalls) to limit the propagation of risk between AeroMACS interconnected nodes. NOTE: A particular attention will be given to protect nodes used at regional or larger scale (e.g. AAA servers, DHCP servers). AeroMACS operators MAY consider manufacturer diversity in the implementation to avoid loss or degradation of service at large scale in case of attacks. AeroMACS operators SHOULD note the intrinsic vulnerabilities of AeroMACS inherited from WiMAX implementation. NOTE: For example, one can take advantage of the fact that RNG-REQ and RNG- RSP messages are not encrypted neither authenticated during Network Entry Procedure to perform Eavesdropping, Denial of Service or Water torture attacks. These vulnerabilities are to be taken into account while implementing and operating AeroMACS considering the context of operation in order to assess the actual related risk.

106 104 CHAPTER 12 TEST CASES In the following subsections two types of test cases are defined. One set of system level test cases provides the required material to certify IPv6, ETHERNET CS and Broadcast / Multicast capability of AeroMACS. For this 3 system level test cases are described: 1) IPv6 n, 2) Ethernet CS, 3) Convergence Sublayer establishment, 4) Broadcast / multicast Text cases 1) and 2) are relevant for certification of the according MAC layer items as outlined in the AeroMACS Profile [51]. They are complemented by the Convergence Sublayer establishment test case. Finally an end-to-end test case similar to the one described in the DLS CS [52] is defined to prove the interoperability of implemented constituents from an application level perspective IPv6 test cases specification The purpose of these test procedures is to verify that an AeroMACS system under test implements IETF RFC 2460 [53], RFC 3315 [55] and RFC 4862 [56] as required in [57]. The test cases in this section are extracted from [66] and cover AeroMACS PICS [57] item 2 in Table Test configuration 1 The following testing configuration is used to verify the IPv6 features in AeroMACS systems. Actual use will depend upon vendor preference, capability and test tool availability in the test laboratory. Wireless capture MS BS Data flow 1 ASN-GW Remote STA1 Roles: - IPv6 access router (stateless case) - DHCPv6 relay (stateful case) Wireline capture Roles: - Data endpoint - AAA - DHCPv6 server (stateful case) IPv6 IPv6 IPv6 IPv6 IP CS IP CS GRE GRE MAC MAC IP* IP* LINK LINK PHY PHY LINK LINK PHY PHY MS PHY PHY Remote STA 1 BS ASN-GW

107 105 Figure 37: IPv6 test cases test configuration *: Either IPv4 or IPv6 can be used in R6 as it is not a requirement for this test specification Tests description The following table summarizes the common preamble and test process that all IPv6 test cases have in common. Configuration Test configuration 1 Conditions Frequency channel: Middle. TX Power Level: Medium. Compressed-IPv6-Header: Enabled. PHS: Enabled. ARQ: Enabled. HARQ: Enabled. Authentication: Any. SS Management: Unmanaged. 1 DL and 1 UL BE Service Flows are Pre-Provisioned at the BS for this MS and the MS can support the Pre-Provisioned Service Flows. Service Flows Classification Rule: Based on IP address/port number.

108 TC-IPv6-STFUL Name: IPv6 CS: Stateful configuration Identifier: TC-IPv6-STFUL Purpose: The AeroMACS system supports stateful address autoconfiguration. Preamble: 1) Start the monitor message capture, if available. 2) Switch on the MS. 3) Carry out the Network Entry procedure with IP-CS. 4) Verifies that the BS sends a DSA-REQ with CS classification Packet IP and the MS accepts it. 5) Carry out one downlink and one uplink BS initiated BE service flows. Steps: No System Action Description 1. AIRCRAFT1 ENTER The AeroMACS MS has successfully completed network entry and device authentication. During authentication DHCPv6 server information has been included. 2. GND1 VERIFY The access router in the ASN sends a Router Advertisement message with the M-flag set. 3. AIRCRAFT1 VERIFY The MS sends a DHCPv6 REQUEST message requesting an IPv6 address to the DHCPv6 server identified during authentication. 4. GND1 VERIFY MS and ASN uses DHCPv6 procedures as defined in RFC 3315 [55] to configure a valid IPv6 address for the MS. 5. AIRCRAFT1 VERIFY The MS can send data traffic to the Remote STA1 (e.g., use ping6 command). 6. AIRCRAFT1 VERIFY When the lease lifetime for the assigned address is near to expire the MS sends a RENEW message to extend the lifetime of the IP address. Postamble: None NOTE 1: Check at MS that a valid IPv6 address has been configured (e.g., use ifconfig command or ip command to check that a global scope IPv6 has been configured, and note the lease time)

109 TC-IPv6-STLESS-VB Name: Identifier: Purpose: Preamble: IPv6 CS: Stateless configuration (valid behaviour) TC-IPv6-STLESS-BV The AeroMACS system supports stateless address autoconfiguration in the case of valid behavior. 1) Start the monitor message capture, if available. 2) Switch on the MS. 3) Carry out the Network Entry procedure with IP-CS. 4) Verifies that the BS sends a DSA-REQ with CS classification Packet IP and the MS accepts it. 5) Carry out one downlink and one uplink BS initiated BE service flows. Steps: No System Action Description 1. AIRCRAFT1 ENTER The MS has successfully completed network entry and device authentication. 2. AIRCRAFT1 VERIFY The MS sends an IPv6 Router Solicitation message to start stateless IP configuration. 3. GND1 VERIFY The access router in the ASN sends a Router Advertisement message. 4. AIRCRAFT1 VERIFY The MS receives a Router Advertisement message, performs stateless auto-configuration of its IP address as defined in RFC 4862 [56] and performs duplicate address detection (DAD) by sending a Neighbor Solicitation message. 5. AIRCRAFT1 VERIFY The MS can send data traffic to the remote STA1 1 (e.g., use ping6 command) Postamble: None NOTE 1: Check at MS that a valid IPv6 address has been configured (e.g., use ifconfig command or ip command to check that a global scope IPv6 has been configured, and note the lease time)

110 TC-IPv6-STLESS-BI Name: Identifier: Purpose: Preamble: IPv6 CS: Stateless configuration (invalid behaviour) TC-IPv6-STLESS-BI The AeroMACS system supports stateless address autoconfiguration in the case of invalid behaviour. 1) Start the monitor message capture, if available. 2) Switch on the MS. 3) Carry out the Network Entry procedure with IP-CS. 4) Verifies that the BS sends a DSA-REQ with CS classification Packet IP and the MS accepts it. 5) Carry out one downlink and one uplink BS initiated BE service flows. Steps: No System Action Description 1. AIRCRAFT1 ENTER The MS has successfully completed network entry and device authentication. 2. AIRCRAFT1 VERIFY The MS sends an IPv6 Router Solicitation message to start stateless IP configuration. 3. GND1 VERIFY The access router in the ASN does not send Router Advertisement message. 4. AIRCRAFT1 VERIFY The MS initiates network exit and re-entry procedures Postamble: None TC-IPV6-FRAG Name: Identifier: Purpose: Preamble: IPv6 CS: IPv6 Fragmentation TC-IPv6-FRAG The AeroMACS system supports IPv6 fragmentation. 1) Start the monitor message capture, if available. 2) Switch on the MS. 3) Carry out the Network Entry procedure with IP-CS. 4) Verifies that the BS sends a DSA-REQ with CS classification Packet IP and the MS accepts it. 5) Carry out one downlink and one uplink BS initiated BE service flows. Steps: No System Action Description 1. AIRCRAFT1 ENTER The MS has successfully completed network entry and device authentication. 2. AIRCRAFT1 VERIFY The MS has completed set-up of IPv6 Initial Service Flow. 3. AIRCRAFT1 ENTER The MS sends an UL IPv6 packet via the IPv6 Initial Service Flow exceeding the MTU size. 4. AIRCRAFT1 VERIFY The IPv6 packet is fragmented into more messages (1). Postamble: None NOTE 1: The existence of IPv6 fragments can be verified only by having a packet analyzer capturing packets in the wired side.

111 Ethernet CS test cases specification The test cases in this section cover AeroMACS PICS [57] item 3 in Table 74 which refers to Ethernet CS as specified in IEEE [39] section Additionally, there are requirements for the PDU format and the classification rules which refer to IEEE [39] section and The purpose of these test procedures is therefore to verify that an AeroMACS system under test implements the following features of Ethernet CS sublayer: Ethernet CS PDU format as required in which refers to [39]. Ethernet CS classification rules as required in which refers to [39] Test configuration 1 The following testing configuration is used to verify the Ethernet CS features in AeroMACS systems. Actual use will depend upon vendor preference, capability and test tool availability in the test laboratory. Data flow 1: IP traffic between Local STA 1 and Remote STA1 Data flow 2: VLAN 1 traffic between Local STA2 and Remote STA2 without QoS. Data flow 3: VLAN 2 traffic between Local STA2 and Remote STA2 with QoS. Hub MS BS ASN-GW Hub Local STA1 Local STA2 Data flow 1 Data flow 2 Data flow 3 (QoS) Remote STA1 Remote STA2 Local STA ETH MS BS ASN-GW ETH ETH ETH ETH ETH Remote STA ETH ETH CS ETH CS GRE GRE ANY MAC MAC IP IP LINK PHY PHY LINK LINK PHY PHY PHY Figure 38: Ethernet CS test cases test configuration NOTE 1: Two stations are needed behind the MS with different IP addresses so that IP header based classification can be verified. NOTE 2: Two flows between the same stations are needed so that Type of Service based classification can be verified (while IP addresses are the same). NOTE 3: There are many classification rules in the IEEE e-2009 (section ). Verifying all of them would not be practical for the test laboratory since it would require a highly complex test configuration. As trade-

112 110 off three rules have been covered in this test specification: VLAN Id rule, IP src/dst rule and IP Type of Service rule.

113 Tests description The following table summarizes the common preamble and test process that all IPv6 test cases have in common. Configuration Test configuration 1 Conditions Frequency channel: Middle. TX Power Level: Medium. Compressed-IPv6-Header: Disabled. PHS: Enabled. ARQ: Disabled. HARQ: Disabled. If a HARQ MAP IE is used to specify the burst, the HARQ MAP IE used to specify the burst is set ACK disable = 1. Authentication: Any. SS Management: Unmanaged.

114 TC-ETH-CS-IP_Rule Name: Identifier: Purpose: Preamble: Ethernet CS: IP header based classification TC-ETH-CS-IP_Rule The AeroMACS system supports IP header based classification. 1) Configure Ethernet CS rules for each service flow as per test case requirements. 2) Start the monitor message capture, if available. 3) Switch on the MS. 4) Carry out the Network Entry procedure with ETH-CS. 5) Verifies that the BS sends a DSA-REQ with CS classification Eth and the MS accepts it. Steps: No System Action Description 1. GND1 ENTER Configure Ethernet CS rules for one Best Effort Uplink service flow between MS and BS that accommodates: - Traffic flow 1 for IP traffic between Local and Remote STA1 by selecting the following rules: Rule 1: Protocol field IPv4 Rule 2: IP source address (Local STA1) Rule 3: IP destination (Remote STA1) 2. GND1 ENTER Configure Ethernet CS rules for one Best Effort Downlink service flow between MS and BS that accommodates: 3. AIRCRAFT1 ENTER Switch on the MS. - Traffic flow 1 for IP traffic between Local and Remote STA1 by selecting the following rules: Rule 1: Protocol field IPv4 Rule 2: IP source address (Remote STA1) Rule 3: IP destination (Local STA1) 4. AIRCRAFT1 VERIFY The AeroMACS MS has successfully completed network entry and device authentication. 5. AIRCRAFT1 VERIFY Verify connectivity (1) between Local STA1 and Remote STA1. 6. AIRCRAFT1 VERIFY Verify the format of the Ethernet CS packets in the Air interface (2). 7. AIRCRAFT1 VERIFY Verify no connectivity between Local STA1 and Remote STA2. Postamble: None

115 TC-ETH-CS-VLAN_Rule Name: Identifier: Purpose: Preamble: Ethernet CS: IP header based classification TC-ETH-CS-VLAN_Rule The AeroMACS system supports VLAN tag based classification. 1) Configure Ethernet CS rules for each service flow as per test case requirements. 2) Start the monitor message capture, if available. 3) Switch on the MS. 4) Carry out the Network Entry procedure with ETH-CS. 5) Verifies that the BS sends a DSA-REQ with CS classification Eth and the MS accepts it. Steps: No System Action Description 1. GND1 ENTER Configure Ethernet CS rules for one Best Effort Uplink service flow between MS and BS that accommodates: - Traffic flow 2 for IP traffic between Local and Remote STA 2 by selecting the following rules: Rule 1: VLAN Id 1 2. GND1 ENTER Configure Ethernet CS rules for one Best Effort Downlink service flow between MS and BS that accommodates: - Traffic flow 2 for IP traffic between Local and Remote STA2 by selecting the following rules: Rule 1: VLAN Id 1 3. AIRCRAFT1 ENTER Switch on the MS. 4. AIRCRAFT1 VERIFY The AeroMACS MS has successfully completed network entry and device authentication. 5. AIRCRAFT1 VERIFY Verify connectivity (1) between Local STA2 and Remote STA2. 6. AIRCRAFT1 VERIFY Verify no connectivity between Local STA2 and Remote STA1. Postamble: None

116 TC-ETH-CS-ToS_Rule Name: Identifier: Purpose: Preamble: Ethernet CS: Type of Service based classification TC-ETH-CS-ToS_Rule The AeroMACS system supports Type of Service based classification. 1) Configure Ethernet CS rules for each service flow as per test case requirements. 2) Start the monitor message capture, if available. 3) Switch on the MS. 4) Carry out the Network Entry procedure with ETH-CS. 5) Verifies that the BS sends a DSA-REQ with CS classification Eth and the MS accepts it. Steps: No System Action Description 1. GND1 ENTER Configure Ethernet CS rules for one Best Effort Uplink service flow between MS and BS that accommodates: - Traffic flow 2 for IP traffic between Local and Remote STA 2 by selecting the following rules: Rule 1: VLAN Id 1 Rule 2: IP Type of Service (None) 2. GND1 ENTER Configure Ethernet CS rules for one Best Effort Downlink service flow between MS and BS that accommodates: - Traffic flow 2 for IP traffic between Local and Remote STA1 by selecting the following rules: Rule 1: VLAN Id 1 Rule 2: IP Type of Service (None) 3. GND1 ENTER Configure Ethernet CS rules for one Best Effort Uplink service flow between MS and BS that accommodates: - Traffic flow 3 for IP traffic between Local and Remote STA 2 by selecting the following rules: Rule 1: VLAN Id 1 4. AIRCRAFT1 ENTER Switch on the MS. Rule 2: IP Type of Service (CS4) 5. AIRCRAFT1 ENTER The AeroMACS MS has successfully completed network entry and device authentication. 6. AIRCRAFT1 VERIFY Verify best effort traffic connectivity (1) between Local STA2 and Remote STA2. 7. AIRCRAFT1 VERIFY Verify that the traffic is carried by two services flows through the air interface, more specifically: SF 1 (UL) carries ICMP Request messages. SF 2 (DL) carries ICMP Response messages. 8. AIRCRAFT1 VERIFY Send UDP datagrams with ToS byte set to CS4 (3) and verify that the datagrams reach Remote STA2. 9. AIRCRAFT1 VERIFY Verify that the traffic is carried by a third service flow (SF 3) through the air interface.

117 115 Postamble: None NOTE 1: Use ping command to Remote STAx IP address in STAx command line interface. NOTE 2: Format of Ethernet CS packets can be verified only by having packet analyzer capturing wireless packets. NOTE 3: Needs to user a traffic generator in Local STA 2 with ability to set ToS byte in the IP packet header.

118 Convergence Sublayer establishment The type of the CS established for the Service Flows is negotiated in the DSA procedure. More specifically, it is indicated by the peers in the CS Specification TLV (section , [54]). Therefore, the landing airborne using Ethernet, IPv4 or IPv6 to access AeroMACS services is decided in this phase of the network entry. According to AeroMACS MOPS, IPv4 CS is mandatory whereas IPv6 CS and Ethernet CS are optional under the labels [IO-IP6V6] and [IO-ETH] respectively Test configuration 1 The following testing configuration is used to verify the IPv6 features in AeroMACS systems. Actual use will depend upon vendor preference, capability and test tool availability in the test laboratory. MS BS ASN-GW Remote STA1 Wireless capture Figure 39: CS Establishment test cases test configuration Tests description The following table summarizes the common preamble and test process that all IPv6 test cases have in common. Configuration Test configuration 1 Conditions Frequency channel: Middle. TX Power Level: Medium. Compressed-IPv6-Header: Disabled. PHS: Enabled. ARQ: Enabled. HARQ: Enabled. Authentication: Any. SS Management: Unmanaged. 1 DL and 1 UL BE Service Flows are Pre-Provisioned at the BS for this MS and the MS can support the Pre-Provisioned Service Flows. Service Flows Classification Rule: Based on IP address/port number.

119 TC-CS-IPv6_FB Name: Identifier: Purpose: Preamble: Steps: No System Action Description 1. AIRCRAFT1 ENTER Switch on the MS. CS Establishment: IPv4 fallback from IPv6 TC-CS-IPv6_FB The AeroMACS system supports fallback to IPv4 CS if the MS does not support IPv6 CS. 1) Start the monitor message capture, if available. 2. AIRCRAFT1 VERIFY The AeroMACS MS has successfully initiated network entry and device authentication. 3. GND1 VERIFY Verify that the AeroMACS BS sends DSA-REQ with CS Specification encoding set to Packet, IPv6 4. AIRCRAFT1 VERIFY Verify that the AeroMACS MS sends DSA-RSP indicating Rejection caused by CS Specification 5. GND1 VERIFY Verify that the AeroMACS BS sends DSA-ACK 6. GND1 VERIFY Verify that the AeroMACS BS sends DSA-REQ with CS Specification encoding set to Packet, IPv4 7. AIRCRAFT1 VERIFY Verify that the AeroMACS MS successfully completes network entry and can send data traffic to the remote STA1 (e.g., use ping command) Postamble: TC-CS-ETH_FB Name: Identifier: Purpose: None Preamble: Steps: No System Action Description 1. AIRCRAFT1 ENTER Switch on the MS. CS Establishment: IPv4 fallback from Ethernet TC-CS-ETH_FB The AeroMACS system supports fallback to IPv4 CS if the MS does not support Ethernet CS. 1) Start the monitor message capture, if available. 2. AIRCRAFT1 VERIFY The AeroMACS MS has successfully initiated network entry and device authentication. 3. GND1 VERIFY Verify that the AeroMACS BS sends DSA-REQ with CS Specification encoding set to Packet, IEEE AIRCRAFT1 VERIFY Verify that the AeroMACS MS sends DSA-RSP indicating Rejection caused by CS Specification 5. GND1 VERIFY Verify that the AeroMACS BS sends DSA-ACK 6. GND1 VERIFY Verify that the AeroMACS BS sends DSA-REQ with CS Specification encoding set to Packet, IPv4 7. AIRCRAFT1 VERIFY Verify that the AeroMACS MS successfully completes network entry and can send data traffic to the remote STA1 (e.g., use ping command) Postamble: None

120 AeroMACS broadcast / multicast test cases The purpose of these test procedures based on [63] is to verify that an AeroMACS system has the ability to use a Multicast Traffic Connections for transmitting the same unencrypted data payload from the network to multiple MS is one single message. The test cases in this section cover AeroMACS PICS [6] item 1 in Table 116. The test cases in this section do not cover layer 3 multicast conformance testing. Therefore, layer 3 multicast procedures such as Join and Leave are assumed to work properly Test configuration The following testing configuration is proposed to verify the Broadcast/Multicast features in AeroMACS systems. Actual use will depend upon vendor preference, capability and test tool availability in the test laboratory. Roles: - Data endpoint (broadcast message sender) Server Local STA1 MS1 Var. Attn (db) BS1 Roles: - Data endpoint (broadcast message receiver) Local STA2 MS2 Var. Attn (db) BS2 ASN-GW Roles: - IGMP router Figure 40. Broadcast/multicast test configuration General considerations: 1. Local STA1 and Local STA2 are the receivers of the broadcast messages. 2. Server is the sender of the broadcast messages. 3. Multicast Traffic Connection is a layer 2 capability to broadcast frames over the air from a BS to the MSs. Additionally, layer 3 multicast addressing is required for carrying the IP flows from the Server to the Local STAs. 4. IPv4 and IGMP have been selected to specify the test cases in this document. Other layer 3 options (e.g., IPv6 and Multicast Listener Discovery) are allowed as long as they are conformant to the AeroMACS standards. a. Either case: Server, Local STA1 and Local STA2 shall belong to the same IP Multicast Group b. Case IPv4: IGMP is part of the routing function of the ASN-GW c. Case IPv6: MLD is part of the routing function of the ASN-GW 5. Packet IP CS rules for one Best Effort Downlink shall accommodate the Traffic flow for IP Multicast traffic between the Server and the MSs: a. Case IPv4: i. Rule 1: Protocol field: IPv4 ii. Rule 2: Destination Address: n, where n is the multicast group of IP devices. b. Case IPv6: i. Rule 1: Protocol field: IPv6 ii. Rule 2: Destination Address: ff02::n, where n is the multicast group of IP devices.

121 In addition to the broadcast/multicast service flows, one pair of unicast Service Flows is required between the BS and each MS to transport IP traffic like IGMP or DHCP signaling. 7. Two Base Stations are used in the test configuration in order to verify broadcast works properly across handover. 8. The variable attenuators are proposed to enforce handover. Another procedure to modify the path loss is left to test laboratory implementation. 9. Server (or another element) shall perform the role of AAA Tests description The following table summarizes the common preamble and test process that all Broadcast/Multicast test cases have in common. Configuration Conditions Test configuration Frequency channel: Middle. TX Power Level: Medium. Compressed-IPv6-Header: Disabled. PHS: Enabled. ARQ: Disabled. HARQ: Disabled. If a HARQ MAP IE is used to specify the burst, the HARQ MAP IE used to specify the burst shall set ACK disable = 1. SS Management: Unmanaged. Security: - Primary SA for the unicast connections will use crypto suite Table 125, Item 6 from AeroMACS System Profile. - Static SA for the multicast connection will use crypto suite Table 125, Item 1 from AeroMACS System Profile. Pre-provisioned service flows: - MS1: DL Service Flow: CID1, Primary SA UL Service Flow: CID2, Primary SA DL Service Flow: CID3, Static SA - MS2: DL Service Flow: CID4, Primary SA UL Service Flow: CID5, Primary SA DL Service Flow: CID3, Static SA

122 TC-MSBS-BASIC Name: Multicast/Broadcast baseline Identifier: TC-MSBS-BASIC Purpose: The AeroMACS system supports layer 3 multicast IP traffic over a layer 2 Multicast Traffic Connection. Preamble: BS1 is On. BS2 is Off. Steps: No System Action Description 8. GND1 ENTER Configure Packet IP CS rules for one Best Effort Downlink service flow between MS and BS that accommodates: - Traffic flow 1 for IP traffic between Local and Remote STA1 by selecting the following rules: Rule 1: Protocol field IPv4 Rule 2: IP multicast group ( n) 9. GND1 ENTER Configure Packet IP CS rules for one Best Effort Downlink service flow between each MS and BS that accommodates: - Traffic flow 2 for IP traffic between Local and Remote STA1 by selecting the following rules: Rule 1: Protocol field IPv4 Rule 2: IP source address (Server) Rule 3: IP destination (MS1) 10. GND1 ENTER Configure Packet IP CS rules for one Best Effort Uplink service flow between each MS and BS that accommodates: - Traffic flow 3 for IP traffic between Local and Remote STA1 by selecting the following rules: Rule 1: Protocol field IPv4 Rule 2: IP source address (MS1) Rule 3: IP destination (Server) 11. GND1 ENTER Configure Packet IP CS rules for one Best Effort Downlink service flow between MS and BS that accommodates: - Traffic flow 1 for IP traffic between Local and Remote STA2 by selecting the following rules: Rule 1: Protocol field IPv4 Rule 2: IP multicast group ( n) 12. GND1 ENTER Configure Packet IP CS rules for one Best Effort Downlink service flow between each MS and BS that accommodates: - Traffic flow 5 for IP traffic between Local and Remote STA2 by selecting the following rules: Rule 1: Protocol field IPv4 Rule 2: IP source address (Server) Rule 3: IP destination (MS2)

123 GND1 ENTER Configure Packet IP CS rules for one Best Effort Uplink service flow between each MS and BS that accommodates: - Traffic flow 6 for IP traffic between Local and Remote STA1 by selecting the following rules: Rule 1: Protocol field IPv4 Rule 2: IP source address (MS2) Rule 3: IP destination (Server) 14. GND1 ENTER Server joins IP multicast group. 15. AIRCRAFT1 ENTER Switch on MS AIRCRAFT1 VERIFY The MS1 has successfully completed network entry and device authentication. 17. AIRCRAFT1 VERIFY Verify connectivity (1) between Local STA1 and Server. 18. AIRCRAFT1 VERIFY Verify the traffic between Local STA1 and Server is encrypted in the air interface (2). 19. AIRCRAFT1 ENTER Local STA1 joins IP multicast group. 20. AIRCRAFT2 ENTER Switch on MS AIRCRAFT2 VERIFY The MS2 has successfully completed network entry and device authentication. 22. AIRCRAFT2 VERIFY Verify connectivity (1) between Local STA2 and Server. 23. AIRCRAFT2 VERIFY Verify the traffic between Local STA2 and Server is encrypted in the air interface (2). 24. AIRCRAFT2 ENTER Local STA2 joins IP multicast group. 25. GND1 ENTER Server generates multicast traffic to IP multicast group (3). 26. AIRCRAFT1 VERIFY Verify Local STA1 receives multicast traffic from Server. 27. AIRCRAFT2 VERIFY Verify Local STA2 receives multicast traffic from Server. 28. AIRCRAFT1 AIRCRAFT2 Postamble: VERIFY Verify that CID3 frames contain unencrypted multicast traffic (2). None NOTE 1: Use ping command to Local STA IP unicast address in Server command line interface. NOTE 2: Wireless analyzer is required. NOTE 3: Use iperf c n b 50K t 10 in Server command line interface and iperf s in Local STA command line interface. Selecting another tool to generate traffic is up to the test laboratory.

124 TC-MSBS-HO Name: Identifier: Purpose: Multicast/Broadcast handover TC-MSBS-HO Preamble: Steps: No System Action Description 1. GND1 ENTER Turn on BS2. The AeroMACS system supports multicast services continuity after HO procedures. TC-MSBS-BASIC 2. GND1 ENTER Increase path loss between MS1, MS2 and BS1. Decrease path loss between MS1, MS2 and BS2. 3. AIRCRAFT1 VERIFY MS1 performs HO from BS1 to BS2. 4. AIRCRAFT2 VERIFY MS2 performs HO from BS1 to BS2. 5. AIRCRAFT1 VERIFY Verify connectivity (1) between Local STA1 and Server. 6. AIRCRAFT2 VERIFY Verify connectivity (1) between Local STA2 and Server. 7. AIRCRAFT1 ENTER Verify Local STA1 continues receiving multicast traffic from Server. 8. AIRCRAFT2 ENTER Verify Local STA2 continues receiving multicast traffic from Server. 9. GND1 ENTER Decrease path loss between MS1, MS2 and BS1. Increase path loss between MS1, MS2 and BS AIRCRAFT1 VERIFY MS1 performs HO from BS2 to BS AIRCRAFT2 VERIFY MS2 performs HO from BS2 to BS AIRCRAFT1 VERIFY Verify connectivity (1) between Local STA1 and Server. 13. AIRCRAFT2 VERIFY Verify connectivity (1) between Local STA2 and Server. 14. AIRCRAFT1 VERIFY Verify Local STA1 continues receiving multicast traffic from Server. 15. AIRCRAFT2 VERIFY Verify Local STA2 continues receiving multicast traffic from Server. Postamble: None NOTE 1: Use ping command to Local STA IP unicast address in Server command line interface. NOTE 2: Use iperf c n b 50K t 10 in Server command line interface and iperf s in Local STA command line interface. Selecting another tool to generate traffic is up to the test laboratory D-TAXI Test cases This test case provides means of interoperability testing compliant with ETSI DLS CS [52] format for real aircraft tests. The purpose of the test is to verify the capability of the ground system to manage an end-to-end dialog through AeroMACS data links by the execution of a CPDLC service sequence between the end users over an authenticated AeroMACS data link with IP connectivity. CM and D-TAXI are considered as the application running. The test is satisfactory if the application

125 123 dialogue is executed satisfactorily, since it proves the correct functioning of data link, IP connectivity, subscriber authentication and user data transmission. The figure presents the test configuration based on [22] reference architecture. CSN GROUND1 MS BS ASN-GW AIRCRAFT1 FIGURE 41: END-TO-END TEST CASE CONFIGURATION Name: Identifier: Purpose: Preamble: CM-Logon: nominal case CM_001 The purpose of the test is to check the Ground System correctly handles the CM-Logon service It is assumed that AIRCRAFT1 is authorized to logon to GND1. As required by ED-110B, the logon request shall provide the optional ADEP and ADES fields. A single stationary MS in AIRCRAFT1 serviced by a single BS of the NAP1 of the Airport. Through NAP1, NSP infrastructure under test, It is assumed that the aircraft MS has already performed network entry with the BS and has been authenticated by the AAA server via the ASN-GW and been distributed the security keys by having passed WiMAX Forum NCT test cases [58] successfully. It is assumed that the MS has acquired an IP address by having passed IPv4 [58], IPv6 or ETH test cases successfully (see test case specification in sections 12.1, 12.2). Steps: No System Action Description 1. AIRCRAFT1 ENTER AIRCRAFT1 sends a CM-logon request to GND1 2. GND1 VERIFY Check GND1 receives the CM-logon indication from AIRCRAFT1. 3. GND1 ENTER GND1 responds with a positive CM-logon response to AIRCRAFT1. 4. AIRCRAF1 VERIFY Check AIRCRAFT1 receives an accepted CM-logon confirmation message providing supported applications by GND1. 5. GND1 VERIFY Check on ground side that AIRCRAFT1 appears logged on GND1 Postamble: None

126 124 Name: CPDLC connection: accepted Identifier: CPDLC_001 Purpose: The purpose of this test is to verify the Ground System correctly handles the CPDLC connection procedure with a logged aircraft. In this test, the request is accepted. This test also includes the CPDLC message exchanges allowing to consider CPDLC enabled (assignment of the Ground System as CDA, provision of the unit name of the R-ATSU). Preamble: It is assumed that AIRCRAFT1 is already logged to the Ground System (c.f. test CM_001). Steps: No System Action Description 1. GND1 ENTER Send a CPDLC-start request to AIRCRAFT1 (no CPDLC message element provided). 2. AIRCRAFT1 VERIFY Check AIRCRAFT1 receives the CPDLC-start indication (no CPDLC message element provided) from GND1. 3. AIRCRAFT1 ENTER Send an accepted CPDLC-start response to GND1. 4. GND1 VERIFY Check GND1 receives the accepted CPDLC-start confirmation from AIRCRAFT1. 5. AIRCRAFT1 ENTER Send the DM99 CURRENT DATA AUTHORITY message to GND1 6. GND1 ENTER Check GND1 receives the DM99 CURRENT DATA AUTHORITY message from AIRCRAFT1. 7. GND1 ENTER Send the UM227 LACK message to AIRCRAFT1 to acknowledge DM99 CURRENT DATA AUTHORITY message. 8. AIRCRAFT1 ENTER Check AIRCRAFT1 receives the UM227 LACK message from GND1 acknowledging the DM99 CURRENT DATA AUTHORITY message. 9. GND1 ENTER Send the UM183 'CURRENT ATC UNIT facility designation, facility name, facility function' message to AIRCRAFT1 10. AIRCRAFT1 ENTER Check AIRCRAFT1 receives the UM183 'CURRENT ATC UNIT facility designation, facility name, facility function' message. 11. AIRCRAFT1 ENTER Send the DM100 LACK message to acknowledge the UM183 'CURRENT ATC UNIT facility designation, facility name, facility function' message 12. GND1 ENTER Check GND1 receives the DM100 LACK message acknowledging the UM183 'CURRENT ATC UNIT facility designation, facility name, facility function' message 13. GND1 ENTER Check AIRCRAFT1 appears as logged on and CPDLC connected to GND1. Postamble: None

127 125 Name: Identifier: Purpose: CPDLC D_TAXI STARTUP TAXI_001 The purpose of this test is to verify the Ground System correctly handles the CPDLC TAXI Start-up Preamble: CPDLC_001 Steps: No System Action Description 1. AIRCRAFT1 ENTER Send the DM25 REQUEST [START-UP] CLEARANCE 2. GND1 VERIFY Check GND1 receives the DM25 REQUEST [START-UP] CLEARANCE 3. GND1 ENTER Send the UM227 LACK message to AIRCRAFT1 to acknowledge DM25 REQUEST [START-UP] CLEARANCE message. 4. AIRCRAFT1 VERIFY Check AIRCRAFT1 receives the UM227 LACK message from GND1 acknowledging the DM25 REQUEST [START-UP] CLEARANCE message. 5. GND1 ENTER Send the UM311 START UP APPROVED 6. AIRCRAFT1 VERIFY Check AIRCRAFT1 receives the UM311 START UP APPROVED 7. AIRCRAFT1 ENTER Send the DM100 LACK message to GND1 to acknowledge the UM311 START UP APPROVED 8. GND1 VERIFY Check GND1 receives the DM100 LACK from AIRCRAFT1 acknowledging the UM311 START UP APPROVED Postamble: None Variants: Repeat

128 126 Appendix A ACRONYMS AND GLOSSARY OF TERMS Term AAA A/C ACSP AeroMACS AK AMC AMHS AMT ANSP AR ARB AOC ARQ AS ASN ASN-GW ATM BB BE BER BS BW CFMU CDM COCR COMT CONOPS Definition Authorisation, Authentication and Accounting Aircraft Aeronautical Communications Service Provider Aeronautical Mobile Airport Communication System Authorization Key Adaptive Modulation and Coding Aeronautical Message Handling System Aeronautical Mobile Telemetry Air Navigation Service Provider Access Router Authoritative Representative Body Airline Operational Communication Automatic Repeat Request Aeronautical Security Access Service Network Access Service Network-Gateway Air Traffic Management Base Band Best Effort Service Bit Error Ratio Base Station Bandwidth Central Flow Management Unit Collaborative Decision Making Communications Operational Concept and Requirements Eurocontrol COM Team Concept of Operations

129 127 Term COTS CSN CSP DCL DDS DL DoS D-TAXI EAD EAP E-ATMS EIRP EUROCAE FA FAB FCI FFS FMTP FOQA H-ARQ H-NSP HMI IP IPsec ITU-R KEK LOS MAC Definition Commercial of the shelf Connectivity Service Network Communications Service Provider Departure Clearance Data Distribution Services Downlink Denial of Service Departure Taxi European AIS Database Extensible Authentication Protocol European Air Traffic Management System Effective isotropic Radiated Power European Organisation for Civil Aviation Equipment Foreign Agent Functional Airspace Block Future Communication Infrastructure For Future Study Flight Message Transfer Protocol Fligt Operations Quality Assurance Hybrid Automatic Repeat Request Home NSP Human Machine Interface Internet Protocol Internet Protocol security International Telecommunication Union Radio Communications Key encryption Key Line of Sight Medium Access Control

130 128 Term MIMO MIP MLS MPLS MS MTOW NAP NET NLOS NRM NSP PKM QoS RF RP rtps RX SA SESAR SF SFA SJU SJU Work Programme SESAR Programme SNR SPR SS Definition Multiple Input Multiple Output Mobile IP Microwave Landing System Multiprotocol Label Switching Mobile Station Maximum Take-off Weight Network Access Provider Network Management Service Non Line of Sight Network Reference Model Network Service Provider Privacy Key Management Protocol Quality of Service Radio Frequency Reference Point Real Time Polling Service Receiver Security Association Single European Sky ATM Research Programme Service Flow Service Flow Authorization SESAR Joint Undertaking (Agency of the European Commission) The programme which addresses all activities of the SESAR Joint Undertaking Agency. The programme which defines the Research and Development activities and Projects for the SJU. Signal to Noise Ratio Safety and Performance Requirements Subscriber Station

131 129 Term SWIM TEK TMA TX TWLU UGS UL VLAN V-NSP VPN WA WMF Definition System Wide Information Management Traffic Encryption Key Terminal Control Area Transmit Terminal Wireless LAN Unit Unsolicited Grant Service Uplink Virtual Local Aera Network ( IEEE 802.1Q) Visiting NSP Virtual Private Network Work Activity WiMAX Forum

132 130 Appendix B CAPACITY ANALYSIS B.1 Capacity and coverage analysis per cell This section presents a preliminary AeroMACS system performance analysis obtained by means of simulation results. These simulations deal with AeroMACS capacity and coverage capabilities. Taking into account the PHY performance (BER/PER curves) provided by SANDRA project and the Barajas path loss model outlined in CHAPTER 10, the maximum possible coverage is evaluated. By maximum possible coverage the distance at which connections get dropped is meant, because throughput goes to zero; in fact at this distance the PER on the air-interface gets very high, greater than 10-2, a condition in which communication is severely impacted. B.1.1 Hypotheses made in simulations This section summarizes results of simulation efforts done within SESAR P to evaluate the capacity offered by an AeroMACS system. At the time of investigation in the SESAR project not all requirements had been finally defined. Especially the considered frequency mask used for the simulation was as follows: Co-channel (N=0): 0 db Adjacent channel (N=1): 32 db Alternate channel (N=2): 50 db These are less stringent requirements than in Table 35, which shows the AeroMACS SARPs mask. This has to be taken into account when considering material related to simulation and calculation of co- and adjacent channel interference levels. Therefore these simulation results can be considered as worst case. Figure 42: Frequency Mask This part of the analysis deals with AeroMACS coverage and capacity capabilities. Taking into account the PHY performance (BER/PER curves) provided by SANDRA project shown in Figures below and the Barajas path loss model, the maximum possible coverage is evaluated depending on the traffic pattern and the configured retransmission policy (ARQ). By maximum possible coverage the distance at which connections get dropped is meant, because throughput goes to zero; in fact at this distance the PER on the air-interface gets very high, greater than 10E-2, a condition in which communication is severely impacted.

133 BER 10-3 CP=1/8Ts,#slot=1 (LIN) CP=1/8Ts,#slot=1 (ID) 10-4 CP=1/16Ts,#slot=1 (LIN) CP=1/8Ts,#slot=195 (LIN) CP=1/16Ts,#slot=195 (LIN) E /N [db] b PER 10-2 CP=1/8Ts,#slot=1 (LIN) 10-3 CP=1/8Ts,#slot=1 (ID) CP=1/16Ts,#slot=1 (LIN) CP=1/8Ts,#slot=195 (LIN) CP=1/16Ts,#slot=195 (LIN) E /N [db] b 0 Figure 43: BER and PER in FL, LOS channel ([50], section 4.4)

134 CP=1/8Ts,#slot=1 (LIN) CP=1/8Ts,#slot=1 (ID) CP=1/16Ts,#slot=1 (LIN) CP=1/8Ts,#slot=195 (LIN) BER E /N [db] b CP=1/8Ts,#slot=1 (LIN) CP=1/8Ts,#slot=1 (ID) CP=1/16Ts,#slot=1 (LIN) CP=1/8Ts,#slot=195 (LIN) 10-2 PER E /N [db] b 0 Figure 44: BER and PER in FL, NLOS channel [50]

135 BER CP=1/8Ts,#slots=102 (LIN) CP=1/8Ts,#slots=1 (LIN) 10-5 CP=1/16Ts,#slots=1 (LIN) CP=1/8Ts,#slots=1(ID) CP=1/8Ts,#slots=102 (ID) E /N [db] b PER 10-2 CP=1/8Ts,#slots=1(LIN) 10-3 CP=1/8Ts,#slots=1(ID) CP=1/8Ts,#slots=102(LIN) CP=1/8Ts,#slots=102(ID) CP=1/16Ts,#slots=1(LIN) E /N [db] b 0 Figure 45: BER and PER for RL, LOS channel [50]

136 CP=1/8Ts,#slot=1 (LIN) CP=1/8Ts,#slot=102 (LIN) CP=1/16Ts,#slot=1 (LIN) CP=1/8Ts,#slot=45 (LIN) BER E /N [db] b CP=1/8Ts,#slot=1 (LIN) CP=1/8Ts,#slot=102 (LIN) CP=1/16Ts,#slot=1 (LIN) CP=1/8Ts,#slot=45 (LIN) PER E /N [db] b 0 Figure 46: BER and PER for RL, NLOS channel [50] The simulations are carried out in a single cell where a single mobile terminal moves away from the BS position with uniform motion and low speed until the throughput goes to zero. The speed of the MS was set to 5m/s (18 km/h). We consider here hard constant bit rate (CBR) 10 traffic; MAC-level SDUs are split in one or more PHY-level PDUs that are then sent over the air-interface. Three different cases have been considered: Case 1: the amount of generated traffic is such that to saturate the available physical bandwidth (the link theoretical capacity). Bandwidth saturation represents a worst case from a channel propagation point of view too, because the packet dimension, i.e. the PDU dimension, is maximum and hence the packet error rate is maximum too. In this case MAC layer gets two SDUs in downlink transmission and one SDU in uplink transmission every 5 ms. Case 2: the amount of generated traffic is one fifth of the link theoretical capacity but all the available resources (the frame slots) can still be allocated to the MS. In this case the link is not fully loaded. MAC layer gets one SDU in downlink transmission and one SDU in uplink transmission every 5 ms. Case 3: the amount of generated traffic is one fifth of the link theoretical capacity (as in case 2 above) but only one fourth of the available resources (1/4 of the frame slots) can be allocated to the MS. Here 10 Hard constant bit rate means a CBR traffic which has also tight restrictions on jitter and latency

137 135 the situation is similar to case 1 with the difference that the available resources in the frame are more limited. Notice that the scheduler has the policy to use as wide as much PDUs to transmit data over the air interface; so this will generally happen in case 1 and case 2 but not in case 3 where resources are limited: in this last case smaller PDUs will be sent with higher frequency over the air interface for the same amount of offered traffic. In the table below the dimensions of the exchanged SDUs are shown: SDU size DL (Byte) UL (Byte) full load /5 full load Table 26: Service Data Unit dimensioning (Bytes) A traffic that saturates the available bandwidth is a traffic which at the physical layer is almost equal to the maximum link theoretical capacity; under the hypothesis of using 16QAM CC ½ and considering a fixed (1:2) UL/DL symbols ratio we get a traffic data rate of 4Mb/s in FL and 1.3Mb/s in RL. The simulator is based on a simplified PHY model, which takes into account the effects of propagation channel (i.e. power losses) on the received signal and the consequent packet errors. Description Symbol Value Transmitted Power BS P TX,BS 23 dbm Transmitted Power MS P TX,SS 20 dbm Cable loss BS L BS 2 db Cable loss MS L SS 2 db Max antenna gain BS G BS 15 dbi Max antenna gain MS G SS 6 dbi Sampling frequency f s 5.6 MHz Carrier frequency f c GHz Noise figure NF 8 db Implementation Loss ImpLoss 5 db Used subcarriers N used 420(FL)/408(RL) FFT dimension N FFT 512 Table 27: PHY Layer parameters With reference to the parameters of Table 27 the received signal power and the SNR are calculated as:

138 136 P P L L G G rx tx tx rx tx rx L SNR P rx where L is the channel propagation loss and N is the noise term equal to: f s N log 10( Nused ) NF ImpLoss N FFT The receiver evaluates the received signal level Prx, if it is higher than the Noise power N the receiver considers the packet as received, calculates its SNR value and addresses a specific PER value in the pre-computed tables allowing further considerations (packet correctly received or packet corrupted). In particular, a random number uniformly distributed between 0 and 1 is drawn and if this value is greater than the PER, the packet is considered correctly received, vice versa the packet is discarded. PER tables are addressed referring to different parameters: SNR, modulation and coding schemes (MCS), channel type (LOS, NLOS). For PER tables 11 we refer to [34][35]. Two different MCSs have been used, QPSK CC ½ and 16QAM CC ½, and two SNR threshold values have been set in FL/RL to switch between them. These thresholds, shown in Table 28 below, have been set in order to select the modulation and coding scheme that guarantees the maximum throughput at each SNR 12. N Adaptive MCS threshold (SNR in db) LOS NLOS UL DL Table 28: MCS switching thresholds In the PHY model the propagation loss L experienced by the transmitted signal is comprised of two components, the Path Loss (PL), that is an increasing function of the distance d, and the Slow Fading (SF), that is a random fluctuation around the average value given by the path loss: L=PL(d)+SF Two different propagation models are simulated, mainly LOS and mainly NLOS, mixing them according to the type of node (aircraft/vehicle) and considered area (Ramp/Tower). The socalled Barajas path loss models have been used in these simulations as propagation loss: log fc 20log d X L d log fc 20log dbp 10 log dbp X d d d d BP BP 11 We are interested in results in 5MHz bandwidth, 1 slot FEC, CP=1/8 and linear channel interpolation 12 It is to be noted that these thresholds might be lower if using a CTC instead of a CC

139 137 where: d BP is the breakpoint distance X is the slow fading term where is the slow fading standard deviation is the path loss exponent for distances above d BP f c is the carrier frequency in GHz Default values for the above parameters are shown in Table 29: Base Station height d BP BS1-MR1 12m 144m BS2-MR1 38m 292m BS1-MR2 12m 52m BS2-MR2 38m 141m Table 29: Barajas Pathloss models parameters The above table refers to a measure campaign executed in the Barajas Airport. In particular, two Base Stations (BS1 and BS2) were located at different heights of the West Tower of Barajas, which is located among the gates of Terminal 4. BS1 was located 12 meters above the airport surface, while BS2 was located 38 meters above the airport surface. Two mobile routes (MRs) were defined, related to BS1 and BS2. The Mobile Route MR1 is provided in Figure 47. This route started almost below the tower, and ended by the end of the terminal building about 700 meters away from the tower. The second Mobile Route MR2 went in between parked aircraft, and not underneath the gates (see Figure 48).

140 138 Figure 47: Mobile Route MR1 Figure 48: Mobile Route MR2 A BS height equal to 38m has been considered, hence BS2-MR1 is used in NLOS propagation conditions and BS2-MR2 is used in LOS propagation conditions. As a rule RAMP areas are considered as characterized by LOS (aircrafts) or NLOS (vehicles) propagation conditions respectively; TOWER areas are considered to be always characterized by LOS propagation conditions. In order to evaluate coverage worst case propagation conditions need to be considered, so in this case BS2-MR1 without slow fading is applied to get more deterministic results. An ARQ scheme has been applied in simulations according to profile specifications. In particular in [10] two possible alternatives are suggested, ARQ type 1 and ARQ type 2. Both types have been considered in these simulations but results will only be presented for ARQ type 2 which showed to be more robust under medium-high BER conditions from a packet loss perspective (especially during MCS switching transients). ARQ type 1: (cumulative ACK mode). In cumulative mode, bit-wise maps are not used, hence the ARQ feedback is constantly 32 bits wide. BSN field is exploited to indicate that the corresponding block and all previous blocks (i.e., blocks with smaller BSN) have been successfully received. The cumulative ACK does not utilize explicit NACK, so the retransmission occurs when the Retransmission

141 139 Timer of a given block expires. The maximum number of acknowledgeable blocks for each ARQ feedback IE is not prefixed. ARQ type 2: (cumulative with selective ACK mode) This combines two ACK types: the BSN is used to acknowledge all the blocks smaller than the indicated value, then from 1 to 4 ACK maps are exploited to represent the blocks successfully received and the blocks that need to be retransmitted. Hence, the ARQ feedback IE extension varies from 48 to 96 bits and the number of blocks that can be acknowledged is not prefixed. Briefly, ARQ type 1 acknowledges transmission blocks in a cumulative way indicating the last block of the sequence correctly received so far. The retransmission in this case occurs after a time-out at the transmitter and all the blocks after the last acknowledged one are retransmitted. On the other side, ARQ type 2 combines the cumulative and the selective methods theoretically exploiting the advantages of both techniques. The feedback is composed of a cumulative part and a selective part. Main ARQ parameters are set as in Table 30: Parameter ARQ Block Size [bytes] Value 64 UL / 256 DL ARQ Window Size [ARQ blocks] 512 ARQ Block Lifetime [s] ARQ Retry Timeout (Retransmission Time Interval-RTI) [s] 6xRTI 0,1 Table 30: Main ARQ parameters Additional secondary-level parameters are set as in Table 31: Parameter ACK Type 1,2 In-Order SDU Delivery Rearrangements Feedback Time Interval enabled enabled Every 16 ARQ blocks correctly received Number of IE for each feedback message 1 Number of maps for each IE 1

142 140 Table 31: Secondary-level ARQ parameters Regardless of the size, every PDU consists of an integer number of ARQ blocks. For example in the case of only one MS the composition of PDUs and ARQ blocks is shown in Table 32: UPLINK DOWNLINK Q-PSK 1/2 16-QAM 1/2 Q-PSK 1/2 16-QAM 1/2 Size of PDU (slots) Size of slot (bytes) # ARQ blocks in PDU Size of ARQ block (bytes) Table 32: Size of PDU and ARQ blocks A description of the IP layer model can be found in [10] B.1.2 Analysis of results This section presents the capacity and coverage simulation results in a cell. In the simulated scenario there is only one node which starts to move after 10 seconds from BS position in radial direction with uniform motion and a speed equal to 5 m/s (18 km/h). The selected output metrics are: Throughput Packet loss For the goal of these simulations, evaluation of maximum coverage and packet delay has no relevance. As a matter of fact under a full traffic load condition high delays will occur when the terminal is far from the BS and will use QPSK modulation. The throughput values refer to the MAC SDUs reassembled at the receiver in each second. The transmitter sends through the MAC PDUs the different ARQ blocks of a SDU that are actual numbered SDU fragments. When every ARQ block of a SDU is correctly received at the receiver, the SDU is reassembled and sent to the upper layer. When a received ARQ block in a SDU still contains an error after the maximum number of retransmissions has elapsed the whole SDU is rejected and counted in the statistics of packet loss. So packet loss can be defined as the number of packets that are discarded by the transmitter after a certain number of retransmissions have failed. So the retransmission of packets does not enter into the calculation of throughput and packet loss metrics. Furthermore the packets that are dropped because the transmission queue is full (i.e. packets that are not even scheduled for transmission) are not considered in the statistics, i.e. packet loss refers only to channel effects.

143 141 Figure 49: Throughput & Packet Loss with ARQ Type 1 and ARQ type 2 (UL) Results provided here are comparing throughput performance with respect to ARQ ACK types 1 and 2 usage. A traffic load almost equal to the theoretical link capacity and LOS propagation conditions are assumed. As Figure 49 shows ARQ type 2 assures better performance than ARQ type 1 in mediumhigh BER conditions since it manages retransmissions in a more efficient way. At the beginning transmission is optimal and the channel causes very few errors, which are managed by ARQ with negligible overhead. After about 120 seconds the propagation channel starts to insert more errors in the packets, leading to a throughput reduction due to a larger amount of retransmitted packets and a ripple effect in the throughput due to local delays in successfully delivered packets; still no packet loss is measured. At about 175 seconds the MCS is changed, switching from 16QAM to QPSK, to adapt to the worse channel conditions: throughput stabilizes to around ½ of the initial value and channel errors are reduced; during this transient phase some packets are lost if ARQ type 1 is used. After about 210 seconds the channel starts again to insert more and more errors in the packets, thus causing a gradual decrease in capacity due to retransmissions and a ripple in the throughput due to local delays. Packet loss remains null until around 265 s for type 1 and 285 s for type 2; afterwards channel conditions become so harsh that packet losses grow up very rapidly thus causing a rapid decrease in throughput too. After 310 s, corresponding to a distance of 1500 meters, throughput goes to zero, thus causing packet loss going to zero in turn, transmitter stops sending packets and the connection is virtually lost.

144 142 The performance behavior of the downlink looks much like the uplink one. So ARQ type 2 seems to achieve better performance in terms of packet loss and throughput, especially during MCS switching and when channel conditions are harsh. As a result of previous simulations all following results will be given for ARQ type 2 only. Afterwards simulations were carried out in different conditions of traffic load and available resources as described previously in Case 1, Case 2 and Case 3; results were analyzed as function of Los/NLos propagation conditions and UL/DL directions. In the following figures throughput and packet losses will be shown, in Cases 1, 2, 3 respectively, for the downlink only, but pretty much equivalent results hold for the uplink too.

145 143 Figure 50: Case 1: Throughput & Packet Loss in Los/NLos (DL) Figure 51: Case 2: Throughput & Packet Loss in Los/NLos (DL)

146 144 Figure 52: Case 3: Throughput & Packet Loss in Los/NLos (DL) The general behavior of the curves is the same as that observed in the ARQ type comparison: in a first step 16QAM transmission is used, with degrading performance while channel impairments grow up, until a time in which a switch to QPSK occurs (at about 160 s in Los and 125 s in NLos conditions) which causes throughput to temporarily stabilize. After some further time performance degrades again until packets are lost, throughput nullifies and the connection is virtually stopped (the persistent ripple phenomena on the packet loss of Figure 52 - NLos case - are artifacts of the simulation which are not relevant for the results). From the figures it can be seen that i) the NLOS propagation condition causes a quicker degradation of performance and hence a smaller coverage ii) in Case 2 the change in modulation does not change the throughput because a lot of free resources are still available, where more than twice of the original resources can be used to sustain the source traffic rate iii) in Case 3 the range is a little bit increased with respect to Cases 1 and 2 (in fact the throughput goes to zero after a longer time period, at about 375 s in LOS and 250 s in NLOS). This last result, which might seem surprising, is caused by the scheduler algorithm implemented, because in Case 3 resources are limited, hence the scheduler will be forced to use shorter packets, transmitted of course with a higher frequency for the same amount of offered traffic. If the MAC PDUs are smaller the probability of error due to channel impairments decreases, assuring a better performance. Thus the BS scheduler could exploit smaller PDUs to transmit data to distant users with a more stable rate. This clearly indicates how important the scheduling algorithm for the overall system performance is. Results for the uplink follow the trends of the downlink, hence the same considerations apply. B.2 Capacity analysis per airport B.2.1 Operational concept This section evaluates the performance in terms of capacity offered by an AeroMACS system by means of simulation in a modeled airport environment. The approach followed here is different to that used in the previous section, where the study is focused in specific airport domains. In this analysis, the system covers the whole airport area, while a single aircraft is the object of study throughout all the operational stages. For the sake of simplicity, configuration of trajectories and application demands is done by domain, as explained in the proper sections. Capacity performance is evaluated through the study of metrics that affect the end-to-end availability levels of specific services or Classes of Service (CoS). In addition, specific metrics at MAC layer such as radio packet delay, frame occupation or handover delay deliver information about the performance of the radio link. Results are not given in terms of coverage, which is studied in other sections. This analysis considers instead that the system dimensioning (i.e. number of BSs deployed) is defined in terms of capacity requirements to cover the necessary availability and continuity figures for the services executed on surface. In order to make the analysis as useful and close to reality as possible, a real case airport (Madrid Barajas) has been taken to define the environment. This airport is a particular case of most complex airport type due to the large number of served operations and the large size. The air traffic model and mobility model have been extracted from real figures that take into account the airport layout and empiric traffic figures. The results have been extracted, however, targeting evaluation metrics that can be considered generic enough to be applied to any airport. Specific cell planning for Barajas is not explained here but is addressed in Appendix C.

147 145 B.2.2 Propagation and PHY/MAC layer model This analysis focuses on system level capacity, while effects of physical channel, propagation and PHY features (BLER and SNR calculation) are abstracted. The configuration at this level follows the same models as in WA3 simulations with OPNET Modeler [9] which provides additional details on the physical layer configuration. Briefly, the propagation channel configuration uses the analytical channel model for Barajas. HARQ is enabled and adaptive operation of every mandatory modulation and coding scheme (i.e. all except 64QAM in UL) are active. The BS and MS have ARQ and HARQ configured as in [51]. The ARQ mode used in this scenario is Mode 2 Cumulative and Selective ACK. Aircraft object of study The A/C object of study is configured in a deterministic basis. It is considered that, for data generation purposes, it follows the application model explained in CHAPTER 3. As it is indicated in the model description, the A/C executes a deterministic sequence of services that represent consecutive arrival and departure operations. The A/C also follows a deterministic trajectory and speed according to the airport layout and following a reasonable track to complete the operations. Note that the trajectory strongly affects the execution of the service sequence, since the chronological execution depends on the instantaneous position of the A/C in the departure and arrival processes. Airport zones have been split in three different zones, depending on the movements performed by the aircraft on surface, namely RAMP, GROUND and TOWER. In each zone the aircraft is configured with a different average speed, values are shown in table below: Arrival Speed [km/h] Speed [knots] TOWER GROUND RAMP Table 33: Arrival speeds Departure Speed [km/h] Speed [knots] RAMP 10 (in push-back) 20 (in taxiing) GROUND

148 146 TOWER Table 34: Departure speeds Due to the difference in trajectories followed by aircrafts in airport depending on a wide number of factors (atmospheric conditions, runway availability, assigned terminal position, airline operatives, etc), four different routes have been set in simulations, two in arrival phase, and two for departure phase. B.2.3 Scenario 1 This scenario assumes an AeroMACS equipped aircraft that completes the operational phases of arrival, turnaround and departure in a consecutive manner. This is the most stringent operational case since the aircraft needs to minimize the time in the airport in order to avoid flight delays caused by the departing or the previous arriving flight. In this situation, the aircraft is assumed to land on the 33L runway (South). Then, it performs taxiing to Terminal 2 allocated slot for turnaround. The aircraft finally takes off on the 36L runway (North). This scenario tries to illustrate the context in which the aircraft performs long carrier or transoceanic flights. This kind of flights has long permitted turnaround times, which is normally operated by major airlines. It is assumed that the runways are closer to the terminal, thus yielding the taxiing time interval minimum. However, this is not always the pattern followed by main airlines in this airport. Arrival For arrival trajectory we estimate a speed of 90km/h about the half of the runway (yellow), then the A/C waits for authorization during a holding time of 5 minutes. After that the A/C cross the GROUND zone at an average speed of 40 km/h (blue) and arrives to the RAMP zone at a speed of 20 km/h (red) stopping finally at the terminal finger.

149 147 Figure 53: Scenario 1 arrival trajectory This sequence assumes that the aircraft will start synchronization once it enters TOWER zone below 50 knots speed, which happens when it surpasses half the length of the runway. It is also assumed that AeroMACS onboard the aircraft is connected and operational at the runway exit. Total time for the arrival process (please note that time is the time between landing and the arrival to the airport terminal finger, it does not include disembarking) is 300 seconds, we show time values for each zone in the Table 35. After the stop of the aircraft the process of disembarking starts, time during the A/C still stays executing service. Time for each zone is shown in the table below. TOWER GROUND RAMP Post-arrival Total arrival Arrival [seconds] Distance [meters] Speed [km/h]

150 148 Table 35: Scenario 1 arrival trajectory times According to the study of services description in CHAPTER 3 some of those services could be executed in parallel or not, because it is not strictly necessary for them to wait for previous services to have finished. However other ones need to wait for previous services to have finished. So, services grouped in the following tables with the same background colour and labelled with the same number could be executed in parallel. Each service is started in one of the airport zones (RAMP, GROUND, TOWER) according to the colored right column. For example, OOOI messages must be sent when the A/C passes from Ground zone to Ramp independently of previous services ending and because of that it is classified as a parallel service. The ACM service is executed when all the previous services have finished because in arrival phase and executed in the Ramp zone it finishes the communication. t[sec] Aircraft->Base Station Service Execution order ToS Service Base Station->Aircraft 0 OOOI S1 AOC 0 NETKEEP S1->P NET NETKEEP 0 AUTOLAND-REG S1-P AOC TOWER 63 ACM S2 ATC ACM 64 S2->P (periodic) ATC SURV 65 ACL S3 ATC ACL 69 D-SIG S4 ATC D-SIG 69 D-TAXI S4->P ATC D-TAXI GROUND 69 EFFU S4->P AOC EFFU 69 FLT-JOURNAL S4->P AOC 69 TECHLOG S4->P AOC TECHLOG 69 CREW-TIME S4->P AOC 254 OOOI S4->P AOC 254 FOQA S4->P AOC

151 FLTLOG S4->P AOC 252 CABINLOG S4->P AOC RAMP 252 ETS-REPORT S4->P AOC 252 REFUEL S4->P AOC When previous services have finished ACM S5 ATC ACM Table 36: Chronological description of Scenario 1 arrival trajectory NOTE: The flag p indicates the service is executed in parallel (i.e. have the same initial instantiation time) with previous ones having the same sequence number (Sx). Departure In the Departure phase we have a previous time not considered here during which the A/C is executing services but it is not moving, for example during the boarding of passengers, baggage cargo, etc. The time while the A/C is moving starts with an initial pushback phase in the RAMP zone and finish about half of the runway where we exceed AEROMACS maximum speed supported. Please note the black line corresponds to the pushback procedure (10 km/h).

152 150 Figure 54: Scenario 1 departure trajectory The departure time while the A/C is moving takes 868 seconds. The total time for the departure process showed (this time is taken since the A/C is towed when the Pushback starts until the A/C has gone over half of the runway) does not include boarding time and pre-departure times, time when the A/C is executing services. Time for each zone is shown in the table below. Predeparture Pushback RAMP Taxiing RAMP GROUND Taxiing TOWER Holding Time TOWER Total departure Departure [seconds] Distance [meters]

153 151 Speed [km/h] Table 37: Scenario 1 departure trajectory times The main difference between arrival and departure phase is the critical timeout of services, because all services must have finished before A/C departure.

154 152

155 153 Table 38: Chronological description of Scenario 1 departure trajectory Taking this service sequence, the average generated ATC message size is 190 Bytes, and the average generated AOC message size is 278 kilobytes [6]. B.2.4 Scenario 2 In this situation, the aircraft is assumed to land on the 33R runway (South). Then, it performs taxiing to Terminal 2 allocated slot for turnaround. The aircraft finally takes off on the 36R runway (North). This scenario tries to illustrate the context in which the aircraft performs short regional flights. This kind of flights has short permitted turnaround times, which is normally operated by regional or low fare airlines. It is assumed that the runways are the furthest from the terminal, thus yielding the taxiing time interval maximum. However, that this is not always the pattern followed by regional airlines in this airport. Arrival Exactly as happens in Scenario 1, we estimate a speed of 90km/h about the half of the runway (yellow) until the end of this, after this the A/C waits for authorization during a holding time of 5 minutes, then the A/C cross the GROUND zone at an average speed of 40 km/h (blue) and arrives to the RAMP zone at a speed of 20 km/h (red) stopping finally at the terminal finger.

156 154 Figure 55: Scenario 2 arrival trajectory According to the description of arrival time used above the total time while the A/C is moving is 540 seconds. TOWER GROUND RAMP Post-arrival Total arrival [sec] Arrival [segs] meters km/h

157 155 Table 39: Scenario 2 arrival trajectory times This list of services and time between them are exactly the same that appears in Scenario 1 with the exception of the FOQA service whose size is now Bytes. t[seconds] Aircraft->Base Station Service Base Station- >Aircraft Execution order ToS Service 0 OOOI S1 AOC 0 NETKEEP S1->P NET NETKEEP 0 AUTOLAND-REG S1-P AOC TOWER 63 ACM S2 ATC ACM 64 S2->P (periodic) ATC SURV 64 ACL S3 ATC ACL 64 D-SIG S4 ATC D-SIG 64 D-TAXI S4->P ATC D-TAXI GROUND 64 EFFU S4->P AOC EFFU 64 FLT-JOURNAL S4->P AOC 64 TECHLOG S4->P AOC TECHLOG 64 CREW-TIME S4->P AOC 461 OOOI S4->P AOC 463 FOQA S4->P AOC 463 FLTLOG S4->P AOC 510 CABINLOG S4->P AOC RAMP 510 ETS-REPORT S4->P AOC 510 REFUEL S4->P AOC

158 156 When previous services have finished ACM S5 ATC ACM Table 40: Chronological description of Scenario 2 arrival trajectory. Departure According to the description of departure used above the trajectory for departure followed by the A/C and the time it takes is shown below.

159 157 Figure 56: Scenario 2 departure trajectory According to the description of arrival time given in Scenario 1 the total time while the line A/C is moving is 913 seconds. Pre-departure Pushback Taxiing Holding Time Total RAMP Taxiing RAMP GROUND TOWER TOWER Departure Departure [segs] Distance [meters] Speed [km/h] Table 41: Scenario 2 departure trajectory times This list of services and time between them are the same that appears in B.2.3 with the exception of the following ones: E-CHARTS size is now Bytes FOQA size is now Bytes This is due to the fact that short-range aircrafts exchange a much lower amount of data to update the electronic flight charts and upload the log of the flight events. Additional information is provided in the SESAR AOC study [28].

160 158

161 159 Table 42: Chronological description of Scenario 2 departure trajectory Taking this service sequence, the average generated ATC message size is 190 Bytes, and the average generated AOC message size is 63 kilobytes [6]. B.2.5 QoS model Every service needs to be mapped to a Class of Service (CoS). Each CoS will be treated differently per service flow by AeroMACS, by guaranteeing a maximum latency or minimum throughput. This leads to prioritization politics in AeroMACS transmission queues, by optimizing the packet transmission rate that covers all the service class policy. QoS model proposed in this analysis is based on the two existing references that are applicable to AeroMACS, namely: ICAO 9896 [12] provides a recommendation to support legacy ATN applications over the IPS, mapping ATS services to proposed CoS (very High, High, Normal and Best Effort), shown in Table 43. The classification recommended for AeroMACS is outlined in the Table 44. This service categorization has been extracted from COCRv2 [1] and SJU AOC service studies [28].

162 160 Table 43: ATN/IPS priority mapping into classes proposed by [12] The CoS classification used in this analysis can be seen below. It is based on the basic classification outlined in Table 6, and ICAO recommendation is taken as guidance to define the mapping for ATS services. These have been classified in three categories according to the application they are part of. The link with SESAR WA2 defined CoS [6] is shown in Table 44. Regarding AOC, they have been classified into the two existing categories according to the load/latency requirement ratio as well as the CoS allocation in Table 6. Hence, a priority AOC category covers services that transmit a low amount of information in a reduced time normally related to clearances and reports. The lowest AOC category involves transfer of high amount of information (e.g. updates, files, etc) and is aimed to be executed in the background with the remaining free bandwidth. Table 44: CoS classification for Airport Capacity Analysis CoS Services included SESAR P CoS

163 161 NET ATS1 ATS2 ATS3 NET services NETKEEP, NETCONN FPS by ADS-C SURV CIS (CPDLC) ACL, COTRAC, DCL, D-TAXI FPS FLIPCY, FLIPINT, PPD DCM DLL, ACM FIS D-OTIS, D-SIGMET, D-RVR, D-SIG AVS D-FLUP AOC1 AOCDLL, CABINLOG, FLTLOG, FLTPLAN, LOADSHT, OOOI, TECHLOG, WXGRAPH, WXRT, WXTEXT, BRFCD, DOOR, ACLOG, AIRWORTH, AUTOLAND-REG, BAGGAGE, NOTAM, CATERING, CREW-L, CREW-RPS, CREW-BUL, CREW-REG, CREW-TIME, FLOWCON, REFUEL, HANDLING, LOADDOC, NOTOC, PASSENGER, PREFLT-INS, TAKEOFF-CALC AOC2 SWLOAD, UPLIB, EFF, EFFU, E-CHARTS, FLTJOURNAL, FOQA, SWLOAD25, SWCONF [6] DG-A DB-D DG-C DG-D DG-C DG-D DG-F DG-J DG-K DG-K DG-L This model for CoS 13 has been taken as hypothesis to develop the QoS configuration in the capacity analysis. Regarding the requirements set by each CoS, service flows and QoS parameters will be defined at the radio link to be compliant with the required figures. In order to configure a set of priority levels for the different applications executed over AeroMACS in the simulation, a refinement of the CoS classification from CHAPTER 3 is proposed here. For every Class of Service defined and applied at higher-layer messaging, a mapping is done to a specific QoS type applied by AeroMACS. Each QoS level defines the scheduling type, the estimated traffic reserved for the service type and the queuing algorithm. Note that AeroMACS, as based on the IEEE standard series, does not imply hard priority between levels (i.e. packet by packet prioritization) but a QoS approach in which each level has been properly dimensioned to be able to guarantee a minimum throughput and maximum delay. Due to this, the QoS configuration in AeroMACS becomes complex and strongly depends on the specific operational concept. In this analysis, we will consider the configuration for the situation in which all the identified potential services are included, as previously explained. The possible scheduling types admitted by the profile for data services are the following: Non-real Time Polling Service (nrtps) offers unicast polls on a regular basis, assuring a minimum reserved data rate even during network congestion. Bandwidth requests in queue are treated using 13 For ADS-C and CPDLC applications a different priority level has been selected compared to the ATN/IPS priority mapping. Reason for that is that EUROCAE WG78 classification requires it.

164 162 the Modified Deficit Round Robin (MDRR) scheduling algorithm. Although the algorithm is implementation-dependent, for the sake of simulation a minimum polling rate is established. Real Time Polling Service (rtps) offers real-time, periodic request opportunities that allow the subscriber to specify the size of the desired resources. Bandwidth requests in queue are treated using the Modified Deficit Round Robin (MDRR) scheduling algorithm. While rtps requires more signalling overhead than nrtps, it allows a periodic request interval of the order of milliseconds. It will be used for the most critical services that require a maximum delay per message of milliseconds, but is usually not configured for heavy load services since it would have a strong impact on the allowed traffic for other messages. Best Effort (BE) guarantees no minimum throughput for the connection. It uses the remaining frame resources (if any) after the rest of connections have been allocated. In the simulation, the algorithm used to serve the queues is Round Robin (RR). The target of this scheduling type is heavy services that need to run in the background and are not delay sensitive. The table below depicts the QoS level mapping proposed for every defined CoS at this analysis. For each QoS level, the relevant parameters used to define the polling rate are indicated. Note that this configuration is not a requirement for all AeroMACS deployments. CoS Services included SESAR P CoS [6] AeroMACS QoS NET NET services DG-A rtps NETKEEP, NETCONN Max latency = 1s Min throughput =32 kbps ATS1 FPS by ADS-C DB-D rtps SURV Max latency = 1.5 s Min throughput = 32 kbps ATS2 CIS (CPDLC) DG-C rtps ACL, COTRAC, DCL, D-TAXI FPS DG-D FLIPCY, FLIPINT, PPD ATS3 DCM DG-C nrtps DLL, ACM FIS D-OTIS, D-SIGMET, D-RVR, D-SIG AVS DG-D DG-F Min throughput =32 kbps

165 163 D-FLUP AOC1 AOCDLL, CABINLOG, FLTLOG, FLTPLAN, LOADSHT, OOOI, TECHLOG, WXGRAPH, WXRT, WXTEXT, BRFCD, DOOR, ACLOG, AIRWORTH, AUTOLAND-REG, BAGGAGE, NOTAM, CATERING, CREW- L, CREW-RPS, CREW-BUL, CREW-REG, CREW-TIME, FLOWCON, REFUEL, HANDLING, LOADDOC, NOTOC, PASSENGER, PREFLT-INS, TAKEOFF- CALC DG-J DG-K nrtps Min throughput =64 kbps (UL), 128 kbps (DL) AOC2 SWLOAD, UPLIB, EFF, EFFU, E-CHARTS, FLTJOURNAL, FOQA, SWLOAD25, SWCONF DG-K DG-L BE Table 45: CoS classification for Airport Capacity Analysis B.2.6 Handover configuration The handover configuration is similar to that in [10] sections 3.3 and Handover MS Handover Retransmission Timer [ms] 30 Maximum Handover Request Retransmissions 6 Handover Threshold Hysteresis [db] 6 Maximum Handover Attempts per BS 10 Scan Duration (N) [Frames] 5 Interleaving Interval (P) [Frames] 140 Scan Iterations 3 Table 46: Handover parameters MS Handover Retransmission Timer: Time the Mobile Station will wait for a response after sending a MOB_MSHO-REQ message to the Serving Base Station. If no response (MOB_BSHO-RSP) is received within this time the Mobile Station will retransmit the MOB_MSHO-REQ message (until the maximum number of retransmissions is reached). Maximum Handover Request Retransmissions: Maximum number of retransmission attempts for the MOB_MSHO-REQ message. If set to 0 (zero) or "No Retransmissions", the Mobile Station will send the original MOB_MSHO-REQ and after expiration of "Handover Request Retransmission Interval" it will not retransmit the handover request. It will abandon the handover process instead.

166 164 Handover Threshold Hysteresis: Specifies the minimum difference that a neighbour BS's CINR must be above the serving BS's CINR before triggering a handover decision to replace the serving BS with the neighbour BS. Maximum Handover Attempts per BS: Maximum number of attempts to handover to a specific target BS when the serving BS responds with a negative BSHO-RSP to the MS for that target BS. When Access Service Network is used by the serving BS to contact the target BS in advance (HO_Req), the target BS can indicate that it does not have enough resources to admit the MS. In this case the serving BS will indicate a rejection in its BSHO-RSP to the MS. This attribute prevents the MS from keep trying indefinitely to handover to a target BS with no resources. If set to "Disable", then the MS will ignore the BSHO-RSP and will continue with the handover process regardless of the capacity of the target BS. Scan Duration: Time (in frames) the Mobile Station scans/measures the neighbour BSs. Measurements are used to evaluate which BS is the best candidate to handover. Interleaving Interval: Duration (in frames) of normal operation intervals (interleaving intervals) during the scanning mode of a Mobile Station. Scan Iterations: Number of repetitions of scan interval and interleaving interval during the scanning mode of a Mobile Station. B.2.7 Background traffic The background traffic refers to all the data traffic generated by the rest of subscribers present in the airport surface that limit the radio resources usable by the A/C of study. In order to specify a representative model of the background traffic generation, a random model is used based on previous work from [6]. The relevant model for Barajas airport is extracted from those available in the study. 1. Air traffic figures in Madrid Barajas Barajas as a large airport has roughly 1100 operations per day. If we consider 15 operational hours within a day, and assuming uniform air traffic distribution along the day, we get 73 op/h which turns into 0,0203 op/s. Checking the appendix in [10] it can be observed that this ratio is the one used for scenarios of 50 A/Cs. Thus, it will be assumed from now on that Barajas has an average number of 50 A/C present on the airport surface. For sake of generality, it is considered that the A/Cs are uniformly distributed among the deployed cells. 2. Background traffic model Background traffic will be configured per Base Station; A node acting as both generator and sink is present at every BS taking background traffic model from scenarios in [6] according to each zone (RAMP, GROUND or TOWER) for an airport with 50 simultaneous ACs operating at the same time. Some modifications have been made in order to suit the model with the concluding results from SESAR P Profile validation [9], because of that FOQA service has been moved from GROUND zone to be initiated in RAMP zone, where the AC will stay long time in a static position. In consequence corresponding background traffic for the FOQA service has been extracted from GROUND zone and added to the RAMP zone. The following tables show the background traffic values for each operational zone according with the terms exposed.

167 A/C, 10 VC Overall Total [Kbps] RAMP arrival FL RL Table 47: RAMP Arrival Background traffic 50 A/C, 10 VC Overall Total [Kbps] RAMP departure FL RL Table 48: RAMP Departure Background traffic (50 A/C, 10 VC) Overall Total [Kbps] GROUND arrival FL RL Table 49: GROUND arrival Background traffic (50 A/C, 10 VC) Overall Total [Kbps] GROUND departure FL RL

168 166 Table 50: GROUND Departure Background traffic (50 A/C, 10 VC) Overall Total [Kbps] TOWER arrival FL 1.08 RL Table 51: TOWER Arrival Background Traffic (50 A/C, 10 VC) Overall Total [Kbps] TOWER departure FL 0.88 RL Table 52: TOWER Departure Background traffic Cell planning has been made covering RAMP zone with 64 QAM ½ in DL, and GROUND and TOWER covered with QPSK ½. In a first step BS sites for RAMP area have been selected and in a second step BS sites for TOWER and GROUND have been selected. We consider these two zones as one in terms of background traffic. Taking this into account final total values for Background traffic for all airport are the following ones: RAMP GROUND+TOWER Background Traffic 2.110E E+03 Kbps DL 3.244E E+02 Kbps UL 1.785E E+03 Kbps Table 53: UL&DL Background Traffic

169 167 Note these values are the throughput generated at the whole airport. Since A/C are uniformly distributed per BS, it is straightforward to divide these figures by the number of BS taken in the scenario to obtain the background traffic present per BS. The expected traffic per cell can be derived by dividing the total traffic per airport zone by the number of cells deployed, obtaining approx. 1 Mbps (RAMP) and 800 kbps (GROUND/TOWER). Assuming nearly all traffic load is caused by AOC, these figures can be considered AOC traffic per cell. To derive ATC traffic share, the AOC/ATC ratio given by Table 22 for 100 A/C scenario can be assumed constant (6500 for RAMP and 1200 for GND/TWR), thus obtaining roughly 0,2 kbps (RAMP) and 0,6 kbps (GND/TWR). 3. Simulation Results In this section, the following types of result are described to drive conclusions on the performance capacity and limits of AeroMACS deployments: End-to-end delay of all the data packets that are successfully received by the WiMAX MAC and forwarded to the higher layer. This statistic is extracted per CoS as an aggregate of the packets generated by all the services in that class. The aim of this figure is to measure the MAC layer (SDU level) capacity performance against the radio latency requirements from [3]. Service response time: This statistic exposes the time elapsed between the sending of the request from the source and the reception of the response at the source (if the service has respond messages).this is measured at application layer from the time the service starts with the first request at application layer until the response is received, or in case of unidirectional services, until the receiver receives the last packet sent by the sender. This statistic measures the effect of the radio throughput on the performance in service execution. Every service has a latency requirement, so service must have been completed in a time lapse less or equal to the latency requirement to be valid [3]. Data burst usage: This metric records the portion of the UL and DL subframes allocated to service flow data (data bursts and polls). It excludes the size of preamble and MAPs, together with other signaling. It is a measure of the occupation of the radio medium available at a specific BS and give a figure on the saturation of the channel. This is useful to predict the availability for the channel to correctly serve further traffic requests. The simulation has been split in two main aspects. First, scenarios where a deployment of a given number of BSs enabling the execution of an arriving and departing aircraft passing by all the airport domains are launched. The focus in this battery is to find out the number of BSs necessary to yield enough capacity to the system to cope with the packet and service delay requirements. The two presented scenarios (Scenario1 and Scenario2) are evaluated following the same approach. This first battery of tests is performed in an iterative manner. The first iteration has been launched assuming a minimum configuration needed to cover the airport surface. It was then found that a second iteration with a more dense cell planning and a refined QoS configuration was needed to yield satisfactory results. While the comprehensive results are presented for the second iteration, a comparison is also presented in order to measure the effect of certain parameters into the performance figures. Finally, a refinement of the cell planning at the GROUND and TOWER areas is performed taking into account the main limitation of handover performance at these airport domains. This section is a refinement of the analysis performed in SESAR P taking into account the realistic environment and trajectories. The cell planning characteristics are summarized in the table below for both

170 168 iterations. Note that cells have been split in two independent plans: RAMP area is composed of BS with a high overlap ratio in order to cover the area with 16QAM or 64QAM schemes. GROUND/TOWER area is composed of BS minimizing the overlap, since the required service load is low, QPSK can be used and thus the deployment is coverage limited in that domain. Iteration # sites # BS (sectors) Reuse cluster size * Tx power Avg BS BS distance Iter 1 RAMP dbm 1300 GND/TWR dbm 2650 Iter 2 RAMP ** 23 dbm 1000 GND/TWR dbm 1300 Table 54: Cell planning features used in capacity simulations *Reuse cluster size = Number of available channels without considering frequency reuse **One channel from GND/TWR has been reused in a single segment in RAMP zone a. Scenario 1 Simulation Results As result of the second iteration in Barajas airport and following AC s trajectory and speeds assumed for Scenario 1, the following metrics have been obtained for the different CoS and aeronautical services executed in the AC. The packet (MAC SDU) delay for every CoS is indicated below. Downlink direction is effectively well under the required packet latency in CHAPTER 5, while Uplink packets latency slightly surpasses the proposed requirement This effect is caused by the ATC message being fragmented and transmitted in a number of consecutive frames due to its size, and it does not affect the service execution latency. Hence, the requirement for the uplink latency is refined according to the figures that can be provided by the data link. It must be cleared out that packet latency requirements can only be targeted for critical ATS applications, AOC being out of this objective since these less priority applications must not be time limited and are thus considered delay tolerant. E2E Delay [avg][ms] NET ATC1 ATC2 ATC3 AOC1 AOC2 UpLink

171 169 DownLink Table 55: End to end Delay per Class of Service The service latency figures for each specific application executed during the arrival and departing operation are indicated in the tables below. Services are depicted following a per-cos classification. NET Service Response Time [s] Latency Requirement [s] Arrival NETKEEP NETCONN Departure NETKEEP Table 56: NET Services Response Time ATC1 Service Response Time [s] Latency Requeriment [s] Arrival SURV Departure SURV Table 57: ATC1 Services Response Time ATC2 Service Response Time [s] Latency Requirement [s] Arrival ACL D-TAXI COTRAC (interactive) DCL Departure FLIPCY FLIPINT PPD

172 170 D-TAXI ACL Table 58: ATC2 Services Response Time ATC3 Service Response Time [s] Latency Requeriment [s] ACM Arrival D-SIG ACM DLL D-OTIS D-SIGMET Departure D-RVR D-SIG D-FLUP ACM ACM Table 59: ATC3 Services Response Time AOC1 Service Response Time [s] Latency Requeriment [s] Arrival OOOI AUTOLAND-REG

173 171 TECHLOG CREW-TIME OOOI FLTLOG CABINLOG ETS-REPORT REFUEL AOCDLL LOADSHT BRFCD ACLOG TECHLOG AIRWORTH WXTEXT PASSENGER CREW-RPS Departure CREW-BUL CREW-REG FLTPLAN NOTAM HANDLING CATERING BAGGAGE NOTOC LOADDOC PREFLT-INS

174 172 DOOR FLOWCON TAKEOFF-CALC OOOI WXRT OOOI Table 60: AOC1 Services Response Time AOC2 Service Response Time [s] Latency Requeriment [s] EFFU FLT-JOURNAL Arrival FOQA E-CHARTS UPLIB SWCONF Departure SWLOAD SWLOAD EFF/WXGRAPH/CREW-L EFFU Table 61: AOC2 Services Response Time As can be observed from the tables, the response time of all critical services (NET and ATC) is lower than the service latency requirements, most of the services spending less than 1 second in the total completion. In effect, although the proposed requirements for these services were relatively loose, as critical applications, they need to be executed in the shortest possible delay. It is proven that AeroMACS can enable instantaneous transmission for safety critical ATC applications.

175 173 AOC services are in general well under the delay requirements, too. However, it can be observed that the requirements set for several high load services (all belonging to AOC2 Class of Service) are inconsistent with the features (failed requirements are indicated orange in Table 61). Latency requirements are not applicable to AOC services and values are only shown for completeness. For instance, the execution of E-CHARTS in 60 seconds time would need a single subscriber to have 20 Mbps available for itself in the link. Besides, this level of stringency is unnecessary considering the operational needs of the application. These applications are completed during the turnaround phase that will take 20 minutes (2400 seg) at the very least, while AOC services can be executed in less than half that time. Thus, a review of the real needs for these services has to be undertaken by the involved airspace users to set a realistic figure that can drive a requirement. The figures below depict the frame utilization by data traffic for one specific channel. The sector to which the A/C is connected during the turnaround phase has been chosen such that the most highly loaded services are executed. It can be observed that, even considering the very worst case in which all the heavy services are instantiated (each of which is actually executed only during 1% of the flights) the channel does not reach complete saturation and can cope with additional critical ATC services if required.

176 174 Figure 57: UL/DL WiMAX Frame. Data Burst Usage in % b. Scenario 2 Simulation Results Results are shown for the different CoS and aeronautical services executed in the AC in Scenario 2. The packet (MAC SDU) delay for every CoS is indicated below. It can be observed that both downlink and uplink figures are well under the packet latency requirements. Note that, in Scenario 2, heavy services are much minimized, by assuming the A/C is a short-range aircraft. RAMP services being the most stringent factor in this scenario, the traffic generated by these services does not affect the performance level. E2E Delay [avg][ms] NET ATC1 ATC2 ATC3 AOC1 AOC2

177 175 UpLink DownLink Table 62: End to end delay per Class of Service The service latency figures for each specific applications executed during the arrival and departing operation are indicated in the tables below. Services are depicted following a per-cos classification. NET Service Response Time [s] Latency Requirement [s] Arrival NETKEEP Departure NETCONN NETKEEP Table 63: NET Services Response Time ATC1 Service Response Time [s] Latency Requirement [s] Arrival SURV Departure SURV Table 64: ATC1 Services Response Time ATC2 Service Response Time [s] Latency Requirement [s] Arrival Departure ACL D-TAXI COTRAC (interactive) DCL

178 176 FLIPCY FLIPINT PPD D-TAXI ACL Table 65: ATC2 Services Response ATC3 Service Response Time [s] Latency Requirement [s] ACM Arrival D-SIG ACM DLL D-OTIS D-SIGMET Departure D-RVR D-SIG D-FLUP ACM ACM Table 66: ATC3 Services Response AOC1 Service Response Time [s] Latency Requirement [s] Arrival OOOI

179 177 AUTOLAND- REG TECHLOG CREW-TIME OOOI FLTLOG CABINLOG ETS-REPORT REFUEL AOCDLL LOADSHT BRFCD ACLOG TECHLOG AIRWORTH WXTEXT PASSENGER Departure CREW-RPS CREW-BUL CREW-REG FLTPLAN NOTAM HANDLING CATERING BAGGAGE NOTOC LOADDOC

180 178 PREFLT-INS DOOR FLOWCON TAKEOFF-CALC OOOI WXRT OOOI Table 67: AOC1 Services Response Time AOC2 Service Response Time [s] Latency Requirement [s] EFFU Arrival FLT-JOURNAL FOQA E-CHARTS UPLIB SWCONF Departure SWLOAD SWLOAD EFF/WXGRAPH/CREW- L EFFU Table 68: AOC2 Services Response Time

181 179 It can be observed that, as in Scenario 1, the service latency requirements for ATC are fully accomplished. Note that this scenario is more stringent in terms of turnaround time. The same effect as in Scenario 1 is replicated here, although the heavy services are mitigated as they generate a smaller amount of traffic. The figures below depict the frame utilization by data traffic for one specific channel. The sector to which the A/C is connected during the turnaround phase has been chosen, where the most highly loaded services are executed. It can be observed that, even considering the very worst case in which all the highly loaded services are instantiated (each of which is actually executed only during 1% of the flights) the channel does not reach complete saturation and can cope with additional critical ATC services if required. Figure 58: UL/DL WiMAX Frame. Data Burst Usage in % c. Comparison between Iteration 1 and Iteration 2 for scenario 1. In order to get convergence between services response time and required latency a pair of iterations increasing the number of base stations has been necessary. Scenario 1 is assumed for the sake of comparison. This paragraph shows briefly main differences between the two iterations.

182 180 The table below summarizes the number of BS configured per iteration, and the consequent amount of background traffic. It can be observed that, in iteration 2, the number of BS in the RAMP area was increased, while GROUND/TOWER kept the same planning. That is due to the fact that the services found to be operating near the limit of the system capacity, as shown in the results below, were executed in RAMP. Note that, assuming uniform background traffic distribution in the airport surface, this figure is inversely proportional to the number of BS. Refer to the first subsection in 3 for detail on the difference between cell planning in iteration 1 and iteration 2. In the latter, the background traffic that occupies a sector is around 1 Mbps. Iteration 1 Iteration 2 Number of BSs Background traffic in RAMP [Kbps] Background traffic in GROUND&TOWER [kbps] RAMP GROUND&TOWER 8 8 DL UL DL UL Table 69: Summary of BS number and background traffic figures per iteration Another major difference of iteration 1 is the QoS configuration. For polling services, the polling rate at which the BS sends periodic unsolicited poll requests has been under dimensioned in iteration 1. In addition, ATC3 CoS has been configured as nrtps instead of rtps as in iteration 2. As a consequence, a minimum periodic poll rate is not set up, and thus the maximum latency per packet is not controllable. The difference in QoS configuration is depicted in the table below. The polling rate is a figure extracted from the configured parameters Maximum or Minimum Traffic Rate. The algorithm to work out the polling rate (PR) is implementation dependent. Class of Service Iteration 1 Iteration 2 NET ATC1 ATC2 rtps PR = 1 ms rtps PR = 1 ms rtps PR = 1 ms rtps PR = 5 ms rtps PR = ms rtps PR = ms

183 181 ATC3 AOC1 nrtps PR = 1 ms nrtps PR = 1 ms rtps PR = ms nrtps PR = ms AOC2 BE BE Table 70: QoS configuration for iteration 1 and iteration 2 Differences on the results in terms of packet delay and execution latency for some relevant services is shown in the tables below. The first aspect to observe, is the poor result for iteration 1 in the tables below: although the polling rate is maximum for every CoS (1 ms), there is a big difference between the maximum delays caused per CoS, and those that are not coherent with the priority level the CoS has. That is explained by the fact that, in the de facto QoS configuration in iteration 1, there is no effective prioritization at all. By scheduling the same polling rate to all rtps CoS, they are finally served in a FIFO manner. In this case, the packets that arrive at the queue will be de-queued at a lower delay than those arriving at peak traffic instants. On the other side, nrtps services are always served with a lower priority, thus causing a significantly longer delay. That is why, in iteration 2, an affective prioritization is configured to serve each CoS in a gradual manner according to its level of priority. E2E Delay [avg][ms] NET ATC1 ATC2 ATC3 AOC1 AOC2 I1 I2 I1 I2 I1 I2 I1 I2 I1 I2 I1 I2 UpLink DownLink Table 71: Results on packet latency for iteration 1 and iteration 2. Scenario 1 Service Name Iter 1 Simulation Latency Iter 2 Simulation Latency Required Latency [s] ACL GND Arr EFFU FLT-JOURNAL RMP Arr ACM ECHARTS

184 182 RMP Dep UPLIB SWLOAD EFF GND Dep ACM ACL TWR Dep WXRT Table 72: Capacity limitations in Iteration 1 solved in Iteration 2 A balanced latency target can be achieved through proper QoS configuration. Note that, in order to do this, dimensioning needs not be equal per CoS, but rather a polling rate needs to be configured per CoS depending to the traffic generation rate and message size of the aggregated services in the specific class. Of course, an implementation-dependent algorithm could be active in the scheduler to adapt to the CoS varying data rate in an optimized manner. It can be observed that, with a wellbalanced QoS, the end-to-end delay of a packet is well below 80 ms, which is very valid for data, and even for real time and voice applications. It is obvious that the QoS configuration mainly affects the Uplink in terms of delay. In effect, the Downlink does not require a polling delay since the BS generates traffic and directly forwards it to lower layers. Uplink, on the other side, has a delay of several frame due to polling negotiation. Besides, with the current symbol configuration, the downlink has more available resources than the Uplink, which could be optimized (within the limits of supported symbol configurations in [51] although not strictly necessary. Regarding service execution latency, it can be observed that iteration 2 deals better with it in general, especially for ATS. Some highly loaded services would still require a redefinition in terms of required latency to suit them better to the operational concept and milestones. In that context, Iteration 2 is just an example on how to improve performance of AeroMACS, but it is not considered to be a standard setting. Optimization has to be done on a case by case basis and the information provided can be used as guideline on how to do it. Finally, the graphs below depict the improvement in terms of frame occupation by data traffic achieved by the refined configuration in iteration 2. It can be observed that, in both Downlink and Uplink, iteration 1 led to a saturation of the channel in the BS in charge of the turn-around phase. This is due to the under-dimensioned cell planning but also to the non-optimized QoS per class of service, which causes an overhead provoked by excessive polling delay. Iteration 2 solves both issues and avoids a saturation of the channel, thus allowing new service flows to be admitted in the sector if necessary. Iteration 2, although providing better results, is not being considered as a minimum performance standard. It is only explaining how improvement can be reached taking into account specific environmental conditions. As outlined above what is important to note is that a balanced latency target can be achieved through proper QoS configuration. Note that, in order to do this, dimensioning needs not be equal per CoS, but

185 183 rather a polling rate needs to be configured per CoS depending to the traffic generation rate and message size of the aggregated services in the specific class. Figure 59: WiMAX DownLink Data Burst Usage. Red=Iteration2. Blue=Iteration1.

186 184 Figure 60: WiMAX UpLink Data Burst Usage. Red=Iteration2. Blue=Iteration1. 4. Handover results The network dimensioning affects mainly the capacity levels of the system in terms of throughput and delay, which could be seen as parameters of static capacity (i.e. linked to the ratio BS vs aircrafts in the overall airport surface). However, capacity also includes the performance levels of the handover process (i.e. the smooth transition of an aircraft registered in a BS to a different one without session interruption), since it can affect the availability of services being executed at a specific moment. As this process is purely dynamic, handover figures depend largely on the aircraft movement on surface, BS placement and signal quality on the moment of handover. This section is a refinement of the handover performance study started in [9]. According to these results, handover is not an issue at RAMP area, where BSs are dense and the subscriber is handed over at high signal to noise values. Besides, the aircraft is expected to move slowly, thus suffering low shadow fading effect. An optimization is needed in GROUND/TOWER areas, though, where BSs are more distant and the aircraft moves faster. This is a harsh situation that leads to a refinement of the cell planning to meet the requirements. The scenario follows the arrival and departure trajectory defined in Scenario 2, starting from the cell planning proposed in iteration 2. The aircraft in this scenario executes services following the data rate in background traffic generation. This is configured in order to obtain a uniform traffic generation and study the effect of handover interruption over the services. In addition, shadow fading has been activated and considered for GROUND and TOWER zones in the same way as in [9]. MAC and PHY configuration is similar to that in [9] (section 3.3). For sake of comparison, statistics similar to [9] have been analyzed here. Handover delay: Handover delay is computed from the time the Mobile Station sends a MOB_MSHO-REQ message starting the handoff process until initial ranging with the new Serving BS is successfully completed.

187 185 Interruption Time 14 : Time between the message indicating the start of the HO (HO_IND) and the creation of the new service flow (DSA_ACK). Failure probability: percentage of Handover Cancellations produced during simulation time over all the Handover realizations. Dropped Packet Rate: this new statistic has been gathered in this scenario in order to illustrate the effect from handover interruption and delay to the transmission of data packets. This statistic is extracted at PHY SDU level, in order not to take buffering effects into account. Handover optimization has been performed taking care of the cell range of contiguous BSs that participate in handover processes (not in all of them). In this sense, contiguous BSs inside GND/TWR or between RAMP and GND/TWR are taken into account (handover within RAMP zone is not part of this analysis). In order to do this, the implementer has to estimate the most likely movement patterns that an aircraft will follow, as has been done in this study. First, the cell planning from iteration 2 is kept in the simulation, where consecutive BSs in an aircraft trajectory are distanced 2650 m in average. Then, consecutive cells that fall under a likely aircraft trajectory are brought closer to the distance necessary to target the recommended PER = 1E-03 from 0 at the cell edge. To meet this PER level at QPSK ½ an SNR = 17 db is needed (see Figure 3-14 in Calibration simulations of [9]), which corresponds to a cell range of 650 m (1300 m distance between BS) according to Figure 26 with propagation model BS1MS1, and considering Noise power = dbm. See Appendix C for details on the BS sitting. Contiguous BS avg distance Avg HO delay [ms] Avg interruption time [ms] Probability of HO failure [%] Dropped Packet Rate in UL [%] Dropped Packet Rate in DL [%] 2650 m (initial) 402,84 266,73 7,16 8,68 1, m 322, ,6 7,77 0,84 Table 73: Results for HO performance. Consecutive BS distance = 2650 m / 1300 m Results show that, in effect, a distance of 1300 m for the BS affected by handover guarantees the fulfillment of the requirement in terms of handover interruption time. It also yields an acceptable probability of handover failure below 4%. Even keeping the initial BS distance of 2650 m, the packet dropping rate caused by handover interruption remains well under 10%. Note that dropping rate has been measured at PHY level, thus not taking retransmission into account. MAC takes charge of the dropped packets by retransmitting them in ARQ. Note that, as previously indicated, only the distance between contiguous BSs that participate in the handover process has been taken into account, it is unnecessarily costly to increase the density of BS in areas that will not see a cell transfer. This is feasible since mobility patterns of aircrafts in the surface are predictable and limited to very specific runway and taxiway zones. It is recommended for a 14 This definition is different to standard definition of interruption time within this document. At the time simulation has been conducted HO optimisation was not active.

188 186 deployment to take care of this when planning the cell sitting in order to optimize handover performance without largely increasing the density of BS.

189 187 Appendix C AEROMACS DEPLOYMENT CASE STUDIES The scope of this section based on RF simulations is to provide the following: Generic guidelines for simulations made with a RF tool. Description of the setup of the scenarios simulated. Designing considerations that will be addressed for the scenarios are: Determine cell density required for a desired level of service, performance, and coverage. Illustrate the effect of frequency, power, terrain, clutter and CPE location on that coverage. Determine expected point-to-point link performance using an analytical path loss model. LOS and NLOS Maximum Allowable Path Loss (MAPL) based on system parameters. Determine power settings and receiver sensitivities. Channel bandwidth and frequency raster. Deem antenna gains. Fading model to be used. Determine site selection criteria over Barajas and Toulouse layouts. All the simulations of this section have been computed with HTZ Warfare tool (an ICS Telecom software based from ATDI Company). Maps from Toulouse and Barajas have been provided in order to perform simulations with the tool for the two airports. A description of the main parameters of the Radio planning tool can be found in Appendix C. C.1 Radio Planning Tool and Parameters HTZ is a commercial tool, based on ICS Telecom tool, and dedicated to military application. It brings few additive functionalities dealing with jammers and interference stations. C.1.1 Definition of propagation media Propagation aspects can be divided in three different parts: LOS propagation (Line Of Sight): The transmitter and the receiver are in visibility one with each other. The propagation in LOS is based upon clearly defined propagation methods, such as the ITU-R P.525 model. Note that in ICS Telecom, taking full advantage of the quality of the cartography loaded, deterministic propagation models, have proved to give the best correlation when correlated with on-field measurements. Of course, additional effects, such as attenuations due to the rain or atmosphere are also considered. NLOS propagation (NON Line Of Sight): The transmitter and the receiver are not in visibility with each other. A typical example is a WiMAX BS located in Outdoor environment, when the MS is located inside a building. The signal between the BS and the MS is then diffracted, diffused, or both. ICS telecom features a new cartographic layer, called the building file that describes the building height above ground level. In ICS telecom, the Digital Terrain Model is now separated from the above-the-ground features (buildings, trees ).

190 188 Diffraction effect nlos propagation(near Line Of Sight): This case is a mix between the LOS and the NLOS case. The transmitter and the receiver can be for instance in visibility with each other, but part of the Fresnel ellipsoid is obstructed. The diffraction models in ICS telecom do quantify the losses due to obstacles between the BS and the MS, avoiding the two entities to be in Line of Sight one with each other. Sub-path attenuation effect Multi-reflection effect The sub-path model in ICS telecom quantifies the losses due partial obstructions of the Fresnel zone. Such an attenuation term can be defined for partial obstruction in the Z axis only, or in full 3D. This model calculates the field strength at all point of the simulation area according to reflected signals contribution, taking into account a reflection coefficient defined by the user. Building loss estimation (indoor communication) In some cases (sector antenna radiating perpendicular on buildings and having beam elevation angle not radiating over the building) it is possible to take into account building losses in order to decrease interference levels with Globalstar. NOTE: The values provided have been obtained for indoor communication and gives an idea on generic value estimations for different materials. However for outdoor communication, values need to build in a safety factor of 3 to 6 db. Table 74: Wall attenuation values Frequency GHz Loss for Thin walls db Loss for Thick walls Concrete db 2 3,3 10,9 3,5 3,4 11,4 5 3,4 11,8 NOTE: Because airport terminal very often include extremely large glass surfaces the attenuation loss for windows can be found in table beneath. Table 75: Window attenuation values Frequency GHz Glass/Window (not tinted) db Double-pane coated glass db

191 189 2, C.1.2 Environmental Models AeroMACS link budget calculation is described in However, LOS and NLOS propagation are differentiated in a real situation, taking into account multipath propagation as well. For this purpose, a deterministic model was used, combining ITU-R P.525 for LOS (Line Of Sight) loss, Deygout 94 method for diffraction loss (when the LOS is obstructed) and Standard for nlos (near LOS) loss (when the 1st Fresnel zone is obstructed but that the LOS is clear). This propagation model takes also into account multipath effect. The deterministic models make use of the laws governing electromagnetic wave propagation to determine the received signal power at a particular location. They require a 3-D map of the propagation environment: the more compatible the accuracy of the cartography with a certain technology to simulate, the better the coverage accuracy (for a given set of technical parameters for the Best Stations / Terminals / Mobile Stations). Typical examples are the ITU-R P.525/526 models, used with appropriate additional propagation effects (diffraction, sub-path attenuation, ray tracing). Attenuation associated to the signal strength received at each pixel will be attenuated based upon the selected diffraction model. A fully deterministic propagation model might be limited for technologies using high frequencies, where each above the ground feature can become a physical obstacle to the propagation of the signal (diffraction, absorption ). HTZ is a deterministic tool taking into account the real environment cartography, the Digital Elevation Model (DEM), whenever all details are available. The choice of the cartography to use depends on the type of WiMAX radio-planning to perform: Large scale WiMAX networks would require Medium Resolution cartography Close range WiMAX network analysis would require High resolution cartography. The DEM is a digital terrain model describing ground heights and a buildings elevation model combined. It describes the maximum or canopy height at any point on the ground. It is described generally by a matrix of points in the x and y or Eastings and Northings directions with the axes aligned to a chosen coordinates system. The matrix has a given resolution. For planning mobile systems and for microwave systems where every path will be surveyed a resolution giving a height point every 50 metres is usable. For PMP networks at 5 GHz, we need to achieve a resolution of nearer 5 meters to position nodes and subscribers more precisely. In the z direction we need to specify a height. Given a Fresnel zone radius of 2.7 meters it would seem excessive if we had a resolution of 10 centimeters and provided that we have captured the maximum height at any point within the 1 meter matrix, a 1 meter z resolution is adequate. Of critical importance is the degree of error in positioning the matrix in the x and y directions and in specifying the height at each point. This error is a function of the way in which the data has been captured and processed to yield the DEM. Most high resolutions are developed from aerial survey either using downward looking radar or laser or the interpretation of stereo photographs. The methods are really beyond the scope of a brief presentation but the key issue is simply this. However produced, the planning engineer must have a specification of the DEM showing both resolution and error. For the two airports considered high resolution data are as follows: DTM (Digital Terrain Model) + clutters for Toulouse map DEM (Digital Elevation Model) for Barajas map (buildings merged with ground) Resolution: 5m Propagation models The global propagation model is a combination of the following models: Free space: ITU-R P.525 model Diffraction geometry: Deygout 94 method Sub-path attenuation: Standard model Reflection coefficient: clutter dependant

192 190 Parameters considered for simulations General e parameters Signal TDD 5MHz PUSC segmentation 8 C.1.3 NOTE: Reflection is considered in the simulations if clutter data are available.base Stations & Mobile Stations General radio parameters found in [10]: Cable and implementation losses, Noise Factors, sub-channelization gain, Receiving threshold considered in the DL (to establish coverage maps): dbm (which corresponds to MS sensitivity for QPSK ½ - CC in the AeroMACS SARPs). Receiving threshold considered in the UL: -96 dbm (which corresponds to BS sensitivity for QPSK ½ - CC, as calculated in UL link budget in table 27 of reference [3]), Specific parameters for coverage analysis: BS sectorized antenna 15dBi : 110 Azimuth ; 7 Elevation, Downtilt = 4.5 BS antenna height above ground = 38m MS omnidirectional dipole antenna 6dBi MS antenna height above ground = 10m (for A/C) and 2m (for vehicles) Specific parameters for interference simulations RAMP Stations: Req (C/N)+I = 14dB (UL) and 15dB (DL) GROUND & TOWER Stations: Req (C/N)+I = 5dB (UL) and 4.5dB (DL) Antenna diagram for BS: Figure 61: Horizontal and Vertical pattern for Base Stations (H: 3dB beamwidth = 110 ; V: 3dB beamwidth = 12 (tbc))

193 191 C.2 Case study 1: AeroMACS Deployment at Barajas Airport This appendix deals with the special case of AeroMACS deployment in the airport of Madrid Barajas as a specific example that can serve as a guideline. While many generic results and statistics shown in Appendix B and B.2 have been extracted by modelling scenarios in this airport (to have a real base for results), the specific cell planning proposed for the airport surface is shown in this section. First, a review is done on the BS site features and limitations applicable to Barajas. Second, cells are distributed in line with the capacity needs in the respective operational domains. Then, it is verified that the coverage from all the BS sites is acceptable in terms of received signal quality in the whole airport surface. Madrid Barajas is a large airport with four runways placed in two far dual parallel configurations (North-South axis 36L/18R 36R/18L Northwest-Southeast axis 15L/33R 15R/33L). The estimated air traffic operating on the surface at a given moment is 50 A/C. Terminal layouts comprise the usual configurations for busy airports (linear and circular), plus a linear satellite terminal (T4S). Few transport areas are present in the surface. Terminal zones are mixed with taxiing and runway zones in a complex manner leaving the two runway domains separated. Due to this, GND/TWR domain has been covered separately for the North and South taxi and runway zones. In both domains, BS have been planned to cover the airport surface, while RAMP has been planned taking into account the placement of the served aircrafts close to the terminal when doing turn-around. The central axe, together with the taxiing between Terminal 4 and Terminal 4S can be covered with the RAMP sectors. Care has been taken to place the BS respecting the distances from runway and taxiways specified in [13], while no BS has been placed to point to terminal roofs in order to avoid reflections towards Globalstar. Antennas are 120º sectorized, in order to provide enough sectorization gain but avoid losses due to blocking small apertures. No MLS system operates in the airport.

194 192 RAMP Decimal values Hex values Sectors Latitude Longitude Latitude Longitude Sectors s1 s2 s ' -3 34' BS1 R1 40, , " 20.31" ' -3 34' BS2 R2 40, , " 9.46" º 27' -3º 34' BS3 R3 40, , " " º 29' -3º 35' BS4 R4 40, , " " º 29' -3º 35' BS5 R5 40, , " " º 29' -3º 34' BS6 R6 40, , " " º 27' -3º 33' BS7 R7 40, , " " º 29' -3º 34' BS8 R8 40, , " " º 27' -3º 34' BS9 R9 40, , " " º º 29' -3º 35' BS10 R10 40, , " " GND TWR BS1 G BS2 G BS3 G ' 13,05'' 40 28' 26,32'' 40 30' 46.11" s1 s2 s3-3 34' 17,05'' ' 53,57'' ' 1.03" Table 76: BS coordinates proposed for Madrid Barajas planning gray 1 G1s1, G2s3 white 6 R1s1, R3s3, R8s2 green 2 G1s3, G3s2 pink 2 7 R1s3, R8s1, R10s3 pink 3 G1s2 orange 8 R2s1, R4s1, R7s2 red 4 G2s1 green 2 9 R2s3, R4s3 black 5 G2,s2, G3s3 yellow 10 R3s1, R5s1, R6s3 blue 11 R5s3, R7s1, R8s3 black 12 R6s2 red 13 R6s1, R9s2 Table 77: Frequency re-use planning proposal Note that the tables above refer to physical and logical frequencies respectively. Among the logical frequencies, 1-5 are frequencies used in GROUND while 6-13 are frequencies used in RAMP. Frequencies 12 and 13 in RAMP are physically the same as frequencies 4 and 5 in GROUND,

195 193 respectively. They have been re-used since they do not alter the frequency reuse scheme due to enough distance between emitting BS, thus avoiding intra-system interference limitations. The tables above and the figure below depict the cell planning proposed for Madrid Barajas, which matches the network used to evaluate the AeroMACS Capacity in B.2. In the picture, the use of each of the 11 available channels is illustrated per colour. The sector size corresponds to the maximum range attainable considering the pathloss model in Barajas outlined in [7]. Note that sectors in RAMP have a transmission power of 23 dbm similar to GROUND and TOWER, but sizes of the coverage at 64QAM in the DL and 16QAM in the UL are depicted to illustrate the conformance to the high capacity requirements stated in [1]. It can be observed that a new sector could be activated in the Tower1 BS if the northern runway area is deemed necessary to cover (e.g. for surface vehicle applications). Otherwise, it is estimated that it is not used by aircraft services, and thus being inactive in order to minimize interference with Globalstar.

196 194 Figure 62: Proposed cell planning in Madrid Barajas Below the optional cell planning proposed in B.2 for handover optimisation is shown. Note that, in this configuration, the number of sectors remains the same, however the BS s have been moved and a new site exists, in order to increase the signal quality at the cell edge between BS participating in handover processes.

197 195

198 196 Figure 63: Proposed cell planning in Madrid Barajas Closer distance between BS in handover Below the cell planning showing only RAMP cells is depicted. Note that RAMP cell edges show the maximum range using 16QAM so, as it was indicated; RAMP cells in North terminals (T4 and T4S) are enough to cover the taxi ways between them by covering them with QPSK. As it can be seen, the sites to cover RAMP zone have been placed on towers and in the edge of buildings in order to cover the line where aircrafts are likely to stay when performing turn-around. Figure 64: Proposed cell planning in Madrid Barajas RAMP only

199 197 With the proposed cell planning, the following aspects regarding sector layout and capacity distribution of the AeroMACS deployment can be extracted. The data rate interval has been obtained by multiplying the number of sectors by the possible data rate offered per sector (which yields an interval depending on which modulation scheme is used for the subscriber, QPSK 64QAM in downlink, QPSK 16QAM in uplink). Zone # sites # BS # channels Data rate per domain Avg BS Tx power (sectors) distance RAMP * Mbps (DL) dbm Mbps (UL) GND/TWR Mbps (DL) Mbps (UL) 2650 ** Table 78: Capacity planning figures in Madrid Barajas * RAMP uses two channels also used in GND/TWR ** This average distance is reduced if the optional cell planning to optimize handover is deployed Finally, the coverage of the airport surface considering the proposed cell planning has been verified with a coverage simulation tool. In these simulations, a free space propagation model added to a fading value caused by the reflections on buildings and aircrafts distributed on Barajas surface has been used to calculate the signal level received at every point of the map. DTM maps have been applied together with information on the clutter and the refraction values of the buildings, instead of applying a generic fading model as was done in the tool for Capacity Analysis. In this case, Free Space propagation mode ITU-R P.525 with Deygout 94 method for diffraction geometry have been applied to obtain the tracing model per point. C.2.1 Global radio coverage in Barajas airport (DL) Barajas airport is taken as an example in order to estimate range and intra-system interference in case of frequency re-use using all the frequency slots available in the AeroMACS band. The radio coverage is a DL estimation of the maximum range mainly driven by the BS transmitted power, BS antenna gain, MS antenna gain and MS sensitivity. It is driven by hypothesis made on capacity (see [10]) which led to 28 sectorized BS. Because of limitation of map area available, few BS are not activated in the simulation. Thus 24 BS are activated for coverage analysis, whose names are given in the following Figure. All BS are positioned at 38m height relative to ground.

200 198 Figure 65: Focus on BS position and label on Barajas airport The global DL, in a composite server display, has been computed and its coverage map is given below for two MS types, aircrafts (with Hant = 10m) and vehicles (with Hant=2m).

201 199 Figure 66: Global coverage (DL) in composite server display: Vehicles with Hant=2m(left) Aircrafts with Hant=10m (right) We first note that the Barajas airport is fully covered by the 24 BS activated in the simulation software. The color legend shows the modulation scheme available at different location on the map, starting from the more efficient modulation scheme (in red) to the less efficient one (in dark blue). Then, we can observe the difference in power collected by the MS in both cases. To be more specific in range values, we are going to focus in the next sub-section on one of the BS installed in the RAMP area.

202 200 MS category (antenna height/groun d) Vehicules (h=2m) Aircrafts (h=10m) 64QAM 3/4 64QAM 2/3 64QAM 1/2 16QAM 3/4 16QAM 1/2 QPSK 3/4 QPSK 1/ Table 79: Calculation of cell range (DL in m) for each modulation scheme and MS category (based on R1s1 coverage, near LOS direction)

203 201 Figure 67: R1s1 coverage for Hant=2m(left) and Hant=10m (right) The main range difference is visible on the; Last modulation scheme (QPSK 1/2) for the range (6 Km instead of 5 Km), where aircrafts take benefits of a better radio range. Better homogeneity of the power received at all positions, especially for 16QAM and QPSK modulations (light greens and blue color in Figure). The aircrafts (Hant=10m) will collect more signal than the vehicle (Hant=2m), operating with a better C/N value, and will of course keep the AeroMACS connection further on the airport. The focus on one BS is mainly interesting for range estimation and visualization of directions where occur direct obstruction to LOS. The aim of the next table is to estimate the reachable range for NLOS directions.

204 202 MS category (antenna height/groun d) Vehicules (h=2m) Aircrafts (h=10m) 64QAM 3/4 64QAM 2/3 64QAM 1/2 16QAM 3/4 16QAM 1/2 QPSK 3/4 QPSK 1/ * * ** ** Table 80: Calculation of cell range (DL in m) for each modulation scheme and MS category (based on R1s1 coverage, NLOS direction) Note *: Not really appreciable due to other main obstructions to signal Note **: Depending on the location of the antenna system on the A/C, mask can occur some of the time, compensated by the visibility of other BS on the airport where the AeroMACS system is deployed. Generally speaking, if we focus on specific area of the composite radio coverage, we observe inhomogeneous colors, thus inhomogeneous modulation and data bit rates. This is either due to masked area (below BS that are installed at the top of high towers or buildings), or area where interference due to reflections occurs, leading to fading events, and thus to less effective modulation scheme. C.2.2 Radio coverage limited by the Uplink (UL) Radio coverage can be limited by the MS ability to communicate with BS. The radio coverage that gives the area in which a connection can be established between a MS and a BS is mainly driven by the MS antenna gain, MS transmitted power, UL sub-channelization gain, BS antenna gain and BS sensitivity. This range is often different from the DL radio coverage because of an unbalance between the two DL and UL budget link (Cf. budget link tables). This budget link unbalanced is around 6dB, considering the simulation hypothesis taken. If we consider this unbalanced in the simulation tool, we get the following figures for the global radio coverage.

205 203 Figure 68: Global coverage (limited by UL) in composite server display: Vehicles with Hant=2m (left) Aircrafts with Hant=10m (right) The airport is still covered, but It can be observed that the highest modulation scheme are less available than in normal DL coverage, especially the 64QAM3/4 for MS on vehicles, radio coverage % of the airport is reduced in the BS configuration chosen (head of two takeoff runways are no longer covered). Full coverage is still accessible if positions of BS are modified (radio planning has been made in order to optimize the capacity). NOTE: Hypothesis made in DL & UL Link Budget Tables can also be reviewed Focus on R1s1 case, Hant=10m The radio coverage is shown below

206 204 Figure 69: R1s1 radio coverage (limited by UL), Aircrafts with Hant=10m Coverage convention DL (from previous tab) DL limited by the UL (current case) 64QAM 64QAM 64QAM 16QAM 16QAM QPSK QPSK 3/4 2/3 1/2 3/4 1/2 3/4 1/ Table 81: DL coverage and reverse coverage Processing a radio coverage limited by the UL leads to a factor 2 degradation in range, as it was predictable by the physics law. These data can be compared to data in section (NLOS Munich, NLOS Barajas range estimation). Note that we are more in near LOS case than in a rigorous NLOS case. C.2.3 Simulation of intra-system interference Frequency reuse-plan among base stations deployed over the airport area A frequency planning has been worked out for Barajas airport, with capacity hypothesis made previously. All spectrum available in future AeroMACS standard has been used. Because of the number of activated BS s (24) and available frequencies (11), a frequency re-used has been used, operating a permutation of sectors on the airport area. The frequency permutation, as well as sectors deployed can be seen on the following table and figure. A more detailed analysis of this process can be found in Appendix C (Case Study 1).

207 205 Note: The calculation of central frequencies is done according to the formula (5005 +n*5 (n=0..4 and )), which gives 11 contiguous channels. Table 82: Frequency planning & reuse for intra-system interference analysis Frequency planning & reuse for HTZ n*5 (n=0..4 and ) 11 available contiguous freq for range: 5091 to 5150 MHz n Fi n Fi Freq nb in HTZ freq. n 1 G1s1, G2s3 2 G1s3, G3s2 3 G1s2 4 G2s1 5 G2,s2, G3s3 6 R1s1, R3s3, R8s2 7 R1s3, R8s1, R10s3 8 R2s1, R4s1, R7s2 9 R2s3, R4s3 10 R3s1, R5s1, R6s3 11 R5s3, R7s1, R8s3 12 R6s2 13 R6s1, R9s2 Note that the tables above refer to physical and logical frequencies respectively. Among the logical frequencies, 1-5 are frequencies used in GROUND while 6-13 are frequencies used in RAMP. Frequencies 12 and 13 in RAMP are physically the same as frequencies 4 and 5 in GROUND, respectively. They have been re-used since they do not alter the frequency reuse scheme due to enough distance between emitting BS, thus avoiding intra-system interference limitations. Simulation of intra-system interference (co-channel and adjacent channel interference) The purpose of this sub-section is to evaluate the co-channel and adjacent channel interference on a real airport deployment. Barajas airport is used for this simulation. Interference is considered at BS level and calculation is performed according to C/I or IRF rules. Results will be presented and displayed on a map. A CINR analysis has been performed in order to check which modulation (i.e bit rate) will be lost according to the interference. For that, a C/(N+Sum(I)) has been calculated, based upon a noise floor N and the interference rejection factors (IRF) of the equipment. Note: C/(N+Sum(I)) function computes the maximum C/(N+sum(I)) value on each point of the terrain according to the noise level value of the receiving point. C is the received wanted power coming from activated stations considered one by one and unwanted power is the power sum of the other stations. Moreover, because PUSC permutation mode is used, the received wanted power C is weighted according to the number of segmentation and the PUSC sector loading allocated to the station. The following frequency mask has been considered: Co-channel (N=0): 0 db Adjacent channel (N=1): 32 db Alternate channel (N=2) : 50 db

208 206 Figure 70: Map of CINR intra-system interference, based on DL coverage Table 83: Assumption of CINR versus Modulation Schemes 15 CINR (>db) Received Power (>=dbm) Modulation Scheme 5-92 QPSK1/ QPSK3/ QAM 1/ QAM 3/ QAM 1/ QAM 2/ QAM 3/4 Note: The CINR values assumed are close to the SNR values of the IEEE standard. Thus, these values have to be revisited taking into account a defined margin for interference. In order to operate in a given modulation scheme, and thus access to a given data bit rate, a minimum CINR needs to be respected. We observe on the CINR map that all the airport area have a CINR between 16 and 40dB, which means that, based on the 15 Assumes minimum adjacent channel rejection level as in table 85 Item 6 in [5]

209 207 frequency planning prepared, no interferences occur in the AeroMACS system for this deployment. C.2.4 Conclusions and recommendation Radio coverage depends on radio parameters, directly linked to AeroMACS device, but also to the position of such equipment and especially; Position of BS device on building (height over ground) = h1. The higher the building or available infrastructure, the longer the reachable range Position of antenna on BS device = h2 (h3 = h1 + h2 = height of antenna over ground) and relatively to local environment. In order to optimize the performances and use the full device capacity, the antenna must be installed in a clear environment, away from any obstacle (LOS situation). Antenna tilting for BS device. After initial simulations for the Barajas case, a 3 was considered. Of course, this parameter has to be adjusted and cannot be taken as a rule for the other airports. It has to be reconsidered for each airport, because it is linked to infrastructure availability (height of buildings), and to coverage goals. In RAMP area, operators would like to increase the BS antenna downtilt, in order to favor the power distributed close to the gates. On the other hand, if a maximum coverage has to be achieved, the BS antenna tilt would have to be moderate. Thus, a trade off will be necessary for each airport. As a result of this Barajas study and as is stated in , we can assume that very large airports will have similar coverage requirements as large airports around terminal areas. For GROUND and TOWER areas there could be a need to add one or two additional sectorized BSs to cover all 5 runways with accompanying taxiways.

210 208 C.3 Case study 2: AeroMACS Deployment at Toulouse Airport C.3.1 Global radio coverage in Toulouse airport For this small airport, a limited number of BS s has been considered, leading to deployment of 3 sectors, covering the gates and the runways. BSs1; 5100 MHz; GPS = N / E; Hant = 45 m BSs2; 5110 MHz; GPS = N / E; Hant = 45 m BSr1; 5130 MHz; GPS = N / E; Hant = 35 m The radio coverage is a DL estimation of the maximum range mainly driven by the BS transmitted power, BS antenna gain, MS antenna gain and MS sensitivity. The computed figures (taking into account waves reflection) are shown below. DL coverage Figure 71: Global coverage (DL) in composite server display: Vehicles with Hant=2m(left) Aircrafts with Hant=10m (right) We observe few differences, with a better coverage for aircrafts, mainly in specific areas (see arrows)

211 209 DL coverage limited by UL Let s consider now a coverage limited by the UL: Figure 72: Global coverage for aircrafts (Hant = 10m) in composite server display: DL coverage (left) DL coverage limited by UL (right) It is observed that the covering is achieved on the airport area in both cases, but the highest modulation (64QAM ¾) is not available for BS1 (sectors 1 and 2) because of the antennas heights and low downtilt selected. If the downtilt is increased, this could increase the capacity available close to the BS while reducing range.

212 210 Figure 73: Global coverage for aircrafts (Hant = 10m) in composite server display: DL coverage limited, no reflections considered Downtilt for BS1 (s1 & s2) has been increased from 5 to 7 Ranges

213 211 Figure 74: BS2 coverage - Aircrafts with Hant=10m, no reflections considered DL (left) - DL limited by UL (right) Coverage convention 64QAM 3/4 64QAM 2/3 64QAM 1/2 16QAM 3/4 16QAM 1/2 QPSK 3/4 QPSK 1/2 DL DL limited by the UL Table 84: BS2 Range for DL and DL limited by UL C.3.2 Simulation of inter-system interferences in Toulouse Purpose of the study The purpose of this study is the compatibility analysis between two different telecommunication systems; an existing MLS system and an AeroMACS deployment, operating in the same band and in the same area (around the Toulouse-Blagnac airport in France). In order to derive general rules, we will consider the worst case, and then make recommendations. More particularly, the calculations performed here will take care of : - interference due to AeroMACS transmitters (3 stations) on MLS receivers (2 stations); - interference due to MLS transmitters (2 stations) on AeroMACS Base stations (Uplink on 3 stations); - interference due to MLS transmitters (2 stations) on AeroMACS receivers (Downlink for mobiles).

214 212 Figure 75: Localization of AeroMACS BS (in red, BS Tower with 2 sectors BSs1 and BSs2) and Tx MLS Stations (MLS AZ and MLS El in yellow) and Rx MLS Stations (Rx Az and Rx El in magenta) Cartographic database The different cartographic layers used in this study are described as follows : - a digital terrain model with 5m resolution providing the altitude of the terrain on any point; - an image with 2.5m resolution used in the background; - a building layer describing the height and the shape of each building in the area; - a clutter layer with 5m resolution containing four classes describing the nature of the ground: open area, building, water and vegetation. Propagation model The following propagation model has been chosen : - free space losses according to the ITU-R P.525 recommendation, - diffraction according to the Deygout 1994 model,

215 213 - and "standard integration" model for the sub-path attenuation. Network and Simulation parameters MLS transmitting station Tx The MLS transmitting radio station parameters as well as the radiation patterns of the antennas connected are described below. Name Azimuth Ground Coordinates 43 36' "N / 1 22' "E Nominal Power 30W Frequency (Bandwidth) MHz (CW for beam scanning) / (300kHz for DPSK) Antenna Gain 27dBi (scanning) / 12.5 dbi (DPSK) Antenna 3dB Beam width (az) 1.65 (scanning) / +/- 50 (DPSK) Antenna 3dB Beam width (el) 0-20 Height above the Ground 1.5 m Azimuth / North 310 Tilt (>0 Uptilt) 0 Name Elevation Ground Coordinates 43 38' "N / 1 20' "E Nominal Power 30W Frequency (Bandwidth) MHz (CW for beam scanning) / (300kHz for DPSK) Antenna Gain 22dBi (scanning) / 12.5 dbi (DPSK) Antenna 3dB Beam width (az) 1.3 (scanning) / +/- 50 (DPSK) Antenna 3dB Beam width (el) 0-20 Height above the Ground 2.5 m Azimuth / North Tilt (>0 Uptilt) 0 Table 85: Azimuth and Elevation Tx MLS Station parameters NOTE: The simulations have been done for the worst case, i.e. the gain of the scanning signal has been considered for the calculations, as for the bandwidth and the horizontal aperture of the DPSK signal.

216 214 Figure 76: Radiation patterns attached to each MLS transmitting station Operational coverage A/C landing Figure 77: Schematic representation of Tx MLS stations H patterns over Toulouse airport MLS receiving station Rx

217 215 The MLS receiving radio station parameters as well as the radiation patterns of the antennas connected are described below. Name Monitor angle Azimut Location 30m in front of AZ Tx station Coordinates 43 36'57.5"N / 1 22'30.7"E Frequency (Bandwidth) MHz (60 MHz) no selectivity Antenna Gain 10dBi Antenna 3dB Beam width (az) +/- 50 Antenna 3dB Beam width (el) 12 Noise factor 11 db KTBF -108dBm Height above the Ground 2m Azimuth / North 310 Tilt (>0 Uptilt) 0 Name Monitor angle Site Location 30m in front of EL Tx station Coordinates 43 38'32.3"N / 1 20'57.7"E Frequency (Bandwidth) MHz (300kHz) Antenna Gain 10dBi Antenna 3dB Beam width (az) +/- 50 Antenna 3dB Beam width (el) 12 Noise factor 11 db KTBF -108dBm Height above the Ground 2m Azimuth / North 310 Tilt (>0 Uptilt) 0 Table 86: Azimut and Elevation Rx MLS station parameters

218 216 Figure 78: Radiation patterns attached to each MLS receiving stations AeroMACS transmitting stations The main parameters for AeroMACS radio transmitters and their antennas are described below. Site Name Longitude (DMS) Latitude (DMS) Nom. Power (W) Tx Ant. Gain (dbi) Tx/Rx Losses (db) Rad. Power (W) Tower BSs Tower BSs VHF BSrs Azimuth Tilt Antenna Frequency Bandwidth KTBF Name Site ( ) ( ) (m) (MHz) (khz) (dbm) Tower BSs Tower BSs VHF BSrs Table 87: Parameters of AeroMACS stations Figure 79: Radiation patterns of antennas attached to AeroMACS stations AeroMACS receiving stations

219 217 For receiving Mobile Stations, an omnidirectional antenna has been considered, 2m over ground, taking into account a minimum coverage threshold of -92dBm, with a KTBF value of -98dBm. Interference parameters In the whole study, all transmitters are supposed to be operating at the same frequency and no rejection on the interfering signals (except the power diffusion effect) has been considered. In case of a AeroMACS signal with 5MHz bandwidth is interfering a MLS signal with 300kHz bandwidth at the same frequency, the power diffusion effect will reduce the interfering power of 10*log(300/5000) = -12.2dB The interference levels are considered as the sum of all interferers and are expressed in terms of Threshold Degradation (TD in db) defined by : TD (db) = 10*log((Sum(I)+KTBF)/KTBF) A common value used for the maximum TD is between 1 and 3 db as a criterion that there is no significant interference. Results Interference on MLS receiving stations According to the above assumptions, the TD is computed on the 2 MLS receiving stations with the 3 AeroMACS base stations considered as interferers. The results, which depend on the distance and on the antenna orientation, are given below. Wanted station (Rx) Rx Az MLS Rx Az MLS Rx Az MLS Rx El MLS Rx El MLS Rx El MLS Rx KTBF (dbm) Interferer (Tx) AeroMACS Tx BSs1 AeroMACS Tx BSs2 AeroMACS Tx BSrs1 AeroMACS Tx BSs1 AeroMACS Tx BSs2 AeroMACS Tx BSrs1 Unwanted Power (dbm) TD (db) Cumulated TD (db) Rejection (db) Tx BW (khz) Rx BW (khz) Distance Tx-Rx (m) Table 88: TD calculation for Interference on MLS receiving stations In order to avoid interference from AeroMACS stations on MLS receivers, an additional rejection of 16dB would be required in the case maximum TD=3dB. This rejection might be provided by a

220 218 combination of spatial separation, frequency separation between the 2 systems and receiver filtering (to be further investigated). Interference on AeroMACS base stations According to the above assumptions, the TD is computed on the 3 AeroMACS stations (Uplink) with the 2 MLS transmitting stations considered as interferers. The results, which depend on the distance and on the antenna orientation, are given below. Wanted station (Rx) AeroMACS Rx BSs1 AeroMACS Rx BSs1 AeroMACS Rx BSs2 AeroMACS Rx BSs2 AeroMACS Rx BSrs1 AeroMACS Rx BSrs1 Rx KTBF (dbm) Interferer (Tx) Unwanted Power (dbm) TD (db) Cumulated TD (db) Rejection (db) Tx BW (khz) Rx BW (khz) Distance Tx-Rx (m) -96 Tx Az MLS Tx El MLS Tx Az MLS Tx El MLS Tx Az MLS Tx El MLS Table 89: TD calculation for Interference on AeroMACS base stations In order to avoid interference from MLS transmitters on AeroMACS base station receivers, an additional rejection of 48dB would be required in the case maximum TD=3dB. This rejection might be provided by a combination of receiving filters and frequency separation between the 2 systems. Using a frequency separation of 2 channels (N+/-2) might be enough, but this has to be confirmed by a further analysis requiring more detailed information about the AeroMACS receivers (out of band rejection). Interference on AeroMACS receiving stations According to the above assumptions, the TD is computed over the AeroMACS downlink coverage (where the AeroMACS mobile receivers are) with the 2 MLS transmitting stations considered as interferers. The results are given in the following maps : On a first simulation, Threshold degradation map on AeroMACS DL coverage interfered by Tx MLS stations have been computed, without any rejection applied.

221 219 Figure 80: Threshold Degradation map for Tx MLS vs. AeroMACS DL coverage - No rejection On a second simulation, Threshold degradation map on AeroMACS DL coverage interfered by Tx MLS stations have been computed, with a rejection of 70dB applied on each interferer

222 220 Figure 81: Threshold Degradation map for Tx MLS vs. AeroMACS DL coverage 70 db rejection In order to have a limited interfered area from MLS transmitters on AeroMACS mobile receivers, an additional rejection of 70dB would be required. In that case, only areas very close to the MLS transmitters (in magenta) will be interfered. This rejection might be provided by a combination of spatial separation, frequency separation between the 2 systems and receiver filtering (to be further investigated).