< draft-ietf-raw-ldacs-08.txt		draft-ietf-raw-ldacs-09.txt >
	RAW N. Maeurer, Ed.		RAW N. Maeurer, Ed.
	Internet-Draft T. Graeupl, Ed.		Internet-Draft T. Graeupl, Ed.
	Intended status: Informational German Aerospace Center (DLR)		Intended status: Informational German Aerospace Center (DLR)
	Expires: 11 November 2021 C. Schmitt, Ed.		Expires: 25 April 2022 C. Schmitt, Ed.
	Research Institute CODE, UniBwM		Research Institute CODE, UniBwM
	10 May 2021		22 October 2021
	L-band Digital Aeronautical Communications System (LDACS)		L-band Digital Aeronautical Communications System (LDACS)
	draft-ietf-raw-ldacs-08		draft-ietf-raw-ldacs-09
	Abstract		Abstract
	This document provides an overview of the architecture of the L-band		This document gives an overview of the architecture of the L-band
	Digital Aeronautical Communications System (LDACS), which provides a		Digital Aeronautical Communications System (LDACS), which provides a
	secure, scalable and spectrum efficient terrestrial data link for		secure, scalable and spectrum efficient terrestrial data link for
	civil aviation. LDACS is a scheduled, reliable multi-application		civil aviation. LDACS is a scheduled, reliable multi-application
	cellular broadband system with support for IPv6. LDACS shall provide		cellular broadband system with support for IPv6. LDACS provides a
	a data link for IP network-based aircraft guidance. High reliability		data link for IPv6 network-based aircraft guidance. High reliability
	and availability for IP connectivity over LDACS are therefore		and availability for IP connectivity over LDACS, as well as security,
	essential.		are therefore essential.
	Status of This Memo		Status of This Memo
	This Internet-Draft is submitted in full conformance with the		This Internet-Draft is submitted in full conformance with the
	provisions of BCP 78 and BCP 79.		provisions of BCP 78 and BCP 79.
	Internet-Drafts are working documents of the Internet Engineering		Internet-Drafts are working documents of the Internet Engineering
	Task Force (IETF). Note that other groups may also distribute		Task Force (IETF). Note that other groups may also distribute
	working documents as Internet-Drafts. The list of current Internet-		working documents as Internet-Drafts. The list of current Internet-
	Drafts is at https://datatracker.ietf.org/drafts/current/.		Drafts is at https://datatracker.ietf.org/drafts/current/.
	Internet-Drafts are draft documents valid for a maximum of six months		Internet-Drafts are draft documents valid for a maximum of six months
	and may be updated, replaced, or obsoleted by other documents at any		and may be updated, replaced, or obsoleted by other documents at any
	time. It is inappropriate to use Internet-Drafts as reference		time. It is inappropriate to use Internet-Drafts as reference
	material or to cite them other than as "work in progress."		material or to cite them other than as "work in progress."
	This Internet-Draft will expire on 11 November 2021.		This Internet-Draft will expire on 25 April 2022.
	Copyright Notice		Copyright Notice
	Copyright (c) 2021 IETF Trust and the persons identified as the		Copyright (c) 2021 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 (https://trustee.ietf.org/
	license-info) in effect on the date of publication of this document.		license-info) in effect on the date of publication of this document.
	Please review these documents carefully, as they describe your rights		Please review these documents carefully, as they describe your rights
	and restrictions with respect to this document. Code Components		and restrictions with respect to this document. Code Components
	extracted from this document must include Simplified BSD License text		extracted from this document must include Simplified BSD License text
	as described in Section 4.e of the Trust Legal Provisions and are		as described in Section 4.e of the Trust Legal Provisions and are
	provided without warranty as described in the Simplified BSD License.		provided without warranty as described in the Simplified BSD License.
	Table of Contents		Table of Contents
	1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3		1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
	2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4		2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5
	3. Motivation and Use Cases . . . . . . . . . . . . . . . . . . 5		3. Motivation and Use Cases . . . . . . . . . . . . . . . . . . 6
	3.1. Voice Communications Today . . . . . . . . . . . . . . . 6		3.1. Voice Communications Today . . . . . . . . . . . . . . . 7
	3.2. Data Communications Today . . . . . . . . . . . . . . . . 6		3.2. Data Communications Today . . . . . . . . . . . . . . . . 7
	4. Provenance and Documents . . . . . . . . . . . . . . . . . . 7		4. Provenance and Documents . . . . . . . . . . . . . . . . . . 8
	5. Applicability . . . . . . . . . . . . . . . . . . . . . . . . 8		5. Applicability . . . . . . . . . . . . . . . . . . . . . . . . 9
	5.1. Advances Beyond the State-of-the-Art . . . . . . . . . . 8		5.1. Advances Beyond the State-of-the-Art . . . . . . . . . . 9
	5.1.1. Priorities . . . . . . . . . . . . . . . . . . . . . 8		5.1.1. Priorities . . . . . . . . . . . . . . . . . . . . . 9
	5.1.2. Security . . . . . . . . . . . . . . . . . . . . . . 9		5.1.2. Security . . . . . . . . . . . . . . . . . . . . . . 9
	5.1.3. High Data Rates . . . . . . . . . . . . . . . . . . . 9		5.1.3. High Data Rates . . . . . . . . . . . . . . . . . . . 10
	5.2. Application . . . . . . . . . . . . . . . . . . . . . . . 9		5.2. Application . . . . . . . . . . . . . . . . . . . . . . . 10
	5.2.1. Air-to-Ground Multilink . . . . . . . . . . . . . . . 9		5.2.1. Air/Ground Multilink . . . . . . . . . . . . . . . . 10
	5.2.2. Air-to-Air Extension for LDACS . . . . . . . . . . . 10		5.2.2. Air/Air Extension for LDACS . . . . . . . . . . . . . 10
	5.2.3. Flight Guidance . . . . . . . . . . . . . . . . . . . 10		5.2.3. Flight Guidance . . . . . . . . . . . . . . . . . . . 11
	5.2.4. Business Communication of Airlines . . . . . . . . . 11		5.2.4. Business Communications of Airlines . . . . . . . . . 12
	5.2.5. LDACS Navigation . . . . . . . . . . . . . . . . . . 11		5.2.5. LDACS-based Navigation . . . . . . . . . . . . . . . 12
	6. Requirements to LDACS . . . . . . . . . . . . . . . . . . . . 12		6. Requirements . . . . . . . . . . . . . . . . . . . . . . . . 12
	7. Characteristics of LDACS . . . . . . . . . . . . . . . . . . 13		7. Characteristics . . . . . . . . . . . . . . . . . . . . . . . 14
	7.1. LDACS Sub-Network . . . . . . . . . . . . . . . . . . . . 13		7.1. LDACS Sub-Network . . . . . . . . . . . . . . . . . . . . 14
	7.2. Topology . . . . . . . . . . . . . . . . . . . . . . . . 14		7.2. Topology . . . . . . . . . . . . . . . . . . . . . . . . 15
	7.3. LDACS Physical Layer . . . . . . . . . . . . . . . . . . 14		7.3. LDACS Protocol Stack . . . . . . . . . . . . . . . . . . 15
	7.4. LDACS Data Link Layer . . . . . . . . . . . . . . . . . . 15		7.3.1. LDACS Physical Layer . . . . . . . . . . . . . . . . 17
	7.5. LDACS Mobility . . . . . . . . . . . . . . . . . . . . . 15		7.3.2. LDACS Data Link Layer . . . . . . . . . . . . . . . . 17
	8. Reliability and Availability . . . . . . . . . . . . . . . . 15		7.3.3. LDACS Sub-Network Layer and Protocol Services . . . . 19
	8.1. Layer 2 . . . . . . . . . . . . . . . . . . . . . . . . . 15		7.4. LDACS Mobility . . . . . . . . . . . . . . . . . . . . . 19
	8.2. Beyond Layer 2 . . . . . . . . . . . . . . . . . . . . . 18		8. Reliability and Availability . . . . . . . . . . . . . . . . 19
	9. Protocol Stack . . . . . . . . . . . . . . . . . . . . . . . 18		8.1. Below Layer 1 . . . . . . . . . . . . . . . . . . . . . . 19
	9.1. Medium Access Control (MAC) Entity Services . . . . . . . 19		8.2. Layer 1 and 2 . . . . . . . . . . . . . . . . . . . . . . 19
	9.2. Data Link Service (DLS) Entity Services . . . . . . . . . 21		8.3. Beyond Layer 2 . . . . . . . . . . . . . . . . . . . . . 23
	9.3. Voice Interface (VI) Services . . . . . . . . . . . . . . 22		9. Security . . . . . . . . . . . . . . . . . . . . . . . . . . 23
	9.4. LDACS Management Entity (LME) Services . . . . . . . . . 22		9.1. Security in Wireless Digital Aeronautical
	9.5. Sub-Network Protocol (SNP) Services . . . . . . . . . . . 22		Communications . . . . . . . . . . . . . . . . . . . . . 24
	10. Security Considerations . . . . . . . . . . . . . . . . . . . 22		9.2. LDACS Requirements . . . . . . . . . . . . . . . . . . . 25
	10.1. Reasons for Wireless Digital Aeronautical		9.3. LDACS Security Objectives . . . . . . . . . . . . . . . . 25
	Communications . . . . . . . . . . . . . . . . . . . . . 23		9.4. LDACS Security Functions . . . . . . . . . . . . . . . . 26
	10.2. LADACS Requirements . . . . . . . . . . . . . . . . . . 24		9.5. LDACS Security Architecture . . . . . . . . . . . . . . . 26
	10.3. LDACS Security Objectives . . . . . . . . . . . . . . . 24		9.5.1. Entities . . . . . . . . . . . . . . . . . . . . . . 26
	10.4. LDACS Security Functions . . . . . . . . . . . . . . . . 25		9.5.2. Entity Identification . . . . . . . . . . . . . . . . 27
	10.5. LDACS Security Architecture . . . . . . . . . . . . . . 25		9.5.3. Entity Authentication and Key Establishment . . . . . 27
	10.5.1. Entities . . . . . . . . . . . . . . . . . . . . . . 25		9.5.4. Message-in-transit Confidentiality, Integrity and
	10.5.2. Entity Identification . . . . . . . . . . . . . . . 25		Authenticity . . . . . . . . . . . . . . . . . . . . 28
	10.5.3. Entity Authentication and Key Negotiation . . . . . 26		10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 28
	10.5.4. Message-in-transit Confidentiality, Integrity and		11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 28
	Authenticity . . . . . . . . . . . . . . . . . . . . 26		12. Normative References . . . . . . . . . . . . . . . . . . . . 28
	10.6. LDACS Security Modules . . . . . . . . . . . . . . . . . 27		13. Informative References . . . . . . . . . . . . . . . . . . . 29
	10.6.1. Placements of Security Functionality in Protocol
	Stack . . . . . . . . . . . . . . . . . . . . . . . . 27
	10.6.2. Trust . . . . . . . . . . . . . . . . . . . . . . . 27
	10.6.3. Mutual Authentication and Key Exchange (MAKE) . . . 28
	10.6.4. Key Derivation and Key Hierarchy . . . . . . . . . . 28
	10.6.5. User Data Security . . . . . . . . . . . . . . . . . 28
	10.6.6. Control Data Security . . . . . . . . . . . . . . . 29
	11. Privacy Considerations . . . . . . . . . . . . . . . . . . . 29
	12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 29
	13. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 29
	14. Normative References . . . . . . . . . . . . . . . . . . . . 30
	15. Informative References . . . . . . . . . . . . . . . . . . . 31
	Appendix A. Selected Information from DO-350A . . . . . . . . . 35		Appendix A. Selected Information from DO-350A . . . . . . . . . 35
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 37		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 37
	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 communication infrastructure that		system is the existence of a communications infrastructure that
	enables efficient aircraft control and safe separation in all phases		enables efficient aircraft control and safe aircraft separation in
	of flight. Current systems are technically mature but suffering from		all phases of flight. Current systems are technically mature but
	the Very High Frequency (VHF) band's increasing saturation in high-		suffering from the Very High Frequency (VHF) band's increasing
	density areas and the limitations posed by analogue radio		saturation in high- density areas and the limitations posed by
	communications. Therefore, aviation globally and the European Union		analogue radio communications. Therefore, aviation globally, and the
	(EU) in particular, strives for a sustainable modernization of the		European Union (EU) in particular, strives for a sustainable
	aeronautical communication infrastructure.		modernization of the aeronautical communications infrastructure.
	In the long-term, ATM communication shall transition from analogue		This modernization is realized in two steps: (1) the transition of
	VHF voice [KAMA2010] and VHF Data Linke mode 2 (VDLM2) communication		communications datalinks from analogue to digital technologies and,
	to more spectrum efficient digital data communication. The European		(2) the introduction of IPv6 based networking protocols in
	ATM Master Plan foresees this transition to be realized for		aeronautical networks [RFC4291], [RFC7136], [ICAO2015].
	terrestrial communications by the development (and potential
	implementation) of the L-band Digital Aeronautical Communications
	System (LDACS). LDACS shall enable IPv6 based air- ground
	communication related to the aviation safety and regularity of flight
	[ICAO20152]. The particular challenge is that no additional spectrum
	can be made available for terrestrial aeronautical communication. It
	was thus necessary to develop co-existence mechanism/procedures to
	enable the interference free operation of LDACS in parallel with
	other aeronautical services/systems in the same frequency band.
	Since LDACS shall be used for aircraft guidance, high reliability and		Step (1) is realized via ATM communications transitioning from
	availability for IP connectivity over LDACS are essential.		analogue VHF voice [KAMA2010] to more spectrum efficient digital data
			communication. For terrestrial communications the European ATM
			Master Plan foresees this transition to be realized by the
			development of the L-band Digital Aeronautical Communications System
			(LDACS). Since central Europe has been identified as the area of the
			world, that suffers the most from increased saturation of the VHF
			band, the initial roll-out of LDACS will likely start there, and
			continue to other increasingly saturated zones as the east- and west-
			cost of the US and parts of Asia [ICAO2018].
			Technically LDACS enables IPv6 based air- ground communication
			related to aviation safety and regularity of flight [ICAO2015].
			Passenger communication and similar services are not supported, since
			only communications related to "safety and regularity of flight" are
			permitted in protected aviation frequency bands. The particular
			challenge is that no additional frequencies can be made available for
			terrestrial aeronautical communication. It was thus necessary to
			develop co-existence mechanism/procedures to enable the interference
			free operation of LDACS in parallel with other aeronautical services/
			systems in the protected frequency band. Since LDACS will be used
			for aircraft guidance, high reliability and availability for IP
			connectivity over LDACS are essential.
			Step (2) is a strategy for the worldwide roll-out of IPv6 capable
			digital aeronautical inter-networking. This is called the
			Aeronautical Telecommunications Network (ATN)/Internet Protocol Suite
			(IPS) (hence, ATN/IPS). It is specified in the International Civil
			Aviation Organization (ICAO) document Doc 9896 [ICAO2015], the Radio
			Technical Commission for Aeronautics (RTCA) document DO-379
			[RTCA2019], the European Organization for Civil Aviation Equipment
			(EUROCAE) document ED-262 [EURO2019], and the Aeronautical Radio
			Incorporated (ARINC) document P858 [ARI2021]. LDACS is subject to
			these regulations since it provides access subnets to the ATN/IPS.
			ICAO has chosen IPv6 as basis for the ATN/IPS mostly for historical
			reasons, since a previous architecture based on ISO/OSI protocols,
			the ATN/OSI, failed in the market place.
			In the context of safety-related communications, LDACS will play a
			major role in future ATM. ATN/IPS datalinks will provide diversified
			terrestrial and space-based connectivity in a multi-link concept,
			called the Future Communications Infrastructure (FCI) [VIR2021].
			From a technical point of view the FCI will realize airborne multi-
			homed IPv6 networks connected to a global ground network via at least
			two independent communication technologies. This is considered in
			more detail in related IETF work in progress [I-D.haindl-lisp-gb-atn]
			[I-D.ietf-rtgwg-atn-bgp].
			In the context of WG-RAW, developing options, such as intelligent
			switching between datalinks, for reliably delivering content from and
			to endpoints, is foreseen. As LDACS is part of such a concept, the
			work of RAW is immediately applicable. In general, with the
			aeronautical communications system transitioning to ATN/IPS, and data
			being transported via IPv6, closer cooperation and collaboration
			between the aeronautical and IETF community is desirable.
			LDACS standardization within the framework of ICAO started in
			December 2016. The ICAO standardization group has produced an
			initial Standards and Recommended Practices (SARPS) document
			[ICA2018]. It defines the general characteristics of LDACS. The
			ICAO standardization group plans to produce an ICAO technical manual
			- the ICAO equivalent to a technical standard - within the next
			years. Generally, the group is open to input from all sources and
			encourages cooperation between the aeronautical and the IETF
			community.
	2. Terminology		2. Terminology
	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:
	A2A Air-to-Air		A/A Air/Air
	AeroMACS Aeronautical Mobile Airport Communication System		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
			ADS-B Automatic Dependent Surveillance - Broadcast
	ADS-C Automatic Dependent Surveillance - Contract		ADS-C Automatic Dependent Surveillance - Contract
	AM(R)S Aeronautical Mobile (Route) Service		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
			AR Access Router
			ARINC Aeronautical Radio, Incorporated
			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 Telecommunication Network
	ATS Air Traffic Service		ATS Air Traffic Service
			BCCH Broadcast Channel
	CCCH Common Control Channel		CCCH Common Control Channel
	COTS IP Commercial Off-The-Shelf
	CM Context Management		CM Context Management
	CNS Communication Navigation Surveillance		CNS Communication Navigation Surveillance
	CPDLC Controller Pilot Data Link Communication		COTS Commercial Off-The-Shelf
			CPDLC Controller Pilot Data Link Communications
			CRL Certificate Revocation List
			CSP Communications Service Provider
	DCCH Dedicated Control Channel		DCCH Dedicated Control Channel
	DCH Data Channel		DCH Data Channel
			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
	FCI Future Communication Infrastructure		DTLS Datagram Transport Layer Security
			EUROCAE European Organization for Civil Aviation Equipment
			FAA Federal Aviation Administration
			FCI Future Communications Infrastructure
			FDD Frequency Division Duplex
	FL Forward Link		FL Forward Link
			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
	LLC Logical Link Control		LLC Logical Link Control
	LME LDACS Management Entity		LME LDACS Management Entity
	MAC Medium Access Layer		MAC Medium Access Control
	MF Multi Frame		MF Multi Frame
	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
			RACH Random Access Channel
	RL Reverse Link		RL Reverse Link
			RTCA Radio Technical Commission for Aeronautics
			SARPS Standards and Recommended Practices
			SDR Software Defined Radio
			SESAR Single European Sky ATM Research
	SF Super-Frame		SF Super-Frame
	SN Serving Network
	SNP Sub-Network Protocol		SNP Sub-Network Protocol
	STS Station-to-Station		VDLm2 VHF Data Link mode 2
	TDMA Time-Division Multiplexing-Access
	VDLM1 VHF Data Link mode 1
	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) via voice and data		Aeronautical Operational Control (AOC) services via voice and data
	communications systems through all phases of a flight. AOC is a		communications systems through all phases of flight. ATC refers to
	generic term referring to the business communication of airlines.		communication for flight guidance. AOC is a generic term referring
	Within the airport terminal, connectivity is focused on high		to the business communication of airlines. It refers to the mostly
	bandwidth communications, while during en-route high reliability,		proprietary exchange of data between the aircraft of the airline, its
	robustness, and range is the main focus. Voice communications may		operation centers, and its service partners. ARINC document 633 was
	use the same or different equipment as data communications systems.		developed and first released in 2007 [ARI2019] with the goal to
	In the following the main differences between voice and data		standardize these messages for interoperability, e.g., messages
	communications capabilities are summarized. The assumed use cases		between the airline and fueling or de-icing companies. Within the
	for LDACS completes the list of use cases stated in [RAW-USE-CASES]		airport terminal, connectivity is focused on high bandwidth
	and the list of reliable and available wireless technologies		communications, while during en-route, high reliability, robustness,
	presented in [RAW-TECHNOS].		and range is the main focus. Voice communications may use the same
			or different equipment as data communications systems. In the
			following, the main differences between voice and data communications
			capabilities are summarized. The assumed use cases for LDACS
			complements the list of use cases stated in [RAW-USE-CASES] and the
			list of reliable and available wireless technologies presented in
			[RAW-TECHNOS].
	3.1. Voice Communications Today		3.1. Voice Communications Today
	Voice links are used for Air-to-Ground (A2G) and Air-to-Air (A2A)		Voice links are used for Air/Ground (A/G) and Air/Air (A/A)
	communications. The communication equipment is either ground-based		communications. The communications equipment is either ground-based
	working in the High Frequency (HF) or VHF frequency band or		working in the High Frequency (HF) or VHF frequency band or
	satellite-based. All VHF and HF voice communications are operated		satellite-based. All VHF and HF voice communications are operated
	via open broadcast channels without authentication, encryption or		via open broadcast channels without authentication, encryption or
	other protective measures. The use of well-proven communication		other protective measures. The use of well-proven communications
	procedures via broadcast channels can help to enhance the safety of		procedures via broadcast channels can help to enhance the safety of
	communications. The main voice communications media is still the		communications. The main voice communications media is still the
	analogue VHF Double Side-Band Amplitude Modulation (DSB-AM)		analogue VHF Double Side-Band Amplitude Modulation (DSB-AM)
	communications technique, supplemented by HF Single Side-Band		communications technique, supplemented by HF single side-band
	Amplitude Modulation and satellite communications for remote and		amplitude modulation and satellite communications for remote and
	oceanic areas. DSB-AM has been in use since 1948, works reliably and		oceanic regions. DSB-AM has been in use since 1948, works reliably
	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. This however, results in current operational limitations and
	impediments in deploying new Air Traffic Management (ATM)		impediments in deploying new ATM applications, such as flight-centric
	applications, such as flight-centric operation with Point-to-Point		operation with point-to-point communications between pilots and air
	communications.		traffic control officers. [BOE2019]
	3.2. Data Communications Today		3.2. Data Communications Today
	Like for voice, data communications into the cockpit is currently		Like for voice, data communications into the cockpit, are currently
	provided by ground-based equipment operating either on HF or VHF		provided by ground-based equipment operating either on HF or VHF
	radio bands or by legacy satellite systems. All these communication		radio bands or by legacy satellite systems. All these communication
	systems are using narrowband radio channels with a data throughput		systems are using narrowband radio channels with a data throughput
	capacity in order of kilobits per second. While the aircraft is on		capacity in the order of kilobits per second. While the aircraft is
	ground some additional communications systems are available, like the		on ground, some additional communications systems are available, like
	Aeronautical Mobile Airport Communication System (AeroMACS) or public		the Aeronautical Mobile Airport Communications System (AeroMACS) or
	cellular networks, operating in the Airport (APT) domain and able to		public cellular networks, operating in the Airport (APT) domain and
	deliver broadband communication capability.		able to deliver broadband communications capability. [BOE2019]
	The data communication networks used for the transmission of data		The data communications networks, used for the transmission of data
	relating to the safety and regularity of the flight must be strictly		relating to the safety and regularity of flight, must be strictly
	isolated from those providing entertainment services to passengers.		isolated from those providing entertainment services to passengers.
	This leads to a situation that the flight crews are supported by		This leads to a situation that the flight crews are supported by
	narrowband services during flight while passengers have access to		narrowband services during flight while passengers have access to
	inflight broadband services. The current HF and VHF data links		inflight broadband services. The current HF and VHF data links
	cannot provide broadband services now or in the future, due to the		cannot provide broadband services now or in the future, due to the
	lack of available spectrum. This technical shortcoming is becoming a		lack of available spectrum. This technical shortcoming is becoming a
	limitation to enhanced ATM operations, such as Trajectory-Based		limitation to enhanced ATM operations, such as trajectory-based
	Operations and 4D trajectory negotiations.		operations and 4D trajectory negotiations. [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 are under development which will be able to
	provide inflight broadband services and communications supporting the		provide inflight broadband services and communications supporting the
	safety and regularity of flight. In parallel, the ground-based		safety and regularity of flight. In parallel the ground-based
	broadband data link technology LDACS is being standardized by ICAO		broadband data link technology LDACS is being standardized by ICAO
	and has recently shown its maturity during flight tests [SCH20191].		and has recently shown its maturity during flight tests [MAE20211]
	The LDACS technology is scalable, secure and spectrum efficient and		[BEL2021]. The LDACS technology is scalable, secure and spectrum
	provides significant advantages to the users and service providers.		efficient and provides significant advantages to the users and
	It is expected that both - satellite systems and LDACS - will be		service providers. It is expected that both - satellite systems and
	deployed to support the future aeronautical communication needs as		LDACS - will be deployed to support the future aeronautical
	envisaged by the ICAO Global Air Navigation Plan.		communication needs as envisaged by the ICAO Global Air Navigation
			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 framework, short SESAR, and is		Single European Sky ATM Research (SESAR) framework and is currently
	currently being continued in the follow-up program SESAR2020		being continued in the follow-up program SESAR2020 [RIH2018]. A key
	[RIH2018]. A key objective of the these activities is to develop,		objective of these activities is to develop, implement and validate a
	implement and validate a modern aeronautical data link able to evolve		modern aeronautical data link able to evolve with aviation needs over
	with aviation needs over long-term. To this end, an LDACS		long-term. To this end, an LDACS specification has been produced
	specification has been produced [GRA2019] and is continuously		[GRA2019] and is continuously updated; transmitter demonstrators were
	updated; transmitter demonstrators were developed to test the		developed to test the spectrum compatibility of LDACS with legacy
	spectrum compatibility of LDACS with legacy systems operating in the		systems operating in the L-band [SAJ2014]; and the overall system
	L-band [SAJ2014]; and the overall system performance was analyzed by		performance was analyzed by computer simulations, indicating that
	computer simulations, indicating that LDACS can fulfil the identified		LDACS can fulfil the identified requirements [GRA2011].
	requirements [GRA2011].
	LDACS standardization within the framework of the ICAO started in
	December 2016. The ICAO standardization group has produced an
	initial Standards and Recommended Practices document [ICA2018]. It
	defines the general characteristics of LDACS. The ICAO
	standardization group plans to produce an ICAO technical manual - the
	ICAO equivalent to a technical standard - within the next years.
	Generally, the group is open to input from all sources and develops
	LDACS in the open.
	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 and the data link layer. Only recently have
	higher layers come into the focus of the LDACS development		higher layers have come into the focus of the LDACS development
	activities. There is currently no "IPv6 over LDACS" specification		activities. There is currently no "IPv6 over LDACS" specification
	publicly available; however, SESAR2020 has started the testing of		publicly available; however, SESAR2020 has started the testing of
	IPv6-based LDACS testbeds.		IPv6-based LDACS testbeds.
	The IPv6 architecture for the aeronautical telecommunication network		The IPv6 architecture for the aeronautical telecommunication network
	is called the Future Communications Infrastructure (FCI). FCI shall		is called the FCI. The FCI will support quality of service,
	support quality of service, diversity, and mobility under the		diversity, and mobility under the umbrella of the "multi-link
	umbrella of the "multi-link concept". This work is conducted by ICAO		concept". This work is led by ICAO Communication Panel working group
	Communication Panel working group WG-I.		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] [SCH20191].		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 (ATS)
	including ATS-B3 and AOC communications services from deployed		including ATS-B3, and AOC communications services from deployed
	Ground-Stations (GS). The A2G sub-system physical layer and data		Ground-Stations (GS). The physical layer and data link layer of
	link layer of LDACS are optimized for data link communications, but		LDACS are optimized for controller-pilot data link communications,
	the system also supports digital air-ground voice communications.		but the system also supports digital air-ground voice communications.
	LDACS supports communication 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 de-coupled 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 A2G communications		transparent to the user. Therefore, the LDACS communications concept
	concept enables the aeronautical communication infrastructure to		enables the aeronautical communication infrastructure to support
	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 offers several capabilities that are not provided in		LDACS offers several capabilities, not yet provided in contemporarily
	contemporarily deployed aeronautical communication systems.		deployed aeronautical communications systems.
	5.1.1. Priorities		5.1.1. Priorities
	LDACS is able to manage services priorities, an important feature not		LDACS is able to manage service priorities, an important feature not
	available in some of the current data link deployments. Thus, LDACS		available in some of the current data link deployments. Thus, LDACS
	guarantees bandwidth, low latency, and high continuity of service for		guarantees bandwidth availability, low latency, and high continuity
	safety critical ATS applications while simultaneously accommodating		of service for safety critical ATS applications while simultaneously
	less safety-critical AOC services.		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
	ANSPs (Air Traffic Network Service Providers). This includes		Air traffic Network Service Providers (ANSP). This includes concepts
	concepts for key and trust management, mutual authenticated key		for key and trust management, mutual authentication and key
	exchange protocols, key derivation measures, user and control		establishment protocols, key derivation measures, user and control
	message-in-transit confidentiality and authenticity protection,		message-in-transit protection, secure logging and availability and
	secure logging and availability and robustness measures [MAE20181],		robustness measures [MAE20182] [MAE2021].
	[MAE20191], [MAE20192].
	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 connection Ground-to-Air (G2A), and 294		Forward Link (FL) for the Ground-to-Air (G2A) connection, and 294
	kbit/s to 1390 kbit/s on the reverse link (RF) for the connection		kbit/s to 1390 kbit/s on the Reverse Link (RL) for the Air-to-Ground
	A2G, depending on coding and modulation. This is 50 times the amount		(A2G) connection, depending on coding and modulation. This is up to
	terrestrial digital aeronautical communications systems such as VDLM2		two orders of magnitude greater than current terrestrial digital
	provide [SCH20191].		aeronautical communications systems, such as the VHF Data Link mode 2
			(VDLm2), provide [ICAO2019] [GRA2019].
	5.2. Application		5.2. Application
	LDACS shall be used by several aeronautical applications ranging from		LDACS will be used by several aeronautical applications ranging from
	enhanced communication protocol stacks (multi-homed mobile IPv6		enhanced communications protocol stacks (multi-homed mobile IPv6
	networks in the aircraft and potentially ad-hoc networks between		networks in the aircraft and potentially ad-hoc networks between
	aircraft) to classical communication applications (sending Ground		aircraft) to broadcast communication applications (sending Ground
	Based Augmentation System (GBAS) correction data) and integration		Based Augmentation System (GBAS) correction data) and integration
	with other service domains (using the communication signal for		with other service domains (using the communications signal for
	navigation).		navigation) [MAE20211].
	5.2.1. Air-to-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 constitute		communications systems, will be deployed within the FCI and
	one of the main components of the multilink concept within the FCI.		constitute one of the main components of the multilink concept within
			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 which complement each other.
	Especially, satellite systems are well-suited for large coverage		Especially, satellite systems are well-suited for large coverage
	areas with less dense air traffic, e.g. oceanic regions. LDACS is		areas with less dense air traffic, e.g. oceanic regions. LDACS is
	well-suited for dense air traffic areas, e.g. continental areas or		well-suited for dense air traffic areas, e.g., continental areas or
	hot-spots around airports and terminal airspace. In addition, both		hot-spots around airports and terminal airspace. In addition, both
	technologies offer comparable data link capacity and, thus, are well-		technologies offer comparable data link capacity and, thus, are well-
	suited for redundancy, mutual back-up, or load balancing.		suited for redundancy, mutual back-up, or load balancing.
	Technically the FCI multilink concept shall be realized by multi-		Technically the FCI multilink concept will be realized by multi-
	homed mobile IPv6 networks in the aircraft. The related protocol		homed mobile IPv6 networks in the aircraft. The related protocol
	stack is currently under development by ICAO and the Single European		stack is currently under development by ICAO, within SESAR, and the
	Sky ATM Research framework.		IETF [I-D.haindl-lisp-gb-atn] [I-D.ietf-rtgwg-atn-bgp].
	5.2.2. Air-to-Air Extension for LDACS		5.2.2. Air/Air Extension for LDACS
	A potential extension of the multi-link concept is its extension to		A potential extension of the multi-link concept is its extension to
	ad-hoc networks between aircraft.		the integration of ad-hoc networks between aircraft.
	Direct A2A communication between aircrafts in terms of ad-hoc data		Direct A/A communication between aircraft in terms of ad-hoc data
	networks is currently considered a research topic since there is no		networks are 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 (digital voice, wake vortex warnings, and		cases are discussed (Automatic Dependent Surveillance - Broadcast
	trajectory negotiation) [BEL2019]. It should also be noted that		(ADS-B), digital voice, wake vortex warnings, and trajectory
	currently deployed analog VHF voice radios support direct voice		negotiation) [BEL2019]. It should also be noted, that currently
	communication between aircraft, making a similar use case for digital		deployed analog VHF voice radios support direct voice communication
	voice plausible.		between aircraft, making a similar use case for digital voice
			plausible.
	LDACS direct A2A is currently not part of standardization.		LDACS A/A is currently not part of the standardization process and
			will not be covered within this document.
	5.2.3. Flight Guidance		5.2.3. Flight Guidance
	The FCI (and therefore LDACS) shall be used to host 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 shall manage the		1. Context Management (CM): The CM application manages the automatic
	automatic logical connection to the ATC center currently		logical connection to the ATC center currently responsible to
	responsible to guide the aircraft. Currently this is done by the		guide the aircraft. Currently this is done by the air crew
	air crew manually changing VHF voice frequencies 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 Communication (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 shall take over		responsible ATC center. The CPDLC application takes over most of
	most of the communication currently performed over VHF voice and		the communication currently performed over VHF voice and enables
	enable new services that do not lend themselves to voice		new services that do not lend themselves to voice communication
	communication (e.g., 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 to		trajectory). ADS-C and CPDLC are the primary applications used
	implement in-flight trajectory management.		for implementing in-flight trajectory management.
	CM, CPDLC, and ADS-C are available on legacy datalinks, but not		CM, CPDLC, and ADS-C are available on legacy datalinks, 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 GBAS for secure, automated landings:
	The Global Navigation Satellite System (GNSS) based GBAS is used to		The Global Navigation Satellite System (GNSS) based GBAS is used to
	improve the accuracy of GNSS to allow GNSS based instrument landings.		improve the accuracy of GNSS to allow GNSS based instrument landings.
	This is realized by sending GNSS correction data (e.g., compensating		This is realized by sending GNSS correction data (e.g., compensating
	ionospheric errors in the GNSS signal) to the aircraft's GNSS		ionospheric errors in the GNSS signal) to the aircraft's GNSS
	receiver via a separate data link. Currently the VDB data link is		receiver via a separate data link. Currently the VDB data link is
	used. VDB is a narrow-band single-purpose datalink without advanced		used. VDB is a narrow-band single-purpose datalink without advanced
	security only used to transmit GBAS correction data. This makes VDB		security only used to transmit GBAS correction data. This makes VDB
	a natural candidate for replacement by LDACS.		a natural candidate for replacement by LDACS [MAE20211].
	5.2.4. Business Communication of Airlines		5.2.4. Business Communications of Airlines
	In addition to air traffic services AOC services shall be transmitted		In addition to air traffic services, AOC services are transmitted
	over LDACS. AOC is a generic term referring to the business		over LDACS. AOC is a generic term referring to the business
	communication of airlines. Regulatory this is considered related to		communication of airlines, between the airlines and service partners
	the safety and regularity of flight and may therefore be transmitted		on the ground and their own aircraft in the air. Regulatory-wise,
	over LDACS.		this is considered related to safety and regularity of flight and may
			therefore be transmitted over LDACS. AOC communication is considered
	AOC communication is considered the main business case for LDACS		the main business case for LDACS communications service providers
	communication service providers since modern aircraft generate		since modern aircraft generate significant amounts of data (i.e.,
	significant amounts of data (e.g., engine maintenance data).		engine maintenance data).
	5.2.5. LDACS Navigation		5.2.5. LDACS-based Navigation
	Beyond communication radio signals can always also be used for		Beyond communications, radio signals can always also be used for
	navigation. LDACS takes this into account.		navigation. 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. However, the drawback of GNSS is its inherent single		navigation. Due to the large separation between navigational
	point of failure - the satellite. Due to the large separation		satellites and aircraft, the power of the GNSS signals received by
	between navigational satellites and aircraft, the received power of		the aircraft is, however, very low. As a result, GNSS disruptions
	GNSS signals on the ground is very low. As a result, GNSS		might occasionally occur due to unintentional interference, or
	disruptions might occasionally occur due to unintentional		intentional jamming. Yet the navigation services must be available
	interference, or intentional jamming. Yet the navigation services		with sufficient performance for all phases of flight. Therefore,
	must be available with sufficient performance for all phases of		during GNSS outages, or blockages, an alternative solution is needed.
	flight. Therefore, during GNSS outages, or blockages, an alternative		This is commonly referred to as Alternative Positioning, Navigation,
	solution is needed. This is commonly referred to as Alternative		and Timing (APNT).
	Positioning, Navigation, and Timing (APNT).
	One of such APNT solution consists of integrating the navigation		One of such APNT solutions consists of exploiting the built-in
	functionality into LDACS. The ground infrastructure for APNT is		navigation capabilities of LDACS operation. That is, the normal
	deployed through the implementation of LDACS's GSs and the navigation		operation of LDACS for ATC and AOC communications would also directly
	capability comes "for free".		enable the aircraft to navigate and obtain a reliable timing
			reference from the LDACS GSs.
	LDACS navigation has already been demonstrated in practice in a		LDACS navigation has already been demonstrated in practice in two
	flight measurement campaign [SCH20191].		flight measurement campaigns [SHU2013] [BEL2021] [MAE20211]. .
	6. Requirements to LDACS		6. Requirements
	The requirements to LDACS are mostly defined by its application area:		The requirements for LDACS are mostly defined by its application
	Communication 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 Aeronautical Telecommunication		Aeronautical data links for the ATN are therefore expected to remain
	Network (ATN) are therefore expected to remain in service for		in service for decades. The VDLm2 data link currently used for
	decades. The VDLM2 data link currently used for digital terrestrial		digital terrestrial internetworking was developed in the 1990ies (the
	internetworking was developed in the 1990es (the use of the Open		use of the Open Systems Interconnection (OSI) stack indicates that as
	Systems Interconnection (OSI) stack indicates that as well). VDLM2		well). VDLm2 is expected to be used at least for several decades.
	is expected to be used at least for several decades. In this respect		In this respect aeronautical communications (for applications related
	aeronautical communication (for applications related to safety and		to safety and regularity of flight) is more comparable to industrial
	regularity of flight) is more comparable to industrial applications		applications than to the open Internet.
	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 the Aircraft Communications		Current ATS applications use either 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 LDACS as part of the FCI is to		objective of the development effort of LDACS, as part of the FCI, is
	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 or proprietary.		will likely be heavily modified versions of Ethernet or proprietary.
	AOC applications currently mostly use the same stack (although some		AOC applications currently 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 (VDLM1/2) do not provide sufficient bandwidth.		terrestrial data links do not provide sufficient bandwidth (i.e.,
	The use of non-aviation specific data links is considered a security		with VDLm2 currently in the order of 10 kbit/s). The use of non-
	problem. Ideally the aeronautical IP internetwork and the Internet		aviation specific data links is considered a security problem.
	should be completely separated.		Ideally the aeronautical IP internetwork and the Internet should be
			completely separated.
	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 and provide much higher bandwidth to		data link designed to support IP addressing and provide much higher
	avoid the currently experienced operational problems.		bandwidth to avoid the currently experienced operational problems.
	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 fulfil 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 (the totality of them being the ATN). On the avionics side		networks (i.e., the ATN). On the avionics side, in the aircraft,
	in the aircraft aviation specific solutions are to be expected.		aviation specific solutions are to be expected.
	In addition to the 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 fulfil 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 air traffic
	management application (CPDLC, CM, and ADS-C). The scope most		management application (CPDLC, CM, and ADS-C). The scope most
	relevant to IP over LDACS is the CSP (Communication Service Provider)		relevant to IP over LDACS is the Communications Service Provider
	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		[DO350A] volume 1 Table 5-14, and Table 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 of LDACS		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 and possibly ACARS/FANS		aircraft to the ATN implemented by the FCI.
	networks [FAN2019].
	The current LDACS design is focused on the specification of layer 2.		The current LDACS design is focused on the specification of layer one
			and two. However, for the purpose of this work, only layer two
			details are discussed here.
	Achieving stringent the 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 undefined. Input		layer). Fault management mechanisms are similarly undefined. Input
	from the working group will be appreciated here.		from the working group will be appreciated here.
	7.1. LDACS Sub-Network		7.1. LDACS Sub-Network
	An LDACS sub-network contains an Access Router (AR) and several GS,		An LDACS sub-network contains an Access Router (AR) and several GS,
	each of them providing one LDACS radio cell.		each of them providing one LDACS radio cell.
	User plane interconnection to the ATN is facilitated by the AR		User plane interconnection to the ATN is facilitated by the AR
	peering with an A2G Router connected to the ATN.		peering with an A/G Router connected to the ATN.
	The internal control plane of an LDACS sub-network interconnects the		The internal control plane of an LDACS sub-network interconnects the
	GS. An LDACS sub-network is illustrated in Figure 1.		GSs. An LDACS sub-network is illustrated in Figure 1.
	wireless user		wireless user
	link plane		link plane
	AS-------------GS---------------AR---A2G-----ATN		AS-------------GS---------------AR---A/G-----ATN
	. | Router		. | Router
	. control |		. control |
	. plane |		. plane |
	. |		. |
	GS...............|		GS---------------|
	. |		. |
	. |		. |
	GS---------------+		GS---------------+
	Figure 1: LDACS sub-network with three GSs and one AS		Figure 1: LDACS sub-network with three GSs and one AS
	7.2. Topology		7.2. Topology
	LDACS operating in A2G mode is a cellular point-to-multipoint system.		LDACS is a cellular point-to-multipoint system. It assumes a star-
	The A2G mode assumes a star-topology in each cell where Aircraft		topology in each cell where Aircraft Stations (AS) belonging to
	Stations (AS) belonging to aircraft within a certain volume of space		aircraft within a certain volume of space (the LDACS cell) is
	(the LDACS cell) is connected to the controlling GS. The LDACS GS is		connected to the controlling GS. The LDACS GS is a centralized
	a centralized instance that controls LDACS A2G communications within		instance that controls LDACS A/G communications within its cell. The
	its cell. The LDACS GS can simultaneously support multiple bi-		LDACS GS can simultaneously support multiple bi-directional
	directional communications to the ASs under its control. LDACS's GSs		communications to the ASs under its control. LDACS's GSs themselves
	themselves are connected to each other and the AR.		are connected to each other and the AR.
	Prior to utilizing the system an AS 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.
	The LDACS wireless link protocol stack defines two layers, the		7.3. LDACS Protocol Stack
	physical layer and the data link layer.
	7.3. LDACS Physical Layer		The protocol stack of LDACS is implemented in the AS and GS: It
			consists of the Physical Layer (PHY) with five major, functional
			blocks above it. Four are placed in the Data Link Layer (DLL) of the
			AS and GS: (1) Medium Access Control (MAC) Layer, (2) Voice Interface
			(VI), (3) Data Link Service (DLS), and (4) LDACS Management Entity
			(LME). The last entity resides within the sub-network layer: the
			Sub-Network Protocol (SNP). The LDACS network is externally
			connected to voice units, radio control units, and the ATN network
			layer.
			LDACS is considered an ATN/IPS radio access technology, from the view
			of ICAO's regulatory framework. Hence, the interface between ATN and
			LDACS must be IPv6 based, as regulatory documents, such as ICAO Doc
			9896 [ICAO2015] and DO-379 [RTCA2019] clearly foresee that. The
			translation between IPv6 layer and SNP layer is currently subject of
			ongoing standardization efforts and at the time of writing not
			finished yet.
			Figure 2 shows the protocol stack of LDACS as implemented in the AS
			and GS. Acronyms used here are introduced throughout the upcoming
			sections.
			IPv6 Network Layer
			|
			|
			+------------------+ +----+
			| SNP |--| | Sub-Network
			| | | | Layer
			+------------------+ | |
			| | LME|
			+------------------+ | |
			| DLS | | | LLC Layer
			+------------------+ +----+
			| |
			DCH DCCH/CCCH
			| RACH/BCCH
			| |
			+--------------------------+
			| MAC | Medium Access
			| | Layer
			+--------------------------+
			|
			+--------------------------+
			| PHY | Physical Layer
			+--------------------------+
			|
			|
			((*))
			FL/RL radio channels
			separated by FDD
			Figure 2: LDACS protocol stack in AS and GS
			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 bi-directional links to multiple		channel. The LDACS GS supports bi-directional 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. 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 (OFDM) symbols on the FL. In the RL different aircraft		Multiplexing Access (OFDM) symbols on the FL. In the RL different
	are separated in time and frequency using a combination of Orthogonal		aircraft are separated in time and frequency using Orthogonal
	Frequency-Division Multiple-Access (OFDMA) and Time-Division		Frequency-Division Multiple Access (OFDMA). Aircraft thus transmit
	Multiple-Access (TDMA). Aircraft thus transmit discontinuously on		discontinuously on the RL via short radio bursts sent in precisely
	the RL with radio bursts sent in precisely defined transmission		defined transmission opportunities allocated by the GS.
	opportunities allocated by the GS.
	7.4. 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 protocol.		aircraft and the GS using an Automatic Repeat reQuest (ARQ) protocol.
	LDACS supports also unacknowledged point-to-point channels and G2A		LDACS supports also unacknowledged point-to-point channels and G2A
	broadcast.		Broadcast transmission.
	7.5. LDACS Mobility
	LDACS supports layer 2 handovers to different LDACS channels.
	Handovers may be initiated by the aircraft (break-before-make) or by
	the GS (make-before-break). Make-before-break handovers are only
	supported for GSs connected to each other.
	External handovers between non-connected LDACS sub-networks or
	different aeronautical data links shall be handled by the FCI multi-
	link concept.
	8. Reliability and Availability
	8.1. Layer 2
	LDACS has been designed with applications related to the safety and		7.3.2.1. Medium Access Control (MAC) Services
	regularity of flight in mind. It has therefore been designed as a
	deterministic wireless data link (as far as this is possible).
	Based on channel measurements of the L-band channel [SCHN2016] and		The MAC time framing service provides the frame structure necessary
	respecting the specific nature of the area of application, LDACS was		to realize slot-based time-division multiplex-access on the physical
	designed from the PHY layer up with robustness in mind.		link. It provides the functions for the synchronization of the MAC
			framing structure and the PHY Layer framing. The MAC time framing
			provides a dedicated time slot for each logical channel.
	In order to maximize the capacity per channel and to optimally use		The MAC sub-layer offers access to the physical channel to its
	the available spectrum, LDACS was designed as an OFDM-based Frequency		service users. Channel access is provided through transparent
	Division Duplex system, supporting simultaneous transmissions in FL		logical channels. The MAC sub-layer maps logical channels onto the
	at the G2A connection and RF at the A2G connection. The legacy		appropriate slots and manages the access to these channels. Logical
	systems already deployed in the L-band limit the bandwidth of both		channels are used as interface between the MAC and LLC sub-layers.
	channels to approximately 500 kHz.
	The LDACS physical layer design includes propagation guard times		7.3.2.2. Data Link Service (DLS) Services
	sufficient for the operation at a maximum distance of 200 nautical
	miles from the GS. In actual deployment, LDACS can be configured for
	any range up to this maximum range.
	The LDACS FL physical layer is a continuous OFDM transmission. LDACS		The DLS provides acknowledged and unacknowledged (including broadcast
	RL transmission is based on OFDMA-TDMA bursts, with silence between		and packet mode voice) bi-directional exchange of user data. If user
	such bursts. The RL resources (i.e. bursts) are assigned to		data is transmitted using the acknowledged DLS, the sending DLS
	different ASs on demand by the GS.		entity will wait for an acknowledgement from the receiver. If no
			acknowledgement is received within a specified time frame, the sender
			may automatically try to retransmit its data. However, after a
			certain number of failed retries, the sender will suspend further
			retransmission attempts and inform its client of the failure.
	The LDACS physical layer supports adaptive coding and modulation for		The DLS uses the logical channels provided by the MAC:
	user data. Control data is always encoded with the most robust
	coding and modulation (QPSK coding rate 1/2).
	LDACS medium access on top of the physical layer uses a static frame		1. A GS announces its existence and access parameters in the
	structure to support deterministic timer management. As shown in		Broadcast Channel (BCCH).
	Figure 3 and Figure 4, LDACS framing structure is based on Super-		2. The Random Access Channel (RACH) enables AS to request access to
	Frames (SF) of 240ms duration corresponding to 2000 OFDM symbols. FL		an LDACS cell.
	and RL boundaries are aligned in time (from the GS perspective)		3. In the FL the Common Control Channel (CCCH) is used by the GS to
	allowing for deterministic sending windows for KEEP ALIVE messages		grant access to data channel resources.
	and control and data channels in general.		4. The reverse direction is covered by the RL, where ASs need to
			request resources before sending. This happens via the Dedicated
			Control Channel (DCCH).
			5. User data itself is communicated in the Data Channel (DCH) on the
			FL and RL.
	LDACS medium access is always under the control of the GS of a radio		Access to the FL and RL data channel is granted by the scheduling
	cell. Any medium access for the transmission of user data has to be		mechanism implemented in the LME discussed below.
	requested with a resource request message stating the requested
	amount of resources and class of service. The GS performs resource
	scheduling on the basis of these requests and grants resources with
	resource allocation messages. Resource request and allocation
	messages are exchanged over dedicated contention-free control
	channels.
	The purpose of Quality-of-Service in LDACS medium access is to		7.3.2.3. Voice Interface (VI) Services
	provide prioritized medium access at the bottleneck (the wireless
	link). The signaling of higher layer Quality-of-Service requirements
	to LDACS is yet to be defined. A DiffServ-based solution with a
	small number of priorities is to be expected.
	LDACS has two mechanisms to request resources from the scheduler in		The VI provides support for virtual voice circuits. Voice circuits
	the GS.		may either be set-up permanently by the GS (e.g., to emulate voice
			party line) or may be created on demand. The creation and selection
			of voice circuits is performed.
	Resources can either be requested "on demand" with a given priority.		7.3.2.4. LDACS Management Entity (LME) Services
	On the FL, this is done locally in the GS, on the RL a dedicated
	contention-free control channel is used called Dedicated Control
	Channel (DCCH), which is roughly 83 bit every 60 ms. A resource
	allocation is always announced in the control channel of the FL,
	short Common Control Channel (CCCH) having variable size. Due to the
	spacing of the RL control channels every 60 ms, a medium access delay
	in the same order of magnitude is to be expected.
	Resources can also be requested "permanently". The permanent		The mobility management service in the LME provides support for
	resource request mechanism supports requesting recurring resources in		registration and de-registration (cell entry and cell exit), scanning
	given time intervals. A permanent resource request has to be		RF channels of neighboring cells and handover between cells. In
	canceled by the user (or by the GS, which is always in control).		addition, it manages the addressing of aircraft within cells.
	User data transmissions over LDACS are therefore always scheduled by		The resource management service provides link maintenance (power,
	the GS, while control data uses statically (i.e. at cell entry)		frequency and time adjustments), support for adaptive coding and
	allocated recurring resources (DCCH and CCCH). The current		modulation, and resource allocation.
	specification specifies no scheduling algorithm. Scheduling of RL
	resources is done in physical Protocol Data Units of 112 bit (or
	larger if more aggressive coding and modulation is used). Scheduling
	on the FL is done Byte-wise since the FL is transmitted continuously
	by the GS.
	In addition to having full control over resource scheduling, the GS		The resource management service accepts resource requests from/for
	can send forced Handover commands for off-loading or RF channel		different AS and issues resource allocations accordingly. While the
	management, e.g. when the signal quality declines and a more suitable		scheduling algorithm is not specified and a point of possible vendor
	GS is in the AS reach. With robust resource management of the		differentiation, it is subject to the following requirements:
	capacities of the radio channel, reliability and robustness measures
	are therefore also anchored in the LDACS management entity.
	In addition, to radio resource management, the LDACS control channels		1. Resource scheduling must provide channel access according to the
	are also used to send keep-alive messages, when they are not		priority of the request
	otherwise used. Since the framing of the control channels is		2. Resource scheduling must support "one-time" requests.
	deterministic, missing keep-alive messages can thus be immediately		3. Resource scheduling must support "permanent" requests that
	detected. This information is made available to the multi-link		reserve a resource until the request is canceled e.g. for digital
	protocols for fault management.		voice circuits.
	The protocol used to communicate faults is not defined in the LDACS		7.3.3. LDACS Sub-Network Layer and Protocol Services
	specification. It is assumed that vendors would use industry
	standard protocols like the Simple Network Management Protocol or the
	Network Configuration Protocol where security permits.
	The LDACS data link layer protocol running on top of the medium		Lastly, the SNP handles the transition from IPv6 packts to LDACS
	access sub-layer uses ARQ to provide reliable data transmission on		internal packet structures. This work is ongoing and not part of
	layer 2.		this document. The DLS provides functions required for the transfer
			of user plane data and control plane data over the LDACS sub-network.
			The security service provides functions for secure user data
			communication over the LDACS sub-network. Note that the SNP security
			service applies cryptographic measures as configured by the GS.
	It employs selective repeat ARQ with transparent fragmentation and		7.4. LDACS Mobility
	reassembly to the resource allocation size to achieve low latency and
	a low overhead without losing reliability. It ensures correct order
	of packet delivery without duplicates. In case of transmission
	errors it identifies lost fragments with deterministic timers synced
	to the medium access frame structure and initiates retransmission.
	Additionally, the priority mechanism of LDACS ensures the timely
	delivery of messages with high importance.
	8.2. Beyond Layer 2		LDACS supports layer 2 handovers to different LDACS cells. Handovers
			may be initiated by the aircraft (break-before-make) or by the GS
			(make-before-break). Make-before-break handovers are only supported
			between GSs connected to each other.
	LDACS availability can be increased by appropriately deploying LDACS		External handovers between non-connected LDACS sub-networks or
	infrastructure: This means proliferating the number of terrestrial		different aeronautical data links are handled by the FCI multi- link
	base stations. However, the scarcity of aeronautical spectrum for		concept.
	data link communication (in the case of LDACS: tens of MHz in the
	L-band) and the long range (in the case of LDACS: up to 400 km) make
	this quite hard. The deployment of a larger number of small cells is
	certainly possible, suffers, however, also from the scarcity of
	spectrum. An additional constraint to consider, is that Distance
	Measuring Equipment (DME) is the primary user of the aeronautical
	L-band. That is, any LDACS deployment has to take DME frequency
	planning into account, too.
	The aeronautical community has therefore decided not to rely on a		8. Reliability and Availability
	single communication system or frequency band. It is envisioned to
	have multiple independent data link technologies in the aircraft
	(e.g., terrestrial and satellite communications) in addition to
	legacy VHF voice.
	However, as of now no reliability and availability mechanisms that		8.1. Below Layer 1
	could utilize the multi-link have been specified on Layer 3 and
	above. Even if LDACS has been designed for reliability, the wireless
	medium presents significant challenges to achieve deterministic
	properties such as low packet error rate, bounded consecutive losses,
	and bounded latency. Support for high reliability and availability
	for IP connectivity over LDACS is therefore highly desirable, needs,
	however, be adapted to the specific use case.
	Below Layer 2 aeronautics usually relies on hardware redundancy. To		Below Layer 2, aeronautics usually relies 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.
	9. Protocol Stack		8.2. Layer 1 and 2
	The protocol stack of LDACS is implemented in the AS and GS: It
	consists of the Physical Layer (PHY) with five major functional
	blocks above it. Four are placed in the Data Link Layer (DLL) of the
	AS and GS: (1) Medium Access Layer (MAC), (2) Voice Interface (VI),
	(3) Data Link Service (DLS), and (4) LDACS Management Entity (LME).
	The last entity resides within the Sub-Network Layer: Sub-Network
	Protocol (SNP). The LDACS network is externally connected to voice
	units, radio control units, and the ATN Network Layer.
	Figure 2 shows the protocol stack of LDACS as implemented in the AS
	and GS.
	IPv6 Network Layer
	|
	|
	+------------------+ +----+
	| SNP |--| | Sub-Network
	| | | | Layer
	+------------------+ | |
	| | LME|
	+------------------+ | |
	| DLS | | | Logical Link
	| | | | Control Layer
	+------------------+ +----+
	| |
	DCH DCCH/CCCH
	| RACH/BCCH
	| |
	+--------------------------+
	| MAC | Medium Access
	| | Layer
	+--------------------------+
	|
	+--------------------------+
	| PHY | Physical Layer
	+--------------------------+
	|
	|
	((*))
	FL/RL radio channels
	separated by
	Frequency Division Duplex
	Figure 2: LDACS protocol stack in AS and GS
	9.1. Medium Access Control (MAC) Entity Services
	The MAC time framing service provides the frame structure necessary		LDACS has been designed with applications related to the safety and
	to realize slot-based Time Division Multiplex (TDM) access on the		regularity of flight in mind. It has therefore been designed as a
	physical link. It provides the functions for the synchronization of		deterministic wireless data link (as far as this is possible).
	the MAC framing structure and the PHY Layer framing. The MAC time
	framing provides a dedicated time slot for each logical channel.
	The MAC Sub-Layer offers access to the physical channel to its		Based on channel measurements of the L-band channel LDACS was
	service users. Channel access is provided through transparent		designed from the PHY layer up with robustness in mind. Channel
	logical channels. The MAC Sub-Layer maps logical channels onto the		measurements of the L-band channel [SCH2016] confirmed LDACS to be
	appropriate slots and manages the access to these channels. Logical		well adapted to its channel.
	channels are used as interface between the MAC and LLC Sub-Layers.
	The LDACS framing structure for FL and RL is based on Super-Frames		In order to maximize the capacity per channel and to optimally use
	(SF) of 240 ms duration. Each SF corresponds to 2000 OFDM symbols.		the available spectrum, LDACS was designed as an OFDM-based FDD
	The FL and RL SF boundaries are aligned in time (from the view of the		system, supporting simultaneous transmissions in FL in the G2A
	GS).		connection and RL in the A2G connection. The legacy systems already
			deployed in the L-band limit the bandwidth of both channels to
			approximately 500 kHz.
	In the FL, an SF contains a Broadcast Frame of duration 6.72 ms (56		The LDACS physical layer design includes propagation guard times
	OFDM symbols) for the Broadcast Control Channel (BCCH), and four		sufficient for the operation at a maximum distance of 200 nautical
	Multi-Frames (MF), each of duration 58.32 ms (486 OFDM symbols).		miles from the GS. In actual deployment, LDACS can be configured for
			any range up to this maximum range.
	In the RL, each SF starts with a Random Access (RA) slot of length		The LDACS physical layer supports adaptive coding and modulation for
	6.72 ms with two opportunities for sending RL random access frames		user data. Control data is always encoded with the most robust
	for the Random Access Channel (RACH), followed by four MFs. These		coding and modulation (FL: Quadrature Phase-Shift Keying (QPSK),
	MFs have the same fixed duration of 58.32 ms as in the FL, but a		coding rate 1/2, RL: QPSK, coding rate 1/3).
	different internal structure
	Figure 3 and Figure 4 illustrate the LDACS frame structure.		LDACS medium access layer on top of the physical layer uses a static
			frame structure to support deterministic timer management. As shown
			in Figure 3 and Figure 4, LDACS framing structure is based on Super-
			Frames (SF) of 240ms duration corresponding to 2000 OFDM symbols. FL
			and RL boundaries are aligned in time (from the GS perspective)
			allowing for deterministic slots for control and data channels. This
			initial AS time synchronization and time synchronization maintenance
			is based on observing the synchronization symbol pairs that
			repetitively occur within the FL stream, being sent by the
			controlling GS [GRA2019].
	^		^
	| +------+------------+------------+------------+------------+		| +------+------------+------------+------------+------------+
	| FL | BCCH | MF | MF | MF | MF |		| FL | BCCH | MF | MF | MF | MF |
	F +------+------------+------------+------------+------------+		F +------+------------+------------+------------+------------+
	r <---------------- Super-Frame (SF) - 240ms ---------------->		r <---------------- Super-Frame (SF) - 240ms ---------------->
	e		e
	q +------+------------+------------+------------+------------+		q +------+------------+------------+------------+------------+
	u RL | RACH | MF | MF | MF | MF |		u RL | RACH | MF | MF | MF | MF |
	e +------+------------+------------+------------+------------+		e +------+------------+------------+------------+------------+
	skipping to change at page 21, line 23 ¶		skipping to change at page 21, line 41 ¶
	e +------+---------------------------+		e +------+---------------------------+
	n <---- Multi-Frame (MF) - 58.32ms -->		n <---- Multi-Frame (MF) - 58.32ms -->
	c		c
	y		y
	|		|
	-------------------- Time ------------------>		-------------------- Time ------------------>
	|		|
	Figure 4: MF structure for LDACS		Figure 4: MF structure for LDACS
	9.2. Data Link Service (DLS) Entity Services		LDACS cell entry is conducted with an initial control message
			exchange via the RACH and the BCCH.
	The DLS provides acknowledged and unacknowledged (including broadcast		After cell entry, LDACS medium access is always under the control of
	and packet mode voice) bi-directional exchange of user data. If user		the GS of a radio cell. Any medium access for the transmission of
	data is transmitted using the acknowledged DLS, the sending DLS		user data on a DCH has to be requested with a resource request
	entity will wait for an acknowledgement from the receiver. If no		message stating the requested amount of resources and class of
	acknowledgement is received within a specified time frame, the sender		service. The GS performs resource scheduling on the basis of these
	may automatically try to retransmit its data. However, after a		requests and grants resources with resource allocation messages.
	certain number of failed retries, the sender will suspend further		Resource request and allocation messages are exchanged over dedicated
	retransmission attempts and inform its client of the failure.		contention-free control channels (DCCH and CCCH).
	The DLS uses the logical channels provided by the MAC:		The purpose of quality-of-service in LDACS medium access is to
			provide prioritized medium access at the bottleneck (the wireless
			link). The signaling of higher layer quality-of-service requirements
			to LDACS is yet to be defined. A Differentiated Services- (DiffServ)
			based solution with a small number of priorities is to be expected.
	1. A GS announces its existence and access parameters in the		In addition to having full control over resource scheduling, the GS
	Broadcast Channel (BC).		can send forced handover commands for off-loading or channel
	2. The RA channel enables AS to request access to an LDACS cell.		management, e.g., when the signal quality declines and a more
	3. In the FL the CCCH is used by the GS to grant access to data		suitable GS is in the AS's reach. With robust resource management of
	channel resources.		the capacities of the radio channel, reliability and robustness
	4. The reverse direction is covered by the RL, where ASs need to		measures are therefore also anchored in the LME.
	request resources before sending. This happens via the DCCH.
	5. User data itself is communicated in the Data Channel (DCH) on the
	FL and RL.
	Access to the FL and RL data channel is granted by the scheduling		In addition to radio resource management, the LDACS control channels
	mechanism implemented in the LME discussed below.		are also used to send keep-alive messages, when they are not
			otherwise used. Since the framing of the control channels is
			deterministic, missing keep-alive messages can thus be immediately
			detected. This information is made available to the multi-link
			protocols for fault management.
	9.3. Voice Interface (VI) Services		The protocol used to communicate faults is not defined in the LDACS
			specification. It is assumed that vendors would use industry
			standard protocols like the Simple Network Management Protocol or the
			Network Configuration Protocol, where security permits.
	The VI provides support for virtual voice circuits. Voice circuits		The LDACS data link layer protocol, running on top of the medium
	may either be set-up permanently by the GS (e.g., to emulate voice		access sub-layer, uses ARQ to provide reliable data transmission on
	party line) or may be created on demand. The creation and selection		the data channel.
	of voice circuits is performed in the LME. The VI provides only the
	transmission services.
	9.4. LDACS Management Entity (LME) Services		It employs selective repeat ARQ with transparent fragmentation and
			reassembly to the resource allocation size to achieve low latency and
			a low overhead without losing reliability. It ensures correct order
			of packet delivery without duplicates. In case of transmission
			errors, it identifies lost fragments with deterministic timers synced
			to the medium access frame structure and initiates retransmission.
	The mobility management service in the LME provides support for		8.3. Beyond Layer 2
	registration and de-registration (cell entry and cell exit), scanning
	RF channels of neighboring cells and handover between cells. In
	addition, it manages the addressing of aircraft/ ASs within cells.
	The resource management service provides link maintenance (power,		LDACS availability can be increased by appropriately deploying LDACS
	frequency and time adjustments), support for adaptive coding and		infrastructure: This means proliferating the number of terrestrial
	modulation, and resource allocation.		ground stations. However, the scarcity of aeronautical spectrum for
			data link communication (in the case of LDACS: tens of MHz in the
			L-band) and the long range (in the case of LDACS: up to 200 nautical
			miles) make this quite hard. The deployment of a larger number of
			small cells is certainly possible, suffers, however, also from the
			scarcity of spectrum. An additional constraint to consider, is that
			Distance Measuring Equipment (DME) is the primary user of the
			aeronautical L-band. That is, any LDACS deployment has to take DME
			frequency planning into account.
	The resource management service accepts resource requests from/for		The aeronautical community has therefore decided not to rely on a
	different AS and issues resource allocations accordingly. While the		single communication system or frequency band. It is envisioned to
	scheduling algorithm is not specified and a point of possible vendor		have multiple independent data link technologies in the aircraft
	differentiation, it is subject to the following requirements:		(e.g., terrestrial and satellite communications) in addition to
			legacy VHF voice.
	1. Resource scheduling must provide channel access according to the		However, as of now, no reliability and availability mechanisms that
	priority of the request		could utilize the multi-link architecture, have been specified on
	2. Resource scheduling must support "one-time" requests		Layer 3 and above. Even if LDACS has been designed for reliability,
	3. Resource scheduling must support "permanent" requests that		the wireless medium presents significant challenges to achieve
	reserve a resource until the request is canceled e.g. for digital		deterministic properties such as low packet error rate, bounded
	voice circuits.		consecutive losses, and bounded latency. Support for high
			reliability and availability for IP connectivity over LDACS is
			therefore, highly desirable, needs, however, to be adapted to the
			specific use case.
	9.5. Sub-Network Protocol (SNP) Services		9. Security
	The DLS provides functions required for the transfer of user plane		ICAO Doc 9896 foresees transport layer security [ICAO2015] for all
	data and control plane data over the LDACS sub-network.		aeronautical data as described in ARINC P858 [ARI2021], most likely
			realized via Datagram Transport Layer Security (DTLS) [RFC6012]
			[RFC6347].
	The security service provides functions for secure communication over		LDACS also needs to comply with in-depth security requirements,
	the LDACS sub-network. Note that the SNP security service applies		stated in P858, for the radio access technologies transporting ATN/
	cryptographic measures as configured by the GS.		IPS data [ARI2021]. These requirements imply that LDACS must provide
			layer 2 security in addition to any higher layer mechanisms.
	10. Security Considerations		9.1. Security in Wireless Digital Aeronautical Communications
	10.1. Reasons for 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 military and a threat		wireless communications technology emerged from military and a threat
	landscape where inferior technological and financial capabilities of		landscape where inferior technological and financial capabilities of
	adversaries were assumed [STR2016]. The main communication method		adversaries were assumed [STR2016]. The main communications method
	for ATC today is still an open analogue voice broadcast within the		for ATC today is still an open analogue voice broadcast within the
	aeronautical VHF band. Currently, the information security is purely		aeronautical VHF band. Currently, information security is mainly
	procedural based by using well-trained personnel and proven		procedural, based by using well-trained personnel and proven
	communications procedures. This communication method has been in		communications procedures. This communication method has been in
	service since 1948. However, since the emergence of civil		service since 1948. However, since the emergence of civil
	aeronautical CNS application and today, the world has changed. Civil		aeronautical CNS applications in the 70s, and today, the world has
	applications have significant lower spectrum available than military		changed.
	applications. This means several military defence mechanisms such as
	frequency hopping or pilot symbol scrambling and, thus, a defense-in-
	depth approach starting at the physical layer is infeasible for civil
	systems. With the rise of cheap Software Defined Radios, the
	previously existing financial barrier is almost gone and open source
	projects such as GNU radio [GNU2012] allow the new type of
	unsophisticated listeners and possible attackers. Most CNS
	technology developed in ICAO relies on open standards, thus syntax
	and semantics of wireless digital aeronautical communications should
	be expected to be common knowledge for attackers. With increased
	digitization and automation of civil aviation the human as control
	instance is being taken gradually out of the loop. Autonomous
	transport drones or single piloted aircraft demonstrate this trend.
	However, without profound cybersecurity measures such as authenticity
	and integrity checks of messages in-transit on the wireless link or
	mutual entity authentication, this lack of a control instance can
	prove disastrous. Thus, future digital communications waveforms will
	need additional embedded security features to fulfill modern
	information security requirements like authentication and integrity.
	These security features require sufficient bandwidth which is beyond
	the capabilities of a VHF narrowband communications system. For
	voice and data communications, sufficient data throughput capability
	is needed to support the security functions while not degrading
	performance. LDACS is a data link technology with sufficient
	bandwidth to incorporate security without losing too much user
	throughput.
	As digitalization progresses even further with LDACS and automated		Civil applications have significant lower spectrum available than
	procedures such as 4D-Trajectories allowing semi-automated en-route		military applications. This means several military defense
	flying of aircraft, LDACS requires stronger cybersecurity measures.		mechanisms, such as frequency hopping or pilot symbol scrambling and,
			thus, a defense-in- depth approach starting at the physical layer, is
			infeasible for civil systems. With the rise of cheap Software
			Defined Radios (SDRs), the previously existing financial barrier is
			almost gone and open source projects such as GNU radio [GNU2021]
			allow a new type of unsophisticated listeners and possible attackers.
	10.2. LADACS Requirements		Most CNS technology developed in ICAO relies on open standards, thus
			syntax and semantics of wireless digital aeronautical communications
			should be expected to be common knowledge for attackers. With
			increased digitization and automation of civil aviation, the human as
			control instance, is being taken gradually out of the loop.
			Autonomous transport drones or single piloted aircraft demonstrate
			this trend. However, without profound cybersecurity measures such as
			authenticity and integrity checks of messages in-transit on the
			wireless link or mutual entity authentication, this lack of a control
			instance can prove disastrous. Thus, future digital communications
			waveforms will need additional embedded security features to fulfill
			modern information security requirements like authentication and
			integrity. These security features require sufficient bandwidth
			which is beyond the capabilities of currently deployed VHF narrowband
			communications systems. For voice and data communications,
			sufficient data throughput capability is needed to support the
			security functions while not degrading performance. LDACS is a data
			link technology with sufficient bandwidth to incorporate security
			without losing too much user data throughput.
	Overall there are several business goals for cybersecurity to protect		9.2. LDACS Requirements
	in FCI in civil aviation:
			Overall, there are several business goals for cybersecurity to
			protect, within the FCI in civil aviation:
	1. Safety: The system must sufficiently mitigate attacks, which		1. Safety: The system must sufficiently mitigate attacks, which
	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		which contribute to delays, diversions, or cancellations 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 which 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 and derive threats and thus protection
	scenarios several Threat-and Risk Analysis were performed for LDACS		scenarios several threat-and risk analyses were performed for LDACS
	[MAE20181] , [MAE20191]. These results allowed deriving security		[MAE20181] , [MAE20191]. These results allowed deriving security
	scope and objectives from the requirements and the conducted Threat-		scope and objectives from the requirements and the conducted threat-
	and Risk Analysis.		and risk analysis.
	10.3. LDACS Security Objectives		9.3. LDACS Security Objectives
	Security considerations for LDACS are defined by the official		Security considerations for LDACS are defined by the official SARPS
	Standards And Recommended Practices (SARPS) document by ICAO		document by ICAO [ICA2018]:
	[ICA2018]:
	1. LDACS shall provide a capability to protect the availability and		1. 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		2. 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		3. 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		4. LDACS should provide a capability for nonrepudiation of origin
	for messages in transit.		for messages in transit.
	5. LDACS should provide a capability to protect the confidentiality		5. LDACS should provide a capability to protect the confidentiality
	of messages in transit.		of messages in transit.
	6. LDACS shall provide an authentication capability.		6. LDACS shall provide an authentication capability.
	7. LDACS shall provide a capability to authorize the permitted		7. 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		8. 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.
	10.4. LDACS Security Functions		Currently, a change request for these SARPS aims to limit the "non-
			repudiation of origin of messages in transit" requirement only to the
			authentication and key establishment messages at the beginning of
			every session.
			9.4. 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: (1) Identification, (2) Authentication, (3)		architecture: Identification, Authentication, Authorization,
	Authorization, (4) Confidentiality, (5) System Integrity, (6) Data		Confidentiality, System Integrity, Data Integrity, Robustness,
	Integrity, (7) Robustness, (8) Reliability, (9) Availability, and		Reliability, Availability, and Key and Trust Management. Several
	(10) Key and Trust Management. Several works investigated possible		works investigated possible measures to implement these security
	measures to implement these security functions [BIL2017], [MAE20181],		functions [BIL2017], [MAE20181], [MAE20191].
	[MAE20191]. Having identified security requirements, objectives and
	functions it must be ensured that they are applicable.
	10.5. LDACS Security Architecture		9.5. LDACS Security Architecture
	The requirements lead to a LDACS security model including different		The requirements lead to a LDACS security model, including different
	entities for identification, authentication and authorization		entities for identification, authentication and authorization
	purposes ensuring integrity, authenticity and confidentiality of data		purposes, ensuring integrity, authenticity and confidentiality of
	in-transit especially.		data. A draft of the cybersecurity architecture of LDACS can be
			found in [ICA2018] and [MAE20182] and respective updates in
			[MAE20191], [MAE20192], [MAE2020], and most recently [MAE2021].
	10.5.1. Entities		9.5.1. Entities
	A simplified LDACS architectural modelrequires 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 [ARI2020]
	are providing access to the (1) Ground IPS network via an (2) A2G		are providing access to the ground IPS network via an A/G LDACS
	LDACS Router. This router is attached to a closed off LDACS Access		router. This router is attached to a closed off LDACS access
	Network, (3) which connects via further (4) Access Routers to the		network, which connects via further (access routers to the different
	different (5) LDACS Cell Ranges, each controlled by a (6) GS (serving		LDACS cell ranges, each controlled by a GS (serving one LDACS cell),
	one LDACS cell), with several interconnected GS (7) spanning a local		with several interconnected GS spanning a local LDACS access network.
	LDACS access network. Via the (8) A2G wireless LDACS data link (9)		Via the A/G wireless LDACS data link AS the aircraft is connected to
	AS the aircraft is connected to the ground network and via the (10)		the ground network and via the aircraft's VI and aircraft's network
	aircrafts's VI and (11) aircraft's network interface, aircraft's data		interface, aircraft's data can be sent via the AS back to the GS,
	can be sent via the AS back to the GS, LDACS local access network,		then to the LDACS local access network, access routers, LDACS access
	access routers, LDACS access network, A2G LDACS router to the ground		network, A/G LDACS router and finally to the ground IPS network
	Internet Protocol Suite (IPS) network [ICAO20152].		[ICAO2015].
	10.5.2. Entity Identification
	LDACS needs specific identities for (1) the AS, (2) the GS, and (3)
	the Network Operator. The aircraft itself can be identified using
	the ICAO unique address of an aircraft, the call sign of that
	aircraft or the recently founded Privacy ICAO Address (PIA) program
	[FAA2020]. It is conceivable that the LDACS AS will use a
	combination of aircraft identification, radio component
	identification and even operator features identification to create a
	unique AS LDACS identification tag. Similar to a 4G's eNodeB Serving
	Network (SN) Identification tag, a GS could be identified using a
	similar field. The identification of the network operator is again
	similar to 4G (e.g., E-Plus, AT&T, and TELUS), in the way that the
	aeronautical network operators are listed (e.g., ARINC [ARI2020] and
	SITA [SIT2020]).
	10.5.3. Entity Authentication and Key Negotiation
	In order to anchor Trust within the system all LDACS entities
	connected to the ground IPS network shall be rooted in an LDACS
	specific chain-of-trust and PKI solution, quite similar to AeroMACS
	approach [CRO2016]. These X.509 certificates [RFC5280] residing at
	the entities and incorporated in the LDACS PKI proof the ownership of
	their respective public key, include information about the identity
	of the owner and the digital signature of the entity that has
	verified the certificate's content. First all ground infrastructures
	must mutually authenticate to each other, negotiate and derive keys
	and, thus, secure all ground connections. How this process is
	handled in detail is still an ongoing discussion. However,
	established methods to secure user plane by IPSec [RFC4301] and IKEv2
	[RFC7296] or the application layer via TLS 1.3 [RFC8446] are
	conceivable. The LDACS PKI with their chain-of-trust approach,
	digital certificates and public entity keys lay the groundwork for
	this step. In a second step the AS with the LDACS radio approaches
	an LDACS cell and performs a cell entry with the corresponding GS.
	Similar to the LTE cell attachment process [TS33.401], where
	authentication happens after basic communication has been enabled
	between AS and GS (step 5a in the UE attachment process [TS33.401]),
	the next step is mutual authentication and key exchange. Hence, in
	step three using the identity-based Station-to-Station (STS) protocol
	with Diffie-Hellman Key Exchange [MAE2020], AS and GS establish
	mutual trust by authenticating each other, exchanging key material
	and finally, both ending up with derived key material. A key
	confirmation is mandatory before the communication channel between
	the AS and the GS can be opened for user-data communications.
	10.5.4. Message-in-transit Confidentiality, Integrity and Authenticity
	The subsequent key material from the previous step can then be used
	to protect LDACS Layer 2 communications via applying encryption and
	integrity 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 important, while confidentiality only needs to be
	applied to AOC data to protect business interests [ICA2018]. This
	possibility of providing low layered confidentiality and integrity
	protection ensures a secure delivery of user data over the air gap.
	Furthermore, it ensures integrity protection of LDACS control data.
	10.6. LDACS Security Modules
	A draft of the cybersecurity architecture of LDACS can be found in
	[ICA2018] and [MAE20182] and respective updates in [MAE20191],
	[MAE20192], and [MAE2020].
	10.6.1. Placements of Security Functionality in Protocol Stack
	Placing protection mechanisms in the LME and SNP entities within the
	protocol stack of LDACS will be most efficient in securing LDACS.
	MAC and DLS will also receive new tasks like the measurement
	performance for control channel protection. Security endpoints for
	secure user data communication, control data protection and primary
	entity authentication are the AS and GS.
	10.6.2. Trust
	The LDACS security concept requires all entities in an LDACS network
	to authenticate to each other to ascertain that only trusted
	participants can use the system. To establish trust within the
	network, inter-operations between all FCI candidates must be
	possible, thus LDACS will follow AeroMACS lead and also use an FCI
	specific PKI [RFC5280]. A PKI can solve the problem of having to
	trust a communication's partner identity claim via involving a
	trusted third party who verifies the identities of the parties who
	wish to engage in communication via issuing a digital certificate.
	As aviation operates worldwide, a hierarchical PKI will have to be
	deployed with several sub-CAs being distributed over the world.
	Basically, there are two proposals on how to achieve worldwide trust
	coverage:
	1. One root CA is installed per geographic region and then it
	performs cross-certification with distributed root-CAs of all
	other geo-graphic regions around the world. Subdomains can exist
	within ATM organizations. Here trust emerges from the assured
	trustworthiness of each regional root CA cross-certifying other
	and being cross-certified by other regional CAs
	2. The other idea is to have one worldwide (probably offline) root
	CA, hosted by a trusted worldwide entity, such as ICAO, with
	several regions sub-CAs distributed around the world. That way,
	the ICAO hosted root CA serves as trust bridge.
	10.6.3. Mutual Authentication and Key Exchange (MAKE)
	Via a modified, identity-based STS procedure and digital certificate
	and public keys pre-deployed during maintenance at the respective
	end-entities, the MAKE procedure can guarantee (1) Mutual
	Authentication, (2) Secure Key Agreement, (3) Prefect Forward Secrecy
	and (4) Key Confirmation [MAE2020]. As Diffie-Hellman Key Exchange
	(DHKE) procedure, we are currently evaluating the classic ephemeral
	DHKE [DIF1976] with 3072bit keys, Elliptic Curve DHKE (ECDH) with
	256bit keys [KOB1987] and the Supersingular Isogeny DHKE (SIDH) with
	2624bit key sizes [JAO2011]. As minimization of security data on the
	datalink is key, ECDH is currently the favorite way forward.
	Assuming that an LDACS security header consists of TYPE, ID, UA and
	PRIO fields, the entire header is of length 48bit [GRA2019].
	Cryptographic nonces are 96bit long, signatures 512bit and the public
	elliptic curve Diffie-Hellman keys 256bit. With these bit sizes, the
	entire STS-MAKE procedure between AS and GS requires a total of 4
	messages and 1920bit [MAE2021].
	10.6.4. Key Derivation and Key Hierarchy
	Once all parties within the network have successfully authenticated		9.5.2. Entity Identification
	to each other, key derivation is necessary to generate different keys
	for different purposes. We need different keys for user data
	protection and keys for control data protection. As key derivation
	function, we propose the Hash-based Message Authentication Code
	(HMAC) Key Derivation Function (KDF) - HKDF [RFC5869]. First the
	input keying material (here: master key/static Diffie Hellman shared
	key) is taken and a fixed-length pseudo-random key is extracted. We
	extract a pseudorandom key from the master key by adding a salt
	value, which can be any fixed non-secret string chosen at random. In
	the process the pseudo random key becomes indistinguishable from a
	uniform distribution of bits. As LDACS will be deployed in 2024 with
	a recommendation of a minimum-security level of 128bit.
	10.6.5. User Data Security		LDACS needs specific identities for the AS, the GS, and the network
			operator. The aircraft itself can be identified using the ICAO
			unique address of an aircraft, the call sign of that aircraft or the
			recently founded privacy ICAO address of the Federal Aviation
			Administration (FAA) program with the same name [FAA2020]. It is
			conceivable that the LDACS AS will use a combination of aircraft
			identification, radio component identification and even operator
			feature identification to create a unique AS LDACS identification
			tag. Similar to a 4G's eNodeB serving network identification tag, a
			GS could be identified using a similar field. The identification of
			the network operator is again similar to 4G (e.g., E-Plus, AT&T, and
			TELUS), in the way that the aeronautical network operators are listed
			(e.g., ARINC [ARI2020] and SITA [SIT2020]).
	It is proposed to secure LDACS Sub-Network Packet Data Units (SN-		9.5.3. Entity Authentication and Key Establishment
	PDU)s, as their size can vary from 128 to 1536 Byte [GRA2019], which
	makes them possibly the largest PDUs within LDACS. This helps
	minimizing security data overhead, in case a Message Authentication
	Code (MAC) tag is attached to the SN-PDU. For confidentiality
	protection, it is recommended symmetric approaches for data
	encryption, due to low computational overhead and fast operation
	times. As encryption algorithm, it is recommended to use AES-128-
	GCM/AES-256-GCM [RFC5288] with Galois Counter Mode (GCM) being a mode
	of operation on symmetric key block. It provides authenticated
	encryption and decryption operations and it proves robust against
	currently known quantum-computer-based algorithms [BER2017]. For
	message integrity/authenticity protection, it is recommended either
	to use the aforementioned AES-GCM with tag lengths of at least 128bit
	or HMAC with hash-functions from the SHA-3 family [PRI2014]. At
	least HMAC-SHA3-128 with a tag length of 128bit is recommended. This
	way the tag security data overhead ranges from 1.04 to 12.50% for
	user data, depending on the SN-PDU size.
	10.6.6. Control Data Security		In order to anchor trust within the system, all LDACS entities
			connected to the ground IPS network will be rooted in an LDACS
			specific chain-of-trust and PKI solution, quite similar to AeroMACS's
			approach [CRO2016]. These certificates, residing at the entities and
			incorporated in the LDACS PKI, providing proof the ownership of their
			respective public key, include information about the identity of the
			owner and the digital signature of the entity that has verified the
			certificate's content. First, all ground infrastructures must
			mutually authenticate to each other, negotiate and derive keys and,
			thus, secure all ground connections. How this process is handled in
			detail is still an ongoing discussion. However, established methods
			to secure user plane by IPSec [RFC4301] and IKEv2 [RFC7296] or the
			application layer via TLS 1.3 [RFC8446] are conceivable. The LDACS
			PKI with their chain-of-trust approach, digital certificates and
			public entity keys lay the groundwork for this step. In a second
			step, the AS with the LDACS radio aboard, approaches an LDACS cell
			and performs a cell-attachment procedure with the corresponding GS.
			This procedure consists of (1) the basic cell entry [GRA2019] and (2)
			a Mutual Authentication and Key Establishment (MAKE) procedure
			[MAE2021].
	LDACS has four control channels: AS announce their existence in the		Note, that LDACS will foresee multiple security levels. To address
	RA, at the beginning of each SF in the RL, where each AS can transmit		the issue of the long service life of LDACS (i.e., possibly >30
	56bit. GS announce their existence in the BC, at the beginning of		years) and the security of current pre-quantum cryptography, these
	each SF in the FL, where the GS can transmit a total of 2304bit. AS		security levels include pre- and post-quantum cryptographic
	can request resources in the DC, where each AS has an 83bit long slot		solutions. Limiting security data on the LDACS datalink as much as
	and GS can grant those resources in the CC, with 728bit per CC-PHY-		possible, to reserve as much space for actual user data transmission,
	SDU. As the control channels of LDACS are very small-size, it is		is key in the LDACS security architecture, this is also reflected in
	obvious that protection is challenging. Having security requirements		the underlying cryptography: Pre-quantum solutions will rely on
	in mind it is recommended to introduce group key mechanisms for		elliptic curves [KOB1987], while post-quantum solutions consider
	LDACS. Thus, after the MAKE procedure of LDACS, a control plane		Falcon [SON2021] [MAE2021] or similar lightweight PQC signature
	related group key is derived by the GS and shared with all AS in a		schemes, and SIKE or SABER as key establishment options [SIK2021]
	protected manner. As group key procedure, several approaches are		[ROY2020].
	investigated (e.g., G-IKEv2 [I-D.ietf-ipsecme-g-ikev2], CRGT
	[ZHE2007], CAKE [GUG2018], LKH [SAK2014], and OFT [KUM2020]). As OFT
	has the least requirements on network operations compared to the
	other, LDACS will use OFT with a fixed tree of 512-member nodes for a
	maximum of 512 supported AS in an LDACS cell. All AS and GS use this
	group key to protect the exchanged control data in the CC/DC slots.
	As these messages remain valid for a time period in the order of 10
	ms and the transmission is distance bound by the MAC protocol of
	LDACS, very small digest tags of 16 or 32bit can suffice to protect a
	minimum of integrity of control messages of LDACS. To that end, it
	is proposed to use blake2b or blake2s and to trim the tag after 4
	bytes [RFC7693].
	11. Privacy Considerations		9.5.4. Message-in-transit Confidentiality, Integrity and Authenticity
	LDACS provides a Quality-of-Service, and the generic considerations		The key material from the previous step can then be used to protect
	for such mechanisms apply.		LDACS Layer 2 communications via applying encryption and integrity
			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
			important, while confidentiality only needs to be applied to AOC data
			to protect business interests [ICA2018]. This possibility of
			providing low layered confidentiality and integrity protection
			ensures a secure delivery of user data over the air gap.
			Furthermore, it ensures integrity protection of LDACS control data.
	12. IANA Considerations		10. IANA Considerations
	This memo includes no request to IANA.		This memo includes no request to IANA.
	13. Acknowledgements		11. Acknowledgements
	Thanks to all contributors to the development of LDACS and ICAO PT-T.		Thanks to all contributors to the development of LDACS and ICAO PT-T.
	Thanks to Klaus-Peter Hauf, Bart Van Den Einden, and Pierluigi		Thanks to Klaus-Peter Hauf, Bart Van Den Einden, and Pierluigi
	Fantappie for further input to this draft.		Fantappie for further input to this draft.
	Thanks to the Chair for Network Security and the research institute		Thanks to the Chair for Network Security and the research institute
	CODE for their comments and improvements.		CODE for their comments and improvements.
	Thanks to SBA Research Vienna for fruitful discussions on		Thanks to SBA Research Vienna for fruitful discussions on
	aeronautical communications concerning security incentives for		aeronautical communications concerning security incentives for
	industry and potential economic spillovers.		industry and potential economic spillovers.
	14. Normative References		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.
			12. Normative References
			[GRA2019] Graeupl, T., Rihacek, C., and B. Haindl, "LDACS A/G
			Specification", SESAR2020 PJ14-02-01 D3.3.030 , 2019.
			[ICAO2015] International Civil Aviation Organization (ICAO), "Manual
			on the Aeronautical Telecommunication Network (ATN) using
			Internet Protocol Suite (IPS) Standards and Protocols, Doc
			9896", January 2015,
			<https://standards.globalspec.com/std/10026940/icao-9896>.
			[RTCA2019] Radio Technical Commission for Aeronautics (RTCA),
			"Internet Protocol Suite Profiles, DO-379", September
			2019, <https://www.rtca.org/products/do-379/>.
			[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/>.
			[ARI2021] ARINC, "Internet Protocol Suite (IPS) For Aeronautical
			Safety Services Part 1- Airborne IP System Technical
			Requirements, ARINC SPECIFICATION 858 P1", June 2021,
			<https://standards.globalspec.com/std/14391274/858p1>.
			13. Informative References
			[RFC3610] Whiting, D., Housley, R., and N. Ferguson, "Counter with
			CBC-MAC (CCM)", RFC 3610, DOI 10.17487/RFC3610, September
			2003, <https://www.rfc-editor.org/info/rfc3610>.
			[RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing
			Architecture", RFC 4291, DOI 10.17487/RFC4291, February
			2006, <https://www.rfc-editor.org/info/rfc4291>.
	[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>.
			[RFC4493] Song, JH., Poovendran, R., Lee, J., and T. Iwata, "The
			AES-CMAC Algorithm", RFC 4493, DOI 10.17487/RFC4493, June
			2006, <https://www.rfc-editor.org/info/rfc4493>.
	[RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S.,		[RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S.,
	Housley, R., and W. Polk, "Internet X.509 Public Key		Housley, R., and W. Polk, "Internet X.509 Public Key
	Infrastructure Certificate and Certificate Revocation List		Infrastructure Certificate and Certificate Revocation List
	(CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008,		(CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008,
	<https://www.rfc-editor.org/info/rfc5280>.		<https://www.rfc-editor.org/info/rfc5280>.
			[RFC5869] Krawczyk, H. and P. Eronen, "HMAC-based Extract-and-Expand
			Key Derivation Function (HKDF)", RFC 5869,
			DOI 10.17487/RFC5869, May 2010,
			<https://www.rfc-editor.org/info/rfc5869>.
			[RFC6012] Salowey, J., Petch, T., Gerhards, R., and H. Feng,
			"Datagram Transport Layer Security (DTLS) Transport
			Mapping for Syslog", RFC 6012, DOI 10.17487/RFC6012,
			October 2010, <https://www.rfc-editor.org/info/rfc6012>.
			[RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer
			Security Version 1.2", RFC 6347, DOI 10.17487/RFC6347,
			January 2012, <https://www.rfc-editor.org/info/rfc6347>.
			[RFC7136] Carpenter, B. and S. Jiang, "Significance of IPv6
			Interface Identifiers", RFC 7136, DOI 10.17487/RFC7136,
			February 2014, <https://www.rfc-editor.org/info/rfc7136>.
			[RFC7236] Reschke, J., "Initial Hypertext Transfer Protocol (HTTP)
			Authentication Scheme Registrations", RFC 7236,
			DOI 10.17487/RFC7236, June 2014,
			<https://www.rfc-editor.org/info/rfc7236>.
	[RFC7296] Kaufman, C., Hoffman, P., Nir, Y., Eronen, P., and T.		[RFC7296] Kaufman, C., Hoffman, P., Nir, Y., Eronen, P., and T.
	Kivinen, "Internet Key Exchange Protocol Version 2		Kivinen, "Internet Key Exchange Protocol Version 2
	(IKEv2)", STD 79, RFC 7296, DOI 10.17487/RFC7296, October		(IKEv2)", STD 79, RFC 7296, DOI 10.17487/RFC7296, October
	2014, <https://www.rfc-editor.org/info/rfc7296>.		2014, <https://www.rfc-editor.org/info/rfc7296>.
	[RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol		[RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol
	Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018,		Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018,
	<https://www.rfc-editor.org/info/rfc8446>.		<https://www.rfc-editor.org/info/rfc8446>.
	[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate		[SCH2016] Schneckenburger, N., Jost, T., Shutin, D., Walter, M.,
	Requirement Levels", BCP 14, RFC 2119,
	DOI 10.17487/RFC2119, March 1997,
	<https://www.rfc-editor.org/info/rfc2119>.
	[RFC5869] Krawczyk, H. and P. Eronen, "HMAC-based Extract-and-Expand
	Key Derivation Function (HKDF)", RFC 5869,
	DOI 10.17487/RFC5869, May 2010,
	<https://www.rfc-editor.org/info/rfc5869>.
	[RFC5288] Salowey, J., Choudhury, A., and D. McGrew, "AES Galois
	Counter Mode (GCM) Cipher Suites for TLS", RFC 5288,
	DOI 10.17487/RFC5288, August 2008,
	<https://www.rfc-editor.org/info/rfc5288>.
	[RFC7693] Saarinen, M-J., Ed. and J-P. Aumasson, "The BLAKE2
	Cryptographic Hash and Message Authentication Code (MAC)",
	RFC 7693, DOI 10.17487/RFC7693, November 2015,
	<https://www.rfc-editor.org/info/rfc7693>.
	15. Informative References
	[SCHN2016] Schneckenburger, N., Jost, T., Shutin, D., Walter, M.,
	Thiasiriphet, T., Schnell, M., and U.C. Fiebig,		Thiasiriphet, T., Schnell, M., and U.C. Fiebig,
	"Measurement of the L-band Air-to-Ground Channel for		"Measurement of the L-band Air-to-Ground Channel for
	Positioning Applications", IEEE Transactions on Aerospace		Positioning Applications", IEEE Transactions on Aerospace
	and Electronic Systems, 52(5), pp.2281-229 , 2016.		and Electronic Systems, 52(5), pp.2281-229 , 2016.
	[MAE20191] Maeurer, N., Graeupl, T., and C. Schmitt, "Evaluation of		[MAE20191] Maeurer, N., Graeupl, T., and C. Schmitt, "Evaluation of
	the LDACS Cybersecurity Implementation", IEEE 38th Digital		the LDACS Cybersecurity Implementation", IEEE 38th Digital
	Avionics Systems Conference (DACS), pp. 1-10, San Diego,		Avionics Systems Conference (DACS), pp. 1-10, San Diego,
	CA, USA , 2019.		CA, USA , 2019.
	[MAE20192] Maeurer, N. and C. Schmitt, "Towards Successful		[MAE20192] Maeurer, N. and C. Schmitt, "Towards Successful
	Realization of the LDACS Cybersecurity Architecture: An		Realization of the LDACS Cybersecurity Architecture: An
	Updated Datalink Security Threat- and Risk Analysis", IEEE		Updated Datalink Security Threat- and Risk Analysis", IEEE
	Integrated Communications, Navigation and Surveillance		Integrated Communications, Navigation and Surveillance
	Conference (ICNS), pp. 1-13, Herndon, VA, USA , 2019.		Conference (ICNS), pp. 1-13, Herndon, VA, USA , 2019.
	[GRA2019] Graeupl, T., Rihacek, C., and B. Haindl, "LDACS A/G
	Specification", SESAR2020 PJ14-02-01 D3.3.030 , 2019.
	[FAN2019] Pierattelli, S., Fantappie, P., Tamalet, S., van den		[FAN2019] Pierattelli, S., Fantappie, P., Tamalet, S., van den
	Einden, B., Rihacek, C., and T. Graeupl, "LDACS Deployment		Einden, B., Rihacek, C., and T. Graeupl, "LDACS Deployment
	Options and Recommendations", SESAR2020 PJ14-02-01		Options and Recommendations", SESAR2020 PJ14-02-01
	D3.4.020 , 2019.		D3.4.020 , 2019.
	[MAE20182] Maeurer, N. and A. Bilzhause, "A Cybersecurity		[MAE20182] Maeurer, N. and A. Bilzhause, "A Cybersecurity
	Architecture for the L-band Digital Aeronautical		Architecture for the L-band Digital Aeronautical
	Communications System (LDACS)", IEEE 37th Digital Avionics		Communications System (LDACS)", IEEE 37th Digital Avionics
	Systems Conference (DASC), pp. 1-10, London, UK , 2017.		Systems Conference (DASC), pp. 1-10, London, UK , 2017.
	skipping to change at page 32, line 13 ¶		skipping to change at page 31, line 28 ¶
	2011.		2011.
	[GRA2018] Graeupl, T., Schneckenburger, N., Jost, T., Schnell, M.,		[GRA2018] Graeupl, T., Schneckenburger, N., Jost, T., Schnell, M.,
	Filip, A., Bellido-Manganell, M.A., Mielke, D.M., Maeurer,		Filip, A., Bellido-Manganell, M.A., Mielke, D.M., Maeurer,
	N., Kumar, R., Osechas, O., and G. Battista, "L-band		N., Kumar, R., Osechas, O., and G. Battista, "L-band
	Digital Aeronautical Communications System (LDACS) flight		Digital Aeronautical Communications System (LDACS) flight
	trials in the national German project MICONAV", Integrated		trials in the national German project MICONAV", Integrated
	Communications, Navigation, Surveillance Conference		Communications, Navigation, Surveillance Conference
	(ICNS), pp. 1-7, Herndon, VA, USA , 2018.		(ICNS), pp. 1-7, Herndon, VA, USA , 2018.
	[SCH20191] Schnell, M., "DLR Tests Digital Communications
	Technologies Combined with Additional Navigation Functions
	for the First Time", 2019.
	[ICA2018] International Civil Aviation Organization (ICAO), "L-Band		[ICA2018] International Civil Aviation Organization (ICAO), "L-Band
	Digital Aeronautical Communication System (LDACS)",		Digital Aeronautical Communication System (LDACS)",
	International Standards and Recommended Practices Annex 10		International Standards and Recommended Practices Annex 10
	- Aeronautical Telecommunications, Vol. III -		- Aeronautical Telecommunications, Vol. III -
	Communication Systems , 2018.		Communication Systems , 2018.
	[SAJ2014] Haindl, B., Meser, J., Sajatovic, M., Mueller, S.,		[SAJ2014] Haindl, B., Meser, J., Sajatovic, M., Mueller, 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,
	skipping to change at page 33, line 32 ¶		skipping to change at page 32, line 41 ¶
	[MAE20181] Maeurer, N. and A. Bilzhause, "Paving the Way for an IT		[MAE20181] Maeurer, N. and A. Bilzhause, "Paving the Way for an IT
	Security Architecture for LDACS: A Datalink Security		Security Architecture for LDACS: A Datalink Security
	Threat and Risk Analysis", IEEE Integrated Communications,		Threat and Risk Analysis", IEEE Integrated Communications,
	Navigation, Surveillance Conference (ICNS), pp. 1-11, New		Navigation, Surveillance Conference (ICNS), pp. 1-11, New
	York, NY, USA , 2018.		York, NY, USA , 2018.
	[FAA2020] FAA, "Federal Aviation Administration. ADS-B Privacy.",		[FAA2020] FAA, "Federal Aviation Administration. ADS-B Privacy.",
	August 2020,		August 2020,
	<https://www.faa.gov/nextgen/equipadsb/privacy/>.		<https://www.faa.gov/nextgen/equipadsb/privacy/>.
	[GNU2012] GNU Radio project, "GNU radio", August 2012,		[GNU2021] GNU Radio project, "GNU radio", October 2021,
	<http://gnuradio.org>.		<http://gnuradio.org>.
	[SIT2020] SITA, "Societe Internationale de Telecommunications		[SIT2020] SITA, "Societe Internationale de Telecommunications
	Aeronautiques", August 2020, <https://www.sita.aero/>.		Aeronautiques", August 2020, <https://www.sita.aero/>.
	[ARI2020] ARINC, "Aeronautical Radio Incorporated", August 2020,		[ARI2020] ARINC, "Aeronautical Radio Incorporated", August 2020,
	<https://www.aviation-ia.com/>.		<https://www.aviation-ia.com/>.
	[DO350A] RTCA SC-214, "Safety and Performance Standard for Baseline		[DO350A] RTCA SC-214, "Safety and Performance Standard for Baseline
	2 ATS Data Communications (Baseline 2 SPR Standard)", May		2 ATS Data Communications (Baseline 2 SPR Standard)", May
	2016, <https://standards.globalspec.com/std/10003192/rtca-		2016, <https://standards.globalspec.com/std/10003192/rtca-
	do-350-volume-1-2>.		do-350-volume-1-2>.
	[ICAO20151]		[ICAO2019] International Civil Aviation Organization (ICAO), "Manual
	International Civil Aviation Organization (ICAO), "Manual
	on VHF Digital Link (VDL) Mode 2, Doc 9776", January 2019,		on VHF Digital Link (VDL) Mode 2, Doc 9776", January 2019,
	<https://store.icao.int/en/manual-on-vhf-digital-link-vdl-		<https://store.icao.int/en/manual-on-vhf-digital-link-vdl-
	mode-2-doc-9776>.		mode-2-doc-9776>.
	[ICAO20152]
	International Civil Aviation Organization (ICAO), "Manual
	on the Aeronautical Telecommunication Network (ATN) using
	Internet Protocol Suite (IPS) Standards and Protocols, Doc
	9896", January 2015,
	<https://standards.globalspec.com/std/10026940/icao-9896>.
	[KAMA2010] Kamali, B., "An Overview of VHF Civil Radio Network and		[KAMA2010] Kamali, B., "An Overview of VHF Civil Radio Network and
	the Resolution of Spectrum Depletion", Integrated		the Resolution of Spectrum Depletion", Integrated
	Communications, Navigation, and Surveillance Conference,		Communications, Navigation, and Surveillance Conference,
	pp. F4-1-F4-8 , May 2010.		pp. F4-1-F4-8 , May 2010.
	[DIF1976] Diffie, W. and M. Hellman, "New Directions in		[SON2021] Soni, D., Basu, K., Nabeel, M., Aaraj, N., Manzano, M.,
	Cryptography", IEEE Transactions on Information Theory,		and R. Karri, "FALCON", Hardware Architectures for Post-
	22(6):644-654 , November 1976.		Quantum Digital Signature Schemes, pp. 31-41 , November
			2021.
	[KOB1987] Koblitz, N. and M. Hellman, "Elliptic Curve		[KOB1987] Koblitz, N. and M. Hellman, "Elliptic Curve
	Cryptosystems", Mathematics of Computation,		Cryptosystems", Mathematics of Computation,
	48(177):203-209. , January 1987.		48(177):203-209. , January 1987.
	[JAO2011] Jao, D. and L. De Feo, "Towards Quantum-Resistant		[SIK2021] SIKE, "SIKE – Supersingular Isogeny Key Encapsulation",
	Cryptosystems from Super-singular Elliptic Curve		October 2021, <https://sike.org/>.
	Isogenies", 4th International Workshop on Post-Quantum
	Cryptography, Springer, Heidelberg, Germany, pp. 19-34 ,
	November 2011.
	[MAE2021] Maeurer, N., Graeupl, T., and C. Schmitt, "Cybersecurity
	for the L-band DigitalAeronautical Communications System
	(LDACS)", Aviation Cybersecurity: Foundations, Principles,
	and Applications. H. Song, K. Hopkinson, T. De Cola, T.
	Alexandrovich, and D. Liu (Eds.), Chapter 07, in printing
	process , 2021.
	[BER2017] Bernstein, D.J. and T. Lange, "Post-Quantum Cryptography",
	Nature, 549(7671):188-194 , 2017.
	[PRI2014] Pritzker, P. and P.D. Gallagher, "SHA-3 standard:
	Permutation-Based Hash and Extendable-Output Functions",
	Information Tech Laboratory National Institute of
	Standards and Technology, pp. 1-35 , 2014.
	[ZHE2007] Zheng, X., Huang, C.T., and M. Matthews, "Chinese
	Remainder Theorem-Based Group Key Management", 45th Annual
	Southeast Regional Conference, ACM, New York, NY, USA, pp.
	266-271 , March 2007.
	[GUG2018] Guggemos, T., Streit, K., Knuepfer, M., gentsche Felde,
	N., and P. Hillmann, "No Cookies, Just CAKE: CRTbased Key
	Hierarchy for Efficient Key Management in Dynamic Groups",
	International Conference for Internet Technology and
	Secured Transactions, Cambridge, UK, pp. 25-32 , December
	2018.
	[SAK2014] Sakamoto, N., "An Efficient Structure for LKH Key Tree on
	Secure Multi-Cast Communications", 15th IEEE/ACIS
	International Conference on Software Engineering,
	Artificial Intelligence, Networking and Parallel/
	Distributed Computing, New York, NY, USA, pp. 1-7 ,
	November 2014.
	[KUM2020] Kumar, V., Kumar, R., and S.K. Pandey, "A Computationally		[ROY2020] Roy, S.S.. and A. Basso, "High-Speed Instruction-Set
	Efficient Centralized Group Key Distribution Protocol for		Coprocessor For Lattice-Based Key Encapsulation Mechanism:
	Secure Multicast Communications Based Upon RSA Public Key		Saber In Hardware", IACR Transactions on Cryptographic
	Cryptosystem", Journal of King Saud University - Computer		Hardware and Embedded Systems, 443-466. , August 2020.
	and Information Sciences, 32(9):1081-1094 , 2020.
	[RAW-TECHNOS]		[RAW-TECHNOS]
	Thubert, P., Cavalcanti, D., Vilajosana, X., Schmitt, C.,		Thubert, P., Cavalcanti, D., Vilajosana, X., Schmitt, C.,
	and J. Farkas, "Reliable and Available Wireless		and J. Farkas, "Reliable and Available Wireless
	Technologies", Work in Progress, Internet-Draft, draft-		Technologies", Work in Progress, Internet-Draft, draft-
	ietf-raw-technologies-01, 19 February 2021,		ietf-raw-technologies-04, 3 August 2021,
	<https://tools.ietf.org/html/draft-ietf-raw-technologies-		<https://datatracker.ietf.org/doc/html/draft-ietf-raw-
	01>.		technologies-04>.
	[RAW-USE-CASES]		[RAW-USE-CASES]
	Papadopoulos, G. Z., Thubert, P., Theoleyre, F., and C. J.		Papadopoulos, G. Z., Thubert, P., Theoleyre, F., and C. J.
	Bernardos, "RAW use cases", Work in Progress, Internet-		Bernardos, "RAW use cases", Work in Progress, Internet-
	Draft, draft-ietf-raw-use-cases-01, 21 February 2021,		Draft, draft-ietf-raw-use-cases-03, 20 October 2021,
	<https://tools.ietf.org/html/draft-ietf-raw-use-cases-01>.		<https://datatracker.ietf.org/doc/html/draft-ietf-raw-use-
			cases-03>.
	[I-D.ietf-ipsecme-g-ikev2]		[I-D.haindl-lisp-gb-atn]
	Smyslov, V. and B. Weis, "Group Key Management using		Haindl, B., Lindner, M., Rahman, R., Comeras, M. P.,
	IKEv2", Work in Progress, Internet-Draft, draft-ietf-		Moreno, V., Maino, F., and B. Venkatachalapathy, "Ground-
	ipsecme-g-ikev2-02, 11 January 2021,		Based LISP for the Aeronautical Telecommunications
	<https://tools.ietf.org/html/draft-ietf-ipsecme-		Network", Work in Progress, Internet-Draft, draft-haindl-
	g-ikev2-02>.		lisp-gb-atn-06, 6 March 2021,
			<https://datatracker.ietf.org/doc/html/draft-haindl-lisp-
			gb-atn-06>.
			[I-D.ietf-rtgwg-atn-bgp]
			Templin, F. L., 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-11, 6
			July 2021, <https://datatracker.ietf.org/doc/html/draft-
			ietf-rtgwg-atn-bgp-11>.
			[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>.
			[EURO2021] European Organization for Civil Aviation Equipment
			(EUROCAE), "Radio Frequency Function 2020 report", March
			2021, <https://www.eurocontrol.int/>.
			[ARI2019] ARINC, "AOC Air-Ground Data And Message Exchange Format,
			ARINC 633", January 2019,
			<https://standards.globalspec.com/std/13152055/
			ARINC%20633>.
			[VIR2021] Virdia, A., Stea, G., and G. Dini, "SAPIENT: Enabling
			Real-Time Monitoring and Control in the Future
			Communication Infrastructure of Air Traffic Management",
			IEEE Transactions on Intelligent Transportation Systems,
			22(8):4864-4875 , August 2021.
			[SHU2013] Shutin, D., Schneckenburger, N., Walter, M., and M.
			Schnell, "LDACS1 Ranging Performance - An Analysis Of
			Flight Measurement Results", IEEE 32th Digital Avionics
			Systems Conference (DASC), pp. 1-10, East Syracuse, NY,
			USA , October 2013.
			[BEL2021] Bellido-Manganell, M.A., Graeupl, T., Heirich, O.,
			Maeurer, 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] Maeurer, N., Graeupl, 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] Maeurer, N., Graeupl, 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.,
			Graeupl, 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 interesting 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 Communication
	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
	skipping to change at page 36, line 14 ¶		skipping to change at page 36, line 4 ¶
	CPDLC Controller Pilot Data Link Communication		CPDLC Controller Pilot Data Link Communication
	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
	+========================+=============+=============+		+========================+=============+=============+
	| | ECP 130 | ECP 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 |
	+------------------------+-------------+-------------+		+------------------------+-------------+-------------+
	| Availability | 0.989 | 0.989 |		| Availability | 0.989 | 0.989 |
	+------------------------+-------------+-------------+		+------------------------+-------------+-------------+
	| Integrity | 1E-5 per FH | 1E-5 per FH |		| Integrity | 1E-5 per FH | 1E-5 per FH |
	+------------------------+-------------+-------------+		+------------------------+-------------+-------------+
	Table 1: CPDLC Requirements for ECP		Table 1: CPDLC Requirements for RCP 130
	+==============+==========+==============+=========+=========+		+==============+==========+==============+=========+=========+
	| | RCP 240 | RCP 240 | RCP 400 | RCP 400 |		| | RCP 240 | RCP 240 | RCP 400 | RCP 400 |
	+==============+==========+==============+=========+=========+		+==============+==========+==============+=========+=========+
	| Parameter | ET | TT95% | ET | TT95% |		| Parameter | ET | TT95% | ET | TT95% |
	+--------------+----------+--------------+---------+---------+		+--------------+----------+--------------+---------+---------+
	| Transaction | 240 | 210 | 400 | 350 |		| Transaction | 240 | 210 | 400 | 350 |
	| Time (sec) | | | | |		| Time (sec) | | | | |
	+--------------+----------+--------------+---------+---------+		+--------------+----------+--------------+---------+---------+
	| Continuity | 0.999 | 0.95 | 0.999 | 0.95 |		| Continuity | 0.999 | 0.95 | 0.999 | 0.95 |
	+--------------+----------+--------------+---------+---------+		+--------------+----------+--------------+---------+---------+
	| Availability | 0.989 | 0.989 | 0.989 | 0.989 |		| Availability | 0.989 | 0.989 | 0.989 | 0.989 |
	| | (safety) | (efficiency) | | |		| | (safety) | (efficiency) | | |
	+--------------+----------+--------------+---------+---------+		+--------------+----------+--------------+---------+---------+
	| Integrity | 1E-5 per | 1E-5 per FH | 1E-5 | 1E-5 |		| Integrity | 1E-5 per | 1E-5 per FH | 1E-5 | 1E-5 |
	| | FH | | per FH | per FH |		| | FH | | per FH | per FH |
	+--------------+----------+--------------+---------+---------+		+--------------+----------+--------------+---------+---------+
	Table 2: CPDLC Requirements for RCP		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.		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 180 | RSP 180 | RSP |RSP 400|		| | RSP | RSP | RSP 180 | RSP 180 | RSP |RSP 400|
	| | 160 | 160 | | | 400 | |		| | 160 | 160 | | | 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 |
	| Time (sec) | | | | | | |		| Time (sec) | | | | | | |
	+--------------+-----+-----+----------+--------------+------+-------+		+--------------+-----+-----+----------+--------------+------+-------+
	skipping to change at page 37, line 35 ¶		skipping to change at page 37, line 28 ¶
	+--------------+-----+-----+----------+--------------+------+-------+		+--------------+-----+-----+----------+--------------+------+-------+
	| Integrity | 1E-5| 1E-5| 1E-5 per | 1E-5 per FH | 1E-5 | 1E-5 |		| Integrity | 1E-5| 1E-5| 1E-5 per | 1E-5 per FH | 1E-5 | 1E-5 |
	| | per | per | FH | |per FH| per FH|		| | per | per | FH | |per FH| per FH|
	| | 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 no longer
	meet the RSP specification for the intended function.		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.
	Authors' Addresses		Authors' Addresses
	Nils Maeurer (editor)		Nils Maeurer (editor)
	German Aerospace Center (DLR)		German Aerospace Center (DLR)
	Muenchner Strasse 20		Muenchner Strasse 20
	82234 Wessling		82234 Wessling
	Germany		Germany
	Email: Nils.Maeurer@dlr.de		Email: Nils.Maeurer@dlr.de
End of changes. 205 change blocks.
	938 lines changed or deleted		917 lines changed or added
This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/