| 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. | ||||