rfc9372.original | rfc9372.txt | |||
---|---|---|---|---|
RAW N. Mäurer, Ed. | Internet Engineering Task Force (IETF) N. Mäurer, Ed. | |||
Internet-Draft T. Gräupl, Ed. | Request for Comments: 9372 T. Gräupl, Ed. | |||
Intended status: Informational German Aerospace Center (DLR) | Category: Informational German Aerospace Center (DLR) | |||
Expires: 5 June 2023 C. Schmitt, Ed. | ISSN: 2070-1721 C. Schmitt, Ed. | |||
Research Institute CODE, UniBwM | Research Institute CODE, UniBwM | |||
2 December 2022 | March 2023 | |||
L-band Digital Aeronautical Communications System (LDACS) | L-Band Digital Aeronautical Communications System (LDACS) | |||
draft-ietf-raw-ldacs-14 | ||||
Abstract | Abstract | |||
This document gives an overview of the architecture of the L-band | This document gives an overview of the L-band Digital Aeronautical | |||
Digital Aeronautical Communications System (LDACS), which provides a | Communications System (LDACS) architecture, which provides a secure, | |||
secure, scalable and spectrum efficient terrestrial data link for | scalable, and spectrum-efficient terrestrial data link for civil | |||
civil aviation. LDACS is a scheduled, reliable multi-application | aviation. LDACS is a scheduled and reliable multi-application | |||
cellular broadband system with support for IPv6. It is part of a | cellular broadband system with support for IPv6. It is part of a | |||
larger shift of flight guidance communication moving to IP-based | larger shift of flight guidance communication moving to IP-based | |||
communication. High reliability and availability of IP connectivity | communication. High reliability and availability of IP connectivity | |||
over LDACS, as well as security, are therefore essential. The intent | over LDACS, as well as security, are therefore essential. The intent | |||
of this document is to introduce LDACS to the IETF community, raise | of this document is to introduce LDACS to the IETF community, raise | |||
awareness on related activities inside and outside of the IETF, and | awareness on related activities inside and outside of the IETF, and | |||
to seek expertise in shaping the shift of aeronautics to IP. | to seek expertise in shaping the shift of aeronautics to IP. | |||
Status of This Memo | Status of This Memo | |||
This Internet-Draft is submitted in full conformance with the | This document is not an Internet Standards Track specification; it is | |||
provisions of BCP 78 and BCP 79. | published for informational purposes. | |||
Internet-Drafts are working documents of the Internet Engineering | ||||
Task Force (IETF). Note that other groups may also distribute | ||||
working documents as Internet-Drafts. The list of current Internet- | ||||
Drafts is at https://datatracker.ietf.org/drafts/current/. | ||||
Internet-Drafts are draft documents valid for a maximum of six months | This document is a product of the Internet Engineering Task Force | |||
and may be updated, replaced, or obsoleted by other documents at any | (IETF). It represents the consensus of the IETF community. It has | |||
time. It is inappropriate to use Internet-Drafts as reference | received public review and has been approved for publication by the | |||
material or to cite them other than as "work in progress." | Internet Engineering Steering Group (IESG). Not all documents | |||
approved by the IESG are candidates for any level of Internet | ||||
Standard; see Section 2 of RFC 7841. | ||||
This Internet-Draft will expire on 5 June 2023. | Information about the current status of this document, any errata, | |||
and how to provide feedback on it may be obtained at | ||||
https://www.rfc-editor.org/info/rfc9372. | ||||
Copyright Notice | Copyright Notice | |||
Copyright (c) 2022 IETF Trust and the persons identified as the | Copyright (c) 2023 IETF Trust and the persons identified as the | |||
document authors. All rights reserved. | document authors. All rights reserved. | |||
This document is subject to BCP 78 and the IETF Trust's Legal | This document is subject to BCP 78 and the IETF Trust's Legal | |||
Provisions Relating to IETF Documents (https://trustee.ietf.org/ | Provisions Relating to IETF Documents | |||
license-info) in effect on the date of publication of this document. | (https://trustee.ietf.org/license-info) in effect on the date of | |||
Please review these documents carefully, as they describe your rights | publication of this document. Please review these documents | |||
and restrictions with respect to this document. Code Components | carefully, as they describe your rights and restrictions with respect | |||
extracted from this document must include Revised BSD License text as | to this document. Code Components extracted from this document must | |||
described in Section 4.e of the Trust Legal Provisions and are | include Revised BSD License text as described in Section 4.e of the | |||
provided without warranty as described in the Revised BSD License. | Trust Legal Provisions and are provided without warranty as described | |||
in the Revised BSD License. | ||||
Table of Contents | Table of Contents | |||
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 | 1. Introduction | |||
2. Acronyms . . . . . . . . . . . . . . . . . . . . . . . . . . 5 | 2. Acronyms | |||
3. Motivation and Use Cases . . . . . . . . . . . . . . . . . . 7 | 3. Motivation and Use Cases | |||
3.1. Voice Communications Today . . . . . . . . . . . . . . . 7 | 3.1. Voice Communications Today | |||
3.2. Data Communications Today . . . . . . . . . . . . . . . . 8 | 3.2. Data Communications Today | |||
4. Provenance and Documents . . . . . . . . . . . . . . . . . . 8 | 4. Provenance and Documents | |||
5. Applicability . . . . . . . . . . . . . . . . . . . . . . . . 9 | 5. Applicability | |||
5.1. Advances Beyond the State-of-the-Art . . . . . . . . . . 10 | 5.1. Advances beyond the State of the Art | |||
5.1.1. Priorities . . . . . . . . . . . . . . . . . . . . . 10 | 5.1.1. Priorities | |||
5.1.2. Security . . . . . . . . . . . . . . . . . . . . . . 10 | 5.1.2. Security | |||
5.1.3. High Data Rates . . . . . . . . . . . . . . . . . . . 10 | 5.1.3. High Data Rates | |||
5.2. Application . . . . . . . . . . . . . . . . . . . . . . . 11 | 5.2. Application | |||
5.2.1. Air/Ground Multilink . . . . . . . . . . . . . . . . 11 | 5.2.1. Air/Ground Multilink | |||
5.2.2. Air/Air Extension for LDACS . . . . . . . . . . . . . 11 | 5.2.2. Air/Air Extension for LDACS | |||
5.2.3. Flight Guidance . . . . . . . . . . . . . . . . . . . 12 | 5.2.3. Flight Guidance | |||
5.2.4. Business Communications of Airlines . . . . . . . . . 13 | 5.2.4. Business Communications of Airlines | |||
5.2.5. LDACS-based Navigation . . . . . . . . . . . . . . . 13 | 5.2.5. LDACS-Based Navigation | |||
6. Requirements . . . . . . . . . . . . . . . . . . . . . . . . 14 | 6. Requirements | |||
7. Characteristics . . . . . . . . . . . . . . . . . . . . . . . 15 | 7. Characteristics | |||
7.1. LDACS Access Network . . . . . . . . . . . . . . . . . . 16 | 7.1. LDACS Access Network | |||
7.2. Topology . . . . . . . . . . . . . . . . . . . . . . . . 16 | 7.2. Topology | |||
7.3. LDACS Protocol Stack . . . . . . . . . . . . . . . . . . 17 | 7.3. LDACS Protocol Stack | |||
7.3.1. LDACS Physical Layer . . . . . . . . . . . . . . . . 18 | 7.3.1. LDACS Physical Layer | |||
7.3.2. LDACS Data Link Layer . . . . . . . . . . . . . . . . 19 | 7.3.2. LDACS Data Link Layer | |||
7.3.3. LDACS Sub-Network Layer and Protocol Services . . . . 20 | 7.3.3. LDACS Subnetwork Layer and Protocol Services | |||
7.4. LDACS Mobility . . . . . . . . . . . . . . . . . . . . . 21 | 7.4. LDACS Mobility | |||
7.5. LDACS Management - Interfaces and Protocols . . . . . . . 21 | 7.5. LDACS Management Interfaces and Protocols | |||
8. Reliability and Availability . . . . . . . . . . . . . . . . 21 | 8. Reliability and Availability | |||
8.1. Below Layer 1 . . . . . . . . . . . . . . . . . . . . . . 22 | 8.1. Below Layer 1 | |||
8.2. Layer 1 and 2 . . . . . . . . . . . . . . . . . . . . . . 22 | 8.2. Layers 1 and 2 | |||
8.3. Beyond Layer 2 . . . . . . . . . . . . . . . . . . . . . 25 | 8.3. Beyond Layer 2 | |||
9. Security . . . . . . . . . . . . . . . . . . . . . . . . . . 25 | 9. Security Considerations | |||
9.1. Security in Wireless Digital Aeronautical | 9.1. Security in Wireless Digital Aeronautical Communications | |||
Communications . . . . . . . . . . . . . . . . . . . . . 26 | 9.2. Security in Depth | |||
9.2. Security in Depth . . . . . . . . . . . . . . . . . . . . 27 | 9.3. LDACS Security Requirements | |||
9.3. LDACS Security Requirements . . . . . . . . . . . . . . . 27 | 9.4. LDACS Security Objectives | |||
9.4. LDACS Security Objectives . . . . . . . . . . . . . . . . 28 | 9.5. LDACS Security Functions | |||
9.5. LDACS Security Functions . . . . . . . . . . . . . . . . 28 | 9.6. LDACS Security Architecture | |||
9.6. LDACS Security Architecture . . . . . . . . . . . . . . . 28 | 9.6.1. Entities | |||
9.6.1. Entities . . . . . . . . . . . . . . . . . . . . . . 29 | 9.6.2. Entity Identification | |||
9.6.2. Entity Identification . . . . . . . . . . . . . . . . 29 | 9.6.3. Entity Authentication and Key Establishment | |||
9.6.3. Entity Authentication and Key Establishment . . . . . 29 | 9.6.4. Message-In-Transit Confidentiality, Integrity, and | |||
9.6.4. Message-in-transit Confidentiality, Integrity and | Authenticity | |||
Authenticity . . . . . . . . . . . . . . . . . . . . 30 | ||||
9.7. Considerations on LDACS Security Impact on IPv6 Operational | 9.7. Considerations on LDACS Security Impact on IPv6 Operational | |||
Security . . . . . . . . . . . . . . . . . . . . . . . . 30 | Security | |||
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 31 | 10. IANA Considerations | |||
11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 31 | 11. Informative References | |||
12. Normative References . . . . . . . . . . . . . . . . . . . . 31 | Appendix A. Selected Information from DO-350A | |||
13. Informative References . . . . . . . . . . . . . . . . . . . 31 | Acknowledgements | |||
Appendix A. Selected Information from DO-350A . . . . . . . . . 39 | Authors' Addresses | |||
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 41 | ||||
1. Introduction | 1. Introduction | |||
One of the main pillars of the modern Air Traffic Management (ATM) | One of the main pillars of the modern Air Traffic Management (ATM) | |||
system is the existence of a communications infrastructure that | system is the existence of a communications infrastructure that | |||
enables efficient aircraft control and safe aircraft separation in | enables efficient aircraft control and safe aircraft separation in | |||
all phases of flight. Current systems are technically mature but | all phases of flight. Current systems are technically mature, but | |||
suffering from the Very High Frequency (VHF) band's increasing | they are suffering from the Very High Frequency (VHF) band's | |||
saturation in high-density areas and the limitations posed by | increasing saturation in high-density areas and the limitations posed | |||
analogue radio communications. Therefore, aviation strives for a | by analog radio communications. Therefore, aviation strives for a | |||
sustainable modernization of the aeronautical communications | sustainable modernization of the aeronautical communications | |||
infrastructure on the basis of IP. | infrastructure on the basis of IP. | |||
This modernization is realized in two steps: (1) the transition of | This modernization is realized in two steps: (1) the transition of | |||
communications datalinks from analogue to digital technologies and, | communications data links from analog to digital technologies and (2) | |||
(2) the introduction of IPv6 based networking protocols [RFC8200] in | the introduction of IPv6-based networking protocols [RFC8200] in | |||
aeronautical networks [ICAO2015]. | aeronautical networks [ICAO2015]. | |||
Step (1) is realized via ATM communications transitioning from | Step (1) is realized via ATM communications transitioning from analog | |||
analogue VHF voice [KAMA2010] to more spectrum efficient digital data | VHF voice [KAMA2010] to more spectrum-efficient digital data | |||
communication. For terrestrial communications the International | communication. For terrestrial communications, the Global Air | |||
Civil Aviation Organization (ICAO)'s Global Air Navigation Plan | Navigation Plan (GANP) created by the International Civil Aviation | |||
(GANP) foresees this transition to be realized by the development of | Organization (ICAO) foresees this transition to be realized by the | |||
the L-band Digital Aeronautical Communications System (LDACS). Since | development of the L-band Digital Aeronautical Communications System | |||
Central Europe has been identified as the area of the world that | (LDACS). Since Central Europe has been identified as the area of the | |||
suffers the most from increased saturation of the VHF band, the | world that suffers the most from increased saturation of the VHF | |||
initial roll-out of LDACS will likely start there, and continue to | band, the initial rollout of LDACS will likely start there and | |||
other increasingly saturated zones as the East and West Coast of the | continue to other increasingly saturated zones such as the East and | |||
US and parts of Asia [ICAO2018]. | West Coast of the US and parts of Asia [ICAO2018]. | |||
Technically LDACS enables IPv6-based air-ground communication related | Technically, LDACS enables IPv6-based Air/Ground (A/G) communication | |||
to aviation safety and regularity of flight [ICAO2015]. Passenger | related to aviation safety and regularity of flight [ICAO2015]. | |||
communication and similar services are not supported, since only | Passenger communication and similar services are not supported since | |||
communications related to "safety and regularity of flight" are | only communications related to "safety and regularity of flight" are | |||
permitted in protected aviation frequency bands. The particular | permitted in protected aviation frequency bands. The particular | |||
challenge is that no additional frequencies can be made available for | challenge is that no additional frequencies can be made available for | |||
terrestrial aeronautical communication. It was thus necessary to | terrestrial aeronautical communication; thus, it was necessary to | |||
develop co-existence mechanism/procedures to enable the interference | develop coexistence mechanisms and procedures to enable the | |||
free operation of LDACS in parallel with other aeronautical services/ | interference-free operation of LDACS in parallel with other | |||
systems in the protected frequency band. Since LDACS will be used | aeronautical services and systems in the protected frequency band. | |||
for aircraft guidance, high reliability and availability for IP | Since LDACS will be used for aircraft guidance, high reliability and | |||
connectivity over LDACS are essential. | availability for IP connectivity over LDACS are essential. | |||
LDACS is standardized in ICAO and European Organization for Civil | LDACS is standardized in ICAO and the European Organization for Civil | |||
Aviation Equipment (EUROCAE). | Aviation Equipment (EUROCAE). | |||
This document provides information to the IETF community about the | This document provides information to the IETF community about the | |||
aviation industry transition of flight guidance systems from analog | aviation industry transition of flight guidance systems from analog | |||
to digital, provides context for LDACS relative to related IETF | to digital, provides context for LDACS relative to related IETF | |||
activities [I-D.haindl-lisp-gb-atn], and seeks expertise on realizing | activities [LISP-GB-ATN], and seeks expertise on realizing reliable | |||
reliable IPv6 over LDACS for step (1). This document does not intend | IPv6 over LDACS for step (1). This document does not intend to | |||
to advance LDACS as an IETF standards-track document. | advance LDACS as an IETF Standards Track document. | |||
Step (2) is a strategy for the worldwide roll-out of IPv6 capable | Step (2) is a strategy for the worldwide rollout of IPv6-capable | |||
digital aeronautical inter-networking. This is called the | digital aeronautical internetworking. This is called the | |||
Aeronautical Telecommunications Network (ATN)/Internet Protocol Suite | Aeronautical Telecommunications Network (ATN) / Internet Protocol | |||
(IPS) (hence, ATN/IPS). It is specified in the International Civil | Suite (IPS) (hence, ATN/IPS). It is specified in the ICAO document | |||
Aviation Organization (ICAO) document Doc 9896 [ICAO2015], the Radio | Doc 9896 [ICAO2015], the Radio Technical Commission for Aeronautics | |||
Technical Commission for Aeronautics (RTCA) document DO-379 | (RTCA) document DO-379 [RTCA2019], the EUROCAE document ED-262 | |||
[RTCA2019], the EUROCAE document ED-262 [EURO2019], and the | [EURO2019], and the Aeronautical Radio Incorporated (ARINC) document | |||
Aeronautical Radio Incorporated (ARINC) document P858 [ARI2021]. | 858 [ARI2021]. LDACS is subject to these regulations since it | |||
LDACS is subject to these regulations since it provides an "access | provides an "access network" (link-layer data link) to the ATN/IPS. | |||
network" - link-layer datalink - to the ATN/IPS. | ||||
ICAO has chosen IPv6 as basis for the ATN/IPS mostly for historical | ICAO has chosen IPv6 as a basis for the ATN/IPS mostly for historical | |||
reasons, since a previous architecture based on ISO/OSI protocols, | reasons since a previous architecture based on ISO/OSI protocols (the | |||
the ATN/OSI, failed in the marketplace. | ATN/OSI) failed in the marketplace. | |||
In the context of safety-related communications, LDACS will play a | In the context of safety-related communications, LDACS will play a | |||
major role in future ATM. ATN/IPS datalinks will provide diversified | major role in future ATM. ATN/IPS data links will provide | |||
terrestrial and space-based connectivity in a multilink concept, | diversified terrestrial and space-based connectivity in a multilink | |||
called the Future Communications Infrastructure (FCI) [VIR2021]. | concept called the Future Communications Infrastructure (FCI) | |||
From a technical point of view the FCI will realize airborne multi- | [VIR2021]. From a technical point of view, the FCI will realize | |||
homed IPv6 networks connected to a global ground network via at least | airborne and multihomed IPv6 networks connected to a global ground | |||
two independent communication technologies. This is considered in | network via at least two independent communication technologies. | |||
more detail in related IETF work in progress [I-D.haindl-lisp-gb-atn] | This is considered in more detail in related IETF documents | |||
[I-D.ietf-rtgwg-atn-bgp]. As such, ICAO has actively sought out the | [LISP-GB-ATN] [RTGWG-ATN-BGP]. As such, ICAO has actively sought out | |||
support of IETF to define a mobility solution for step (2), which is | the support of IETF to define a mobility solution for step (2), which | |||
currently the Locator/ID Separation Protocol (LISP). | is currently the Locator/ID Separation Protocol (LISP). | |||
In the context of the Reliable and Available Wireless (RAW) working | In the context of the Reliable and Available Wireless (RAW) Working | |||
group, developing options, such as intelligent switching between | Group, developing options, such as intelligent switching between data | |||
datalinks, for reliably delivering content from and to endpoints, is | links, for reliably delivering content from and to endpoints is | |||
foreseen. As LDACS is part of such a concept, the work of RAW is | foreseen. As LDACS is part of such a concept, the work of RAW is | |||
immediately applicable. In general, with the aeronautical | immediately applicable. In general, with the aeronautical | |||
communications system transitioning to ATN/IPS, and data being | communications system transitioning to ATN/IPS and data being | |||
transported via IPv6, closer cooperation and collaboration between | transported via IPv6, closer cooperation and collaboration between | |||
the aeronautical and IETF community is desirable. | the aeronautical and IETF community is desirable. | |||
LDACS standardization within the framework of ICAO started in | LDACS standardization within the framework of ICAO started in | |||
December 2016. The ICAO standardization group has produced the final | December 2016. As of 2022, the ICAO standardization group has | |||
Standards and Recommended Practices (SARPS) document as of 2022 | produced the final Standards and Recommended Practices (SARPS) | |||
[ICAO2022]. It defines the general characteristics of LDACS. By the | document [ICAO2022] that defines the general characteristics of | |||
end of 2023, the ICAO standardization group plans to have developed | LDACS. By the end of 2023, the ICAO standardization group plans to | |||
an ICAO technical manual - the ICAO equivalent to a technical | have developed an ICAO technical manual, which is the ICAO equivalent | |||
standard. As such LDACS standardization is not finished yet, and | to a technical standard. The LDACS standardization is not finished | |||
therefore this document is a snapshot of current status. The | yet; therefore, this document is a snapshot of the current status. | |||
physical characteristics of an LDACS installation (form, fit, and | The physical characteristics of an LDACS installation (form, fit, and | |||
function) will be standardized by EUROCAE. Generally, the group is | function) will be standardized by EUROCAE. Generally, the group is | |||
open to input from all sources and encourages cooperation between the | open to input from all sources and encourages cooperation between the | |||
aeronautical and the IETF community. | aeronautical and IETF communities. | |||
2. Acronyms | 2. Acronyms | |||
The following terms are used in the context of RAW in this document: | The following terms are used in the context of RAW in this document: | |||
A/A Air/Air | A/A: Air/Air | |||
A/G Air/Ground | A/G: Air/Ground | |||
A2G Air-to-Ground | A2G: Air-to-Ground | |||
ACARS Aircraft Communications Addressing and Reporting System | ACARS: Aircraft Communications Addressing and Reporting System | |||
AC-R Access Router | AC-R: Access Router | |||
ADS-B Automatic Dependent Surveillance - Broadcast | ADS-B: Automatic Dependent Surveillance - Broadcast | |||
ADS-C Automatic Dependent Surveillance - Contract | ADS-C: Automatic Dependent Surveillance - Contract | |||
AeroMACS Aeronautical Mobile Airport Communications System | AeroMACS: Aeronautical Mobile Airport Communications System | |||
ANSP Air Traffic Network Service Provider | ANSP: Air Traffic Network Service Provider | |||
AOC Aeronautical Operational Control | AOC: Aeronautical Operational Control | |||
ARINC Aeronautical Radio, Incorporated | ARINC: Aeronautical Radio Incorporated | |||
ARQ Automatic Repeat reQuest | ARQ: Automatic Repeat reQuest | |||
AS Aircraft Station | AS: Aircraft Station | |||
ATC Air Traffic Control | ATC: Air Traffic Control | |||
ATM Air Traffic Management | ATM: Air Traffic Management | |||
ATN Aeronautical Telecommunication Network | ATN: Aeronautical Telecommunications Network | |||
ATS Air Traffic Service | ATS: Air Traffic Service | |||
BCCH Broadcast Channel | BCCH: Broadcast Channel | |||
CCCH Common Control Channel | CCCH: Common Control Channel | |||
CM Context Management | CM: Context Management | |||
CNS Communication Navigation Surveillance | CNS: Communication Navigation Surveillance | |||
COTS Commercial Off-The-Shelf | COTS: Commercial Off-The-Shelf | |||
CPDLC Controller Pilot Data Link Communications | CPDLC: Controller-Pilot Data Link Communications | |||
CRL Certificate Revocation List | CSP: Communications Service Provider | |||
CSP Communications Service Provider | DCCH: Dedicated Control Channel | |||
DCCH Dedicated Control Channel | DCH: Data Channel | |||
DCH Data Channel | Diffserv: Differentiated Services | |||
DiffServ Differentiated Services | DLL: Data Link Layer | |||
DLL Data Link Layer | DLS: Data Link Service | |||
DLS Data Link Service | DME: Distance Measuring Equipment | |||
DME Distance Measuring Equipment | DSB-AM: Double Side-Band Amplitude Modulation | |||
DSB-AM Double Side-Band Amplitude Modulation | DTLS: Datagram Transport Layer Security | |||
DTLS Datagram Transport Layer Security | EUROCAE: European Organization for Civil Aviation Equipment | |||
EUROCAE European Organization for Civil Aviation Equipment | FAA: Federal Aviation Administration | |||
FAA Federal Aviation Administration | FCI: Future Communications Infrastructure | |||
FCI Future Communications Infrastructure | FDD: Frequency Division Duplex | |||
FDD Frequency Division Duplex | FL: Forward Link | |||
FL Forward Link | GANP: Global Air Navigation Plan | |||
GANP Global Air Navigation Plan | GBAS: Ground-Based Augmentation System | |||
GBAS Ground Based Augmentation System | GNSS: Global Navigation Satellite System | |||
GNSS Global Navigation Satellite System | GS: Ground-Station | |||
GS Ground-Station | G2A: Ground-to-Air | |||
G2A Ground-to-Air | HF: High Frequency | |||
HF High Frequency | ICAO: International Civil Aviation Organization | |||
ICAO International Civil Aviation Organization | IP: Internet Protocol | |||
IP Internet Protocol | IPS: Internet Protocol Suite | |||
IPS Internet Protocol Suite | kbit/s: kilobit per second | |||
kbit/s kilobit per second | LDACS: L-band Digital Aeronautical Communications System | |||
LDACS L-band Digital Aeronautical Communications System | LISP: Locator/ID Separation Protocol | |||
LISP Locator/ID Separation Protocol | LLC: Logical Link Control | |||
LLC Logical Link Control | LME: LDACS Management Entity | |||
LME LDACS Management Entity | MAC: Medium Access Control | |||
MAC Medium Access Control | MF: Multiframe | |||
MF Multi Frame | NETCONF: Network Configuration Protocol | |||
NETCONF NETCONF Network Configuration Protocol | OFDM: Orthogonal Frequency Division Multiplexing | |||
OFDM Orthogonal Frequency-Division Multiplexing | OFDMA: Orthogonal Frequency Division Multiplexing Access | |||
OFDMA Orthogonal Frequency-Division Multiplexing Access | OSI: Open Systems Interconnection | |||
OSI Open Systems Interconnection | PHY: Physical Layer | |||
PHY Physical Layer | QPSK: Quadrature Phase-Shift Keying | |||
QPSK Quadrature Phase-Shift Keying | RACH: Random-Access Channel | |||
RACH Random-Access Channel | RL: Reverse Link | |||
RL Reverse Link | RTCA: Radio Technical Commission for Aeronautics | |||
RTCA Radio Technical Commission for Aeronautics | SARPS: Standards and Recommended Practices | |||
SARPS Standards and Recommended Practices | SDR: Software-Defined Radio | |||
SDR Software Defined Radio | SESAR: Single European Sky ATM Research | |||
SESAR Single European Sky ATM Research | SF: Super-Frame | |||
SF Super-Frame | SNMP: Simple Network Management Protocol | |||
SNMP Simple Network Management Protocol | SNP: Subnetwork Protocol | |||
SNP Sub-Network Protocol | VDLm2: VHF Data Link mode 2 | |||
VDLm2 VHF Data Link mode 2 | VHF: Very High Frequency | |||
VHF Very High Frequency | VI: Voice Interface | |||
VI Voice Interface | ||||
3. Motivation and Use Cases | 3. Motivation and Use Cases | |||
Aircraft are currently connected to Air Traffic Control (ATC) and | Aircraft are currently connected to Air Traffic Control (ATC) and | |||
Aeronautical Operational Control (AOC) services via voice and data | Aeronautical Operational Control (AOC) services via voice and data | |||
communications systems through all phases of flight. ATC refers to | communications systems through all phases of flight. ATC refers to | |||
communication for flight guidance. AOC is a generic term referring | communication for flight guidance. AOC is a generic term referring | |||
to the business communication of airlines. It refers to the mostly | to the business communication of airlines and refers to the mostly | |||
proprietary exchange of data between the aircraft of the airline and | proprietary exchange of data between the aircraft of the airline and | |||
the airline's operation centers and service partners. The ARINC | the airline's operation centers and service partners. The ARINC | |||
document 633 was developed and first released in 2007 [ARI2019] with | document 633 was developed and first released in 2007 [ARI2019] with | |||
the goal to standardize these messages for interoperability, e.g., | the goal to standardize these messages for interoperability, e.g., | |||
messages between the airline and fueling or de-icing companies. | messages between the airline and fueling or de-icing companies. | |||
Within the airport and terminal area, connectivity is focused on high | Within the airport and terminal area, connectivity is focused on high | |||
bandwidth communications. In the En-Route domain, however, high | bandwidth communications. However, in the en route domain, high | |||
reliability, robustness, and range are the main foci. Voice | reliability, robustness, and range are the main foci. Voice | |||
communications may use the same or different equipment as data | communications may use the same or different equipment as data | |||
communications systems. In the following, the main differences | communications systems. In the following, the main differences | |||
between voice and data communications capabilities are summarized. | between voice and data communications capabilities are summarized. | |||
The assumed list of use cases for LDACS complements the list of use | The assumed list of use cases for LDACS complements the list of use | |||
cases stated in [RAW-USE-CASES] and the list of reliable and | cases stated in [RAW-USE-CASES] and the list of reliable and | |||
available wireless technologies presented in [RAW-TECHNOS]. | available wireless technologies presented in [RAW-TECHNOS]. | |||
3.1. Voice Communications Today | 3.1. Voice Communications Today | |||
Voice links are used for Air/Ground (A/G) and Air/Air (A/A) | Voice links are used for Air/Ground (A/G) and Air/Air (A/A) | |||
communications. The communications equipment can be installed on | communications. The communications equipment can be installed on | |||
ground or in the aircraft, in which cases the High Frequency (HF) or | ground or in the aircraft, in which cases the High Frequency (HF) or | |||
VHF frequency band is used. For remote domains voice communications | VHF frequency band is used. For remote domains, voice communications | |||
can also be satellite-based. All VHF and HF voice communications are | can also be satellite-based. All VHF and HF voice communications are | |||
operated via open broadcast channels without authentication, | operated via open Broadcast Channels (BCCHs) without authentication, | |||
encryption or other protective measures. The use of well-proven | encryption, or other protective measures. The use of well-proven | |||
communications procedures via broadcast channels, such as phraseology | communications procedures via BCCHs, such as phraseology or read- | |||
or read-backs, requiring well-trained personnel, help to enhance the | backs, requiring well-trained personnel help to enhance the safety of | |||
safety of communications, but does not replace necessary | communications but does not replace necessary cryptographical | |||
cryptographical security mechanisms. The main voice communications | security mechanisms. The main voice communications media is still | |||
media is still the analogue VHF Double Side-Band Amplitude Modulation | the analog VHF Double Side-Band Amplitude Modulation (DSB-AM) | |||
(DSB-AM) communications technique, supplemented by HF single side- | communications technique supplemented by HF single side-band | |||
band amplitude modulation and satellite communications for remote and | amplitude modulation and satellite communications for remote and | |||
oceanic regions. DSB-AM has been in use since 1948, works reliably | oceanic regions. DSB-AM has been in use since 1948, works reliably | |||
and safely, and uses low-cost communication equipment. These are the | and safely, and uses low-cost communication equipment. These are the | |||
main reasons why VHF DSB-AM communications are still in use, and it | main reasons why VHF DSB-AM communications are still in use, and it | |||
is likely that this technology will remain in service for many more | is likely that this technology will remain in service for many more | |||
years. This however, results in current operational limitations and | years. However, this results in current operational limitations and | |||
impediments in deploying new ATM applications, such as flight-centric | impediments in deploying new ATM applications, such as flight-centric | |||
operation with point-to-point communications between pilots and air | operation with point-to-point communications between pilots and ATC | |||
traffic control officers. [BOE2019] | officers [BOE2019]. | |||
3.2. Data Communications Today | 3.2. Data Communications Today | |||
Like for voice, data communications into the cockpit, are currently | Like for voice communications, data communications into the cockpit | |||
provided by ground-based equipment operating either on HF or VHF | are currently provided by ground-based equipment operating either on | |||
radio bands or by legacy satellite systems. All these communication | HF or VHF radio bands or by legacy satellite systems. All these | |||
systems use narrowband radio channels with a data throughput capacity | communication systems use narrowband radio channels with a data | |||
in the order of kbit/s. While the aircraft is on the ground, some | throughput capacity in the order of kbit/s. Additional | |||
additional communications systems are available, like the | communications systems are available while the aircraft is on the | |||
Aeronautical Mobile Airport Communications System (AeroMACS) or | ground, such as the Aeronautical Mobile Airport Communications System | |||
public cellular networks, operating in the Airport (APT) domain and | (AeroMACS) or public cellular networks, that operate in the Airport | |||
able to deliver broadband communications capability. [BOE2019] | (APT) domain and are able to deliver broadband communications | |||
capability [BOE2019]. | ||||
For regulatory reasons, the data communications networks, used for | For regulatory reasons, the data communications networks used for the | |||
the transmission of data relating to the safety and regularity of | transmission of data relating to the safety and regularity of flight | |||
flight, must be strictly isolated from those providing entertainment | must be strictly isolated from those providing entertainment services | |||
services to passengers. This leads to a situation that the flight | to passengers. This leads to a situation where the flight crews are | |||
crews are supported by narrowband services during flight while | supported by narrowband services during flight while passengers have | |||
passengers have access to inflight broadband services. The current | access to in-flight broadband services. The current HF and VHF data | |||
HF and VHF data links cannot provide broadband services now or in the | links cannot provide broadband services now or in the future due to | |||
future, due to the lack of available spectrum. This technical | the lack of available spectrum. This technical shortcoming is | |||
shortcoming is becoming a limitation to enhanced ATM operations, such | becoming a limitation to enhanced ATM operations, such as trajectory- | |||
as trajectory-based operations and 4D trajectory negotiations. | based operations and 4D trajectory negotiations [BOE2019]. | |||
[BOE2019] | ||||
Satellite-based communications are currently under investigation and | Satellite-based communications are currently under investigation, and | |||
enhanced capabilities are under development which will be able to | enhanced capabilities that will be able to provide in-flight | |||
provide inflight broadband services and communications supporting the | broadband services and communications supporting the safety and | |||
safety and regularity of flight. In parallel the ground-based | regularity of flight are under development. In parallel, the ground- | |||
broadband data link technology LDACS is being standardized by ICAO | based broadband data link technology LDACS is being standardized by | |||
and has recently shown its maturity during flight tests [MAE20211] | ICAO and has recently shown its maturity during flight tests | |||
[BEL2021]. The LDACS technology is scalable, secure and spectrum | [MAE20211] [BEL2021]. The LDACS technology is scalable, secure, and | |||
efficient and provides significant advantages to the users and | spectrum-efficient, and it provides significant advantages to the | |||
service providers. It is expected that both - satellite systems and | users and service providers. It is expected that both satellite | |||
LDACS - will be deployed to support the future aeronautical | systems and LDACS will be deployed to support the future aeronautical | |||
communication needs as envisaged by the ICAO Global Air Navigation | communication needs as envisaged by the ICAO GANP [BOE2019]. | |||
Plan (GNAP). [BOE2019] | ||||
4. Provenance and Documents | 4. Provenance and Documents | |||
The development of LDACS has already made substantial progress in the | The development of LDACS has already made substantial progress in the | |||
Single European Sky ATM Research (SESAR) framework and is currently | Single European Sky ATM Research (SESAR) framework and is currently | |||
being continued in the follow-up program SESAR2020 [RIH2018]. A key | being continued in the follow-up program SESAR2020 [RIH2018]. A key | |||
objective of these activities is to develop, implement and validate a | objective of these activities is to develop, implement, and validate | |||
modern aeronautical data link able to evolve with aviation needs over | a modern aeronautical data link that is able to evolve with aviation | |||
the long term. To this end, an LDACS specification has been produced | needs over the long term. To this end, an LDACS specification has | |||
been produced [GRA2020] and is continuously updated. Transmitter | ||||
[GRA2020] and is continuously updated; transmitter demonstrators were | demonstrators were developed to test the spectrum compatibility of | |||
developed to test the spectrum compatibility of LDACS with legacy | LDACS with legacy systems operating in the L-band [SAJ2014], and the | |||
systems operating in the L-band [SAJ2014]; and the overall system | overall system performance was analyzed by computer simulations, | |||
performance was analyzed by computer simulations, indicating that | indicating that LDACS can fulfill the identified requirements | |||
LDACS can fulfil the identified requirements [GRA2011]. | [GRA2011]. | |||
Up to now LDACS standardization has been focused on the development | Up to now, LDACS standardization has been focused on the development | |||
of the physical layer and the data link layer. Only recently have | of the Physical Layer (PHY) and the Data Link Layer (DLL). Only | |||
higher layers have come into the focus of the LDACS development | recently have higher layers come into the focus of the LDACS | |||
activities. Currently no "IPv6 over LDACS" specification is defined; | development activities. Currently no "IPv6 over LDACS" specification | |||
however, SESAR2020 has started experimenting with IPv6-based LDACS | is defined; however, SESAR2020 has started experimenting with | |||
and ICAO plans to seek guidance from IETF to develop IPv6 over LDACS. | IPv6-based LDACS and ICAO plans to seek guidance from IETF to develop | |||
As of May 2022, LDACS defines 1536 Byte user-data packets [GRA2020] | IPv6 over LDACS. As of May 2022, LDACS defines 1536-byte user data | |||
in which IPv6 traffic shall be encapsulated. Additionally, Robust | packets [GRA2020] in which IPv6 traffic shall be encapsulated. | |||
Header Compression (ROHC) is considered on LDACS Sub-Network Protocol | Additionally, Robust Header Compression (ROHC) [RFC5795] is | |||
(SNP) layer (cf. Section 7.3.3.) [RFC5795]. | considered on the LDACS Subnetwork Protocol (SNP) layer | |||
(cf. Section 7.3.3). | ||||
The IPv6 architecture for the aeronautical telecommunication network | The IPv6 architecture for the aeronautical telecommunication network | |||
is called the ATN/IPS. Link-layer technologies within the ATN/IPS | is called the ATN/IPS. Link-layer technologies within the ATN/IPS | |||
encompass LDACS [GRA2020], AeroMACS [KAMA2018] and several SatCOM | encompass LDACS [GRA2020], AeroMACS [KAMA2018], and several SatCOM | |||
candidates and combined with the ATN/IPS, are called the FCI. The | candidates; combined with the ATN/IPS, these are called the "FCI". | |||
FCI will support quality of service, link diversity, and mobility | The FCI will support quality of service, link diversity, and mobility | |||
under the umbrella of the "multilink concept". The "multilink | under the umbrella of the "multilink concept". The "multilink | |||
concept" describing the idea that depending on link quality, | concept" describes the idea that depending on link quality, | |||
communication can be switched seamlessly from one datalink technology | communication can be switched seamlessly from one data link | |||
to another. This work is led by ICAO Communication Panel working | technology to another. This work is led by the ICAO Communication | |||
group WG-I. | Panel Working Group (WG-I). | |||
In addition to standardization activities several industrial LDACS | In addition to standardization activities, several industrial LDACS | |||
prototypes have been built. One set of LDACS prototypes has been | prototypes have been built. One set of LDACS prototypes has been | |||
evaluated in flight trials confirming the theoretical results | evaluated in flight trials confirming the theoretical results | |||
predicting the system performance [GRA2018] [MAE20211] [BEL2021]. | predicting the system performance [GRA2018] [MAE20211] [BEL2021]. | |||
5. Applicability | 5. Applicability | |||
LDACS is a multi-application cellular broadband system capable of | LDACS is a multi-application cellular broadband system capable of | |||
simultaneously providing various kinds of Air Traffic Services (ATS) | simultaneously providing various kinds of Air Traffic Services (ATSs) | |||
including ATS-B3, and AOC communications services from deployed | including ATS-B3 and AOC communications services from deployed | |||
Ground-Stations (GS). The physical layer and data link layer of | Ground-Stations (GSs). The physical layer and data link layer of | |||
LDACS are optimized for controller-pilot data link communications, | LDACS are optimized for Controller-Pilot Data Link Communications | |||
but the system also supports digital air-ground voice communications. | (CPDLC), but the system also supports digital A/G voice | |||
communications. | ||||
LDACS supports communications in all airspaces (airport, terminal | LDACS supports communications in all airspaces (airport, terminal | |||
maneuvering area, and en-route), and on the airport surface. The | maneuvering area, and en route) and on the airport surface. The | |||
physical LDACS cell coverage is effectively de-coupled from the | physical LDACS cell coverage is effectively decoupled from the | |||
operational coverage required for a particular service. This is new | operational coverage required for a particular service. This is new | |||
in aeronautical communications. Services requiring wide-area | in aeronautical communications. Services requiring wide-area | |||
coverage can be installed at several adjacent LDACS cells. The | coverage can be installed at several adjacent LDACS cells. The | |||
handover between the involved LDACS cells is seamless, automatic, and | handover between the involved LDACS cells is seamless, automatic, and | |||
transparent to the user. Therefore, the LDACS communications concept | transparent to the user. Therefore, the LDACS communications concept | |||
enables the aeronautical communication infrastructure to support | enables the aeronautical communication infrastructure to support | |||
future dynamic airspace management concepts. | future dynamic airspace management concepts. | |||
5.1. Advances Beyond the State-of-the-Art | 5.1. Advances beyond the State of the Art | |||
LDACS will offer several capabilities, not yet provided in | LDACS will offer several capabilities that are not yet provided in | |||
contemporarily deployed aeronautical communications systems. All | contemporarily deployed aeronautical communications systems. These | |||
these were already tested and confirmed in lab or flight trials with | capabilities were already tested and confirmed in lab or flight | |||
available LDACS prototype hardware [BEL2021] [MAE20211]. | trials with available LDACS prototype hardware [BEL2021] [MAE20211]. | |||
5.1.1. Priorities | 5.1.1. Priorities | |||
LDACS is able to manage service priorities, an important feature not | LDACS is able to manage service priorities, which is an important | |||
available in some of the current data link deployments. Thus, LDACS | feature that is not available in some of the current data link | |||
guarantees bandwidth availability, low latency, and high continuity | deployments. Thus, LDACS guarantees bandwidth availability, low | |||
of service for safety critical ATS applications while simultaneously | latency, and high continuity of service for safety-critical ATS | |||
accommodating less safety-critical AOC services. | applications while simultaneously accommodating less safety-critical | |||
AOC services. | ||||
5.1.2. Security | 5.1.2. Security | |||
LDACS is a secure data link with built-in security mechanisms. It | LDACS is a secure data link with built-in security mechanisms. It | |||
enables secure data communications for ATS and AOC services, | enables secure data communications for ATS and AOC services, | |||
including secured private communications for aircraft operators and | including secured private communications for aircraft operators and | |||
Air traffic Network Service Providers (ANSP). This includes concepts | Air Traffic Network Service Providers (ANSPs). This includes | |||
for key and trust management, mutual authentication and key | concepts for key and trust management, Mutual Authentication and Key | |||
establishment protocols, key derivation measures, user and control | Establishment (MAKE) protocols, key derivation measures, user and | |||
message-in-transit protection, secure logging and availability and | control message-in-transit protection, secure logging, and | |||
robustness measures [MAE20182] [MAE2021]. | availability and robustness measures [MAE20182] [MAE2021]. | |||
5.1.3. High Data Rates | 5.1.3. High Data Rates | |||
The user data rate of LDACS is 315 kbit/s to 1428 kbit/s on the | The user data rate of LDACS is 315 kbit/s to 1428 kbit/s on the | |||
Forward Link (FL) for the Ground-to-Air (G2A) connection, and 294 | Forward Link (FL) for the Ground-to-Air (G2A) connection, and 294 | |||
kbit/s to 1390 kbit/s on the Reverse Link (RL) for the Air-to-Ground | kbit/s to 1390 kbit/s on the Reverse Link (RL) for the Air-to-Ground | |||
(A2G) connection, depending on coding and modulation. This is up to | (A2G) connection, depending on coding and modulation. This is up to | |||
two orders of magnitude greater than current terrestrial digital | two orders of magnitude greater than what current terrestrial digital | |||
aeronautical communications systems, such as the VHF Data Link mode 2 | aeronautical communications systems, such as the VHF Data Link mode 2 | |||
(VDLm2), provide [ICAO2019] [GRA2020]. | (VDLm2), provide; see [ICAO2019] [GRA2020]. | |||
5.2. Application | 5.2. Application | |||
LDACS will be used by several aeronautical applications ranging from | LDACS will be used by several aeronautical applications ranging from | |||
enhanced communications protocol stacks (multi-homed mobile IPv6 | enhanced communications protocol stacks (multihomed mobile IPv6 | |||
networks in the aircraft and potentially ad-hoc networks between | networks in the aircraft and potentially ad-hoc networks between | |||
aircraft) to broadcast communication applications (GNSS correction | aircraft) to broadcast communication applications (Global Navigation | |||
data) and integration with other service domains (using the | Satellite System (GNSS) correction data) and integration with other | |||
communications signal for navigation) [MAE20211]. Also, a digital | service domains (using the communications signal for navigation) | |||
voice service offering better quality and service than current HF and | [MAE20211]. Also, a digital voice service offering better quality | |||
VHF systems is foreseen. | and service than current HF and VHF systems is foreseen. | |||
5.2.1. Air/Ground Multilink | 5.2.1. Air/Ground Multilink | |||
It is expected that LDACS, together with upgraded satellite-based | It is expected that LDACS, together with upgraded satellite-based | |||
communications systems, will be deployed within the FCI and | communications systems, will be deployed within the FCI and | |||
constitute one of the main components of the multilink concept within | constitute one of the main components of the multilink concept within | |||
the FCI. | the FCI. | |||
Both technologies, LDACS and satellite systems, have their specific | Both technologies, LDACS and satellite systems, have their specific | |||
benefits and technical capabilities which complement each other. | benefits and technical capabilities that complement each other. | |||
Especially, satellite systems are well-suited for large coverage | Satellite systems are especially well-suited for large coverage areas | |||
areas with less dense air traffic, e.g. oceanic regions. LDACS is | with less dense air traffic, e.g., oceanic regions. LDACS is well- | |||
well-suited for dense air traffic areas, e.g., continental areas or | suited for dense air traffic areas, e.g., continental areas or | |||
hot-spots around airports and terminal airspace. In addition, both | hotspots around airports and terminal airspace. In addition, both | |||
technologies offer comparable data link capacity and, thus, are well- | technologies offer comparable data link capacity; thus, both are | |||
suited for redundancy, mutual back-up, or load balancing. | well-suited for redundancy, mutual back-up, or load balancing. | |||
Technically the FCI multilink concept will be realized by multi-homed | Technically, the FCI multilink concept will be realized by multihomed | |||
mobile IPv6 networks in the aircraft. The related protocol stack is | mobile IPv6 networks in the aircraft. The related protocol stack is | |||
currently under development by ICAO, within SESAR, and the IETF. | currently under development by ICAO, within SESAR, and the IETF. | |||
Currently two layers of mobility are foreseen. Local mobility within | Currently, two layers of mobility are foreseen. Local mobility | |||
the LDACS access network is realized through PMIPv6, global mobility | within the LDACS access network is realized through Proxy Mobile IPv6 | |||
between "multi-link" access networks (which need not be LDACS) is | (PMIPv6), and global mobility between "multilink" access networks | |||
implemented on top of LISP [I-D.haindl-lisp-gb-atn] | (which need not be LDACS) is implemented on top of LISP [LISP-GB-ATN] | |||
[I-D.ietf-lisp-rfc6830bis] [I-D.ietf-lisp-rfc6833bis]. | [RFC9300] [RFC9301]. | |||
5.2.2. Air/Air Extension for LDACS | 5.2.2. Air/Air Extension for LDACS | |||
A potential extension of the multilink concept is its extension to | A potential extension of the multilink concept is its extension to | |||
the integration of ad-hoc networks between aircraft. | the integration of ad-hoc networks between aircraft. | |||
Direct A/A communication between aircraft in terms of ad-hoc data | Direct A/A communication between aircraft in terms of ad-hoc data | |||
networks are currently considered a research topic since there is no | networks is currently considered a research topic since there is no | |||
immediate operational need for it, although several possible use | immediate operational need for it, although several possible use | |||
cases are discussed (Automatic Dependent Surveillance - Broadcast | cases are discussed (Automatic Dependent Surveillance - Broadcast | |||
(ADS-B), digital voice, wake vortex warnings, and trajectory | (ADS-B), digital voice, wake vortex warnings, and trajectory | |||
negotiation) [BEL2019]. It should also be noted, that currently | negotiation) [BEL2019]. It should also be noted that currently | |||
deployed analog VHF voice radios support direct voice communication | deployed analog VHF voice radios support direct voice communication | |||
between aircraft, making a similar use case for digital voice | between aircraft, making a similar use case for digital voice | |||
plausible. | plausible. | |||
LDACS A/A is currently not part of the standardization process and | LDACS A/A is currently not a part of the standardization process and | |||
will not be covered within this document. However, it is planned | will not be covered within this document. However, it is planned | |||
that LDACS A/A will be rolled out after the initial deployment of | that LDACS A/A will be rolled out after the initial deployment of | |||
LDACS A/G, then being seamlessly integrated in the existing LDACS | LDACS A/G and seamlessly integrated in the existing LDACS ground- | |||
ground-based system. | based system. | |||
5.2.3. Flight Guidance | 5.2.3. Flight Guidance | |||
The FCI (and therefore LDACS) is used to provide flight guidance. | The FCI (and therefore LDACS) is used to provide flight guidance. | |||
This is realized using three applications: | This is realized using three applications: | |||
1. Context Management (CM): The CM application manages the automatic | 1. Context Management (CM): The CM application manages the automatic | |||
logical connection to the ATC center currently responsible to | logical connection to the ATC center currently responsible to | |||
guide the aircraft. Currently, this is done by the air crew | guide the aircraft. Currently, this is done by the air crew | |||
manually changing VHF voice frequencies manually according to the | manually changing VHF voice frequencies according to the progress | |||
progress of the flight. The CM application automatically sets up | of the flight. The CM application automatically sets up | |||
equivalent sessions. | equivalent sessions. | |||
2. Controller Pilot Data Link Communications (CPDLC): The CPDLC | 2. Controller-Pilot Data Link Communications (CPDLC): The CPDLC | |||
application provides the air crew with the ability to exchange | application provides the air crew with the ability to exchange | |||
data messages similar to text messages with the currently | data messages similar to text messages with the currently | |||
responsible ATC center. The CPDLC application takes over most of | responsible ATC center. The CPDLC application takes over most of | |||
the communication currently performed over VHF voice and enables | the communication currently performed over VHF voice and enables | |||
new services that do not lend themselves to voice communication | new services that do not lend themselves to voice communication | |||
(i.e., trajectory negotiation). | (i.e., trajectory negotiation). | |||
3. Automatic Dependent Surveillance - Contract (ADS-C): ADS-C | 3. Automatic Dependent Surveillance - Contract (ADS-C): ADS-C | |||
reports the position of the aircraft to the currently active ATC | reports the position of the aircraft to the currently active ATC | |||
center. Reporting is bound to "contracts", i.e., pre-defined | center. Reporting is bound to "contracts", i.e., pre-defined | |||
events related to the progress of the flight (i.e., the | events related to the progress of the flight (i.e., the | |||
trajectory). ADS-C and CPDLC are the primary applications used | trajectory). ADS-C and CPDLC are the primary applications used | |||
for implementing in-flight trajectory management. | for implementing in-flight trajectory management. | |||
CM, CPDLC, and ADS-C are available on legacy datalinks, but are not | CM, CPDLC, and ADS-C are available on legacy data links but are not | |||
widely deployed and with limited functionality. | widely deployed and with limited functionality. | |||
Further ATC applications may be ported to use the FCI or LDACS as | Further ATC applications may be ported to use the FCI or LDACS as | |||
well. A notable application is GBAS for secure, automated landings: | well. A notable application is the Ground-Based Augmentation System | |||
The Global Navigation Satellite System (GNSS) based GBAS is used to | (GBAS) for secure, automated landings. The GNSS-based GBAS is used | |||
improve the accuracy of GNSS to allow GNSS based instrument landings. | to improve the accuracy of GNSS to allow GNSS-based instrument | |||
landings. This is realized by sending GNSS correction data (e.g., | ||||
This is realized by sending GNSS correction data (e.g., compensating | compensating ionospheric errors in the GNSS signal) to the aircraft's | |||
ionospheric errors in the GNSS signal) to the aircraft's GNSS | GNSS receiver via a separate data link. Currently, the VHF Data | |||
receiver via a separate data link. Currently, the VDB data link is | Broadcast (VDB) data link is used. VDB is a narrowband one-way, | |||
used. VDB is a narrowband single-purpose datalink without advanced | single-purpose data link without advanced security and is only used | |||
security only used to transmit GBAS correction data. This makes VDB | to transmit GBAS correction data. These shortcomings show a clear | |||
a natural candidate for replacement by LDACS [MAE20211]. | need to replace VDB. A natural candidate to replace it is LDACS, | |||
because it is a bidirectional data link, also operates in non-line-of | ||||
sight scenarios, offers strong integrated link-layer security, and | ||||
has a considerably larger operational range than VDB [MAE20211]. | ||||
5.2.4. Business Communications of Airlines | 5.2.4. Business Communications of Airlines | |||
In addition to air traffic services, AOC services are transmitted | In addition to ATSs, AOC services are transmitted over LDACS. AOC is | |||
over LDACS. AOC is a generic term referring to the business | a generic term referring to the business communication of airlines | |||
communication of airlines, between the airlines and service partners | between the airlines and service partners on the ground and their own | |||
on the ground and their own aircraft in the air. Regulatory-wise, | aircraft in the air. Regulatory-wise, this is considered related to | |||
this is considered related to safety and regularity of flight and may | safety and regularity of flight; therefore, it may be transmitted | |||
therefore, be transmitted over LDACS. AOC communication is | over LDACS. AOC communication is considered the main business case | |||
considered the main business case for LDACS communications service | for LDACS communications service providers since modern aircraft | |||
providers since modern aircraft generate significant amounts of data | generate significant amounts of data (e.g., engine maintenance data). | |||
(e.g., engine maintenance data). | ||||
5.2.5. LDACS-based Navigation | 5.2.5. LDACS-Based Navigation | |||
Beyond communications, radio signals can always also be used for | Beyond communications, radio signals can always be used for | |||
navigation. This fact is used for the LDACS navigation concept. | navigation as well. This fact is used for the LDACS navigation | |||
concept. | ||||
For future aeronautical navigation, ICAO recommends the further | For future aeronautical navigation, ICAO recommends the further | |||
development of GNSS based technologies as primary means for | development of GNSS-based technologies as primary means for | |||
navigation. Due to the large separation between navigational | navigation. However, due to the large separation between | |||
satellites and aircraft, the power of the GNSS signals received by | navigational satellites and aircraft, the power of the GNSS signals | |||
the aircraft is, however, very low. As a result, GNSS disruptions | received by the aircraft is very low. As a result, GNSS disruptions | |||
might occasionally occur due to unintentional interference, or | might occasionally occur due to unintentional interference or | |||
intentional jamming. Yet the navigation services must be available | intentional jamming. Yet, the navigation services must be available | |||
with sufficient performance for all phases of flight. Therefore, | with sufficient performance for all phases of flight. Therefore, | |||
during GNSS outages, or blockages, an alternative solution is needed. | during GNSS outages or blockages, an alternative solution is needed. | |||
This is commonly referred to as Alternative Positioning, Navigation, | This is commonly referred to as Alternative Positioning, Navigation, | |||
and Timing (APNT). | and Timing (APNT). | |||
One such APNT solution is based on exploiting the built-in navigation | One such APNT solution is based on exploiting the built-in navigation | |||
capabilities of LDACS operation. That is, the normal operation of | capabilities of LDACS operation. That is, the normal operation of | |||
LDACS for ATC and AOC communications would also directly enable the | LDACS for ATC and AOC communications would also directly enable the | |||
aircraft to navigate and obtain a reliable timing reference from the | aircraft to navigate and obtain a reliable timing reference from the | |||
LDACS GSs. Current cell planning for Europe shows 84 LDACS cells to | LDACS GSs. Current cell planning for Europe shows 84 LDACS cells to | |||
be sufficient [MOST2018] to cover the continent at sufficient service | be sufficient [MOST2018] to cover the continent at a sufficient | |||
level. If more than three Ground Stations (GS) are visible by the | service level. If more than three GSs are visible by the aircraft, | |||
aircraft, via knowing the exact positions of these and having a good | via knowing the exact positions of these and having a good channel | |||
channel estimation (which LDACS does due to numerous works mapping | estimation (which LDACS does due to numerous works mapping the L-band | |||
the L-band channel characteristics [SCHN2018] ) it is possible to | channel characteristics [SCHN2018]), it is possible to calculate the | |||
calculate the position of the aircraft via measuring signal | position of the aircraft via measuring signal propagation times to | |||
propagation times to each GS. In flight trials in 2019 with one | each GS. In flight trials in 2019 with one aircraft (and airborne | |||
aircraft (and airborne radio inside it) and just four GS, navigation | radio inside it) and just four GSs, navigation feasibility was | |||
feasibility was demonstrated within the footprint of all four GS with | demonstrated within the footprint of all four GSs with a 95th | |||
a 95th percentile position-domain error of 171.1m [OSE2019] [BEL2021] | percentile position-domain error of 171.1m [OSE2019] [BEL2021] | |||
[MAE20211]. As such, LDACS can be used independently of GNSS as a | [MAE20211]. As such, LDACS can be used independently of GNSS as a | |||
navigation alternative. Positioning errors will decrease markedly as | navigation alternative. Positioning errors will decrease markedly as | |||
more GSes are deployed. [OSE2019] [BEL2021] [MAE20211] | more GSs are deployed [OSE2019] [BEL2021] [MAE20211]. | |||
LDACS navigation has already been demonstrated in practice in two | LDACS navigation has already been demonstrated in practice in two | |||
flight measurement campaigns [SHU2013] [BEL2021] [MAE20211]. | flight measurement campaigns [SHU2013] [BEL2021] [MAE20211]. | |||
6. Requirements | 6. Requirements | |||
The requirements for LDACS are mostly defined by its application | The requirements for LDACS are mostly defined by its application | |||
area: Communications related to safety and regularity of flight. | area: communications related to safety and regularity of flight. | |||
A particularity of the current aeronautical communication landscape | A particularity of the current aeronautical communication landscape | |||
is that it is heavily regulated. Aeronautical data links (for | is that it is heavily regulated. Aeronautical data links (for | |||
applications related to safety and regularity of flight) may only use | applications related to safety and regularity of flight) may only use | |||
spectrum licensed to aviation and data links endorsed by ICAO. | spectrum licensed to aviation and data links endorsed by ICAO. | |||
Nation states can change this locally; however, due to the global | Nation states can change this locally; however, due to the global | |||
scale of the air transportation system, adherence to these practices | scale of the air transportation system, adherence to these practices | |||
is to be expected. | is to be expected. | |||
Aeronautical data links for the ATN are therefore expected to remain | Aeronautical data links for the ATN are therefore expected to remain | |||
in service for decades. The VDLm2 data link currently used for | in service for decades. The VDLm2 data link currently used for | |||
digital terrestrial internetworking was developed in the 1990s (the | digital terrestrial internetworking was developed in the 1990s (the | |||
use of the Open Systems Interconnection (OSI) stack indicates that as | use of the Open Systems Interconnection (OSI) stack indicates that as | |||
well). VDLm2 is expected to be used at least for several decades to | well). VDLm2 is expected to be used at least for several decades to | |||
come. In this respect aeronautical communications (for applications | come. In this respect, aeronautical communications for applications | |||
related to safety and regularity of flight) is more comparable to | related to safety and regularity of flight is more comparable to | |||
industrial applications than to the open Internet. | industrial applications than to the open Internet. | |||
Internetwork technology is already installed in current aircraft. | Internetwork technology is already installed in current aircraft. | |||
Current ATS applications use either Aircraft Communications | Current ATS applications use either the Aircraft Communications | |||
Addressing and Reporting System (ACARS) or the OSI stack. The | Addressing and Reporting System (ACARS) or the OSI stack. The | |||
objective of the development effort of LDACS, as part of the FCI, is | objective of the development effort of LDACS, as part of the FCI, is | |||
to replace legacy OSI stack and proprietary ACARS internetwork | to replace legacy OSI stack and proprietary ACARS internetwork | |||
technologies with industry standard IP technology. It is anticipated | technologies with industry standard IP technology. It is anticipated | |||
that the use of Commercial Off-The-Shelf (COTS) IP technology mostly | that the use of Commercial Off-The-Shelf (COTS) IP technology mostly | |||
applies to the ground network. The avionics networks on the aircraft | applies to the ground network. The avionics networks on the aircraft | |||
will likely be heavily modified versions of Ethernet or proprietary. | will likely be heavily modified versions of Ethernet or proprietary. | |||
AOC applications currently mostly use the same stack (although some | Currently, AOC applications mostly use the same stack (although some | |||
applications, like the graphical weather service may use the | applications, like the graphical weather service, may use the | |||
commercial passenger network). This creates capacity problems | commercial passenger network). This creates capacity problems | |||
(resulting in excessive amounts of timeouts) since the underlying | (resulting in excessive amounts of timeouts) since the underlying | |||
terrestrial data links do not provide sufficient bandwidth (i.e., | terrestrial data links do not provide sufficient bandwidth (i.e., | |||
with VDLm2 currently in the order of 10 kbit/s). The use of non- | with VDLm2 currently in the order of 10 kbit/s). The use of non- | |||
aviation specific data links is considered a security problem. | aviation-specific data links is considered a security problem. | |||
Ideally the aeronautical IP internetwork, hence the ATN over which | Ideally, the aeronautical IP internetwork (hence the ATN over which | |||
only communications related to safety and regularity of flight is | only communications related to safety and regularity of flight is | |||
handled, and the Internet should be completely separated at Layer 3. | handled) and the Internet should be completely separated at Layer 3. | |||
The objective of LDACS is to provide a next generation terrestrial | The objective of LDACS is to provide a next-generation terrestrial | |||
data link designed to support IP addressing and provide much higher | data link designed to support IP addressing and provide much higher | |||
bandwidth to avoid the currently experienced operational problems. | bandwidth to avoid the operational problems that are currently | |||
experienced. | ||||
The requirement for LDACS is therefore to provide a terrestrial high- | The requirement for LDACS is therefore to provide a terrestrial high- | |||
throughput data link for IP internetworking in the aircraft. | throughput data link for IP internetworking in the aircraft. | |||
In order to fulfil the above requirement LDACS needs to be | In order to fulfill the above requirement, LDACS needs to be | |||
interoperable with IP (and IP-based services like Voice-over-IP) at | interoperable with IP (and IP-based services like Voice-over-IP) at | |||
the gateway connecting the LDACS network to other aeronautical ground | the gateway connecting the LDACS network to other aeronautical ground | |||
networks (i.e., the ATN). On the avionics side, in the aircraft, | networks (i.e., the ATN). On the avionics side, in the aircraft, | |||
aviation specific solutions are to be expected. | aviation-specific solutions are to be expected. | |||
In addition to these functional requirements, LDACS and its IP stack | In addition to these functional requirements, LDACS and its IP stack | |||
need to fulfil the requirements defined in RTCA DO-350A/EUROCAE ED- | need to fulfill the requirements defined in RTCA DO-350A/EUROCAE ED- | |||
228A [DO350A]. This document defines continuity, availability, and | 228A [DO350A]. This document defines continuity, availability, and | |||
integrity requirements at different scopes for each air traffic | integrity requirements at different scopes for each ATM application | |||
management application (CPDLC, CM, and ADS-C). The scope most | (CPDLC, CM, and ADS-C). The scope most relevant to IP over LDACS is | |||
relevant to IP over LDACS is the Communications Service Provider | the Communications Service Provider (CSP) scope. | |||
(CSP) scope. | ||||
Continuity, availability, and integrity requirements are defined in | Continuity, availability, and integrity requirements are defined in | |||
[DO350A] volume 1 Table 5-14, and Table 6-13. Appendix A presents | Volume 1 of [DO350A] in Tables 5-14 and 6-13. Appendix A presents | |||
the required information. | the required information. | |||
In a similar vein, requirements to fault management are defined in | In a similar vein, requirements to fault management are defined in | |||
the same tables. | the same tables. | |||
7. Characteristics | 7. Characteristics | |||
LDACS will become one of several wireless access networks connecting | LDACS will become one of several wireless access networks connecting | |||
aircraft to the ATN implemented by the FCI. | aircraft to the ATN implemented by the FCI. | |||
The current LDACS design is focused on the specification of layer one | The current LDACS design is focused on the specification of Layers 1 | |||
and two. However, for the purpose of this work, only layer two | and 2. However, for the purpose of this work, only Layer 2 details | |||
details are discussed here. | are discussed here. | |||
Achieving the stringent continuity, availability, and integrity | Achieving the stringent continuity, availability, and integrity | |||
requirements defined in [DO350A] will require the specification of | requirements defined in [DO350A] will require the specification of | |||
layer 3 and above mechanisms (e.g., reliable crossover at the IP | Layer 3 and above mechanisms (e.g., reliable crossover at the IP | |||
layer). Fault management mechanisms are similarly unspecified as of | layer). Fault management mechanisms are similarly unspecified as of | |||
November 2022. Current regulatory documents do not fully specify the | November 2022. Current regulatory documents do not fully specify the | |||
above mechanism yet. However, a short overview of the current state | above mechanism yet. However, a short overview of the current state | |||
shall be given throughout each section here. | shall be given throughout each section here. | |||
7.1. LDACS Access Network | 7.1. LDACS Access Network | |||
An LDACS access network contains an Access Router (AC-R) and several | An LDACS access network contains an Access Router (AC-R) and several | |||
GS, each of them providing one LDACS radio cell. | GSs, each of them providing one LDACS radio cell. | |||
User plane interconnection to the ATN is facilitated by the AC-R | User-plane interconnection to the ATN is facilitated by the AC-R | |||
peering with an A/G Router connected to the ATN. | peering with an A/G Router connected to the ATN. | |||
The internal control plane of an LDACS access network interconnects | The internal control plane of an LDACS access network interconnects | |||
the GSs. An LDACS access network is illustrated in Figure 1. | the GSs. An LDACS access network is illustrated in Figure 1. Dashes | |||
denote the user plane and points denote the control plane. | ||||
wireless user | wireless user | |||
link plane | link plane | |||
AS-------------GS---------------AC-R---A/G-----ATN | AS-------------GS---------------AC-R---A/G-----ATN | |||
.............. | Router | .............. | Router | |||
control . | | control . | | |||
plane . | | plane . | | |||
. | | . | | |||
GS----------------| | GS----------------| | |||
. | | . | | |||
. | | . | | |||
GS----------------+ | GS----------------+ | |||
Figure 1: LDACS access network with three GSs and one AS. dashes | Figure 1: LDACS Access Network with Three GSs and One AS | |||
denotes the user plane and points the control plane | ||||
7.2. Topology | 7.2. Topology | |||
LDACS is a cellular point-to-multipoint system. It assumes a star- | LDACS is a cellular point-to-multipoint system. It assumes a star | |||
topology in each cell where Aircraft Stations (AS) belonging to | topology in each cell where Aircraft Stations (ASs) belonging to | |||
aircraft within a certain volume of space (the LDACS cell) are | aircraft within a certain volume of space (the LDACS cell) are | |||
connected to the controlling GS. The LDACS GS is a centralized | connected to the controlling GS. The LDACS GS is a centralized | |||
instance that controls LDACS A/G communications within its cell. The | instance that controls LDACS A/G communications within its cell. The | |||
LDACS GS can simultaneously support multiple bidirectional | LDACS GS can simultaneously support multiple bidirectional | |||
communications to the ASs under its control. LDACS's GSs themselves | communications to the ASs under its control. LDACS's GSs themselves | |||
are connected to each other and the AC-R. | are connected to each other and the AC-R. | |||
Prior to utilizing the system an aircraft has to register with the | Prior to utilizing the system, an aircraft has to register with the | |||
controlling GS to establish dedicated logical channels for user and | controlling GS to establish dedicated logical channels for user and | |||
control data. Control channels have statically allocated resources, | control data. Control channels have statically allocated resources | |||
while user channels have dynamically assigned resources according to | while user channels have dynamically assigned resources according to | |||
the current demand. Logical channels exist only between the GS and | the current demand. Logical channels exist only between the GS and | |||
the AS. | the AS. | |||
7.3. LDACS Protocol Stack | 7.3. LDACS Protocol Stack | |||
The protocol stack of LDACS is implemented in the AS and GS: It | The protocol stack of LDACS is implemented in the AS and GS. It | |||
consists of the Physical Layer (PHY) with five major, functional | consists of the PHY with five major functional blocks above it. Four | |||
blocks above it. Four are placed in the Data Link Layer (DLL) of the | are placed in the DLL of the AS and GS: Medium Access Control (MAC) | |||
AS and GS: (1) Medium Access Control (MAC) Layer, (2) Voice Interface | layer, Voice Interface (VI), Data Link Service (DLS), and LDACS | |||
(VI), (3) Data Link Service (DLS), and (4) LDACS Management Entity | Management Entity (LME). The fifth entity, the SNP, resides within | |||
(LME). The fifth entity resides within the sub-network layer: (5) | the subnetwork layer. The LDACS radio is externally connected to a | |||
the Sub-Network Protocol (SNP). The LDACS radio is externally | voice unit and radio control unit via the AC-R to the ATN network. | |||
connected to a voice unit, radio control unit, and via the AC-R to | ||||
the ATN network. | ||||
LDACS is considered an ATN/IPS radio access technology, from the view | LDACS is considered an ATN/IPS radio access technology from the view | |||
of ICAO's regulatory framework. Hence, the interface between ATN and | of ICAO's regulatory framework. Hence, the interface between ATN and | |||
LDACS must be IPv6 based, as regulatory documents, such as ICAO Doc | LDACS must be IPv6-based, as regulatory documents such as ICAO Doc | |||
9896 [ICAO2015] and DO-379 [RTCA2019] clearly foresee that. The | 9896 [ICAO2015] and DO-379 [RTCA2019] clearly foresee that. The | |||
translation between IPv6 layer and SNP layer is currently the subject | translation between the IPv6 layer and SNP layer is currently the | |||
of ongoing standardization efforts and at the time of writing not | subject of ongoing standardization efforts and not finished yet at | |||
finished yet. | the time of writing. | |||
Figure 2 shows the protocol stack of LDACS as implemented in the AS | Figure 2 shows the protocol stack of LDACS as implemented in the AS | |||
and GS. Acronyms used here are introduced throughout the upcoming | and GS. Acronyms used here are introduced throughout the upcoming | |||
sections. | sections. | |||
IPv6 Network Layer | IPv6 Network Layer | |||
| | | | |||
Airborne Voice | | Airborne Voice | | |||
Interface (AVI)/ | Radio Control Unit (RCU) | Interface (AVI) / | Radio Control Unit (RCU) | |||
Voice Unit (VU) | | Voice Unit (VU) | | |||
| | | | | | |||
| +------------------+ +----+ | | +------------------+ +----+ | |||
| | SNP |--| | Sub-Network | | | SNP |--| | Subnetwork | |||
| | | | | Layer | | | | | | Layer | |||
| +------------------+ | | | | +------------------+ | | | |||
| | | LME| | | | | LME| | |||
+-----+ +------------------+ | | | +-----+ +------------------+ | | | |||
| VI | | DLS | | | LLC Layer | | VI | | DLS | | | LLC Layer | |||
+-----+ +------------------+ +----+ | +-----+ +------------------+ +----+ | |||
| | | | | | | | |||
DCH DCH DCCH/CCCH | DCH DCH DCCH/CCCH | |||
| RACH/BCCH | | RACH/BCCH | |||
| | | | | | |||
skipping to change at page 18, line 37 ¶ | skipping to change at line 806 ¶ | |||
| | | | |||
+-------------------------------------+ | +-------------------------------------+ | |||
| PHY | Physical Layer | | PHY | Physical Layer | |||
+-------------------------------------+ | +-------------------------------------+ | |||
| | | | |||
| | | | |||
((*)) | ((*)) | |||
FL/RL radio channels | FL/RL radio channels | |||
separated by FDD | separated by FDD | |||
Figure 2: LDACS protocol stack in AS and GS | Figure 2: LDACS Protocol Stack in the AS and GS | |||
7.3.1. LDACS Physical Layer | 7.3.1. LDACS Physical Layer | |||
The physical layer provides the means to transfer data over the radio | The physical layer provides the means to transfer data over the radio | |||
channel. The LDACS GS supports bidirectional links to multiple | channel. The LDACS GS supports bidirectional links to multiple | |||
aircraft under its control. The FL direction at the G2A connection | aircraft under its control. The FL direction at the G2A connection | |||
and the RL direction at the A2G connection are separated by Frequency | and the RL direction at the A2G connection are separated by Frequency | |||
Division Duplex (FDD). FL and RL use a 500 kHz channel each. The GS | Division Duplex (FDD). FL and RL use a 500 kHz channel each. The GS | |||
transmits a continuous stream of Orthogonal Frequency-Division | transmits a continuous stream of Orthogonal Frequency Division | |||
Multiplexing Access (OFDM) symbols on the FL. In the RL different | Multiplexing Access (OFDM) symbols on the FL. In the RL, different | |||
aircraft are separated in time and frequency using Orthogonal | aircraft are separated in time and frequency using Orthogonal | |||
Frequency-Division Multiple Access (OFDMA). Aircraft thus transmit | Frequency Division Multiple Access (OFDMA). Thus, aircraft transmit | |||
discontinuously on the RL via short radio bursts sent in precisely | discontinuously on the RL via short radio bursts sent in precisely | |||
defined transmission opportunities allocated by the GS. | defined transmission opportunities allocated by the GS. | |||
7.3.2. LDACS Data Link Layer | 7.3.2. LDACS Data Link Layer | |||
The data-link layer provides the necessary protocols to facilitate | The data link layer provides the necessary protocols to facilitate | |||
concurrent and reliable data transfer for multiple users. The LDACS | concurrent and reliable data transfer for multiple users. The LDACS | |||
data link layer is organized in two sub-layers: The medium access | data link layer is organized in two sub-layers: the medium access | |||
sub-layer and the Logical Link Control (LLC) sub-layer. The medium | sub-layer and the Logical Link Control (LLC) sub-layer. The medium | |||
access sub-layer manages the organization of transmission | access sub-layer manages the organization of transmission | |||
opportunities in slots of time and frequency. The LLC sub-layer | opportunities in slots of time and frequency. The LLC sub-layer | |||
provides acknowledged point-to-point logical channels between the | provides acknowledged point-to-point logical channels between the | |||
aircraft and the GS using an Automatic Repeat reQuest (ARQ) protocol. | aircraft and the GS using an Automatic Repeat reQuest (ARQ) protocol. | |||
LDACS also supports unacknowledged point-to-point channels and G2A | LDACS also supports unacknowledged point-to-point channels and G2A | |||
Broadcast transmission. | broadcast transmission. | |||
7.3.2.1. Medium Access Control (MAC) Services | 7.3.2.1. Medium Access Control (MAC) Services | |||
The MAC time framing service provides the frame structure necessary | The MAC time framing service provides the frame structure necessary | |||
to realize slot-based time-division multiplex-access on the physical | to realize slot-based time-division multiplex-access on the physical | |||
link. It provides the functions for the synchronization of the MAC | link. It provides the functions for the synchronization of the MAC | |||
framing structure and the PHY Layer framing. The MAC time framing | framing structure and the PHY layer framing. The MAC time framing | |||
provides a dedicated time slot for each logical channel. | provides a dedicated time slot for each logical channel. | |||
The MAC sub-layer offers access to the physical channel to its | The MAC sub-layer offers access to the physical channel to its | |||
service users. Channel access is provided through transparent | service users. Channel access is provided through transparent | |||
logical channels. The MAC sub-layer maps logical channels onto the | logical channels. The MAC sub-layer maps logical channels onto the | |||
appropriate slots and manages the access to these channels. Logical | appropriate slots and manages the access to these channels. Logical | |||
channels are used as interface between the MAC and LLC sub-layers. | channels are used as interface between the MAC and LLC sub-layers. | |||
7.3.2.2. Data Link Service (DLS) Services | 7.3.2.2. Data Link Services (DLSs) | |||
The DLS provides acknowledged and unacknowledged (including broadcast | The DLS provides acknowledged and unacknowledged (including broadcast | |||
and packet mode voice) bidirectional exchange of user data. If user | and packet mode voice) bidirectional exchange of user data. If user | |||
data is transmitted using the acknowledged DLS, the sending DLS | data is transmitted using the acknowledged DLS, the sending DLS | |||
entity will wait for an acknowledgement from the receiver. If no | entity will wait for an acknowledgement from the receiver. If no | |||
acknowledgement is received within a specified time frame, the sender | acknowledgement is received within a specified time frame, the sender | |||
may automatically try to retransmit its data. However, after a | may automatically try to retransmit its data. However, after a | |||
certain number of failed retries, the sender will suspend further | certain number of failed retries, the sender will suspend further | |||
retransmission attempts and inform its client of the failure. | retransmission attempts and inform its client of the failure. | |||
The DLS uses the logical channels provided by the MAC: | The DLS uses the logical channels provided by the MAC: | |||
1. A GS announces its existence and access parameters in the | 1. A GS announces its existence and access parameters in the | |||
Broadcast Channel (BCCH). | Broadcast Channel (BCCH). | |||
2. The Random-Access Channel (RACH) enables AS to request access to | 2. The Random-Access Channel (RACH) enables the AS to request access | |||
an LDACS cell. | to an LDACS cell. | |||
3. In the FL the Common Control Channel (CCCH) is used by the GS to | 3. In the FL, the Common Control Channel (CCCH) is used by the GS to | |||
grant access to data channel resources. | grant access to Data Channel (DCH) resources. | |||
4. The reverse direction is covered by the RL, where ASs need to | 4. The reverse direction is covered by the RL, where ASs need to | |||
request resources before sending. This happens via the Dedicated | request resources before sending. This happens via the Dedicated | |||
Control Channel (DCCH). | Control Channel (DCCH). | |||
5. User data itself is communicated in the Data Channel (DCH) on the | 5. User data itself is communicated in the DCH on the FL and RL. | |||
FL and RL. | ||||
Access to the FL and RL data channel is granted by the scheduling | Access to the FL and RL DCH is granted by the scheduling mechanism | |||
mechanism implemented in the LME discussed below. | implemented in the LME discussed below. | |||
7.3.2.3. Voice Interface (VI) Services | 7.3.2.3. Voice Interface (VI) Services | |||
The VI provides support for virtual voice circuits. Voice circuits | The VI provides support for virtual voice circuits. Voice circuits | |||
may either be set-up permanently by the GS (e.g., to emulate voice | may be either set up permanently by the GS (e.g., to emulate voice | |||
party line) or may be created on demand. | party line) or created on demand. | |||
7.3.2.4. LDACS Management Entity (LME) Services | 7.3.2.4. LDACS Management Entity (LME) Services | |||
The mobility management service in the LME provides support for | The mobility management service in the LME provides support for | |||
registration and de-registration (cell entry and cell exit), scanning | registration and de-registration (cell entry and cell exit), scanning | |||
RF channels of neighboring cells and handover between cells. In | RF channels of neighboring cells, and handover between cells. In | |||
addition, it manages the addressing of aircraft within cells. | addition, it manages the addressing of aircraft within cells. | |||
The resource management service provides link maintenance (power, | The resource management service provides link maintenance (power, | |||
frequency and time adjustments), support for adaptive coding and | frequency, and time adjustments), support for adaptive coding and | |||
modulation, and resource allocation. | modulation, and resource allocation. | |||
The resource management service accepts resource requests from/for | The resource management service accepts resource requests from/for | |||
different AS and issues resource allocations accordingly. While the | different ASs and issues resource allocations accordingly. While the | |||
scheduling algorithm is not specified and a point of possible vendor | scheduling algorithm is not specified and a point of possible vendor | |||
differentiation, it is subject to the following requirements: | differentiation, it is subject to the following requirements: | |||
1. Resource scheduling must provide channel access according to the | 1. Resource scheduling must provide channel access according to the | |||
priority of the request | priority of the request. | |||
2. Resource scheduling must support "one-time" requests. | 2. Resource scheduling must support "one-time" requests. | |||
3. Resource scheduling must support "permanent" requests that | 3. Resource scheduling must support "permanent" requests that | |||
reserve a resource until the request is canceled e.g. for digital | reserve a resource until the request is canceled (e.g., for | |||
voice circuits. | digital voice circuits). | |||
7.3.3. LDACS Sub-Network Layer and Protocol Services | 7.3.3. LDACS Subnetwork Layer and Protocol Services | |||
Lastly, the SNP layer of LDACS directly interacts with IPv6 traffic. | Lastly, the SNP layer of LDACS directly interacts with IPv6 traffic. | |||
Incoming ATN/IPS IPv6 packets are forwarded over LDACS from and to | Incoming ATN/IPS IPv6 packets are forwarded over LDACS from and to | |||
the aircraft. The final IP addressing structure in an LDACS subnet | the aircraft. The final IP addressing structure in an LDACS subnet | |||
still needs to be defined; however, the current layout is considered | still needs to be defined; however, the current layout consists of | |||
to consist of the five network segments: Air Core Net, Air Management | the five network segments: Air Core Net, Air Management Net, Ground | |||
Net, Ground Core Net, Ground Management Net, Ground Net. Any | Core Net, Ground Management Net, and Ground Net. Any protocols that | |||
protocols that the ATN/IPS [ICAO2015] defines as mandatory will reach | the ATN/IPS [ICAO2015] defines as mandatory will reach the aircraft; | |||
the aircraft, however listing these here is out of scope. For more | however, listing these here is out of scope. For more information on | |||
information on the technicalities of the above ATN/IPS layer, please | the technicalities of the above ATN/IPS layer, please refer to | |||
refer to [ICAO2015] [RTCA2019] [ARI2021]. | [ICAO2015], [RTCA2019], and [ARI2021]. | |||
The DLS provides functions required for the transfer of user plane | The DLS provides functions that are required for the transfer of | |||
data and control plane data over the LDACS access network. The | user-plane data and control plane data over the LDACS access network. | |||
security service provides functions for secure user data | The security service provides functions for secure user data | |||
communication over the LDACS access network. Note that the SNP | communication over the LDACS access network. Note that the SNP | |||
security service applies cryptographic measures as configured by the | security service applies cryptographic measures as configured by the | |||
GS. | GS. | |||
7.4. LDACS Mobility | 7.4. LDACS Mobility | |||
LDACS supports layer 2 handovers to different LDACS cells. Handovers | LDACS supports Layer 2 handovers to different LDACS cells. Handovers | |||
may be initiated by the aircraft (break-before-make) or by the GS | may be initiated by the aircraft (break-before-make) or by the GS | |||
(make-before-break). Make-before-break handovers are only supported | (make-before-break). Make-before-break handovers are only supported | |||
between GSs connected to each other, usually GS operated by the same | between GSs connected to each other and usually GSs operated by the | |||
service provider. | same service provider. | |||
When a handover between AS and two interconnected GS takes place, it | ||||
can be triggered by AS or GS. Once that is done, new security | ||||
information is exchanged between AS, GS1 and GS2, before the "old" | ||||
connection is terminated between AS and GS1 and a "new" connection is | ||||
set up between AS and GS2. As a last step, accumulated user-data at | ||||
GS1 is forwarded to GS2 via a ground connection, before that is sent | ||||
via GS2 to the AS. While some information for handover is | ||||
transmitted in the LDACS DCH, the information remains in the | ||||
"control-plane" part of LDACS and is exchanged between LMEs in AS, | ||||
GS1 and GS2. As such, local mobility takes place entirely within the | ||||
LDACS network, utilizing the PMIPv6 protocol [RFC5213]. The use of | ||||
PMIPv6 is currently not mandated by standardization, and may be | ||||
vendor-specific. External handovers between non-connected LDACS | ||||
access networks or different aeronautical data links are handled by | ||||
the FCI multi-link concept. | ||||
External handovers between non-connected LDACS access networks or | When a handover between the AS and two interconnected GSs takes | |||
different aeronautical data links are handled by the FCI multi- link | place, it can be triggered by the AS or GS. Once that is done, new | |||
concept. | security information is exchanged between the AS, GS1, and GS2 before | |||
the "old" connection is terminated between the AS and GS1 and a "new" | ||||
connection is set up between the AS and GS2. As a last step, | ||||
accumulated user data at GS1 is forwarded to GS2 via a ground | ||||
connection before it is sent via GS2 to the AS. While some | ||||
information for handover is transmitted in the LDACS DCH, the | ||||
information remains in the "control plane" part of LDACS and is | ||||
exchanged between LMEs in the AS, GS1, and GS2. As such, local | ||||
mobility takes place entirely within the LDACS network and utilizes | ||||
the PMIPv6 protocol [RFC5213]. The use of PMIPv6 is currently not | ||||
mandated by standardization and may be vendor-specific. External | ||||
handovers between non-connected LDACS access networks or different | ||||
aeronautical data links are handled by the FCI multilink concept. | ||||
7.5. LDACS Management - Interfaces and Protocols | 7.5. LDACS Management Interfaces and Protocols | |||
LDACS management interfaces and protocols are currently not be | LDACS management interfaces and protocols are currently not be | |||
mandated by standardization. The implementations currently available | mandated by standardization. The implementations currently available | |||
use SNMP for management and Radius for AAA. Link state (link up, | use SNMP for management and Radius for Authentication, Authorization, | |||
link down) is reported using the ATN/IPS Aircraft Protocol (AIAP) | and Accounting (AAA). Link state (link up, link down) is reported | |||
mandated by ICAO WG-I for multi-link. | using the ATN/IPS Aircraft Protocol (AIAP) mandated by ICAO WG-I for | |||
multilink. | ||||
8. Reliability and Availability | 8. Reliability and Availability | |||
8.1. Below Layer 1 | 8.1. Below Layer 1 | |||
Below Layer 2, aeronautics usually relies on hardware redundancy. To | Below Layer 1, aeronautics usually rely on hardware redundancy. To | |||
protect availability of the LDACS link, an aircraft equipped with | protect availability of the LDACS link, an aircraft equipped with | |||
LDACS will have access to two L-band antennae with triple redundant | LDACS will have access to two L-band antennae with triple redundant | |||
radio systems as required for any safety relevant aeronautical | radio systems as required for any safety relevant aeronautical | |||
systems by ICAO. | systems by ICAO. | |||
8.2. Layer 1 and 2 | 8.2. Layers 1 and 2 | |||
LDACS has been designed with applications related to the safety and | LDACS has been designed with applications related to the safety and | |||
regularity of flight in mind. It has therefore been designed as a | regularity of flight in mind; therefore, it has been designed as a | |||
deterministic wireless data link (as far as this is possible). | deterministic wireless data link (as far as this is possible). | |||
Based on channel measurements of the L-band channel LDACS was | Based on channel measurements of the L-band channel, LDACS was | |||
designed from the PHY layer up with robustness in mind. Channel | designed from the PHY layer up with robustness in mind. Channel | |||
measurements of the L-band channel [SCH2016] confirmed LDACS to be | measurements of the L-band channel [SCH2016] confirmed LDACS to be | |||
well adapted to its channel. | well adapted to its channel. | |||
In order to maximize the capacity per channel and to optimally use | In order to maximize the capacity per channel and to optimally use | |||
the available spectrum, LDACS was designed as an OFDM-based FDD | the available spectrum, LDACS was designed as an OFDM-based FDD | |||
system, supporting simultaneous transmissions in FL in the G2A | system that supports simultaneous transmissions in FL in the G2A | |||
connection and RL in the A2G connection. The legacy systems already | connection and RL in the A2G connection. The legacy systems already | |||
deployed in the L-band limit the bandwidth of both channels to | deployed in the L-band limit the bandwidth of both channels to | |||
approximately 500 kHz. | approximately 500 kHz. | |||
The LDACS physical layer design includes propagation guard times | The LDACS physical layer design includes propagation guard times | |||
sufficient for operation at a maximum distance of 200 nautical miles | sufficient for operation at a maximum distance of 200 nautical miles | |||
from the GS. In actual deployment, LDACS can be configured for any | (nm) from the GS. In actual deployment, LDACS can be configured for | |||
range up to this maximum range. | any range up to this maximum range. | |||
The LDACS physical layer supports adaptive coding and modulation for | The LDACS physical layer supports adaptive coding and modulation for | |||
user data. Control data is always encoded with the most robust | user data. Control data is always encoded with the most robust | |||
coding and modulation (FL: Quadrature Phase-Shift Keying (QPSK), | coding and modulation (FL: Quadrature Phase-Shift Keying (QPSK), | |||
coding rate 1/2, RL: QPSK, coding rate 1/3). | coding rate 1/2; RL: QPSK, coding rate 1/3). | |||
LDACS medium access layer on top of the physical layer uses a static | LDACS medium access layer on top of the physical layer uses a static | |||
frame structure to support deterministic timer management. As shown | frame structure to support deterministic timer management. As shown | |||
in Figure 3 and Figure 4, LDACS framing structure is based on Super- | in Figures 3 and 4, LDACS framing structure is based on Super-Frames | |||
Frames (SF) of 240ms duration corresponding to 2000 OFDM symbols. | (SFs) of 240 ms (milliseconds) duration corresponding to 2000 OFDM | |||
OFDM symbol time is 120 microseconds, sampling time 1.6 microseconds | symbols. OFDM symbol time is 120 microseconds, sampling time is 1.6 | |||
and a guard time of 4.8 microseconds. The structure of a SF is | microseconds, and guard time is 4.8 microseconds. The structure of | |||
depicted in Figure 3 along with its structure and timings of each | an SF is depicted in Figure 3 along with its structure and timings of | |||
part. FL and RL boundaries are aligned in time (from the GS | each part. FL and RL boundaries are aligned in time (from the GS | |||
perspective) allowing for deterministic slots for control and data | perspective) allowing for deterministic slots for control and DCHs. | |||
channels. This initial AS time synchronization and time | This initial AS time synchronization and time synchronization | |||
synchronization maintenance is based on observing the synchronization | maintenance is based on observing the synchronization symbol pairs | |||
symbol pairs that repetitively occur within the FL stream, being sent | that repetitively occur within the FL stream being sent by the | |||
by the controlling GS [GRA2020]. As already mentioned, LDACS data | controlling GS [GRA2020]. As already mentioned, LDACS data | |||
transmission is split into user-data (DCH) and control (BCCH, CCCH in | transmission is split into user data (DCH) and control (BCCH and CCCH | |||
FL; RACH, DCCH in RL) as depicted with corresponding timings in | in FL; RACH and DCCH in RL) as depicted with corresponding timings in | |||
Figure 4. | Figure 4. | |||
^ | ^ | |||
| +--------+------------+------------+------------+------------+ | | +---------+------------+------------+------------+------------+ | |||
| FL | BCCH | MF | MF | MF | MF | | | FL | BCCH | MF | MF | MF | MF | | |||
| | 6.72ms | 58.32ms | 58.32ms | 58.32ms | 58.32ms | | | | 6.72 ms | 58.32 ms | 58.32 ms | 58.32 ms | 58.32 ms | | |||
F +--------+------------+------------+------------+------------+ | F +---------+------------+------------+------------+------------+ | |||
r <----------------- Super-Frame (SF) - 240ms -----------------> | r <----------------- Super-Frame (SF) - 240 ms -----------------> | |||
e | e | |||
q +--------+------------+------------+------------+------------+ | q +---------+------------+------------+------------+------------+ | |||
u RL | RACH | MF | MF | MF | MF | | u RL | RACH | MF | MF | MF | MF | | |||
e | 6.72ms | 58.32ms | 58.32ms | 58.32ms | 58.32ms | | e | 6.72 ms | 58.32 ms | 58.32 ms | 58.32 ms | 58.32 ms | | |||
n +--------+------------+------------+------------+------------+ | n +---------+------------+------------+------------+------------+ | |||
c <----------------- Super-Frame (SF) - 240ms -----------------> | c <----------------- Super-Frame (SF) - 240 ms -----------------> | |||
y | y | |||
------------------------------ Time -------------------------------> | ------------------------------ Time --------------------------------> | |||
| | | | |||
Figure 3: SF structure for LDACS | Figure 3: SF Structure for LDACS | |||
^ | ^ | |||
| +-------------+----------------+-----------------+ | | +--------------+-----------------+------------------+ | |||
| FL | DCH | CCCH | DCH | | | FL | DCH | CCCH | DCH | | |||
| | 25.92ms | 2.16 - 17.28ms | 15.12 - 30.24ms | | | | 25.92 ms | 2.16 - 17.28 ms | 15.12 - 30.24 ms | | |||
F +-------------+----------------+-----------------+ | F +--------------+-----------------+------------------+ | |||
r <----------- Multi-Frame (MF) - 58.32ms ---------> | r <----------- Multiframe (MF) - 58.32 ms -----------> | |||
e | e | |||
q +--------------+---------------------------------+ | q +---------------+----------------------------------+ | |||
u RL | DCCH | DCH | | u RL | DCCH | DCH | | |||
e | 2.8 - 24.4ms | 33.84 - 55.44ms | | e | 2.8 - 24.4 ms | 33.84 - 55.44 ms | | |||
n +--------------+---------------------------------+ | n +---------------+----------------------------------+ | |||
c <----------- Multi-Frame (MF) - 58.32ms ---------> | c <----------- Multiframe (MF) - 58.32 ms ----------> | |||
y | y | |||
----------------------------- Time --------------------> | ----------------------------- Time ----------------------> | |||
| | | | |||
Figure 4: MF structure for LDACS | Figure 4: MF Structure for LDACS | |||
LDACS cell entry is conducted with an initial control message | LDACS cell entry is conducted with an initial control message | |||
exchange via the RACH and the BCCH. | exchange via the RACH and the BCCH. | |||
After cell entry, LDACS medium access is always under the control of | After cell entry, LDACS medium access is always under the control of | |||
the GS of a radio cell. Any medium access for the transmission of | the GS of a radio cell. Any medium access for the transmission of | |||
user data on a DCH has to be requested with a resource request | user data on a DCH has to be requested with a resource request | |||
message stating the requested amount of resources and class of | message stating the requested amount of resources and class of | |||
service. The GS performs resource scheduling on the basis of these | service. The GS performs resource scheduling on the basis of these | |||
requests and grants resources with resource allocation messages. | requests and grants resources with resource allocation messages. | |||
Resource request and allocation messages are exchanged over dedicated | Resource request and allocation messages are exchanged over dedicated | |||
contention-free control channels (DCCH and CCCH). | contention-free control channels (DCCH and CCCH). | |||
The purpose of quality-of-service in LDACS medium access is to | The purpose of QoS in LDACS medium access is to provide prioritized | |||
provide prioritized medium access at the bottleneck (the wireless | medium access at the bottleneck (the wireless link). Signaling of | |||
link). Signaling of higher layer quality-of-service requests to | higher-layer QoS requests to LDACS is implemented on the basis of | |||
LDACS is implemented on the basis of Differentiated | Differentiated Services (Diffserv) classes CS01 (lowest priority) to | |||
Services-(DiffServ) classes CS01 (lowest priority) to CS07 (highest | CS07 (highest priority). | |||
priority). | ||||
In addition to having full control over resource scheduling, the GS | In addition to having full control over resource scheduling, the GS | |||
can send forced handover commands for off-loading or channel | can send forced handover commands for off-loading or channel | |||
management, e.g., when the signal quality declines and a more | management, e.g., when the signal quality declines and a more | |||
suitable GS is in the AS's reach. With robust resource management of | suitable GS is in the AS's reach. With robust resource management of | |||
the capacities of the radio channel, reliability and robustness | the capacities of the radio channel, reliability and robustness | |||
measures are therefore also anchored in the LME. | measures are also anchored in the LME. | |||
In addition to radio resource management, the LDACS control channels | In addition to radio resource management, the LDACS control channels | |||
are also used to send keep-alive messages, when they are not | are also used to send keepalive messages when they are not otherwise | |||
otherwise used. Since the framing of the control channels is | used. Since the framing of the control channels is deterministic, | |||
deterministic, missing keep-alive messages can thus be immediately | missing keepalive messages can be immediately detected. This | |||
detected. This information is made available to the multilink | information is made available to the multilink protocols for fault | |||
protocols for fault management. | management. | |||
The protocol used to communicate faults is not defined in the LDACS | The protocol used to communicate faults is not defined in the LDACS | |||
specification. It is assumed that vendors would use industry | specification. It is assumed that vendors would use industry | |||
standard protocols like the Simple Network Management Protocol or the | standard protocols like the Simple Network Management Protocol or the | |||
Network Configuration Protocol, where security permits. | Network Configuration Protocol (NETCONF) where security permits. | |||
The LDACS data link layer protocol, running on top of the medium | The LDACS data link layer protocol, running on top of the medium | |||
access sub-layer, uses ARQ to provide reliable data transmission on | access sub-layer, uses ARQ to provide reliable data transmission on | |||
the data channel. | the DCH. It employs selective repeat ARQ with transparent | |||
fragmentation and reassembly to the resource allocation size to | ||||
It employs selective repeat ARQ with transparent fragmentation and | minimize latency and overhead without losing reliability. It ensures | |||
reassembly to the resource allocation size to minimize latency and | correct order of packet delivery without duplicates. In case of | |||
overhead without losing reliability. It ensures correct order of | transmission errors, it identifies lost fragments with deterministic | |||
packet delivery without duplicates. In case of transmission errors, | timers synced to the medium access frame structure and initiates | |||
it identifies lost fragments with deterministic timers synced to the | retransmission. | |||
medium access frame structure and initiates retransmission. | ||||
8.3. Beyond Layer 2 | 8.3. Beyond Layer 2 | |||
LDACS availability can be increased by appropriately deploying LDACS | LDACS availability can be increased by appropriately deploying LDACS | |||
infrastructure: This means proliferating the number of terrestrial | infrastructure. This means proliferating the number of terrestrial | |||
ground stations. However, there are four aspects that need to be | GSs. However, there are four aspects that need to be taken into | |||
taken into consideration: (1) scarcity of aeronautical spectrum for | consideration: (1) scarcity of aeronautical spectrum for data link | |||
data link communication (in the case of LDACS: tens of MHz in the | communication (tens of MHz in the L-band in the case of LDACS), (2) | |||
L-band), (2) an increase in the amount of ground stations also | an increase in the number of GSs also increases the individual | |||
increases the individual bandwidth for aircraft in the cell, as fewer | bandwidth for aircraft in the cell, as fewer aircraft have to share | |||
aircraft have to share the spectrum, (3) to cover worldwide | the spectrum, (3) covering worldwide terrestrial ATM via LDACS is | |||
terrestrial ATM via LDACS is also a question of cost and the possible | also a question of cost and the possible reuse of spectrum, which | |||
reuse of spectrum which makes it not always possible to decrease cell | makes it not always possible to decrease cell sizes, and (4) the | |||
sizes and (4) the Distance Measuring Equipment (DME) is the primary | Distance Measuring Equipment (DME) is the primary user of the | |||
user of the aeronautical L-band, which means any LDACS deployment has | aeronautical L-band, which means any LDACS deployment has to take DME | |||
to take DME frequency planning into account. | frequency planning into account. | |||
While aspect (2) provides a good reason, alongside increasing | While aspect (2) provides a good reason alongside increasing | |||
redundancy, for smaller cells than the maximum range LDACS was | redundancy for smaller cells than the maximum range LDACS was | |||
developed for (200 Nautical Miles (NM)), the other three need to be | developed for (200 nm), the other three need to be respected when | |||
respected when doing so. There are preliminary works on LDACS cell | doing so. There are preliminary works on LDACS cell planning, such | |||
planning, such as [MOST2018], where the authors reach the conclusion | as [MOST2018], where the authors concluded that 84 LDACS cells in | |||
that 84 LDACS cells in Europe would be sufficient to serve European | Europe would be sufficient to serve European air traffic for the next | |||
air traffic for the next 20 years. | 20 years. | |||
For redundancy reasons, the aeronautical community has decided not to | For redundancy reasons, the aeronautical community has decided not to | |||
rely on a single communication system or frequency band. It is | rely on a single communication system or frequency band. It is | |||
envisioned to have multiple independent data link technologies in the | envisioned to have multiple independent data link technologies in the | |||
aircraft (e.g., terrestrial and satellite communications) in addition | aircraft (e.g., terrestrial and satellite communications) in addition | |||
to legacy VHF voice. | to legacy VHF voice. | |||
However, as of now, no reliability and availability mechanisms that | However, as of now, no reliability and availability mechanisms that | |||
could utilize the multilink architecture, have been specified on | could utilize the multilink architecture have been specified on Layer | |||
Layer 3 and above. Even if LDACS has been designed for reliability, | 3 and above. Even if LDACS has been designed for reliability, the | |||
the wireless medium presents significant challenges to achieve | wireless medium presents significant challenges to achieve | |||
deterministic properties such as low packet error rate, bounded | deterministic properties such as low packet error rate, bounded | |||
consecutive losses, and bounded latency. Support for high | consecutive losses, and bounded latency. Support for high | |||
reliability and availability for IP connectivity over LDACS is | reliability and availability for IP connectivity over LDACS is highly | |||
certainly highly desirable but needs to be adapted to the specific | desirable, but support needs to be adapted to the specific use case. | |||
use case. | ||||
9. Security | 9. Security Considerations | |||
The goal of this Section is to inform the reader about the state of | The goal of this section is to inform the reader about the state of | |||
security in aeronautical communications, state security | security in aeronautical communications and the state security | |||
considerations applicable for all ATN/IPS traffic and to provide an | considerations applicable for all ATN/IPS traffic and to provide an | |||
overview of the LDACS link-layer security capabilities. | overview of the LDACS link-layer security capabilities. | |||
9.1. Security in Wireless Digital Aeronautical Communications | 9.1. Security in Wireless Digital Aeronautical Communications | |||
Aviation will require secure exchanges of data and voice messages for | Aviation will require secure exchanges of data and voice messages for | |||
managing the air traffic flow safely through the airspaces all over | managing the air traffic flow safely through the airspaces all over | |||
the world. Historically Communication Navigation Surveillance (CNS) | the world. Historically, Communication Navigation Surveillance (CNS) | |||
wireless communications technology emerged from the military and a | wireless communications technology emerged from the military and a | |||
threat landscape where inferior technological and financial | threat landscape where inferior technological and financial | |||
capabilities of adversaries were assumed [STR2016]. The main | capabilities of adversaries were assumed [STR2016]. The main | |||
communications method for ATC today is still an open analogue voice | communications method for ATC today is still an open analog voice | |||
broadcast within the aeronautical VHF band. Currently, information | broadcast within the aeronautical VHF band. Currently, information | |||
security is mainly procedural, based by using well-trained personnel | security is mainly procedural and based by using well-trained | |||
and proven communications procedures. This communication method has | personnel and proven communications procedures. This communication | |||
been in service since 1948. However, since the emergence of civil | method has been in service since 1948. However, the world has | |||
aeronautical CNS applications in the 70s, and today, the world has | changed since the emergence of civil aeronautical CNS applications in | |||
changed. | the 70s. | |||
CCivil applications have significant lower spectrum available than | Civil applications have significant lower spectrum available than | |||
military applications. This means several military defense | military applications. This means that several military defense | |||
mechanisms, such as frequency hopping or pilot symbol scrambling and, | mechanisms such as frequency hopping or pilot symbol scrambling (and | |||
thus, a defense-in-depth approach starting at the physical layer, is | thus a defense-in-depth approach starting at the physical layer) are | |||
infeasible for civil systems. With the rise of cheap Software | infeasible for civil systems. With the rise of cheap Software- | |||
Defined Radios (SDR), the previously existing financial barrier is | Defined Radios (SDRs), the previously existing financial barrier is | |||
almost gone and open source projects such as GNU radio [GNU2021] | almost gone, and open source projects such as GNU radio [GNU2021] | |||
allow a new type of unsophisticated listeners and possible attackers. | allow for a new type of unsophisticated listener and possible | |||
attacker. | ||||
Most CNS technology developed in ICAO relies on open standards, thus | Most CNS technology developed in ICAO relies on open standards; thus, | |||
syntax and semantics of wireless digital aeronautical communications | syntax and semantics of wireless digital aeronautical communications | |||
should be expected to be common knowledge for attackers. With | should be expected to be common knowledge for attackers. With | |||
increased digitization and automation of civil aviation, the human as | increased digitization and automation of civil aviation, the human as | |||
control instance, is being taken gradually out of the loop. | control instance is being taken gradually out of the loop. | |||
Autonomous transport drones or single piloted aircraft demonstrate | Autonomous transport drones or single-piloted aircraft demonstrate | |||
this trend. However, without profound cybersecurity measures such as | this trend. However, without profound cybersecurity measures, such | |||
authenticity and integrity checks of messages in-transit on the | as authenticity and integrity checks of messages in-transit on the | |||
wireless link or mutual entity authentication, this lack of a control | wireless link or mutual entity authentication, this lack of a control | |||
instance can prove disastrous. Thus, future digital communications | instance can prove disastrous. Thus, future digital communications | |||
will need additional embedded security features to fulfill modern | will need additional embedded security features to fulfill modern | |||
information security requirements like authentication and integrity. | information security requirements like authentication and integrity. | |||
These security features require sufficient bandwidth which is beyond | These security features require sufficient bandwidth, which is beyond | |||
the capabilities of currently deployed VHF narrowband communications | the capabilities of currently deployed VHF narrowband communications | |||
systems. For voice and data communications, sufficient data | systems. For voice and data communications, sufficient data | |||
throughput capability is needed to support the security functions | throughput capability is needed to support the security functions | |||
while not degrading performance. LDACS is a data link technology | while not degrading performance. LDACS is a data link technology | |||
with sufficient bandwidth to incorporate security without losing too | with sufficient bandwidth to incorporate security without losing too | |||
much user data throughput. | much user data throughput. | |||
9.2. Security in Depth | 9.2. Security in Depth | |||
ICAO Doc 9896 foresees transport layer security [ICAO2015] for all | ICAO Doc 9896 [ICAO2015] foresees transport layer security for all | |||
aeronautical data transmitted via the ATN/IPS, as described in ARINC | aeronautical data transmitted via the ATN/IPS, as described in ARINC | |||
P858 [ARI2021]. This is realized via Datagram Transport Layer | 858 [ARI2021]. This is realized via Datagram Transport Layer | |||
Security (DTLS) 1.3 [RFC9147]. | Security (DTLS) 1.3 [RFC9147]. | |||
LDACS also needs to comply with in-depth security requirements, | LDACS also needs to comply with in-depth security requirements as | |||
stated in ARINC 858, for the radio access technologies transporting | stated in ARINC 858 for the radio access technologies transporting | |||
ATN/IPS data. These requirements imply that LDACS must provide layer | ATN/IPS data. These requirements imply that LDACS must provide Layer | |||
2 security in addition to any higher layer mechanisms. Specifically, | 2 security in addition to any higher-layer mechanisms. Specifically, | |||
ARINC 858 states that [datalinks within the FCI need to provide] "a | ARINC 858 [ARI2021] states that data links within the FCI need to | |||
secure channel between the airborne radio systems and the peer radio | provide | |||
access endpoints on the ground [...] to ensure authentication and | ||||
integrity of air-ground message exchanges in support of an overall | | a secure channel between the airborne radio systems and the peer | |||
defense-in-depth security strategy." [ARI2021] | | radio access endpoints on the ground [...] to ensure | |||
| authentication and integrity of air-ground message exchanges in | ||||
| support of an overall defense-in-depth security strategy. | ||||
9.3. LDACS Security Requirements | 9.3. LDACS Security Requirements | |||
Overall, cybersecurity for CNS technology shall protect the following | Overall, cybersecurity for CNS technology shall protect the following | |||
business goals [MAE20181]: | business goals [MAE20181]: | |||
1. Safety: The system must sufficiently mitigate attacks, which | 1. Safety: The system must sufficiently mitigate attacks that | |||
contribute to safety hazards. | contribute to safety hazards. | |||
2. Flight regularity: The system must sufficiently mitigate attacks, | 2. Flight regularity: The system must sufficiently mitigate attacks | |||
which contribute to delays, diversions, or cancellations of | that contribute to delays, diversions, or cancelations of | |||
flights. | flights. | |||
3. Protection of business interests: The system must sufficiently | 3. Protection of business interests: The system must sufficiently | |||
mitigate attacks which result in financial loss, reputation | mitigate attacks that result in financial loss, reputation | |||
damage, disclosure of sensitive proprietary information, or | damage, disclosure of sensitive proprietary information, or | |||
disclosure of personal information. | disclosure of personal information. | |||
To further analyze assets and derive threats and thus protection | To further analyze assets, derive threats, and create protection | |||
scenarios several threat-and risk analyses were performed for LDACS | scenarios, several threat and risk analyses were performed for LDACS | |||
[MAE20181] , [MAE20191]. These results allowed the derivation of | [MAE20181] [MAE20191]. These results allowed the derivation of | |||
security scope and objectives from the requirements and the conducted | security scope and objectives from the requirements and the conducted | |||
threat-and risk analysis. Note, IPv6 security considerations are | threat and risk analysis. Note, IPv6 security considerations are | |||
briefly discussed in Section 9.7 while a summary of security | briefly discussed in Section 9.7 while a summary of security | |||
requirements for link-layer candidates in the ATN/IPS is given in | requirements for link-layer candidates in the ATN/IPS is given in | |||
[ARI2021], which states: "Since the communication radios connect to | [ARI2021], which states: | |||
local airborne networks in the aircraft control domain, [...] the | ||||
airborne radio systems represent the first point of entry for an | | Since the communication radios connect to local airborne networks | |||
external threat to the aircraft. Consequently, a secure channel | | in the aircraft control domain, [...] the airborne radio systems | |||
between the airborne radio systems and the peer radio access | | represent the first point of entry for an external threat to the | |||
endpoints on the ground is necessary to ensure authentication and | | aircraft. Consequently, a secure channel between the airborne | |||
integrity of air-ground message exchanges in support of an overall | | radio systems and the peer radio access endpoints on the ground is | |||
defense-in-depth security strategy". | | necessary to ensure authentication and integrity of air-ground | |||
| message exchanges in support of an overall defense-in-depth | ||||
| security strategy. | ||||
9.4. LDACS Security Objectives | 9.4. LDACS Security Objectives | |||
Security considerations for LDACS are defined by the official SARPS | Security considerations for LDACS are defined by the official SARPS | |||
document by ICAO [ICAO2022]: | document by ICAO [ICAO2022]: | |||
1. LDACS shall provide a capability to protect the availability and | * LDACS shall provide a capability to protect the availability and | |||
continuity of the system. | continuity of the system. | |||
2. LDACS shall provide a capability including cryptographic | * LDACS shall provide a capability including cryptographic | |||
mechanisms to protect the integrity of messages in transit. | mechanisms to protect the integrity of messages in transit. | |||
3. LDACS shall provide a capability to ensure the authenticity of | * LDACS shall provide a capability to ensure the authenticity of | |||
messages in transit. | messages in transit. | |||
4. LDACS should provide a capability for nonrepudiation of origin | * LDACS should provide a capability for non-repudiation of origin | |||
for messages in transit. | for messages in transit. | |||
5. LDACS should provide a capability to protect the confidentiality | * LDACS should provide a capability to protect the confidentiality | |||
of messages in transit. | of messages in transit. | |||
6. LDACS shall provide an authentication capability. | * LDACS shall provide an authentication capability. | |||
7. LDACS shall provide a capability to authorize the permitted | * LDACS shall provide a capability to authorize the permitted | |||
actions of users of the system and to deny actions that are not | actions of users of the system and to deny actions that are not | |||
explicitly authorized. | explicitly authorized. | |||
8. If LDACS provides interfaces to multiple domains, LDACS shall | * If LDACS provides interfaces to multiple domains, LDACS shall | |||
provide capability to prevent the propagation of intrusions within | provide capability to prevent the propagation of intrusions within | |||
LDACS domains and towards external domains. | LDACS domains and towards external domains. | |||
Work in 2022 includes a change request for these SARPS aims to limit | Work in 2022 includes a change request for these SARPS aims to limit | |||
the "non-repudiation of origin of messages in transit" requirement | the "non-repudiation of origin of messages in transit" requirement | |||
only to the authentication and key establishment messages at the | only to the authentication and key establishment messages at the | |||
beginning of every session. | beginning of every session. | |||
9.5. LDACS Security Functions | 9.5. LDACS Security Functions | |||
These objectives were used to derive several security functions for | These objectives were used to derive several security functions for | |||
LDACS required to be integrated in the LDACS cybersecurity | LDACS required to be integrated in the LDACS cybersecurity | |||
architecture: Identification, Authentication, Authorization, | architecture: Identification, Authentication, Authorization, | |||
Confidentiality, System Integrity, Data Integrity, Robustness, | Confidentiality, System Integrity, Data Integrity, Robustness, | |||
Reliability, Availability, and Key and Trust Management. Several | Reliability, Availability, and Key and Trust Management. Several | |||
works investigated possible measures to implement these security | works investigated possible measures to implement these security | |||
functions [BIL2017], [MAE20181], [MAE20191]. | functions [BIL2017] [MAE20181] [MAE20191]. | |||
9.6. LDACS Security Architecture | 9.6. LDACS Security Architecture | |||
The requirements lead to a LDACS security model, including different | The requirements lead to an LDACS security model, including different | |||
entities for identification, authentication and authorization | entities for identification, authentication, and authorization | |||
purposes, ensuring integrity, authenticity and confidentiality of | purposes ensuring integrity, authenticity, and confidentiality of | |||
data. A draft of the cybersecurity architecture of LDACS can be | data. A draft of the cybersecurity architecture of LDACS can be | |||
found in [ICAO2022] and [MAE20182] and respective updates in | found in [ICAO2022] and [MAE20182], and respective updates can be | |||
[MAE20191], [MAE20192], [MAE2020], [MAE2021]. | found in [MAE20191], [MAE20192], [MAE2020], and [MAE2021]. | |||
9.6.1. Entities | 9.6.1. Entities | |||
A simplified LDACS architectural model requires the following | A simplified LDACS architectural model requires the following | |||
entities: Network operators such as the Societe Internationale de | entities: network operators such as the Societe Internationale de | |||
Telecommunications Aeronautiques (SITA) [SIT2020] and ARINC [ARI2020] | Telecommunications Aeronautiques (SITA) [SIT2020] and ARINC | |||
are providing access to the ground IPS network via an A/G LDACS | [ARI2020]; both entities provide access to the ground IPS network via | |||
router. This router is attached to an internal LDACS access network, | an A/G LDACS router. This router is attached to an internal LDACS | |||
which connects via further access routers to the different LDACS cell | access network that connects via further AC-Rs to the different LDACS | |||
ranges, each controlled by a GS (serving one LDACS cell), with | cell ranges, each controlled by a GS (serving one LDACS cell), with | |||
several interconnected GS spanning a local LDACS access network. Via | several interconnected GSs spanning a local LDACS access network. | |||
the A/G wireless LDACS data link AS the aircraft is connected to the | Via the A/G wireless LDACS data link AS, the aircraft is connected to | |||
ground network and via the aircraft's VI and aircraft's network | the ground network. Via the aircraft's VI and network interface, the | |||
interface, aircraft's data can be sent via the AS back to the GS, | aircraft's data can be sent via the AS back to the GS, then to the | |||
then to the LDACS local access network, access routers, LDACS access | LDACS local access network, AC-Rs, LDACS access network, A/G LDACS | |||
network, A/G LDACS router and finally to the ground IPS network | router, and finally to the ground IPS network [ICAO2015]. | |||
[ICAO2015]. | ||||
9.6.2. Entity Identification | 9.6.2. Entity Identification | |||
LDACS needs specific identities for the AS, the GS, and the network | LDACS needs specific identities for the AS, the GS, and the network | |||
operator. The aircraft itself can be identified using the 24-bit | operator. The aircraft itself can be identified using the 24-bit | |||
ICAO identifier of an aircraft [ICAO2022], the call sign of that | ICAO identifier of an aircraft [ICAO2022], the call sign of that | |||
aircraft or the recently founded privacy ICAO address of the Federal | aircraft, or the recently founded privacy ICAO address of the Federal | |||
Aviation Administration (FAA) program with the same name [FAA2020]. | Aviation Administration (FAA) program with the same name [FAA2020]. | |||
It is conceivable that the LDACS AS will use a combination of | It is conceivable that the LDACS AS will use a combination of | |||
aircraft identification, radio component identification and even | aircraft identification, radio component identification, and even | |||
operator feature identification to create a unique AS LDACS | operator feature identification to create a unique LDACS AS | |||
identification tag. Similar to a 4G's eNodeB serving network | identification tag. Similar to a 4G's eNodeB-serving network | |||
identification tag, a GS could be identified using a similar field. | identification tag, a GS could be identified using a similar field. | |||
The identification of the network operator is again similar to 4G | The identification of the network operator is similar to 4G (e.g., | |||
(e.g., E-Plus, AT&T, and TELUS), in the way that the aeronautical | E-Plus, AT&T, and TELUS), in the way that the aeronautical network | |||
network operators are listed (e.g., ARINC [ARI2020] and SITA | operators are listed (e.g., ARINC [ARI2020] and SITA [SIT2020]). | |||
[SIT2020]). | ||||
9.6.3. Entity Authentication and Key Establishment | 9.6.3. Entity Authentication and Key Establishment | |||
In order to anchor trust within the system, all LDACS entities | In order to anchor trust within the system, all LDACS entities | |||
connected to the ground IPS network will be rooted in an LDACS | connected to the ground IPS network will be rooted in an LDACS- | |||
specific chain-of-trust and PKI solution, quite similar to AeroMACS's | specific chain-of-trust and PKI solution, quite similar to AeroMACS's | |||
approach [CRO2016]. These certificates, residing at the entities and | approach [CRO2016]. These certificates, residing at the entities and | |||
incorporated in the LDACS PKI, providing proof the ownership of their | incorporated in the LDACS PKI, provide proof of the ownership of | |||
respective public key, include information about the identity of the | their respective public key and include information about the | |||
owner and the digital signature of the entity that has verified the | identity of the owner and the digital signature of the entity that | |||
certificate's content. First, all ground infrastructures must | has verified the certificate's content. First, all ground | |||
mutually authenticate to each other, negotiate and derive keys and, | infrastructures must mutually authenticate to each other, negotiate | |||
thus, secure all ground connections. How this process is handled in | and derive keys, and then secure all ground connections. How this | |||
detail is still an ongoing discussion. However, established methods | process is handled in detail is still an ongoing discussion. | |||
to secure user plane by IPSec [RFC4301] and IKEv2 [RFC7296] or the | However, established methods to secure the user plane by IPsec | |||
application layer via TLS 1.3 [RFC8446] are conceivable. The LDACS | [RFC4301] and IKEv2 [RFC7296] or the application layer via TLS 1.3 | |||
PKI with its chain-of-trust approach, digital certificates and public | [RFC8446] are conceivable. The LDACS PKI with its chain-of-trust | |||
entity keys lay the groundwork for this step. In a second step, the | approach, digital certificates, and public entity keys lay the | |||
AS with the LDACS radio aboard, approaches an LDACS cell and performs | groundwork for this step. In a second step, the AS with the LDACS | |||
a cell-attachment procedure with the corresponding GS. This | radio aboard approaches an LDACS cell and performs a cell-attachment | |||
procedure consists of (1) the basic cell entry [GRA2020] and (2) a | procedure with the corresponding GS. This procedure consists of (1) | |||
Mutual Authentication and Key Establishment (MAKE) procedure | the basic cell entry [GRA2020] and (2) a MAKE procedure [MAE2021]. | |||
[MAE2021]. | ||||
Note that LDACS will foresee multiple security levels. To address | Note that LDACS will foresee multiple security levels. To address | |||
the issue of the long service life of LDACS (i.e., possibly >30 | the issue of the long service life of LDACS (i.e., possibly greater | |||
years) and the security of current pre-quantum cryptography, these | than 30 years) and the security of current pre-quantum cryptography, | |||
security levels include pre- and post-quantum cryptographic | these security levels include pre-quantum and post-quantum | |||
solutions. Limiting security data on the LDACS datalink as much as | cryptographic solutions. Limiting security data on the LDACS data | |||
possible, to reserve as much space for actual user data transmission, | link as much as possible to reserve as much space for actual user | |||
is key in the LDACS security architecture, this is also reflected in | data transmission is key in the LDACS security architecture. This is | |||
the underlying cryptography: Pre-quantum solutions will rely on | also reflected in the underlying cryptography. Pre-quantum solutions | |||
elliptic curves [NIST2013], while post-quantum solutions consider | will rely on elliptic curves [NIST2013], while post-quantum solutions | |||
Falcon [SON2021] [MAE2021] or similar lightweight PQC signature | consider Falcon [SON2021] [MAE2021] or similar lightweight PQC | |||
schemes, and CRYSTALS-KYBER or SABER as key establishment options | signature schemes and CRYSTALS-KYBER or SABER as key establishment | |||
[AVA2021] [ROY2020]. | options [AVA2021] [ROY2020]. | |||
9.6.4. Message-in-transit Confidentiality, Integrity and Authenticity | 9.6.4. Message-In-Transit Confidentiality, Integrity, and Authenticity | |||
The key material from the previous step can then be used to protect | The key material from the previous step can then be used to protect | |||
LDACS Layer 2 communications via applying encryption and integrity | LDACS Layer 2 communications via applying encryption and integrity | |||
protection measures on the SNP layer of the LDACS protocol stack. As | protection measures on the SNP layer of the LDACS protocol stack. As | |||
LDACS transports AOC and ATS data, the integrity of that data is most | LDACS transports AOC and ATS data, the integrity of that data is most | |||
important, while confidentiality only needs to be applied to AOC data | important while confidentiality only needs to be applied to AOC data | |||
to protect business interests [ICAO2022]. This possibility of | to protect business interests [ICAO2022]. This possibility of | |||
providing low layered confidentiality and integrity protection | providing low-layered confidentiality and integrity protection | |||
ensures a secure delivery of user data over the wireless link. | ensures a secure delivery of user data over the wireless link. | |||
Furthermore, it ensures integrity protection of LDACS control data. | Furthermore, it ensures integrity protection of LDACS control data. | |||
9.7. Considerations on LDACS Security Impact on IPv6 Operational | 9.7. Considerations on LDACS Security Impact on IPv6 Operational | |||
Security | Security | |||
In this part, considerations on IPv6 operational security in | In this part, considerations on IPv6 operational security in | |||
[RFC9099] and interrelations with the LDACS security additions are | [RFC9099] and interrelations with the LDACS security additions are | |||
compared and evaluated to identify further protection demands. As | compared and evaluated to identify further protection demands. As | |||
IPv6 heavily relies on the Neighbor Discovery Protocol (NDP) | IPv6 heavily relies on the Neighbor Discovery Protocol (NDP) | |||
[RFC4861], integrity and authenticity protection on the link-layer, | [RFC4861], integrity and authenticity protection on the link layer, | |||
as provided by LDACS, already help mitigate spoofing and redirection | as provided by LDACS, already help mitigate spoofing and redirection | |||
attacks. However, to also mitigate the threat of remote DDoS | attacks. However, to also mitigate the threat of remote DDoS | |||
attacks, neighbor solicitation rate-limiting is recommended by RFC | attacks, neighbor solicitation rate-limiting is recommended by | |||
9099. To prevent the threat of (D)DoS attacks in general on the | [RFC9099]. To prevent the threat of DDoS and DoS attacks in general | |||
LDACS access network, rate-limiting needs to be performed on each | on the LDACS access network, rate-limiting needs to be performed on | |||
network node in the LDACS access network. One approach is to filter | each network node in the LDACS access network. One approach is to | |||
for the total amount of possible LDACS AS-GS traffic per cell - i.e., | filter for the total amount of possible LDACS AS-GS traffic per cell | |||
of up to 1.4 Mbps user-data per cell and up to the amount of GS per | (i.e., of up to 1.4 Mbit/s user data per cell and up to the amount of | |||
service provider network times 1.4 Mbps. | GS per service provider network times 1.4 Mbit/s). | |||
10. IANA Considerations | 10. IANA Considerations | |||
This memo includes no request to IANA. | This document has no IANA actions. | |||
11. Acknowledgements | 11. Informative References | |||
Thanks to all contributors to the development of LDACS and ICAO PT-T, | [ARI2019] ARINC, "AOC AIR-GROUND DATA AND MESSAGE EXCHANGE FORMAT", | |||
as well as to all in the RAW Working Group for deep discussions and | ARINC 633, January 2019, | |||
feedback. | <https://standards.globalspec.com/std/13152055/ | |||
ARINC%20633>. | ||||
Thanks to Klaus-Peter Hauf, Bart Van Den Einden, and Pierluigi | [ARI2020] "Aeronautical Radio Incorporated (ARINC) Industry | |||
Fantappie for their comments to this draft. | Activities", <https://www.aviation-ia.com/>. | |||
Thanks to the Chair for Network Security and the research institute | [ARI2021] ARINC, "INTERNET PROTOCOL SUITE (IPS) FOR AERONAUTICAL | |||
CODE for their comments and improvements. | SAFETY SERVICES PART 1 AIRBORNE IPS SYSTEM TECHNICAL | |||
REQUIREMENTS", ARINC 858P1, June 2021, | ||||
<https://standards.globalspec.com/std/14391274/858p1>. | ||||
Thanks to the colleagues of the Research Institute CODE at the UniBwM | [AVA2021] Avanzi, R., Bos, J., Ducas, L., Kiltz, E., Lepoint, T., | |||
working in the AMIUS project funded under the Bavarian Aerospace | Lyubashevsky, V., Schanck, J.M., Schwabe, P., Seiler, G., | |||
Program by the Bavarian State Ministry of Economics, Regional | and D. Stehlé, "CRYSTALS-KYBER - Algorithm Specification | |||
Development and Energy with the GA ROB-2-3410.20-04-11-15/HAMI- | and Supporting Documentation (version 3.02)", August 2021, | |||
2109-0015 for fruitful discussions on aeronautical communications and | <https://pq-crystals.org/kyber/data/kyber-specification- | |||
relevant security incentives for the target market. | round3-20210804.pdf>. | |||
Thanks to SBA Research Vienna for continuous discussions on security | [BEL2019] Bellido-Manganell, M. A. and M. Schnell, "Towards Modern | |||
infrastructure issues in quick developing markets such the air space | Air-to-Air Communications: the LDACS A2A Mode", IEEE/AIAA | |||
and potential economic spillovers to used technologies and protocols. | 38th Digital Avionics Systems Conference (DASC), pp. 1-10, | |||
DOI 10.1109/DASC43569.2019.9081678, September 2019, | ||||
<https://doi.org/10.1109/DASC43569.2019.9081678>. | ||||
Thanks to the Aeronautical Communications group at the Institute of | [BEL2021] Bellido-Manganell, M.A., Gräupl, T., Heirich, O., Mäurer, | |||
Communications and Navigation of the German Aerospace Center (DLR). | N., Filip-Dhaubhadel, A., Mielke, D.M., Schalk, L.M., | |||
With that, the authors would like to explicitly thank Miguel Angel | Becker, D., Schneckenburger, N., and M. Schnell, "LDACS | |||
Bellido-Manganell and Lukas Marcel Schalk for their thorough | Flight Trials: Demonstration and Performance Analysis of | |||
feedback. | the Future Aeronautical Communications System", IEEE | |||
Transactions on Aerospace and Electronic Systems, Vol. 58, | ||||
Issue 1, pp. 615-634, DOI 10.1109/TAES.2021.3111722, | ||||
September 2021, | ||||
<https://doi.org/10.1109/TAES.2021.3111722>. | ||||
12. Normative References | [BIL2017] Bilzhause, A., Belgacem, B., Mostafa, M., and T. Gräupl, | |||
"Datalink security in the L-band digital aeronautical | ||||
communications system (LDACS) for air traffic management", | ||||
IEEE Aerospace and Electronic Systems Magazine, Vol. 32, | ||||
Issue 11, pp. 22-33, DOI 10.1109/MAES.2017.160282, | ||||
November 2017, <https://doi.org/10.1109/MAES.2017.160282>. | ||||
13. Informative References | [BOE2019] Boegl, T., Rautenberg, M., Haindl, R., Rihacek, C., Meser, | |||
J., Fantappie, P., Pringvanich, N., Micallef, J., Hauf, | ||||
K., MacBride, J., Sacre, P., v.d. Eiden, B., Gräupl, T., | ||||
and M. Schnell, "LDACS White Paper - A Roll-out Scenario", | ||||
International Civil Aviation Organization, Communications | ||||
Panel - Data Communications Infrastructure Working Group - | ||||
Third Meeting, pp. 1-8, October 2019. | ||||
[CRO2016] Crowe, B., "Proposed AeroMACS PKI specification is a model | ||||
for global and National Aeronautical PKI Deployments", | ||||
Integrated Communications, Navigation and Surveillance | ||||
Conference (ICNS), pp. 1-19, | ||||
DOI 10.1109/ICNSURV.2016.7486405, April 2016, | ||||
<https://doi.org/10.1109/ICNSURV.2016.7486405>. | ||||
[DO350A] RTCA, "Safety and Performance Requirements Standard for | ||||
Baseline 2 ATS Data Communications (Baseline 2 SPR | ||||
Standard)", Vol. 1 & 2, RTCA DO-350, March 2016, | ||||
<https://standards.globalspec.com/std/10003192/rtca-do- | ||||
350-volume-1-2>. | ||||
[EURO2019] European Organization for Civil Aviation Equipment | ||||
(EUROCAE), "Technical Standard of Aviation Profiles for | ||||
ATN/IPS", ED 262, September 2019, | ||||
<https://eshop.eurocae.net/eurocae-documents-and-reports/ | ||||
ed-262/>. | ||||
[FAA2020] Federal Aviation Administration, "ADS-B Privacy", February | ||||
2023, | ||||
<https://www.faa.gov/air_traffic/technology/equipadsb/ | ||||
privacy>. | ||||
[GNU2021] GNU Radio Project, "GNU Radio", <http://gnuradio.org>. | ||||
[GRA2011] Gräupl, T. and M. Ehammer, "LDACS1 data link layer | ||||
evolution for ATN/IPS", IEEE/AIAA 30th Digital Avionics | ||||
Systems Conference (DASC), pp. 1-28, | ||||
DOI 10.1109/DASC.2011.6096230, October 2011, | ||||
<https://doi.org/10.1109/DASC.2011.6096230>. | ||||
[GRA2018] Gräupl, T., Schneckenburger, N., Jost, T., Schnell, M., | ||||
Filip, A., Bellido-Manganell, M.A., Mielke, D.M., Mäurer, | ||||
N., Kumar, R., Osechas, O., and G. Battista, "L-band | ||||
Digital Aeronautical Communications System (LDACS) flight | ||||
trials in the national German project MICONAV", Integrated | ||||
Communications, Navigation, Surveillance Conference | ||||
(ICNS), pp. 1-7, DOI 10.1109/ICNSURV.2018.8384881, April | ||||
2018, <https://doi.org/10.1109/ICNSURV.2018.8384881>. | ||||
[GRA2020] Gräupl, T., "Initial LDACS A/G Specification", SESAR2020 | ||||
- PJ14-W2-60, D3.1.210, December 2020, | ||||
<https://www.ldacs.com/wp-content/uploads/2013/12/SESAR202 | ||||
0_PJ14-W2-60_D3_1_210_Initial_LDACS_AG_Specification_00_01 | ||||
_00-1_0_updated.pdf>. | ||||
[ICAO2015] International Civil Aviation Organization (ICAO), "Manual | ||||
on the Aeronautical Telecommunication Network (ATN) using | ||||
Internet Protocol Suite (IPS) Standards and Protocol", | ||||
ICAO 9896, January 2015, | ||||
<https://standards.globalspec.com/std/10026940/icao-9896>. | ||||
[ICAO2018] International Civil Aviation Organization (ICAO), | ||||
"Handbook on Radio Frequency Spectrum Requirements for | ||||
Civil Aviation", Vol. 1, ICAO Spectrum Strategy, Policy | ||||
Statements and Related Information, Doc 9718, AN/957, July | ||||
2018, <https://www.icao.int/safety/FSMP/Documents/Doc9718/ | ||||
Doc.9718%20Vol.%20I%20(AdvanceUneditedVersion%202021).pdf> | ||||
. | ||||
[ICAO2019] International Civil Aviation Organization (ICAO), "Manual | ||||
on VHF Digital Link (VDL) Mode 2", Second Edition, | ||||
Doc 9776, 2015, <https://store.icao.int/en/manual-on-vhf- | ||||
digital-link-vdl-mode-2-doc-9776>. | ||||
[ICAO2022] International Civil Aviation Organization (ICAO), "CHAPTER | ||||
13 L-Band Digital Aeronautical Communications System | ||||
(LDACS)", International Standards and Recommended | ||||
Practices, Annex 10 - Aeronautical Telecommunications, | ||||
Volume III, Communication Systems, 2022, | ||||
<https://www.ldacs.com/wp-content/uploads/2023/03/ | ||||
WP06.AppA-DCIWG-6-LDACS_SARPs.pdf>. | ||||
[KAMA2010] Kamali, B., "An overview of VHF civil radio network and | ||||
the resolution of spectrum depletion", Integrated | ||||
Communications, Navigation, and Surveillance Conference, | ||||
pp. F4-1-F4-8, DOI 10.1109/ICNSURV.2010.5503256, May 2010, | ||||
<https://doi.org/10.1109/ICNSURV.2010.5503256>. | ||||
[KAMA2018] Kamali, B., "AeroMACS: An IEEE 802.16 Standard-Based | ||||
Technology for the Next Generation of Air Transportation | ||||
Systems", DOI 10.1002/9781119281139, September 2018, | ||||
<https://doi.org/10.1002/9781119281139>. | ||||
[LISP-GB-ATN] | ||||
Haindl, B., Lindner, M., Moreno, V., Portoles-Comeras, M., | ||||
Maino, F., and B. Venkatachalapathy, "Ground-Based LISP | ||||
for the Aeronautical Telecommunications Network", Work in | ||||
Progress, Internet-Draft, draft-haindl-lisp-gb-atn-08, 23 | ||||
September 2022, <https://datatracker.ietf.org/doc/html/ | ||||
draft-haindl-lisp-gb-atn-08>. | ||||
[MAE20181] Mäurer, N. and A. Bilzhause, "Paving the way for an it | ||||
security architecture for LDACS: A datalink security | ||||
threat and risk analysis", IEEE Integrated Communications, | ||||
Navigation, Surveillance Conference (ICNS), pp. 1-11, | ||||
DOI 10.1109/ICNSURV.2018.8384828, April 2018, | ||||
<https://doi.org/10.1109/ICNSURV.2018.8384828>. | ||||
[MAE20182] Mäurer, N. and A. Bilzhause, "A Cybersecurity Architecture | ||||
for the L-band Digital Aeronautical Communications System | ||||
(LDACS)", IEEE/AIAA 37th Digital Avionics Systems | ||||
Conference (DASC), pp. 1-10, | ||||
DOI 10.1109/DASC.2018.8569878, September 2018, | ||||
<https://doi.org/10.1109/DASC.2018.8569878>. | ||||
[MAE20191] Mäurer, N., Gräupl, T., and C. Schmitt, "Evaluation of the | ||||
LDACS Cybersecurity Implementation", IEEE 38th Digital | ||||
Avionics Systems Conference (DASC), pp. 1-10, | ||||
DOI 10.1109/DASC43569.2019.9081786, September 2019, | ||||
<https://doi.org/10.1109/DASC43569.2019.9081786>. | ||||
[MAE20192] Mäurer, N. and C. Schmitt, "Towards Successful Realization | ||||
of the LDACS Cybersecurity Architecture: An Updated | ||||
Datalink Security Threat- and Risk Analysis", IEEE | ||||
Integrated Communications, Navigation and Surveillance | ||||
Conference (ICNS), pp. 1-13, | ||||
DOI 10.1109/ICNSURV.2019.8735139, April 2019, | ||||
<https://doi.org/10.1109/ICNSURV.2019.8735139>. | ||||
[MAE2020] Mäurer, N., Gräupl, T., Gentsch, C., and C. Schmitt, | ||||
"Comparing Different Diffie-Hellman Key Exchange Flavors | ||||
for LDACS", IEEE/AIAA 39th Digital Avionics Systems | ||||
Conference (DASC), pp. 1-10, | ||||
DOI 10.1109/DASC50938.2020.9256746, October 2020, | ||||
<https://doi.org/10.1109/DASC50938.2020.9256746>. | ||||
[MAE2021] Mäurer, N., Gräupl, T., Gentsch, C., Guggemos, T., | ||||
Tiepelt, M., Schmitt, C., and G. Dreo Rodosek, "A Secure | ||||
Cell-Attachment Procedure for LDACS", IEEE European | ||||
Symposium on Security and Privacy Workshops (EuroS&PW), | ||||
pp. 1-10, DOI 10.1109/EuroSPW54576.2021.00019, September | ||||
2021, <https://doi.org/10.1109/EuroSPW54576.2021.00019>. | ||||
[MAE20211] Mäurer, N., Gräupl, T., Bellido-Manganell, M.A., Mielke, | ||||
D.M., Filip-Dhaubhadel, A., Heirich, O., Gerberth, D., | ||||
Felux, M., Schalk, L.M., Becker, D., Schneckenburger, N., | ||||
and M. Schnell, "Flight Trial Demonstration of Secure GBAS | ||||
via the L-band Digital Aeronautical Communications System | ||||
(LDACS)", IEEE Aerospace and Electronic Systems Magazine, | ||||
Vol. 36, Issue 4, pp. 8-17, DOI 10.1109/MAES.2021.3052318, | ||||
April 2021, <https://doi.org/10.1109/MAES.2021.3052318>. | ||||
[MOST2018] Mostafa, M., Bellido-Manganell, M.A.., and T. Gräupl, | ||||
"Feasibility of Cell Planning for the L-Band Digital | ||||
Aeronautical Communications System Under the Constraint of | ||||
Secondary Spectrum Usage", IEEE Transactions on Vehicular | ||||
Technology, Vol. 67, Issue 10, pp. 9721-9733, | ||||
DOI 10.1109/TVT.2018.2862829, October 2018, | ||||
<https://doi.org/10.1109/TVT.2018.2862829>. | ||||
[NIST2013] National Institute of Standards and Technology (NIST), | ||||
"Digital Signature Standard (DSS)", FIPS PUB 186-4, | ||||
DOI 10.6028/NIST.FIPS.186-4, July 2013, | ||||
<https://doi.org/10.6028/NIST.FIPS.186-4>. | ||||
[OSE2019] Osechas, O., Narayanan, S., Crespillo, O.G., Zampieri, G., | ||||
Battista, G., Kumar, R., Schneckenburger, N., Lay, E., | ||||
Belabbas, B., and M. Meurer, "Feasibility Demonstration of | ||||
Terrestrial RNP with LDACS", 32nd International Technical | ||||
Meeting of the Satellite Division of The Institute of | ||||
Navigation, pp. 3254-3265, DOI 10.33012/2019.17119, | ||||
September 2019, <https://doi.org/10.33012/2019.17119>. | ||||
[RAW-TECHNOS] | ||||
Thubert, P., Ed., Cavalcanti, D., Vilajosana, X., Schmitt, | ||||
C., and J. Farkas, "Reliable and Available Wireless | ||||
Technologies", Work in Progress, Internet-Draft, draft- | ||||
ietf-raw-technologies-06, 30 November 2022, | ||||
<https://datatracker.ietf.org/doc/html/draft-ietf-raw- | ||||
technologies-06>. | ||||
[RAW-USE-CASES] | ||||
Bernardos, C. J., Ed., Papadopoulos, G. Z., Thubert, P., | ||||
and F. Theoleyre, "RAW Use-Cases", Work in Progress, | ||||
Internet-Draft, draft-ietf-raw-use-cases-09, 13 March | ||||
2023, <https://datatracker.ietf.org/doc/html/draft-ietf- | ||||
raw-use-cases-08>. | ||||
[RFC4301] Kent, S. and K. Seo, "Security Architecture for the | [RFC4301] Kent, S. and K. Seo, "Security Architecture for the | |||
Internet Protocol", RFC 4301, DOI 10.17487/RFC4301, | Internet Protocol", RFC 4301, DOI 10.17487/RFC4301, | |||
December 2005, <https://www.rfc-editor.org/info/rfc4301>. | December 2005, <https://www.rfc-editor.org/info/rfc4301>. | |||
[RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, | [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, | |||
"Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, | "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, | |||
DOI 10.17487/RFC4861, September 2007, | DOI 10.17487/RFC4861, September 2007, | |||
<https://www.rfc-editor.org/info/rfc4861>. | <https://www.rfc-editor.org/info/rfc4861>. | |||
skipping to change at page 32, line 44 ¶ | skipping to change at line 1664 ¶ | |||
[RFC9099] Vyncke, É., Chittimaneni, K., Kaeo, M., and E. Rey, | [RFC9099] Vyncke, É., Chittimaneni, K., Kaeo, M., and E. Rey, | |||
"Operational Security Considerations for IPv6 Networks", | "Operational Security Considerations for IPv6 Networks", | |||
RFC 9099, DOI 10.17487/RFC9099, August 2021, | RFC 9099, DOI 10.17487/RFC9099, August 2021, | |||
<https://www.rfc-editor.org/info/rfc9099>. | <https://www.rfc-editor.org/info/rfc9099>. | |||
[RFC9147] Rescorla, E., Tschofenig, H., and N. Modadugu, "The | [RFC9147] Rescorla, E., Tschofenig, H., and N. Modadugu, "The | |||
Datagram Transport Layer Security (DTLS) Protocol Version | Datagram Transport Layer Security (DTLS) Protocol Version | |||
1.3", RFC 9147, DOI 10.17487/RFC9147, April 2022, | 1.3", RFC 9147, DOI 10.17487/RFC9147, April 2022, | |||
<https://www.rfc-editor.org/info/rfc9147>. | <https://www.rfc-editor.org/info/rfc9147>. | |||
[GRA2020] Gräupl, T., Rihacek, C., and B. Haindl, "LDACS A/G | [RFC9300] Farinacci, D., Fuller, V., Meyer, D., Lewis, D., and A. | |||
Specification", SESAR2020 PJ14-02-01 D3.3.030 , 2020, | Cabellos, Ed., "The Locator/ID Separation Protocol | |||
<https://www.ldacs.com/wp-content/uploads/2013/12/SESAR202 | (LISP)", RFC 9300, DOI 10.17487/RFC9300, October 2022, | |||
0_PJ14-W2-60_D3_1_210_Initial_LDACS_AG_Specification_00_01 | <https://www.rfc-editor.org/info/rfc9300>. | |||
_00-1_0_updated.pdf>. | ||||
[ARI2021] ARINC, "Internet Protocol Suite (IPS) For Aeronautical | [RFC9301] Farinacci, D., Maino, F., Fuller, V., and A. Cabellos, | |||
Safety Services Part 1- Airborne IP System Technical | Ed., "Locator/ID Separation Protocol (LISP) Control | |||
Requirements, ARINC SPECIFICATION 858 P1", June 2021, | Plane", RFC 9301, DOI 10.17487/RFC9301, October 2022, | |||
<https://standards.globalspec.com/std/14391274/858p1>. | <https://www.rfc-editor.org/info/rfc9301>. | |||
[EURO2019] European Organization for Civil Aviation Equipment | [RIH2018] Rihacek, C., Haindl, B., Fantappie, P., Pierattelli, S., | |||
(EUROCAE), "Technical Standard of Aviation Profiles for | Gräupl, T., Schnell, M., and N. Fistas, "L-band Digital | |||
ATN/IPS, ED-262", September 2019, | Aeronautical Communications System (LDACS) activities in | |||
<https://eshop.eurocae.net/eurocae-documents-and-reports/ | SESAR2020", Integrated Communications Navigation and | |||
ed-262/>. | Surveillance Conference (ICNS), pp. 1-8, | |||
DOI 10.1109/ICNSURV.2018.8384880, April 2018, | ||||
<https://doi.org/10.1109/ICNSURV.2018.8384880>. | ||||
[ICAO2015] International Civil Aviation Organization (ICAO), "Manual | [ROY2020] Roy, S.S. and A. Basso, "High-speed Instruction-set | |||
on the Aeronautical Telecommunication Network (ATN) using | Coprocessor for Lattice-based Key Encapsulation Mechanism: | |||
Internet Protocol Suite (IPS) Standards and Protocols, Doc | Saber in Hardware", IACR Transactions on Cryptographic | |||
9896", January 2015, | Hardware and Embedded Systems, Vol. 2020, Issue 4, pp. | |||
<https://standards.globalspec.com/std/10026940/icao-9896>. | 443-466, DOI 10.13154/tches.v2020.i4.443-466, August 2020, | |||
<https://doi.org/10.13154/tches.v2020.i4.443-466>. | ||||
[RTCA2019] Radio Technical Commission for Aeronautics (RTCA), | [RTCA2019] Radio Technical Commission for Aeronautics (RTCA), | |||
"Internet Protocol Suite Profiles, DO-379", September | "Internet Protocol Suite Profiles", RTCA DO-379, September | |||
2019, <https://www.rtca.org/products/do-379/>. | 2019, <https://standards.globalspec.com/std/14224450/rtca- | |||
do-379>. | ||||
[SCH2016] Schneckenburger, N., Jost, T., Shutin, D., Walter, M., | ||||
Thiasiriphet, T., Schnell, M., and U.C. Fiebig, | ||||
"Measurement of the L-band Air-to-Ground Channel for | ||||
Positioning Applications", IEEE Transactions on Aerospace | ||||
and Electronic Systems, 52(5), pp.2281-229 , 2016. | ||||
[OSE2019] Osechas, O., Narayanan, S., Crespillo, O.G., Zampieri, G., | ||||
Battista, G., Kumar, R., Schneckenburger, N., Lay, E., | ||||
Belabbas, B., and M. Meurer, "Feasibility Demonstration of | ||||
Terrestrial RNP with LDACS", 32nd International Technical | ||||
Meeting of the Satellite Division of The Institute of | ||||
Navigation, pp.1-12 , 2019. | ||||
[SCHN2018] Schneckenburger, N., "A Wide-Band Air-Ground Channel | ||||
Mode", Dissertation, Technische Universitaet Ilmenau, | ||||
Ilmenau, Germany , 2018. | ||||
[MOST2018] Mostafa, M., Bellido-Manganell, M.A.., and T. Gräupl, | ||||
"Feasibility of Cell Planning for the L-Band Digital | ||||
Aeronautical Communications System Under the Constraint of | ||||
Secondary Spectrum Usage", IEEE Transactions on Vehicular | ||||
Technology, vol. 67, no. 10, pp. 9721-9733 , 2018. | ||||
[MAE20191] Mäurer, N., Gräupl, T., and C. Schmitt, "Evaluation of the | ||||
LDACS Cybersecurity Implementation", IEEE 38th Digital | ||||
Avionics Systems Conference (DACS), pp. 1-10, San Diego, | ||||
CA, USA , 2019. | ||||
[MAE20192] Mäurer, N. and C. Schmitt, "Towards Successful Realization | ||||
of the LDACS Cybersecurity Architecture: An Updated | ||||
Datalink Security Threat- and Risk Analysis", IEEE | ||||
Integrated Communications, Navigation and Surveillance | ||||
Conference (ICNS), pp. 1-13, Herndon, VA, USA , 2019. | ||||
[MAE20182] Mäurer, N. and A. Bilzhause, "A Cybersecurity Architecture | ||||
for the L-band Digital Aeronautical Communications System | ||||
(LDACS)", IEEE 37th Digital Avionics Systems Conference | ||||
(DASC), pp. 1-10, London, UK , 2017. | ||||
[GRA2011] Gräupl, T. and M. Ehammer, "L-DACS1 Data Link Layer | ||||
Evolution of ATN/IPS", 30th IEEE/AIAA Digital Avionics | ||||
Systems Conference (DASC), pp. 1-28, Seattle, WA, USA , | ||||
2011. | ||||
[GRA2018] Gräupl, T., Schneckenburger, N., Jost, T., Schnell, M., | ||||
Filip, A., Bellido-Manganell, M.A., Mielke, D.M., Mäurer, | ||||
N., Kumar, R., Osechas, O., and G. Battista, "L-band | ||||
Digital Aeronautical Communications System (LDACS) flight | ||||
trials in the national German project MICONAV", Integrated | ||||
Communications, Navigation, Surveillance Conference | ||||
(ICNS), pp. 1-7, Herndon, VA, USA , 2018. | ||||
[ICAO2022] International Civil Aviation Organization (ICAO), "L-Band | [RTGWG-ATN-BGP] | |||
Digital Aeronautical Communication System (LDACS", | Templin, F., Ed., Saccone, G., Dawra, G., Lindem, A., and | |||
International Standards and Recommended Practices Annex 10 | V. Moreno, "A Simple BGP-based Mobile Routing System for | |||
- Aeronautical Telecommunications, Vol. III - | the Aeronautical Telecommunications Network", Work in | |||
Communication Systems, 2022 , 2022. | Progress, Internet-Draft, draft-ietf-rtgwg-atn-bgp-19, 7 | |||
November 2022, <https://datatracker.ietf.org/doc/html/ | ||||
draft-ietf-rtgwg-atn-bgp-19>. | ||||
[SAJ2014] Haindl, B., Meser, J., Sajatovic, M., Müller, S., | [SAJ2014] Haindl, B., Meser, J., Sajatovic, M., Müller, S., | |||
Arthaber, H., Faseth, T., and M. Zaisberger, "LDACS1 | Arthaber, H., Faseth, T., and M. Zaisberger, "LDACS1 | |||
Conformance and Compatibility Assessment", IEEE/AIAA 33rd | conformance and compatibility assessment", IEEE/AIAA 33rd | |||
Digital Avionics Systems Conference (DASC), pp. 1-11, | Digital Avionics Systems Conference (DASC), pp. 1-11, | |||
Colorado Springs, CO, USA , 2014. | DOI 10.1109/DASC.2014.6979447, October 2014, | |||
<https://doi.org/10.1109/DASC.2014.6979447>. | ||||
[RIH2018] Rihacek, C., Haindl, B., Fantappie, P., Pierattelli, S., | ||||
Gräupl, T., Schnell, M., and N. Fistas, "L-band Digital | ||||
Aeronautical Communications System (LDACS) Activities in | ||||
SESAR2020", Integrated Communications Navigation and | ||||
Surveillance Conference (ICNS), pp. 1-8, Herndon, VA, | ||||
USA , 2018. | ||||
[BEL2019] Bellido-Manganell, M. A. and M. Schnell, "Towards Modern | ||||
Air-to-Air Communications: the LDACS A2A Mode", IEEE/AIAA | ||||
38th Digital Avionics Systems Conference (DASC), pp. 1-10, | ||||
San Diego, CA, USA , 2019. | ||||
[CRO2016] Crowe, B., "Proposed AeroMACS PKI Specification is a Model | ||||
for Global and National Aeronautical PKI Deployments", | ||||
WiMAX Forum at 16th Integrated Communications, Navigation | ||||
and Surveillance Conference (ICNS), pp. 1-19, New York, | ||||
NY, USA , 2016. | ||||
[MAE2020] Mäurer, N., Gräupl, T., and C. Schmitt, "Comparing | ||||
Different Diffie-Hellman Key Exchange Flavors for LDACS", | ||||
IEEE/AIAA 39th Digital Avionics Systems Conference (DASC), | ||||
pp. 1-10, San Antonio, TX, USA , 2020. | ||||
[STR2016] Strohmeier, M., Schäfer, M., Pinheiro, R., Lenders, V., | ||||
and I. Martinovic, "On Perception and Reality in Wireless | ||||
Air Traffic Communication Security", IEEE Transactions on | ||||
Intelligent Transportation Systems, 18(6), pp. 1338-1357, | ||||
New York, NY, USA , 2016. | ||||
[BIL2017] Bilzhause, A., Belgacem, B., Mostafa, M., and T. Gräupl, | ||||
"Datalink Security in the L-band Digital Aeronautical | ||||
Communications System (LDACS) for Air Traffic Management", | ||||
IEEE Aerospace and Electronic Systems Magazine, 32(11), | ||||
pp. 22-33, New York, NY, USA , 2017. | ||||
[MAE20181] Mäurer, N. and A. Bilzhause, "Paving the Way for an IT | ||||
Security Architecture for LDACS: A Datalink Security | ||||
Threat and Risk Analysis", IEEE Integrated Communications, | ||||
Navigation, Surveillance Conference (ICNS), pp. 1-11, New | ||||
York, NY, USA , 2018. | ||||
[FAA2020] FAA, "Federal Aviation Administration. ADS-B Privacy.", | ||||
August 2020, | ||||
<https://www.faa.gov/nextgen/equipadsb/privacy/>. | ||||
[GNU2021] GNU Radio project, "GNU radio", October 2021, | ||||
<http://gnuradio.org>. | ||||
[SIT2020] SITA, "Societe Internationale de Telecommunications | ||||
Aeronautiques", August 2020, <https://www.sita.aero/>. | ||||
[ARI2020] ARINC, "Aeronautical Radio Incorporated", August 2020, | ||||
<https://www.aviation-ia.com/>. | ||||
[DO350A] RTCA SC-214, "Safety and Performance Standard for Baseline | ||||
2 ATS Data Communications (Baseline 2 SPR Standard)", May | ||||
2016, <https://standards.globalspec.com/std/10003192/rtca- | ||||
do-350-volume-1-2>. | ||||
[ICAO2019] International Civil Aviation Organization (ICAO), "Manual | [SCH2016] Schneckenburger, N., Jost, T., Shutin, D., Walter, M., | |||
on VHF Digital Link (VDL) Mode 2, Doc 9776", January 2019, | Thiasiriphet, T., Schnell, M., and U.C. Fiebig, | |||
<https://store.icao.int/en/manual-on-vhf-digital-link-vdl- | "Measurement of the l-band air-to-ground channel for | |||
mode-2-doc-9776>. | positioning applications", IEEE Transactions on Aerospace | |||
and Electronic Systems, Vol. 52, Issue 5, pp. 2281-2297, | ||||
DOI 10.1109/TAES.2016.150451, October 2016, | ||||
<https://doi.org/10.1109/TAES.2016.150451>. | ||||
[KAMA2010] Kamali, B., "An Overview of VHF Civil Radio Network and | [SCHN2018] Schneckenburger, N., "A Wide-Band Air-Ground Channel | |||
the Resolution of Spectrum Depletion", Integrated | Model", Dissertation, Technischen Universitaet Ilmenau, | |||
Communications, Navigation, and Surveillance Conference, | February 2018. | |||
pp. F4-1-F4-8 , May 2010. | ||||
[KAMA2018] Kamali, B., "AeroMACS: An IEEE 802.16 Standard-based | [SHU2013] Shutin, D., Schneckenburger, N., Walter, M., and M. | |||
Technology for the Next Generation of Air Transportation | Schnell, "LDACS1 ranging performance - An analysis of | |||
Systems", John Wiley and Sons, DOI: | flight measurement results", IEEE 32nd Digital Avionics | |||
10.1002/9781119281139 , September 2018. | Systems Conference (DASC), pp. 1-10, | |||
DOI 10.1109/DASC.2013.6712567, October 2013, | ||||
<https://doi.org/10.1109/DASC.2013.6712567>. | ||||
[NIST2013] Barker, E., "Digital Signature Standard (DSS)", National | [SIT2020] "Societe Internationale de Telecommunica Aéronautique | |||
Institute of Standards and Technology (NIST), FIPS.186-4, | (SITA)", <https://www.sita.aero/>. | |||
DOI: 10.6028/NIST.FIPS.186-4 , 2013. | ||||
[SON2021] Soni, D., Basu, K., Nabeel, M., Aaraj, N., Manzano, M., | [SON2021] Soni, D., Basu, K., Nabeel, M., Aaraj, N., Manzano, M., | |||
and R. Karri, "FALCON", Hardware Architectures for Post- | and R. Karri, "FALCON", Hardware Architectures for Post- | |||
Quantum Digital Signature Schemes, pp. 31-41 , November | Quantum Digital Signature Schemes, pp. 31-41, | |||
2021. | DOI 10.1007/978-3-030-57682-0_3, 2021, | |||
<https://doi.org/10.1007/978-3-030-57682-0_3>. | ||||
[AVA2021] Avanzi, R., Bos, J., Ducas, L., Kiltz, E., Lepoint, T., | ||||
Lyubashevsky, C., Schanck, J.M., Schwabe, P., Seiler, G., | ||||
and D. Stehle, "CRYSTALS-KYBER - Algorithm Specification | ||||
and Supporting Documentation (version 3.02)", August 2021, | ||||
<https://pq-crystals.org/kyber/data/kyber-specification- | ||||
round3-20210804.pdf>. | ||||
[ROY2020] Roy, S.S.. and A. Basso, "High-Speed Instruction-Set | ||||
Coprocessor For Lattice-Based Key Encapsulation Mechanism: | ||||
Saber In Hardware", IACR Transactions on Cryptographic | ||||
Hardware and Embedded Systems, 443-466. , August 2020. | ||||
[RAW-TECHNOS] | ||||
Thubert, P., Cavalcanti, D., Vilajosana, X., Schmitt, C., | ||||
and J. Farkas, "Reliable and Available Wireless | ||||
Technologies", Work in Progress, Internet-Draft, draft- | ||||
ietf-raw-technologies-06, 30 November 2022, | ||||
<https://www.ietf.org/archive/id/draft-ietf-raw- | ||||
technologies-06.txt>. | ||||
[RAW-USE-CASES] | ||||
Bernardos, C. J., Papadopoulos, G. Z., Thubert, P., and F. | ||||
Theoleyre, "RAW Use-Cases", Work in Progress, Internet- | ||||
Draft, draft-ietf-raw-use-cases-08, 22 October 2022, | ||||
<https://www.ietf.org/archive/id/draft-ietf-raw-use-cases- | ||||
08.txt>. | ||||
[I-D.haindl-lisp-gb-atn] | ||||
Haindl, B., Lindner, M., Moreno, V., Portoles-Comeras, M., | ||||
Maino, F., and B. Venkatachalapathy, "Ground-Based LISP | ||||
for the Aeronautical Telecommunications Network", Work in | ||||
Progress, Internet-Draft, draft-haindl-lisp-gb-atn-08, 23 | ||||
September 2022, <https://www.ietf.org/archive/id/draft- | ||||
haindl-lisp-gb-atn-08.txt>. | ||||
[I-D.ietf-rtgwg-atn-bgp] | ||||
Templin, F., Saccone, G., Dawra, G., Lindem, A., and V. | ||||
Moreno, "A Simple BGP-based Mobile Routing System for the | ||||
Aeronautical Telecommunications Network", Work in | ||||
Progress, Internet-Draft, draft-ietf-rtgwg-atn-bgp-19, 6 | ||||
November 2022, <https://www.ietf.org/archive/id/draft- | ||||
ietf-rtgwg-atn-bgp-19.txt>. | ||||
[I-D.ietf-lisp-rfc6830bis] | ||||
Farinacci, D., Fuller, V., Meyer, D., Lewis, D., and A. | ||||
Cabellos-Aparicio, "The Locator/ID Separation Protocol | ||||
(LISP)", Work in Progress, Internet-Draft, draft-ietf- | ||||
lisp-rfc6830bis-38, 7 May 2022, | ||||
<https://www.ietf.org/archive/id/draft-ietf-lisp- | ||||
rfc6830bis-38.txt>. | ||||
[I-D.ietf-lisp-rfc6833bis] | ||||
Farinacci, D., Maino, F., Fuller, V., and A. Cabellos- | ||||
Aparicio, "Locator/ID Separation Protocol (LISP) Control | ||||
Plane", Work in Progress, Internet-Draft, draft-ietf-lisp- | ||||
rfc6833bis-31, 2 May 2022, | ||||
<https://www.ietf.org/archive/id/draft-ietf-lisp- | ||||
rfc6833bis-31.txt>. | ||||
[ICAO2018] International Civil Aviation Organization (ICAO), | ||||
"Handbook on Radio Frequency Spectrum Requirements for | ||||
Civil Aviation, Doc 9718, Volume 1, ICAO Spectrum | ||||
Strategy, Policy Statements and Related Information", July | ||||
2018, <https://www.icao.int/safety/FSMP/Documents/Doc9718/ | ||||
Doc9718_Vol_I_2nd_ed_(2018)corr1.pdf>. | ||||
[ARI2019] ARINC, "AOC Air-Ground Data And Message Exchange Format, | [STR2016] Strohmeier, M., Schäfer, M., Pinheiro, R., Lenders, V., | |||
ARINC 633", January 2019, | and I. Martinovic, "On Perception and Reality in Wireless | |||
<https://standards.globalspec.com/std/13152055/ | Air Traffic Communication Security", IEEE Transactions on | |||
ARINC%20633>. | Intelligent Transportation Systems, Vol. 18, Issue 6, pp. | |||
1338-1357, DOI 10.1109/TITS.2016.2612584, October 2016, | ||||
<https://doi.org/10.1109/TITS.2016.2612584>. | ||||
[VIR2021] Virdia, A., Stea, G., and G. Dini, "SAPIENT: Enabling | [VIR2021] Virdia, A., Stea, G., and G. Dini, "SAPIENT: Enabling | |||
Real-Time Monitoring and Control in the Future | Real-Time Monitoring and Control in the Future | |||
Communication Infrastructure of Air Traffic Management", | Communication Infrastructure of Air Traffic Management", | |||
IEEE Transactions on Intelligent Transportation Systems, | IEEE Transactions on Intelligent Transportation Systems, | |||
22(8):4864-4875 , August 2021. | Vol. 22, Issue 8, pp. 4864-4875, | |||
DOI 10.1109/TITS.2020.2983614, August 2021, | ||||
[SHU2013] Shutin, D., Schneckenburger, N., Walter, M., and M. | <https://doi.org/10.1109/TITS.2020.2983614>. | |||
Schnell, "LDACS1 Ranging Performance - An Analysis Of | ||||
Flight Measurement Results", IEEE 32nd Digital Avionics | ||||
Systems Conference (DASC), pp. 1-10, East Syracuse, NY, | ||||
USA , October 2013. | ||||
[BEL2021] Bellido-Manganell, M.A., Gräupl, T., Heirich, O., Mäurer, | ||||
N., Filip-Dhaubhadel, A., Mielke, D.M., Schalk, L.M., | ||||
Becker, D., Schneckenburger, N., and M. Schnell, "LDACS | ||||
Flight Trials: Demonstration and Performance Analysis of | ||||
the Future Aeronautical Communications System", IEEE | ||||
Transactions on Aerospace and Electronic Systems, pp. | ||||
1-19 , September 2021. | ||||
[MAE2021] Mäurer, N., Gräupl, T., Gentsch, C., Guggemos, T., | ||||
Tiepelt, M., Schmitt, C., and G. Dreo Rodosek, "A Secure | ||||
Cell-Attachment Procedure for LDACS", 1st Workshop on | ||||
Secure and Reliable Communication and Navigation in the | ||||
Aerospace Domain (SRCNAS), pp. 1-10, Vienna, Austria , | ||||
September 2021. | ||||
[MAE20211] Mäurer, N., Gräupl, T., Bellido-Manganell, M.A., Mielke, | ||||
D.M., Filip-Dhaubhadel, A., Heirich, O., Gerberth, D., | ||||
Flux, M., Schalk, L.M., Becker, D., Schneckenburger, N., | ||||
and M. Schnell, "Flight Trial Demonstration of Secure GBAS | ||||
via the L-band Digital Aeronautical Communications System | ||||
(LDACS)", IEEE Aerospace and Electronic Systems Magazine, | ||||
36(4), pp. 8-17 , April 2021. | ||||
[BOE2019] Boegl, T., Rautenberg, M., Haindl, R., Rihacek, C., Meser, | ||||
J., Fantappie, P., Pringvanich, N., Micallef, J., | ||||
Klauspeter, H., MacBride, J., Sacre, P., v.d. Eiden, B., | ||||
Gräupl, T., and M. Schnell, "LDACS White Paper - A Roll- | ||||
out Scenario", International Civil Aviation Organization, | ||||
Communications Panel - Data Communications Infrastructure | ||||
Working Group - Third Meeting, pp. 1-8, Montreal, Canada , | ||||
October 2019. | ||||
Appendix A. Selected Information from DO-350A | Appendix A. Selected Information from DO-350A | |||
This appendix includes the continuity, availability, and integrity | This appendix includes the continuity, availability, and integrity | |||
requirements applicable for LDACS defined in [DO350A]. | requirements applicable for LDACS defined in [DO350A]. | |||
The following terms are used here: | The following terms are used here: | |||
CPDLC Controller Pilot Data Link Communication | CPDLC: Controller-Pilot Data Link Communications | |||
DT Delivery Time (nominal) value for RSP | DT: Delivery Time (nominal) value for RSP | |||
ET Expiration Time value for RCP | ET: Expiration Time value for RCP | |||
FH Flight Hour | FH: Flight Hour | |||
MA Monitoring and Alerting criteria | MA: Monitoring and Alerting criteria | |||
OT Overdue Delivery Time value for RSP | OT: Overdue Delivery Time value for RSP | |||
RCP Required Communication Performance | RCP: Required Communication Performance | |||
RSP Required Surveillance Performance | RSP: Required Surveillance Performance | |||
TT Transaction Time (nominal) value for RCP | TT: Transaction Time (nominal) value for RCP | |||
+========================+=============+=============+ | +========================+=============+=============+ | |||
| | RCP 130 | RCP 130 | | | | RCP 130 | RCP 130 | | |||
+========================+=============+=============+ | +========================+=============+=============+ | |||
| Parameter | ET | TT95% | | | Parameter | ET | TT95% | | |||
+------------------------+-------------+-------------+ | +------------------------+-------------+-------------+ | |||
| Transaction Time (sec) | 130 | 67 | | | Transaction Time (sec) | 130 | 67 | | |||
+------------------------+-------------+-------------+ | +------------------------+-------------+-------------+ | |||
| Continuity | 0.999 | 0.95 | | | Continuity | 0.999 | 0.95 | | |||
+------------------------+-------------+-------------+ | +------------------------+-------------+-------------+ | |||
skipping to change at page 40, line 24 ¶ | skipping to change at line 1804 ¶ | |||
| Availability | 0.989 | 0.989 | 0.989 | 0.989 | | | Availability | 0.989 | 0.989 | 0.989 | 0.989 | | |||
+------------------------+---------+---------+---------+---------+ | +------------------------+---------+---------+---------+---------+ | |||
| Integrity | 1E-5 | 1E-5 | 1E-5 | 1E-5 | | | Integrity | 1E-5 | 1E-5 | 1E-5 | 1E-5 | | |||
| | per FH | per FH | per FH | per FH | | | | per FH | per FH | per FH | per FH | | |||
+------------------------+---------+---------+---------+---------+ | +------------------------+---------+---------+---------+---------+ | |||
Table 2: CPDLC Requirements for RCP 240/400 | Table 2: CPDLC Requirements for RCP 240/400 | |||
RCP Monitoring and Alerting Criteria in case of CPDLC: | RCP Monitoring and Alerting Criteria in case of CPDLC: | |||
- MA-1: The system shall be capable of detecting failures and | MA-1: The system shall be capable of detecting failures and | |||
configuration changes that would cause the communication service | configuration changes that would cause the communication service | |||
no longer meet the RCP specification for the intended use. | to no longer meet the RCP specification for the intended use. | |||
- MA-2: When the communication service can no longer meet the RCP | MA-2: When the communication service can no longer meet the RCP | |||
specification for the intended function, the flight crew and/or | specification for the intended function, the flight crew and/or | |||
the controller shall take appropriate action. | the controller shall take appropriate action. | |||
+==============+========+========+========+========+========+=======+ | +==============+========+========+========+========+========+=======+ | |||
| | RSP | RSP | RSP | RSP | RSP | RSP | | | | RSP | RSP | RSP | RSP | RSP | RSP | | |||
| | 160 | 160 | 180 | 180 | 400 | 400 | | | | 160 | 160 | 180 | 180 | 400 | 400 | | |||
+==============+========+========+========+========+========+=======+ | +==============+========+========+========+========+========+=======+ | |||
| Parameter | OT | DT95% | OT | DT95% | OT | DT95% | | | Parameter | OT | DT95% | OT | DT95% | OT | DT95% | | |||
+--------------+--------+--------+--------+--------+--------+-------+ | +--------------+--------+--------+--------+--------+--------+-------+ | |||
| Transaction | 160 | 90 | 180 | 90 | 400 | 300 | | | Transaction | 160 | 90 | 180 | 90 | 400 | 300 | | |||
skipping to change at page 41, line 5 ¶ | skipping to change at line 1833 ¶ | |||
+--------------+--------+--------+--------+--------+--------+-------+ | +--------------+--------+--------+--------+--------+--------+-------+ | |||
| Integrity | 1E-5 | 1E-5 | 1E-5 | 1E-5 | 1E-5 | 1E-5 | | | Integrity | 1E-5 | 1E-5 | 1E-5 | 1E-5 | 1E-5 | 1E-5 | | |||
| | per FH | per FH | per FH | per FH | per | per | | | | per FH | per FH | per FH | per FH | per | per | | |||
| | | | | | FH | FH | | | | | | | | FH | FH | | |||
+--------------+--------+--------+--------+--------+--------+-------+ | +--------------+--------+--------+--------+--------+--------+-------+ | |||
Table 3: ADS-C Requirements | Table 3: ADS-C Requirements | |||
RCP Monitoring and Alerting Criteria: | RCP Monitoring and Alerting Criteria: | |||
- MA-1: The system shall be capable of detecting failures and | MA-1: The system shall be capable of detecting failures and | |||
configuration changes that would cause the ADS-C service no longer | configuration changes that would cause the ADS-C service to no | |||
meet the RSP specification for the intended function. | longer meet the RSP specification for the intended function. | |||
- MA-2: When the ADS-C service can no longer meet the RSP | MA-2: When the ADS-C service can no longer meet the RSP | |||
specification for the intended function, the flight crew and/or | specification for the intended function, the flight crew and/or | |||
the controller shall take appropriate action. | the controller shall take appropriate action. | |||
Acknowledgements | ||||
Thanks to all contributors to the development of LDACS and ICAO | ||||
Project Team Terrestrial (PT-T), as well as to all in the RAW Working | ||||
Group for deep discussions and feedback. | ||||
Thanks to Klaus-Peter Hauf, Bart Van Den Einden, and Pierluigi | ||||
Fantappie for their comments on this document. | ||||
Thanks to the Chair of Network Security for input and to the Research | ||||
Institute CODE for their comments and improvements. | ||||
Thanks to the colleagues of the Research Institute CODE at the | ||||
UniBwM, who are working on the AMIUS project funded under the | ||||
Bavarian Aerospace Program by the Bavarian State Ministry of | ||||
Economics, Regional Development and Energy with the GA ROB- | ||||
2-3410.20-04-11-15/HAMI-2109-0015, for fruitful discussions on | ||||
aeronautical communications and relevant security incentives for the | ||||
target market. | ||||
Thanks to SBA Research Vienna for continuous discussions on security | ||||
infrastructure issues in quickly developing markets such as the air | ||||
space and potential economic spillovers to used technologies and | ||||
protocols. | ||||
Thanks to the Aeronautical Communications group at the Institute of | ||||
Communications and Navigation of the German Aerospace Center (DLR). | ||||
With that, the authors would like to explicitly thank Miguel Angel | ||||
Bellido-Manganell and Lukas Marcel Schalk for their thorough | ||||
feedback. | ||||
Authors' Addresses | Authors' Addresses | |||
Nils Mäurer (editor) | Nils Mäurer (editor) | |||
German Aerospace Center (DLR) | German Aerospace Center (DLR) | |||
Münchner Strasse 20 | Münchner Strasse 20 | |||
82234 Wessling | 82234 Wessling | |||
Germany | Germany | |||
Email: Nils.Maeurer@dlr.de | Email: Nils.Maeurer@dlr.de | |||
Thomas Gräupl (editor) | Thomas Gräupl (editor) | |||
End of changes. 216 change blocks. | ||||
1041 lines changed or deleted | 1064 lines changed or added | |||
This html diff was produced by rfcdiff 1.48. |