aeromacs sarps validation report (appendix d to wp03.1) first... · validation which is the system...
TRANSCRIPT
CP/1 WP03.1 Appendix D [Type text] [Type text]
- 1 -
(49 pages) CP 1 WP03 1 Appendix D_AeroMAX Validation Report_revised.docx
FIRST MEETING OF THE COMMUNICATIONS PANEL (CP/1)
AeroMACS SARPS Validation Report (Appendix D to WP03.1)
Version 0.5a
Prepared by ACP WG/S and
presented by Chairperson of the ACP WG/S
SUMMARY
The draft validation report was presented during the 6th meeting of the ACP WG/S in
November 2014 and the meeting successfully finalized the “Validation Report” based
on ACP WG S/6 WP03R1. Furthermore, the ACP WG S members reached a
unanimous agreement and conclusion to submit this report with draft AeroMACS
SARPs (amendment proposal of Annex 10 Volume III) to the CP/1 for their further
consideration and approval.
This report includes inputs from the testing activities of the SESAR AeroMACS
projects (Airbus, SELEX, Thales, INDRA, DSNA, AENA, NATMIG and
EUROCONTROL), the SANDRA testing, the FAA and NASA testing, JCAB
CARATS projects (supported by the HITACHI testing and the ENRI R&D
activities).
This document provides a full list of AeroMACS SARPs requirements and for each
of them it summarises the validation activities undertaken. In addition the report
provides the references to other documents and reports which provide additional
information for the relevant validation activities.
International Civil Aviation Organization
WORKING PAPER
CP/1 WP03.1
Appendix D
Based on WG-S/6
WP03R4(11/11/2014)
CP/1 WP03.1 Appendix D [Type text] [Type text]
- 2 -
CP/1 WP 03
APPENDIX D
VALIDATION REPROT
CP/1 WP03.1 Appendix D [Type text] [Type text]
- 3 -
FOREWORD
The AeroMACS SARPs proposal has been produced by the Aeronautical Communications
Panel (ACP) Surface Datalink Working Group (WGS) which consists of members nominated
by States and International Organization (Japan, United States and Eurocontrol) and their
advisors. Furthermore, in order to validate draft SARPs, ACP WGS dedicated substantial
effort to produce this validation report which includes inputs from the testing activities of the
SESAR AeroMACS projects (Airbus, SELEX, Thales, INDRA, DSNA, AENA, NATMIG
and EUROCONTROL), the SANDRA testing, the FAA and NASA testing, JCAB CARATS
projects (supported by the HITACHI testing and the ENRI R&D activities).
1. AEROMACS VALIDATION: INTRODUCTION AND METHODOLOGY
1.1 The AeroMACS data link is the customisation of a commercial 4G system: WiMAX, which
is based on the IEEE 802.16 standard. WiMAX is a mature and validated system that has
been in operation and supporting mobile communications in various countries for many years
now.
1.2 The WIMAX (and the 802.16 standard) provide a multitude of capabilities, and they offer the
possibility for selected features to be supported only in some networks/implementations.
However as interoperability is a critical requirement for aviation, the aviation community has
agreed to the “AeroMACS profile” jointly developed in EUROCAE and RTCA in order to
facilitate interoperability. The AeroMACS profile is specifying the minimum set of required
WiMAX features that need to be implemented in all AeroMACS implementations in order to
support interoperability in a regional and global level for aviation.
1.3 Therefore, as AeroMACS is based on a system (WiMAX) already in operation, the validation
of AeroMACS SARPs focuses in the specific selected features for the AeroMACS profile,
and is not covering the general validation of the WiMAX (and 802.16 standard features.
1.4 Following the discussions in the 5th WGS meeting as well as in other WGS webex meetings,
this document identifies the validation activity undertaken for each of the AeroMACS
SARPs, and provides a summary of the validation conclusions that can be drawn based on
referenced validation activity.
1.5 WGS has agreed that the AeroMACS SARPs Validation Report (VR) will contain mainly
four parts (sections) as described below:
1) Introduction identifying the validation methods used and providing information for the
contributing exercises
2) A table providing the following information:
SARPs numbering and corresponding SARPs text
Validation method(s) applied for each of the SARPs
Identification of the contributor(s) contributing to the validation of the specific SARP
Summary of validation result with references as required to Appendices and other
documents with detailed validation information.
CP/1 WP03.1 Appendix D [Type text] [Type text]
- 4 -
3) Conclusions of the overall AeroMACS validation based on the validation results reported
in point 2 above and recommendations to WGS as appropriate,
4) Appendices as required with the detailed validation information for the different SARPs
(as referenced in point 2 above).
1.6 The sections 1, 2, 3, 4 and 5 of this report cover the point one above, section 6 covers the
point two above and section 7 covers the point three above. In addition, Section 8 identifies
the used references and the appendices of this report cover the point four above.
1.7 WGS also agreed that it would be beneficial to provide a traceability of the various SARPs
requirements to actual operational requirements and/or identify the rationale for the SARPs
requirements.
1.8 For the validation of AeroMACS, WGS agreed to use the same approach as the UAT
validation which is the system most recently introduced in Annex 10. In particular, the
validation report of UAT ([1]) identifies 10 validation methods:
IA Inspection using common
knowledge
IT Integration Test
IB Inspection through use of prior
analysis/documents
FT Flight Test
A Analysis MN Monitoring
S Simulation MD Manufacturer’s Data
UT Unit Test NVR No Validation Required (may
include editorial inspection
Table 1a: UAT Validation Methods
1.9 WGS agreed to use in general the same validation methods as in Table 1 above and modify
them as required (for example no FT will be planned). In addition, in the end there was no
MN validation activity performed. Therefore, based on the actual validation activities
undertaken for AeroMACS, the table below identifies the validation methods used for
AeroMACS.
IA Inspection using common
knowledge
UT Unit Test
IB Inspection through use of prior
analysis/documents
IT Integration Test
A Analysis MD Manufacturer’s Data
S Simulation NVR No Validation Required (may
include editorial inspection
Table 1b: AeroMACS Validation Methods
1.10 Overall there were 5 independent testing activities, which have produced material to support
the validation of the AeroMACS SARPs: SESAR testing, SANDRA testing, FAA/NASA
testing, and JCAB CARATS projects (supported by ENRI testing and HITACHI testing).
Sections 2, 3, 4 and 5 below provide a brief introduction to these testing exercises.
CP/1 WP03.1 Appendix D [Type text] [Type text]
- 5 -
2. AEROMACS TESTING IN SESAR AND SANDRA
2.1 In Europe, in the context of the SESAR Programme, there were two projects supporting the
development of AeroMACS. Project P15.02.07 addressed the overall system aspects and
focused on the ground system side and project P9.16 addressed the airborne side. In addition
in Europe, AeroMACS activities were also undertaken in the context of the EU FP7 project
SANDRA (subproject activities SP6 and SP7). The SESAR and SANDRA activities were
closely coordinated.
2.2 In the context of the SESAR projects there were two prototypes developed by SELEX and
THALES. In addition Airbus and DSNA actively participated in the extensive SESAR testing
activities covering:
Laboratory tests: measuring in a lab environment the performance aspects of the
AeroMACS profile, as well as investigating interoperability between mobile and base
station units as well as between the different manufacturers.
Field tests: tests in the Toulouse (TLS) airport environment addressing both the ground
and the aircraft segment of the AeroMACS data link.
2.3 For the AeroMACS prototypes, SELEX and THALES built different prototypes of both the
Base Station (BS) and the Mobile Station (MS) able to operate in the aeronautical C-Band
(5091 – 5150 MHz). Additional information for the SELEX and THALES prototypes is
provided in [2].
2.4 The table below gives an overview of focus areas and main partners involved in the lab and
field tests within projects P15.02.07 and P9.16:
P 15.02.07 P 9.16
Lab.
Test
THALES, THALES Lab. SELEX ES, SELEX Lab.
SELEX ES, SELEX Lab.
Field test
THALES + DSNA SELEX ES + Airbus
Toulouse airport Toulouse airport
Focus on ground component of
AeroMACS
Focus on airborne component of
AeroMACS
Table 2: SESAR AeroMACS testing organization
2.5 Overall the P15.02.07 and P9.16 testing activities covered:
Measurement of AeroMACS performance by testing the BS with the MS originating from
the same supplier in laboratories (controlled environment),
Interoperability evaluation of the AeroMACS prototypes, by cross-testing of BS with MS
from different suppliers in laboratories,
AeroMACS assessment, by carrying out tests in a real airport environment (taking place
in the Toulouse Airport and by installing the MS in cars and in an airplane and the BS on
fixed locations).
2.6 Additional information for the SESAR testing set up, the testing objectives, the test cases and
the testing outcome is provided in the SESAR deliverables [2a], [2b], [3a], [3b], [4], and [5].
CP/1 WP03.1 Appendix D [Type text] [Type text]
- 6 -
2.7 The two SESAR projects are scheduled to be completed by February 2015. The last testing
activities took place in October 2014 and the final reports are still under final review and
approval.
2.8 In the context of the SANDRA, the objectives of the AeroMACS testing activities were to
demonstrate that: 1) AeroMACS could be integrated within the new multi-link IPv6 A/G
Mobile Network defined in SANDRA; 2) AeroMACS could interoperate with future
Integrated Modular Radio architectures; and 3) the profile defined is compatible with support
of multiple type of communication services (ATC, AOC, …).
2.9 Analysis has been conducted on WiMAX Characteristics and Airport modeling, with the goal
of identifying the features to be included in the AeroMACS System Profile, in strict
coordination with the SESAR 15.2.7 Project. Deployment studies have been performed
together with studies on possible extension of AeroMACS use above the parking and taxing
flight phases. Simulations have been performed in order to evaluate deployment in a wide
range of practical airport scenarios (different speeds/doppler, different cases of Multipath
Fading depending on the specific simulated area (RAMP, GROUND, TOWER), shadowing,
etc.).
2.10 AeroMACS Base Stations (BS) and Mobile Stations (MS) prototypes commonly developed
for SESAR and SANDRA have been used in the SANDRA testing. Prototype integration and
lab testing activities performed within Selex ES included: MAC layer software testing,
integration and testing of the networking solution (ASN-GW, Hand-over, Security features),
Radio Head Performances, Physical layer feature testing and mobility tests.
2.11 AeroMACS airborne and ground systems were integrated in SANDRA overall Mobile IPv6
multi-link test-bed in Oberpfaffenhofen.
2.12 Field Trials were executed in Oberpfaffenhofen Airport (Car Tests and Flight Tests, under
SP7) and Toulouse Airport (AeroMACS Point-to-point link tests, under SP6). In addition
SANDRA Flight Trials have been performed in Oberpfaffenhofen airport.
2.13 The SANDRA AeroMACS activities have been undertaken with the participation of Selex
ES, SITA, DLR, Triagnosys, Intecs, Altys, Alenia Aeronautica, Radiolabs, University of
Salzburg and University of Pisa.
2.14 The SANDRA project concluded in end of 2013 and additional information on the SANDRA
testing set up, the testing objectives, the test cases and the testing outcome is provided in the
SANDRA deliverables [6a] and [6b].
3. FAA/NASA AEROMACS TESTING
3.1 NASA Glenn Research Center (GRC) in collaboration with Federal Aviation Administration
and industry partners developed the AeroMACS test bed in Cleveland, Ohio. The test bed
facility is hosted at Cleveland Hopkins Airport (CLE) and the NASA GRC campus. NASA
GRC test bed infrastructure includes two base station locations, seven subscriber station
locations, one mobile station, a control room and a microwave communications link that
connects the control room to base stations. ITT Exelis was contracted to provide technical
and installation support. The following section provides a description of AeroMACS testing
accomplished at NASA test bed facility.
CP/1 WP03.1 Appendix D [Type text] [Type text]
- 7 -
3.2 Testing activities covered by NASA and FAA in Cleveland test bed facility included:
Network entry with authentication and data transfer - The purpose of this test was to
verify that a service flow is successfully created when an SS enters the network and that
the service flow is removed completely when the SS exits the network.
QPSK throughput, UL and DL - This test verified baseline maximum throughput from
LOS within the sector using QPSK rate 1/2 coded modulation.
16-QAM throughput, UL and DL - This test case verified the baseline maximum
throughput from LOS within the sector using 16QAM rate 1/2 coded modulation.
64-QAM throughput, DL - The purpose of this test was to verify the baseline maximum
throughput from LOS within the sector using 64QAM rate 1/2 coded modulation on DL.
Sector capacity with multiple SSs - Demonstrate the operation of multiple SSs within a
sector to test the maximum throughput capacity of a single sector and the capability of a
sector to handle terminal “network entries” in congested conditions.
Multiple BTS throughput - Demonstrate the operation of multiple SSs across multiple
sectors to test the maximum throughput capacity of multiple BTSs and the capability of
multiple sectors to handle terminal “network entries” in congested conditions.
QoS—DL non-real-time (nRT) prioritization over best effort with two terminals - Data
prioritization test to verify the handling of data on the DL classified as high priority.
QoS—UL nRT prioritization over best effort with two terminals - Data prioritization test
to verify handling of data on UL classified as high priority. It verified that an nRT
protocol data stream is prioritized over a best-effort data stream when both data types that
are sent originate from the same SS.
Intra-sector mobility with link adaptation - Test ability to maintain a User Datagram
Protocol (UDP) traffic stream while mobile in a single BTS sector with link adaptation
enabled. Demonstrate network’s ability to switch between QPSK, 16QAM, and
64QAM using AMC.
Inter-sector mobility with link adaptation - Evaluate BTS handover ability for a mobile
SS that moves over multiple sectors and the ability to maintain a UDP traffic stream
while moving about multiple sectors with link adaptation enabled. Test network’s ability
to switch between QPSK, 16QAM, and 64QAM using AMC.
Long-term stability test - This was an extended-operation test to verify network stability
by periodically sending and receiving data bursts.
4. HITACHI AEROMACS TESTING
4.1 Hitachi has been contributing to ACP WG-S as a technical liaison through WiMAX Forum
and it is requested by WG-S to assist SARPS validation by using its AeroMACS system in
laboratory testing measuring the performance aspects of the AeroMACS profile, investigating
interoperability between mobile and base station units as well as between multiple vendors.
4.2 Laboratory tests
Hitachi AeroMACS prototype system consists of BS, ASN-GW, AAA, HA, and BS-
OMC.
Hitachi validated the protocol and sequence using network monitor, wireless monitor, and
logging functions to check R1 and R6 message.
CP/1 WP03.1 Appendix D [Type text] [Type text]
- 8 -
BS was developed by Hitachi and MS was developed by multi vendors. Hitachi
AeroMACS prototype has been used in the Hitachi testing. Prototype integration and lab
testing activities include: MAC layer software testing, integration and testing of the
networking solution (ASN-GW, Hand-over, Security features), Radio Head
Performances, Physical layer feature testing and mobility tests.
4.3 Field tests
Collaborative experiments with NASA
Hitachi validated the field trial test items with NASA at CLE airport.
Evaluation facilities to ENRI
ENRI utilized Hitachi's AeroMACS systems as the evaluation facility and several
demonstrations for the WiMAX aviation summit 2014 in Sendai.
5. ENRI AEROMACS TESTING
5.1 ENRI has contributed to SARPS validation by using AeroMACS prototype, which was
evaluated in laboratory and ENRI’s Iwanuma Brunch at Sendai Airport.
5.2 The validation results provided by ENRI included:
SARPs 7.3.6 Point-to point communication
ENRI conducted several tests and demonstration related to section 7.3.6 of SARPs. The
results of those tests are provided in ACP WG S/6 WP04[10].
SARPs 7.3.8 IP packet data service
ENRI conducted several tests and demonstration related to section 7.3.8 of SARPs. The
results of those tests are provided in ACP WG S/6 WP04[10].
SARPs 7.3.10 recommendation voice services:
ENRI conducted bidirectional communication test and demonstration. The results of
those tests are provided in ACP WG S/6 WP04[10].
SARPs 7.3.11 multiple service flow
ENRI conducted multiple flow test and demonstration. The results of those tests are
provided in ACP WG S/6 WP04[10].
SARPs 7.4.1.1 TDD mode
ENRI conducted related several tests and demonstration related to section 3.1.1 of
SARPs. The results of those tests are provided in ACP WG S/6 WP04[10].
SARPs 7.4.1.2 5MHz channel bandwidth:
ENRI conducted several tests and demonstration related to section 7.4.1.2 of SARPs. The
results of those tests are provided in EUROCAE WG82 May meeting, WP Preliminary
evaluation for AeroMACS prototype Mobile Station [11].
SARPs 7.6.2 Notification of the status communication:
ENRI confirmed that several LED indicated the status of communication such as Power,
Data, RSSI on the top of MSs. The results are provided in ACP WG S/6 WP04[10].
CP/1 WP03.1 Appendix D [Type text] [Type text]
- 9 -
6. AEROMACS SARPS VALIDATION: CONTRIBUTIONS TABLE
6.1 The table below summarises the outcome of the AeroMACS SARPS validation activities. For
each of the SARP, the table provides the SARP number and text, identifies the validation
method(s) applied for this SARP, identifies who has performed relevant validation activities
and finally provides a summary of validation result with references as required to Appendices
and other documents providing detailed information on the outcome of the validation work.
CP/1 WP03.1 Appendix D [Type text] [Type text]
10
AeroMACS SARPS Validation: Methods used, Contributors and Summary Outcome
AeroMACS SARPs:
Numbering and Text
Validation
method used
Validation
contributing
Partners
Validation conclusions/summary
7.1 DEFINITIONS NVR
7.2 INTRODUCTION NVR
7.3 GENERAL NVR
7.3.1 AeroMACS shall conform to the
requirements of this and the
following chapters.
IA WG-S IA:
Inspection only. Requirement is only referencing other requirements. It is
validated through the validation of the actual SARPs requirements.
7.3.2 AeroMACS shall only transmit
when on the surface of an
aerodrome.
IB, IT SESAR This restriction aims to demonstrate compliance with the ITU assumptions and
analysis for the allocation of the AeroMACS frequency band in WRC 2007.
This is a requirement on the avionics equipment and it is usually enabled with a
weight on wheels switch.
IB:
The EUROCAE AeroMACS draft MASPS include this requirement in sections
5.1 and 5.3. Furthermore the AeroMACS MOPS are expected to include this
requirement in version 2 which is planned for 2015. Finally the realisation of
this requirement is also part of the avionics standard (ARINC spec) which is
under development in AEEC and is expected to include this requirement.
IT:
The current prototypes (developed to support validation of standards) have not
fully implemented this requirement. In SESAR P9.16 the SELEX prototype
implements a kind of solution by forcing the shutdown of RF transmission on
the condition given by a discrete input. The working of this solution has been
verified.
Airbus has also confirmed that such requirement is achievable on A/C, by
similarity with existing systems (e.g. WIFI, Cellular Airborne radio) that obey
to the same rule.
CP/1 WP03.1 Appendix D [Type text] [Type text]
- 11 -
AeroMACS SARPs:
Numbering and Text
Validation
method used
Validation
contributing
Partners
Validation conclusions/summary
7.3.3 AeroMACS shall support
aeronautical mobile (route)
service (AM(R) S)
communications.
IB, A, S, IT SESAR
SANDRA
This requirement is derived from the ITU conditions for the allocation of the
AeroMACS frequency band in WRC 2007.
IB:
The EUROCAE/RTCA AeroMACS MOPS and the EUROCAE draft MASPS
include this requirement in sections 1.3 and 2.2.1, and 11.1 respectively.
Considering the frequency band of operations, AeroMACS will be supporting
ATM, AOC and Airport communications impacting the safety and regularity of
flights.
A and S:
In SESAR there were analysis and simulations of the capacity of the
AeroMACS data link to support the communication exchanges of such
applications. The SESAR Deliverable P15.02.07 D04 AeroMACS deployment
and Integration Analysis provides in section 3 the outcome of these simulations
and analysis for different size of airports ranging from very small airports (3
a/c movements per hours) to very busy ones (more than 100 a/c movements per
hour).
IT:
In the SANDRA project there has been integrated testing of ATN applications.
These tests are described in the SANDRA deliverable D7.6.1 Evaluation
Results, Assessments and Recommendations, section 2.1.3. The SANDRA
testing demonstrates the feasibility of supporting air-ground ATN applications
(CM and PM-CPDLC) over IP data links (BGAN and AeroMACS were used).
In the tests CM was successfully established and CPDLC messages
successfully routed over the IP path enabled by the AeroMACS data link.
7.3.4 AeroMACS shall process
messages according to their
associated priority.
IB, A, S, UT SESAR
NASA
Hitachi
IB:
The draft AeroMACS MASPS in sections 4.3 and 7.2 cover the AeroMACS
mechanisms for handling priority. In addition a section in the AeroMACS
Technical Manual will also cover the AeroMACS mechanisms to meet the QoS
(including priority) of the supported applications based on the
EUROCONTROL/AT4W Technical Note 14 (Service Flow Management and
QoS Management in AeroMACS).
CP/1 WP03.1 Appendix D [Type text] [Type text]
- 12 -
AeroMACS SARPs:
Numbering and Text
Validation
method used
Validation
contributing
Partners
Validation conclusions/summary
A and S:
In SESAR, there were analysis and simulations of the ability of the AeroMACS
data link to support multiple classes of service and these are reported in the
SESAR Deliverable P15.02.07 D04 AeroMACS deployment and Integration
Analysis in section 3.3.3 and the draft AeroMACS MASPS in section 12.1.2.2.
UT:
In SESAR there were also unit tests demonstrating the handling of messages
according to priority and this is covered in the SESAR Deliverables P15.02.07
D10 Verification Plan and Report – Phase 2 (section A1.3) and P15.02.07
D06.2 Verification Report –Phase 1 (section A.2) and P9.16 ACP-WG-S/6
WP06 (sections 5.4 and 6.1.2.5).
NASA tested prioritization utilizing VLAN and is covered in document
NASA/CR—2011-216997/VOL2.
Hitachi and NASA testing in Cleveland validated the requirements for service
flow and prioritization. The measured results of this testing are provided in
ACP-WG-S/6 WP09 [14] , Section 2.3.
7.3.5 AeroMACS shall support
multiple levels of message
priority.
IB, UT SESAR
NASA
Hitachi
IB:
AeroMACS can support different levels of message priorities in a flexible
manner. Based on the analysis in SESAR, a 6 level priority scheme has been
defined to satisfy the envisaged applications QoS requirements (see SESAR
Deliverable P15.02.07 D04, section 3.3.3) and is depicted in the draft MASPS
sections 4.3 and 7.2. A proposal to realise the envisaged priorities and QoS
requirements will be included in the AeroMACS Technical Manual (see
above).
UT:
In SESAR there were also unit tests demonstrating the handling of messages
according to priority (two service flows of BE with different maximum
sustained traffic rate values) .
CP/1 WP03.1 Appendix D [Type text] [Type text]
- 13 -
AeroMACS SARPs:
Numbering and Text
Validation
method used
Validation
contributing
Partners
Validation conclusions/summary
This is covered in the SESAR Deliverables P15.02.07 D10 Verification Plan
and Report – Phase 2 (section A1.3) and P15.02.07 D06.2 Verification Report
– Phase 1 (sections A.2 and A.8) and P9.16 ACP-WG-S/6 WP06 [5] (section
5.4).
NASA conducted tests addressing quality of service and results are available in
NASA/CR—2011-216997/VOL2 [12].
Hitachi and NASA testing in Cleveland validated the requirements for multiple
priorities. The measured results of this testing are provided in ACP-WG-
S/6WP09 [14] , Section 2.3.
7.3.6 AeroMACS shall support point to
point communication.
S, UT SESAR
NASA
Hitachi
ENRI
S:
In SESAR, there were simulations of the capacity of the AeroMACS data link
to support various point to point communications. The outcome of these
simulations is reported in the SESAR Deliverable P15.02.07 D03.1
AeroMACS profile evaluation and validation in sections 2, 3 and 4 and the
draft AeroMACS MASPS in sections 12.1.2.1 and 12.1.2.2.
UT:
In SESAR there were also numerous unit tests demonstrating the transmissions
of point to point communications. The outcome of these tests is covered in the
SESAR Deliverables 15.02.07 D10 Verification Plan and Report – Phase 2
(section A1.3, A2.1) and P15.02.07 D06.2 Verification Report – Phase 1
(sections A.2 and A.8) and P9.16 ACP-WG-S/6 WP06 [5] (sections 5.4, 6.1.5.3
and 6.2.2).
NASA completed point-to-point communications testing utilizing different
system configurations. Information can be found in NASA/CR—2011-
216997/VOL2 [12]
Hitachi and NASA testing in Cleveland validated the requirements for point to
point. The measured results of this testing are provided in ACP-WG-S/6
WP09[14], Section 2.2.
ENRI validated the point-to-point communications. The results of this testing
and demonstration are provided in Section 3.2 of ACP-WG-S/6 WP04 [10].
CP/1 WP03.1 Appendix D [Type text] [Type text]
- 14 -
AeroMACS SARPs:
Numbering and Text
Validation
method used
Validation
contributing
Partners
Validation conclusions/summary
7.3.7 AeroMACS shall support
multicast and broadcast
communication services.
IB SESAR The AeroMACS profile specifies the use of the Multicast Traffic Connections
as the mechanism to support multicast and broadcast communications. A
proposal has been developed in the context of the SESAR work
(EUROCONTROL/AT4W Technical Note 18 Multicast and Broadcast
Services on AeroMACS) to describe how to implement multicast and broadcast
services as multiple unicast communications and in addition to provide test
cases to support a revision of the AeroMACS MOPS in the future. The material
of this technical note will be the basis for a dedicated section in the AeroMACS
Technical Manual.
7.3.8 AeroMACS shall support internet
protocol (IP) packet data services.
IB, UT, IT SESAR
Hitachi
SANDRA
NASA
ENRI
IB:
The AeroMACS profile requires support for IPv4 and IPv6, IPv6 is currently
not certifiable by WMF as there are no test cases to support the WIMAX
Forum certification of this feature. For this reason, in the context of the SESAR
work a proposal has been developed (EUROCONTROL/AT4W Technical
Note 17 IPv6 and Ethernet CS for AeroMACS) to describe the corresponding
test cases. This material will be included in a future version of the AeroMACS
MOPS and may also be included in the AeroMACS Technical Manual.
UT:
In SESAR there was extensive testing in the SELEX and Thales labs to
demonstrate the transmissions of IPv4 data packets. The outcome of these tests
is covered in the SESAR Deliverables P15.02.07 D06.2 AeroMACS
Verification Report – Phase 1(e.g. see sections A.2. and A.8) and P15.02.07
D10 AeroMACS Verification Plan and Report – Phase 2 (e.g. see section A1.3
and A2.1) and P9.16 ACP-WG-S/6 WP06 [5] (sections 5.4, 6.1.5.6 and
6.1.5.9).
Hitachi and NASA testing in Cleveland validated the requirements for IP data
service. The measured results of this testing are provided in ACP-WG-S/6
WP09, Section 2.2.
CP/1 WP03.1 Appendix D [Type text] [Type text]
- 15 -
AeroMACS SARPs:
Numbering and Text
Validation
method used
Validation
contributing
Partners
Validation conclusions/summary
IT:
In addition in the context of the SANDRA activities there has also been
integrated testing to demonstrate the transmission of the IP traffic and
establishment of an end-to-end IP connectivity and this is covered in the
SANDRA deliverable D6.5.1 Report on Testing (see section 4.1 Basic
functionality test). The test results show a successful establishment of IP
connectivity, the MS acquires IPv4 address from the DHCP server and is able
to authenticate itself in the network via the ASN-GW.
NASA tested IPv4 transport capabilities and outcomes are covered in
NASA/CR—2011-216997/VOL2 [12]
ENRI validated the IP packet data services. The testing and demonstrating are
provided in ACP-WG-S/6 WP04R3, Section 3.
7.3.9 AeroMACS shall provide
mechanisms to transport
ATN/IPS and ATN/OSI (over IP)
based messaging.
IB, IT SANDRA IB:
AeroMACS is designed to be a data link capable to support ATN services, as is
mentioned in the draft MASPS section 4.3 and provides a recommended
mapping of ICAO ATN services into AeroMACS Classes of Service. In order
to support both short-term and long-term evolution roadmaps, AeroMACS
should thus support physical and link layer functions to support both current
ATN/OSI and future ATN/IPS networks.
IT:
In the context of the SANDRA activities there was testing of the transport of
ATN/OSI traffic over AeroMACS. This is described in the SANDRA
deliverable D7.6.1 SANDRA evaluation results – Assessment and
recommendations (see section 2.1.3 and 2.1.4). The SANDRA report indicates
how traffic from ATN/OSI CPDLC was exchanged during a handover between
VDLM2 and AeroMACS.
CP/1 WP03.1 Appendix D [Type text] [Type text]
- 16 -
AeroMACS SARPs:
Numbering and Text
Validation
method used
Validation
contributing
Partners
Validation conclusions/summary
7.3.10 Recommendation.—AeroMACS
should support voice services.
Note.- Manual on the Aeronautical
Telecommunication Network (ATN)
using Internet Protocol Suite (IPS)
Standards and Protocols (Doc 9896)
provide information on voice service
over IP .
IB, A, IT FAA
SANDRA
NASA
Hitachi
ENRI
IB:
While the focus of the AeroMACS development for aviation is on data link, the
WIMAX technology is commercially used to support digital voice
communications (VoIP). Therefore it is expected that AeroMACS will also
support voice services as is indicated in the draft MASPS section 5.
A:
FAA provided in WGS an analysis (ACP-WG-S-6 IP02) of the AeroMACS
capabilities with respect to implementing voice services based on prior testing
results of data packet performance characteristics obtained at NASA-Exelis
Cleveland AeroMACS test bed located at the Cleveland Hopkins Airport. The
analysis focused on the results of the testing of the jitter and dropped packet
rate that are critical in the support of VoIP services. The Analysis concludes
that voice could be supported by AeroMACS.
IT:
Voice over AeroMACS was actually tested in the SANDRA project which
produced MOS estimates for the voice quality. The outcome of the SANDRA
testing is described the SANDRA deliverable D6.5.1 Report on testing (see
section 4.3) which shows as a final step that a working VoIP session with 32
kbps and 64 kbps codecs was successfully established and showed good call
quality results.
A VoIP capability (skype) was successfully tested in the AeroMACS
demonstration day organised by NASA and Hitachi in September 2014 in the
NASA AeroMACS test bed in the Cleveland Hopkins Airport. Test
information can be found in ACP-WG-S-6 WP09 titled “Field Trials and
Results” [14].
Hitachi and NASA testing in Cleveland validated the requirements for VoIP
communications. The results of this testing are provided in ACP-WG-S-6
WP09 [14], Section 2.3.
ENRI validated the voice services. The results of bidirectional communication
test and demonstrations are provided in ACP-WG-S-6 WP04[10], Section 3.2.
CP/1 WP03.1 Appendix D [Type text] [Type text]
- 17 -
AeroMACS SARPs:
Numbering and Text
Validation
method used
Validation
contributing
Partners
Validation conclusions/summary
7.3.11 AeroMACS shall support
multiple service flows
simultaneously.
S, UT, IT SESAR
NASA
Hitachi
ENRI
S:
A number of simulations were carried out and described in SESAR 15.2.7 D04
(section 3), and also in the draft MASPS (section 12.1.2.2), showing the
transmission of data payload over multiple service flows configured
simultaneously with different transmission parameters associated to the
corresponding CoS.
UT:
In SESAR there were various tests at labs demonstrating the handling of two
service flows simultaneously. The outcome of this is covered in the SESAR
Deliverables P15.02.07 D10 Verification Plan and Report – Phase 2 (section
A1.3) and: P15.02.07 D06.2 Verification Report – Phase 1 (section A.2 and
A.8) and P9.16 ACP-WG-S/6 WP06 [5] (sections 5.4, and 6.1.2.5).
IT:
In addition this was also tested in SANDRA D6.5.1 Report on testing (see
section 4.3), in which four (4) concurrent traffic flows were configured with the
different QoS parameters and corresponding port classification rules. It was
verified that AeroMACS allocates bandwidth to the different traffic according
to the parameters of the corresponding service flows.
NASA-Hitachi field trials demonstrated multiple service flow operations under
different loading profiles. Results can be viewed in ACP WG S/6 WP09 titled
“Field Trials and Results” [14].
Hitachi and NASA testing in Cleveland validated the requirements for multiple
service flows. The results of this testing are provided in ACP-WG-
S/6WP09[14] , Section 2.3.
ENRI validated the multiple service flow. Multi flow test and demonstrations
are provided in ACP-WG-S/6WP04R3, Section 3.2.
CP/1 WP03.1 Appendix D [Type text] [Type text]
- 18 -
AeroMACS SARPs:
Numbering and Text
Validation
method used
Validation
contributing
Partners
Validation conclusions/summary
7.3.12 AeroMACS shall support
adaptive modulation and coding.
IB, UT SESAR
NASA
IB:
The AeroMACS MOPS mandates in section 2.2.8.4.9.4.2 the support of the
data modulation mechanisms referred by IEEE 802.16-2009. This implies that
per-allocation adaptive modulation and coding shall be supported in the DL,
and the UL shall support different modulation schemes for each SS based on
the MAC burst configuration messages coming from the BS.
UT:
This capability was tested in SESAR. In particular, the SESAR deliverables
P15.02.07 D10 Verification Plan and Report – Phase 2 (section A3.3) and
P15.02.07 D06.2 Verification Report – Phase 1 – (section A.1) and P9.16 ACP-
WG-S/6 WP06 [5] (section 5.3).
NASA completed tests addressing adaptive modulation capabilities. Results
are documented in NASA/CR—2011-216997/VOL2 [12].
7.3.13 AeroMACS shall support
handover between different
AeroMACS BSs during aircraft
movement or on degradation of
connection with current BS.
S, UT SESAR
NASA
Hitachi
S:
In SESAR there have been analysis and coverage simulations for the handover
capability (P15.02.07 D03 Profile validation 2.3, 3.3), simulating the execution
of several handover options and message formats, and also the handover
performance in terms of delay and interruption time, respectively. Handover
was also executed in the capacity analysis in the draft MASPS section 12.1.2.2.
UT:
In SESAR P9.16, the hard handover feature was successfully tested without
data transmission (see P9.16 ACP-WG-S/6 WP06 [5] (section 5.6)
NASA-Hitachi field trials demonstrated handover capabilities. Results are
available in ACP-WG-S/6 WP09 titled “Field Trials and Results” [14] and in
NASA/CR—2011-216997/VOL2 [12].
Hitachi and NASA testing in Cleveland validated the requirements for hand
over function. The results of this testing are provided in ACP-WG-S/6 WP09
[14], Section 2.4.
CP/1 WP03.1 Appendix D [Type text] [Type text]
- 19 -
AeroMACS SARPs:
Numbering and Text
Validation
method used
Validation
contributing
Partners
Validation conclusions/summary
7.3.14 AeroMACS shall keep total
accumulated interference levels
with limits defined by the
International Telecommunication
Union - Radiocommunication
Sector (ITU-R) as required by
national/international rules on
frequency assignment planning
and implementation.
S (for large
scale)
UT
FAA
SESAR
NASA
S:
Both in US and Europe extensive simulations were undertaken to demonstrate
that AeroMACS would not interfere in particular with the satellite feeder links
(FSS). A comprehensive interference study is described in the draft MASPS
section11, which defined SARPS section 7.4.3 radiation power the maximum
tolerable power levels for implementation of AeroMACS in order not to
interfere with the FSS.
In SESAR, Deliverable P15.02.07 D02.3 describes the outcome of analysis and
simulations addressing the interference to FSS and indicates that there are no
problems expected. In addition, SESAR Deliverable P15.02.05 D01.5 describes
the outcome of theoretical spectrum investigations of interferences to and from
other systems operating in the same band or in adjacent bands and in particular
RLANs operating in the 5150-5250 MHz band, BBDR systems, MLS, Galileo
C1 and AMT. The outcome indicates there are no interference issues expected
in the case of RLANs and BBDR, but in the other cases and in particular with
MLS, there may be the need for careful planning to protect the AeroMACS
receiver from interfering systems but it is not impacting the other systems. This
will be further addressed with the development of AeroMACS frequency
planning criteria and guidance.
NASA provides information in the report [13]
UT:
For information, In SESAR, there was extensive testing of the spectrum
performance of the prototypes. The results of these tests are provided in the
deliverables P15.02.07 D06.2 Verification Report – Phase 1 (sections A.5,
A.10 and A.11) and P15.02.07 D10 Verification Plan and Report – Phase 2
(sections A2.2, A3.2 and A3.6).
CP/1 WP03.1 Appendix D [Type text] [Type text]
- 20 -
AeroMACS SARPs:
Numbering and Text
Validation
method used
Validation
contributing
Partners
Validation conclusions/summary
7.3.15 AeroMACS shall support a
flexible implementation
architecture to permit link and
network layer functions to be
located in different or same
physical entities.
IB ACP WG/S IB:
In the implementation of link and network functions, AeroMACS follows the
WMF concept in which these can belong to either component such as BS or
ASN-GW without a loss of system capability. This concept is shown in the
ASN Profiles described in the draft MASPS (section 2.1.7) which remain at the
level of functional components and not physical boxes.
System configurations used in various demonstrations conducted by SESAR,
Hitachi, and NASA included AeroMACS functions located in a stand-alone
prototype unit and the network router and application functions located on a
different physical entity. These represent federated architectures.
WiMAX Forum COTS products include WIMAX Hot Spots and Smart
Phones, which include the WiMAX, network router, and application functions
integrated in the same physical entity.
Based on the above existing system configurations, it can be concluded that
future AeroMACS systems will support flexible implementation architectures.
7.4 RADIO FREQUENCY (RF)
CHARACTERISTICS
NVR
7.4.1 GENERAL RADIO
CHARACTERISTICS
NVR
7.4.1.1 AeroMACS shall operate in time
division duplex (TDD) mode.
IB, UT SESAR
NASA
Hitachi
ENRI
IB:
Time Division Duplex is the basic mode to duplex DL and UL subframes and
is mandated in the MOPS Chapter 2.2.6.3.7.2.
UT:
In the laboratory tests described in Deliverable P15.02.07 D06.2 Verification
Report – Phase 1 sections A.1 and A.6, the correct configuration and operation
of the TDD mode is verified by spectrum analyser at both the BS and the MS
as a middle step in the verification test.
CP/1 WP03.1 Appendix D [Type text] [Type text]
- 21 -
AeroMACS SARPs:
Numbering and Text
Validation
method used
Validation
contributing
Partners
Validation conclusions/summary
In the laboratory tests described in P9.16 ACP-WG-S/6 WP06 [5] in section
5.1, the SELEX AeroMACS MS prototype Net Entry procedures is verified,
and shows among the different operations also the TDD mode.
All NASA tests were conducted in TDD mode. Results are available in
NASA/CR—2011-216997/VOL2 [12]
Hitachi and NASA testing in Cleveland validated the requirements for TDD
mode. The testing included the multiple uplink and downlink ratios. This
testing is presented in ACP-WG-S/6 WP09 [14], Section 2.2.
ENRI validated the TDD mode. The results of the test and demonstrations are
provided in ACP-WG-S/6 WP04, Section 3.2.
7.4.1.2 AeroMACS shall operate with a 5
MHz channel bandwidth.
UT SESAR
SANDRA
Hitachi
ENRI
UT:
In the laboratory tests described in P15.02.07 D06.2 Verification Report –
Phase 1 (sections A.1, A.6 and A.10) and in the P9.16 ACP-WG-S/6 WP06 [5]
in sections 5.1, the correct configuration and operation of the 5 MHz channel
bandwidth is verified at both the BS and the MS as a means to ensure the link
interoperability and compliance to RF characteristics.
UT:
In SANDRA D6.5.1 Report on testing (see section 4.2), the test platform is
successfully verified to operate in 5 MHz bandwidth channels.
Hitachi and NASA testing in Cleveland validated the requirements for 5MHz
channels. The results of this testing are provided in ACP-WG-S/6 WP09[14],
Section 2.2.
ENRI validated the 5MHz channel bandwidth. The several demonstrations are
documented in ACP-WG-S/6 WP04, Section 3.2 and the results of test are
provided in WP of EUROCAE WG82 meeting in May 2014.
CP/1 WP03.1 Appendix D [Type text] [Type text]
- 22 -
AeroMACS SARPs:
Numbering and Text
Validation
method used
Validation
contributing
Partners
Validation conclusions/summary
7.4.1.3 AeroMACS MS antenna
polarization shall be vertical.
MD SESAR MD:
During the field tests performed by Airbus in Toulouse airport the following
airborne MS antenna was used:
ANTCOM 5B-4.4-5.8V-O-XT-2 4.4-5.85 GHz 5dB Gain Omni Blade Antenna
http://www.antcom.com/documents/catalogs/Page/5B-4.4-5.8V-O-XT-2_LSC-
BandAntennas1.pdf.
The antenna is described by the manufacturer antenna as having vertical
polarization.
7.4.1.4 AeroMACS BS antenna
polarization shall have a vertical
component.
MD, UT SESAR
MD:
During the field tests performed by Thales in Toulouse airport and described in
15.2.7 D10 section A3, the following BS antenna was used:
MARS MA-WD55-DS16 4.9-6.1 GHz Dual Slant ±45°,Base Station Antenna,
90° sector antenna http://www.mars-antennas.com/MA-WD55-DS16.
The antenna is described by the manufacturer as dual slant (double
polarization).
UT:
AeroMACS field tests performed by Thales and described in SESAR
P15.02.07 D10 Verification Plan and Report – Phase 2 section A3 make use of
a cross-polarization antenna, which thus includes a vertical component.
7.4.1.5 AeroMACS shall operate without
guard bands between adjacent
AeroMACS channels.
UT SESAR UT:
The field test performed by Thales in Toulouse and described in P15.02.07 D10
Verification Plan and Report – Phase 2 A3.6 shows the operation of two
contiguous AeroMACS BS using adjacent channels (without guard band).
CP/1 WP03.1 Appendix D [Type text] [Type text]
- 23 -
AeroMACS SARPs:
Numbering and Text
Validation
method used
Validation
contributing
Partners
Validation conclusions/summary
7.4.1.6 AeroMACS shall operate
according to the orthogonal
frequency division multiple
access method.
IB, UT SESAR
IB:
OFDMA is the only supported physical layer by AeroMACS, as is described in
the MOPS section 2.2.6.3.7.5.3.
UT:
The test described in deliverables P15.02.07 D10 Verification Plan and Report
– Phase 2 section A2.2 and P15.02.07 D06.2 Verification Report – Phase 1
sections A.1 and A.6 verify the crest factor, (which is a basic characteristic of
an OFDMA signal) and the use of OFDMA itself, respectively.
In the laboratory tests described in P9.16 ACP-WG-S/6 WP06 [5] in section
5.1, the SELEX AeroMACS MS prototype Net Entry procedures is verified, and shows
among the different operations also the OFDMA mode.
7.4.1.7 AeroMACS shall support both
segmented partial usage sub-
channelisation (PUSC) and PUSC
with all carriers as sub-carrier
permutation methods.
IB, UT SESAR
Hitachi
IB:
AeroMACS MOPS mandates the use of PUSC in sections 2.2.8.4.6.1.2.1, and
2.2.8.4.6.2.1. PUSC is a basic configuration for AeroMACS
UT:
The use of PUSC is shown during a sub-channelisation test described in
P15.02.07 D06.2 Verification Report – Phase 1 section A4.3 (see pictures in
A4.3.2 pages 52 and 53).
Hitachi's implementation provides for full support of PUSC as described in
IEEE 802.16e and required by the SARPS. The implementation was verified in
Hitachi's product development laboratory.
CP/1 WP03.1 Appendix D [Type text] [Type text]
- 24 -
AeroMACS SARPs:
Numbering and Text
Validation
method used
Validation
contributing
Partners
Validation conclusions/summary
7.4.2 FREQUENCY BANDS NVR
7.4.2.1 The AeroMACS equipment shall
be able to operate in the band
from 5030 MHz to 5150 MHz in
channels of 5 MHz bandwidth.
Note 1.— Some States may, on the
basis of national regulations, have
additional allocations to support
AeroMACS. Information on the
technical characteristics and
operational performance of
AeroMACS is contained in the
AeroMACS Minimum Operational
Performance Specification (MOPS)
(EUROCAE ED-233 / RTCA DO-
346) and AeroMACS Minimum
Aviation System Performance
Standard (MASPS) (EUROCAE ED-
227).
Note 2. — The last center frequency
of 5145MHz is selected as the
reference frequency. AeroMACS
nominal center frequencies are
referenced downward from the
reference frequency in 5 MHz steps.
IA
UT
SESAR
NASA
UT:
In SESAR there was extensive lab testing of AeroMACS units operating in the
5091 to 5150 MHz frequency band. These tests are described in SESAR
deliverables P15.02.07 D10 Verification Plan and Report – Phase 2 sections A1
and A2 and P15.02.07 D06.2 Verification Report – Phase 1 sections A.1 and
A.6, and in the P9.16 ACP-WG-S/6 WP06 [5] in sections 5.1 and 6.1.5.1.
NASA completed tests utilizing 5000 – 5030 MHz. Information is available in
document [15].
IA:
For the band from 5030 to 5091 MHz, there has not been any testing in
SESAR. However, based on common knowledge, there is no technical
impediment to question the operation in this lower band, in particular since the
signal propagation conditions will actually be better.
CP/1 WP03.1 Appendix D [Type text] [Type text]
- 25 -
AeroMACS SARPs:
Numbering and Text
Validation
method used
Validation
contributing
Partners
Validation conclusions/summary
7.4.2.2 The mobile equipment shall be
able to operate at center
frequencies offset from the
preferred frequencies, with an
offset of 250 KHz step size.
Note. — The nominal center
frequencies are the preferred center
frequencies for AeroMACS
operations. However, the base
stations should have the capability to
deviate from the preferred center
frequencies to satisfy potential
national spectrum authority
implementation issues (i.e. to allow
AeroMACS operations while
avoiding receiving or causing
interference to other systems
operating in the band such as MLS
and AMT).
UT
SESAR
Hitachi
UT:
In the laboratory tests described in the P9.16 ACP-WG-S/6 WP06 [5] in
section 5.1, the AeroMACS MS Prototype has been configured to perform the
frequency scanning in a settable range (in the 5-5.15GHz bandwidth), with
selectable step intervals multiple of 250KHz, demonstrating the requirement is
achievable.
The lab tests and field test executed in Toulouse airport and described in
SESAR deliverables P15.02.07 D10 Verification Plan and Report – Phase 2
section A3.2, and P15.02.07 D06.2 Verification Report – Phase 1 sections A.1
to A.5 indicate that a 250 kHz step was used in the MS equipment.
Hitachi and NASA testing in Cleveland validated the requirements for offset of
250 kHz step size. The results of this testing included searching 250kHz step to
network entry. Refer to ACP-WG-S/6WP09 [14], Section 2.1.
7.4.3 RADIATED POWER NVR
7.4.3.1 The maximum mobile station
effective isotropic radiated power
(EIRP) shall not exceed 30 dBm
A, UT SESAR,
During Toulouse testing, the MS EIRP was below 30 dBm: Max emitting
power 23 dBm and Max Antenna gain 6 dBi => EIRP 29 dBi as described in
P15.02.07 D05.1 System Implementation Deliverable Part1: AeroMACS
Ground Prototypes Description, section 2.3.3.
7.4.3.2 The maximum base station EIRP
in a sector shall not exceed 39.4
dBm
A
UT
SESAR UT + A:
In P15.02.07 field test, BS prototype maximum emitting power is 23 dBm and
max BS antenna gain is 15 dBi so that max BS EIRP is 38 dBm as shown in
P15.02.07 D05.1 System Implementation Deliverable Part1: AeroMACS
Ground Prototypes Description, section 2.3.2.1
CP/1 WP03.1 Appendix D [Type text] [Type text]
- 26 -
AeroMACS SARPs:
Numbering and Text
Validation
method used
Validation
contributing
Partners
Validation conclusions/summary
7.4.3.3 Recommendation. — In order to
meet ITU requirements, the total
base station EIRP in a sector
should be decreased from that
peak, considering the antenna
characteristics, at elevations
above the horizon. Further
information is provided in the
guidance material;
Note 1.— EIRP 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.
Note 2.— If a sector contains
multiple transmit antennas (e.g.,
multiple input multiple
output(MIMO) antenna), the
specified power limit is the sum of the
powers from each antenna.
IB
FAA This recommendation provides guidance on the antenna diagram shape relative
to the elevation and azimuth angle, based on the interference limitations
required to minimize the impact on FSS signals.
IB:
The elevation and azimuth pattern, and the recommended maximum power
transmission limits per angle value are indicated in the draft MASPS section
11.4. The AeroMACS Technical Manual will contain information and
examples based on analysis carried out by FAA.
CP/1 WP03.1 Appendix D [Type text] [Type text]
- 27 -
AeroMACS SARPs:
Numbering and Text
Validation
method used
Validation
contributing
Partners
Validation conclusions/summary
7.4.4 MINIMUM RECEIVER
SENSITIVITY
NVR
7.4.4.1 AeroMACS receiver sensitivity
shall comply with table 7-1 –
AeroMACS Receiver Sensitivity
values.
Note 1.—The computation of the
sensitivity level for the AeroMACS is
described in the guidance material
Note 2.— AeroMACS receiver would
be 2 dB more sensitive than
indicated if Convolutional Turbo
Codes (CTC) is used.
Note 3 - The sensitivity level is
defined as the power level measured
at the receiver input when the bit
error rate (BER) is equal to 1*10-6
and all active sub carriers are
transmitted in the channel. In general
the requisite input power depends on
the number of active sub-carriers of
the transmission.
Note 4.— The above values assume a
receiver noise figure of 8 dB.
Note 5 .— The sensitivity values in
Table 7-1 assume absence of any
source of interference except for
thermal and receiver noise.
Table 7-1 –AeroMACS Receiver
Sensitivity values.
Note .— 64 QAM transmission is
optional for MS.
IB, UT SESAR
Hitachi
IB:
The sensitivity levels to be complied with are in line with the values required
by IEEE802.16-2009 standard. This is consistent with the MOPS section
2.2.8.4.14.1.1.
UT:
Sensitivity levels have been verified in SESAR as described in the test in
deliverable P15.02.07 D06.2 Verification Report – Phase 1 section A.4. In this
test, sensitivity limits are obtained by use of a variable attenuator for each of
the supported modulation and coding schemes. This is performed both in
downlink and uplink directions.
In addition, this requirement was also tested by Hitachi and measured results
are compliant with the specifications. The detailed test results are provided in
Appendix B-1 of [8].
CP/1 WP03.1 Appendix D [Type text] [Type text]
- 28 -
AeroMACS SARPs:
Numbering and Text
Validation
method used
Validation
contributing
Partners
Validation conclusions/summary
7.4.5 SPECTRAL MASK AND
EMISSIONS
NVR
7.4.5.1 The power spectral density of the
emissions when all active sub
carriers are transmitted in the
channel shall be attenuated below
the maximum power spectral
density as follows:
a) On any frequency removed from
the assigned frequency between 50–
55% of the authorized bandwidth: 26
+ 145 log (% of BW/50) dB.
b) On any frequency removed from
the assigned frequency between 55–
100% of the authorized bandwidth:
32 + 31 log (% of (BW)/55) dB.
c) On any frequency removed from
the assigned frequency between 100–
150% of the authorized bandwidth:
40 +57 log (% of (BW)/100) dB.
d) On any frequency removed from
the assigned frequency beyond 150%
of the authorized bandwidth: 50 dB.
Note.- The power spectral density at
a given frequency is the power within
a bandwidth equal to 100 kHz
centred at this frequency, divided by
this measurement bandwidth. It is
clarified that the measurement of the
power spectral density should
encompass the energy over at least
one frame period.
UT SESAR
Hitachi
UT:
The Spectrum Mask has been measured in the SESAR testing and this is
described in deliverables P15.02.07 D06.2 Verification Report – Phase 1
(sections A.5 and A.10) and P15.02.07 D10 Verification Plan and Report –
Phase 2 (section A2.2). The first deliverable verifies the compliance of the
required attenuation values (plus minimum spurious attenuation which is
verified at 53 dB) and flatness of the transmission mask. The second
deliverable verifies the transmission mask in terms of adjacent/non-adjacent
channel rejection requirements.
In addition, this requirement was also tested by Hitachi and measured results
are compliant with the specifications. The Hitachi test was done with the
following settings:
- Measurement bandwidth (MeasBW): 100KHz
- RBW : 10kHz (MeasBW = 10 * RBW)
- Detector : Positive Peak
- Trace : Max-Hold
- Spectrum Peak Reference Mode
The detailed test results are provided in [9].
The testing methodology will be described in the Technical Manual (Guidance
Material).
CP/1 WP03.1 Appendix D [Type text] [Type text]
- 29 -
AeroMACS SARPs:
Numbering and Text
Validation
method used
Validation
contributing
Partners
Validation conclusions/summary
7.4.5.2 AeroMACS shall implement
power control.
UT SESAR,
Hitachi
UT:
Unit tests have been performed in SESAR to verify the operation of power
control in the lab. This is described in SESAR P15.2.7 D06.2 Verification
Report – Phase 1 section A.7, which tests that the MS properly applies an Open
Loop (during ranging phase) and Closed Loop Power Control procedure and
that the physical measurements which drive them are correct within the
specified tolerances. In addition, SESAR P15.02.07 D10 Verification Plan and
Report – Phase 2 section A1.2 describes the unit test verifying the correct use
of CQI channels during the Closed Loop Power Control Execution, also
verifying that the closed loop power control satisfactorily sustains a data
transfer without causing any oscillation or instability in the system, facing
channel gain variations of up to 30 dB/s.
In the laboratory tests described in the P9.16 ACP-WG-S/6 WP06 [5]in section
5.2, the AeroMACS MS Prototype has been capable to apply both Open Loop
and Closed Loop Power Control. A configuration file (config.dat) parameter
has been set to enable/disable the OLPC in UL, demonstrating the requirement
is achievable on aircraft.
In addition as reported in Appendix B-2 of [8], Hitachi testing confirmed that
the transmission power of the MS changes according to the path-loss.
7.4.5.3 AeroMACS minimum rejection
for adjacent (+/–5MHz) channel –
measured at BER=10-6 level for a
victim signal power 3 dB higher
than the receiver sensitivity - shall
be 10 dB for 16 QAM 3/4.
UT SESAR,
Hitachi
UT:
Prototype unit tests were executed in SESAR and these are described in
deliverable P15.02.07 D10 Verification Plan and Report – Phase 2 section
A2.2, verifying the rejection value for adjacent and non-adjacent channels for
16 QAM ¾ signal at 3dB higher than the sensitivity level.
This requirement was also measured by Hitachi and the results are compliant
with the specification. The detailed results are described in Appendix B-3 of
[8].
CP/1 WP03.1 Appendix D [Type text] [Type text]
- 30 -
AeroMACS SARPs:
Numbering and Text
Validation
method used
Validation
contributing
Partners
Validation conclusions/summary
7.4.5.4 AeroMACS minimum rejection
for adjacent (+/–5MHz) channel
measured at BER=10-6 level for a
victim signal power 3 dB higher
than the receiver sensitivity shall
be 4 dB for 64 QAM 3/4.
UT SESAR
Hitachi
UT:
Prototype unit tests were executed in SESAR and these are described in
deliverable P15.02.07 D10 Verification Plan and Report – Phase 2 section
A2.2, verifying the rejection value for adjacent and non-adjacent channels for
64 QAM ¾ signal at 3dB higher than the sensitivity level.This requirement was
also measured by Hitachi and the results are compliant with the specification.
The detailed results are described in Appendix B-3 of [8].
7.4.5.5 AeroMACS minimum rejection
for second adjacent(+/–10MHz)
channel and beyond – measured
at BER=10-6 level for a victim
signal power 3 dB higher than the
receiver sensitivity - shall be 29
dB for 16 QAM 3/4.
UT SESAR
Hitachi
UT:
Prototype unit tests were executed in SESAR and these are described in
deliverable P15.02.07 D10 Verification Plan and Report – Phase 2 section
A2.2, verifying the rejection value for adjacent and non-adjacent channels for
16 QAM ¾ signal at 3dB higher than the sensitivity level.
This requirement was also measured by Hitachi and the results are compliant
with the specification. The detailed results are described in Appendix B-3 of
[8].
7.4.5.6 AeroMACS minimum rejection
for second adjacent (+/–10MHz)
channel and beyond – measured
at BER=10-6 level for a victim
signal power 3 dB higher than the
receiver sensitivity - shall be 23
dB for 64 QAM 3/4.
Note.— for additional clarification,
to the requirements stated in
paragraphs from 7.4.5.3, 7.4.5.4, 7.4.5.5 and 7.4.5.6, refer to IEEE
802.16-2009 section 8.4.14.2.
UT SESAR
Hitachi
UT:
Prototype unit tests were executed in SESAR and these are described in
deliverable P15.02.07 D10 Verification Plan and Report – Phase 2 section
A2.2, verifying the rejection value for adjacent and non-adjacent channels for
64 QAM ¾ signal at 3dB higher than the sensitivity level.
This requirement was also measured by Hitachi and the results are compliant
with the specification. The detailed results are described in Appendix B-3 of
[8].
CP/1 WP03.1 Appendix D [Type text] [Type text]
- 31 -
AeroMACS SARPs:
Numbering and Text
Validation
method used
Validation
contributing
Partners
Validation conclusions/summary
7.4.6 FREQUENCY TOLERANCE NVR
7.4.6.1 AeroMACS BS reference
frequency accuracy shall be better
than +/- 2 x 10E-6.
IB, UT
SESAR IB:
AeroMACS MOPS 2.2.8.4.15.1 references to the requirement based in the
IEEE802.16-2009 standard.
UT:
In SESAR there was a unit test to verified the required accuracy. This is
described in P15.2.7 D06.2 Verification Report – Phase 1 section A.10. The
test concludes that the BS center frequency error measured was about ±100 Hz
at 5.091 MHz, i.e. less than 2x10-8
7.4.6.2 AeroMACS MS reference
frequency shall be locked to that
of the BS centre frequency with
an accuracy better than 2% of the
subcarrier spacing.
IB,UT
SESAR IB:
AeroMACS MOPS 2.2.8.4.15.1 references to the requirement based in the
IEEE802.16-2009 standard.
UT:
In SESAR there was a unit test that verified the required accuracy. This is
described in P15.2.7 D10 Verification Plan and Report – Phase 2 section A2.3.
7.4.6.3 AeroMACS MS shall track the
frequency of the BS and shall
defer any transmission if
synchronisation is lost or exceeds
the tolerances given above.
IB
WG S
analysis
based on
WiMAX
Forum
certification
IB:
AeroMACS MOPS 2.2.8.4.15.1 references to the requirement based in the
IEEE802.16-2009 standard.
The WiMAX Forum Certification Requirement Status List (CRSL) RCT MS-
19.1 Transmit Synchronization tests are category A certification tests required
for Forum Certification that cover the protocol implementation requirement to
sync the MS frequency to the BS and to shut down the MS transmitter under
certain circumstances that include loss of sync and frequency drift.
CP/1 WP03.1 Appendix D [Type text] [Type text]
- 32 -
AeroMACS SARPs:
Numbering and Text
Validation
method used
Validation
contributing
Partners
Validation conclusions/summary
7.5 PERFORMANCE
REQUIREMENTS
NVR
7.5.1 AeroMACS
COMMUNICATIONS
SERVICE PROVIDER
NVR
7.5.1.1 The maximum unplanned service
outage duration on a per
aerodrome basis shall be 6
minutes.
IB , A FAA IB:
AeroMACS safety and performance analysis is based on the work from
EUROCAE WG-78/RTCA SC-214 and sets the availability requirements over
the Aeronautical Communication Service Provider (ACSP) as described in the
draft MASPS section 8.1.1.
The ACSP covers both the connectivity service network (CSN) and the access
service network (ASN) that is deployed within a specific airport.
A:
Unplanned service outage is managed through appropriate design and
implementation of the system. Usually, this design process involves bottom up
analysis of the MTBF and MTTRs of the underlying components and
subsequent addition of redundancies at appropriate levels. It can be concluded
from the analysis of FAA’s existing critical infrastructure services such as FTI,
ASSC, ADS-B, VSCS, VDL, etc. that the stated requirement can be satisfied.
7.5.1.2 The maximum accumulated
unplanned service outage time on
per aerodrome basis shall be 240
minutes/year.
A, IB FAA IB:
AeroMACS safety and performance analysis is based on the work from
EUROCAE WG-78/RTCA SC-214 and sets the availability requirements over
the Aeronautical Communication Service Provider (ACSP) as described in the
draft MASPS section 8.1.1. The ACSP covers both the connectivity service
network (CSN) and the access service network (ASN) that is deployed within a
specific airport.
A:
As described under Section 7.5.1.1, this requirement is validated through
extension of FAA’s existing infrastructures supporting safety critical services.
CP/1 WP03.1 Appendix D [Type text] [Type text]
- 33 -
AeroMACS SARPs:
Numbering and Text
Validation
method used
Validation
contributing
Partners
Validation conclusions/summary
7.5.1.3 The maximum number of
unplanned service outages shall
not exceed 40 per year per
aerodrome.
A, IB FAA IB:
AeroMACS safety and performance analysis is based on the work from
EUROCAE WG-78/RTCA SC-214 and sets the availability requirements over
the Aeronautical Communication Service Provider (ACSP) as described in the
draft MASPS section 8.1.1.
The ACSP covers both the connectivity service network (CSN) and the access
service network (ASN) that is deployed within a specific airport.
A:
As described under Section 7.5.1.1, this requirement is validated through
extension of FAA’s existing infrastructures supporting safety critical services.
7.5.1.4 Connection resilience. The
probability that a transaction will
be completed once started shall be
at least .999 for AeroMACS
systems over any one-hour
interval.
Note 1. — Connection releases
resulting from AeroMACS handover
between base stations, log-off or
circuit pre-emption are excluded
from this specification.
Note 2. — The requirements given in
7.5.1 refer to the overall service
provision, i.e; when all aircraft
operating at the aerodrome are
affected.
IB FAA,
SESAR
IB:
AeroMACS safety and performance analysis is based on the work from
EUROCAE WG-78/RTCA SC-214 and defines the continuity target as the
99.9% probability to be compliant with the maximum acceptable transaction
time or expiration time, as described in the draft MASPS section 8.1. The
safety and performance analysis in SESAR 15.2.7 D08-T8.1 AeroMACS
Safety and Performance Analysis section 4.2 also defines continuity as the
probability that the transaction completes within a given duration, and given
that the continuity requirement is 0.999, this duration that all transactions shall
respect is the Transaction Time at 99.9% (TT 99.9 %).
CP/1 WP03.1 Appendix D [Type text] [Type text]
- 34 -
AeroMACS SARPs:
Numbering and Text
Validation
method used
Validation
contributing
Partners
Validation conclusions/summary
7.5.2 DOPPLER SHIFT NVR
7.5.2.1 AeroMACS shall operate with a
Doppler shift induced by the
movement of the MS up to a
radial speed of 92.6km (50
nautical miles) per hour, relative
to the BS.
UT SESAR UT:
The MS mobility requirement has been verified In the laboratory tests
described in the P9.16 ACP-WG-S/6 WP06 [5] in section 5.7 and in the airport
tests performed in Toulouse and described in SESAR P15.02.07 D10
Verification Plan and Report– Phase 2 section A3.5.3. The test evaluates the
impact of mobility on the data communications and channel selectivity at 50,
90 and 120 km/h. The results showed that the data link could maintain
connectivity at reasonable data rate and maintained a consistent RSSI and
CINR performance. (ACP WG S/6 IP04).
7.5.3 DELAY NVR
7.5.3.1 Subnetwork entry time shall be
less than 90 seconds.
IB, A, UT,
MD
SESAR
Hitachi
IB and A:
AeroMACS draft MASPS requires a network entry time of 90 seconds as
indicated in section 6.3.
The SARPs Definitions section describes subnetwork entry time as the time
from when the MS starts scanning for BS transmissions until the first network
user “PDU” can be sent. Therefore it does not include time for self-test or other
power up functions.
The channel bandwidth being 5 MHz there are only 23 channels in the band
5030 to 5150 (and only 11 are available in the band 5091 to 5150).The SARPs
(as well as the MOPS and MASPS) required though that the AeroMACS MS
should be able to support 250 kHz frequency step size but also define a
preferred frequency set of 5 MHz step size.
There are various ways to implement the scanning process and it clarified that
the SARPs do not require sequential scanning with 250 KHz step size.
In addition other solutions to minimise the Subnetwork Entry Time exist such
as to pre-provision the MS with the frequency it needs to use at start-up (i.e. at
a destination airport) by means of a database.
CP/1 WP03.1 Appendix D [Type text] [Type text]
- 35 -
AeroMACS SARPs:
Numbering and Text
Validation
method used
Validation
contributing
Partners
Validation conclusions/summary
Finally, as the deviations from the nominal frequencies should only take place
in exceptional cases, it is recommended that any implementation of the
scanning process addresses first the preferred frequencies.
UT:
In SESAR there were measurements in the lab as well as in a real environment.
A lab measurement is described in deliverable P15.02.07 D06.2 Verification
Report – Phase 1 section A.6. The test verifies the MS connects properly with a
BS in the laboratory. The test results show a network entry time of 9.33
seconds considering one scanning. In the same section, the subnetwork entry
time is estimated to 26.73 seconds assuming a sequential scan with 250 KHz
step size for the whole 5000-5150 MHz band (580 scans with 30 ms each
scan). A measurement of the scanning time in a real environment has also taken
place and it is described in SEAR 15.2.7 D10 Verification Plan and Report –
Phase 2 section A3.2. The test performed a MS initialization and scanning with
250 kHz step size, of 217 frequencies from 5093,5 to 5147,5 and the test results
indicate 2 minutes 10 seconds from MS switch on and network entry
completed.
In the laboratory tests described in the P9.16 ACP-WG-S/6 WP06 [5] in
section 5.1, the same lab test as reported above for the P15.02.07 project is
mentioned. As already reported, the Network Entry Time (consisting in
Physical/MAC Synchronization, Authentication/Registration and Service
Flows Creation) was measured being about 9.330 seconds. This time does not
include time for self-test and other power up functions. Furthermore, all of the
devices involved in the process were located in the same room. It is worth
observing that in this test the MS had been previously configured to scan a
limited list of frequencies. If instead the MS had to scan the whole frequency
band 5000-5150 MHz, an extra time should be considered for physical layer
scanning.
It is estimated that the order of magnitude of the time needed to span the whole
band looking for a valid preamble could be tens of milliseconds per each
channel.
CP/1 WP03.1 Appendix D [Type text] [Type text]
- 36 -
AeroMACS SARPs:
Numbering and Text
Validation
method used
Validation
contributing
Partners
Validation conclusions/summary
Therefore, assuming for instance this time being 30 ms, the extra-time needed
to span the whole band would be 30ms * 580 = 17.4 seconds. This would lead
to a total Net Entry Time of 9.33 + 17.4 = 26.73 seconds.
It is also worth underlining that this result has been obtained in a controlled
environment (lab). Real environments (airports) can introduce degradation
factors (attenuation, multipath fading, shadowing, Doppler effects, etc.) that
may increase the packet error rate and the number of retransmissions, with
subsequent increase in the Net Entry Time. For this reason, the 90 seconds
currently hypothesized in the ICAO SARPs as maximum net entry time can be
considered appropriate.
UT:
Hitachi and NASA testing in Cleveland validated the requirements for network
entry time. The measured results of this testing are provided in ACP-WG-
S/6WP09 [14], Section 2.1.
MD:
Further testing has been conducted by Thales measuring the scanning time in a
lab for a limited set of frequencies (11 and 22). For 11 frequencies (forcing the
worst case scenario needing to scan all 11 nominal canter frequencies) the
subnetwork entry time is around 12 seconds. For 22 frequencies the
subnetwork entry time is around 16 seconds.
During the SARPs development process there was an open item to consider
reducing the 90s requirement. In the end considering requests also from the
industry involved it is proposed to maintain this requirement to 90s with the
expectation that a much better than 90s entry time will be generally achievable.
7.5.3.2 Recommendation .—
Subnetwork entry time should be
less than 20 seconds .
IB, A, UT,
MD
SESAR Based on the analysis above it is expected that this recommendation is feasible
and it could be met through an efficient implementation of the scanning
algorithm, or other means (such as frequency data bases).
CP/1 WP03.1 Appendix D [Type text] [Type text]
- 37 -
AeroMACS SARPs:
Numbering and Text
Validation
method used
Validation
contributing
Partners
Validation conclusions/summary
7.5.3.3 The from-MS data transit delay
(95th percentile) for the highest
priority data service, shall be less
than or equal to 1.4 seconds over
a window of 1 hour or 600 SDUs,
whichever is longer.
S, A, UT
SESAR S+A:
The draft AeroMACS MASPS describes the results of simulations of capacity
analysis per airport in section 12.1.2.2.
The simulations calculate the average delay of data link message delay is 0.17
seconds in the worst case. A calculation of the variance range acceptable for
this delay to be within 95th percentile margin is a straightforward analysis
validation method. Assuming normal distribution of message delay, the 95th
percentile falls within 1.96*std dev. For it to be under 1.4 s, the std dev must be
0.63 s maximum (i.e. 3.7 times the mean). This means that, in order not to
comply with the requirement, the spread of the message delay distribution must
be very high, which was not the case observed in the simulations.
UT: In the tests described in the P9.16 ACP-WG-S/6 WP06 [5] in sections 5.4,
6.1.5.2, 6.1.5.6, 6.2.4.3, 6.2.4.5, 6.2.4.7 this requirement has been validated
both in laboratory and field environment
7.5.3.4 The to-MS data transit delay (95th
percentile) for the highest priority
data service, shall be less than or
equal to 1.4 seconds over a
window of 1 hour or 600SDUs,
whichever is longer.
S, A, UT SESAR S+A:
The draft AeroMACS MASPS describes the results of simulations of capacity
analysis per airport in section 12.1.2.2. The simulations calculate the average
delay of data link message delay is 0.17 seconds in the worst case. A
calculation of the variance range acceptable for this delay to be within 95th
percentile margin is a straightforward analysis validation method. Assuming
normal distribution of message delay, the 95th percentile falls within 1.96*std
dev. For it to be under 1.4 s, the std dev must be 0.63 s maximum (i.e. 3.7 times
the mean). This means that, in order not to comply with the requirement, the
spread of the message delay distribution must be very high, which was not the
case observed in the simulations.
UT:
In the tests described in the P9.16 ACP-WG-S/6 WP06 [5] in sections 5.4,
6.1.5.2, 6.1.5.6, 6.2.4.3, 6.2.4.5, 6.2.4.7 this requirement has been validated
both in laboratory and field environment
CP/1 WP03.1 Appendix D [Type text] [Type text]
- 38 -
AeroMACS SARPs:
Numbering and Text
Validation
method used
Validation
contributing
Partners
Validation conclusions/summary
7.5.4 INTEGRITY NVR
7.5.4.1 AeroMACS BS and MS shall
support mechanisms to detect and
correct corrupt SNSDUs
IB, S
SESAR IB:
The AeroMACS draft MASPS requires in section 13 a mechanism to ensure
message integrity. In addition, the AeroMACS MOPS mandates the use of
CRC and ARQ retransmission to detect and correct corrupt SDUs in sections
2.2.8.4.16.1.2 and 2.2.6.3.3.3.2, respectively. The requirement is also addressed
at operational level in SESAR P15.02.07 D08 T8.1 Safety and Performance
Analysis, section 6.2.3, by indicating that the AeroMACS system shall prohibit
operational processing of corrupted messages.
S:
The operation of mechanisms to detect and correct corrupt SDUs (specifically,
the use of ARQ retransmission) has been described in the draft MASPS section
C1 in the capacity analysis per operational domain. The simulation verifies the
configuration and performance of various types of retransmission schemes.
7.5.4.2 AeroMACS BS and MS shall
only process SNSDUs addressed
to themselves
IB, A SESAR IB+A:
The AeroMACS draft MASPS requires in section 13 a mechanism of
continuous verification of the sender of the message. By a straightforward
analysis, it can be concluded that authenticating the sender ensures that the
corresponding security association (SA) is established bilaterally between the
sender and the receiver using a mutually agreed encryption key, and thus a
mechanism exists to ensure that no MS other than the intended receiver can
process the desired message.
The requirement is also addressed at operational level in SESAR P15.02.07
D08 T8.1 Safety and Performance Analysis section 6.2.3, by indicating that the
AeroMACS system shall only accept uplink messages intended for the aircraft.
CP/1 WP03.1 Appendix D [Type text] [Type text]
- 39 -
AeroMACS SARPs:
Numbering and Text
Validation
method used
Validation
contributing
Partners
Validation conclusions/summary
7.5.4.3 Recommendation .— The
residual error rate, to/from MS
should be less than or equal to 5 x
10-8
per SNSDU.
Note.— There are no integrity
requirements for SNSDU residual
rate to the BS and MS as the
requirement is entirely satisfied by
the end-to-end systems in the aircraft
and Air Traffic Service Provider.
IB, A ACP-WG-S IB+A:
This recommendation is raised from an operational (application level)
requirement existent in the Communications Operating Concept and
Requirements (COCR) for the Future Radio System document v2. Tables 5-7
and 5-8 establish the integrity RCTP per service instantiation for ATS phase 1
and 2, respectively. The most stringent services in the tables require a
maximum error rate of 5*10E-08.
7.5.4.4 The maximum bit error rate shall
not exceed 10-6 after CTC-FEC
assuming a minimum received
signal equal to the corresponding
sensitivity level.
IB, A, UT SESAR
Hitachi
IB:
This requirement is covered by the MOPS section 2.2.8.4.14.1.1 which
establishes the maximum BER value to comply with the sensitivity requirement
as 10E-06.
A+UT:
The unit test performed and described in SESAR P15.02.07 D10 Verification
Plan and Report – Phase 2 section A2.2 uses the maximum BER level as a
reference to increase power levels until sensitivity level is achieved. Note that
it is acceptable to make measurements in terms of Packet Error Rate (PER) as
there exists a clear PER to BER translation depending on the packet size as
described in the future AeroMACS Technical Manual.
UT:
This requirement was tested by Hitachi and the results are compliant with the
specification. The detailed results are shown in Appendix B-4 of [8].
CP/1 WP03.1 Appendix D [Type text] [Type text]
- 40 -
AeroMACS SARPs:
Numbering and Text
Validation
method used
Validation
contributing
Partners
Validation conclusions/summary
7.5.5 SECURITY NVR
7.5.5.1 AeroMACS shall provide a
capability to protect the integrity
of messages in transit.
Note.— The capability includes
cryptographic mechanisms to provide
integrity of messages in transit.
IB, UT SESAR
Hitachi
IB:
The AeroMACS draft MASPS mandates in section 13 the support of
mechanisms and procedures to ensure message integrity and the
implementation of security association with cryptographic suites.
UT:
A unit test is described in SESAR P15.02.07 D10 Verification Plan and Report
– Phase 2 section A1.4 verifying that after authentication, the transmitted data
are properly encrypted, according to the required Private Key Management
Protocol. In addition, laboratory tests are described in SESAR P15.02.07 D06.2
Verification Report – Phase 1 in sections A.3 and A.9, which verify that BS
and MS are able to use encryption, and that encryption keys are correctly
distributed by the ASN-GW after authentication, respectively.
Hitachi tested and confirmed the use of the CMAC for MAC PDU exchange.
The detailed test results are described in Appendix B-5(2) of [8].
7.5.5.2 AeroMACS shall provide a
capability to protect the
availability of the system.
Note.— The capability includes
measures to ensure that the system
and its capacity are available for
authorized uses during unauthorized
events.
IB, UT SESAR
ACP WG S
IB:
The AeroMACS draft MASPS mandate in section 13 the integrity,
authentication and confidentiality mechanisms that aim to avoid loss of
availability due to flooding or DoS attacks.
UT:
Refer to UT in the section 7.5.5.5.
CP/1 WP03.1 Appendix D [Type text] [Type text]
- 41 -
AeroMACS SARPs:
Numbering and Text
Validation
method used
Validation
contributing
Partners
Validation conclusions/summary
7.5.5.3 AeroMACS shall provide a
capability to protect the
confidentiality of messages in
transit.
Note.— The capability includes
cryptographic mechanisms to provide
encryption/decryption of messages.
IB, UT SESAR
Hitachi
IB:
The AeroMACS draft MASPS mandates in section 13 the support of
mechanisms and procedures to provide transmission confidentiality and the
implementation of security association with cryptographic suites.
UT:
A unit test is described in SESAR P15.02.07 D10 Verification Plan and Report
– Phase 2 section A1.4 verifying that after authentication, the transmitted data
are properly encrypted, according to the required Private Key Management
Protocol. In addition, laboratory tests are described in SESAR P15.02.07 D06.2
Verification Report – Phase 1 in sections A.3 and A.9, which verify that BS
and MS are able to use encryption, and that encryption keys are correctly
distributed by the ASN-GW after authentication, respectively.
In the laboratory tests described in the P9.16 ACP-WG-S/6 WP06 [5] in
section 5.5, the test verified that AeroMACS MS Prototype were able, after Net
Entry and Authentication, to encrypt data according to the required Private Key
Management Protocol, demonstrating the requirement is achievable on the
A/C.
Hitachi tested and confirmed the use of the TEK field for data transfer. The
detailed test results are described in Appendix B-5(3) of [8].
7.5.5.4 AeroMACS shall provide an
authentication capability.
Note.— The capability includes
cryptographic mechanisms to provide
peer entity authentication, mutual
peer entity authentication, and data
origin authentication.
IB, UT SESAR
Hitachi
IB:
The AeroMACS draft MASPS mandates in section 13 the support of
mechanisms and procedures to provide protection against unauthorized entry
and perform device authentication.
UT:
A unit test is described in SESAR P15.02.07 D10 Verification Plan and Report
– Phase 2 section A1.4 verifying that EAP authentication is successfully
performed, and then the transmitted data are properly encrypted, according to
the required Private Key Management Protocol.
CP/1 WP03.1 Appendix D [Type text] [Type text]
- 42 -
AeroMACS SARPs:
Numbering and Text
Validation
method used
Validation
contributing
Partners
Validation conclusions/summary
In addition, laboratory tests are described in SESAR P15.02.07 D06.2
Verification Report – Phase 1 in sections A.3 and A.9, which verify that BS
and MS are able to use encryption, and that encryption keys are correctly
distributed by the ASN-GW after authentication, respectively.
In the laboratory tests described in the P9.16 ACP-WG-S/6 WP06 [5] in
sections 5.5, the test verified that AeroMACS MS Prototype support both Non-
Authentication and Authentication, EAP-based, mode of operations,
demonstrating the requirement is achievable.
UT:
Hitachi's authentication implementation makes use of EAP-TLS and key
encryption protocols to provide an authentication feature that is compliant with
IEEE802.16e and fully satisfies the SARPS requirement. The authentication
implementation has been verified in Hitachi's product development laboratory.
Further detail can be found in the Validation results in Appendix B 5(4) of[8].
7.5.5.5 AeroMACS shall provide a
capability to ensure the
authenticity of messages in
transit.
Note.— The capability includes
cryptographic mechanisms to
provide authenticity of messages
in transit.
IB, UT SESAR
HITACH
IB:
The AeroMACS draft MASPS mandates in section 13 the support of
mechanisms and procedures to ensure message integrity and the continuous
verification of the sender of the message, plus the implementation of security
association with cryptographic suites.
UT:
A unit test is described in SESAR P15.02.07 D10 Verification Plan and Report
– Phase 2 section A1.4 verifying that after authentication, the transmitted data
are properly encrypted, according to the required Private Key Management
Protocol. In addition, laboratory tests are described in SESAR P15.02.07 D06.2
Verification Report – Phase 1 in sections A.3 and A.9, which verify that BS
and MS are able to use encryption, and that encryption keys are correctly
distributed by the ASN-GW after authentication, respectively.
Hitachi also tested and confirmed the use of the CMAC for MAC PDU
exchange. The detailed test results are described in Appendix B-5(2) of [8].
CP/1 WP03.1 Appendix D [Type text] [Type text]
- 43 -
AeroMACS SARPs:
Numbering and Text
Validation
method used
Validation
contributing
Partners
Validation conclusions/summary
7.5.5.6 AeroMACS shall provide a
capability to authorize the
permitted actions of users of the
system.
Note.— The capability s includes
mechanisms to explicitly authorize
the actions of authenticated users.
Actions that are not explicitly
authorized are denied.
IB, UT SESAR IB:
The AeroMACS draft MASPS mandates in section 13 the support of
mechanisms and procedures to provide protection against unauthorized entry
and perform device authentication. In addition, it mandates the support of
security control mechanisms in order to avoid unauthorized users to reach and
get ATC/AOC/NET services and interact with other parts of the infrastructure.
UT:
The field test described by P15.02.07 D10 Verification Plan and Report –
Phase 2 A3.3 was configured with the certificates and other secret information
(password, …), it was correctly authenticated and authorized to communicate.
Without this mandatory information, the MS was not authorized to register.
7.5.5.7 If AeroMACS provides interfaces
to multiple domains, AeroMACS
shall provide capability to prevent
intrusion from lower integrity
domain to higher integrity
domain.
IB, A ACP WG S IB:
The AeroMACS draft MASPS mandates in section 13 the support of security
control mechanisms in order to avoid unauthorized users to reach and get
ATC/AOC/NET services and interact with other parts of the infrastructure. In
addition, the MASPS section 3 Network Architecture indicates that
AeroMACS avoids an attack to spread to multiple NSP domains since it only
allows the connectivity with a single NSP at a time for a given MS. Thus, an
intruder cannot spread an attack to various NSP since it would need to perform
different network entry procedures for different service providers.
A:
The Thales AeroMACS MS includes the following security mechanisms to the
interfaces:
- MAC Filer to prevent computers with specified MAC address from
accessing to MS
- User Access Control to limit the device usage by the user.
- IP Filter capability with either black or white rule based on protocol
type, source and destination IP, port range
Other mechanisms include IP filtering, Port filtering and Access control
through credential.
CP/1 WP03.1 Appendix D [Type text] [Type text]
- 44 -
AeroMACS SARPs:
Numbering and Text
Validation
method used
Validation
contributing
Partners
Validation conclusions/summary
7.6 SYSTEM INTERFACES NVR
7.6.1. AeroMACS shall provide data
service interface to the system
users.
UT SESAR UT:
In the SESAR testing, an Ethernet interface was implemented and tested on
both the THALES and SELEX prototypes. Ethernet interfaces exist between
the BS/MS equipment and their respective networks for control and data
payload communications. This is described in the Deliverable P15.02.07 D10
Verification Plan and Report – Phase 2 sections 3.5.2 and 3.5.3.’
7.6.2 AeroMACS shall support
notification of the status of
communications
Note.- this requirement could
support notification of the loss of
communications (such as join and
leave events)
IB, UT SESAR
Hitachi
ENRI
IB:
SESAR deliverable P15.02.07 D08-T8.1 Safety and Performance Analysis
indicates in section 5.2.2.5 the maximum delays for the ATC center to be
notified in case of an interruption of the service.
UT:
All developed prototypes have indicates (LEDs) to indicate status of
functionalities. In the tests described in the P9.16 ACP-WG-S/6 WP06 [5] in
sections 5.1, this requirement has been validated in laboratory by Logs
observation (and storage) from the network management and by the presence
of a dedicated LED, indicating the overall Net Entry Status starting from
AeroMACS MS scanning (LED=Yellow) and ending with the AeroMACS MS
registration on the AeroMACS Network after the acquisition of the IP address
through DHCP process (LED=Green), demonstrating the requirement is
achievable on the A/C.
ENRI validated the status of communication. Several LED indicate the status
of communication such as Power, Data, RSSI on the top of MSs. Those results
are provided in ACP WG-S/6 WP04, Section 3.2.
CP/1 WP03.1 Appendix D [Type text] [Type text]
- 45 -
AeroMACS SARPs:
Numbering and Text
Validation
method used
Validation
contributing
Partners
Validation conclusions/summary
7.7 APPLICATION
REQUIREMENTS
NVR
7.7.1 AeroMACS shall support
multiple classes of services to
provide appropriate service levels
to applications.
IB, A,S and
UT
SESAR
IB:
The draft AeroMACS MASPS mandates in sections 5.3 and 6.2 the support of
applications of type ATC, AOC and NET. In addition, section 4.3 indicates a
service classification of these applications in a scheme of 6 classes of service
(CoS). Each class of service supports a service level characterised by a set of
parameters such as minimum reserved bandwidth, maximum reserved
bandwidth, maximum delay, scheduling type or relative priority.
IB+A:
A section in the AeroMACS Technical Manual will also cover the AeroMACS
mechanisms to meet the QoS (including priority) of the supported applications
based on the EUROCONTROL/AT4W Technical Note 14 (Service Flow
Management and QoS Management in AeroMACS). Such note will cover the
mechanisms of prioritization of packets belonging to different service classes,
CoS parameter configuration and call admission control. The operation of these
features creates altogether a QoS scheme that clearly delimits the different
service levels and relative priorities of the existing traffic flows.
S:
In SESAR, there were analysis and simulations of the ability of the AeroMACS
data link to support multiple classes of service and these are reported in the
SESAR Deliverable P15.02.07 D04 AeroMACS deployment and Integration
Analysis in section 3 and the draft AeroMACS MASPS in section 12.1.2.2.
UT:
In SESAR there were also unit tests demonstrating the handling of messages
according to priority (two service flows of BE with different maximum
sustained traffic rate values) and this is covered in the SESAR Deliverables
P15.02.07 D10 Verification Plan and Report – Phase 2 (sections A1.3 and
A2.1) and P15.02.07 D06.2 Verification Report – Phase 1 (sections A.2 and
A.8) and in the P9.16 ACP-WG-S/6 WP06 [5] (sections 5.4 and 6.1.2.5).
CP/1 WP03.1 Appendix D [Type text] [Type text]
- 46 -
AeroMACS SARPs:
Numbering and Text
Validation
method used
Validation
contributing
Partners
Validation conclusions/summary
7.7.2 If there is a resource contention,
AeroMACS shall pre-empt lower
priority service(s) in favour of
higher priority service(s).
IB, A S, UT
SESAR
IB:
As reported previously, a section in the AeroMACS Technical Manual will
cover the AeroMACS mechanisms to meet the required QoS (including
priority) of the supported applications based on the EUROCONTROL/AT4W
Technical Note 14 (Service Flow Management and QoS Management in
AeroMACS).
IB+A:
In addition, AeroMACS MASPS section 4.3 indicates a service classification
of the different applications in a scheme of 6 classes of service (CoS). Each
class of service supports a service level characterised by a set of parameters
such as minimum reserved bandwidth, maximum reserved bandwidth,
maximum delay, scheduling type or relative priority. This CoS scheme makes
the scheduler handle priority mechanisms among the outgoing packets in the
queues according to the corresponding parameters and, if not enough resources
are available in the channel, pre-empt the scheduling of packets belonging to
classes of service of a lower level in favour of higher level classes of service.
S:
In SESAR, there were analysis and simulations of the ability of the AeroMACS
data link to support multiple classes of service and these are reported in the
SESAR Deliverable P15.02.07 D04 AeroMACS deployment and Integration
Analysis in section 3 and the draft AeroMACS MASPS in section 12.1.2.2. The
simulation shows how the higher classes of service (NET, ATC1 and ATC2)
comply with lower latency values than lower classes of service (AOCx).
UT:
SESAR P15.02.07 D10 Verification Plan and Report – Phase 2 section A1.3
verifies that all QoS related requirements are satisfied for different Scheduling
Types and for different traffic priorities, in both DL and UL directions. In the
laboratory tests described in P9.16 ACP-WG-S/6 WP06 [5] in section 5.4, the
test verified the capability of the AeroMACS MS prototype to assign high
priority service (SF data) more bandwidth than lower priority services (SF
data) demonstrating the requirement is achievable on the A/C.
CP/1 WP03.1 Appendix D [Type text] [Type text]
47
7. CONCLUSIONS OF VALIDATION ACTIVITIES
7.1 The AeroMACS data link is the customisation of the WiMAX system (which is based on the
IEEE 802.16 standard) to meet the aviation requirements of information exchanges while the
aircraft is on the airport surface.
7.2 WiMAX is a system that is already in operation and supporting mobile communications in
various countries since 2005. However, there are many features in WiMAX whose
implementation is optional and depending on the equipment manufacturer, the network
provider, or both and therefore compliance with the WiMAX standard alone would not
guarantee interoperability for aviation.
7.3 To address this issue, the aviation community has agreed on the AeroMACS profile. The
AeroMACS profile is specifying the minimum set of the required WiMAX features that are
need to be implemented in all AeroMACS implementations in order to support
interoperability in a regional and global level for aviation.
7.4 The AeroMACS SARPs aim to unambiguously identify the SARPs required to realise the
AeroMACS profile in terms of the “Signal in Space”. Furthermore, considering that the
WiMAX is in general a validated system being in operation, the validation of the AeroMACS
SARPs is effectively focusing on the validation of the identified AeroMACS Profile features
is not covering the general validation of the WiMAX system.
7.5 The analysis of the material presented in section 6 of this report, shows that multiple
AeroMACS testing activities have been conducted with different AeroMACS
implementations from different equipment manufacturers and in different countries.
7.6 There are many SARPs that have been tested by one or more different testing exercise and
there is testing evidence that these are met. However there are also SARPs for which limited
testing has been made and some for which only analysis is provided.
7.7 It is noted that a Technical Manual is being developed to provide further explanation and
guidance on the implementation as well as the testing in some cases, of some SARPs
requirements.
7.8 WGS considering all the information in section 6 considers that the AeroMACS SARPs are
validated.
CP/1 WP03.1 Appendix D [Type text] [Type text]
- 48 -
8. APPENDICES
Appendix 1: SESAR Project P15.02.07, Deliverable D06.2, AeroMACS Integration and Testing – Phase
1 Verification Report, version 00.01.00, 06/12/2013, SJU
Appendix 2: SESAR PROJECT P15.02.07, DELIVERABLE D10, AEROMACS VERIFICATION
PLAN AND REPORT – PHASE 2, DRAFT VERSION 00.00.07, NOVEMBER 2014
Appendix 3: Draft AeroMACS MASPS, version 0.19, EUROCAE WG82
9. REFERENCES
[1] ICAO ACP, UAT Validation Report, 2005, ICAO
[2a] SESAR Project P15.02.07, Deliverable D05.1, AeroMACS Ground Prototypes Description,
version 00.01.00, 23/05/2013, SJU
[2b] SESAR Project P15.02.07, Deliverable D05.2, AeroMACS Verification Strategy, version
00.01.00, 25/05/2013, SJU
[3a] SESAR Project P15.02.07, Deliverable D06.1, AeroMACS Integration and Testing – Phase 1
Verification Plan, version 00.01.00, 06/12/2013, SJU
[3b] SESAR Project P15.02.07, Deliverable D06.2, AeroMACS Integration and Testing – Phase 1
Verification Report, version 00.01.00, 06/12/2013, SJU
[4] SESAR Project P15.02.07, Deliverable D10, AeroMACS Verification Plan and Report – Phase 2,
Draft version 00.00.07, November 2014
[5] SESAR Project P9.16, Deliverable D11, AeroMACS System Final Validation Report, under
development (WP06 in the WGS/6 meeting is providing a summary of the P9.16 results to
support the SARPs validation)
[6a] SANDRA Project Deliverable 6.5.1 Report on Testing, 2013, SANDRA
[6b] SANDRA Project Deliverable 7.6.1 Evaluation results – Assessment and Recommendations,
2013, SANDRA
[7] ACP WG S Feb web meeting, WP01-NetworkEntryTime.doc, 21/2//2014.
[8] ACP WG S Jul meeting, IP04 - AeroMACS Validation Report from Hitachi_r9.doc, 14/7/2014.
[9] ACP WG S Sep web meeting, IP01_Validation Comments for Spectral Mask Specification from
Hitachi_r7.docx, 9/9/2014.
[10] ACP-WG-S/6 WP04 Throughput Evaluation of ENRI Prototype AeroMACS in Sendai
Airport.docx, 14/11/2014
CP/1 WP03.1 Appendix D [Type text] [Type text]
- 49 -
[11] EUROCAE WG82 May meeting, WP Preliminary evaluation for AeroMACS prototype Mobile
Station “20140509EUROCAE_WG82.pdf”, 11/5/2014,
[12] NASA/CR—2011-216997/VOL2 - C-Band Airport Surface Communications System Standards
Development, Phase II Final Report, Volume 2: Test Bed Performance Evaluation and Final
AeroMACS Recommendations
[13] Mobile Satellite Service Interference Analysis for AeroMACS Base Stations
[14] ACP-WG-S/6 WP09 Field Trial and Test Results, 14/11/2014
[15] New ATM Requirements - Future Communications, C-Band and L-Band Communications Study
SE2020 TO 0008 (TORP 1240) Task 1, AeroMACS Interference Reduction and Spectrum
Studies. SE2020 TO 0007 (TORP 1252)