< draft-maeurer-raw-ldacs-05.txt		draft-maeurer-raw-ldacs-06.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: 15 February 2021 C. Schmitt, Ed.		Expires: 5 April 2021 C. Schmitt, Ed.
	Research Institute CODE, UniBwM		Research Institute CODE, UniBwM
	14 August 2020		2 October 2020
	L-band Digital Aeronautical Communications System (LDACS)		L-band Digital Aeronautical Communications System (LDACS)
	draft-maeurer-raw-ldacs-05		draft-maeurer-raw-ldacs-06
	Abstract		Abstract
	This document provides an overview of the architecture of the L-band		This document provides 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 shall provide
	a data link for IP network-based aircraft guidance. High reliability		a data link for IP network-based aircraft guidance. High reliability
	and availability for IP connectivity over LDACS are therefore		and availability for IP connectivity over LDACS are therefore
	skipping to change at page 1, line 39 ¶		skipping to change at page 1, line 39 ¶
	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 15 February 2021.		This Internet-Draft will expire on 5 April 2021.
	Copyright Notice		Copyright Notice
	Copyright (c) 2020 IETF Trust and the persons identified as the		Copyright (c) 2020 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
	skipping to change at page 2, line 16 ¶		skipping to change at page 2, line 16 ¶
	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 . . . . . . . . . . . . . . . . . . . . . . . . . 3		2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
	3. Motivation and Use Cases . . . . . . . . . . . . . . . . . . 5		3. Motivation and Use Cases . . . . . . . . . . . . . . . . . . 5
	3.1. Voice Communications Today . . . . . . . . . . . . . . . 5		3.1. Voice Communications Today . . . . . . . . . . . . . . . 5
	3.2. Data Communications Today . . . . . . . . . . . . . . . . 6		3.2. Data Communications Today . . . . . . . . . . . . . . . . 6
	4. Provenance and Documents . . . . . . . . . . . . . . . . . . 6		4. Provenance and Documents . . . . . . . . . . . . . . . . . . 7
	5. Applicability . . . . . . . . . . . . . . . . . . . . . . . . 7		5. Applicability . . . . . . . . . . . . . . . . . . . . . . . . 8
	5.1. Advances Beyond the State-of-the-Art . . . . . . . . . . 8		5.1. Advances Beyond the State-of-the-Art . . . . . . . . . . 8
	5.1.1. Priorities . . . . . . . . . . . . . . . . . . . . . 8		5.1.1. Priorities . . . . . . . . . . . . . . . . . . . . . 8
	5.1.2. Security . . . . . . . . . . . . . . . . . . . . . . 8		5.1.2. Security . . . . . . . . . . . . . . . . . . . . . . 8
	5.1.3. High Data Rates . . . . . . . . . . . . . . . . . . . 8		5.1.3. High Data Rates . . . . . . . . . . . . . . . . . . . 9
	5.2. Application . . . . . . . . . . . . . . . . . . . . . . . 8		5.2. Application . . . . . . . . . . . . . . . . . . . . . . . 9
	5.2.1. Air-to-Ground Multilink . . . . . . . . . . . . . . . 9		5.2.1. Air-to-Ground Multilink . . . . . . . . . . . . . . . 9
	5.2.2. Air-to-Air Extension for LDACS . . . . . . . . . . . 9		5.2.2. Air-to-Air Extension for LDACS . . . . . . . . . . . 9
	5.2.3. Flight Guidance . . . . . . . . . . . . . . . . . . . 9		5.2.3. Flight Guidance . . . . . . . . . . . . . . . . . . . 10
	5.2.4. Business Communication of Airlines . . . . . . . . . 10		5.2.4. Business Communication of Airlines . . . . . . . . . 11
	5.2.5. LDACS Navigation . . . . . . . . . . . . . . . . . . 10		5.2.5. LDACS Navigation . . . . . . . . . . . . . . . . . . 11
	6. Requirements to LDACS . . . . . . . . . . . . . . . . . . . . 11		6. Requirements to LDACS . . . . . . . . . . . . . . . . . . . . 12
	7. Characteristics of LDACS . . . . . . . . . . . . . . . . . . 12		7. Characteristics of LDACS . . . . . . . . . . . . . . . . . . 15
	7.1. LDACS Sub-Network . . . . . . . . . . . . . . . . . . . . 12		7.1. LDACS Sub-Network . . . . . . . . . . . . . . . . . . . . 16
	7.2. Topology . . . . . . . . . . . . . . . . . . . . . . . . 13		7.2. Topology . . . . . . . . . . . . . . . . . . . . . . . . 16
	7.3. LDACS Physical Layer . . . . . . . . . . . . . . . . . . 14		7.3. LDACS Physical Layer . . . . . . . . . . . . . . . . . . 17
	7.4. LDACS Data Link Layer . . . . . . . . . . . . . . . . . . 14		7.4. LDACS Data Link Layer . . . . . . . . . . . . . . . . . . 17
	7.5. LDACS Mobility . . . . . . . . . . . . . . . . . . . . . 14		7.5. LDACS Mobility . . . . . . . . . . . . . . . . . . . . . 17
	8. Reliability and Availability . . . . . . . . . . . . . . . . 14		8. Reliability and Availability . . . . . . . . . . . . . . . . 18
	8.1. Layer 2 . . . . . . . . . . . . . . . . . . . . . . . . . 15		8.1. Layer 2 . . . . . . . . . . . . . . . . . . . . . . . . . 18
	8.2. Beyond Layer 2 . . . . . . . . . . . . . . . . . . . . . 17		8.2. Beyond Layer 2 . . . . . . . . . . . . . . . . . . . . . 20
	9. Protocol Stack . . . . . . . . . . . . . . . . . . . . . . . 18		9. Protocol Stack . . . . . . . . . . . . . . . . . . . . . . . 21
	9.1. Medium Access Control (MAC) Entity Services . . . . . . . 19		9.1. Medium Access Control (MAC) Entity Services . . . . . . . 22
	9.2. Data Link Service (DLS) Entity Services . . . . . . . . . 20		9.2. Data Link Service (DLS) Entity Services . . . . . . . . . 24
	9.3. Voice Interface (VI) Services . . . . . . . . . . . . . . 21		9.3. Voice Interface (VI) Services . . . . . . . . . . . . . . 25
	9.4. LDACS Management Entity (LME) Services . . . . . . . . . 21		9.4. LDACS Management Entity (LME) Services . . . . . . . . . 25
	9.5. Sub-Network Protocol (SNP) Services . . . . . . . . . . . 21		9.5. Sub-Network Protocol (SNP) Services . . . . . . . . . . . 25
	10. Security Considerations . . . . . . . . . . . . . . . . . . . 22		10. Security Considerations . . . . . . . . . . . . . . . . . . . 25
	10.1. Reasons for Wireless Digital Aeronautical		10.1. Reasons for Wireless Digital Aeronautical
	Communications . . . . . . . . . . . . . . . . . . . . . 22		Communications . . . . . . . . . . . . . . . . . . . . . 25
	10.2. Requirements for LDACS . . . . . . . . . . . . . . . . . 23		10.2. Requirements for LDACS . . . . . . . . . . . . . . . . . 26
	10.3. Security Objectives for LDACS . . . . . . . . . . . . . 23		10.3. Security Objectives for LDACS . . . . . . . . . . . . . 27
	10.4. Security Functions for LDACS . . . . . . . . . . . . . . 24		10.4. Security Functions for LDACS . . . . . . . . . . . . . . 27
	10.5. Security Architectural Details for LDACS . . . . . . . . 24		10.5. Security Architectural Details for LDACS . . . . . . . . 28
	10.5.1. Entities in LDACS Security Model . . . . . . . . . . 24		10.5.1. Entities in LDACS Security Model . . . . . . . . . . 28
	10.5.2. Matter of LDACS Entity Identification . . . . . . . 24		10.5.2. Matter of LDACS Entity Identification . . . . . . . 28
	10.5.3. Matter of LDACS Entity Authentication and Key		10.5.3. Matter of LDACS Entity Authentication and Key
	Negotiation . . . . . . . . . . . . . . . . . . . . . 25		Negotiation . . . . . . . . . . . . . . . . . . . . . 29
	10.5.4. Matter of LDACS Message-in-transit Confidentiality,		10.5.4. Matter of LDACS Message-in-transit Confidentiality,
	Integrity and Authenticity . . . . . . . . . . . . . 26		Integrity and Authenticity . . . . . . . . . . . . . 29
	10.6. Security Architecture for LDACS . . . . . . . . . . . . 26		10.6. Security Architecture for LDACS . . . . . . . . . . . . 30
	11. Privacy Considerations . . . . . . . . . . . . . . . . . . . 26		11. Privacy Considerations . . . . . . . . . . . . . . . . . . . 30
	12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 26		12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 30
	13. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 26		13. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 30
	14. Normative References . . . . . . . . . . . . . . . . . . . . 27		14. Normative References . . . . . . . . . . . . . . . . . . . . 30
	15. Informative References . . . . . . . . . . . . . . . . . . . 27		15. Informative References . . . . . . . . . . . . . . . . . . . 31
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 30		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 34
	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 communication infrastructure that
	enables efficient aircraft control and safe separation in all phases		enables efficient aircraft control and safe separation in all phases
	of flight. Current systems are technically mature but suffering from		of flight. Current systems are technically mature but suffering from
	the VHF band's increasing saturation in high-density areas and the		the VHF band's increasing saturation in high-density areas and the
	limitations posed by analogue radio communications. Therefore,		limitations posed by analogue radio communications. Therefore,
	aviation globally and the European Union (EU) in particular, strives		aviation globally and the European Union (EU) in particular, strives
	skipping to change at page 4, line 7 ¶		skipping to change at page 4, line 7 ¶
	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		A2A Air-to-Air
	LDACS A2A LDACS Air-to-Air		LDACS A2A LDACS Air-to-Air
	AeroMACS Aeronautical Mobile Airport Communication System		AeroMACS Aeronautical Mobile Airport Communication System
	A2G Air-to-Ground		A2G Air-to-Ground
	ACARS Aircraft Communications Addressing and Reporting System		ACARS Aircraft Communications Addressing and Reporting System
			ADS-C Automatic Dependent Surveillance - Contract
	AM(R)S Aeronautical Mobile (Route) Service		AM(R)S Aeronautical Mobile (Route) Service
	ANSP Air traffic Network Service Provider		ANSP Air traffic Network Service Provider
	AOC Aeronautical Operational Control		AOC Aeronautical Operational Control
	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
	CCCH Common Control Channel		CCCH Common Control Channel
	COTS IP Commercial Off-The-Shelf		COTS IP Commercial Off-The-Shelf
			CM Context Management
	CNS Communication Navigation Surveillance		CNS Communication Navigation Surveillance
			CPDLC Controller Pilot Data Link Communication
	DCCH Dedicated Control Channel		DCCH Dedicated Control Channel
	DCH Data Channel		DCH Data Channel
	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
	FAA Federal Aviation Administration		FAA Federal Aviation Administration
	FCI Future Communication Infrastructure		FCI Future Communication Infrastructure
	FDD Frequency Division Duplex		FDD Frequency Division Duplex
	FL Forward Link		FL Forward Link
	skipping to change at page 11, line 35 ¶		skipping to change at page 12, line 21 ¶
	Communication related to safety and regularity of flight.		Communication related to safety and regularity of flight.
	A particularity of the current aeronautical communication landscape		A particularity of the current aeronautical communication landscape
	is that it is heavily regulated. Aeronautical data links (for		is that it is heavily regulated. Aeronautical data links (for
	applications related to safety and regularity of flight) may only use		applications related to safety and regularity of flight) may only use
	spectrum licensed to aviation and data links endorsed by ICAO.		spectrum licensed to aviation and data links endorsed by ICAO.
	Nation states can change this locally, however, due to the global		Nation states can change this locally, however, due to the global
	scale of the air transportation system adherence to these practices		scale of the air transportation system adherence to these practices
	is to be expected.		is to be expected.
	Aeronautical data links for the ATN are therefore expected to remain		Aeronautical data links for the Aeronautical Telecommunication
	in service for decades. The VDLM2 data link currently used for		Network (ATN) are therefore expected to remain in service for
	digital terrestrial internetworking was developed in the 1990es (the		decades. The VDLM2 data link currently used for digital terrestrial
	use of the OSI internetwork stack indicates that as well). VDLM2 is		internetworking was developed in the 1990es (the use of the OSI
	expected to be used at least for several decades. In this respect		internetwork stack indicates that as well). VDLM2 is expected to be
	aeronautical communication (for applications related to safety and		used at least for several decades. In this respect aeronautical
	regularity of flight) is more comparable to industrial applications		communication (for applications related to safety and regularity of
	than to the open Internet.		flight) is more comparable to industrial applications than to the
			open Internet.
	Internetwork technology is already installed in current aircraft.		Internetwork technology is already installed in current aircraft.
	Current ATS applications use either the Aircraft Communications		Current ATS applications use either the Aircraft Communications
	Addressing and Reporting System (ACARS) or the Open Systems		Addressing and Reporting System (ACARS) or the Open Systems
	Interconnection (OSI) stack. The objective of the development effort		Interconnection (OSI) stack. The objective of the development effort
	LDACS is part of (FCI) is to replace legacy (OSI) and proprietary		LDACS is part of (FCI) is to replace legacy (OSI) and proprietary
	(ACARS) internetwork technologies with industry standard IP		(ACARS) internetwork technologies with industry standard IP
	technology. It is anticipated that the use of Commercial Off-The-		technology. It is anticipated that the use of Commercial Off-The-
	Shelf (COTS) IP technology mostly applies to the ground network. The		Shelf (COTS) IP technology mostly applies to the ground network. The
	avionics networks on the aircraft will likely be heavily modified or		avionics networks on the aircraft will likely be heavily modified or
	skipping to change at page 12, line 38 ¶		skipping to change at page 13, line 18 ¶
	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 e.g. VoIP) at the		interoperable with IP (and IP-based services e.g. VoIP) at the
	gateway connecting the LDACS network to other aeronautical ground		gateway connecting the LDACS network to other aeronautical ground
	networks (the totality of them being the ATN). On the avionics side		networks (the totality of them being the ATN). On the avionics side
	in the aircraft aviation specific solutions are to be expected.		in the aircraft aviation specific solutions are to be expected.
			In addition to the functional requirements LDACS and its IP stack
			need to fulfil the requirements defined in RTCA DO-350A/EUROCAE ED-
			228A [DO350A]. This document defines continuity, availability, and
			integrity requirements at different scopes for each air traffic
			management application (CPDLC, CM, and ADS-C). The scope most
			relevant to IP over LDACS is the CSP (Communication Service Provider)
			scope.
			The upcoming Figures Figure 1 and Figure 2 summarize the main
			seetings based on volume 1 Table 5-14, and Table 6-13 defined in
			[DO350A]. In a similar vein, requirements to fault management are
			defined in the same tables.
			+--------------+----------------+---------------------+----------------+
			| | ECP 130 | RCP 240 | RCP 400 |
			+--------------+-------+--------+----------+----------+-------+--------+
			| Parameter | ET | TT_95% | ET | TT_95% | ET | TT_95% |
			+--------------+-------+--------+----------+----------+-------+--------+
			| Transaction | 130 | 67 | 240 | 210 | 400 | 350 |
			| Time (Sec) | | | | | | |
			+--------------+-------+--------+----------+----------+-------+--------+
			| Continuity | 0.999 | 0.95 | 0.999 | 0.95 | 0.999 | 0.95 |
			+--------------+-------+--------+----------+----------+-------+--------+
			| Availability | 0.989 | 0.989 (safety) | 0.989 |
			| | | 0.9899 (efficiency) | |
			+--------------+----------------+---------------------+----------------+
			| Integrity | 1E-5 per FH | 1E-5 per FH | 1E-5 per FH |
			+--------------+----------------+---------------------+----------------+
			| RCP Monitoring and Alerting Criteria |
			+--------------+-------------------------------------------------------+
			| MA-1 | The system shall be capable of detecting failures |
			| | and configuration changes that would cause the |
			| | communication service no longer meet the RCP |
			| | specification for the intended use. |
			+--------------+-------------------------------------------------------+
			| MA-2 | When the communication service can no longer |
			| | meet the RCP specification for the intended |
			| | function, the flight crew and/or the controller |
			| | shall take appropriate action. |
			+--------------+-------------------------------------------------------+
			Figure 1: Requirements for CPDLC
			+--------------+----------------+---------------------+----------------+
			| | RSP 160 | RSP 180 | RSP 400 |
			+--------------+-------+--------+----------+----------+-------+--------+
			| Parameter | OT | DT 95% | OT | DT 95% | OT | DT 95% |
			+--------------+-------+--------+----------+----------+-------+--------+
			| Transaction | 160 | 90 | 180 | 90 | 400 | 300 |
			| time (sec) | | | | | | |
			+--------------+-------+--------+----------+----------+-------+--------+
			| Continuity | 0.999 | 0.95 | 0.999 | 0.95 | 0.999 | 0.95 |
			+--------------+-------+--------+----------+----------+-------+--------+
			| Availability | 0.989 | 0.989 (safety) | 0.989 |
			| | | 0.9899 (efficiency) | |
			+--------------+----------------+---------------------+----------------+
			| Integrity | 1E-5 per FH | 1E-5 per FH | 1E-5 per FH |
			+--------------+----------------+---------------------+----------------+
			| RCP Monitoring and Alerting Criteria |
			+--------------+-------------------------------------------------------+
			| MA-1 | The system shall be capable of detecting failures |
			| | and configuration changes that would cause the |
			| | ADS-C service no longer meet the RSP |
			| | specification for the intended function. |
			+--------------+-------------------------------------------------------+
			| MA-2 | When the ADS-C service can no longer meet the RSP |
			| | specification for the intended function, the |
			| | flight crew and/or the controller |
			| | shall take appropriate action. |
			+--------------+-------------------------------------------------------+
			Figure 2: Requirements for ADS-C
	7. Characteristics of LDACS		7. Characteristics of LDACS
	LDACS will become one of several wireless access networks connecting		LDACS will become one of several wireless access networks connecting
	aircraft to the Aeronautical Telecommunications Network (ATN)		aircraft to the ATN implemented by the FCI and possibly ACARS/FANS
	implemented by the FCI and possibly ACARS/FANS networks [FAN2019].		networks [FAN2019].
			The current LDACS design is focused on the specification of layer 2.
			Achieving stringent the continuity, availability, and integrity
			requirements defined in [DO350A] will require the specification of
			layer 3 and above mechanisms (e.g. reliable crossover at the IP
			layer). Fault management mechanisms are similarly undefined. Input
			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), a Ground-Station		An LDACS sub-network contains an Access Router (AR), a Ground-Station
	Controller (GSC), and several Ground-Stations (GS), each of them		Controller (GSC), and several Ground-Stations (GS), each of them
	providing one LDACS radio cell.		providing one LDACS radio cell.
	User plane interconnection to the ATN is facilitated by the Access		User plane interconnection to the ATN is facilitated by the Access
	Router (AR) peering with an Air-to-Ground Router (A2G Router)		Router (AR) peering with an Air-to-Ground Router (A2G Router)
	connected to the ATN. It is up to implementer's choice to keep		connected to the ATN. It is up to implementer's choice to keep
	Access Router and Air-Ground Router functions separated, or to merge		Access Router and Air-Ground Router functions separated, or to merge
	them.		them.
	The internal control plane of an LDACS sub-network is managed by the		The internal control plane of an LDACS sub-network is managed by the
	GSC. An LDACS sub-network is illustrated in Figure 1.		GSC. An LDACS sub-network is illustrated in Figure 3.
	wireless user		wireless user
	link plane		link plane
	A--------------G-------------Access---A2G-----ATN		A--------------G-------------Access---A2G-----ATN
	S..............S Router Router		S..............S Router Router
	. control . |		. control . |
	. plane . |		. plane . |
	. . |		. . |
	GSC..............|		GSC..............|
	. |		. |
	. |		. |
	GS---------------+		GS---------------+
	Figure 1: LDACS sub-network with two GSs and one AS		Figure 3: LDACS sub-network with two GSs and one AS
	7.2. Topology		7.2. Topology
	LDACS operating in A2G mode is a cellular point-to-multipoint system.		LDACS operating in A2G mode is a cellular point-to-multipoint system.
	The A2G mode assumes a star-topology in each cell where Aircraft		The A2G mode assumes a star-topology in each cell where Aircraft
	Stations (AS) belonging to aircraft within a certain volume of space		Stations (AS) belonging to aircraft within a certain volume of space
	(the LDACS cell) is connected to the controlling GS. The LDACS GS is		(the LDACS cell) is connected to the controlling GS. The LDACS GS is
	a centralized instance that controls LDACS A2G communications within		a centralized instance that controls LDACS A2G communications within
	its cell. The LDACS GS can simultaneously support multiple bi-		its cell. The LDACS GS can simultaneously support multiple bi-
	directional communications to the ASs under its control. LDACS		directional communications to the ASs under its control. LDACS
	skipping to change at page 17, line 20 ¶		skipping to change at page 20, line 27 ¶
	The LDACS data link layer protocol running on top of the medium		The LDACS data link layer protocol running on top of the medium
	access sub-layer uses ARQ to provide reliable data transmission on		access sub-layer uses ARQ to provide reliable data transmission on
	layer 2.		layer 2.
	It employs selective repeat ARQ with transparent fragmentation and		It employs selective repeat ARQ with transparent fragmentation and
	reassembly to the resource allocation size to achieve low latency and		reassembly to the resource allocation size to achieve low latency and
	a low overhead without losing reliability. It ensures correct order		a low overhead without losing reliability. It ensures correct order
	of packet delivery without duplicates. In case of transmission		of packet delivery without duplicates. In case of transmission
	errors it identifies lost fragments with deterministic timers synced		errors it identifies lost fragments with deterministic timers synced
	to the medium access frame structure and initiates retransmission.		to the medium access frame structure and initiates retransmission.
	Additionally the priority mechanism of LDACS ensures the timely		Additionally, the priority mechanism of LDACS ensures the timely
	delivery of messages with high importance.		delivery of messages with high importance.
	8.2. Beyond Layer 2		8.2. Beyond Layer 2
	LDACS availability can be increased by appropriately deploying LDACS		LDACS availability can be increased by appropriately deploying LDACS
	infrastructure: This means proliferating the number of terrestrial		infrastructure: This means proliferating the number of terrestrial
	base stations. However, the scarcity of aeronautical spectrum for		base stations. However, the scarcity of aeronautical spectrum for
	data link communication (in the case of LDACS: tens of MHz in the		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		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		this quite hard. The deployment of a larger number of small cells is
	certainly possible, suffers, however, also from the scarcity of		certainly possible, suffers, however, also from the scarcity of
	spectrum. An additional constraint to take into account, is that		spectrum. An additional constraint to take into account, is that
	Distance Measuring Equipment (DME) is the primary user of the		Distance Measuring Equipment (DME) is the primary user of the
	aeronautical L-band. That is, any LDACS deployment has to take DME		aeronautical L-band. That is, any LDACS deployment has to take DME
	frequency planning into account, too.		frequency planning into account, too.
	The aeronautical community has therefore decided not to rely on a		The aeronautical community has therefore decided not to rely on a
	single communication system or frequency band. It is envisioned to		single communication system or frequency band. It is envisioned to
	have multiple independent data link technologies in the aircraft		have multiple independent data link technologies in the aircraft
	(e.g. terrestrial and SatCom).		(e.g. terrestrial and SatCom) in addition to legacy VHF voice.
	However, as of now no reliability and availability mechanisms that		However, as of now no reliability and availability mechanisms that
	could utilize the multi-link have been specified on Layer 3 and		could utilize the multi-link have been specified on Layer 3 and
	above.		above.
	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 system by ICAO.		radio systems as required for any safety relevant system by ICAO.
	skipping to change at page 18, line 16 ¶		skipping to change at page 21, line 21 ¶
	The protocol stack of LDACS is implemented in the AS, GS, and GSC: It		The protocol stack of LDACS is implemented in the AS, GS, and GSC: It
	consists of the Physical Layer (PHY) with five major functional		consists of the Physical Layer (PHY) with five major functional
	blocks above it. Four are placed in the Data Link Layer (DLL) of the		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),		AS and GS: (1) Medium Access Layer (MAC), (2) Voice Interface (VI),
	(3) Data Link Service (DLS), (4) LDACS Management Entity (LME). The		(3) Data Link Service (DLS), (4) LDACS Management Entity (LME). The
	last entity resides within the Sub-Network Layer: Sub-Network		last entity resides within the Sub-Network Layer: Sub-Network
	Protocol (SNP). The LDACS network is externally connected to voice		Protocol (SNP). The LDACS network is externally connected to voice
	units, radio control units, and the ATN Network Layer.		units, radio control units, and the ATN Network Layer.
	Figure 2 shows the protocol stack of LDACS as implemented in the AS		Figure 4 shows the protocol stack of LDACS as implemented in the AS
	and GS.		and GS.
	IPv6 Network Layer		IPv6 Network Layer
	|		|
	|		|
	+------------------+ +----+		+------------------+ +----+
	| SNP |--| | Sub-Network		| SNP |--| | Sub-Network
	| | | | Layer		| | | | Layer
	+------------------+ | |		+------------------+ | |
	| | LME|		| | LME|
	skipping to change at page 19, line 5 ¶		skipping to change at page 22, line 35 ¶
	|		|
	+--------------------------+		+--------------------------+
	| PHY | Physical Layer		| PHY | Physical Layer
	+--------------------------+		+--------------------------+
	|		|
	|		|
	((*))		((*))
	FL/RL radio channels		FL/RL radio channels
	separated by FDD		separated by FDD
	Figure 2: LDACS protocol stack in AS and GS		Figure 4: LDACS protocol stack in AS and GS
	9.1. Medium Access Control (MAC) Entity Services		9.1. Medium Access Control (MAC) Entity Services
	The MAC time framing service provides the frame structure necessary		The MAC time framing service provides the frame structure necessary
	to realize slot-based Time Division Multiplex (TDM) access on the		to realize slot-based Time Division Multiplex (TDM) access on the
	physical link. It provides the functions for the synchronization of		physical link. It provides the functions for the synchronization of
	the MAC framing structure and the PHY Layer framing. The MAC time		the MAC framing structure and the PHY Layer framing. The MAC time
	framing provides a dedicated time slot for each logical channel.		framing provides a dedicated time slot for each logical channel.
	The MAC Sub-Layer offers access to the physical channel to its		The MAC Sub-Layer offers access to the physical channel to its
	skipping to change at page 19, line 36 ¶		skipping to change at page 23, line 20 ¶
	In the FL, an SF contains a Broadcast Frame of duration 6.72 ms (56		In the FL, an SF contains a Broadcast Frame of duration 6.72 ms (56
	OFDM symbols) for the Broadcast Control Channel (BCCH), and four		OFDM symbols) for the Broadcast Control Channel (BCCH), and four
	Multi-Frames (MF), each of duration 58.32 ms (486 OFDM symbols).		Multi-Frames (MF), each of duration 58.32 ms (486 OFDM symbols).
	In the RL, each SF starts with a Random Access (RA) slot of length		In the RL, each SF starts with a Random Access (RA) slot of length
	6.72 ms with two opportunities for sending reverse link random access		6.72 ms with two opportunities for sending reverse link random access
	frames for the Random Access Channel (RACH), followed by four MFs.		frames for the Random Access Channel (RACH), followed by four MFs.
	These MFs have the same fixed duration of 58.32 ms as in the FL, but		These MFs have the same fixed duration of 58.32 ms as in the FL, but
	a different internal structure		a different internal structure
	Figure 3 and Figure 4 illustrates the LDACS frame structure.		Figure 5 and Figure 6 illustrates the LDACS frame structure.
	^		^
	| +------+------------+------------+------------+------------+		| +------+------------+------------+------------+------------+
	| 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 +------+------------+------------+------------+------------+
	n <---------------- Super-Frame (SF) - 240ms ---------------->		n <---------------- Super-Frame (SF) - 240ms ---------------->
	c		c
	y		y
	|		|
	----------------------------- Time ------------------------------>		----------------------------- Time ------------------------------>
	|		|
	Figure 3: LDACS super-frame structure		Figure 5: LDACS super-frame structure
	^		^
	| +-------------+------+-------------+		| +-------------+------+-------------+
	| FL | DCH | CCCH | DCH |		| FL | DCH | CCCH | DCH |
	F +-------------+------+-------------+		F +-------------+------+-------------+
	r <---- Multi-Frame (MF) - 58.32ms -->		r <---- Multi-Frame (MF) - 58.32ms -->
	e		e
	q +------+---------------------------+		q +------+---------------------------+
	u RL | DCCH | DCH |		u RL | DCCH | DCH |
	e +------+---------------------------+		e +------+---------------------------+
	n <---- Multi-Frame (MF) - 58.32ms -->		n <---- Multi-Frame (MF) - 58.32ms -->
	c		c
	y		y
	|		|
	----------------------------- Time ------------------------------>		----------------------------- Time ------------------------------>
	|		|
	Figure 4: LDACS multi-frame (MF) structure		Figure 6: LDACS multi-frame (MF) structure
	9.2. Data Link Service (DLS) Entity Services		9.2. Data Link Service (DLS) Entity Services
	The DLS provides acknowledged and unacknowledged (including broadcast		The DLS provides acknowledged and unacknowledged (including broadcast
	and packet mode voice) bi-directional exchange of user data. If user		and packet mode voice) bi-directional exchange of user data. If user
	data is transmitted using the acknowledged data link service, the		data is transmitted using the acknowledged data link service, the
	sending DLS entity will wait for an acknowledgement from the		sending DLS entity will wait for an acknowledgement from the
	receiver. If no acknowledgement is received within a specified time		receiver. If no acknowledgement is received within a specified time
	frame, the sender may automatically try to retransmit its data.		frame, the sender may automatically try to retransmit its data.
	However, after a certain number of failed retries, the sender will		However, after a certain number of failed retries, the sender will
	skipping to change at page 27, line 26 ¶		skipping to change at page 31, line 16 ¶
	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>.
	[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>.
	[RFC8462] Rooney, N. and S. Dawkins, Ed., "Report from the IAB
	Workshop on Managing Radio Networks in an Encrypted World
	(MaRNEW)", RFC 8462, DOI 10.17487/RFC8462, October 2018,
	<https://www.rfc-editor.org/info/rfc8462>.
	[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>.
	15. Informative References		15. Informative References
	[SCHN2016] Schneckenburger, N., Jost, T., Shutin, D., Walter, M.,		[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
	skipping to change at page 30, line 8 ¶		skipping to change at page 33, line 47 ¶
	[GNU2012] GNU Radio project, "GNU radio", August 2012,		[GNU2012] GNU Radio project, "GNU radio", August 2012,
	<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
			2 ATS Data Communications (Baseline 2 SPR Standard)", May
			2016, <https://standards.globalspec.com/std/10003192/rtca-
			do-350-volume-1-2>.
	[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-
	thubert-raw-technologies-05, 18 May 2020,		thubert-raw-technologies-05, 18 May 2020,
	<https://tools.ietf.org/html/draft-thubert-raw-		<https://tools.ietf.org/html/draft-thubert-raw-
	technologies-05>.		technologies-05>.
	[RAW-USE-CASES]		[RAW-USE-CASES]
	Papadopoulos, G., Thubert, P., Theoleyre, F., and C.		Papadopoulos, G., Thubert, P., Theoleyre, F., and C.
End of changes. 27 change blocks.
	68 lines changed or deleted		153 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/