< draft-ietf-raw-ldacs-00.txt		draft-ietf-raw-ldacs-01.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: 23 April 2021 C. Schmitt, Ed.		Expires: 25 April 2021 C. Schmitt, Ed.
	Research Institute CODE, UniBwM		Research Institute CODE, UniBwM
	20 October 2020		22 October 2020
	L-band Digital Aeronautical Communications System (LDACS)		L-band Digital Aeronautical Communications System (LDACS)
	draft-ietf-raw-ldacs-00		draft-ietf-raw-ldacs-01
	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 23 April 2021.		This Internet-Draft will expire on 25 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 29 ¶		skipping to change at page 2, line 29 ¶
	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 . . . . . . . . . . . . . . . . . . . 9		5.1.3. High Data Rates . . . . . . . . . . . . . . . . . . . 9
	5.2. Application . . . . . . . . . . . . . . . . . . . . . . . 9		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 . . . . . . . . . . . . . . . . . . . 10		5.2.3. Flight Guidance . . . . . . . . . . . . . . . . . . . 10
	5.2.4. Business Communication of Airlines . . . . . . . . . 11		5.2.4. Business Communication of Airlines . . . . . . . . . 11
	5.2.5. LDACS Navigation . . . . . . . . . . . . . . . . . . 11		5.2.5. LDACS Navigation . . . . . . . . . . . . . . . . . . 11
	6. Requirements to LDACS . . . . . . . . . . . . . . . . . . . . 12		6. Requirements to LDACS . . . . . . . . . . . . . . . . . . . . 12
	7. Characteristics of LDACS . . . . . . . . . . . . . . . . . . 15		7. Characteristics of LDACS . . . . . . . . . . . . . . . . . . 13
	7.1. LDACS Sub-Network . . . . . . . . . . . . . . . . . . . . 16		7.1. LDACS Sub-Network . . . . . . . . . . . . . . . . . . . . 13
	7.2. Topology . . . . . . . . . . . . . . . . . . . . . . . . 16		7.2. Topology . . . . . . . . . . . . . . . . . . . . . . . . 14
	7.3. LDACS Physical Layer . . . . . . . . . . . . . . . . . . 17		7.3. LDACS Physical Layer . . . . . . . . . . . . . . . . . . 15
	7.4. LDACS Data Link Layer . . . . . . . . . . . . . . . . . . 17		7.4. LDACS Data Link Layer . . . . . . . . . . . . . . . . . . 15
	7.5. LDACS Mobility . . . . . . . . . . . . . . . . . . . . . 17		7.5. LDACS Mobility . . . . . . . . . . . . . . . . . . . . . 15
	8. Reliability and Availability . . . . . . . . . . . . . . . . 18		8. Reliability and Availability . . . . . . . . . . . . . . . . 15
	8.1. Layer 2 . . . . . . . . . . . . . . . . . . . . . . . . . 18		8.1. Layer 2 . . . . . . . . . . . . . . . . . . . . . . . . . 16
	8.2. Beyond Layer 2 . . . . . . . . . . . . . . . . . . . . . 20		8.2. Beyond Layer 2 . . . . . . . . . . . . . . . . . . . . . 18
	9. Protocol Stack . . . . . . . . . . . . . . . . . . . . . . . 21		9. Protocol Stack . . . . . . . . . . . . . . . . . . . . . . . 19
	9.1. Medium Access Control (MAC) Entity Services . . . . . . . 22		9.1. Medium Access Control (MAC) Entity Services . . . . . . . 20
	9.2. Data Link Service (DLS) Entity Services . . . . . . . . . 24		9.2. Data Link Service (DLS) Entity Services . . . . . . . . . 21
	9.3. Voice Interface (VI) Services . . . . . . . . . . . . . . 25		9.3. Voice Interface (VI) Services . . . . . . . . . . . . . . 22
	9.4. LDACS Management Entity (LME) Services . . . . . . . . . 25		9.4. LDACS Management Entity (LME) Services . . . . . . . . . 22
	9.5. Sub-Network Protocol (SNP) Services . . . . . . . . . . . 25		9.5. Sub-Network Protocol (SNP) Services . . . . . . . . . . . 22
	10. Security Considerations . . . . . . . . . . . . . . . . . . . 25		10. Security Considerations . . . . . . . . . . . . . . . . . . . 23
	10.1. Reasons for Wireless Digital Aeronautical		10.1. Reasons for Wireless Digital Aeronautical
	Communications . . . . . . . . . . . . . . . . . . . . . 25		Communications . . . . . . . . . . . . . . . . . . . . . 23
	10.2. Requirements for LDACS . . . . . . . . . . . . . . . . . 26		10.2. Requirements for LDACS . . . . . . . . . . . . . . . . . 24
	10.3. Security Objectives for LDACS . . . . . . . . . . . . . 27		10.3. Security Objectives for LDACS . . . . . . . . . . . . . 24
	10.4. Security Functions for LDACS . . . . . . . . . . . . . . 27		10.4. Security Functions for LDACS . . . . . . . . . . . . . . 25
	10.5. Security Architectural Details for LDACS . . . . . . . . 28		10.5. Security Architectural Details for LDACS . . . . . . . . 25
	10.5.1. Entities in LDACS Security Model . . . . . . . . . . 28		10.5.1. Entities in LDACS Security Model . . . . . . . . . . 25
	10.5.2. Matter of LDACS Entity Identification . . . . . . . 28		10.5.2. Matter of LDACS Entity Identification . . . . . . . 25
	10.5.3. Matter of LDACS Entity Authentication and Key		10.5.3. Matter of LDACS Entity Authentication and Key
	Negotiation . . . . . . . . . . . . . . . . . . . . . 29		Negotiation . . . . . . . . . . . . . . . . . . . . . 26
	10.5.4. Matter of LDACS Message-in-transit Confidentiality,		10.5.4. Matter of LDACS Message-in-transit Confidentiality,
	Integrity and Authenticity . . . . . . . . . . . . . 29		Integrity and Authenticity . . . . . . . . . . . . . 27
	10.6. Security Architecture for LDACS . . . . . . . . . . . . 30		10.6. Security Architecture for LDACS . . . . . . . . . . . . 27
	11. Privacy Considerations . . . . . . . . . . . . . . . . . . . 30		11. Privacy Considerations . . . . . . . . . . . . . . . . . . . 27
	12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 30		12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 27
	13. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 30		13. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 27
	14. Normative References . . . . . . . . . . . . . . . . . . . . 30		14. Normative References . . . . . . . . . . . . . . . . . . . . 28
	15. Informative References . . . . . . . . . . . . . . . . . . . 31		15. Informative References . . . . . . . . . . . . . . . . . . . 28
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 34		Appendix A. Selected Information from DO-350A . . . . . . . . . 31
			Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 33
	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 13, line 26 ¶		skipping to change at page 13, line 26 ¶
	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		In addition to the 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 CSP (Communication Service Provider)
	scope.		scope.
	The upcoming Figures Figure 1 and Figure 2 summarize the main		Continuity, availability, and integrity requirements are defined in
	seetings based on volume 1 Table 5-14, and Table 6-13 defined in		[DO350A] volume 1 Table 5-14, and Table 6-13. Appendix A presents
	[DO350A]. In a similar vein, requirements to fault management are		the required information.
	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		In a similar vein, requirements to fault management are defined in
			the same tables.
	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 ATN implemented by the FCI and possibly ACARS/FANS		aircraft to the ATN implemented by the FCI and possibly ACARS/FANS
	networks [FAN2019].		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 2.
	Achieving stringent the continuity, availability, and integrity		Achieving stringent the continuity, availability, and integrity
	skipping to change at page 16, line 18 ¶		skipping to change at page 14, line 12 ¶
	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 3.		GSC. An LDACS sub-network is illustrated in Figure 1.
	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 3: LDACS sub-network with two GSs and one AS		Figure 1: 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 21, line 21 ¶		skipping to change at page 19, line 16 ¶
	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 4 shows the protocol stack of LDACS as implemented in the AS		Figure 2 shows the protocol stack of LDACS as implemented in the AS
	and GS.		and GS.
	IPv6 Network Layer		IPv6 Network Layer
	|		|
	|		|
	+------------------+ +----+		+------------------+ +----+
	| SNP |--| | Sub-Network		| SNP |--| | Sub-Network
	| | | | Layer		| | | | Layer
	+------------------+ | |		+------------------+ | |
	| | LME|		| | LME|
	skipping to change at page 22, line 35 ¶		skipping to change at page 20, line 5 ¶
	|		|
	+--------------------------+		+--------------------------+
	| PHY | Physical Layer		| PHY | Physical Layer
	+--------------------------+		+--------------------------+
	|		|
	|		|
	((*))		((*))
	FL/RL radio channels		FL/RL radio channels
	separated by FDD		separated by FDD
	Figure 4: LDACS protocol stack in AS and GS		Figure 2: 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 23, line 20 ¶		skipping to change at page 20, line 36 ¶
	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 5 and Figure 6 illustrates the LDACS frame structure.		Figure 3 and Figure 4 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 5: LDACS super-frame structure		Figure 3: 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 6: LDACS multi-frame (MF) structure		Figure 4: 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 34, line 20 ¶		skipping to change at page 31, line 28 ¶
	<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.
	Bernardos, "RAW use cases", Work in Progress, Internet-		Bernardos, "RAW use cases", Work in Progress, Internet-
	Draft, draft-bernardos-raw-use-cases-04, 13 July 2020,		Draft, draft-bernardos-raw-use-cases-04, 13 July 2020,
	<https://tools.ietf.org/html/draft-bernardos-raw-use-		<https://tools.ietf.org/html/draft-bernardos-raw-use-
	cases-04>.		cases-04>.
			Appendix A. Selected Information from DO-350A
			+--------------+---------------+
			| | ECP 130 |
			+--------------+-------+-------+
			| Parameter | ET | TT95% |
			+--------------+-------+-------+
			| Transaction | 130 | 67 |
			| Time (sec) | | |
			+--------------+-------+-------+
			| Continuity | 0.999 | 0.95 |
			+--------------+-------+-------+
			| Availability | 0.989 |
			+--------------+---------------+
			| Integrity | 1E-5 per FH |
			+--------------+---------------+
			Figure 5: CPDLC Requirements for ECP
			+--------------+--------------------+---------------+
			| | RCP 240 | RCP 400 |
			+--------------+----------+---------+-------+-------+
			| Parameter | ET | TT95% | ET | TT95% |
			+--------------+----------+---------+-------+-------+
			| Transaction | 240 | 210 | 400 | 350 |
			| Time (sec) | | | | |
			+--------------+----------+---------+-------+-------+
			| Continuity | 0.999 | 0.95 | 0.999 | 0.95 |
			+--------------+----------+---------+-------+-------+
			| Availability | 0.989 (safety) | 0.989 |
			| | 0.9899 (efficiency)| |
			+--------------+--------------------+---------------+
			| Integrity | 1E-5 per FH | 1E-5 per FH |
			+--------------+--------------------+---------------+
			Figure 6: CPDLC Requirements for RCP
			RCP Monitoring and Alerting Criteria in case of CPDLC:
			- 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.
			+------------+---------------+--------------------+---------------+
			| | RSP 160 | RSP 180 | RSP 400 |
			+------------+-------+-------+----------+---------+-------+-------+
			| Parameter | OT | DT95% | OT | DT95% | OT | DT95% |
			+------------+-------+-------+----------+---------+-------+-------+
			| Trans- | | | | | | |
			| action | 160 | 90 | 180 | 90 | 400 | 300 |
			| Time (sec) | | | | | | |
			+------------+-------+-------+----------+---------+-------+-------+
			| Continuity | 0.999 | 0.95 | 0.999 | 0.95 | 0.999 | 0.95 |
			+------------+-------+-------+----------+---------+-------+-------+
			| Avail- | 0.989 | 0.989 (safety) | 0.989 |
			| ability | | 0.9899 (efficiency)| |
			+------------+---------------+--------------------+---------------+
			| Integrity | 1E-5 per FH | 1E-5 per FH | 1E-5 per FH |
			+------------+---------------+--------------------+---------------+
			Figure 7: ADS-C Requirements
			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.
	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. 18 change blocks.
	106 lines changed or deleted		122 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/