1. business and industrial
2. company
3. bankruptcy

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)
Draft 0.19, November 2014
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
92240 MALAKOFF, France
Web Site: www.eurocae.net
Tel: 33 1 40 92 79 30
Fax: 33 1 46 55 62 65
Email: [email protected]
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
© EUROCAE, 20XX
i
FOREWORD
1.
2.
3.
4.
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].
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.
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.
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>
•
5.
6.
7.
<For extensive changes, consider the inclusion of a revision history table
as an annex to the document.>
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.>
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.
Copies of this document may be obtained from:
EUROCAE
102, rue Etienne Dolet
92240 MALAKOFF
France
Telephone: 33 1 40 92 79 30
Fax: 33 1 46 55 62 65
Email: [email protected]
Website: www.eurocae.net
© EUROCAE, 20XX
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
TABLE OF CONTENTS ........................................................................................................ II
LIST OF FIGURES.............................................................................................................. VII
LIST OF TABLES ............................................................................................................ IXVII
CHAPTER 1
INTRODUCTION ......................................................................................138
1.1
1.2
1.3
1.3.1
1.3.2
1.4
CHAPTER 2
OVERALL SYSTEM DESCRIPTION .....................................................2116
2.1
2.1.1
2.1.2
2.1.3
2.1.4
2.1.5
2.1.6
2.1.7
2.1.8
CHAPTER 3
PURPOSE AND SCOPE ............................................................................ 138
RELATIONSHIPS TO OTHER DOCUMENTS ........................................... 149
DESCRIPTION OF THIS DOCUMENT ...................................................... 149
DOCUMENT CONVENTIONS ................................................................... 149
DEFINITIONS ............................................................................................. 149
REFERENCES ......................................................................................... 1813
NETWORK REFERENCE MODEL ................................................................... 2116
OVERVIEW.................................................................................................. 2116
REFERENCE POINTS ................................................................................... 2217
ASN REFERENCE MODEL ........................................................................... 2217
ASN REFERENCE POINTS ........................................................................... 2419
AEROMACS NETWORK ARCHITECTURE INTEROPERABILITY SCOPE .............. 2419
CSN REFERENCE MODEL ........................................................................... 2419
AEROMACS ASN PROFILE......................................................................... 2419
AEROMACS ASN PROFILE CHOICE ............................................................ 2722
AEROMACS NETWORK ARCHITECTURE ..........................................2823
3.1
3.1.1
3.1.2
3.1.3
3.2
3.2.1
3.2.2
3.2.3
3.2.4
3.3
3.3.1
3.4
FUNCTIONAL REQUIREMENTS ...................................................................... 2823
ACCESS SERVICE NETWORK (ASN) REQUIREMENTS .................................... 2823
CORE SERVICE NETWORK (CSN) REQUIREMENTS........................................ 2823
SERVICE PROVISION REQUIREMENTS .......................................................... 2924
FUNCTIONAL ARCHITECTURE ....................................................................... 2924
BUSINESS ENTITIES (NAP, V-NSP, H-NSP) ................................................ 3025
NETWORK ENTITIES..................................................................................... 3126
ADDRESSING CONCEPT ............................................................................... 3732
NETWORK ENTRY AND NAP/NSP SELECTION ............................................... 3833
AIRPORT NETWORK INFRASTRUCTURE ......................................................... 4136
BARAJAS AIRPORT NETWORK TOPOLOGY...................................................... 4136
DEPLOYMENT MODELS ................................................................................ 4540
© EUROCAE, 20XX
iii
3.4.1
3.4.2
3.5
3.5.1
3.5.2
3.5.3
3.5.4
3.5.5
3.5.6
3.5.7
CHAPTER 4
APPLICATIONS.....................................................................................6055
4.1
4.2
4.3
CHAPTER 5
OPERATING ALTITUDE ................................................................................ 7065
COVERAGE ................................................................................................. 7065
ATS AND AOC SUPPORT ............................................................................ 7065
REGISTRATION PROCEDURE ........................................................................ 7065
MOBILITY AND HANDOVER .......................................................................... 7065
PERFORMANCE MONITORING ....................................................................... 7166
SYSTEM SUPERVISION ................................................................................. 7166
AEROMACS TECHNICAL REQUIREMENTS........................................7267
6.1
6.2
6.3
6.4
6.5
6.6
6.7
6.8
CHAPTER 7
OPERATIONAL CONCEPT ............................................................................. 6055
SERVICE INSTANTIATION ............................................................................. 6661
QOS MODEL ............................................................................................... 6762
AEROMACS OPERATIONAL REQUIREMENTS ..................................7065
5.1
5.2
5.3
5.4
5.5
5.6
5.7
CHAPTER 6
NSP & NAP DEPLOYMENT MODELS ............................................................. 4540
ROAMING SCENARIOS ................................................................................. 4843
AEROMACS AIRBORNE ARCHITECTURE ........................................... 5146
FOREWORD ON OVERALL AIRCRAFT SYSTEMS ORGANISATION ....................... 5146
ASSUMPTIONS REGARDING THE INITIAL IMPLEMENTATION OF AIRBORNE
AEROMACS SYSTEMS: ............................................................................... 5247
SCENARIO 1-A – “NEAR TERM INITIAL INSTALLATION OF THE AEROMACS MS IN
THE AISD DOMAINS”: .................................................................................. 5247
SCENARIO 2-A – “MEDIUM TERM INITIAL INSTALLATION OF THE AEROMACS MS IN
THE ACD DOMAIN”: ..................................................................................... 5449
SCENARIO 2-B – “MEDIUM TERM INSTALLATION OF THE AEROMACS MS IN BOTH
THE ACD AND AISD DOMAINS” .................................................................... 5550
SCENARIO 3-A – “LONGER TERM INSTALLATION OF THE AEROMACS MS IN THE
ACD DOMAIN” ............................................................................................ 5651
SCENARIO 3-B – “LONGER TERM INSTALLATION OF THE AEROMACS MS IN BOTH
THE ACD AND AISD DOMAINS” .................................................................... 5752
MIN MAX AIRCRAFT, VEHICLE SPEED ........................................................... 7267
ATS AND AOC SUPPORT ............................................................................ 7267
REGISTRATION PROCEDURE ........................................................................ 7267
MOBILITY AND HANDOVER .......................................................................... 7267
SYNCHRONIZATION AND TIMING REQUIREMENTS .......................................... 7267
DATA LATENCY .......................................................................................... 7368
RESIDUAL ERROR RATE .......................................................................... 7368
SYSTEM SUPERVISION ................................................................................. 7368
QUALITY OF SERVICE REQUIREMENTS............................................7469
7.1
7.1.1
7.1.2
7.1.3
7.1.4
7.1.5
AEROMACS SERVICE FLOWS .................................................................... 7469
EXTENDED REAL-TIME POLLING SERVICE .................................................... 7469
REAL-TIME POLLING SERVICE ..................................................................... 7469
NON-REAL TIME POLLING SERVICE .............................................................. 7469
BEST EFFORT SERVICE ............................................................................... 7469
UNSOLICITED GRANT SERVICE .................................................................... 7570
© EUROCAE, 20XX
iv
7.2
CHAPTER 8
SAFETY AND PERFORMANCE REQUIREMENTS ..............................7671
8.1
8.1.1
8.1.2
8.1.3
8.1.4
8.2
8.2.1
8.2.2
8.3
8.3.1
8.3.2
8.3.3
8.4
CHAPTER 9
INPUTS TO COVERAGE AND CAPACITY REQUIREMENTS .................................... 80
AMOUNT OF GATES AND STANDS ..................................................................... 80
AIRPORT AREAS DEFINITIONS.......................................................................... 80
AIRPORT VISITING A/C FRAME TYPES AND AIRPORT TRAFFIC MIX ....................... 80
AIRCRAFT FRAME ANTENNA HEIGHTS FROM GROUND ........................................ 81
TRAFFIC MODELLING AND SCENARIO DEFINITION ............................................. 82
SESAR 15.2.7 AIRPORT CATEGORIZATION..................................................... 85
SYSTEM INTEROPERABILITY .................................................................94
10.1
CHAPTER 11
SAFETY AND PERFORMANCE REQUIREMENTSERROR! BOOKMARK NOT DEFINED.71
DEFINITIONS ............................................... ERROR! BOOKMARK NOT DEFINED.71
DOMAINS OF RESPONSIBILITY ...................... ERROR! BOOKMARK NOT DEFINED.72
SERVICES AND APPLICATIONS ...................... ERROR! BOOKMARK NOT DEFINED.74
SAFETY AND PERFORMANCE REQUIREMENTS APPLICABLE TO ACSP ......... ERROR!
BOOKMARK NOT DEFINED.74
SAFETY AND PERFORMANCE REQUIREMENTS: IMPLEMENTATION GUIDANCE
................................................................... ERROR! BOOKMARK NOT DEFINED.75
SOFTWARE ASSURANCE LEVEL REQUIREMENT .............ERROR! BOOKMARK NOT
DEFINED.75
GUIDANCE TO MEET THE AVAILABILITY REQUIREMENTS.....ERROR! BOOKMARK NOT
DEFINED.75
GUIDANCE TO MEET THE TRANSACTION TIME REQUIREMENTS .. ERROR! BOOKMARK
NOT DEFINED.77
CSN FUNCTION .......................................... ERROR! BOOKMARK NOT DEFINED.77
ASN FUNCTION........................................... ERROR! BOOKMARK NOT DEFINED.77
TRAFFIC REQUIREMENTS ............................ ERROR! BOOKMARK NOT DEFINED.78
OVERVIEW OF SPR VALUES ......................... ERROR! BOOKMARK NOT DEFINED.78
COVERAGE AND CAPACITY ...................................................................80
9.1
9.1.1
9.1.2
9.1.3
9.1.4
9.1.5
9.2
CHAPTER 10
PRIORITIZATION .......................................................................................... 7570
MULTI-VENDOR INTEROPERABILITY ................................................................. 94
INTERFERENCE .......................................................................................97
11.1
11.1.1
11.1.2
11.2
11.2.1
11.2.2
11.3
11.3.1
11.3.2
11.3.3
11.4
11.5
REGULATORY ASPECTS .................................................................................. 97
AMT .............................................................................................................. 97
MSS .............................................................................................................. 98
IMPACT OF OUT OF BAND INTERFERENCE ON DEPLOYMENT (MLS)................... 98
SEPARATION REQUIREMENTS .......................................................................... 98
IMPACT ON AEROMACS DEPLOYMENT ............................................................. 99
IMPACT OF IN BAND INTERFERENCE ON DEPLOYMENT (AMT) ........................... 99
UTILISATION OF AMT ON 5 GHZ BY AIRBUS ..................................................... 99
SEPARATION REQUIREMENTS .................................................................. 102101
IMPACT ON AEROMACS DEPLOYMENT ..................................................... 104103
MSS INTERFERENCE ANALYSIS FOR AEROMACS ................................... 104103
POTENTIAL FUTURE INTERFERENCE SOURCES......................................... 107106
© EUROCAE, 20XX
v
CHAPTER 12
RF CELL DIMENSIONING AND PLANNING ..................................... 108107
12.1
12.1.1
12.1.2
12.2
12.2.1
RF CELL DIMENSIONING ......................................................................... 108107
COVERAGE ANALYSIS .............................................................................. 108107
CAPACITY ANALYSIS ............................................................................... 116115
RF CELL PLANNING ........................................................................... 125124
SIMULATION OF INTRA-SYSTEM INTERFERENCE ......................................... 125124
CHAPTER 13
SECURITY REQUIREMENTS ............................................................ 129127
CHAPTER 14
TEST CASES ..................................................................................... 131129
14.1
IPV6 TEST CASES SPECIFICATION ............................................................ 131129
14.1.1 TEST CONFIGURATION 1 .......................................................................... 131129
14.1.2 TESTS DESCRIPTION ............................................................................... 132129
14.1.3 TC-IPV6-STFUL.................................................................................... 133130
IPV6 CS: STATEFUL CONFIGURATION ..................................................................... 133130
TC-IPV6-STFUL ................................................................................................... 133130
14.1.4 TC-IPV6-STLESS-BV ........................................................................... 134131
IPV6 CS: STATELESS CONFIGURATION (VALID BEHAVIOUR) ..................................... 134131
TC-IPV6-STLESS-BV .......................................................................................... 134131
14.1.5 TC-IPV6-STLESS-BI ............................................................................. 135132
IPV6 CS: STATELESS CONFIGURATION (INVALID BEHAVIOUR) .................................. 135132
TC-IPV6-STLESS-BI............................................................................................ 135132
THE AEROMACS SYSTEM SUPPORTS STATELESS ADDRESS AUTO-CONFIGURATION IN THE
CASE OF INVALID BEHAVIOUR. ................................................................. 135132
14.1.6 TC-IPV6-FRAG..................................................................................... 135132
IPV6 CS: IPV6 FRAGMENTATION ............................................................................ 135132
TC-IPV6-FRAG .................................................................................................... 135132
14.2
ETHERNET CS TEST CASES SPECIFICATION.............................................. 136133
14.2.1 TEST CONFIGURATION 1 .......................................................................... 136133
14.2.2 TESTS DESCRIPTION ............................................................................... 138134
14.2.3 TC-ETH-CS-IP_RULE ........................................................................... 139135
ETHERNET CS: IP HEADER BASED CLASSIFICATION ................................................. 139135
TC-ETH-CS-IP_RULE........................................................................................... 139135
14.2.4 TC-ETH-CS-VLAN_RULE ..................................................................... 140136
ETHERNET CS: IP HEADER BASED CLASSIFICATION ................................................. 140136
TC-ETH-CS-VLAN_RULE .................................................................................... 140136
14.2.5 TC-ETH-CS-TOS_RULE ........................................................................ 141137
ETHERNET CS: TYPE OF SERVICE BASED CLASSIFICATION ...................................... 141137
TC-ETH-CS-TOS_RULE ....................................................................................... 141137
THE AEROMACS SYSTEM SUPPORTS TYPE OF SERVICE BASED CLASSIFICATION. .... 141137
14.3
CONVERGENCE SUBLAYER ESTABLISHMENT ............................................ 143139
14.3.1 TEST CONFIGURATION 1 .......................................................................... 143139
14.3.2 TESTS DESCRIPTION ............................................................................... 143139
14.3.3 TC-CS-IPV6_FB ................................................................................... 144140
14.3.4 TC-CS-ETH_FB.................................................................................... 144140
14.4
D-TAXI TEST CASES .............................................................................. 145141
CM-LOGON: NOMINAL CASE ................................................................................... 145142
© EUROCAE, 20XX
vi
CM_001 145142
CPDLC CONNECTION: ACCEPTED .......................................................................... 146143
CPDLC_001 ......................................................................................................... 146143
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. .......................................................................... 146143
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). ...................................................... 146143
IT IS ASSUMED THAT AIRCRAFT1 IS ALREADY LOGGED TO THE GROUND SYSTEM (C.F. TEST
CM_001). .............................................................................................. 146143
SEND A CPDLC-START REQUEST TO AIRCRAFT1 (NO CPDLC MESSAGE ELEMENT
PROVIDED). ............................................................................................ 146143
CHECK AIRCRAFT1 RECEIVES THE CPDLC-START INDICATION (NO CPDLC MESSAGE
ELEMENT PROVIDED) FROM GND1........................................................... 146143
SEND AN ACCEPTED CPDLC-START RESPONSE TO GND1. ..................................... 146143
CHECK GND1 RECEIVES THE ACCEPTED CPDLC-START CONFIRMATION FROM
AIRCRAFT1. ........................................................................................ 146143
SEND THE DM99 CURRENT DATA AUTHORITY MESSAGE TO GND1 ................. 146143
CHECK GND1 RECEIVES THE DM99 CURRENT DATA AUTHORITY MESSAGE FROM
AIRCRAFT1. ........................................................................................ 146143
SEND THE UM227 LACK MESSAGE TO AIRCRAFT1 TO ACKNOWLEDGE DM99 CURRENT
DATA AUTHORITY MESSAGE. ............................................................. 146143
CHECK AIRCRAFT1 RECEIVES THE UM227 LACK MESSAGE FROM GND1
ACKNOWLEDGING THE DM99 CURRENT DATA AUTHORITY MESSAGE.
.............................................................................................................. 146143
SEND THE UM183 'CURRENT ATC UNIT FACILITY DESIGNATION, FACILITY NAME,FACILITY
FUNCTION' MESSAGE TO AIRCRAFT1 .................................................... 146143
CHECK AIRCRAFT1 RECEIVES THE UM183 'CURRENT ATC UNIT FACILITY
DESIGNATION, FACILITY NAME, FACILITY FUNCTION' MESSAGE................... 146143
SEND THE DM100 LACK MESSAGE TO ACKNOWLEDGE THE UM183 'CURRENT ATC
UNIT FACILITY DESIGNATION, FACILITY NAME, FACILITY FUNCTION' MESSAGE
.............................................................................................................. 146143
CHECK GND1 RECEIVES THE DM100 LACK MESSAGE ACKNOWLEDGING THE UM183
'CURRENT ATC UNIT FACILITY DESIGNATION, FACILITY NAME, FACILITY
FUNCTION' MESSAGE ............................................................................... 146143
CHECK AIRCRAFT1 APPEARS AS LOGGED ON AND CPDLC CONNECTED TO GND1.
.............................................................................................................. 146143
CPDLC D_TAXI STARTUP ................................................................................. 147144
TAXI_001 ............................................................................................................. 147144
THE PURPOSE OF THIS TEST IS TO VERIFY THE GROUND SYSTEM CORRECTLY HANDLES THE
CPDLC TAXI STARTUP ......................................................................... 147144
CPDLC_001 ......................................................................................................... 147144
SEND THE DM25 REQUEST [START-UP] CLEARANCE .................................... 147144
CHECK GND1 RECEIVES THE DM25 REQUEST [START-UP] CLEARANCE ....... 147144
SEND THE UM227 LACK MESSAGE TO AIRCRAFT1 TO ACKNOWLEDGE DM25 REQUEST
[START-UP] CLEARANCE MESSAGE. ................................................. 147144
CHECK AIRCRAFT1 RECEIVES THE UM227 LACK MESSAGE FROM GND1
ACKNOWLEDGING THE DM25 REQUEST [START-UP] CLEARANCE
MESSAGE. .............................................................................................. 147144
SEND THE UM311 START UP APPROVED .......................................................... 147144
CHECK AIRCRAFT1 RECEIVES THE UM311 START UP APPROVED................... 147144
© EUROCAE, 20XX
vii
SEND THE DM100 LACK MESSAGE TO GND1 TO ACKNOWLEDGE THE UM311 START UP
APPROVED ......................................................................................... 147144
CHECK GND1 RECEIVES THE DM100 LACK FROM AIRCRAFT1 ACKNOWLEDGING THE
UM311 START UP APPROVED .......................................................... 147144
APPENDIX A
GUIDELINES FOR <XXX> ................................................................. 148145
APPENDIX B
ACRONYMS AND GLOSSARY OF TERMS ...................................... 149146
APPENDIX C
CAPACITY ANALYSIS ...................................................................... 153150
C.1
C.1.1
C.1.2
C.2
C.2.1
C.2.2
C.2.3
C.2.4
C.2.5
C.2.6
C.2.7
1.
2.
3.
A.
B.
C.
4.
APPENDIX D
CAPACITY ANALYSIS PER OPERATIONAL DOMAIN ...................................... 153150
HYPOTHESES MADE IN SIMULATIONS ........................................................ 153150
ANALYSIS OF RESULTS ............................................................................ 159156
CAPACITY ANALYSIS PER AIRPORT .......................................................... 163160
OPERATIONAL CONCEPT.......................................................................... 163160
PROPAGATION AND PHY/MAC LAYER MODEL .......................................... 164161
SCENARIO 1 ........................................................................................... 165162
SCENARIO 2 ........................................................................................... 172169
QOS MODEL ........................................................................................... 178175
HANDOVER CONFIGURATION.................................................................... 180176
BACKGROUND TRAFFIC ........................................................................... 181178
AIR TRAFFIC FIGURES IN MADRID BARAJAS............................................... 181178
BACKGROUND TRAFFIC MODEL ................................................................ 181178
SIMULATION RESULTS ............................................................................. 184181
SCENARIO 1 – SIMULATION RESULTS ....................................................... 185182
SCENARIO 2– SIMULATION RESULTS........................................................ 191188
COMPARISON BETWEEN ITERATION 1 AND ITERATION 2 FOR SCENARIO 1. .. 197194
HANDOVER RESULTS............................................................................... 202199
AEROMACS DEPLOYMENT CASE STUDIES .................................. 205202
D.1
D.2
D.2.1
D.2.2
D.2.3
D.3
D.3.1
D.3.2
PREAMBLE: RADIO PLANNING TOOL AND PARAMETERS ....................... 205202
CASE STUDY 1: AEROMACS DEPLOYMENT AT BARAJAS AIRPORT .......... 207204
GLOBAL RADIO COVERAGE IN BARAJAS AIRPORT (DL)............................... 213210
RADIO COVERAGE LIMITED BY THE UPLINK (UL)........................................ 218215
CONCLUSIONS AND RECOMMENDATION .................................................... 220217
CASE STUDY 2: AEROMACS DEPLOYMENT AT TOULOUSE AIRPORT ........ 222219
GLOBAL RADIO COVERAGE IN TOULOUSE AIRPORT .................................... 222219
SIMULATION OF INTER-SYSTEM INTERFERENCES IN TOULOUSE .................. 225222
APPENDIX E HISTORY AND TERMS OF REFERENCE OF WG-82ERROR! BOOKMARK
NOT DEFINED.233
APPENDIX F
WG-82 MEMBERSHIP ....................................................................... 236234
IMPROVEMENT SUGGESTION FORM ....................................................................... 237235
LIST OF FIGURES
FIGURE 1: ILLUSTRATION OF REFERENCE POINTS FOR THE MAXIMUM DATA LATENCY.................................... 17
© EUROCAE, 20XX
viii
FIGURE 2: NETWORK REFERENCE MODEL................................................................................................. 22
FIGURE 3: ASN REFERENCE MODEL ........................................................................................................ 23
FIGURE 4: WMF ASN PROFILE A ............................................................................................................. 25
FIGURE 5: WMF ASN PROFILE B ............................................................................................................. 26
FIGURE 6: WMF ASN PROFILE C ............................................................................................................. 27
FIGURE 7: OVERALL RELATIONS BETWEEN AEROMACS BUSINESS ENTITIES [10] ........................................ 30
FIGURE 8: AEROMACS NETWORK ENTITIES .............................................................................................. 32
FIGURE 9: MAIN FUNCTIONALITIES OF AEROMACS ASN-GW [10]............................................................. 33
FIGURE 10: AEROMACS AAA AND HA DEPLOYMENT SCENARIO ............................................................... 36
FIGURE 11: ICAO WG-I #7 RECOMMENDED FORMAT................................................................................. 37
FIGURE 12: ILLUSTRATION OF SANDRA ADDRESSING CONCEPT. ............................................................... 38
FIGURE 13: BARAJAS TERMINAL MAP OVERVIEW ........................................................................................ 42
FIGURE 14: BARAJAS MULTISERVICE AIRPORT NETWORK TOPOLOGY ........................................................ 43
FIGURE 15: BARAJAS RADIO NAVIGATION AIDS CABLING INFRASTRUCTURE .................................................. 44
FIGURE 16: BARAJAS MLAT SYSTEM CABLING INFRASTRUCTURE ............................................................... 45
FIGURE 17: SINGLE NAP - MULTIPLE NSP................................................................................................ 46
FIGURE 18: MULTIPLE NAP - SINGLE NSP................................................................................................ 46
FIGURE 19: GREENFIELD NAP-NSP ......................................................................................................... 47
FIGURE 20: AEROMACS ROAMING ARCHITECTURE ................................................................................... 49
FIGURE 21: ROAMING SCENARIO 1 [49] ..................................................................................................... 50
FIGURE 22:ROAMING SCENARIO 2 [49]...................................................................................................... 50
FIGURE 23: AEROMACS SYSTEM INTEGRATION ON A/C – SCENARIO 1-A................................................... 53
FIGURE 24: AEROMACS SYSTEM INTEGRATION ON A/C – SCENARIO 1-B................................................... 54
FIGURE 25: AEROMACS SYSTEM INTEGRATION ON A/C – SCENARIO 2-A................................................... 55
FIGURE 26: AEROMACS SYSTEM INTEGRATION ON A/C – SCENARIO 2-B................................................... 56
FIGURE 27: SCENARIO 2-B: CONNECTION BETWEEN AEROMACS AND ACD/AISD ..................................... 56
FIGURE 28: AEROMACS SYSTEM INTEGRATION ON A/C – SCENARIO 3-A................................................... 57
FIGURE 29: AEROMACS SYSTEM INTEGRATION ON A/C – SCENARIO 3-B................................................... 58
FIGURE 30: SCENARIO 3-B: CONNECTION BETWEEN AEROMACS AND ACD/AISD ..................................... 58
FIGURE 31: PHYSICAL SEGREGATION BETWEEN ACD AND AISD ................................................................ 59
FIGURE 32: FLIGHT PHASES AND EVENTS IN APT SURFACE ........................................................................ 60
FIGURE 33: SEQUENTIAL EXECUTION OF SERVICES IN ARRIVAL ................................................................... 66
FIGURE 34: SEQUENTIAL EXECUTION OF SERVICES IN DEPARTURE.............................................................. 67
FIGURE 35: DEFINITION AND INTERCONNECTION OF AIRCRAFT, ACSP AND ATSU DOMAIN .......................... 76
FIGURE 36: FRESNEL ZONE DETERMINATION PARAMETERS ..................................................................... 89
FIGURE 37: MINIMUM DISTANCE BETWEEN MLS TRANSMITTER AND AEROMACS RECEIVER [19] ................. 99
FIGURE 38: RECEPTION ANTENNA COVERAGE (20000 FT) ....................................................................... 101
FIGURE 39: MINIMUM SPATIAL SEPARATION AS FUNCTION OF SPECTRAL ISOLATION. TOTAL ISOLATION IS 154
DB. ................................................................................................................................................ 103
FIGURE 40: ITU-R-F-1336-2 REFERENCE ANTENNA PATTERNS AND MASK [43] ......................................... 106
FIGURE 41: COMPARISON OF AIRPORT PATHLOSS MODELS....................................................................... 111
FIGURE 42: GRAPHICAL PRESENTATION OF TILE IN UL-PUSC ZONE ; SLOT = 6 TILES OVER 3 SYMBOLS .... 113
FIGURE 43: FREQUENCY MASK............................................................................................................... 116
FIGURE 44: BER AND PER IN FL, LOS CHANNEL ([50], SECTION 4.4) ...................................................... 118
FIGURE 45: BER AND PER IN FL, NLOS CHANNEL [50] .......................................................................... 119
FIGURE 46: BER AND PER FOR RL, LOS CHANNEL [50] ......................................................................... 120
FIGURE 47: BER AND PER FOR RL, NLOS CHANNEL [50]....................................................................... 121
FIGURE 48: MAP OF C/I INTRA-SYSTEM INTERFERENCE, BASED ON DL COVERAGE ................................... 127
© EUROCAE, 20XX
ix
FIGURE 49: IPV6 TEST CASES TEST CONFIGURATION ........................................................................ 131130
FIGURE 50: ETHERNET CS TEST CASES TEST CONFIGURATION .......................................................... 136135
FIGURE 51: CS ESTABLISHMENT TEST CASES TEST CONFIGURATION ................................................. 143142
FEHLER! ES IST NICHT MÖGLICH, DURCH DIE BEARBEITUNG VON FELDFUNKTIONEN OBJEKTE ZU ERSTELLEN.
FIGURE 52: END-TO-END TEST CASE CONFIGURATION......................................................... 145144
FIGURE 49: MOBILE ROUTE MR1 ..................................................................................................... 157156
FIGURE 50: MOBILE ROUTE MR2 ..................................................................................................... 157156
FIGURE 51: THROUGHPUT & PACKET LOSS WITH ARQ TYPE 1 AND ARQ TYPE 2 (UL) ........................................... 160159
FIGURE 52: CASE 1: THROUGHPUT & PACKET LOSS IN LOS/NLOS (DL) ............................................................. 162161
FIGURE 53: CASE 2: THROUGHPUT & PACKET LOSS IN LOS/NLOS (DL) ............................................................. 162161
FIGURE 54: CASE 3: THROUGHPUT & PACKET LOSS IN LOS/NLOS (DL) ............................................................. 163162
FIGURE 55: SCENARIO 1 ARRIVAL TRAJECTORY ............................................................................................ 166165
FIGURE 56: SCENARIO 1 DEPARTURE TRAJECTORY ........................................................................................ 169168
FIGURE 57: SCENARIO 2 ARRIVAL TRAJECTORY ............................................................................................ 173172
FIGURE 58: SCENARIO 2 DEPARTURE TRAJECTORY ........................................................................................ 176175
FIGURE 59: UL/DL W IMAX FRAME. DATA BURST USAGE IN % .......................................................... 191190
FIGURE 60: UL/DL W IMAX FRAME. DATA BURST USAGE IN % .......................................................... 197196
FIGURE 61: W IMAX DOWNLINK DATA BURST USAGE. RED=ITERATION2. BLUE=ITERATION1. ............. 201200
FIGURE 62: W IMAX UPLINK DATA BURST USAGE. RED=ITERATION2. BLUE=ITERATION1. .................. 202201
FIGURE 63: HORIZONTAL AND VERTICAL PATTERN FOR BASE STATIONS (H: 3DB BEAMWIDTH = 110°; V: 3DB
BEAMWIDTH = 12° (TBC)) .......................................................................................................... 206205
FIGURE 64: PROPOSED CELL PLANNING IN MADRID BARAJAS ............................................................. 210209
FIGURE 65: PROPOSED CELL PLANNING IN MADRID BARAJAS – CLOSER DISTANCE BETWEEN BS IN HANDOVER
................................................................................................................................................ 212211
FIGURE 66: PROPOSED CELL PLANNING IN MADRID BARAJAS – RAMP ONLY ...................................... 212211
FIGURE 67: FOCUS ON BS POSITION AND LABEL ON BARAJAS’ AIRPORT .............................................. 214213
FIGURE 68: GLOBAL COVERAGE (DL) IN COMPOSITE SERVER DISPLAY: VEHICULES WITH HANT=2M(LEFT) –
AIRCRAFTS WITH HANT=10M (RIGHT)........................................................................................ 215214
FIGURE 69: R1S1 COVERAGE FOR HANT=2M(LEFT) AND HANT=10M (RIGHT) ...................................... 217216
FIGURE 70: GLOBAL COVERAGE (LIMITED BY UL) IN COMPOSITE SERVER DISPLAY: VEHICULES WITH HANT=2M
(LEFT) – AIRCRAFTS WITH HANT=10M (RIGHT) ........................................................................... 219218
FIGURE 71: R1S1 RADIO COVERAGE (LIMITED BY UL), AIRCRAFTS WITH HANT=10M............................ 220219
FIGURE 72: GLOBAL COVERAGE (DL) IN COMPOSITE SERVER DISPLAY: VEHICULES WITH HANT=2M(LEFT) –
AIRCRAFTS WITH HANT=10M (RIGHT)........................................................................................ 222221
FIGURE 73: GLOBAL COVERAGE FOR AIRCRAFTS (HANT = 10M) IN COMPOSITE SERVER DISPLAY: DL
COVERAGE(LEFT) – DL COVERAGE LIMITED BY UL (RIGHT).......................................................... 223222
FIGURE 74: 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° ........................................................................................................................... 224223
FIGURE 75: BS2 COVERAGE - AIRCRAFTS WITH HANT=10M, NO REFLECTIONS CONSIDERED DL (LEFT) - DL
LIMITED BY UL (RIGHT) .............................................................................................................. 225224
FIGURE 76: 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) ................................................................................................................................ 226225
FIGURE 77: RADIATION PATTERNS ATTACHED TO EACH MLS TRANSMITTING STATION .......................... 228227
FIGURE 78: SCHEMATIC REPRESENTATION OF TX MLS STATIONS H PATTERNS OVER TOULOUSE AIRPORT
................................................................................................................................................ 228227
FIGURE 79: RADIATION PATTERNS ATTACHED TO EACH MLS RECEIVING STATIONS .............................. 230229
FIGURE 80: RADIATION PATTERNS OF ANTENNAS ATTACHED TO AEROMACS STATIONS ...................... 230229
© EUROCAE, 20XX
x
FIGURE 81: THRESHOLD DEGRADATION MAP FOR TX MLS VS. AEROMACS DL COVERAGE - NO REJECTION
................................................................................................................................................ 234233
FIGURE 82: THRESHOLD DEGRADATION MAP FOR TX MLS VS. AEROMACS DL COVERAGE – 70 DB
REJECTION ............................................................................................................................... 234233
LIST OF TABLES
TABLE 1: POSSIBLE ACTORS FOR NAP/V-NSP/H-NSP FUNCTIONS............................................................ 31
TABLE 2: NSP ID FORMAT [32] ................................................................................................................. 40
TABLE 3: AEROMACS DEPLOYMENT SCENARIOS PROPOSED...................................................................... 47
TABLE 4: SERVICES EXECUTED DURING DEPARTURE PHASE ....................................................................... 62
TABLE 5: SERVICES EXECUTED DURING ARRIVAL PHASE ............................................................................. 65
TABLE 6: ATN/IPS PRIORITY MAPPING INTO CLASSES PROPOSED BY [12] ................................................... 68
TABLE 7: COS CLASSIFICATION FOR AIRPORT CAPACITY ANALYSIS ............................................................ 69
TABLE 8: AEROMACS CLASSES OF SERVICE EXAMPLE [3].......................................................................... 75
TABLE 9: ACSP TRANSACTION TIME REQUIREMENTS [40] ......................................................................... 77
TABLE 10: ACSP AVAILABILITY REQUIREMENTS [40] ................................................................................. 78
TABLE 11: ATC AND AOC REQUIRED THROUGHPUT AND PACKET SIZES ...................................................... 79
TABLE 12: A/C SEPARATION MINIMA .......................................................................................................... 81
TABLE 13: AIRFRAME HEIGHTS WITH RESPECT TO GROUND ........................................................................ 81
TABLE 14: A/C DWELL TIMES VS A/C AIRPORT OPERATION AREAS .............................................................. 82
TABLE 15: AEROMACS EXPECTED THROUGHPUTS VS MODULATION SCHEMES ............................................ 83
TABLE 16: SINGLE SECTOR SCENARIO – EXCLUDING FOQA....................................................................... 84
TABLE 17: AIRPORT SIZE CATEGORIES ACCORDING TO COCR ................................................................... 84
TABLE 18: AIRPORT CAPACITY LOAD FOR SMALL AIRPORTS (3 OPERATIONS/HOUR) ...................................... 85
TABLE 19: AIRPORT CAPACITY LOAD FOR SMALL AIRPORTS (3 OPERATIONS/HOUR) CONSIDERING FOQA AS A
RAMP SERVICE................................................................................................................................ 86
TABLE 20: AIRPORT CAPACITY LOAD FOR SMALL AIRPORTS (20 OPERATIONS/HOUR) .................................... 87
TABLE 21: AIRPORT CAPACITY LOAD FOR MEDIUM AIRPORTS (50 OPERATIONS/HOUR) ................................. 89
TABLE 22: AIRPORT CAPACITY LOAD FOR LARGE AIRPORTS (100 OPERATIONS/HOUR) ................................. 91
TABLE 23: AIRPORT CAPACITY LOAD FOR VERY LARGE AIRPORTS (MORE THAN 100 OPERATIONS/HOUR) ...... 92
TABLE 24: TELEMETRY FREQUENCY ALLOCATIONS (USA) [20] ................................................................... 97
TABLE 25: AMT CHARACTERISTICS ......................................................................................................... 102
TABLE 26: DL LINK BUDGET ................................................................................................................... 112
TABLE 27: UL LINK BUDGET ................................................................................................................... 115
TABLE 28: W ALL ATTENUATION VALUES .................................................................................................. 115
TABLE 29: W INDOW ATTENUATION VALUES.............................................................................................. 115
TABLE 30: MCS SWITCHING THRESHOLDS .............................................................................................. 122
TABLE 31: MAXIMUM COVERAGE RESULTS............................................................................................... 123
TABLE 32: FREQUENCY PLANNING & REUSE FOR INTRA-SYSTEM INTERFERENCE ANALYSIS ........................ 125
TABLE 33: C/I VERSUS MODULATION SCHEMES ....................................................................................... 127
TABLE 34: SERVICE DATA UNIT DIMENSIONING (BYTES)..................................................................... 154153
TABLE 35: PHY LAYER PARAMETERS................................................................................................ 154153
TABLE 36: MCS SWITCHING THRESHOLDS ........................................................................................ 155154
TABLE 37: BARAJAS PATHLOSS MODELS’ PARAMETERS ..................................................................... 156155
TABLE 38: MAIN ARQ PARAMETERS ................................................................................................. 158157
TABLE 39: SECONDARY-LEVEL ARQ PARAMETERS ............................................................................ 158157
TABLE 40: SIZE OF PDU AND ARQ BLOCKS ...................................................................................... 159158
TABLE 41: ARRIVAL SPEEDS ............................................................................................................. 165164
© EUROCAE, 20XX
xi
TABLE 42: DEPARTURE SPEEDS........................................................................................................ 165164
TABLE 43: SCENARIO 1 ARRIVAL TRAJECTORY TIMES ......................................................................... 167166
TABLE 44: CHRONOLOGICAL DESCRIPTION OF SCENARIO 1 ARRIVAL TRAJECTORY............................... 168167
TABLE 45: SCENARIO 1 DEPARTURE TRAJECTORY TIMES.................................................................... 170169
TABLE 46: CHRONOLOGICAL DESCRIPTION OF SCENARIO 1 DEPARTURE TRAJECTORY ......................... 172171
TABLE 47: SCENARIO 2 ARRIVAL TRAJECTORY TIMES ......................................................................... 174173
TABLE 48: CHRONOLOGICAL DESCRIPTION OF SCENARIO 2 ARRIVAL TRAJECTORY............................... 175174
TABLE 49: SCENARIO 2 DEPARTURE TRAJECTORY TIMES.................................................................... 176175
TABLE 50: CHRONOLOGICAL DESCRIPTION OF SCENARIO 2 DEPARTURE TRAJECTORY ......................... 178177
TABLE 51: COS CLASSIFICATION FOR AIRPORT CAPACITY ANALYSIS .................................................. 179178
TABLE 52: HANDOVER PARAMETERS ................................................................................................. 180179
TABLE 53: RAMP ARRIVAL BACKGROUND TRAFFIC ........................................................................... 182181
TABLE 54: RAMP DEPARTURE BACKGROUND TRAFFIC ...................................................................... 182181
TABLE 55: GROUND ARRIVAL BACKGROUND TRAFFIC ...................................................................... 182181
TABLE 56: GROUND DEPARTURE BACKGROUND TRAFFIC ................................................................ 182181
TABLE 57: TOWER ARRIVAL BACKGROUND TRAFFIC ........................................................................ 183182
TABLE 58: TOWER DEPARTURE BACKGROUND TRAFFIC ................................................................... 183182
TABLE 59: UL&DL BACKGROUND TRAFFIC ....................................................................................... 183182
TABLE 60: CELL PLANNING FEATURES USED IN CAPACITY SIMULATIONS............................................... 185184
TABLE 61: END TO END DELAY PER CLASS OF SERVICE ..................................................................... 186185
TABLE 62: NET SERVICES RESPONSE TIME ...................................................................................... 186185
TABLE 63: ATC1 SERVICES RESPONSE TIME .................................................................................... 186185
TABLE 64: ATC2 SERVICES RESPONSE TIME .................................................................................... 187186
TABLE 65: ATC3 SERVICES RESPONSE TIME .................................................................................... 187186
TABLE 66: AOC1 SERVICES RESPONSE TIME ................................................................................... 189188
TABLE 67: AOC2 SERVICES RESPONSE TIME ................................................................................... 189188
TABLE 68: END TO END DELAY PER CLASS OF SERVICE ..................................................................... 192191
TABLE 69: NET SERVICES RESPONSE TIME ...................................................................................... 192191
TABLE 70: ATC1 SERVICES RESPONSE TIME .................................................................................... 192191
TABLE 71: ATC2 SERVICES RESPONSE ............................................................................................ 193192
TABLE 72: ATC3 SERVICES RESPONSE ............................................................................................ 193192
TABLE 73: AOC1 SERVICES RESPONSE TIME ................................................................................... 195194
TABLE 74: AOC2 SERVICES RESPONSE TIME ................................................................................... 195194
TABLE 75: SUMMARY OF BS NUMBER AND BACKGROUND TRAFFIC FIGURES PER ITERATION ................. 198197
TABLE 76: QOS CONFIGURATION FOR ITERATION 1 AND ITERATION 2 .................................................. 199198
TABLE 77: RESULTS ON PACKET LATENCY FOR ITERATION 1 AND ITERATION 2. SCENARIO 1 ................. 199198
TABLE 78: CAPACITY LIMITATIONS IN ITERATION 1 SOLVED IN ITERATION 2 .......................................... 200199
TABLE 79: RESULTS FOR HO PERFORMANCE. CONSECUTIVE BS DISTANCE = 2650 M / 1300 M ........... 203202
TABLE 80: BS COORDINATES PROPOSED FOR MADRID BARAJAS PLANNING......................................... 208207
TABLE 81: FREQUENCY RE-USE PLANNING PROPOSAL........................................................................ 208207
FEHLER! ES IST NICHT MÖGLICH, DURCH DIE BEARBEITUNG VON FELDFUNKTIONEN OBJEKTE ZU
ERSTELLEN.TABLE 82: CAPACITY PLANNING FIGURES IN MADRID BARAJAS .................................. 213212
TABLE 83: CALCULATION OF CELL RANGE (DL IN M) FOR EACH MODULATION SCHEME AND MS CATEGORY
(BASED ON R1S1 COVERAGE, NEAR LOS DIRECTION) ................................................................. 216215
TABLE 84: CALCULATION OF CELL RANGE (DL IN M) FOR EACH MODULATION SCHEME AND MS CATEGORY
(BASED ON R1S1 COVERAGE, NLOS DIRECTION) ....................................................................... 218217
TABLE 85: DL COVERAGE AND REVERSE COVERAGE .......................................................................... 220219
TABLE 86: BS2 RANGE FOR DL AND DL LIMITED BY UL ..................................................................... 225224
TABLE 87: AZIMUT AND ELEVATION TX MLS STATION PARAMETERS ................................................... 227226
© EUROCAE, 20XX
xii
TABLE 88: AZIMUT AND ELEVATION RX MLS STATION PARAMETERS ................................................... 229228
TABLE 89: PARAMETERS OF AEROMACS STATIONS .......................................................................... 230229
FEHLER! ES IST NICHT MÖGLICH, DURCH DIE BEARBEITUNG VON FELDFUNKTIONEN OBJEKTE ZU
ERSTELLEN.TABLE 90: TD CALCULATION FOR INTERFERENCE ON MLS RECEIVING STATIONS ....... 232231
FEHLER! ES IST NICHT MÖGLICH, DURCH DIE BEARBEITUNG VON FELDFUNKTIONEN OBJEKTE ZU
ERSTELLEN.TABLE 91: TD CALCULATION FOR INTERFERENCE ON AEROMACS BASE STATIONS.... 232231
© EUROCAE, 20XX
13
CHAPTER 1
1.1
INTRODUCTION
PURPOSE AND SCOPE
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 standards have not yet been developed (like for the IP addressing scheme) it
provides recommendations for further consideration in the according 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.
During the development of the present document it turned out that not all
implementation relevant parts of the system have been defined, like IP addressing
scheme and security frame work. It is expected that after having agreed on these
implementation relevant subjects within ICAO that AeroMACS MASPS have to be
amended accordingly.
Chapter 2 of this document provides the description of the network reference model
including the AeroMACS functional entities and reference points over which
interoperability is achieved between functional entities.
Chapter 3 discusses different implementation architectures. This includes the whole
end-to-end communication chain and deals with the ground and airborne architectural
components as well. In that context a recommendation regarding an IP addressing
scheme within the ICAO community is proposed.
Chapter 4 describes potential ATC and AOC applications for AeroMACS. Further on it
defines scenarios, which have been used to validate performance requirements for
AeroMACS.
Chapter 5 summarizes AeroMACS operation requirements.
Chapter 6 summarizes AeroMACS technical requirements.
Chapter 7 provides the QoS requirements for AeroMACS.
Chapter 8 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 9 deals specifically with aspects of physical coverage and capacity of the
AeroMACS system.
Chapter 10 outlines AeroMACS interoperability requirements.
Chapter 11 deals with AeroMACS interference aspects. It deals with AeroMACS
internal and external interference aspects.
© EUROCAE, 20XX
14
Chapter 12 provides information related to RF cell dimensioning and planning. This
material is an extract of SESAR material, which is used to define simulation scenarios
for investigation and validation of certain AeroMACS functions as support of the
AeroMACS validation effort. Finally this simulation effort is used within Chapter 9 to
clarify the AeroMACS SPR behaviour.
Chapter 13 outlines AeroMACS Security requirements.
Chapter 14 describes a set of system level tests on one side and an end-to-end test
case on the other side. The end-to-end test case is similar to the one described in the
DLS Community Specification [52][52][57], which is defined to prove the
interoperability of implemented constituents from an application level perspective.
Appendix A provides guidelines for ED-227[AS1].
Appendix B outlines the list of acronyms and glossary of terms
Appendix C gives more information about a capacity analysis conducted within SJU
P15.2.7.
Appendix D includes material from SJU P15.2.7 related to AeroMACS deployment
case studies.
Appendix E provides the list of EUROCAE WG-82 members.
1.2
RELATIONSHIPS TO OTHER DOCUMENTS
Most of the text material has been made available by SESAR Projects P15.2.7 and P
9.16. As far as required these material has been updated in order to reflect the status
of work within EUROCAE WG-82 at the time of publication of the present document.
1.3
1.3.1
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[AS2]”
The use of the word MAY Iindicates that alternative procedures, specifications or
criteria are permitteda permission to do something ….
1.3.2
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,
© EUROCAE, 20XX
15
•
Transfer of AAA messages to AeroMACS subscriber’s Home Network Service
Provider (H-NSP) for authentication, authorization and session accounting for
subscriber sessions,
•
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)
•
Radio Resource Management.
•
In addition to the above mandatory functions, for a portable and mobile
environment, an ASN SHALL support the following functions:
•
ASN anchored mobility,
•
Paging,
•
ASN-CSN tunneling.
ASN comprises network elements such as one or more Base Station(s), and one ASN
Gateway (TBC, e.g. in US there could be 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
© EUROCAE, 20XX
16
parameters such as modulation type, forward error correction (FEC) type, preamble
length, guard times, etc.
CPDLC. The ATN application Controller Pilot Data Link Communications.
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 tunneling support,
•
Inter-CSN tunneling 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).
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.
© EUROCAE, 20XX
17
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 802.16-2009 mobile standard.
N (Network). The word "network" and its abbreviation "N" in ISO 8348 are replaced by
the word "sub-network" and its abbreviation "SN", respectively, whenever they appear
in relation to the sub-network layer packet data performance.
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 Entry Time. The time from when the SS first attempts to determine the
channel to “TXon” (e.g. scanning) until the first network user “PDU” can be sent.
Note: It does not include time for self-test or other power up functions.
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.
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..
© EUROCAE, 20XX
18
Transaction expiration time (defined in OSED [11]). AeroMACS SHALL provision
the means to, given a maximum time for completing a transaction, start up an
alternative procedure to accomplish the transaction. This is related to the continuity
parameter.
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). See Network (N).
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.
Uplink. The direction from a subscriber station (SS) to the base station (BS).
REFERENCES[schlereth3]
1.4
[1]
EUROCONTROL COCR v2.0, “Communications Operating Concept and Requirements
for the Future Radio System”
[2]
SESAR P15.2.7 Deliverable T1.1A “System Analysis For AeroMACS Use”
[3]
SESAR P15.2.7 Deliverable T1.1B “AeroMACS System Requirements Document”
[4]
SESAR P15.2.7 Deliverable T1.4 “AeroMACS Functional Architecture Definition v1.0”
[5]
SESAR P15.2.7 Deliverable T3.1-T3.3: D3.2 “AeroMACS Profile Definition v00.01.00”
[6]
SESAR P15.2.7 Deliverable T2.6 “AeroMACS Traffic Modelling”
[7]
SESAR P15.2.7 Deliverable T2.1 “AeroMACS Channel Modelling”
[8]
SESAR P15.2.7 Deliverable D2.3 “Compatibility_FSS_AeroMACS”
[9]
SESAR P15.2.7 Deliverable D3.1 “AeroMACS profile validation v0.2.0”
[10]
SESAR P15.2.7
Analysis"[schlereth4]
Deliverable
D4.0
"AeroMACS
Deployment
&
[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]
Integration
“Procedimiento Interno para Tramitación y Coordinación de Informes por Servidumbres
Aeronaúticas” AENA, 2010
© EUROCAE, 20XX
19
[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]
SJU 15.2.7 D01-T1.5, Spectrum investigations, Ed. 1.0.
[20]
IRIG 106, DOCUMENT 106-11 PART I: TELEMETRY STANDARDS, (APRIL 2011)
[21]
ITU, 2nd Session of the Conference Preparatory Meeting (CPM) for WRC-12, 12-25
February 2011.
[22]
WMF-T32-002-R010v04-Stage2 “Network Architecture: Architecture tenets, Reference
Model and Reference Points”
[23]
WMF-T33-001-R010v05-Stage3_”Network
Procedures”
Architecture:
Detailed
Protocols
[24]
WMF-T33-003-R010v4-Stage3 “R6 R8 ASN Anchored Mobility Scenarios”
[25]
SESAR P15.2.7 WA08 Deliverable D08 AeroMACS Safety and Security Analysis
[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-T25-003-R010v07-IOT, “Mobile interoperability test”
and
[31]
WMF-T32-002-R010v04-Stage2 “Network Architecture: Architecture tenets, Reference
Model and Reference Points”
[32]
WMF-T33-001-R010v05-Stage3_”Network
Procedures”
[33]
[34]
Architecture:
Detailed
Protocols
SANDRA Project, http://www.sandra.aero
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 2009.
[38]
RFC 791 – “Internet Protocol” (September 1981)
[39]
IEEE802.16-2009, “Part 16: Air Interface for Broadband Wireless Access Systems”
[40]
[41]
and
EUROCAE ED-228: Safety and Performance Standard for Baseline 2 ATS Data
Communications (Baseline 2 SPR Standard)
AOC Datalink dimensioning study, Edition 01.00.00, Ed date Nov 16th, 2010.
[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 2013.
[44]
http://openflights.org/data.html
[45]
http://aspmhelp.faa.gov/index.php/OEP_35
[46]
http://en.wikipedia.org/wiki/List_of_the_busiest_airports_in_Europe
[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
© EUROCAE, 20XX
20
[49]
[50]
SANDRA D3.2.1 CONSOLIDATED SANDRA NETWORK AND INTEROPERABILITY
ARCHITECTURE, v2.0, March 2012
SANDRA D6.2.1[schlereth5]
[51]
EUROCAE ED-222: AERONAUTICAL MOBILE AIRPORT COMMUNICATIONS SYSTEM
(AeroMACS) PROFILE, November 2013
[52]
ETSI EN 303 214 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-T32-001-R016v01-Stage 2[schlereth6]
[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-T24-003-R010-v01
[58]
ETSI TS 102 624-2 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
© EUROCAE, 20XX
21
CHAPTER 2
2.1
2.1.1
OVERALL SYSTEM
DESCRIPTION
Network Reference Model
Overview
The Network Reference Model (NRM) is a logical representation of the network
architecture. 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.
Each of these functions MAY be realized in a single physical functional entity or MAY
be distributed over multiple physical functional 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 SHALL 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.
© EUROCAE, 20XX
22
FIGURE 2: NETWORK REFERENCE MODEL
2.1.2
Reference Points
Figure 2Figure 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 SHALL be able to originate and terminate in different functional entities. The
normative reference points between the major functional entities are in the following
subsections.
2.1.2.1
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.
2.1.2.2
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 might support IP Host Configuration
Management running between the MS and the CSN (operated by either the home
NSP or the visited NSP).
2.1.2.3
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., tunneling) to
transfer user data between the ASN and the CSN. Some of the protocols foreseen on
this RP are RADIUS and DHCP.
2.1.2.4
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.
2.1.2.5
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.
2.1.3
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.
2.1.3.1
ASN Decomposition
The ASN reference model is illustrated in Figure 3Figure 3. An ASN shares R1
reference point (RP) with an MS, R3 RP with a CSN and R4 RP with another ASN.
© EUROCAE, 20XX
23
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 n 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 SHALL be fully
compatible with the Inter-ASN equivalent.
FIGURE 3: ASN REFERENCE MODEL
2.1.3.2
BS Definition
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 ASNGW MAY be required as a redundancy option.
2.1.3.3
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 (TBC). ASN-GW implementation SHALL
include load-balancing based on SLA requirements of the MSs. The implementation
details are out of scope for this document.
For every MS, a BS is associated with exactly one default ASN GW.
© EUROCAE, 20XX
24
2.1.4
2.1.4.1
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 intraASN 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
Ethernet packets coming from the ASN to CSN. Another mean to achieve that is the
end-to-end VLAN service.
2.1.4.2
Reference Point R8
Reference Point R8 is not used in real implementation therefore out of scope. 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 3.4.2.
2.1.5
2.1.5.1
AeroMACS Network Architecture Interoperability Scope
Reference Points
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.
2.1.5.2
ASN Functions
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.
2.1.6
CSN Reference Model
CSN internal reference points are out of scope of this specification.
2.1.7
AeroMACS ASN Profile
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. If a vendor chooses to implement any given
profile, then that vendor’s implementation SHALL conform to the chosen profile as
specified in this text. The depiction of a function on either the ASN GW 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.
2.1.7.1
Profile A
ASN functions are mapped into ASN-GW and BS as shown in Figure 4Figure 4. Some
of the key attributes of Profile A are:
© EUROCAE, 20XX
25
•
HO Control is in the ASN GW.
•
RRC is in ASN GW that allows RRM among multiple BSs.
•
ASN Anchored mobility among BSs SHALL be achieved by utilizing R6 and R4
physical connections.
•
FIGURE 4: WMF ASN PROFILE A
For more details refer to [22].
2.1.7.2
Profile B
Profile B ASNs are characterized by unexposed intra-ASN interfaces and hence intraASN interoperability is not specified. However, Profile B ASNs shall be capable of
interoperating with other ASNs of any profile type via R3 and R4 reference points.
Inter-ASN anchored mobility SHALL be possible via R4.
© EUROCAE, 20XX
26
FIGURE 5: WMF ASN PROFILE B
For more details refer to [22].
2.1.7.3
Profile C
According to Profile C, ASN functions are mapped into ASN-GW and BS as shown in
Figure 6Figure 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 SHALL be achieved by
utilizing R6 and R4 physical connections.
© EUROCAE, 20XX
27
•
FIGURE 6: WMF ASN PROFILE C
For more details refer to [22].
2.1.8
AeroMACS ASN Profile Choice
AeroMACS ASN Profile SHALL support profile C.
© EUROCAE, 20XX
28
CHAPTER 3
AEROMACS NETWORK
ARCHITECTURE
This chapter describes the functional component organization and operation principles
of AeroMACS networks. The chapter is organized as follows: first, functional
requirements affecting network design and service provision are listed. Second, 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.
3.1
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.
3.1.1
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 HOs.
AeroMACS convergence sublayer SHALL support IPv4 CS and IPv6 CS and 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.
In order to support authentication AeroMACS SHALL support the Public Key
Infrastructure utilizing X.509 certificates.
In order to give support to subscriber authentication, proper means SHALL be
foreseen. Thus, MS and AAA server SHALL support EAP-TLS framework.
3.1.2
Core Service Network (CSN) requirements
AeroMACS SHALL be based on an all IP radio and ground Internet Protocol (IP)
compliant infrastructure as defined in ICAO DOC 9896.
AeroMACS infrastructure SHALL support different network addressing schemes in
order to give support to network addressing for vehicles and home and visiting aircraft
without distinction.
Mobile IP SHALL be implemented in compliance with ICAO standard for
communication with Aircraft.
AeroMACS SHALL support IPv6.
AeroMACS SHALL support IPv4 address in order to be interoperable with legacy
systems and for vehicles on the airport domain.
A MS SHALL get a dynamic IP address.
The vehicles which have been allocated the same address SHALL not operate on the
same aerodrome.
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.
© EUROCAE, 20XX
29
ASN-GW SHALL support GRE tunnelling on R6 interface.
ASN routers SHALL support dual network layer stack, tunneling or protocol
conversion, as specified in ICAO Doc 9896, for connecting IPv6 core networks to
AeroMACS ASN network which may go over IPv4 stack.
MSs SHALL support UDP/TCP transport connections.
3.1.3
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. For instance, airlines that do not
subscribe any AOC/AAC contract over AeroMACS SHOULD be accepted on NAP and
NSP networks for ATC only service provision, and proper authentication procedures
SHOULD 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. This information 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.
3.2
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 10.110.1.
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).
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
© EUROCAE, 20XX
30
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. For interoperability purposes, special care should be paid to the reference
points R1 and R6 of the ASN reference model. Regarding the AeroMACS business
model, it is expected to have just one single ASN-GW deployed in the airport domain.
Intra ASN mobility will imply full support of R6 control messages.
3.2.1
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.
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
may 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
•
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 the
Table 1 below. It is assumed that aircraft mobility will be managed by a central Mobility
Service Provider (ACSP or CSP) (ARINC, SITA, others) (=aircraft H-NSP).
© EUROCAE, 20XX
31
Table 1: Possible actors for NAP/V-NSP/H-NSP functions
3.2.2
Airport telco
operator
ANSP
ACSP
NAP
x
x
x
V-NSP
x
x
x
H-NSP
x (for vehicles)
x
CSP
Airline
x
x
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 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 may operate one or more Home
Agents (HA) [12]. Regarding IP connectivity, it is possible that IP addresses will be
assigned directly by an HNSP 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.
© EUROCAE, 20XX
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 802.16-2009
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 (AR)
The airborne router contains the on-board routing function. The AR 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
© EUROCAE, 20XX
33
and access networks including AeroMACS. Refer to section 3.5 for the different
airborne configuration options. The AR may 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.
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 an 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:
© EUROCAE, 20XX
34
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
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 commonly functions that can be found on a COTS ASN-GW
have no applicability for AeroMACS. These are listed below:
•
Radio Resource Management (RRM) is left optional and therefore opened to
specific implementations in the future.
•
No paging needed as stated in the profile [51]
•
No load balancing policy.
•
No 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. 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. In
contrast they SHALL be queued in case of congestion and accordingly to the different
priorities (RFC 4594 gives a recommendation on service categorization). This entity
will then read the IP header, maps it to an AeroMACS MAC QoS class and through
means of GRE tunneling, convey that packet to the specific BS to which the MS is
attached.
AAA proxy/server
One of the main roles of AAA server is gathering the information of all AeroMACS
users. The CSN of the home NSP SHALL distribute the subscriber’s profile to the NAP
directly or via the visited NSP. 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)
© EUROCAE, 20XX
35
DHCP server
In the same line, we would find the DHCP server 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, and may
either be a point-of-attachment IP address or an inner-tunnel IP address, according to
WiMAX Forum specification [22].
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 SHALL implement Mobile IPv6 as
specified in ICAO Doc 9896 [12]. A Home Agent (HA) SHALL be required at the home
network. A secure communication path (e.g. private network tunnel) between ASNGW to the NSP HA SHALL be required. In the visited network, Foreign Agent (FA) or
Access Router (AR[schlereth7]) 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. 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 ones, would be affected by this. See
“Deployment Models” section 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.
© EUROCAE, 20XX
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,
ASN-GW SHOULD support and implement a client RADIUS. 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
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 data base, 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
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.
© EUROCAE, 20XX
37
AAA servers will depend on the core network managed by the service provider. Data
bases 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.
3.2.3
Addressing concept
According to ICAO Doc 9896, mobile and fixed nodes SHOULD 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.
A standard prefix convention is proposed by SANDRA study [33]: the convention is
ICAO and airline dependent and is Provider Independent. The global routing prefix is
designed to be structured hierarchically by the aeronautical organization in Provider
Independent address block case. The subnet field is designed to be structured
hierarchically by site administrators.
There are several proposals of an IPv6 address format for ATN/IPS nodes (refer to
[47] for more details). The currently recommended format (as approved by ICAO ACP
WG-I #7) is based on the work performed by NEWSKY, and only applies to airborne
sites. Mobility Service Providers (ACSPs, ANSPs, airlines, airport authorities,
organizations, etc.) are allocated a /32 to be used for airborne site allocation. Beyond
this 32 bit boundary, ICAO recommends the IPv6 address format for airborne sites
shown in Figure 11.
Figure 11: ICAO WG-I #7 recommended format
SANDRA draft proposal [47] is the most advanced solution as of today and builds over
the ICAO recommended format and NEWSKY proposals. SANDRA address structure
applies to both ground and airborne sites and assumes a smaller Global ICAO prefix
of /22 which looks as indicated in Figure 12. It covers safety related applications (ATS,
AOC) and non-safety applications (AAC, APC).This overall address block is split into
two subspaces (50-50 split) for each safety and non-safety related services. These
sub-spaces are then split, based on a 50-50 ratio, into ground and airborne address
subspaces.
© EUROCAE, 20XX
38
Figure 12: Illustration of SANDRA addressing concept[schlereth8].
In the airborne address structure, operator field allows for discrimination by
organization/airline: providers will advertise airlines and not aircraft. This provides
aggregation and therefore reduces the size of the routing tables. It is possible to have
multiple service providers for the same aircraft or airline. On the ground network
structure, a sufficiently large number of supported organizations is possible.
Aggregation is even on the level of ICAO regions and large service providers.
For safety issues, it is highly recommended to ensure segregation between vehicle
and aircraft subscribers through the use of different IP ranges in the airport network.
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.
3.2.4
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
© EUROCAE, 20XX
39
•
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). Previously it 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. NAP discovery is based on the
procedures defined in IEEE 802.16 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 802.16 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’. 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.
© EUROCAE, 20XX
40
Table 2: NSP ID format [32]
In the authentication process described in section 4.1.2.4 of [32], the MS shall format
the NAI (Network Access Identifier) used as an outer identity during EAP exchanges
as follows:<routing realms><WiMAX decoration><username>@<realm> where:
•
Routing realms: Optionally used. The use of routing realm is described by RFC
4282. Example: [email protected]
•
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 4282. The
name must be alphanumeric with no spaces. Example:
{fm=1|xm=3}[email protected]. Currently there is no specific avp defined.
•
Additional requirements
•
When an aircraft (MS) lands and scans the AeroMACS band, it has to select a
NAP, and then most likely the adequate NSP. The way/order in which the
channels are scanned are implementation-dependent, as well as the way the
preferred NAP is selected. The NAP (operator) selection will possibly 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)
The criteria for NAP selection SHOULD be:
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)
© EUROCAE, 20XX
41
The previous criteria can be respected either by
a) analysing the Operator ID (that should be encoded in a specific way), or
b) pre-determine channel values/operator IDs in a local aircraft configuration file, or
c) analyse 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 should use the H-NSP realm as <routing realm> in
authentication process and the ASN shall use this parameter to route to the proper
NSP
It needs to be noted that the recommendations articulated in this sub-section 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.
3.3
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 shall be
integrated within airport network depends on the deployment solution.
3.3.1
Barajas airport network topology
A general overview of Barajas airport is shown in Figure 13, 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.
© EUROCAE, 20XX
42
Figure 13: 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 50000 access ports and network
access equipment is deployed all over the airport (see Figure 14). It is composed of
three main nets 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 DSP (e.g. SITA, ARINC ...).
© EUROCAE, 20XX
43
Figure 14: 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
DSP (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 15 depicts it.
© EUROCAE, 20XX
44
Figure 15: 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 16 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.
© EUROCAE, 20XX
45
Figure 16: Barajas MLAT system cabling infrastructure
3.4
3.4.1
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 should be preferred 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.
© EUROCAE, 20XX
46
Figure 17: 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.
playing the role of a H-NSP who 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 3.2), enabling the MS to establish data
communication to its NSPs through AeroMACS ASN and relaying them to reach final
airline operator.
Single NSP Providing Access through Multiple NAPs
This deployment model should be 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).
Figure 18: 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 should be a distinction 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, a connectivity to the global network would be necessary.
Greenfield NAP+NSP
This deployment model should be foreseen by manufacturers and operator since they
let flexibility to NSP to act or not as NAP depending on local issues.
This model is not suitable to ANSPs but rather to ACSPs in areas where they will be
allowed to act as NAP. A single NSP, corresponding to the same ACSP, operates the
network.
© EUROCAE, 20XX
47
Figure 19: 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 should be served by the
same H-NSP.
Deployment scenarios proposed
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: AeroMACS deployment scenarios proposed
Use
Case
N°
Descripti
on
NAP
V-NSP
H-NSP
Deployment model
Use
case 1
No Fixed
services
Airport telco
Airport
telco
For aircraft:
-NAP sharing
multiple NSPs.
Mobile
and
Aircraft
services
on same
channels
Use
case 2
No Fixed
services
(only
NAP..)
one
(for
vehicle
:
HNSP=
VNSP)
ACSP
CSP
The airline itself
Airport telco
for mobile
N/A
Airport telco for
mobile
ANSP
for
aircraft (one
ANSP
for
For aircraft:
Segregation between
types of service
by
-One NSP providing
access
through
multiple NAPs
Segregation between
vehicle/aircraft
by
using
different
channels
Mobile
services
on
a
specific
set
of
channels
Aircraft
services
© EUROCAE, 20XX
Segregation between
vehicle/aircraft
by
using
different
Service flows
-NAP sharing
multiple NSPs
by
48
on
a
specific
set
of
channels
NAP only for
aircraft)
Aircraft
services
on
a
specific
set
of
channels
SITA
Use
case 4
No Fixed
services
Airline
(at
airline
Hub)
Mobile
and
Aircraft
services
on same
channels
Use
case 3
3.4.2
aircraft
ACSP
-Several NAPs
CSP
The airline itself
DSP
For aircraft:
ARINC
ACSP
MSP
CSP
-Greenfield
NAP+NSP
-Several NAPs
Segregation between
vehicle/aircraft
by
using
different
channels
The airline itself
Airport telco
Airline
Subcontracted to
CSP or Airline
-Greenfield
NAP+NSP
-One NAPs
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 20 shows the entities participating in roaming. This
architecture SHALL not preclude roaming between NSPs. The architecture SHOULD
allow a single NAP to 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. 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.
© EUROCAE, 20XX
49
Figure 20: 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 placement of the HA for data access purposes, the following cases
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 to 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 X, has been assessed both by NEWSKY and SANDRA
projects.
•
Data access via correspondent router: This deployment model should be
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 may 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 Y).
© EUROCAE, 20XX
50
Figure 21: Roaming scenario 1 [49]
Figure 22:Roaming scenario 2 [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 21), 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.
© EUROCAE, 20XX
51
Note: SANDRA project concluded that use of CR versus global HAHA was more
appropriate to ATM communications.[49]
3.5
AEROMACS AIRBORNE ARCHITECTURE
A standard airborne AeroMACS system architecture will be developed by AEEC. It is
not yet available at the publication time of the present document. In order to give an
idea on how airborne AeroMACS system architecture might look like available material
from SESAR P9.16 has been used to develop the proposals shown below, which
should be considered as potential ways of implementing AeroMACS allowing for
having early benefits from an AeroMACS implementation on one side and outlining the
target architecture, which has to be considered on a long term basis as a second step,
on the other side.
The following explanations are based on material described in SESAR Project 9.16
document entitled AeroMACS Airborne System Requirements and Architecture
Dossier (SRAD) [42].
3.5.1
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 and ARINC664P5[schlereth9], 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 Email.
•
The Passenger Owned Devices Domain is a network of those devices that
passengers may 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,
•
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.
© EUROCAE, 20XX
52
3.5.2
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 onward.
Due to its earlier deployment, AeroMACS might be the first ATN/IPS-compatible
“Future Communication System” candidate for 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 may 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.
3.5.3
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.
© EUROCAE, 20XX
53
Aircraft Control Domain
(ACD)
FANS A/B (or
C)
ATC
Applications
AOC
Applications in
ACD
Airline Information
Services Domain
(AISD)
AOC
Applications in
AISD
ACARS
+ ATN
Router
VHF
system
HF
system
(PIESD)
(PODD)
OpenIP
Router
SATCOM
system
Aeromacs
system
Gatelink system
(Wifi / Cellular)
Figure 23: 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 1B 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.
© EUROCAE, 20XX
54
Aircraft Control Domain
(ACD)
FANS A/B (or
C)
ATC
Applications
Airline Information
Services Domain
(AISD)
AOC
Applications in
ACD
AOC
Applications in
AISD
ACARS
+ ATN
Router
VHF
system
HF
system
(PODD)
OpenIP
Router
SATCOM
system
(PIESD)
Aeromacs
system
Gatelink system
(Wifi / Cellular)
Figure 24: AeroMACS system integration on A/C – Scenario 1-B
3.5.4
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.
© EUROCAE, 20XX
55
ACARS
+ ATN
Router
OpenIP
Router
Figure 25: AeroMACS system integration on A/C – Scenario 2-A
3.5.5
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 Immarsat-SBB).
ACARS
+ ATN
Router
OpenIP
Router
© EUROCAE, 20XX
56
Figure 26: 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 26 would be guaranteed by an appropriate SubNetwork Dependent
Convergence Function Layer. A similar solution has been already tested and validated
under the SANDRA Project, allowing interoperability between AeroMACS MSs and
COTS ATN/OSI Routers. See Figure 27.
A security capability, on top AeroMACS security framework, should be implemented at
IP level. The AeroMACS “Box” security capabilities should encompass:
•
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
AISD
OpenIP
Router
ACARS
+ ATN
Router
ATN/OSI
Traffic
IP Traffic
IP -SNDCF
ACD
User
AISD
User
AeroMACS Terminal
SFs
SFs
Figure 27: Scenario 2-B: connection between AeroMACS and ACD/AISD
3.5.6
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.
© EUROCAE, 20XX
57
Aircraft Control Domain
(ACD)
FANS A/B
(or C)
ATC
Applications
Airline Information
Services Domain
(AISD)
AOC
AOC
Applications
Applications
in ACD
in AISD
ACARS
ACARS
ATN
++ATN
Router
Routeur
AeroIP
AeroIP
Routeur
Router
VHF
HF
SATCOM
Aeromacs
system
system
system
system
OpenIP
OpenIP
Router
Routeur
future
SATCOM
System (Ka)
(PIESD)
(PODD)
Extended
WACS
(Wifi/GSM/
4G+)
Figure 28: AeroMACS system integration on A/C – Scenario 3-A
3.5.7
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 29 and Figure 30.
Aircraft Control Domain
(ACD)
FANS A/B
(or C)
ATC
Applications
AOC
AOC
Applications
Applications
in ACD
in AISD
ACARS
ACARS
ATN
++ATN
Router
Routeur
VHF
system
HF
system
Airline Information
Services Domain
(AISD)
AeroIP
AeroIP
Routeur
Router
SATCOM
Aeromacs
system
system
OpenIP
OpenIP
Router
Routeur
future
SATCOM
System (Ka)
© EUROCAE, 20XX
Extended
WACS
(Wifi/GSM/
4G+)
(PIESD)
(PODD)
58
Figure 29: AeroMACS system integration on A/C – Scenario 3-B
OpenIP
Router
AeroIP
Router
Figure 30: Scenario 3-B: connection between AeroMACS and ACD/AISD
The above scenarios define different strategies for implementing an AeroMACS
System on aircraft, which may 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 should not 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 31.
© EUROCAE, 20XX
59
AeroIP
Router
OpenIP
Router
Figure 31: Physical Segregation between ACD and AISD
© EUROCAE, 20XX
60
CHAPTER 4
APPLICATIONS
This section covers the list of services to be supported by AeroMACS. Service
instantiation deemed and description for an operational landing, turnaround and take
off procedure is provided. The description is the basis for simulation results outlined in
12.1.2. 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.
4.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] are 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 32: 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.
© EUROCAE, 20XX
61
LDT’: Landing Time for AeroMACS. It stands for the instant at which the aircraft
moves below the maximum speed supported by AeroMACS (50 knots)
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 in 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.
According to WG78 naming [refSPR], the services can be categorized in a different
manner. These are explained below:
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.
© EUROCAE, 20XX
62
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
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 may 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
2020-2025 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 heavy load 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.
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
RAMP
1
Service
Category
Application
Application
FRS data services
WG78 ATS services
[1], [28]
[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
AOCDLL
Airport Operational Center
Data Link Logon
AOC
L-AOC
LOADSHT
Load Sheet
Request/Transfer
AOC
L-AOC
This service is named Data Link Initiation (DLIC) in WG78 documentation [11]
© EUROCAE, 20XX
-
1
G ↔ A/C
G ↔ A/C
G ↔ A/C
63
Operational
domain
execution
Service
Category
Application
Application
FRS data services
WG78 ATS services
[1], [28]
[11]
Directionality
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
SWLOAD25
Software Loading (Part 25)
AOC
EFB (S)
-
G → A/C
SWLOAD
Software Loading
AOC
L-AOC (S)
-
G → A/C
BRFCD
Aircraft Briefing Cards
AOC
EFB
-
G → A/C
ACLOG
Aircraft Technical Log
Rectification
AOC
EFB
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
Passenger Information
List/Manifest
AOC
EFB
CREW-RPS
Crew
rotation/planning/scheduling
AOC
EFB
CREW-BUL
Crew Briefings/Bulletins
AOC
EFB
CREW-REG
Flight Crew Recency
Registration
AOC
EFB
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
EFF
Electronic Flight Folder
Exchange
AOC
EFB
WXGRAPH
Graphical Weather
Information
AOC
L-AOC
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
© EUROCAE, 20XX
-
-
-
CPDLC
-
G ↔ A/C
G ↔ A/C
G → A/C
G → A/C
G → A/C
G ← A/C
G ↔ A/C
G ↔ A/C
G ↔ A/C
64
Operational
domain
execution
GROUND
Service
Category
Application
Application
FRS data services
WG78 ATS services
[1], [28]
[11]
-
Directionality
NOTOC
Notice to Captain
AOC
EFB
LOADDOC
Load documentation
Acceptance
AOC
EFB
PREFLT-INS
Pre-Flight Inspection Signoff
AOC
EFB
D-OTIS
Data Link Operational
Terminal Information Service
ATC
FIS
D-SIGMET
Data Link Significant
Meteorological Information
ATC
FIS
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
FLIPCY
Flight Plan Consistency
ATC
FPS
-
G ↔ A/C
FLIPINT
Flight Path Intent
ATC
FPS
-
G ↔ A/C
D-RVR
Data Link Runway Visual
Range
ATC
FIS
D-SIG
Data Link Surface
Information and Guidance
ATC
FIS
EFFU
Electronic Flight Folder
Update
AOC
EFB
TAKEOFFCALC
Takeoff Performance
Calculation
AOC
EFB
D-FLUP
Data Link Flight Update
ATC
AVS
-
G ↔ A/C
PPD
Pilot preferences downlink
ATC
FPS
-
G ↔ A/C
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
ACL
ATC clearance
ATC
CIS
ACM
ATC Communication
Management
ATC
DCM
2
G → A/C
-
G ← A/C
-
G ← A/C
D-FIS
D-FIS
G ↔ A/C
2
G ↔ A/C
-
G ↔ A/C
D-FIS
G ↔ A/C
-
G ↔ A/C
-
G ↔ A/C
-
G ↔ A/C
ADS-C
3
CPDLC
4
G → A/C
CPDLC
This service is included inside Hazardous Weather service (D-HZWX) in WG78 documentation [11]
Equivalent to Position Report (PR) in WG78 documentation [11]
4
This service is named Clearence Request and Delivery (CRD) in WG78 documentation [11]
3
© EUROCAE, 20XX
G ↔ A/C
G ↔ A/C
65
Operational
domain
execution
TOWER
Service
Category
Application
Application
FRS data services
WG78 ATS services
[1], [28]
[11]
WXRT
Real Time Weather Reports
for Met Office
AOC
L-AOC
OOOI
Out-Off-On-In
AOC
L-AOC
ACM
ATC Communication
Management
ATC
DCM
-
Directionality
G ← A/C
-
G ← A/C
CPDLC
G ↔ A/C
Table 5: Services executed during arrival phase
Application
Operational
domain
execution
TOWER
GROUND
RAMP
5
Service
Category
FRS data
services
Application
WG78 ATS
Directionality
services
[1], [28]
[11]
L-AOC
-
G ← A/C
NET
NET
-
G ↔ A/C
OOOI
Out-Off-On-In
NETKEEP
Network keep-alive
AUTOLANDREG
Autoland Registration
AOC
EFB
ACM
ATC Communication Management
ATC
DCM
CPDLC
SURV
Air Traffic Control Surveillance
ATC
FPS
ADS-C
ACL
ATC clearance
ATC
CIS
CPDLC
D-SIG
Data Link Surface Information and
Guidance
ATC
FIS
D-TAXI
Data Link Taxi Clearance
ATC
CIS
CPDLC
G ↔ A/C
EFFU
Electronic Flight Folder Update
AOC
EFB
-
G ↔ A/C
FLTJOURNAL
Flight Journal Documentation
AOC
EFB
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
FLTLOG
Flight Log Transfer
AOC
L-AOC
-
G ← A/C
CABINLOG
Cabin Log
AOC
L-AOC
-
G ← A/C
ETS-REPORT
Post flight report required for ETS
AOC
EFB
-
G ← A/C
Equivalent to Position Report (PR) in WG78 documentation [11]
© EUROCAE, 20XX
AOC
-
G ← A/C
5
-
-
-
G ↔ A/C
G → A/C
G ↔ A/C
G ↔ A/C
G ← A/C
G ← A/C
66
Application
Operational
domain
execution
Service
Category
FRS data
services
[1], [28]
Application
WG78 ATS
Directionality
services
[11]
(Emissions Trading Scheme)
4.2
REFUEL
Fuel ordering (Tickets) / Fuel
Release
AOC
EFB
ACM
ATC Communication Management
ATC
DCM
CPDLC
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 may 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.
Figure 33: Sequential execution of services in arrival
© EUROCAE, 20XX
G ← A/C
G ↔ A/C
67
Figure 34: Sequential execution of services in departure
4.3
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 sending 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 below.
© EUROCAE, 20XX
68
The classification required for AeroMACS is outlined in the Table 7. This service
categorization has been extracted from COCRv2 [1] and SJU AOC service studies
[28].
Table 6: 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 classificationn outlined in Table 8, 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 15.2.7
WA2 defined CoS [6] is shown in Table 7.
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 8. 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.
© EUROCAE, 20XX
69
Table 7: CoS classification for Airport Capacity Analysis
CoS
Services included
NET
•
ATS1
•
ATS2
AOC1
AOC2
NET services
DG-A
NETKEEP, NETCONN
FPS by ADS-C
DB-D
SURV
CIS (CPDLC)
DG-C
•
ACL, COTRAC, DCL, D-TAXI
FPS
•
FLIPCY, FLIPINT, PPD
DCM
ATS3
•
DLL, ACM
FIS
•
D-OTIS, D-SIGMET, D-RVR, D-SIG
AVS
•
•
D-FLUP
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
SWLOAD, UPLIB, EFF, EFFU, E-CHARTS,
FLTJOURNAL, FOQA, SWLOAD25, SWCONF
•
SESAR P15.2.7 CoS
[6]
DG-D
DG-C
DG-D
DG-F
DG-J
DG-K
DG-K
DG-L
6
This model for CoS 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.
6
It should be mentioned that 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.
© EUROCAE, 20XX
70
CHAPTER 5
AEROMACS
OPERATIONAL REQUIREMENTS
This section aims to gather worthwhile information that helps to understand the
rationale for system characteristics, operational goals, requirements and workout 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 shall be an enabler to enhance the
productivity and safety of ATS by optimizing the involvement of controllers, aircrew
and airline operators through integrated data communications, improved forms of
surveillance and automation.
In Europe AeroMACS SHALL support only mobile services.
AeroMACS SHALL support data services (NET, ATC and AOC).
AeroMACS SHOULD support voice services.
5.1
Operating Altitude
AeroMACS SHALL be available, exclusively, on the airport surface. Only the A/Cs on
the ground will trigger services through AeroMACS.
5.2
Coverage
The foreseen operational area for AeroMACS goes from terminals (RAMP area) to
taxiing zones (GROUND and TOWER). AeroMACS operating coverage SHALL
extend to full airport area. It’s important to point out that coverage area is much related
to specific deployment cases. In order to fully accomplish this statement, 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. Mainly those zones are RAMP area
(operational turnaround zones) and taxiways.
5.3
ATS and AOC 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 SHOULD support VoIP services for airport operation.
Note: Currently, it is not intended to support VoIP for ATC applications in Europe.
5.4
Registration procedure
Aircraft device SHALL automatically register and de-register from AeroMACS system
without intervention of human agents.
5.5
Mobility and Handover
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.
© EUROCAE, 20XX
71
Service flows connections SHALL be kept and guarantee their continuity without
service disruption from the user’s point of view.
5.6
Performance monitoring
System monitoring SHALL be performed by organizations which operate the
AeroMACS system or components.
The monitoring capability of the AeroMACS SHALL NOT impede the working 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.
5.7
System supervision
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.
© EUROCAE, 20XX
72
CHAPTER 6
AEROMACS TECHNICAL
REQUIREMENTS
This section aims to gather technical requirements, which are related to the
operational requirements outlined in section 5.
6.1
Min Max aircraft, vehicle speed
AeroMACS data link SHALL be able to support every single data transaction related to
ATM services while the A/C speed is lower or equal 50 knots.
6.2
ATS and AOC support
AeroMACS SHALL support the necessary Network Management services (NET) as
required by the supported safety of life and flight regularity services.
6.3
Registration procedure
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 1: 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).
Note 2: The AeroMACS equipment is required to be able to tune in to authorised
frequencies with a resolution of 250 KHz. While in normal operations the nominal
centre frequencies SHOULD 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 3: In order to reduce the Net Entry Time, a possible solution is to pre-provision
the MS with frequency it SHALL use at the start-up (i.e. at the destination airport).
6.4
Mobility and Handover
AeroMACS SHALL be capable to operate within the FCI 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. Therefore the whole set of keys is transferred to the BS (TEK) through
PKM protocol. Besides it 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.
6.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 handover interruption time SHALL be kept sufficiently low to guarantee no
service disruption within the whole operational turnaround of the aircraft in the airport
surface.
All the BSs SHALL get synchronized using a unique time reference getting an error of
the clocks of better than ±2ppm.
The maximum resynchronization time for the MS after signal loss SHALL be less than
10 s.
© EUROCAE, 20XX
73
6.6
Data Latency
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.
6.7
Residual ERROR RATE
The residual error rate, to/from subscriber station SHOULD be less than or equal to 5
x 10E-8 per SNSDU.
6.8
System supervision
AeroMACS SHALL support VPN or VLAN in case it`s required for system supervision
purposes.
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 SHOULD implement SNMP agents in order to enable its
management whereas MSs SHALL NOT include any agent.
AeroMACS problem resolution SHOULD be easily traced back to the point at which
the problem was encountered from the SNMP protocol.
© EUROCAE, 20XX
74
CHAPTER 7
QUALITY OF SERVICE
REQUIREMENTS
In a real deployment, a specific mapping of QoS levels SHALL be provided.
NOTE: In section 4.3 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 SHALL provide means to guarantee data integrity.
AeroMACS BSs SHALL be capable to establish different dynamic service flows (SF)
to the MSs (with different parameters of throughput, jitter, delay, etc.)
AeroMACS BS SHALL guarantee the dynamic change of a SF attending to different
traffic patterns and requisites.
AeroMACS SHALL implement different traffic schedule 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)
7.1
AeroMACS Service Flows
IEEE 802.16-2009 supports 5 QoS classes (in IEEE terminology they are called
Service Flows), which are outlined in the following sub sections.
7.1.1
Extended Real-Time Polling Service
Extended real time Polling Service (ertPS) is defined as a real-time service flows that
generates variable-sized data packets on a periodic basis.
An example of an ertPS based commercial communications application would be
VOIP with silence suppression.
AeroMACS shall support ertPS
7.1.2
Real-Time Polling Service
Real time Polling Service (rtPS ) is defined as real-time data streams comprising
variable-sized data packets that are issued at periodic intervals.
An example of a rtPS based commercial communications application would be MPEG
Video.
AeroMACS shall support rtPS
7.1.3
Non-real Time Polling Service
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.
An example of a nrtPS based commercial communications application would be FTP
with guaranteed minimum throughput.
AeroMACS shall support nrtPS
7.1.4
Best Effort Service
Best Effort Service (BE) is defined as data streams for which no minimum service
level is required and therefore may be handled on a space-available basis.
An example of a BE based commercial communications application would be HTTP.
AeroMACS shall support BE.
© EUROCAE, 20XX
75
7.1.5
Unsolicited Grant Service
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.
An example of a UGS based commercial communications application would be E1/T1
transport, or circuit switched voice or VOIP without silence suppression.
NOTE : It is expected that in the future there will be no need any longer for circuit
switched communications.
AeroMACS shall support UGS.
7.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 8.
Table 8: AeroMACS classes of service example [3]
Classes of
Service
CoS 1
(highest)
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
Subscribers
Aircraft
NET
services
Surface
vehicles
NET
services
Additional implementation guidelines are outlined in Appendix XX (section 5 of TN#14
of Carlos[schlereth10]).
© EUROCAE, 20XX
76
CHAPTER 8
SAFETY AND
PERFORMANCE REQUIREMENTS
8.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 are 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
Flight crew
Airborne
End-System
HMI
Airborne
router
Airborne
radio
ASN
Visited CSN
ATSU
Procedures
(ATSU)
End-System
Access
router
Home CSN
ACSP
Controller
HMI
FIGURE 35: 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 subnetworks would be available (e.g VDL
Mode 2), ED-228 requirements would have to be apportioned to AeroMACS
infrastructure.
8.1.1
Performance requirements
ED-228 expresses Performance requirements based on the following parameters:
© EUROCAE, 20XX
77
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)
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.
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.
Continuity and Probability 95%
The Continuity is linked with the Maximum Transaction Time, while the Probability95%
is associated with the Nominal Time.
Integrity
Integrity is the probability that a transaction completes with no undetected errors.
The following apportionment of requirements to the ACSP domain is defined in ED228:
Table 9: ACSP Transaction Time Requirements [40]
Maximum
ACSP
contribution
Communication
Surveillance
ET (sec)
C = 99.9%
TT (sec)
C = 95%
OT (sec)
C = 99.9%
DT (sec)
C = 95%
18
(two way
transaction)
10
(two way
transaction)
12
(one way
transaction)
5
(one way
transaction)
Note: these performance requirements are based on most constraining performance
labels specified in ED-228 (RCP130 and RSP160).
© EUROCAE, 20XX
78
Table 10: ACSP Availability Requirements [40]
ACSP requirements
Availability
0.9995
Maximum Unplanned service outage duration (min)
6
Maximum number of service unplanned
outages
40
Maximum accumulated service unplanned
outage time(min/yr)
240
Unplanned service outage notification delay
(min)
5
Note: these performance requirements are based on most constraining performance
labels specified in ED-228 (RCP130 and RSP160).
Integrity:
ED-228 does not specify any requirement related to Integrity and applicable to the
ACSP domain.
8.1.2
Safety requirements applicable to the ACSP domain
Safety requirements applicable to AeroMACS are quite dependent upon overall
communication architecture. However, compliance to here above performance
requirements applicable to the ACSP domain should 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. Nevertheless, manufacturers may consider to implement AeroMACS critical
function in compliance with SWAL 4 objectives according to ED-153 [59].
8.2
Guidances related to ATC and AOC throughput and packet size
Required Throughput
ATC: The overall (combined up and downlink) average data load supported by one
cell/sector SHOULD be at least 0,6kbps (GROUND/TOWER) or 0,2kbps (RAMP).
AOC: The overall (combined up and downlink) average data load supported by one
cell/sector SHOULD be at least 800kbps (GROUND/TOWER) or 1Mbps (RAMP).
These figures have been yielded from large airport case analysis (typically 50 A/C).
Thus figures for smaller airports would be likely lower.
Packet size (see capacity analysis in Appendix C):
•
AeroMACS average ATC message size is 190 Bytes.
•
AeroMACS average AOC message size is 278 kBytes.
© EUROCAE, 20XX
79
Table 11: ATC and AOC required throughput and packet sizes
ATC Required Throughput
Overall (combined up and downlink)
minimum average data load within one
cell/sector of GROUND/TOWER OPS
domain
0,6 kps
Overall (combined up and downlink)
minimum average data load within one
cell/sector of RAMP OPS domain
0,2 kps
AOC Required Throughput
Overall (combined up and downlink)
minimum average data load within one
cell/sector of GROUND/TOWER OPS
domain
800 kps
Overall (combined up and downlink)
minimum average data load within one
cell/sector of RAMP OPS domain
1000 kps
Packet size
Average ATC message size
190 Bytes
Average AOC message size
278 Bytes
© EUROCAE, 20XX
80
CHAPTER 9
9.1
COVERAGE AND
CAPACITY
Inputs to Coverage and Capacity Requirements
AeroMACS Coverage and Capacity requirements depend on many different
parameters as listed below. These parameters will be addressed in succeeding
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.
9.1.1
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.
9.1.2
Airport Areas Definitions
Under SJU P15.2.7 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 C.
AeroMACS coverage requirements at an airport are also determined by the size of
previously defined areas for this airport.
9.1.3
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 attracting.
An airport attracting many light aircraft will have a larger capacity compared to an
identical airport attracting 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.
© EUROCAE, 20XX
81
During take off phase the following rules are applicable:
•
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 shall be respected as indicated
in the table below.
Table 12: A/C separation minima
Preceding
aircraft
Minimum
radar
separation
Following
aircraft
Super
4 NM
Heavy
6 NM
Medium
7 NM
Light
8 NM
Heavy
4 NM
Medium
5 NM
Light
5 NM
Light
4 NM
Super
Heavy
Medium
9.1.4
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 13: Airframe heights with respect to ground
7
AIRCRAFT
AeroMACS
FRAME TYPE
Antenna height
7
(m)
A 318
5,9
A 320
5,91
A 340-500
7,55
A 330-200
8,22
Heights may fluctuate around 0,3 m depending on A/C load conditions.
© EUROCAE, 20XX
82
9.1.5
A 380
10,74
A 350-900
8,09
B 737300/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 747
10,06
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 in “average”
the number of A/Cs spread all over the airport in a given time “t” for the simulations.
Such an average value however includes landing as well as departing A/Cs.
Nevertheless, 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 14: A/C Dwell times vs A/C airport operation areas
Airport
area
density
and
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
6m
8m
4,5 m
LD Phase 2 Departure
15 m
6m
2,5 m
© EUROCAE, 20XX
83
LD Phase 2 Arrival
3m
4m
2,5 m
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 SESAR
P15.2.7 WA 2 tasks [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 may not all fit exactly all possible existing European airport
size. Hence there may 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 15: AeroMACS expected throughputs vs modulation schemes
MC scheme
Downlink [kbps]
QPSK1/2
Uplink [Kbps]
983.3
532.4
16QAM1/2
2153.52
1235.52
64QAM1/2
3595.04
1758.48
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.
Hence it is clear that the actual data rate AeroMACS is able to support between BS
and MS is difficult to establish. Therefore we assume 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 15 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.
© EUROCAE, 20XX
84
Table 16: Single Sector scenario – excluding FOQA
Average
offered load
ATC
(Kbits/sec)
Average offered
load AOC
(Kbits/sec)
Overall
0,84
1867,43 (~1,8
MBitps)
FL
0,34
1619,49
RL
0,50
248,22
Scenario
20 A/C, 4 VC
RAMP departure
ATC, NET, AOC, EFF,
UPLIB, E-CHARTS
On scenario interpretation we could assume that 12 A/C may 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 17: Airport size categories according to COCR
Phase 1
Phase 2
APT Position
HD
LD
HD
LD
Clearance/Ramp
134
4
194
7
Ground
48
3
70
4
Tower
18
5
26
8
Total
200
12
290
19
For this document, the COCR differentiation was found not to be detailed enough. So
by refining the airport model and to provide 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.
© EUROCAE, 20XX
85
9.2
SESAR 15.2.7 Airport Categorization
For this section, FL stands for “Forward Link” which operationally means data flowing
from tower to the A/Cs and RL, “Reverse Link” that refers to packets going from A/Cs
to the tower.
9.2.1.1
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 may also belong to the
satellite or curvilinear category.
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.
NOTE: It may very well be possible that those airports having less than 5 operations
per hour will never be equipped with AeroMACS either because it may not be
economically viable or in order to preserve Globalstar interference limits.
9.2.1.1.1
Capacity Requirements for airports with 3 operations/hour
It is very likely that the Airport service provider cannot justify the
installation/maintenance cost for deploying the AeroMACS infrastructure. From
previous Globalstar interference studies, it is also not likely that all small European
airports will be allowed by ICAO FMG to be equipped with AeroMACS – to be
confirmed after development of COM AeroMACS tables and establishment of
interference criteria rules.
In case of AeroMACS availability at such an airport it is obvious that any AeroMACS
deployment 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] fulfil 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 conform to such an airport data needs.
Table 18: Airport capacity load for small airports (3 operations/hour)
Scenario
Average
offered
load
ATC
(Kbits/sec)
© EUROCAE, 20XX
Average offered load AOC
(Kbits/sec)
86
Average
offered
load
ATC
(Kbits/sec)
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 offered load AOC
(Kbits/sec)
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
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 18Table
18 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.9-68. 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 18 will develop as follows:
Table 19: Airport capacity load for small airports (3 operations/hour) considering FOQA as a
RAMP service
Average
offered
load
ATC
(Kbits/sec)
Scenario
Scenario 19 (1 A/C, 1 VC)
Overall
© EUROCAE, 20XX
0,0
Average offered load AOC
(Kbits/sec)
357,91
87
Average
offered
load
ATC
(Kbits/sec)
Scenario
RAMP arrival with FOQA
Scenario 20 (1 A/C, 1 VC)
RAMP departure/
ATC,NET,AOC,EFF,UPLIB,Echarts
9.2.1.1.2
Average offered load AOC
(Kbits/sec)
FL
0,0
0,22
RL
0,0
357,69
Overall
0,04
56,69
FL
0,02
47,64
RL
0,02
9,35
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.
Existing airport infrastructure shall 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.
Cell sizes should be of the macro cell size (large cells).
There is no need for special cell planning studies to determine BS site as terminal
infrastructure is likely to be small.
Nevertheless – in case AeroMACS installation - the airport authority has to contact
ICAO FMG and forward all information as specified under the frequency planning
regulations.
9.2.1.1.3
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 fulfil 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 omni-direction 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 20: Airport capacity load for small airports (20 operations/hour)
Scenario
Scenario 21 (10 A/C, 4 VC)
Average
offered load
ATC
(Kbits/sec)
Average offered load
AOC
(Kbits/sec)
0,14
3597,55
Overall
© EUROCAE, 20XX
88
RAMP arrival with FOQA
Scenario 22 (10 A/C, 4 VC)
RAMP departure
9.2.1.1.4
FL
0,06
18,32
RL
0,08
3579,23
Overall
0,41
1039,82 (~1 MBit)
FL
0,16
902,07
RL
0,24
139,24
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.
Also here macro cell sizes should be deployed.
The BS installed shall be deployed in such a way that it will provide the highest data
throughput at the RAMP area and hence operation under 64 QAM shall be strived for.
It should be mentioned that 64QAM modulation scheme in UL is optional for
implementation.
In case the terminal infrastructure is straight forward and not too complex there may
be no need to rely on dedicated cell planning to optimize BS location. Application of
RF rule of thumb, RF and installation requirements from this document as well as cell
planning rules may be sufficient for AeroMACS deployment.
Nevertheless the airport authority has to contact ICAO FMG and forward all
information as specified under the frequency planning regulations.
As an RF rule of thumb for establishing LOS conditions at several locations at the
airport the 1st FRESNEL zone can be calculated. This calculation will also allow the
determination of BS antenna height. For good LOS conditions the maximum
obstructions allowed into the beam is 20 to 40% of the first FRESNEL zone.
The general equation for calculating Fresnel zones radius at any point P in between
the endpoints of the link is the following:
where,
Fn = the nth Fresnel Zone radius in meters
d1 = the distance of P from one end in meters
d2 = the distance of P from the other end in meters
λ = the wavelength of the transmitted signal in meters
© EUROCAE, 20XX
89
Figure 36: FRESNEL zone determination parameters
9.2.1.2
Medium airports (20- 60 mvts/hr) – Parallel or Open V Runways and Linear – Curvilinear
Terminals
Medium airports may 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.
While it was not likely that many small airports will be equipped with AeroMACS, it is
foreseen that the medium airport category will be equipped.
9.2.1.2.1
Capacity Requirements for airports with 50 operations/hour
Medium airports are likely to comply to 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. Moreover, there was a mistaken found on simulations
results for scenario 30. FOQA was introduced in that scenario and counted for the
overall AOC traffic on the RL. That is completely wrong, and the service is only
instantiated in GROUND arrival phase. Therefore it must be removed from the figures.
As shown on table A.30-249 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 21: Airport capacity load for medium airports (50 operations/hour)
Scenario
Average offered
load ATC
(Kbits/sec)
© EUROCAE, 20XX
Average offered load
AOC
(Kbits/sec)
90
Overall
0,47
9021,26(~9 MBit)
FL
0,19
69,42
RL
0,28
8951,84
Overall
1,02
2317,97 (~2,3 MBit)
FL
0,41
1992,86
RL
0,60
325,45
Scenario 29 (25 A/C, 10
VC)
GROUND arrival without
FOQA
Overall
1,23
3321,19(~3 MBit)
FL
1,14
196,97
RL
0,09
3124,22
Scenario 30 (25 A/C, 10
VC)
GROUND departure (FOQA
is not executed on
departure)
Overall
1,05
1041,2 (~1 MBit)
FL
0,98
95,58
RL
0,07
945,6
Scenario 31 (25 A/C, 10
VC)
TOWER arrival
Overall
0,58
141,97
FL
0,57
0,0
RL
0,02
141,97
Overall
0,44
287,38
Scenario 27 (25 A/C, 10
VC)
RAMP arrival with FOQA
Scenario 28 (25 A/C, 10
VC)
RAMP departure
Scenario 32 (25 A/C, 10
VC)
TOWER departure
9.2.1.2.2
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 showed above, it is obvious that a single
AeroMACS BS is not any longer able to sustain the needed data throughput.
Medium airports should deploy multiple BSs locations to cover all airport areas.
Generally it is estimated that 3 BS with 3 sectors each should be able to fulfil 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 implementation should provide
more capacity in this area.
The exact location of the BS shall be determined by an airport cell planning study
which will take into account the terminal and airport infrastructure availability for this
particular airport.
Curvilinear – Satellite terminals may 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 terminals it may be useful to deploy an omni-directional
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 may be installed on light poles around the terminal area.
© EUROCAE, 20XX
91
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.
Nevertheless for every European medium airport, the appropriate cell planning study
shall be performed before any deployment can take place. AeroMACS frequency
planning shall be coordinated with ICAO FMG.
9.2.1.3
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.
9.2.1.3.1
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 53 and Table 54, which refine the original figures adding AOC data traffic
Table 22: Airport capacity load for large airports (100 operations/hour)
Scenario
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
Scenario 04 (50 A/C, 10 VC)
GROUND departure (FOQA is
not executed on departure)
Scenario 05
TOWER arrival
Scenario 06 (50 A/C, 10 VC)
TOWER departure
Overall
average
offered load FL
(Kbits/sec)
Overall average
offered load RL
(Kbits/sec)
137,53
17355,42
3106,42
496,42
352,47
3418,44
180,93
1807,7
1,08
279,21
0,88
596,12
© EUROCAE, 20XX
92
9.2.1.3.2
Coverage Requirements for airports with 100 operations/hour
Even without the heavy 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. Nevertheless the airport authority has to contact ICAO FMG and forward all
information as specified under the frequency planning regulations.
Because the terminal area is often a mixed structure, every airport shall rely on a
specific airport cell planning study to optimize BS placement so that all coverage
requirements will be met.
9.2.1.4
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.
9.2.1.4.1
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 23: Airport capacity load for very large airports (more than 100 operations/hour)
Average
offered load
ATC
(Kbits/sec)
Average offered load AOC
(Kbits/sec)
Overall
1,91
36079,32 (~36 MBit)
FL
0,78
274,27
RL
1,14
35805,05
Overall
3,20
471,62
FL
1,29
408,09
RL
1,91
63,53
Scenario
Scenario 07 (100 A/C, 20
VC)
RAMP arrival with FOQA
Scenario 08 (100 A/C, 20
VC)
RAMP departure
service exempted8
8
Service exempted means that the really large AOC applications such as EFF, UPLIB, E-CHARTS
have not been considered as AOC applications.
© EUROCAE, 20XX
93
Overall
4,53
7840,33 (~8 MBit)
FL
4,19
710,03
RL
0,34
7130,3
Scenario 10 (100 A/C, 20
VC)
GROUND departure (FOQA
is not executed on
departure)
Overall
3,52
3420,58 (~3,5 MBit)
FL
3,28
312,77
RL
0,24
3107,81
Scenario 11 (100 A/C, 20
VC)
TOWER arrival
services exempted
Overall
2,17
538,39
FL
2,11
0,0
RL
0,06
538,39
Overall
1,55
1019,44 (~1 MBit)
Scenario 09 (100 A/C, 20
VC)
GROUND arrival
Scenario 12 (100 A/C, 20
VC)
TOWER departure
9.2.1.4.2
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.
© EUROCAE, 20XX
94
CHAPTER 10
SYSTEM
INTEROPERABILITY
10.1 Multi-vendor Interoperability
The network reference model aimed to support AeroMACS access network and its
interconnection to the backbone has been previously depicted in section 2.1.
Sticking to 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.
•
The architecture SHALL support common functionalities according to what is
currently stated down below as requirements between BSs and between BS
and ASN-GW from different manufacturers.
As noted, these are not addressed issues and for the time being they’re not going to
be addressed.
The BS SHALL offer an interoperable interface with an ASN-GW. Besides, all
interfaces to core equipment SHALL be performed through R3 interface (as stated on
section 3.2). Protocols and procedures for R3 as well as R6 are drawn in [32].
As mandated on this WiMAX Forum document, GRE SHALL be used as the tunneling
protocol for the data plane over R6. GRE is an IP-in-IP tunnel. The granularity of this
tunnel SHALL be one tunnel per Service Flow (SF). It’s important to get straight with
the granularity issue in order to solve out interoperability. This is left to
implementation. In this case, all control resides in the ASN-GW.
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 going
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 so much meaningful in terms of security 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 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.
© EUROCAE, 20XX
95
The required R6 messages in order to support interoperability are described in [31] as
follows:
On the BS side:
It SHALL support Data path registration type1.
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
It SHALL support Data path de-registration for triggering MS network exit.
Operation ID IE: Data Path De-registration
It SHALL support HO preparation
Trigger source IE: 16e[schlereth11] function entity (RRC and NRM dismissed)
HO optimization IE: enabled or disabled? It’s a flag that may skip some
phases of network re-entry during HO process. i.e SBC REQ/RSP, REG
REQ/RSP PKM-TEK.
It SHALL support HO action.
It SHALL support HO cancellation.
It SHALL support HO rejection.
It SHALL perform Authentication Relay.
BS SHALL forward EAP messages over R6 to the ASN-GW Authenticator with the
ASN control data plane protocol.
It SHALL support AK transfer primitives and key reception.
It SHALL support NSP id list.
It SHALL implement the Context functionality.
On the ASN-GW side:
It SHALL perform Authentication and key distribution
ASN-GW SHALL forward EAP messages over R3 to the AAA server with the RADIUS
protocol.
It SHALL support Network Entry signaling.
It SHALL support Proxy MIPv4 Client.
It SHALL support MIP registration revocation.
It SHALL support DHCPv4 Proxy/Relay.
It SHOULD support MIPv6 Access Router.
It SHALL support Service Flow Authorization.
Policies are pulled from external AAA. Therefore it SHALL implement a AAA
client.
It SHALL support Data path registration type1.
It SHALL support Data path deregistration for triggering MS network exit.
It SHALL support HO preparation.
SBC context IE in case the field HO_optimization is enabled. Thus no new
capabilities are negotiated with the target BS and the ASN-GW has to forward
the ones of the serving BS.
AK context retrieval to the target BS.
© EUROCAE, 20XX
96
It SHALL support HO action.
It SHALL support HO cancellation.
It SHALL support HO rejection.
It SHALL support Context transfer.
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.
It SHALL support CMAC key count update.
Upon successful completion of Authentication, the Authenticator (in our case
the AAA server) sets the count for the MS to 1.
© EUROCAE, 20XX
97
CHAPTER 11
INTERFERENCE
The following material on interference issues related to AeroMACS is mainly an
excerpt of SESAR Project P15.2.7 deliverable [10]. In addition material on MSS
interference analysis worked out by a subgroup of RTCA SC-223 in collaboration with
EUROCAE WG-82 [43] is summarized in section 11.4, which provides guidance with
respect to the maximum tolerable power levels for implementation of AeroMACS.
Within SESAR Project P15.2.7 an assessment of potential coexistence problems
between AeroMACS and other systems operating in the same or in adjacent
frequency bands was made. The assessment included IEEE802.11a systems (i.e.
Radio Local Access Networks - RLANs) operating in the 5150-5350 MHz band, BBDR
(Broadband Disaster Relief) systems, MLS (Microwave Landing Systems) and AMT
(Aeronautical Mobile services for Telemetry). The main conclusions from the
assessment are that:
•
•
•
MLS transmitters may cause harmful interference to AeroMACS receivers when
installed at the same airport, even when the two systems are separated in
frequency by several tens of MHz. AeroMACS transmitters may also prevent MLS
operation.
AMT transmissions from aircraft may cause harmful interference to AeroMACS
receivers due to their high transmit powers.
It is unlikely that other terrestrial systems will cause coexistence problems for
AeroMACS.
Hence, coordination between the administrations operating AeroMACS, MLS and/or
AMT systems is required.
11.1 Regulatory Aspects
While the 5091-5150 MHz band has been assigned to Aviation as primary user, the
same band is also co-allocated to non-geostationary LEO satellite operators (e.g.,
Globalstar feeder links) and aeronautical mobile telemetry (AMT) as co-primary users.
ITU-R requires therefore that AeroMACS and any additional future aviation service
such as telemetry (AMT) or Aeronautical security (AS) limits the total aggregated
power flux density (pfd) at the satellite receiver to increasing the satellite receiver
Noise temperature ( ∆T/T) by no more than 3% at any orbit point and within the LEO
satellite antenna’s footprint.
11.1.1
AMT
The AMT system is used for real-time analysis and visualization of data during flight
tests. The 5091-5150 MHz band was allocated to AMT for transmission from aircraft to
ground at WRC-07, and adds to a list of frequency bands allocated to AMT. In Table
14, the different frequency bands are listed [20]. In Area 1 (Europe + Africa) it is also
possible to use the frequency band 5150-5250 MHz.
Table 24: Telemetry frequency allocations (USA) [20]
Frequency range
[MHz]
Primary/secondary
Comments
1435-1525
Primary
1525-1535
Secondary
Mobile satellite service (MSS) primary service
2200-2290
Co-primary
Co-primary service in USA
© EUROCAE, 20XX
98
2310-2360
Secondary
Wireless Communication Service (WCS) and broadcastingsatellite (sound) service (BSS) primary
2360-2395
Primary
4400-4940
-
Telemetry allowed under the mobile service allocation
5091-5150
-
Inclusion into NTIA Table of Frequency Allocation not yet
completed.
5925-6700
-
Inclusion into NTIA Table of Frequency Allocation not yet
completed.
The main challenge concerning AMT and AeroMACS is that AMT may interfere with
AeroMACS. It is considered less safety critical that AeroMACS may interfere with AMT
operations.
According to Annex 1 to Resolution 418 (WRC-07), certain conditions apply to the
implementation of AMT:
•
•
•
•
The operation of AMT systems shall be coordinated with administrations
operating MLS systems within a certain defined distance from the AMT flight
area.
For the protection of FSS systems, the increase in equivalent noise temperature
in the satellites due to AMT transmissions shall not exceed 1 %.
For the protection of mobile services in the 5150-5250 MHz frequency band, the
maximum power-flux-density at the Earth surface shall not exceed -79
2
dB(W/(m ·20 MHz))-Gr(θ), where Gr(θ) represents the mobile service receiver
antenna gain as function of elevation angle.
For the protection of aeronautical mobile (R) service (AM(R)S) in the frequency
band 5091-5150 MHz, maximum power flux density at the Earth surface
2
produced by AMT emissions shall not exceed -89.4 dB(W/(m ·20 MHz))-Gr(θ),(θ),
where Gr(θ) represents the AeroMACS mobile receiver antenna gain as function
of elevation angle. The maximum antenna gain is set to 6 dBi.
Hence, the last bullet point relates to AeroMACS and the protection of AeroMACS
mobile receivers.
11.1.2
MSS
The apportioned RFI allowance due to AeroMACS and AS shall be limited to 2 %.
This allows for fulfilling the ITU requirement of increase of satellite receiver Noise
temperature ( ∆T/T) by no more than 3% taking into account 1 % contribution by AMT
.
11.2 Impact of Out of Band Interference on Deployment (MLS)
The MLS signal use Time Division Multiplexing (TDM) including azimuth and elevation
signals. These signals are Continuous Wave (CW) with DPSK preambles with 3 dB
bandwidth of 15.626 kHz. It is the preambles that may interfere with other systems
and notably AeroMACS due to its low out-of-band attenuation.
11.2.1
Separation requirements
In [19], the minimum distance between a MLS transmitter and an AeroMACS receiver
with antenna gain 4 dBi as function of frequency offset was estimated. The figure is
included below for convenience.
© EUROCAE, 20XX
99
Minimum distance to interferer [m]
2000
1500
1000
500
0
5
10
15
20
25
30
Frequency off-set [MHz]
35
40
Figure 37: Minimum distance between MLS transmitter and AeroMACS receiver [19]
The minimum distance is reduced as the frequency offset increases. An offset of 10
MHz leads to a minimum distance of 800 meters, while an offset of 40 MHz leads to a
minimum distance of 200-250 meters.
11.2.2
Impact on AeroMACS deployment
The impact of MLS on AeroMACS deployment will depend on the number of airports
having operational MLS.
In order to operate both MLS and AeroMACS at an airport, bilateral coordination
between the two systems is necessary. This coordination must include:
Allocation of MLS frequency channels to European airports should facilitate operation
of AeroMACS systems. At large airports, at which it is likely to deploy a multi-cell
AeroMACS network, allocation of MLS channels should be in the lower part of the
5030-5091 MHz band. The AeroMACS system may be forced to avoid the frequency
channels closest to the MLS channels.
The cell planning of an AeroMACS network must take into account the location of MLS
ground equipment, and perhaps also the approach routes so that a base station
antenna is not directed directly towards approaching flights.
11.3 Impact of In Band Interference on Deployment (AMT)
11.3.1
Utilisation of AMT on 5 GHz by Airbus
The Airbus telemetry department uses three downlink channels to transfer data from
aircraft to ground stations. These channels allow monitoring directly the aircraft data
from the ground.
A reason why the 5091-5150 MHz band was allocated to AMT at WRC-07 is jamming
problems in the S-band. Currently, two frequency slots are available at S-band and Cband. From 2014 onwards, only the C-band will be used. According to AMT Airbus
service, the following four 8 MHz channels have been allocated to AMT by the French
telecom regulation authorities ANFR (centre frequencies):
•
5126 MHz
•
5135 MHz
•
5144 MHz
© EUROCAE, 20XX
100
•
5153 MHz
Except 5153 MHz all other channels are within the AeroMACS band.
The Airbus system is able to track three aircraft on three different frequencies
anywhere above France. Nine receiving antennas are placed at five strategic points to
realise this coverage:
•
4 antennas in Toulouse
•
1 antenna in Martigues
•
2 antennas in Bordeaux
•
1 antenna in Saint-Nazaire
•
1 antenna in Tarbes
The figure below presents the coverage of the terrestrial AMT antennas in reception.
The circles drawn in the figure give an idea of the optical coverage for each reception
antenna. These circles do not take into account the S/N required in reception (15dB)
and the power emitted by the aircraft antennas. The smallest circles represent an
altitude of 3 km and the largest circles an altitude of 10 km.
© EUROCAE, 20XX
101
FIGURE 38: RECEPTION ANTENNA COVERAGE (20000 FT)
Note:
Tarbes AMT station coverage is not represented. The AMT station has a
limited coverage of 20Nm around Tarbes Airport
Several modulation types are defined for telemetry systems in [20]:
•
Frequency Modulation (FM) and Phase Modulation (PM) – traditional methods
•
Pulse Code Modulation/Frequency Modulation (PCM/FM) – most popular since the
1970s
•
Feher Patented Quadrature Phase Shifting (FQPSK)
•
Shaped Offset Quadrature Phase Modulation (SOQPSK)
© EUROCAE, 20XX
102
•
Advanced Range Telemetry (ARTM) Continuous Phase Modulation (CPM)
In the table below, characteristics of the Airbus AMT system are listed. These
characteristics have been selected to obtain good operational conditions.
Table 25: AMT characteristics
Channel bandwidth
4 x 8 MHz
Modulation
Single Carrier-SOQPSK or COFDM-QPSK
Emitted Power
10 W
Aircraft antennas
One antenna on the bottom of the aircraft and another
antenna on the top of the aircraft
Gain: 0 dBi
Cable loss
2 dB
Steering Parabolic antenna
Ground antenna
2.4 m diameter
Throughput expected
20 Mbps downlink
Deployment
Tests aircraft (16 to 25 aircraft for Airbus), but
maximum 3 in flight at the same time
Coverage area
France
To resolve jamming issues, COFDM adaptive modulation has been selected. The
selected transmit power is 10 W, although 20 W is an option. The width of the
channels allows conveying all the traffic with good performances.
11.3.2
Separation requirements
The maximum transmit power for AMT is 20 W per transmitter with 8 MHz bandwidth,
and the typical number of transmitters on an aircraft is 2. As one antenna is located on
top of the aircraft and the other one underneath the aircraft, it is assumed that only
one of the two antennas will emit energy in the direction of an AeroMACS installation
at any time. With 0 dBi AMT antennas, the maximum EIRP is then 38 dBm over 8
MHz or 36 dBm over 5 MHz assuming 10 W transmit power and 2 dB cable loss.
The interference threshold for AeroMACS receivers is derived in [19]. Assuming noise
factor
dB and setting the interference margin to 3 dB, the following is obtained:
•
Thermal noise:
dBm (effective bandwidth
MHz)
•
•
Interference threshold
•
The AeroMACS base station antenna gain including cable loss is assumed to be
13 dBi. Hence, the attenuation of the AMT signal in the AeroMACS system's
© EUROCAE, 20XX
dBm
103
frequency channel due to separation in space and frequency should at least be in
the order of 36-(-100.1-13) ≈ 149 dB, assuming the worst case that the AMT
transmitter is located within the main beam of the AeroMACS antenna. The main
beam of the AeroMACS BS antenna is generally close to horizontal to cover the
airport surface. It is reasonable to assume that the distance to the AMT
transmitter is shortest when the test aircraft is close to the ground. Hence, there
is a risk that an interfering source will be within the main beam of the receive
antenna when the distance is the shortest.
When the interfering signal's bandwidth is non-overlapping with the receive filters of
the receiver, the total interference level depends on:
•
The level of the interfering signal within the receiver filter's bandwidth
•
The receive filter's attenuation within the interfering signal's bandwidth
First, the case where all interference is entering the receive bandwidth is considered.
In Figure 39, the minimum spatial separation distance between an AMT transmitter
and an AeroMACS base station and mobile station is illustrated as function of the
spectral isolation.
80
AeroMACS BS receiver
AeroMACS A/C receiver
70
Spectral isolation [dB]
60
50
40
30
20
10
0 1
10
10
2
3
4
10
10
Minimum separation [m]
10
5
10
6
Figure 39: Minimum spatial separation as function of spectral isolation. Total isolation is 154
dB.
If the AMT transmitter operates on the same frequency as an AeroMACS receiver,
there is no spectral isolation. In this case and assuming free space path loss, there
should not be any AMT transmissions closer to an AeroMACS base station than 132
km. For AeroMACS A/C receivers, the minimum distance is 59 km.
Typical transmission masks of AMT signals are not available, but generally the
spectral isolation will be between 50 dB and 80 dB at a distance from the centre
frequency equal to or greater than the signal bandwidth. Assuming 50 dB spectral
isolation, additional 99 dB attenuation can be obtained by about 418 meter spatial
separation (assuming free space path loss). If however the spectral isolation can be
© EUROCAE, 20XX
104
increased to 80 dB, the additional 74 dB attenuation can be obtained by about 13
meter separation in space.
Considering the interference entering the receiver within the AMT bandwidth, the
receive filters at radio frequencies (RF), intermediate frequencies (IF) and baseband
together should assure that the interference level becomes well below the interference
threshold. A similar analysis can be done as above for the case of interference level
within the receive bandwidth. If the interference levels within both the AMT transmit
band and the AeroMACS receive filters' band are of similar magnitude, it is important
the sum of the two is below the interference threshold.
In this analysis, 3rd order inter-modulation products (IMP) is not included, as it is
assumed that it will be of less importance. The same is the case for signal distortion
due to saturation in the receive amplifier.
11.3.3
Impact on AeroMACS deployment
The calculations above indicate that AMT systems operating in the 5091-5150 MHz
band may pose a problem for AeroMACS in Europe. Airbus currently operates three 8
MHz channels, which will overlap with at least 5 AeroMACS channels if they are all
using the 5091-5150 MHz band. In particular large airports will probably have multiple
AeroMACS cells occupying several or all of the eleven available 5 MHz channels. As
the minimum separation distance for co-channel AMT transmitters and AeroMACS
receivers is over 100 km, and the AMT coverage is the airspace over France, coexistence issues affecting all airports in France will arise. Coordination between AMT
systems and AeroMACS systems will therefore be required.
It should be noted that the restrictions on AMT from WRC-07, keeping the power flux
at the surface of the Earth where AeroMACS can be deployed lower than density
89.4 dB (W/(m2·20MHz)) with isotropic ground antenna, corresponds to an
interference level of:
dBm,
assuming that two 8 MHz AMT channels are active simultaneously within the 20 MHz.
Hence, the flux density requirement from WRC-07 corresponds to the interference
threshold derived in this project. For an AMT transmitter with transmit power 10 W to
comply with the requirements, the minimum altitude should be:
meters
Hence, according to WRC-07, either AMT transmitters should be turned off in the
vicinity of areas where AeroMACS is deployed, or the transmit power should be
reduced.
11.4 MSS Interference Analysis for AeroMACS
A subgroup of RTCA SC-223 lead by ITT Exelis in collaboration with EUROCAE WG82 and SESAR P15.2.7 defined a working method of specifying emissions from all
expected AeroMACS future deployments that are compliant with ITU co-interference
requirements, to establish 2-way link levels with the aircraft to ensure communication
service provision through the RF-link without adversely affecting the Global Star
Satellite feeder links. The following material is an excerpt of a working paper
presented at ACP WG-S in July 2013 [43].
The threshold interference power level for Globalstar at low earth orbit (LEO) has
been established at -157,3 dBW corresponding to 2% increase of the satellite
receiver’s noise temperature as outlined in section 11.1.2.
© EUROCAE, 20XX
105
In order to establish power limits for AeroMACS base station transmitters to avoid
interference with Globalstar uplinks, base stations with sector antenna transmitters
were modelled at 6207 airports in the United States, Europe and the rest of the world.
The following assumptions have been applied related to large, medium and small size
category airports:
Large size airports:
US categories: 35 Operational Evolution Partnership airports (OEP 35) [45]
Europe: 50 largest European airports according to Wikipedia list [46]
Medium size airports:
123 US category Class C airports
Europe: 50 medium category airports according to Wikipedia list rank 51 to 100
Small size airports:
All other airports in Openflights database [44]
In the model, each large airport is assigned six 120° sector antennas, each medium
airports is assigned three 120° sector antennas and each small airport is assigned one
120° sector antenna. Several simulation runs were applied with different random
antenna directions. This is equivalent to assume horizontal omni-directional station
pattern as a mean.
It is assumed that large airports will use all eleven 5 MHz channels, medium airports
will use six 5 MHz channels and small airports will use one 5 MHz channel. Small
airports are only allowed transmitting half as much power per sector as the medium
and large airports. This takes into account that at smaller sites it is expected that
AeroMACS is not permanently running.
Finally the following assumptions for EIRP, MIMO system and antenna pattern have
been applied:
•
Effective isotropic Radiated Power (EIRP) is the sector transmit power at the
antenna input plus antenna gain,
•
Maximum allowable EIRP in a base station sector shall be the sum of both
transmit power amplifiers in a 2-channel MIMO system,
•
Base Station Sector patterns are defined to be ITU-R-F-1336-2 reference
patterns with 120° 3 dB beam width toward Horizon (see Figure 40Figure 40).
© EUROCAE, 20XX
106
Figure 40: ITU-R-F-1336-2 reference antenna patterns and mask [43]
© EUROCAE, 20XX
107
Based on the analysis it is recommended that deployment of AeroMACS base stations
observe the following emissions limitations:
The total base station EIRP in a sector should not exceed:
•
39.4 dBm for elevation angles up to 1.5 degrees
•
39.4 dBm linearly decreasing (in dB) to 24.4 dBm for elevation angles from 1.5 to
7.5 degrees
•
24.4 dBm linearly decreasing (in dB) to 19.4 dBm for elevation angles from 7.5
to 27.5 degrees
•
19.4 dBm linearly decreasing (in dB) to 11.4 dBm for elevation angles from 27.5
to 90 degrees
In addition the following requirement for the mobile stations is applied:
The total mobile station EIRP shall not exceed 30 dBm
These limitations include the following assumptions:
(a) EIRP is defined as antenna gain in a specified elevation direction plus the average
AeroMACS transmitter power. While the instantaneous peak power from a given
transmitter may exceed that level when all of the subcarriers randomly align in phase,
when the large number of transmitters assumed in the analysis is taken into account,
average power is the appropriate metric.
(b) The breakpoints in the base station EIRP mask are consistent with the elevation
pattern of a +15 dBi peak, 120 degree sector antenna as contained in ITU-R F.1336-2.
(c) If a station sector contains multiple transmit antennas on the same frequency (e.g.,
MIMO), the specified power limit is the sum of the power from each antenna.
(d) No base station antenna down-tilt is applied in these assumptions. Higher sector
average transmit power may meet these limitations if antenna pattern down-tilt is
used.
(f) Mobile station EIRP is based on full occupancy of transmit sub-carriers for 5 MHz
bandwidth
11.5 Potential Future Interference Sources
Another major potential interference source is the Control and Non Payload
communication (CNPC) for Unmanned Aircraft Systems (UAS). In that context
discussion at the time of publication of the present document is about one satellite and
one terrestrial link for CNPC services within the MLS band 5030 to 5091 MHz.
It is recommended to follow the discussion on these proposals as interference
between CNPC communications in the MLS band and AeroMACS is very likely, which
would require appropriate interference planning activities to be initiated.
© EUROCAE, 20XX
108
CHAPTER 12
RF Cell Dimensioning
and Planning
12.1 RF Cell Dimensioning
The scope of this section and thus through the RF simulations is:
•
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
AeroMACS Deployment Case StudiesAPPENDIX D: AeroMACS Deployment Case
Studies.
12.1.1
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 may
occur between statistical models and determinist 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. 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
© EUROCAE, 20XX
109
ground feature can become a physical obstacle to the propagation of the signal
(diffraction, absorption…).
12.1.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…).
•
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.
12.1.1.2 Diffraction effect
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.
12.1.1.3 Sub-path attenuation 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.
12.1.1.4 Multi-reflection effect
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.
12.1.1.5 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].
© EUROCAE, 20XX
110
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 datacarriers 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.
12.1.1.5.1 Free space model
Both free space and NLOS MUNICH pathloss models have been calculated in the
spreadsheet.
The mathematical formula for free space model and AWGN operating conditions
corresponds to:
Lp = -32,4-20LOG(f (MHz))-20LOG(d (km))
12.1.1.5.2 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:
Lp = A + 10µlog(d) with A = 49,3dB and µ = 2,5
12.1.1.5.3 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 P15.2.7 channel modelling) or BS1MR1 and BS2MR2
4. DLR MUNICH NLOS
9
A comparison can be found between all 4 models in Figure 41 .
9
DLR (NLOS) is equivalent to DLR MUNICH NLOS
© EUROCAE, 20XX
111
Figure 41: 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 C.
12.1.1.5.4 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.
It should be mentioned that parameters shown are not minimum requirements (e.g.
antenna gain). These values have been considered as realistic at time of simulation
investigations and might vary in the future dependent on equipment available.
© EUROCAE, 20XX
112
WIMAX IEEE802.e LINKBUDGET FOR THE DOWNLINK (5 MHz Bandwidth)
Modulation Scheme
Link Direction
TX Parameters
# of antenna elements
TX Power per Antenna Element
Maximum TX Antenna Gain
Tx Cable loss
TX EiRP
# of occupied sub-carriers
NFFT Window size
TX EIRP per sub-carrier
QPSK 1/2
DL (CC)
DL (CTC)
16QAM 1/2
DL (CC)
DL (CTC)
64 QAM 1/2
DL (CC)
DL (CTC)
Unit
dBm
dBi
dB
dBm
dBm
1
23,00
15,00
3,00
35,00
420
512
8,77
1
23,00
15,00
3,00
35,00
420
512
8,77
1
23,00
15,00
3,00
35,00
420
512
8,77
1
23,00
15,00
3,00
35,00
420
512
8,77
1
23,00
15,00
3,00
35,00
420
512
8,77
1
23,00
15,00
3,00
35,00
420
512
8,77
5,00
5,00
10,94
2,90
5,00
10,94
11,00
5,00
10,94
8,60
5,00
10,94
16,00
5,00
10,94
13,80
5,00
10,94
5120
5120
5120
5120
5120
5120
1
3
3
0
0
0
1
3
3
0
0
0
1
3
3
0
0
0
1
3
3
0
0
0
1
3
3
0
0
0
1
3
3
0
0
0
6
1,8
-174
7
8,8
6
1,8
-174
7
8,8
6
1,8
-174
7
8,8
6
1,8
-174
7
8,8
6
1,8
-174
7
8,8
6
1,8
-174
7
8,8
-118,8
-92,6
-120,9
-94,7
-112,8
-86,6
-115,2
-89,0
-107,8
-81,6
-110,0
-83,8
System Parameters
Required SNR
Bandwidth
sub-carrier spacing
Transmit upper Frequency
dB
MHz
kHz
MHz
Margins
Non-orthogonality Margin
Inter-cell Interference Margin
Implementation Margin
Safety Margin
Banking Loss Margin
RX Antenna Diversity Gain
dB
dB
dB
dB
dB
dB
RX Parameters
Maximum RX Antenna Gain
Rx Cable loss
Thermal Noise Density@290K
Receiver Noise Figure
Composite Noise Figure
dBi
dB
dBm/Hz
dB
dB
RX Sensitivity (per sub-carrier)
RX Sensitivity (composite)
dBm
dBm
Maximum Allowable Path Loss
free space LOS
NLOS MUNICH
dB
127,6
129,7
11190,94 14251,70
1352,36 1640,94
121,6
5608,76
778,20
Table 26: DL Link Budget
12.1.1.5.5 UPLINK PUSC
© EUROCAE, 20XX
124,0
7393,78
970,72
116,6
3154,04
491,01
118,8
4063,19
601,30
113
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
PILOT
DATA
DATA
DATA
DATA
DATA
DATA
PILOT
DATA
PILOT
Freq carriers
Figure 42: 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.
© EUROCAE, 20XX
114
WIMAX IEEE802.e LINKBUDGET FOR THE UPLINK (5 MHz Bandw idth)
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
# of antenna elements
1
1
1
1
1
1
TX Pow er per Antenna Element
dBm 21,00
21,00
21,00
21,00
21,00
21,00
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
TX EiRP
dBm 25,20
25,20
25,20
25,20
25,20
25,20
# of occupied sub-carriers
24
24
24
24
24
24
NusedsubCh UL
1
1
1
1
1
1
NSubChUL
17
17
17
17
17
17
NFTT Window size
512
512
512
512
512
512
TX EIRP per sub-carrier
dBm 11,40
11,40
11,40
11,40
11,40
11,40
System Parameters
Required SNR
Bandw idth
sub-carrier spacing
Uplink Sub-Channelization Gain
Transmit upper Frequency
dB
MHz
kHz
dB
MHz
5,00
5,00
10,94
12,3
5120
2,90
5,00
10,94
12,3
5120
10,50
5,00
10,94
12,3
5120
8,60
5,00
10,94
12,3
5120
16,00
5,00
10,94
12,3
5120
13,80
5,00
10,94
12,3
5120
Margins
Non-orthogonality Margin
Implementation Margin
Safety Margin
Banking Loss Margin
RX Antenna Diversity Gain
dB
dB
dB
dB
dB
0
5
0
0
0
0
5
0
0
0
0
5
0
0
0
0
5
0
0
0
0
5
0
0
0
0
5
0
0
0
RX Parameters
Maximum RX Antenna Gain
Rx Cable loss
Thermal Noise Density@290K
Receiver Noise Figure
Composite Noise Figure
dBi
dB
dBm/Hz
dB
dB
15
3
-174
8
11
15
3
-174
8
11
15
3
-174
8
11
15
3
-174
8
11
15
3
-174
8
11
15
3
-174
8
11
RX Sensitivity (per sub-carrier) dBm
RX Sensitivity (per sub-carrier)
w ithout subcahnnelization gain dBm
RX Sensitivity (composite)
dBm
-109,9
-112,0
-104,4
-106,3
-98,9
-101,1
-97,6
-96,1
-99,7
-98,2
-92,1
-90,6
-94,0
-92,5
-86,6
-85,1
-88,8
-87,3
Maximum Allow able Path Loss dB
Maximum Allow able Path Loss
dB
w ithout Sub-Channelization
m
free space LOS
N LOS M UN IC H
m
121,3
123,4
115,8
117,7
110,3
112,5
109,01
5440,14
759
111,11
6928,04
921
103,51
2888,09
458
105,41
3594,27
545
98,01
1533,24
276
100,21
1975,20
338
© EUROCAE, 20XX
115
Table 27: UL Link Budget
12.1.1.6 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 may be 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 may
give 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 28: 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 29: Window attenuation values
Frequency GHz
Glass/Window
Double-pane
(not tinted) dB
coated glass dB
2,4
2-3
13
5
6-8
20
12.1.1.7 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
© EUROCAE, 20XX
116
• Antenna systems, choice of optimized localizations for BS and downtilts
• Detailed radio coverage analysis
Step 4 – Network optimization
• Interferers mitigation
• Tuning
This process is unique for each deployment and is common to all the wireless radio
technologies.
12.1.2
Capacity Analysis
This section summarizes results of simulation efforts done within SESAR P15.2.7 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 Figure XX, which shows the AeroMACS
Profile 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[schlereth12].
Figure 43: Frequency Mask
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
10
requirements that may be needed by the services identified . 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 C.
Two possible scopes of study have been defined:
10
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.
© EUROCAE, 20XX
117
Analysis of the coverage and capacity offered per cell;
Study of the overall capacity offered in a whole airport (Madrid Barajas).
12.1.2.1 Capacity and coverage analysis per cell
12.1.2.1.1 Summary on simulation conditions
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.
© EUROCAE, 20XX
118
0
10
-1
10
-2
BER
10
-3
10
-4
10
-5
10
0
CP=1/8Ts,#slot=1 (LIN)
CP=1/8Ts,#slot=1 (ID)
CP=1/16Ts,#slot=1 (LIN)
CP=1/8Ts,#slot=195 (LIN)
CP=1/16Ts,#slot=195 (LIN)
5
10
15
10
15
E /N [dB]
b
0
0
10
-1
PER
10
-2
10
-3
10
-4
10
0
CP=1/8Ts,#slot=1 (LIN)
CP=1/8Ts,#slot=1 (ID)
CP=1/16Ts,#slot=1 (LIN)
CP=1/8Ts,#slot=195 (LIN)
CP=1/16Ts,#slot=195 (LIN)
5
E /N [dB]
b
0
Figure 44: BER and PER in FL, LOS channel ([50], section 4.4)
© EUROCAE, 20XX
119
0
10
CP=1/8Ts,#slot=1 (LIN)
CP=1/8Ts,#slot=1 (ID)
CP=1/16Ts,#slot=1 (LIN)
CP=1/8Ts,#slot=195 (LIN)
-1
10
-2
BER
10
-3
10
-4
10
-5
10
-6
10
0
5
10
15
E /N [dB]
b
20
25
30
0
0
10
CP=1/8Ts,#slot=1 (LIN)
CP=1/8Ts,#slot=1 (ID)
CP=1/16Ts,#slot=1 (LIN)
CP=1/8Ts,#slot=195 (LIN)
-1
10
-2
PER
10
-3
10
-4
10
-5
10
0
5
10
15
E /N [dB]
b
20
25
0
Figure 45: BER and PER in FL, NLOS channel [50]
© EUROCAE, 20XX
30
120
0
10
-1
10
-2
BER
10
-3
10
-4
10
-5
10
-6
10
0
CP=1/8Ts,#slots=102 (LIN)
CP=1/8Ts,#slots=1 (LIN)
CP=1/16Ts,#slots=1 (LIN)
CP=1/8Ts,#slots=1(ID)
CP=1/8Ts,#slots=102 (ID)
5
10
E /N [dB]
b
15
20
15
20
0
0
10
-1
PER
10
-2
10
-3
10
-4
10
0
CP=1/8Ts,#slots=1(LIN)
CP=1/8Ts,#slots=1(ID)
CP=1/8Ts,#slots=102(LIN)
CP=1/8Ts,#slots=102(ID)
CP=1/16Ts,#slots=1(LIN)
5
10
E /N [dB]
b
0
Figure 46: BER and PER for RL, LOS channel [50]
© EUROCAE, 20XX
121
0
10
CP=1/8Ts,#slot=1 (LIN)
CP=1/8Ts,#slot=102 (LIN)
CP=1/16Ts,#slot=1 (LIN)
CP=1/8Ts,#slot=45 (LIN)
-1
10
-2
BER
10
-3
10
-4
10
-5
10
-6
10
0
5
10
15
E /N [dB]
b
20
25
30
0
0
10
CP=1/8Ts,#slot=1 (LIN)
CP=1/8Ts,#slot=102 (LIN)
CP=1/16Ts,#slot=1 (LIN)
CP=1/8Ts,#slot=45 (LIN)
-1
PER
10
-2
10
-3
10
-4
10
0
5
10
15
E /N [dB]
b
20
25
30
0
Figure 47: 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). Hard constant bit rate
(CBR)11 traffic has been considered; MAC-level SDUs are split in one or more PHYlevel PDUs that are then sent over the air-interface. Three different cases have been
investigated:
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 the situation is similar to case 1 with the difference
that the available resources in the frame are less.
The following modulation and coding schemes (MCS) have been considered:
11
Hard constant bit rate means a CBR traffic which has also tight restrictions on jitter and latency.
© EUROCAE, 20XX
122
•
•
16-QAM CC ½
QPSK CC ½
No Turbo-Decoding has been applied. Two SNR threshold values have been set in
FL/RL to switch between them. These thresholds, shown in Table 30 below, have
been set in order to select the modulation and coding scheme that guarantees the
maximum throughput at each SNR12.
Adaptive MCS threshold (SNR in dB)
LoS
NLoS
UL
20.7
24.1
DL
24.9
28.7
Table 30: MCS switching thresholds
According to suggestion in [9] the following two different ARQ schemes have been
recommended:
•
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
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.
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.
12.1.2.1.2 Conclusions
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 means that ARQ type 2 should be preferred to ARQ type 1 to best manage these
conditions.
Comparing the results obtained in the three considered simulation Cases as outlined
in more detail in APPENDIX XX it is possible to state that system performance is
mainly influenced by two aspects, packet dimension and bandwidth saturation:
12
It is to be noted that these thresholds might be lower if using a CTC instead of a CC
© EUROCAE, 20XX
123
-
-
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
depends on channel impairments and packets length; smaller packet lengths get
a benefit from a lower error probability
Table 31: Maximum coverage results
Maximum coverage (meter)
DL
UL
Full load – LoS – ARQ ACK 1
1495
1365
Full load – LoS – ARQ ACK 2
1600
1420
Full load – NLoS – ARQ ACK 2
955
965
1/5 traffic- LoS – ARQ ACK 2
1605
1405
1/5 traffic- NLoS – ARQ ACK 2
960
985
1/4 resources LoS – ARQ ACK 2
1835
1685
1/4 resources NLoS – ARQ ACK
2
1210
1125
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 31. 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.
12.1.2.2 Capacity analysis per airport
12.1.2.2.1 Operational concept
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[schlereth13]).
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
© EUROCAE, 20XX
124
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
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, AeroMACS Deployment Case StudiesAPPENDIX D:
AeroMACS Deployment Case Studies should be checked for this purpose instead.
More details on the capacity analysis can be found in Appendix C.
12.1.2.2.2 Conclusions
In CAPACITY ANALYSIS, 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 should 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 may be spaced 2650 m out, while RAMP BSs should 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 implementers
should 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
C 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 C 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
© EUROCAE, 20XX
125
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.
12.2 RF CELL PLANNING
The purpose of this subsection is to identify and provide recommendations for
AeroMACS cell planning and for intra and inter-system interference reducing. 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 AeroMACS Deployment Case
StudiesAPPENDIX D: AeroMACS Deployment Case Studies Case Study 2.
12.2.1
Simulation of intra-system interference
12.2.1.1 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 AeroMACS Deployment Case
StudiesAPPENDIX D: AeroMACS Deployment Case Studies (Case Study 1).
Note: The calculation of central frequencies is done according to the formula (5005
+n*5 (n=0..4 and 19..28)), which gives 11 contiguous channels.
Table 32: Frequency planning & reuse for intra-system interference analysis
Frequency planning & reuse for HTZ
5005 +n*5 (n=0..4 and 19..28)
n
0
1
Fi
5005
5010
n° Fi
1
2
Freq nb in HTZ
2
5015
3
3
5020
4
4
5025
5
11 available contiguous freq for range: 5091 to 5150 MHz
18
19
20
21
22
23
5095
5100
5105
5110
5115
5120
6
7
8
9
10
11
1
2
3
4
5
6
24
5125
12
7
25
5130
13
8
26
5135
14
9
27
5140
15
10
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
© EUROCAE, 20XX
28
5145
16
11
126
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.
12.2.1.2 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 that may occur during a real deployment on airport. We still consider
Barajas airport 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
© EUROCAE, 20XX
127
Figure 48: Map of C/I intra-system interference, based on DL coverage
Table 33: C/I versus Modulation Schemes13
C/I (>dB)
5
8
11
14
16
19
20
Received Power
(>=dBm)
-92
-86
-84
-80
-78
-76
-74
Modulation
Scheme
QPSK1/2
QPSK3/4
16QAM 1/2
16QAM 3/4
64QAM 1/2
64QAM 2/3
64QAM 3/4
In order to operate in a given modulation scheme, and thus access to a given data bit
rate, a minimum C/I shall be respected. We observe on the C/I map that all the airport
area have a C/I between 16 and 40dB, which means that, based on the frequency
planning prepared, no interferences occur in the AeroMACS system for this
deployment.
Because FFR (Fractional Frequency Re-use) won’t be available 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.
12.2.1.3 Optimization of cell planning
As result of this cell planning process the number of base stations could change. In
this case, the planning tool should make 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)
13
See table 85 Item 6 in Error! Reference source not found.Fehler! Verweisquelle konnte nicht
gefunden werden.
© EUROCAE, 20XX
128
Cell planning is basic, and focus has been done on inter-system interference
analysis (see also AeroMACS Deployment Case StudiesAPPENDIX D:
AeroMACS Deployment Case Studies).
© EUROCAE, 20XX
129
CHAPTER 13
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.
AeroMACS SHALL perform device authentication. According to ARINC 842, aircraft
identification SHALL be performed through tail numbering and optionally including
ICAO 24-bit ID.
AeroMACS SHALL support mechanisms and procedures to ensure message integrity
and the continuous verification of the sender of the message.
AeroMACS by means of Authorization and Authentication mechanisms SHALL deal
with different types of access (USER/ADMIN). Nevertheless user authentication is out
of the scope of AeroMACS and hence left to implementation.
AeroMACS, in order to provide secured communications within the air interface
(MS/BS) SHALL implement security association with cryptographic suites. Moreover,
two types of Security Associations SHALL be implemented: primary and static.
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 BS units SHALL handle and manage the security, and connection
identifiers of each MS that is successfully authenticated.
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. The use of a 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 architecture SHALL give the means to correct billing of data traffic to the
respective users (Accounting). Nevertheless 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 SHALL support security association mechanisms between MS and BS.
Therefore some control policy must be applied in order to give differentiated grade of
service and accuracy to the same user.
AeroMACS security SHALL be considered at every phase of the system's life cycle.
AeroMACS devices SHOULD present as far as possible, the lowest number of
exploitable vulnerabilities. In case COTS devices would be used Public vulnerability
databases (e.g. National Vulnerability Database – NVD) COULD be used as they
provide updated information on newly discovered vulnerabilities and relative corrective
patches. The CVSS scores COULD 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. A particular attention
SHALL be given to protect nodes used at regional or larger scale (e.g. AAA servers,
DHCP servers).
AeroMACS operators MAY consider diversity of 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. For example, one may take advantage of the
© EUROCAE, 20XX
130
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 SHOULD be taken into account while
implementing and operating AeroMACS considering the context of operation in order
to assess the actual related risk
© EUROCAE, 20XX
131
CHAPTER 14
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 and ETHERNET CS
capability of AeroMACS. For this 3 system level test cases are described:
1) IPv6 test specification,
2) Ethernet CS test case specification,
3) Convergence Sublayer establishment test case specification.
Text cases 1) and 2) are relevant for certification the according MAY 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.
14.1 IPv6 test cases specification
The purpose of these test procedures is to verify that an AeroMACS system under test
implements IETF RFC 2460 [53] as required in [57].
The test cases in this section cover AeroMACS PICS [57] item 2 in Table 74.
14.1.1
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
Roles:
- IPv6 access router
(stateless case)
- DHCPv6 relay
(stateful case)
Wireline
capture
Wireless
capture
Remote
STA1
ASN-GW
IPv6
IPv6
Roles:
- Data endpoint
- AAA
- DHCPv6 server
(stateful case)
IPv6
IPv6
IP CS
IP CS GRE
GRE
MAC
MAC
IP*
IP*
LINK
LINK
PHY
PHY
LINK
LINK
PHY
PHY
PHY
PHY
Figure 49: IPv6 test cases test configuration
*: Either IPv4 or IPv6 can be used in R6 as it is not a requirement for this test
specification.
© EUROCAE, 20XX
132
14.1.2
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.
© EUROCAE, 20XX
133
14.1.3
TC-IPv6-STFUL
Name:
Identifier:
Purpose:
IPv6 CS: Stateful configuration
TC-IPv6-STFUL
The AeroMACS system supports stateful address
configuration.
1) Start the monitor message capture, if available.
Preamble:
auto-
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
1.
AIRCRAFT1
Action
ENTER
2.
GND1
VERIFY
3.
AIRCRAFT1
VERIFY
4.
GND1
VERIFY
5.
AIRCRAFT1
VERIFY
6.
AIRCRAFT1
VERIFY
Postamble:
Description
The AeroMACS MS has successfully completed network entry
and device authentication.
During authentication DHCPv6 server information has been
included.
The access router in the ASN sends a Router Advertisement
message with the M-flag set.
The MS sends a DHCPv6 REQUEST message requesting an
IPv6 address to the DHCPv6 server identified during
authentication.
MS and ASN uses DHCPv6 procedures as defined in RFC 3315
[55] to configure a valid IPv6 address for the MS.
The MS can send data traffic to the Remote STA1 (e.g., use
ping6 command).
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.
None
© EUROCAE, 20XX
134
14.1.4
TC-IPv6-STLESS-BV
Name:
Identifier:
Purpose:
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.
Preamble:
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
1.
AIRCRAFT1
Action
ENTER
Description
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
© EUROCAE, 20XX
135
14.1.5
TC-IPv6-STLESS-BI
Name:
Identifier:
Purpose:
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.
Preamble:
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
1.
AIRCRAFT1
Action
ENTER
Description
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:
14.1.6
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
1.
AIRCRAFT1
Action
ENTER
Description
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.
© EUROCAE, 20XX
136
14.2 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 802.16-2009 [39] section 5.2.4.
Additionally, there are requirements for the PDU format and the classification rules
which refer to IEEE 802.16-2009 [39] section 5.2.4.1 and 5.2.4.2.
The purpose of these test procedures is therefore to verify that an AeroMACS system
under test implements the following features of Ethernet CS sublayer:
14.2.1
•
Ethernet CS PDU format as required in 2.2.5.2.4.1 which refers to 5.2.4.1 [39].
•
Ethernet CS classification rules as required in 2.2.5.2.4.2 which refers to 5.2.4.2
[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
Data flow 1
Local
STA1
Remote
STA1
Data flow 2
Local
STA2
Hub
Remote
STA2
Data flow 3 (QoS)
Local STA
ETH
MS
BS
ASN-GW
ETH
ETH
ETH
ETH
ETH
ETH CS
ETH CS
GRE
GRE
ANY
MAC
MAC
IP
IP
LINK
PHY
PHY
LINK
LINK
PHY
PHY
PHY
Remote STA
Figure 50: 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 802.16e-2009 (section
11.13.18.3.3). Verifying all of them would not be practical for the test
laboratory since it would require a highly complex test configuration. As trade-
© EUROCAE, 20XX
ETH
137
off three rules have been covered in this test specification: VLAN Id rule, IP
src/dst rule and IP Type of Service rule.
© EUROCAE, 20XX
138
14.2.2
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 shall set ACK disable = 1.
Authentication: Any.
SS Management: Unmanaged.
© EUROCAE, 20XX
139
14.2.3
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
1.
GND1
Action
ENTER
Description
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:
- 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)
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 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
© EUROCAE, 20XX
140
14.2.4
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
1.
GND1
Action
ENTER
Description
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
© EUROCAE, 20XX
141
14.2.5
TC-ETH-CS-ToS_Rule
Name:
Identifier:
Purpose:
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.
Preamble:
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
1.
GND1
Action
ENTER
Description
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
Rule 2: IP Type of Service (CS4)
4.
AIRCRAFT1
ENTER
Switch on the MS.
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.
© EUROCAE, 20XX
142
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.
© EUROCAE, 20XX
143
14.3 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 11.13.18.1, [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.
14.3.1
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 51: CS Establishment test cases test configuration
14.3.2
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.
© EUROCAE, 20XX
144
14.3.3
TC-CS-IPv6_FB
Name:
Identifier:
Purpose:
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.
Preamble:
Steps:
No
System
1.
AIRCRAFT1
Action
ENTER
Description
Switch on the MS.
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:
14.3.4
None
TC-CS-ETH_FB
Name:
Identifier:
Purpose:
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.
Preamble:
Steps:
No
System
1.
AIRCRAFT1
Action
ENTER
Description
Switch on the MS.
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 802.3
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:
None
© EUROCAE, 20XX
145
14.4 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 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.
FIGURE 52: END-TO-END TEST CASE CONFIGURATION
Name:
Identifier:
Purpose:
CM-Logon: nominal case
CM_001
The purpose of the test is to check the Ground System correctly
handles the CM-Logon service
Preamble:
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
14.1, 14.2).
Steps:
No
System
1.
AIRCRAFT1
2.
GND1
3.
GND1
Action
ENTER
VERIFY
ENTER
4.
VERIFY
AIRCRAF1
5.
GND1
Postamble:
VERIFY
Description
AIRCRAFT1 sends a CM-logon request to GND1
Check GND1 receives the CM-logon indication from AIRCRAFT1.
GND1 responds with a positive CM-logon response to
AIRCRAFT1.
Check AIRCRAFT1 receives an accepted CM-logon confirmation
message providing supported applications by GND1.
Check on ground side that AIRCRAFT1 appears logged on GND1
None
© EUROCAE, 20XX
146
Name:
Identifier:
Purpose:
CPDLC connection: accepted
CPDLC_001
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).
It is assumed that AIRCRAFT1 is already logged to the Ground
System (c.f. test CM_001).
Preamble:
Steps:
No
System
1.
GND1
Action
ENTER
2.
AIRCRAFT1
VERIFY
3.
4.
AIRCRAFT1
GND1
ENTER
VERIFY
5.
AIRCRAFT1
ENTER
6.
GND1
ENTER
7.
GND1
ENTER
8.
AIRCRAFT1
ENTER
9.
GND1
ENTER
10.
AIRCRAFT1
ENTER
11.
AIRCRAFT1
ENTER
12.
GND1
ENTER
13.
GND1
ENTER
Postamble:
Description
Send a CPDLC-start request to AIRCRAFT1 (no CPDLC
message element provided).
Check AIRCRAFT1 receives the CPDLC-start indication (no
CPDLC message element provided) from GND1.
Send an accepted CPDLC-start response to GND1.
Check GND1 receives the accepted CPDLC-start confirmation
from AIRCRAFT1.
Send the DM99 CURRENT DATA AUTHORITY message to
GND1
Check GND1 receives the DM99 CURRENT DATA AUTHORITY
message from AIRCRAFT1.
Send the UM227 LACK message to AIRCRAFT1 to acknowledge
DM99 CURRENT DATA AUTHORITY message.
Check AIRCRAFT1 receives the UM227 LACK message from
GND1 acknowledging the DM99 CURRENT DATA AUTHORITY
message.
Send the UM183 'CURRENT ATC UNIT facility designation,
facility name,facility function' message to AIRCRAFT1
Check AIRCRAFT1 receives the UM183 'CURRENT ATC UNIT
facility designation, facility name, facility function' message.
Send the DM100 LACK message to acknowledge the UM183
'CURRENT ATC UNIT facility designation, facility name, facility
function' message
Check GND1 receives the DM100 LACK message acknowledging
the UM183 'CURRENT ATC UNIT facility designation, facility
name, facility function' message
Check AIRCRAFT1 appears as logged on and CPDLC connected
to GND1.
None
© EUROCAE, 20XX
147
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 Startup
Preamble:
Steps:
No
System
1.
AIRCRAFT1
2.
GND1
CPDLC_001
Action
ENTER
VERIFY
3.
GND1
ENTER
4.
AIRCRAFT1
VERIFY
5.
6.
7.
GND1
AIRCRAFT1
AIRCRAFT1
ENTER
VERIFY
ENTER
8.
GND1
VERIFY
Postamble:
Variants:
Description
Send the DM25 REQUEST [START-UP] CLEARANCE
Check GND1 receives the DM25 REQUEST [START-UP]
CLEARANCE
Send the UM227 LACK message to AIRCRAFT1 to acknowledge
DM25 REQUEST [START-UP] CLEARANCE message.
Check AIRCRAFT1 receives the UM227 LACK message from
GND1 acknowledging the DM25 REQUEST [START-UP]
CLEARANCE message.
Send the UM311 START UP APPROVED
Check AIRCRAFT1 receives the UM311 START UP APPROVED
Send the DM100 LACK message to GND1 to acknowledge the
UM311 START UP APPROVED
Check GND1 receives the DM100 LACK from AIRCRAFT1
acknowledging the UM311 START UP APPROVED
None
Repeat
© EUROCAE, 20XX
148
Appendix A GUIDELINES FOR <xxx>
Include any useful additional information as necessary. This is not a mandatory annex.
© EUROCAE, 20XX
149
Appendix B ACRONYMS AND GLOSSARY OF TERMS
Term
Definition
AAA
Authorisation, Authentication and Accounting
AeroMACS
Aeronautical Mobile Airport Communication System
AK
Authorization Key
AMC
Adaptive Modulation and Coding
AMHS
Aeronautical Message Handling System
AMT
Aeronautical Mobile Telemetry
ANSP
Air Navigation Service Provider
AR
Airborne Router
ARB
Authoritative Representative Body
AOC
Airline Operational Communication
ARQ
Automatic Repeat Request
AS
Aeronautical Security
ASN-GW
Access Service Network-Gateway
ATM
Air Traffic Management
BB
Base Band
BE
Best Effort Service
BER
Bit Error Ratio
BS
Base Station
BW
Bandwidth
CFMU
Central Flow Management Unit
CDM
Collaborative Decision Making
COCR
Communications Operational Concept and Requirements
COMT
Eurocontrol COM Team
CONOPS
Concept of Operations
COTS
Commercial of the shelf
DCL
Departure Clearance
DDS
Data Distribution Services
© EUROCAE, 20XX
150
Term
Definition
DL
Downlink
DoS
Denial of Service
D-TAXI
Departure Taxi
EAD
European AIS Database
EAP
Extensible Authentication Protocol
E-ATMS
European Air Traffic Management System
EIRP
Effective isotropic Radiated Power
EUROCAE
European Organisation for Civil Aviation Equipment
FA
Foreign Agent
FAB
Functional Airspace Block
FCI
Future Communication Infrastructure
FFS
For Future Study
FMTP
Flight Message Transfer Protocol
FOQA
Fligt Operations Quality Assurance
H-ARQ
Hybrid Automatic Repeat Request
H-NSP
Home NSP
HMI
Human Machine Interface
IP
Internet Protocol
IPsec
Internet Protocol security
ITU-R
International Telecommunication Union – Radio Communications
KEK
Key encryption Key
LOS
Line of Sight
MAC
Medium Access Control
MIMO
Multiple Input Multiple Output
MIP
Mobile IP
MLS
Microwave Landing System
MPLS
Multiprotocol Label Switching
MS
Mobile Station
© EUROCAE, 20XX
151
Term
Definition
MTOW
Maximum Take-off Weight
NAP
Network Access Provider
NET
Network Management Service
NLOS
Non Line of Sight
NSP
Network Service Provider
PENS
Pan European Network Services
PKM
Privacy Key Management Protocol
QoS
Quality of Service
RF
Radio Frequency
rtPS
Real Time Polling Service
RX
Receiver
SA
Security Association
SESAR
Single European Sky ATM Research Programme
SF
Service Flow
SJU
SESAR Joint Undertaking (Agency of the European Commission)
SJU Work Programme
The programme which addresses all activities of the SESAR Joint
Undertaking Agency.
SESAR Programme
The programme which defines the Research and Development activities
and Projects for the SJU.
SNR
Signal to Noise Ratio
SPR
Safety and Performance Requirements
SS
Subscriber Station
SWIM
System Wide Information Management
TEK
Traffic Encryption Key
TMA
Terminal Control Area
TX
Transmit
UGS
Unsolicited Grant Service
UL
Uplink
VLAN
Virtual Local Aera Network ( IEEE 802.1Q)
© EUROCAE, 20XX
152
Term
Definition
V-NSP
Visiting NSP
WA
Work Activity
WMF
WiMAX Forum
© EUROCAE, 20XX
153
Appendix C CAPACITY ANALYSIS
C.1 Capacity analysis per operational domain
This section presents a preliminary AeroMACS system performance analysis obtained by means of
simulation results. Coverage analysis
These simulations deals with AeroMACS coverage capabilities. Taking into account the PHY
performance (BER/PER curves) provided by SANDRA project and the Barajas path loss model outlined
in CHAPTER 12, 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.
C.1.1 Hypotheses made in simulations
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)14 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 the situation is similar to case 1 with the difference that the available resources in the
frame are less
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:
14
Hard constant bit rate means a CBR traffic which has also tight restrictions on jitter and latency
© EUROCAE, 20XX
154
SDU size
DL (Byte)
UL (Byte)
full load
1400 + 1100
674
1/5 full load
500
134
Table 34: 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
PTX,BS
23 dBm
Transmitted Power MS
PTX,SS
20 dBm
Cable loss BS
LBS
2 dB
Cable loss MS
LSS
2 dB
Max antenna gain BS
GBS
15 dBi
Max antenna gain MS
GSS
6 dBi
Sampling frequency
fs
5.6 MHz
Carrier frequency
fc
5.150 GHz
Noise figure
NF
8 dB
Implementation Loss
ImpLoss
5 dB
Used subcarriers
Nused
420(FL)/408(RL)
FFT dimension
NFFT
512
Table 35: PHY Layer parameters
With reference to the parameters of Table 35 the received signal power and the SNR are calculated
as:
Prx = Ptx − Ltx − Lrx + Gtx + Grx − L
SNR = Prx − N
where L is the channel propagation loss and N is the noise term equal to:
© EUROCAE, 20XX
155
N = −174 + 10 log10 (
fs
N FFT
N used ) + NF + ImpLoss
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 tables15 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 36 below, have been set in order to select the
modulation and coding scheme that guarantees the maximum throughput at each SNR16.
Adaptive MCS threshold (SNR in
dB)
LoS
NLoS
UL
20.7
24.1
DL
24.9
28.7
Table 36: 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
so-called Barajas’ path loss models have been used in these simulations as propagation loss:
32.44 + 20 log f c + 20 log d + X σ

L = −
d
32.44 + 20 log f c + 20 log d BP + 10γ log d + X σ

BP
d < d BP
d ≥ d BP
where:
•
15
16
dBP is the breakpoint distance
We are interested in results in 5MHz bandwidth, 1 slot FEC, CP=1/8 and linear channel interpolation
It is to be noted that these thresholds might be lower if using a CTC instead of a CC
© EUROCAE, 20XX
156
•
•
X σ is the slow fading term where σ is the slow fading standard deviation
γ is the path loss exponent for distances above dBP
•
fc is the carrier frequency in GHz
Default values for the above parameters are shown in Table 37:
Base Station
height
dBP
γ
σ
BS1-MR1
12m
144m
4.13
1.67
BS2-MR1
38m
292m
4.15
2.80
BS1-MR2
12m
52m
3.4
4.25
BS2-MR2
38m
141m
3.15
3.96
Table 37: 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 53Figure 49. 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 54Figure 50).
© EUROCAE, 20XX
157
Figure 5349: Mobile Route MR1
Figure 5450: 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 condition should 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 [9]
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).
Main ARQ parameters are set as in Table 38:
© EUROCAE, 20XX
158
Parameter
Value
ARQ Block Size [bytes]
64 UL / 256 DL
ARQ Window Size [ARQ blocks]
512
ARQ Block Lifetime [s]
6xRTI
ARQ Retry Timeout
0,1
(Retransmission Time Interval-RTI) [s]
Table 38: Main ARQ parameters
Additional secondary-level parameters are set as in Table 39:
Parameter
ACK Type 1,2
In-Order SDU Delivery
enabled
Rearrangements
enabled
Feedback Time Interval
Every 16 ARQ blocks
correctly received
Number of IE for each feedback message
1
Number of maps for each IE
1
Table 39: 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 40:
UPLINK
DOWNLINK
Q-PSK 1/2
16-QAM 1/2
Q-PSK 1/2
16-QAM 1/2
Size of PDU (slots)
68
68
219
219
Size of slot (bytes)
6
12
6
12
# ARQ blocks in PDU
6
12
5
10
© EUROCAE, 20XX
159
Size of ARQ block (bytes)
64
64
256
256
Table 40: Size of PDU and ARQ blocks
A description of the IP layer model can be found in [9].
C.1.2 Analysis of results
This section presents the coverage simulation results. 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.
© EUROCAE, 20XX
160
Figure 5551: 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 55Figure 51 shows ARQ type 2 assures better performance than ARQ type 1
in medium-high 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,
© EUROCAE, 20XX
161
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.
The performance behaviour 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 analysed 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.
© EUROCAE, 20XX
162
Figure 5652: Case 1: Throughput & Packet Loss in Los/NLos (DL)
Figure 5753: Case 2: Throughput & Packet Loss in Los/NLos (DL)
© EUROCAE, 20XX
163
Figure 5854: Case 3: Throughput & Packet Loss in Los/NLos (DL)
The general behaviour 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 58Figure 54 - NLos case - are artefacts 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.
C.2 Capacity analysis per airport
C.2.1 Operational concept
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 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
© EUROCAE, 20XX
164
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, AeroMACS Deployment Case StudiesAPPENDIX D: AeroMACS Deployment
Case Studies should be checked for this purpose instead.
C.2.2 Propagation and PHY/MAC layer model
It should be noted that this analysis is focused 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 [5]. This document
should be checked for more detail 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 4. 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
90
48.6
GROUND
40
21.6
RAMP
20
10.8
© EUROCAE, 20XX
165
Table 41: Arrival speeds
Departure
Speed [km/h]
Speed [knots]
RAMP
10 (in push-back)
5.4
20 (in taxiing)
10.8
GROUND
40
21.6
TOWER
90
48.6
Table 42: 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.
C.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 have 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, it should be noted that this is not always the pattern followed by
mainlines 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.
© EUROCAE, 20XX
166
Figure 5955: 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 should be 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 43. 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]
63.87
186.44
48.6
1800
2098.912
Distance [meters]
1596.7
2071.6
270
© EUROCAE, 20XX
167
Speed [km/h]
90
40
20
Table 43: Scenario 1 arrival trajectory times
According to the study of services description in CHAPTER 4 some of those services may 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
may 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 pass 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.
Aircraft->Base Station
Base Station->Aircraft
t[sec]
Service
Execution
order
0
OOOI
S1
AOC
0
NETKEEP
S1->P
NET
0
AUTOLAND-REG
S1-P
AOC
63
ACM
S2
ATC
ACM
S2->P
(periodic)
ATC
SURV
64
ToS
Service
NETKEEP
TOWER
65
ACL
S3
ATC
ACL
69
D-SIG
S4
ATC
D-SIG
69
D-TAXI
S4->P
ATC
D-TAXI
69
EFFU
S4->P
AOC
EFFU
© EUROCAE, 20XX
GROUND
168
69
FLT-JOURNAL
S4->P
AOC
69
TECHLOG
S4->P
AOC
69
CREW-TIME
S4->P
AOC
254
OOOI
S4->P
AOC
254
FOQA
S4->P
AOC
252
FLTLOG
S4->P
AOC
252
CABINLOG
S4->P
AOC
252
ETS-REPORT
S4->P
AOC
252
REFUEL
S4->P
AOC
S5
ATC
When
previous
services
have
finished ACM
TECHLOG
RAMP
ACM
Table 44: Chronological description of Scenario 1 arrival trajectory[schlereth14]
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).
© EUROCAE, 20XX
169
Figure 6056: 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
Departure
[seconds]
1800
Distance
[meters]
0
Pushback
RAMP
Taxiing
RAMP
GROUND
Taxiing
TOWER
Holding
Time
TOWER
47.88
141.3
325.98
53.6
300
133
785
3622
1340
© EUROCAE, 20XX
Total
departure
2668.76
170
Speed
[km/h]
0
10
20
40
90
Table 45: 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.
© EUROCAE, 20XX
171
© EUROCAE, 20XX
172
Table 46: 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].
C.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 have 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, it should be noted 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.
© EUROCAE, 20XX
173
Figure 6157: 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]
63.84
397.08
88.74
900
1449.66
meters
1596
4412
493
km/h
90
40
20
© EUROCAE, 20XX
174
Table 47: 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 10.000.000 Bytes.
Base Station>Aircraft
Aircraft->Base Station
t[seconds]
Service
Execution
order
ToS
Service
0 OOOI
S1
AOC
0 NETKEEP
S1->P
NET
0 AUTOLAND-REG
S1-P
AOC
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
64 EFFU
S4->P
AOC
EFFU
64 FLT-JOURNAL
S4->P
AOC
64 TECHLOG
S4->P
AOC
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
510 ETS-REPORT
S4->P
AOC
510 REFUEL
S4->P
AOC
© EUROCAE, 20XX
NETKEEP
TOWER
GROUND
TECHLOG
RAMP
175
When
previous
services
have
finished
ACM
S5
ATC
ACM
Table 48: 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.
© EUROCAE, 20XX
176
Figure 6258: 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
300
1813.94
Departure [segs]
900
39.6
70.74
450
53.6
Distance [meters]
0
110
393
5000
1340
Speed [km/h]
0
10
20
40
90
Table 49: Scenario 2 departure trajectory times
This list of services and time between them are the same that appears in 00[schlereth15], with the
exception of the following ones:
E-CHARTS size is now 2.000.000 Bytes
FOQA size is now 10.000.000 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. One should refer to SJU AOC study
[28] AOC Datalink Dimensioning Executive Summary, SESAR] for further details.
© EUROCAE, 20XX
177
© EUROCAE, 20XX
178
Table 50: 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].
C.2.5 QoS model
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 4 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
802.16 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
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
should never be 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 (see
also Table 7 in CHAPTER 4. For each QoS level, the relevant parameters used to define the polling
rate are indicated.
© EUROCAE, 20XX
179
CoS
Services included
SESAR
P15.2.7
CoS [6]
AeroMACS QoS
NET
NET services
DG-A
rtPS
Max latency = 1s
NETKEEP, NETCONN
Min throughput =32 kbps
ATS1
FPS by ADS-C
DB-D
rtPS
Max latency = 1.5 s
SURV
Min throughput = 32 kbps
ATS2
CIS (CPDLC)
DG-C
ACL, COTRAC, DCL, D-TAXI
DG-D
rtPS
FPS
FLIPCY, FLIPINT, PPD
ATS3
DCM
DG-C
nrtPS
DLL, ACM
DG-D
Min throughput =32 kbps
FIS
DG-F
D-OTIS, D-SIGMET, D-RVR, D-SIG
AVS
AOC1
AOC2
D-FLUP
AOCDLL, CABINLOG, FLTLOG, FLTPLAN,
LOADSHT, OOOI, TECHLOG, WXGRAPH,
WXRT, WXTEXT, BRFCD, DOOR,
ACLOG, AIRWORTH, AUTOLAND-REG,
BAGGAGE, NOTAM, CATERING, CREWL, CREW-RPS, CREW-BUL, CREW-REG,
CREW-TIME, FLOWCON, REFUEL,
HANDLING, LOADDOC, NOTOC,
PASSENGER, PREFLT-INS, TAKEOFFCALC
SWLOAD, UPLIB, EFF, EFFU, E-CHARTS,
FLTJOURNAL, FOQA, SWLOAD25,
SWCONF
DG-J
nrtPS
DG-K
Min throughput =64 kbps
(UL), 128 kbps (DL)
DG-K
BE
DG-L
Table 51: CoS classification for Airport Capacity Analysis
© EUROCAE, 20XX
180
C.2.6 Handover configuration
The handover configuration is similar to that in [5] sections 3.3 and 2.3.2.3.
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 52: 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.
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 may 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.
© EUROCAE, 20XX
181
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.
•
C.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 [6][6] 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 P15.2.7 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.
50 A/C, 10
VC
RAMP
arrival
Overall
Total [Kbps]
FL
137.53
RL
17355.42
© EUROCAE, 20XX
182
Table 53: RAMP Arrival Background traffic
50 A/C,
10 VC
Overall
RAMP
departure
Total
[Kbps]
FL
3106.42
RL
496.42
Table 54: RAMP Departure Background traffic
(50 A/C, 10
VC)
GROUND
arrival
Overall
Total
[Kbps]
FL
352.47
RL
3418.44
Table 55: GROUND arrival Background traffic
(50 A/C, 10
VC)
GROUND
departure
Overall
Total
[Kbps]
FL
180.93
RL
1807.70438
Table 56: GROUND Departure Background traffic
(50 A/C, 10
VC)
Overall
TOWER arrival
Total
[Kbps]
FL
1.08
RL
279.21
© EUROCAE, 20XX
183
Table 57: TOWER Arrival Background Traffic
(50 A/C, 10
VC)
Total
[Kbps]
Overall
TOWER
departure
FL
0.88
RL
596.12
Table 58: 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+04
6.637E+03 Kbps
DL
3.244E+03
5.354E+02 Kbps
UL
1.785E+04
6.101E+03 Kbps
Table 59: UL&DL Background Traffic
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 23 for 100 A/C scenario can be
© EUROCAE, 20XX
184
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 signalling. 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 P15.2.7 taking into account the realistic environment
and trajectories. The cell planning characteristics are summarized in the table below for both
iterations. Note that cells have been split in two independent plans: RAMP area is composed of BS
© EUROCAE, 20XX
185
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
6
15
6
23 dBm
1300
GND/TWR
3
8
5
23 dBm
2650
RAMP
10
20
6+1 **
23 dBm
1000
GND/TWR
3
8
5
23 dBm
1300
Iter 2
Table 60: 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 6, 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
© EUROCAE, 20XX
ATC3
AOC1
AOC2
186
UpLink
DownLink
53
56.33333
59.5
66
167.5
75
6.95
7.95
8.75
7.9
24.45
22
Table 61: 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
Arrival
Departure
Response Time [s]
Latency Requirement [s]
NETKEEP
0.91007
20
NETCONN
0.28186667
20
NETKEEP
0.15653333
20
Table 62: NET Services Response Time
ATC1 Service
Response Time [s]
Latency Requeriment [s]
Arrival
SURV
1.157
1.2
Departure
SURV
1.07415
1.2
Table 63: ATC1 Services Response Time
ATC2 Service
ACL
Response
Time [s]
Latency Requirement
[s]
0.65025
3
D-TAXI
0.2832
5
COTRAC (interactive)
0.6725
5
0.324
20
FLIPCY
0.194805
5
FLIPINT
0.206125
5
Arrival
DCL
Departure
© EUROCAE, 20XX
187
PPD
D-TAXI
ACL
0.195625
10
0.32
5
1.3826
3
Table 64: ATC2 Services Response Time
ATC3 Service
Arrival
Response Time [s]
Latency
Requeriment
[s]
ACM
0.975
3
D-SIG
0.71875
10
ACM
0.194375
3
DLL
0.1990775
3
0.414375
5
0.415
5
D-RVR
0.59575
3
D-SIG
0.611625
10
D-FLUP
0.21125
5
ACM
0.19125
3
ACM
0.195625
3
D-OTIS
D-SIGMET
Departure
Table 65: ATC3 Services Response Time
AOC1 Service
Arrival
Response Time [s]
OOOI
4.604125
© EUROCAE, 20XX
Latency
Requeriment
[s]
30
188
AUTOLAND-REG
1.39156
60
TECHLOG
0.393225
60
CREW-TIME
1.105475
60
0.64645
30
0.432945
60
0.1747875
60
0.15505
60
REFUEL
1.579625
30
AOCDLL
0.196125
60
0.34225
10
BRFCD
0.830625
30
ACLOG
2.6147875
30
0.1945
60
0.241
60
0.33
30
PASSENGER
0.9545
60
CREW-RPS
0.228
60
CREW-BUL
2.816625
60
CREW-REG
0.645125
60
FLTPLAN
0.367
30
NOTAM
0.5255
60
HANDLING
0.38725
60
CATERING
0.830625
60
BAGGAGE
7.536
20
0.374375
60
0.40875
20
OOOI
FLTLOG
CABINLOG
ETS-REPORT
LOADSHT
TECHLOG
AIRWORTH
WXTEXT
Departure
NOTOC
LOADDOC
© EUROCAE, 20XX
189
PREFLT-INS
0.195
120
DOOR
1.071
30
0.1955
60
TAKEOFF-CALC
0.980625
40
OOOI
9.519125
30
WXRT
1.016
30
OOOI
0.749
30
FLOWCON
Table 66: AOC1 Services Response Time
AOC2 Service
Response
Time [s]
EFFU
31.418
30
367.2365
60
1191.11875
1200
1064.785
60
426.626875
120
0.416125
120
109.4075
60
SWLOAD
26.429375
120
EFF/WXGRAPH/CREW-L
262.08875
60
EFFU
25.820625
30
FLT-JOURNAL
Arrival
Latency
Requeriment
[s]
FOQA
E-CHARTS
UPLIB
SWCONF
Departure SWLOAD25
Table 67: 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, it
© EUROCAE, 20XX
190
could be argued that, as critical applications, they should be however executed in the shortest
possible delay. It is proven that AeroMACS can enable instantaneous transmission for safety critical
ATC applications.
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 67Table 67).
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.
© EUROCAE, 20XX
191
Figure 6359: 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 minimised, 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
© EUROCAE, 20XX
AOC1
AOC2
192
UpLink
6.4
10.42625
9.9875
7.80625
24.4875
20.65
DownLink
6.45
9.764375
9.33125
8.289375
23.13125
20.125
Table 68: 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
Arrival
Response
Time [s]
Latency
Requirement [s]
NETKEEP
0.2998
20
NETCONN
0.156
20
NETKEEP
0.0494
20
Departure
Table 69: NET Services Response Time
ATC1 Service
Response
Time [s]
Latency
Requirement [s]
Arrival
SURV
0.066
1.2
Departure
SURV
0.061033333
1.2
Table 70: ATC1 Services Response Time
ATC2 Service
ACL
Response
Latency
Time [s] Requirement [s]
0.18
3
0.126
5
0.46732
5
0.815
20
Arrival
D-TAXI
COTRAC
Departure (interactive)
DCL
© EUROCAE, 20XX
193
FLIPCY
0.63
5
0.2225
5
PPD
0.25572
10
D-TAXI
0.55875
5
0.125
3
FLIPINT
ACL
Table 71: ATC2 Services Response
ATC3 Service
Arrival
Response
Time [s]
Latency
Requirement
[s]
ACM
0.086
3
D-SIG
0.372
10
ACM
0.34
3
0.09575
3
0.292
5
D-SIGMET
0.2278
5
D-RVR
2.1146
3
D-SIG
2.1132
10
D-FLUP
0.328
5
ACM
0.095
3
ACM
0.085
3
DLL
D-OTIS
Departure
Table 72: ATC3 Services Response
AOC1 Service
Arrival
Response
Time [s]
OOOI
0.76
© EUROCAE, 20XX
Latency
Requirement
[s]
30
194
AUTOLANDREG
0.1866
60
TECHLOG
0.0506
60
CREW-TIME
0.1196
60
OOOI
0.229
30
FLTLOG
0.294
60
CABINLOG
0.197
60
ETS-REPORT
0.187
60
REFUEL
1.78
30
AOCDLL
0.190333333
60
LOADSHT
2.544
10
BRFCD
0.795
30
ACLOG
3.368
30
TECHLOG
0.198
60
AIRWORTH
0.1876
60
WXTEXT
0.3802
30
PASSENGER
0.856
60
CREW-RPS
0.1932
60
CREW-BUL
2.508
60
CREW-REG
0.443
60
FLTPLAN
0.4356
30
NOTAM
0.5218
60
HANDLING
0.3574
60
CATERING
1.1524
60
BAGGAGE
10.232
20
NOTOC
0.5328
60
LOADDOC
0.5474
20
Departure
© EUROCAE, 20XX
195
PREFLT-INS
0.2352
120
DOOR
1.4232
30
FLOWCON
1.0894
60
15.5668
40
OOOI
0.566666667
30
WXRT
0.751
30
OOOI
0.75
30
TAKEOFF-CALC
Table 73: AOC1 Services Response Time
AOC2 Service
Latency
Response
Requirement
Time [s]
[s]
EFFU
Arrival
Departure
17.72
30
320
60
FOQA
189.8
1200
E-CHARTS
205.4
60
UPLIB
1060
120
SWCONF
71.6
120
110.464
60
163.3
120
325.286
60
86.222
30
FLT-JOURNAL
SWLOAD25
SWLOAD
EFF/WXGRAPH/CREWL
EFFU
Table 74: AOC2 Services Response Time
© EUROCAE, 20XX
196
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.
© EUROCAE, 20XX
197
Figure 6460: 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 show briefly main differences between the two iterations.
The table below summarises 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
were 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
3C.2.8 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.
© EUROCAE, 20XX
198
Iteration 1
RAMP
Iteration 2
15
20
8
8
Background traffic in DL
RAMP [Kbps]
UL
216.263333
162.1975
1190.12267
892.592
Background traffic in DL
GROUND&TOWER
[kbps]
UL
66.92
66.92
Number of BSs
GROUND&TOWER
762.684297 762.684297
Table 75: 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 differences 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
rtPS
rtPS
PR = 1 ms
PR = 5 ms
rtPS
rtPS
PR = 1 ms
PR = 7.813 ms
rtPS
rtPS
PR = 1 ms
PR = 9.375 ms
nrtPS
rtPS
PR = 1 ms
PR = 10.714 ms
nrtPS
nrtPS
PR = 1 ms
PR = 23.475 ms
BE
BE
ATC1
ATC2
ATC3
AOC1
AOC2
© EUROCAE, 20XX
199
Table 76: 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 should have. 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 dequeued 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.
NET
E2E Delay
[avg][ms]
ATC1
I1
I2
I1
UpLink
55.85
53
27.8
DownLink
8.765
6.95
8.255
ATC2
I2
I1
56.33333 22.75
7.95
9.735
ATC3
AOC1
AOC2
I2
I1
I2
I1
I2
I1
I2
59.5
480.5
66
179
167.5
80.5
75
8.75 10.583
7.9
38.2
24.45 19.795
Table 77: Results on packet latency for iteration 1 and iteration 2. Scenario 1
Iter 1
Iter 2
Service Name Simulation Simulation
Latency
Latency
GND Arr
ACL
4.475
0.65025
3
EFFU
111.6
31.418
30
939
367.2365
60
-
0.194375
3
ECHARTS
933.14
1064.785
60
UPLIB
375.66
426.626875
120
SWLOAD
123.8
26.429375
60
EFF
340.22
262.08875
60
FLT-JOURNAL
RMP Arr
RMP Dep
Required
Latency [s]
ACM
© EUROCAE, 20XX
22
200
GND Dep
TWR Dep
ACM
-
0.19125
ACL
-
1.3826
WXRT
-
1.016
3
30
Table 78: 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 should 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 it should be mentioned that Iteration 2 is just an example no how to improve
performance of AeroMACS, but it should not be considered as a standard setting. Optimisation 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.
It should be mentioned that Iteration 2 although providing better results should not be considered as
a minimum performance standard. It should only explain how improvement can be reached taking
into account specific environmental conditions.
© EUROCAE, 20XX
201
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 should 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.
Figure 6561: WiMAX DownLink Data Burst Usage. Red=Iteration2.
Blue=Iteration1.
© EUROCAE, 20XX
202
Figure 6662: 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 may 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 [5]. 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 [5].
MAC and PHY configuration is similar to that in ([5] section 3.3).
For sake of comparison, statistics similar to [5] have been analysed here.
© EUROCAE, 20XX
203
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.
Interruption Time17: 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 optimisation 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 [5]), 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 = -107.4
dBm. See AeroMACS Deployment Case StudiesAPPENDIX D: AeroMACS Deployment Case Studies
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
(initial)
402,84
266,73
7,16
8,68
1,44
322,54
194
3,6
7,77
0,84
1300 m
m
Table 79: 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
fulfilment 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 it should be
17
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.
© EUROCAE, 20XX
204
noted that 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 deployment to take care of this when planning the cell sitting in order to optimise handover
performance without largely increasing the density of BS.
© EUROCAE, 20XX
205
Appendix D AeroMACS Deployment Case Studies
D.1 PREAMBLE: 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.
Environmental Models
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
Parameters considered for simulations
General 802.16e parameters
•
•
Signal TDD 5MHz
PUSC segmentation 8
Note: Reflection is considered in the simulations if clutter data are available.
© EUROCAE, 20XX
206
Base Stations & Mobile stations
• General radio parameters found in Table 2 and Table 3 of [10],
Cable and implementation losses, Noise Factors, sub-channelization gain, …
•
Receiving threshold considered in the DL (to establish coverage maps): -92.4
dBm (which corresponds to MS sensitivity for QPSK ½ - CC in table 1 of [10])
•
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 [10])
• Specific parameters for coverage analysis:
BS sectorized antenna 15dBi : 110° Azimuth ; 7° Elevation, Downtilt = 4.5°
BS antenna height above ground = 38m
MS omnidirectionnal 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 6763: Horizontal and Vertical pattern for Base Stations (H: 3dB
beamwidth = 110°; V: 3dB beamwidth = 12° (tbc))
© EUROCAE, 20XX
207
D.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 C and C.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.
© EUROCAE, 20XX
208
Decimal values
BS1
R1
40,476480
-3,572308
BS2
R2
40,466718
-3,569294
BS3
R3
40,455423
-3,577383
BS4
R4
40,492297
-3,590215
BS5
R5
40,48609
-3,591489
BS6
R6
40,491917
-3,569112
BS7
R7
40,458611
-3,563703
BS8
R8
40,496012
-3,566917
BS9
R9
40,462429
-3,571356
BS10
R10
40,497028
-3,593169
BS1
G1
40.486958°
BS2
G2
40.473978°
BS3
G3
40.512807°
3.571404°
3.548213°
3.566953°
40° 29'
13,05''
40° 28'
26,32''
40° 30'
46.11"
Longitude
RAMP
GND
TWR
Hex values
Latitude
40° 28'
35.33"
40° 28'
0.18"
40º 27'
19.5228"
40º 29'
32.2692"
40º 29'
9.9234"
40º 29'
30.9012"
40º 27'
30.999"
40º 29'
45.6432"
40º 27'
44.7444"
40º 29'
49.3008"
Latitude
Longitude
-3° 34'
20.31"
-3° 34'
9.46"
-3º 34'
38.5788"
-3º 35'
24.774"
-3º 35'
29.3604"
-3º 34'
8.8032"
-3º 33'
49.3302"
-3º 34'
0.9012"
-3º 34'
16.8816"
-3º 35'
35.4084"
-3° 34'
17,05''
-3° 32'
53,57''
- 3° 34'
1.03"
Sectors
Sectors
s1
s2
s3
2
0°
120°
240°
2
0°
120°
240°
2
0°
120°
240°
2
0°
120°
240°
2
0°
120°
240°
3
0°
120°
240°
2
0°
120°
240°
3
0°
120°
240°
1
0°
165º
240°
1
0°
s1
120°
s2
240°
s3
3
0°
120°
240°
3
0°
120°
240°
2
0°
120°
240°
Table 80: 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 81: 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,
© EUROCAE, 20XX
209
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 Appendix C.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.
© EUROCAE, 20XX
210
Figure 6864: Proposed cell planning in Madrid Barajas
Below the optional cell planning proposed in Appendix C.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.
© EUROCAE, 20XX
211
© EUROCAE, 20XX
212
Figure 6965: 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 7066: Proposed cell planning in Madrid Barajas – RAMP only
© EUROCAE, 20XX
213
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
# channels
Data rate per domain
10
# BS
(sectors)
20
RAMP
6+2 *
3
8
5
19.6 – 71.9 Mbps (DL)
10.6 – 24.7 Mbps (UL)
7.9 – 28.8 Mbps (DL)
4.3 – 9.9 Mbps (UL)
GND/TWR
Avg BS
distance
810
Tx power
23 dBm
2650 **
Table 82: 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.
D.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 section Error! Reference source not found.11.1.2) 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.
© EUROCAE, 20XX
214
Figure 7167: 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 vehicules (with Hant=2m).
© EUROCAE, 20XX
215
Figure 7268: Global coverage (DL) in composite server display: Vehicules 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.
© EUROCAE, 20XX
216
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/2
1000
1260
1560
1950
2940
3600
5000
1000
1260
1560
1950
2940
3600
6000
Table 83: Calculation of cell range (DL in m) for each modulation scheme and
MS category (based on R1s1 coverage, near LOS direction)
© EUROCAE, 20XX
217
Figure 7369: 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.
© EUROCAE, 20XX
218
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/2
600
700
1800
*
*
800
1500
1800
**
**
Table 84: 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.
D.2.2 Radio coverage limited by the Uplink (UL)
Radio coverage is always in DL, but may appreciate limitation of the coverage by the MS ability to
communicate with BS. We could use the “reverse radio coverage” terminology, or “radio coverage
limited by the UL”.
Comparison between radio range (DL) and radio reverse range
The radio coverage that gives the area in which a connection may 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.
© EUROCAE, 20XX
219
Figure 7470: Global coverage (limited by UL) in composite server display:
Vehicules 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
© EUROCAE, 20XX
220
Figure 7571: R1s1 radio coverage (limited by UL), Aircrafts with Hant=10m
Coverage
convention
DL (from
previous tab)
DL limited by
the UL
(current case)
64QAM
3/4
64QAM
2/3
64QAM
1/2
16QAM
3/4
16QAM
1/2
QPSK
3/4
QPSK
1/2
1000
1260
1560
1950
2940
3600
6000
500
630
800
1000
1500
1900
3600
Table 85: 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 12.1.1.5.3 (NLOS
Munich, NLOS Barajas range estimation). Note that we are more in “near LOS case” than in a rigorous
NLOS case.
D.2.3 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 highest the building or available
infrastructure, the longer the reachable range
© EUROCAE, 20XX
221
•
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 9.2.1.48.2.4, we can assume that very large
airports will have similar 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.
© EUROCAE, 20XX
222
D.3 Case study 2: AeroMACS Deployment at Toulouse Airport
D.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 = 43° 38’ 22.5” N / 1° 22’ 40” E; Hant = 45 m
BSs2; 5110 MHz; GPS = 43° 38’ 22.5” N / 1° 22’ 40” E; Hant = 45 m
BSr1; 5130 MHz; GPS = 43° 37’ 22.5“ N / 1° 22’ 48“ 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 7672: Global coverage (DL) in composite server display: Vehicules 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)
© EUROCAE, 20XX
223
DL coverage limited by UL
Let’s consider now a coverage limited by the UL:
Figure 7773: Global coverage for aircrafts (Hant = 10m) in composite server
display: DL coverage(left) – DL coverage limited by UL (right)
We observe that the covering is achieved on the airport area in both case, but the highest modulation
(64QAM ¾) is not available for BS1 (sectors 1 and 2) because of the antennas heights and low
downtilt selected. If we increase the latter, we should increase the capacity available close to BS1
(see next figure), but reduce range.
© EUROCAE, 20XX
224
Figure 7874: 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
© EUROCAE, 20XX
225
Figure 7975: BS2 coverage - Aircrafts with Hant=10m, no reflections
considered DL (left) - DL limited by UL (right)
Coverage
convention
DL
DL limited by
the UL
64QAM
3/4
64QAM
2/3
64QAM
1/2
16QAM
3/4
16QAM
1/2
QPSK
3/4
QPSK
1/2
600
410
750
480
900
560
1000
650
1500
910
1800
1000
3000
1750
Table 86: BS2 Range for DL and DL limited by UL
D.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).
© EUROCAE, 20XX
226
Figure 8076: 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,
© EUROCAE, 20XX
227
-
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
Coordinates
Nominal Power
Frequency (Bandwidth)
Antenna Gain
Antenna 3dB Beam width (az)
Antenna 3dB Beam width (el)
Height above the Ground
Azimuth / North
Tilt (>0 Uptilt)
Azimuth Ground
43°36' 56.7725"N / 1°22' 31.5807"E
30W
5038.8MHz (CW for beam scanning) / (300kHz for DPSK)
27dBi (scanning) / 12.5 dBi (DPSK)
1.65° (scanning) / +/- 50° (DPSK)
0-20°
1.5 m
310°
0°
Name
Coordinates
Nominal Power
Frequency (Bandwidth)
Antenna Gain
Antenna 3dB Beam width (az)
Antenna 3dB Beam width (el)
Height above the Ground
Azimuth / North
Tilt (>0 Uptilt)
Elevation Ground
43°38' 33.1581"N / 1°20' 57.0729"E
30W
5038.8MHz (CW for beam scanning) / (300kHz for DPSK)
22dBi (scanning) / 12.5 dBi (DPSK)
1.3° (scanning) / +/- 50° (DPSK)
0-20°
2.5 m
310.00
0°
Table 87: Azimut 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.
© EUROCAE, 20XX
228
Figure 8177: Radiation patterns attached to each MLS transmitting station
Operational coverage
A/C landing
Figure 8278: Schematic representation of Tx MLS stations H patterns over
Toulouse airport
MLS receiving station Rx
© EUROCAE, 20XX
229
The MLS receiving radio station parameters as well as the radiation patterns of the antennas
connected are described below.
Name
Location
Coordinates
Frequency (Bandwidth)
Antenna Gain
Antenna 3dB Beam width (az)
Antenna 3dB Beam width (el)
Noise factor
KTBF
Height above the Ground
Azimuth / North
Tilt (>0 Uptilt)
Monitor angle Azimut
30m in front of AZ Tx station
43°36'57.5"N / 1°22'30.7"E
5038.8MHz (60 MHz) no selectivity
10dBi
+/- 50°
12°
11 dB
-108dBm
2m
310°
0°
Name
Location
Coordinates
Frequency (Bandwidth)
Antenna Gain
Antenna 3dB Beam width (az)
Antenna 3dB Beam width (el)
Noise factor
KTBF
Height above the Ground
Azimuth / North
Tilt (>0 Uptilt)
Monitor angle Site
30m in front of EL Tx station
43°38'32.3"N / 1°20'57.7"E
5038.8MHz (300kHz)
10dBi
+/- 50°
12°
11 dB
-108dBm
2m
310°
0°
Table 88: Azimut and Elevation Rx MLS station parameters
© EUROCAE, 20XX
230
Figure 8379: 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)
Tower
Tower
VHF
BSs1
BSs2
BSrs1
1.2204
1.2204
1.2248
43.38062
43.38062
43.37225
Site
Tower
Tower
VHF
Name
BSs1
BSs2
BSrs1
Azimuth
(°)
280
170
300
Tilt
(°)
-3
-3
-3
Nom.
Power
(W)
0.2
0.2
0.2
Antenna
(m)
45
45
30
Tx Ant.
Gain
(dBi)
15
15
15
Frequency
(MHz)
5038.8
5038.8
5038.8
Tx/Rx
Losses
(dB)
8
8
8
Bandwidth
(kHz)
5000
5000
5000
Rad.
Power
(W)
0.61098
0.61098
0.61098
KTBF
(dBm)
-96
-96
-96
Table 89: Parameters of AeroMACS stations
Figure 8480: Radiation patterns of antennas attached to AeroMACS stations
AeroMACS receiving stations
© EUROCAE, 20XX
231
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 value to consider that there is no significant interference is
between 1 and 3dB.
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 are given below.
© EUROCAE, 20XX
232
Wanted
station
(Rx)
Rx Az
MLS
Rx Az
MLS
Rx Az
MLS
Rx El
MLS
Rx El
MLS
Rx El
MLS
Rx
KTBF
(dBm)
-108
-108
-108
-108
-108
-108
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)
-103.58
5.76
5.76
12
5000
300
2205.3
-95.44
12.79
13.38
12
5000
300
2205.3
-95.58
12.67
15.94
12
5000
300
863.69
-114.03
0.97
0.97
12
5000
300
1694.96
-128.92
0.03
1
12
5000
300
1694.96
-122.95
0.14
1.1
12
5000
300
3286.27
Table 90: 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. This rejection might be provided by a combination of receiving filters and
frequency separation between the 2 systems. Using adjacent frequencies might be enough, but this
has to be confirmed by a further analysis requiring more detailed information about the MLS receivers
(rejections).
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 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)
Distanc
Tx-Rx
(m)
-96
Tx Az MLS
-56.99
39.01
39.01
0
300
5000
2234.67
-96
Tx El MLS
-81.96
14.21
39.03
0
300
5000
1720.27
-96
Tx Az MLS
-48.71
47.29
47.29
0
300
5000
2234.67
-96
Tx El MLS
-96.85
2.61
47.29
0
300
5000
1720.27
-96
Tx Az MLS
-48.94
47.06
47.06
0
300
5000
877.1
-96
Tx El MLS
-90.89
6.28
47.06
0
300
5000
3314.11
Table 91: 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. This rejection might be provided by a combination of
© EUROCAE, 20XX
233
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.
© EUROCAE, 20XX
234
Figure 8581: 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
Figure 8682: 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
receiving filters and frequency separation between the 2 systems. Using a frequency separation of 3
channels (N+/-3) might be enough, but this has to be confirmed by a further analysis requiring more
detailed information about the AeroMACS receivers (out of band characteristics).
© EUROCAE, 20XX
235
Conclusion
In order to be able to share the same band between the MLS service and the AeroMACS service, a
rejection of 70dB in the worst case should be applied on interferers. This rejection might be provided
by a combination of receiving filters and frequency separation between the 2 systems. Using a
frequency separation of 3 channels (N+/-3) might be enough, especially with the pessimistic approach
used in this study, but this has to be confirmed by a further analysis requiring more detailed
information about the MLS and AeroMACS receivers.
In case of Toulouse airport, the MLS center frequency (5038,8 MHz) is separated from 52 MHz from
the lower AeroMACS frequency (5091 MHz), which means a frequency separation of more than 10
channels. Thus we can conclude than no interference would occur between already deployed MLS
and future AeroMACS prototypes to deploy on Toulouse airport.
© EUROCAE, 20XX
236
Appendix E WG-82 MEMBERSHIP
Include a list of all WG members and contributors.
This is a mandatory annex.
Name
Company or Organisation
© EUROCAE, 20XX
237
IMPROVEMENT SUGGESTION FORM
This is a mandatory annex – do not change.
Name:
Company:
Address:
City:
State, Province:
Postal Code, Country:
Date:
Phone:
Fax:
Email:
Document : ED[ ]
[ ]
[ ]
/ DO-
Sec:
Page:
Documentation error (Format, punctuation, spelling)
Content error
Enhancement or refinement
Rationale (Describe the error or justification for enhancement):
Proposed change (Attach marked-up text or proposed rewrite):
Please provide any general comments for improvement of this document:
Return completed form to:
EUROCAE
Attention: Secretariat General
102 rue Etienne Dolet
92240 Malakoff - France
Email: [email protected]
Fax: +33 (0) 1 40 92 79 30
© EUROCAE, 20XX
Line: