idnits 2.17.00 (12 Aug 2021) /tmp/idnits48893/draft-ietf-raw-ldacs-09.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == There is 1 instance of lines with non-ascii characters in the document. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (22 October 2021) is 211 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'RFC3610' is defined on line 1280, but no explicit reference was found in the text == Unused Reference: 'RFC4493' is defined on line 1292, but no explicit reference was found in the text == Unused Reference: 'RFC5280' is defined on line 1296, but no explicit reference was found in the text == Unused Reference: 'RFC5869' is defined on line 1302, but no explicit reference was found in the text == Unused Reference: 'RFC7236' is defined on line 1320, but no explicit reference was found in the text == Unused Reference: 'FAN2019' is defined on line 1351, but no explicit reference was found in the text == Unused Reference: 'EURO2021' is defined on line 1514, but no explicit reference was found in the text -- Obsolete informational reference (is this intentional?): RFC 6347 (Obsoleted by RFC 9147) == Outdated reference: A later version (-05) exists of draft-ietf-raw-technologies-04 == Outdated reference: A later version (-05) exists of draft-ietf-raw-use-cases-03 == Outdated reference: A later version (-07) exists of draft-haindl-lisp-gb-atn-06 == Outdated reference: A later version (-17) exists of draft-ietf-rtgwg-atn-bgp-11 Summary: 0 errors (**), 0 flaws (~~), 13 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 RAW N. Maeurer, Ed. 3 Internet-Draft T. Graeupl, Ed. 4 Intended status: Informational German Aerospace Center (DLR) 5 Expires: 25 April 2022 C. Schmitt, Ed. 6 Research Institute CODE, UniBwM 7 22 October 2021 9 L-band Digital Aeronautical Communications System (LDACS) 10 draft-ietf-raw-ldacs-09 12 Abstract 14 This document gives an overview of the architecture of the L-band 15 Digital Aeronautical Communications System (LDACS), which provides a 16 secure, scalable and spectrum efficient terrestrial data link for 17 civil aviation. LDACS is a scheduled, reliable multi-application 18 cellular broadband system with support for IPv6. LDACS provides a 19 data link for IPv6 network-based aircraft guidance. High reliability 20 and availability for IP connectivity over LDACS, as well as security, 21 are therefore essential. 23 Status of This Memo 25 This Internet-Draft is submitted in full conformance with the 26 provisions of BCP 78 and BCP 79. 28 Internet-Drafts are working documents of the Internet Engineering 29 Task Force (IETF). Note that other groups may also distribute 30 working documents as Internet-Drafts. The list of current Internet- 31 Drafts is at https://datatracker.ietf.org/drafts/current/. 33 Internet-Drafts are draft documents valid for a maximum of six months 34 and may be updated, replaced, or obsoleted by other documents at any 35 time. It is inappropriate to use Internet-Drafts as reference 36 material or to cite them other than as "work in progress." 38 This Internet-Draft will expire on 25 April 2022. 40 Copyright Notice 42 Copyright (c) 2021 IETF Trust and the persons identified as the 43 document authors. All rights reserved. 45 This document is subject to BCP 78 and the IETF Trust's Legal 46 Provisions Relating to IETF Documents (https://trustee.ietf.org/ 47 license-info) in effect on the date of publication of this document. 48 Please review these documents carefully, as they describe your rights 49 and restrictions with respect to this document. Code Components 50 extracted from this document must include Simplified BSD License text 51 as described in Section 4.e of the Trust Legal Provisions and are 52 provided without warranty as described in the Simplified BSD License. 54 Table of Contents 56 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 57 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 58 3. Motivation and Use Cases . . . . . . . . . . . . . . . . . . 6 59 3.1. Voice Communications Today . . . . . . . . . . . . . . . 7 60 3.2. Data Communications Today . . . . . . . . . . . . . . . . 7 61 4. Provenance and Documents . . . . . . . . . . . . . . . . . . 8 62 5. Applicability . . . . . . . . . . . . . . . . . . . . . . . . 9 63 5.1. Advances Beyond the State-of-the-Art . . . . . . . . . . 9 64 5.1.1. Priorities . . . . . . . . . . . . . . . . . . . . . 9 65 5.1.2. Security . . . . . . . . . . . . . . . . . . . . . . 9 66 5.1.3. High Data Rates . . . . . . . . . . . . . . . . . . . 10 67 5.2. Application . . . . . . . . . . . . . . . . . . . . . . . 10 68 5.2.1. Air/Ground Multilink . . . . . . . . . . . . . . . . 10 69 5.2.2. Air/Air Extension for LDACS . . . . . . . . . . . . . 10 70 5.2.3. Flight Guidance . . . . . . . . . . . . . . . . . . . 11 71 5.2.4. Business Communications of Airlines . . . . . . . . . 12 72 5.2.5. LDACS-based Navigation . . . . . . . . . . . . . . . 12 73 6. Requirements . . . . . . . . . . . . . . . . . . . . . . . . 12 74 7. Characteristics . . . . . . . . . . . . . . . . . . . . . . . 14 75 7.1. LDACS Sub-Network . . . . . . . . . . . . . . . . . . . . 14 76 7.2. Topology . . . . . . . . . . . . . . . . . . . . . . . . 15 77 7.3. LDACS Protocol Stack . . . . . . . . . . . . . . . . . . 15 78 7.3.1. LDACS Physical Layer . . . . . . . . . . . . . . . . 17 79 7.3.2. LDACS Data Link Layer . . . . . . . . . . . . . . . . 17 80 7.3.3. LDACS Sub-Network Layer and Protocol Services . . . . 19 81 7.4. LDACS Mobility . . . . . . . . . . . . . . . . . . . . . 19 82 8. Reliability and Availability . . . . . . . . . . . . . . . . 19 83 8.1. Below Layer 1 . . . . . . . . . . . . . . . . . . . . . . 19 84 8.2. Layer 1 and 2 . . . . . . . . . . . . . . . . . . . . . . 19 85 8.3. Beyond Layer 2 . . . . . . . . . . . . . . . . . . . . . 23 86 9. Security . . . . . . . . . . . . . . . . . . . . . . . . . . 23 87 9.1. Security in Wireless Digital Aeronautical 88 Communications . . . . . . . . . . . . . . . . . . . . . 24 89 9.2. LDACS Requirements . . . . . . . . . . . . . . . . . . . 25 90 9.3. LDACS Security Objectives . . . . . . . . . . . . . . . . 25 91 9.4. LDACS Security Functions . . . . . . . . . . . . . . . . 26 92 9.5. LDACS Security Architecture . . . . . . . . . . . . . . . 26 93 9.5.1. Entities . . . . . . . . . . . . . . . . . . . . . . 26 94 9.5.2. Entity Identification . . . . . . . . . . . . . . . . 27 95 9.5.3. Entity Authentication and Key Establishment . . . . . 27 96 9.5.4. Message-in-transit Confidentiality, Integrity and 97 Authenticity . . . . . . . . . . . . . . . . . . . . 28 98 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 28 99 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 28 100 12. Normative References . . . . . . . . . . . . . . . . . . . . 28 101 13. Informative References . . . . . . . . . . . . . . . . . . . 29 102 Appendix A. Selected Information from DO-350A . . . . . . . . . 35 103 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 37 105 1. Introduction 107 One of the main pillars of the modern Air Traffic Management (ATM) 108 system is the existence of a communications infrastructure that 109 enables efficient aircraft control and safe aircraft separation in 110 all phases of flight. Current systems are technically mature but 111 suffering from the Very High Frequency (VHF) band's increasing 112 saturation in high- density areas and the limitations posed by 113 analogue radio communications. Therefore, aviation globally, and the 114 European Union (EU) in particular, strives for a sustainable 115 modernization of the aeronautical communications infrastructure. 117 This modernization is realized in two steps: (1) the transition of 118 communications datalinks from analogue to digital technologies and, 119 (2) the introduction of IPv6 based networking protocols in 120 aeronautical networks [RFC4291], [RFC7136], [ICAO2015]. 122 Step (1) is realized via ATM communications transitioning from 123 analogue VHF voice [KAMA2010] to more spectrum efficient digital data 124 communication. For terrestrial communications the European ATM 125 Master Plan foresees this transition to be realized by the 126 development of the L-band Digital Aeronautical Communications System 127 (LDACS). Since central Europe has been identified as the area of the 128 world, that suffers the most from increased saturation of the VHF 129 band, the initial roll-out of LDACS will likely start there, and 130 continue to other increasingly saturated zones as the east- and west- 131 cost of the US and parts of Asia [ICAO2018]. 133 Technically LDACS enables IPv6 based air- ground communication 134 related to aviation safety and regularity of flight [ICAO2015]. 135 Passenger communication and similar services are not supported, since 136 only communications related to "safety and regularity of flight" are 137 permitted in protected aviation frequency bands. The particular 138 challenge is that no additional frequencies can be made available for 139 terrestrial aeronautical communication. It was thus necessary to 140 develop co-existence mechanism/procedures to enable the interference 141 free operation of LDACS in parallel with other aeronautical services/ 142 systems in the protected frequency band. Since LDACS will be used 143 for aircraft guidance, high reliability and availability for IP 144 connectivity over LDACS are essential. 146 Step (2) is a strategy for the worldwide roll-out of IPv6 capable 147 digital aeronautical inter-networking. This is called the 148 Aeronautical Telecommunications Network (ATN)/Internet Protocol Suite 149 (IPS) (hence, ATN/IPS). It is specified in the International Civil 150 Aviation Organization (ICAO) document Doc 9896 [ICAO2015], the Radio 151 Technical Commission for Aeronautics (RTCA) document DO-379 152 [RTCA2019], the European Organization for Civil Aviation Equipment 153 (EUROCAE) document ED-262 [EURO2019], and the Aeronautical Radio 154 Incorporated (ARINC) document P858 [ARI2021]. LDACS is subject to 155 these regulations since it provides access subnets to the ATN/IPS. 157 ICAO has chosen IPv6 as basis for the ATN/IPS mostly for historical 158 reasons, since a previous architecture based on ISO/OSI protocols, 159 the ATN/OSI, failed in the market place. 161 In the context of safety-related communications, LDACS will play a 162 major role in future ATM. ATN/IPS datalinks will provide diversified 163 terrestrial and space-based connectivity in a multi-link concept, 164 called the Future Communications Infrastructure (FCI) [VIR2021]. 165 From a technical point of view the FCI will realize airborne multi- 166 homed IPv6 networks connected to a global ground network via at least 167 two independent communication technologies. This is considered in 168 more detail in related IETF work in progress [I-D.haindl-lisp-gb-atn] 169 [I-D.ietf-rtgwg-atn-bgp]. 171 In the context of WG-RAW, developing options, such as intelligent 172 switching between datalinks, for reliably delivering content from and 173 to endpoints, is foreseen. As LDACS is part of such a concept, the 174 work of RAW is immediately applicable. In general, with the 175 aeronautical communications system transitioning to ATN/IPS, and data 176 being transported via IPv6, closer cooperation and collaboration 177 between the aeronautical and IETF community is desirable. 179 LDACS standardization within the framework of ICAO started in 180 December 2016. The ICAO standardization group has produced an 181 initial Standards and Recommended Practices (SARPS) document 182 [ICA2018]. It defines the general characteristics of LDACS. The 183 ICAO standardization group plans to produce an ICAO technical manual 184 - the ICAO equivalent to a technical standard - within the next 185 years. Generally, the group is open to input from all sources and 186 encourages cooperation between the aeronautical and the IETF 187 community. 189 2. Terminology 191 The following terms are used in the context of RAW in this document: 193 A/A Air/Air 194 A/G Air/Ground 195 A2G Air-to-Ground 196 ACARS Aircraft Communications Addressing and Reporting System 197 ADS-B Automatic Dependent Surveillance - Broadcast 198 ADS-C Automatic Dependent Surveillance - Contract 199 AeroMACS Aeronautical Mobile Airport Communications System 200 ANSP Air Traffic Network Service Provider 201 AOC Aeronautical Operational Control 202 AR Access Router 203 ARINC Aeronautical Radio, Incorporated 204 ARQ Automatic Repeat reQuest 205 AS Aircraft Station 206 ATC Air Traffic Control 207 ATM Air Traffic Management 208 ATN Aeronautical Telecommunication Network 209 ATS Air Traffic Service 210 BCCH Broadcast Channel 211 CCCH Common Control Channel 212 CM Context Management 213 CNS Communication Navigation Surveillance 214 COTS Commercial Off-The-Shelf 215 CPDLC Controller Pilot Data Link Communications 216 CRL Certificate Revocation List 217 CSP Communications Service Provider 218 DCCH Dedicated Control Channel 219 DCH Data Channel 220 DiffServ Differentiated Services 221 DLL Data Link Layer 222 DLS Data Link Service 223 DME Distance Measuring Equipment 224 DSB-AM Double Side-Band Amplitude Modulation 225 DTLS Datagram Transport Layer Security 226 EUROCAE European Organization for Civil Aviation Equipment 227 FAA Federal Aviation Administration 228 FCI Future Communications Infrastructure 229 FDD Frequency Division Duplex 230 FL Forward Link 231 GANP Global Air Navigation Plan 232 GBAS Ground Based Augmentation System 233 GNSS Global Navigation Satellite System 234 GS Ground-Station 235 G2A Ground-to-Air 236 HF High Frequency 237 ICAO International Civil Aviation Organization 238 IP Internet Protocol 239 IPS Internet Protocol Suite 240 kbit/s kilobit per second 241 LDACS L-band Digital Aeronautical Communications System 242 LLC Logical Link Control 243 LME LDACS Management Entity 244 MAC Medium Access Control 245 MF Multi Frame 246 OFDM Orthogonal Frequency-Division Multiplexing 247 OFDMA Orthogonal Frequency-Division Multiplexing Access 248 OSI Open Systems Interconnection 249 PHY Physical Layer 250 QPSK Quadrature Phase-Shift Keying 251 RACH Random Access Channel 252 RL Reverse Link 253 RTCA Radio Technical Commission for Aeronautics 254 SARPS Standards and Recommended Practices 255 SDR Software Defined Radio 256 SESAR Single European Sky ATM Research 257 SF Super-Frame 258 SNP Sub-Network Protocol 259 VDLm2 VHF Data Link mode 2 260 VHF Very High Frequency 261 VI Voice Interface 263 3. Motivation and Use Cases 265 Aircraft are currently connected to Air Traffic Control (ATC) and 266 Aeronautical Operational Control (AOC) services via voice and data 267 communications systems through all phases of flight. ATC refers to 268 communication for flight guidance. AOC is a generic term referring 269 to the business communication of airlines. It refers to the mostly 270 proprietary exchange of data between the aircraft of the airline, its 271 operation centers, and its service partners. ARINC document 633 was 272 developed and first released in 2007 [ARI2019] with the goal to 273 standardize these messages for interoperability, e.g., messages 274 between the airline and fueling or de-icing companies. Within the 275 airport terminal, connectivity is focused on high bandwidth 276 communications, while during en-route, high reliability, robustness, 277 and range is the main focus. Voice communications may use the same 278 or different equipment as data communications systems. In the 279 following, the main differences between voice and data communications 280 capabilities are summarized. The assumed use cases for LDACS 281 complements the list of use cases stated in [RAW-USE-CASES] and the 282 list of reliable and available wireless technologies presented in 283 [RAW-TECHNOS]. 285 3.1. Voice Communications Today 287 Voice links are used for Air/Ground (A/G) and Air/Air (A/A) 288 communications. The communications equipment is either ground-based 289 working in the High Frequency (HF) or VHF frequency band or 290 satellite-based. All VHF and HF voice communications are operated 291 via open broadcast channels without authentication, encryption or 292 other protective measures. The use of well-proven communications 293 procedures via broadcast channels can help to enhance the safety of 294 communications. The main voice communications media is still the 295 analogue VHF Double Side-Band Amplitude Modulation (DSB-AM) 296 communications technique, supplemented by HF single side-band 297 amplitude modulation and satellite communications for remote and 298 oceanic regions. DSB-AM has been in use since 1948, works reliably 299 and safely, and uses low-cost communication equipment. These are the 300 main reasons why VHF DSB-AM communications are still in use, and it 301 is likely that this technology will remain in service for many more 302 years. This however, results in current operational limitations and 303 impediments in deploying new ATM applications, such as flight-centric 304 operation with point-to-point communications between pilots and air 305 traffic control officers. [BOE2019] 307 3.2. Data Communications Today 309 Like for voice, data communications into the cockpit, are currently 310 provided by ground-based equipment operating either on HF or VHF 311 radio bands or by legacy satellite systems. All these communication 312 systems are using narrowband radio channels with a data throughput 313 capacity in the order of kilobits per second. While the aircraft is 314 on ground, some additional communications systems are available, like 315 the Aeronautical Mobile Airport Communications System (AeroMACS) or 316 public cellular networks, operating in the Airport (APT) domain and 317 able to deliver broadband communications capability. [BOE2019] 319 The data communications networks, used for the transmission of data 320 relating to the safety and regularity of flight, must be strictly 321 isolated from those providing entertainment services to passengers. 323 This leads to a situation that the flight crews are supported by 324 narrowband services during flight while passengers have access to 325 inflight broadband services. The current HF and VHF data links 326 cannot provide broadband services now or in the future, due to the 327 lack of available spectrum. This technical shortcoming is becoming a 328 limitation to enhanced ATM operations, such as trajectory-based 329 operations and 4D trajectory negotiations. [BOE2019] 331 Satellite-based communications are currently under investigation and 332 enhanced capabilities are under development which will be able to 333 provide inflight broadband services and communications supporting the 334 safety and regularity of flight. In parallel the ground-based 335 broadband data link technology LDACS is being standardized by ICAO 336 and has recently shown its maturity during flight tests [MAE20211] 337 [BEL2021]. The LDACS technology is scalable, secure and spectrum 338 efficient and provides significant advantages to the users and 339 service providers. It is expected that both - satellite systems and 340 LDACS - will be deployed to support the future aeronautical 341 communication needs as envisaged by the ICAO Global Air Navigation 342 Plan (GNAP). [BOE2019] 344 4. Provenance and Documents 346 The development of LDACS has already made substantial progress in the 347 Single European Sky ATM Research (SESAR) framework and is currently 348 being continued in the follow-up program SESAR2020 [RIH2018]. A key 349 objective of these activities is to develop, implement and validate a 350 modern aeronautical data link able to evolve with aviation needs over 351 long-term. To this end, an LDACS specification has been produced 352 [GRA2019] and is continuously updated; transmitter demonstrators were 353 developed to test the spectrum compatibility of LDACS with legacy 354 systems operating in the L-band [SAJ2014]; and the overall system 355 performance was analyzed by computer simulations, indicating that 356 LDACS can fulfil the identified requirements [GRA2011]. 358 Up to now LDACS standardization has been focused on the development 359 of the physical layer and the data link layer. Only recently have 360 higher layers have come into the focus of the LDACS development 361 activities. There is currently no "IPv6 over LDACS" specification 362 publicly available; however, SESAR2020 has started the testing of 363 IPv6-based LDACS testbeds. 365 The IPv6 architecture for the aeronautical telecommunication network 366 is called the FCI. The FCI will support quality of service, 367 diversity, and mobility under the umbrella of the "multi-link 368 concept". This work is led by ICAO Communication Panel working group 369 WG-I. 371 In addition to standardization activities several industrial LDACS 372 prototypes have been built. One set of LDACS prototypes has been 373 evaluated in flight trials confirming the theoretical results 374 predicting the system performance [GRA2018] [MAE20211] [BEL2021]. 376 5. Applicability 378 LDACS is a multi-application cellular broadband system capable of 379 simultaneously providing various kinds of Air Traffic Services (ATS) 380 including ATS-B3, and AOC communications services from deployed 381 Ground-Stations (GS). The physical layer and data link layer of 382 LDACS are optimized for controller-pilot data link communications, 383 but the system also supports digital air-ground voice communications. 385 LDACS supports communications in all airspaces (airport, terminal 386 maneuvering area, and en-route), and on the airport surface. The 387 physical LDACS cell coverage is effectively de-coupled from the 388 operational coverage required for a particular service. This is new 389 in aeronautical communications. Services requiring wide-area 390 coverage can be installed at several adjacent LDACS cells. The 391 handover between the involved LDACS cells is seamless, automatic, and 392 transparent to the user. Therefore, the LDACS communications concept 393 enables the aeronautical communication infrastructure to support 394 future dynamic airspace management concepts. 396 5.1. Advances Beyond the State-of-the-Art 398 LDACS offers several capabilities, not yet provided in contemporarily 399 deployed aeronautical communications systems. 401 5.1.1. Priorities 403 LDACS is able to manage service priorities, an important feature not 404 available in some of the current data link deployments. Thus, LDACS 405 guarantees bandwidth availability, low latency, and high continuity 406 of service for safety critical ATS applications while simultaneously 407 accommodating less safety-critical AOC services. 409 5.1.2. Security 411 LDACS is a secure data link with built-in security mechanisms. It 412 enables secure data communications for ATS and AOC services, 413 including secured private communications for aircraft operators and 414 Air traffic Network Service Providers (ANSP). This includes concepts 415 for key and trust management, mutual authentication and key 416 establishment protocols, key derivation measures, user and control 417 message-in-transit protection, secure logging and availability and 418 robustness measures [MAE20182] [MAE2021]. 420 5.1.3. High Data Rates 422 The user data rate of LDACS is 315 kbit/s to 1428 kbit/s on the 423 Forward Link (FL) for the Ground-to-Air (G2A) connection, and 294 424 kbit/s to 1390 kbit/s on the Reverse Link (RL) for the Air-to-Ground 425 (A2G) connection, depending on coding and modulation. This is up to 426 two orders of magnitude greater than current terrestrial digital 427 aeronautical communications systems, such as the VHF Data Link mode 2 428 (VDLm2), provide [ICAO2019] [GRA2019]. 430 5.2. Application 432 LDACS will be used by several aeronautical applications ranging from 433 enhanced communications protocol stacks (multi-homed mobile IPv6 434 networks in the aircraft and potentially ad-hoc networks between 435 aircraft) to broadcast communication applications (sending Ground 436 Based Augmentation System (GBAS) correction data) and integration 437 with other service domains (using the communications signal for 438 navigation) [MAE20211]. 440 5.2.1. Air/Ground Multilink 442 It is expected that LDACS, together with upgraded satellite-based 443 communications systems, will be deployed within the FCI and 444 constitute one of the main components of the multilink concept within 445 the FCI. 447 Both technologies, LDACS and satellite systems, have their specific 448 benefits and technical capabilities which complement each other. 449 Especially, satellite systems are well-suited for large coverage 450 areas with less dense air traffic, e.g. oceanic regions. LDACS is 451 well-suited for dense air traffic areas, e.g., continental areas or 452 hot-spots around airports and terminal airspace. In addition, both 453 technologies offer comparable data link capacity and, thus, are well- 454 suited for redundancy, mutual back-up, or load balancing. 456 Technically the FCI multilink concept will be realized by multi- 457 homed mobile IPv6 networks in the aircraft. The related protocol 458 stack is currently under development by ICAO, within SESAR, and the 459 IETF [I-D.haindl-lisp-gb-atn] [I-D.ietf-rtgwg-atn-bgp]. 461 5.2.2. Air/Air Extension for LDACS 463 A potential extension of the multi-link concept is its extension to 464 the integration of ad-hoc networks between aircraft. 466 Direct A/A communication between aircraft in terms of ad-hoc data 467 networks are currently considered a research topic since there is no 468 immediate operational need for it, although several possible use 469 cases are discussed (Automatic Dependent Surveillance - Broadcast 470 (ADS-B), digital voice, wake vortex warnings, and trajectory 471 negotiation) [BEL2019]. It should also be noted, that currently 472 deployed analog VHF voice radios support direct voice communication 473 between aircraft, making a similar use case for digital voice 474 plausible. 476 LDACS A/A is currently not part of the standardization process and 477 will not be covered within this document. 479 5.2.3. Flight Guidance 481 The FCI (and therefore LDACS) is used to provide flight guidance. 482 This is realized using three applications: 484 1. Context Management (CM): The CM application manages the automatic 485 logical connection to the ATC center currently responsible to 486 guide the aircraft. Currently this is done by the air crew 487 manually changing VHF voice frequencies according to the progress 488 of the flight. The CM application automatically sets up 489 equivalent sessions. 490 2. Controller Pilot Data Link Communications (CPDLC): The CPDLC 491 application provides the air crew with the ability to exchange 492 data messages similar to text messages with the currently 493 responsible ATC center. The CPDLC application takes over most of 494 the communication currently performed over VHF voice and enables 495 new services that do not lend themselves to voice communication 496 (i.e., trajectory negotiation). 497 3. Automatic Dependent Surveillance - Contract (ADS-C): ADS-C 498 reports the position of the aircraft to the currently active ATC 499 center. Reporting is bound to "contracts", i.e., pre-defined 500 events related to the progress of the flight (i.e., the 501 trajectory). ADS-C and CPDLC are the primary applications used 502 for implementing in-flight trajectory management. 504 CM, CPDLC, and ADS-C are available on legacy datalinks, but are not 505 widely deployed and with limited functionality. 507 Further ATC applications may be ported to use the FCI or LDACS as 508 well. A notable application is GBAS for secure, automated landings: 509 The Global Navigation Satellite System (GNSS) based GBAS is used to 510 improve the accuracy of GNSS to allow GNSS based instrument landings. 511 This is realized by sending GNSS correction data (e.g., compensating 512 ionospheric errors in the GNSS signal) to the aircraft's GNSS 513 receiver via a separate data link. Currently the VDB data link is 514 used. VDB is a narrow-band single-purpose datalink without advanced 515 security only used to transmit GBAS correction data. This makes VDB 516 a natural candidate for replacement by LDACS [MAE20211]. 518 5.2.4. Business Communications of Airlines 520 In addition to air traffic services, AOC services are transmitted 521 over LDACS. AOC is a generic term referring to the business 522 communication of airlines, between the airlines and service partners 523 on the ground and their own aircraft in the air. Regulatory-wise, 524 this is considered related to safety and regularity of flight and may 525 therefore be transmitted over LDACS. AOC communication is considered 526 the main business case for LDACS communications service providers 527 since modern aircraft generate significant amounts of data (i.e., 528 engine maintenance data). 530 5.2.5. LDACS-based Navigation 532 Beyond communications, radio signals can always also be used for 533 navigation. This fact is used for the LDACS navigation concept. 535 For future aeronautical navigation, ICAO recommends the further 536 development of GNSS based technologies as primary means for 537 navigation. Due to the large separation between navigational 538 satellites and aircraft, the power of the GNSS signals received by 539 the aircraft is, however, very low. As a result, GNSS disruptions 540 might occasionally occur due to unintentional interference, or 541 intentional jamming. Yet the navigation services must be available 542 with sufficient performance for all phases of flight. Therefore, 543 during GNSS outages, or blockages, an alternative solution is needed. 544 This is commonly referred to as Alternative Positioning, Navigation, 545 and Timing (APNT). 547 One of such APNT solutions consists of exploiting the built-in 548 navigation capabilities of LDACS operation. That is, the normal 549 operation of LDACS for ATC and AOC communications would also directly 550 enable the aircraft to navigate and obtain a reliable timing 551 reference from the LDACS GSs. 553 LDACS navigation has already been demonstrated in practice in two 554 flight measurement campaigns [SHU2013] [BEL2021] [MAE20211]. . 556 6. Requirements 558 The requirements for LDACS are mostly defined by its application 559 area: Communications related to safety and regularity of flight. 561 A particularity of the current aeronautical communication landscape 562 is that it is heavily regulated. Aeronautical data links (for 563 applications related to safety and regularity of flight) may only use 564 spectrum licensed to aviation and data links endorsed by ICAO. 565 Nation states can change this locally, however, due to the global 566 scale of the air transportation system, adherence to these practices 567 is to be expected. 569 Aeronautical data links for the ATN are therefore expected to remain 570 in service for decades. The VDLm2 data link currently used for 571 digital terrestrial internetworking was developed in the 1990ies (the 572 use of the Open Systems Interconnection (OSI) stack indicates that as 573 well). VDLm2 is expected to be used at least for several decades. 574 In this respect aeronautical communications (for applications related 575 to safety and regularity of flight) is more comparable to industrial 576 applications than to the open Internet. 578 Internetwork technology is already installed in current aircraft. 579 Current ATS applications use either Aircraft Communications 580 Addressing and Reporting System (ACARS) or the OSI stack. The 581 objective of the development effort of LDACS, as part of the FCI, is 582 to replace legacy OSI stack and proprietary ACARS internetwork 583 technologies with industry standard IP technology. It is anticipated 584 that the use of Commercial Off-The-Shelf (COTS) IP technology mostly 585 applies to the ground network. The avionics networks on the aircraft 586 will likely be heavily modified versions of Ethernet or proprietary. 588 AOC applications currently mostly use the same stack (although some 589 applications, like the graphical weather service may use the 590 commercial passenger network). This creates capacity problems 591 (resulting in excessive amounts of timeouts) since the underlying 592 terrestrial data links do not provide sufficient bandwidth (i.e., 593 with VDLm2 currently in the order of 10 kbit/s). The use of non- 594 aviation specific data links is considered a security problem. 595 Ideally the aeronautical IP internetwork and the Internet should be 596 completely separated. 598 The objective of LDACS is to provide a next generation terrestrial 599 data link designed to support IP addressing and provide much higher 600 bandwidth to avoid the currently experienced operational problems. 602 The requirement for LDACS is therefore to provide a terrestrial high- 603 throughput data link for IP internetworking in the aircraft. 605 In order to fulfil the above requirement LDACS needs to be 606 interoperable with IP (and IP-based services like Voice-over-IP) at 607 the gateway connecting the LDACS network to other aeronautical ground 608 networks (i.e., the ATN). On the avionics side, in the aircraft, 609 aviation specific solutions are to be expected. 611 In addition to these functional requirements, LDACS and its IP stack 612 need to fulfil the requirements defined in RTCA DO-350A/EUROCAE ED- 613 228A [DO350A]. This document defines continuity, availability, and 614 integrity requirements at different scopes for each air traffic 615 management application (CPDLC, CM, and ADS-C). The scope most 616 relevant to IP over LDACS is the Communications Service Provider 617 (CSP) scope. 619 Continuity, availability, and integrity requirements are defined in 620 [DO350A] volume 1 Table 5-14, and Table 6-13. Appendix A presents 621 the required information. 623 In a similar vein, requirements to fault management are defined in 624 the same tables. 626 7. Characteristics 628 LDACS will become one of several wireless access networks connecting 629 aircraft to the ATN implemented by the FCI. 631 The current LDACS design is focused on the specification of layer one 632 and two. However, for the purpose of this work, only layer two 633 details are discussed here. 635 Achieving the stringent continuity, availability, and integrity 636 requirements defined in [DO350A] will require the specification of 637 layer 3 and above mechanisms (e.g. reliable crossover at the IP 638 layer). Fault management mechanisms are similarly undefined. Input 639 from the working group will be appreciated here. 641 7.1. LDACS Sub-Network 643 An LDACS sub-network contains an Access Router (AR) and several GS, 644 each of them providing one LDACS radio cell. 646 User plane interconnection to the ATN is facilitated by the AR 647 peering with an A/G Router connected to the ATN. 649 The internal control plane of an LDACS sub-network interconnects the 650 GSs. An LDACS sub-network is illustrated in Figure 1. 652 wireless user 653 link plane 654 AS-------------GS---------------AR---A/G-----ATN 655 . | Router 656 . control | 657 . plane | 658 . | 659 GS---------------| 660 . | 661 . | 662 GS---------------+ 664 Figure 1: LDACS sub-network with three GSs and one AS 666 7.2. Topology 668 LDACS is a cellular point-to-multipoint system. It assumes a star- 669 topology in each cell where Aircraft Stations (AS) belonging to 670 aircraft within a certain volume of space (the LDACS cell) is 671 connected to the controlling GS. The LDACS GS is a centralized 672 instance that controls LDACS A/G communications within its cell. The 673 LDACS GS can simultaneously support multiple bi-directional 674 communications to the ASs under its control. LDACS's GSs themselves 675 are connected to each other and the AR. 677 Prior to utilizing the system an aircraft has to register with the 678 controlling GS to establish dedicated logical channels for user and 679 control data. Control channels have statically allocated resources, 680 while user channels have dynamically assigned resources according to 681 the current demand. Logical channels exist only between the GS and 682 the AS. 684 7.3. LDACS Protocol Stack 686 The protocol stack of LDACS is implemented in the AS and GS: It 687 consists of the Physical Layer (PHY) with five major, functional 688 blocks above it. Four are placed in the Data Link Layer (DLL) of the 689 AS and GS: (1) Medium Access Control (MAC) Layer, (2) Voice Interface 690 (VI), (3) Data Link Service (DLS), and (4) LDACS Management Entity 691 (LME). The last entity resides within the sub-network layer: the 692 Sub-Network Protocol (SNP). The LDACS network is externally 693 connected to voice units, radio control units, and the ATN network 694 layer. 696 LDACS is considered an ATN/IPS radio access technology, from the view 697 of ICAO's regulatory framework. Hence, the interface between ATN and 698 LDACS must be IPv6 based, as regulatory documents, such as ICAO Doc 699 9896 [ICAO2015] and DO-379 [RTCA2019] clearly foresee that. The 700 translation between IPv6 layer and SNP layer is currently subject of 701 ongoing standardization efforts and at the time of writing not 702 finished yet. 704 Figure 2 shows the protocol stack of LDACS as implemented in the AS 705 and GS. Acronyms used here are introduced throughout the upcoming 706 sections. 708 IPv6 Network Layer 709 | 710 | 711 +------------------+ +----+ 712 | SNP |--| | Sub-Network 713 | | | | Layer 714 +------------------+ | | 715 | | LME| 716 +------------------+ | | 717 | DLS | | | LLC Layer 718 +------------------+ +----+ 719 | | 720 DCH DCCH/CCCH 721 | RACH/BCCH 722 | | 723 +--------------------------+ 724 | MAC | Medium Access 725 | | Layer 726 +--------------------------+ 727 | 728 +--------------------------+ 729 | PHY | Physical Layer 730 +--------------------------+ 731 | 732 | 733 ((*)) 734 FL/RL radio channels 735 separated by FDD 737 Figure 2: LDACS protocol stack in AS and GS 739 7.3.1. LDACS Physical Layer 741 The physical layer provides the means to transfer data over the radio 742 channel. The LDACS GS supports bi-directional links to multiple 743 aircraft under its control. The FL direction at the G2A connection 744 and the RL direction at the A2G connection are separated by Frequency 745 Division Duplex (FDD). FL and RL use a 500 kHz channel each. The GS 746 transmits a continuous stream of Orthogonal Frequency-Division 747 Multiplexing Access (OFDM) symbols on the FL. In the RL different 748 aircraft are separated in time and frequency using Orthogonal 749 Frequency-Division Multiple Access (OFDMA). Aircraft thus transmit 750 discontinuously on the RL via short radio bursts sent in precisely 751 defined transmission opportunities allocated by the GS. 753 7.3.2. LDACS Data Link Layer 755 The data-link layer provides the necessary protocols to facilitate 756 concurrent and reliable data transfer for multiple users. The LDACS 757 data link layer is organized in two sub-layers: The medium access 758 sub-layer and the Logical Link Control (LLC) sub-layer. The medium 759 access sub-layer manages the organization of transmission 760 opportunities in slots of time and frequency. The LLC sub-layer 761 provides acknowledged point-to-point logical channels between the 762 aircraft and the GS using an Automatic Repeat reQuest (ARQ) protocol. 763 LDACS supports also unacknowledged point-to-point channels and G2A 764 Broadcast transmission. 766 7.3.2.1. Medium Access Control (MAC) Services 768 The MAC time framing service provides the frame structure necessary 769 to realize slot-based time-division multiplex-access on the physical 770 link. It provides the functions for the synchronization of the MAC 771 framing structure and the PHY Layer framing. The MAC time framing 772 provides a dedicated time slot for each logical channel. 774 The MAC sub-layer offers access to the physical channel to its 775 service users. Channel access is provided through transparent 776 logical channels. The MAC sub-layer maps logical channels onto the 777 appropriate slots and manages the access to these channels. Logical 778 channels are used as interface between the MAC and LLC sub-layers. 780 7.3.2.2. Data Link Service (DLS) Services 782 The DLS provides acknowledged and unacknowledged (including broadcast 783 and packet mode voice) bi-directional exchange of user data. If user 784 data is transmitted using the acknowledged DLS, the sending DLS 785 entity will wait for an acknowledgement from the receiver. If no 786 acknowledgement is received within a specified time frame, the sender 787 may automatically try to retransmit its data. However, after a 788 certain number of failed retries, the sender will suspend further 789 retransmission attempts and inform its client of the failure. 791 The DLS uses the logical channels provided by the MAC: 793 1. A GS announces its existence and access parameters in the 794 Broadcast Channel (BCCH). 795 2. The Random Access Channel (RACH) enables AS to request access to 796 an LDACS cell. 797 3. In the FL the Common Control Channel (CCCH) is used by the GS to 798 grant access to data channel resources. 799 4. The reverse direction is covered by the RL, where ASs need to 800 request resources before sending. This happens via the Dedicated 801 Control Channel (DCCH). 802 5. User data itself is communicated in the Data Channel (DCH) on the 803 FL and RL. 805 Access to the FL and RL data channel is granted by the scheduling 806 mechanism implemented in the LME discussed below. 808 7.3.2.3. Voice Interface (VI) Services 810 The VI provides support for virtual voice circuits. Voice circuits 811 may either be set-up permanently by the GS (e.g., to emulate voice 812 party line) or may be created on demand. The creation and selection 813 of voice circuits is performed. 815 7.3.2.4. LDACS Management Entity (LME) Services 817 The mobility management service in the LME provides support for 818 registration and de-registration (cell entry and cell exit), scanning 819 RF channels of neighboring cells and handover between cells. In 820 addition, it manages the addressing of aircraft within cells. 822 The resource management service provides link maintenance (power, 823 frequency and time adjustments), support for adaptive coding and 824 modulation, and resource allocation. 826 The resource management service accepts resource requests from/for 827 different AS and issues resource allocations accordingly. While the 828 scheduling algorithm is not specified and a point of possible vendor 829 differentiation, it is subject to the following requirements: 831 1. Resource scheduling must provide channel access according to the 832 priority of the request 833 2. Resource scheduling must support "one-time" requests. 834 3. Resource scheduling must support "permanent" requests that 835 reserve a resource until the request is canceled e.g. for digital 836 voice circuits. 838 7.3.3. LDACS Sub-Network Layer and Protocol Services 840 Lastly, the SNP handles the transition from IPv6 packts to LDACS 841 internal packet structures. This work is ongoing and not part of 842 this document. The DLS provides functions required for the transfer 843 of user plane data and control plane data over the LDACS sub-network. 844 The security service provides functions for secure user data 845 communication over the LDACS sub-network. Note that the SNP security 846 service applies cryptographic measures as configured by the GS. 848 7.4. LDACS Mobility 850 LDACS supports layer 2 handovers to different LDACS cells. Handovers 851 may be initiated by the aircraft (break-before-make) or by the GS 852 (make-before-break). Make-before-break handovers are only supported 853 between GSs connected to each other. 855 External handovers between non-connected LDACS sub-networks or 856 different aeronautical data links are handled by the FCI multi- link 857 concept. 859 8. Reliability and Availability 861 8.1. Below Layer 1 863 Below Layer 2, aeronautics usually relies on hardware redundancy. To 864 protect availability of the LDACS link, an aircraft equipped with 865 LDACS will have access to two L-band antennae with triple redundant 866 radio systems as required for any safety relevant aeronautical 867 systems by ICAO. 869 8.2. Layer 1 and 2 871 LDACS has been designed with applications related to the safety and 872 regularity of flight in mind. It has therefore been designed as a 873 deterministic wireless data link (as far as this is possible). 875 Based on channel measurements of the L-band channel LDACS was 876 designed from the PHY layer up with robustness in mind. Channel 877 measurements of the L-band channel [SCH2016] confirmed LDACS to be 878 well adapted to its channel. 880 In order to maximize the capacity per channel and to optimally use 881 the available spectrum, LDACS was designed as an OFDM-based FDD 882 system, supporting simultaneous transmissions in FL in the G2A 883 connection and RL in the A2G connection. The legacy systems already 884 deployed in the L-band limit the bandwidth of both channels to 885 approximately 500 kHz. 887 The LDACS physical layer design includes propagation guard times 888 sufficient for the operation at a maximum distance of 200 nautical 889 miles from the GS. In actual deployment, LDACS can be configured for 890 any range up to this maximum range. 892 The LDACS physical layer supports adaptive coding and modulation for 893 user data. Control data is always encoded with the most robust 894 coding and modulation (FL: Quadrature Phase-Shift Keying (QPSK), 895 coding rate 1/2, RL: QPSK, coding rate 1/3). 897 LDACS medium access layer on top of the physical layer uses a static 898 frame structure to support deterministic timer management. As shown 899 in Figure 3 and Figure 4, LDACS framing structure is based on Super- 900 Frames (SF) of 240ms duration corresponding to 2000 OFDM symbols. FL 901 and RL boundaries are aligned in time (from the GS perspective) 902 allowing for deterministic slots for control and data channels. This 903 initial AS time synchronization and time synchronization maintenance 904 is based on observing the synchronization symbol pairs that 905 repetitively occur within the FL stream, being sent by the 906 controlling GS [GRA2019]. 908 ^ 909 | +------+------------+------------+------------+------------+ 910 | FL | BCCH | MF | MF | MF | MF | 911 F +------+------------+------------+------------+------------+ 912 r <---------------- Super-Frame (SF) - 240ms ----------------> 913 e 914 q +------+------------+------------+------------+------------+ 915 u RL | RACH | MF | MF | MF | MF | 916 e +------+------------+------------+------------+------------+ 917 n <---------------- Super-Frame (SF) - 240ms ----------------> 918 c 919 y 920 | 921 ----------------------------- Time ------------------------------> 922 | 924 Figure 3: SF structure for LDACS 926 ^ 927 | +-------------+------+-------------+ 928 | FL | DCH | CCCH | DCH | 929 F +-------------+------+-------------+ 930 r <---- Multi-Frame (MF) - 58.32ms --> 931 e 932 q +------+---------------------------+ 933 u RL | DCCH | DCH | 934 e +------+---------------------------+ 935 n <---- Multi-Frame (MF) - 58.32ms --> 936 c 937 y 938 | 939 -------------------- Time ------------------> 940 | 942 Figure 4: MF structure for LDACS 944 LDACS cell entry is conducted with an initial control message 945 exchange via the RACH and the BCCH. 947 After cell entry, LDACS medium access is always under the control of 948 the GS of a radio cell. Any medium access for the transmission of 949 user data on a DCH has to be requested with a resource request 950 message stating the requested amount of resources and class of 951 service. The GS performs resource scheduling on the basis of these 952 requests and grants resources with resource allocation messages. 953 Resource request and allocation messages are exchanged over dedicated 954 contention-free control channels (DCCH and CCCH). 956 The purpose of quality-of-service in LDACS medium access is to 957 provide prioritized medium access at the bottleneck (the wireless 958 link). The signaling of higher layer quality-of-service requirements 959 to LDACS is yet to be defined. A Differentiated Services- (DiffServ) 960 based solution with a small number of priorities is to be expected. 962 In addition to having full control over resource scheduling, the GS 963 can send forced handover commands for off-loading or channel 964 management, e.g., when the signal quality declines and a more 965 suitable GS is in the AS's reach. With robust resource management of 966 the capacities of the radio channel, reliability and robustness 967 measures are therefore also anchored in the LME. 969 In addition to radio resource management, the LDACS control channels 970 are also used to send keep-alive messages, when they are not 971 otherwise used. Since the framing of the control channels is 972 deterministic, missing keep-alive messages can thus be immediately 973 detected. This information is made available to the multi-link 974 protocols for fault management. 976 The protocol used to communicate faults is not defined in the LDACS 977 specification. It is assumed that vendors would use industry 978 standard protocols like the Simple Network Management Protocol or the 979 Network Configuration Protocol, where security permits. 981 The LDACS data link layer protocol, running on top of the medium 982 access sub-layer, uses ARQ to provide reliable data transmission on 983 the data channel. 985 It employs selective repeat ARQ with transparent fragmentation and 986 reassembly to the resource allocation size to achieve low latency and 987 a low overhead without losing reliability. It ensures correct order 988 of packet delivery without duplicates. In case of transmission 989 errors, it identifies lost fragments with deterministic timers synced 990 to the medium access frame structure and initiates retransmission. 992 8.3. Beyond Layer 2 994 LDACS availability can be increased by appropriately deploying LDACS 995 infrastructure: This means proliferating the number of terrestrial 996 ground stations. However, the scarcity of aeronautical spectrum for 997 data link communication (in the case of LDACS: tens of MHz in the 998 L-band) and the long range (in the case of LDACS: up to 200 nautical 999 miles) make this quite hard. The deployment of a larger number of 1000 small cells is certainly possible, suffers, however, also from the 1001 scarcity of spectrum. An additional constraint to consider, is that 1002 Distance Measuring Equipment (DME) is the primary user of the 1003 aeronautical L-band. That is, any LDACS deployment has to take DME 1004 frequency planning into account. 1006 The aeronautical community has therefore decided not to rely on a 1007 single communication system or frequency band. It is envisioned to 1008 have multiple independent data link technologies in the aircraft 1009 (e.g., terrestrial and satellite communications) in addition to 1010 legacy VHF voice. 1012 However, as of now, no reliability and availability mechanisms that 1013 could utilize the multi-link architecture, have been specified on 1014 Layer 3 and above. Even if LDACS has been designed for reliability, 1015 the wireless medium presents significant challenges to achieve 1016 deterministic properties such as low packet error rate, bounded 1017 consecutive losses, and bounded latency. Support for high 1018 reliability and availability for IP connectivity over LDACS is 1019 therefore, highly desirable, needs, however, to be adapted to the 1020 specific use case. 1022 9. Security 1024 ICAO Doc 9896 foresees transport layer security [ICAO2015] for all 1025 aeronautical data as described in ARINC P858 [ARI2021], most likely 1026 realized via Datagram Transport Layer Security (DTLS) [RFC6012] 1027 [RFC6347]. 1029 LDACS also needs to comply with in-depth security requirements, 1030 stated in P858, for the radio access technologies transporting ATN/ 1031 IPS data [ARI2021]. These requirements imply that LDACS must provide 1032 layer 2 security in addition to any higher layer mechanisms. 1034 9.1. Security in Wireless Digital Aeronautical Communications 1036 Aviation will require secure exchanges of data and voice messages for 1037 managing the air traffic flow safely through the airspaces all over 1038 the world. Historically Communication Navigation Surveillance (CNS) 1039 wireless communications technology emerged from military and a threat 1040 landscape where inferior technological and financial capabilities of 1041 adversaries were assumed [STR2016]. The main communications method 1042 for ATC today is still an open analogue voice broadcast within the 1043 aeronautical VHF band. Currently, information security is mainly 1044 procedural, based by using well-trained personnel and proven 1045 communications procedures. This communication method has been in 1046 service since 1948. However, since the emergence of civil 1047 aeronautical CNS applications in the 70s, and today, the world has 1048 changed. 1050 Civil applications have significant lower spectrum available than 1051 military applications. This means several military defense 1052 mechanisms, such as frequency hopping or pilot symbol scrambling and, 1053 thus, a defense-in- depth approach starting at the physical layer, is 1054 infeasible for civil systems. With the rise of cheap Software 1055 Defined Radios (SDRs), the previously existing financial barrier is 1056 almost gone and open source projects such as GNU radio [GNU2021] 1057 allow a new type of unsophisticated listeners and possible attackers. 1059 Most CNS technology developed in ICAO relies on open standards, thus 1060 syntax and semantics of wireless digital aeronautical communications 1061 should be expected to be common knowledge for attackers. With 1062 increased digitization and automation of civil aviation, the human as 1063 control instance, is being taken gradually out of the loop. 1064 Autonomous transport drones or single piloted aircraft demonstrate 1065 this trend. However, without profound cybersecurity measures such as 1066 authenticity and integrity checks of messages in-transit on the 1067 wireless link or mutual entity authentication, this lack of a control 1068 instance can prove disastrous. Thus, future digital communications 1069 waveforms will need additional embedded security features to fulfill 1070 modern information security requirements like authentication and 1071 integrity. These security features require sufficient bandwidth 1072 which is beyond the capabilities of currently deployed VHF narrowband 1073 communications systems. For voice and data communications, 1074 sufficient data throughput capability is needed to support the 1075 security functions while not degrading performance. LDACS is a data 1076 link technology with sufficient bandwidth to incorporate security 1077 without losing too much user data throughput. 1079 9.2. LDACS Requirements 1081 Overall, there are several business goals for cybersecurity to 1082 protect, within the FCI in civil aviation: 1084 1. Safety: The system must sufficiently mitigate attacks, which 1085 contribute to safety hazards. 1086 2. Flight regularity: The system must sufficiently mitigate attacks, 1087 which contribute to delays, diversions, or cancellations of 1088 flights. 1089 3. Protection of business interests: The system must sufficiently 1090 mitigate attacks which result in financial loss, reputation 1091 damage, disclosure of sensitive proprietary information, or 1092 disclosure of personal information. 1094 To further analyze assets and derive threats and thus protection 1095 scenarios several threat-and risk analyses were performed for LDACS 1096 [MAE20181] , [MAE20191]. These results allowed deriving security 1097 scope and objectives from the requirements and the conducted threat- 1098 and risk analysis. 1100 9.3. LDACS Security Objectives 1102 Security considerations for LDACS are defined by the official SARPS 1103 document by ICAO [ICA2018]: 1105 1. LDACS shall provide a capability to protect the availability and 1106 continuity of the system. 1107 2. LDACS shall provide a capability including cryptographic 1108 mechanisms to protect the integrity of messages in transit. 1109 3. LDACS shall provide a capability to ensure the authenticity of 1110 messages in transit. 1111 4. LDACS should provide a capability for nonrepudiation of origin 1112 for messages in transit. 1113 5. LDACS should provide a capability to protect the confidentiality 1114 of messages in transit. 1115 6. LDACS shall provide an authentication capability. 1116 7. LDACS shall provide a capability to authorize the permitted 1117 actions of users of the system and to deny actions that are not 1118 explicitly authorized. 1119 8. If LDACS provides interfaces to multiple domains, LDACS shall 1120 provide capability to prevent the propagation of intrusions within 1121 LDACS domains and towards external domains. 1123 Currently, a change request for these SARPS aims to limit the "non- 1124 repudiation of origin of messages in transit" requirement only to the 1125 authentication and key establishment messages at the beginning of 1126 every session. 1128 9.4. LDACS Security Functions 1130 These objectives were used to derive several security functions for 1131 LDACS required to be integrated in the LDACS cybersecurity 1132 architecture: Identification, Authentication, Authorization, 1133 Confidentiality, System Integrity, Data Integrity, Robustness, 1134 Reliability, Availability, and Key and Trust Management. Several 1135 works investigated possible measures to implement these security 1136 functions [BIL2017], [MAE20181], [MAE20191]. 1138 9.5. LDACS Security Architecture 1140 The requirements lead to a LDACS security model, including different 1141 entities for identification, authentication and authorization 1142 purposes, ensuring integrity, authenticity and confidentiality of 1143 data. A draft of the cybersecurity architecture of LDACS can be 1144 found in [ICA2018] and [MAE20182] and respective updates in 1145 [MAE20191], [MAE20192], [MAE2020], and most recently [MAE2021]. 1147 9.5.1. Entities 1149 A simplified LDACS architectural model requires the following 1150 entities: Network operators such as the Societe Internationale de 1151 Telecommunications Aeronautiques (SITA) [SIT2020] and ARINC [ARI2020] 1152 are providing access to the ground IPS network via an A/G LDACS 1153 router. This router is attached to a closed off LDACS access 1154 network, which connects via further (access routers to the different 1155 LDACS cell ranges, each controlled by a GS (serving one LDACS cell), 1156 with several interconnected GS spanning a local LDACS access network. 1157 Via the A/G wireless LDACS data link AS the aircraft is connected to 1158 the ground network and via the aircraft's VI and aircraft's network 1159 interface, aircraft's data can be sent via the AS back to the GS, 1160 then to the LDACS local access network, access routers, LDACS access 1161 network, A/G LDACS router and finally to the ground IPS network 1162 [ICAO2015]. 1164 9.5.2. Entity Identification 1166 LDACS needs specific identities for the AS, the GS, and the network 1167 operator. The aircraft itself can be identified using the ICAO 1168 unique address of an aircraft, the call sign of that aircraft or the 1169 recently founded privacy ICAO address of the Federal Aviation 1170 Administration (FAA) program with the same name [FAA2020]. It is 1171 conceivable that the LDACS AS will use a combination of aircraft 1172 identification, radio component identification and even operator 1173 feature identification to create a unique AS LDACS identification 1174 tag. Similar to a 4G's eNodeB serving network identification tag, a 1175 GS could be identified using a similar field. The identification of 1176 the network operator is again similar to 4G (e.g., E-Plus, AT&T, and 1177 TELUS), in the way that the aeronautical network operators are listed 1178 (e.g., ARINC [ARI2020] and SITA [SIT2020]). 1180 9.5.3. Entity Authentication and Key Establishment 1182 In order to anchor trust within the system, all LDACS entities 1183 connected to the ground IPS network will be rooted in an LDACS 1184 specific chain-of-trust and PKI solution, quite similar to AeroMACS's 1185 approach [CRO2016]. These certificates, residing at the entities and 1186 incorporated in the LDACS PKI, providing proof the ownership of their 1187 respective public key, include information about the identity of the 1188 owner and the digital signature of the entity that has verified the 1189 certificate's content. First, all ground infrastructures must 1190 mutually authenticate to each other, negotiate and derive keys and, 1191 thus, secure all ground connections. How this process is handled in 1192 detail is still an ongoing discussion. However, established methods 1193 to secure user plane by IPSec [RFC4301] and IKEv2 [RFC7296] or the 1194 application layer via TLS 1.3 [RFC8446] are conceivable. The LDACS 1195 PKI with their chain-of-trust approach, digital certificates and 1196 public entity keys lay the groundwork for this step. In a second 1197 step, the AS with the LDACS radio aboard, approaches an LDACS cell 1198 and performs a cell-attachment procedure with the corresponding GS. 1199 This procedure consists of (1) the basic cell entry [GRA2019] and (2) 1200 a Mutual Authentication and Key Establishment (MAKE) procedure 1201 [MAE2021]. 1203 Note, that LDACS will foresee multiple security levels. To address 1204 the issue of the long service life of LDACS (i.e., possibly >30 1205 years) and the security of current pre-quantum cryptography, these 1206 security levels include pre- and post-quantum cryptographic 1207 solutions. Limiting security data on the LDACS datalink as much as 1208 possible, to reserve as much space for actual user data transmission, 1209 is key in the LDACS security architecture, this is also reflected in 1210 the underlying cryptography: Pre-quantum solutions will rely on 1211 elliptic curves [KOB1987], while post-quantum solutions consider 1212 Falcon [SON2021] [MAE2021] or similar lightweight PQC signature 1213 schemes, and SIKE or SABER as key establishment options [SIK2021] 1214 [ROY2020]. 1216 9.5.4. Message-in-transit Confidentiality, Integrity and Authenticity 1218 The key material from the previous step can then be used to protect 1219 LDACS Layer 2 communications via applying encryption and integrity 1220 protection measures on the SNP layer of the LDACS protocol stack. As 1221 LDACS transports AOC and ATS data, the integrity of that data is most 1222 important, while confidentiality only needs to be applied to AOC data 1223 to protect business interests [ICA2018]. This possibility of 1224 providing low layered confidentiality and integrity protection 1225 ensures a secure delivery of user data over the air gap. 1226 Furthermore, it ensures integrity protection of LDACS control data. 1228 10. IANA Considerations 1230 This memo includes no request to IANA. 1232 11. Acknowledgements 1234 Thanks to all contributors to the development of LDACS and ICAO PT-T. 1236 Thanks to Klaus-Peter Hauf, Bart Van Den Einden, and Pierluigi 1237 Fantappie for further input to this draft. 1239 Thanks to the Chair for Network Security and the research institute 1240 CODE for their comments and improvements. 1242 Thanks to SBA Research Vienna for fruitful discussions on 1243 aeronautical communications concerning security incentives for 1244 industry and potential economic spillovers. 1246 Thanks to the Aeronautical Communications group at the Institute of 1247 Communications and Navigation of the German Aerospace Center (DLR). 1248 With that, the authors would like to explicitly thank Miguel Angel 1249 Bellido-Manganell and Lukas Marcel Schalk for their thorough 1250 feedback. 1252 12. Normative References 1254 [GRA2019] Graeupl, T., Rihacek, C., and B. Haindl, "LDACS A/G 1255 Specification", SESAR2020 PJ14-02-01 D3.3.030 , 2019. 1257 [ICAO2015] International Civil Aviation Organization (ICAO), "Manual 1258 on the Aeronautical Telecommunication Network (ATN) using 1259 Internet Protocol Suite (IPS) Standards and Protocols, Doc 1260 9896", January 2015, 1261 . 1263 [RTCA2019] Radio Technical Commission for Aeronautics (RTCA), 1264 "Internet Protocol Suite Profiles, DO-379", September 1265 2019, . 1267 [EURO2019] European Organization for Civil Aviation Equipment 1268 (EUROCAE), "Technical Standard of Aviation Profiles for 1269 ATN/IPS, ED-262", September 2019, 1270 . 1273 [ARI2021] ARINC, "Internet Protocol Suite (IPS) For Aeronautical 1274 Safety Services Part 1- Airborne IP System Technical 1275 Requirements, ARINC SPECIFICATION 858 P1", June 2021, 1276 . 1278 13. Informative References 1280 [RFC3610] Whiting, D., Housley, R., and N. Ferguson, "Counter with 1281 CBC-MAC (CCM)", RFC 3610, DOI 10.17487/RFC3610, September 1282 2003, . 1284 [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing 1285 Architecture", RFC 4291, DOI 10.17487/RFC4291, February 1286 2006, . 1288 [RFC4301] Kent, S. and K. Seo, "Security Architecture for the 1289 Internet Protocol", RFC 4301, DOI 10.17487/RFC4301, 1290 December 2005, . 1292 [RFC4493] Song, JH., Poovendran, R., Lee, J., and T. Iwata, "The 1293 AES-CMAC Algorithm", RFC 4493, DOI 10.17487/RFC4493, June 1294 2006, . 1296 [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., 1297 Housley, R., and W. Polk, "Internet X.509 Public Key 1298 Infrastructure Certificate and Certificate Revocation List 1299 (CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008, 1300 . 1302 [RFC5869] Krawczyk, H. and P. Eronen, "HMAC-based Extract-and-Expand 1303 Key Derivation Function (HKDF)", RFC 5869, 1304 DOI 10.17487/RFC5869, May 2010, 1305 . 1307 [RFC6012] Salowey, J., Petch, T., Gerhards, R., and H. Feng, 1308 "Datagram Transport Layer Security (DTLS) Transport 1309 Mapping for Syslog", RFC 6012, DOI 10.17487/RFC6012, 1310 October 2010, . 1312 [RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer 1313 Security Version 1.2", RFC 6347, DOI 10.17487/RFC6347, 1314 January 2012, . 1316 [RFC7136] Carpenter, B. and S. Jiang, "Significance of IPv6 1317 Interface Identifiers", RFC 7136, DOI 10.17487/RFC7136, 1318 February 2014, . 1320 [RFC7236] Reschke, J., "Initial Hypertext Transfer Protocol (HTTP) 1321 Authentication Scheme Registrations", RFC 7236, 1322 DOI 10.17487/RFC7236, June 2014, 1323 . 1325 [RFC7296] Kaufman, C., Hoffman, P., Nir, Y., Eronen, P., and T. 1326 Kivinen, "Internet Key Exchange Protocol Version 2 1327 (IKEv2)", STD 79, RFC 7296, DOI 10.17487/RFC7296, October 1328 2014, . 1330 [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol 1331 Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, 1332 . 1334 [SCH2016] Schneckenburger, N., Jost, T., Shutin, D., Walter, M., 1335 Thiasiriphet, T., Schnell, M., and U.C. Fiebig, 1336 "Measurement of the L-band Air-to-Ground Channel for 1337 Positioning Applications", IEEE Transactions on Aerospace 1338 and Electronic Systems, 52(5), pp.2281-229 , 2016. 1340 [MAE20191] Maeurer, N., Graeupl, T., and C. Schmitt, "Evaluation of 1341 the LDACS Cybersecurity Implementation", IEEE 38th Digital 1342 Avionics Systems Conference (DACS), pp. 1-10, San Diego, 1343 CA, USA , 2019. 1345 [MAE20192] Maeurer, N. and C. Schmitt, "Towards Successful 1346 Realization of the LDACS Cybersecurity Architecture: An 1347 Updated Datalink Security Threat- and Risk Analysis", IEEE 1348 Integrated Communications, Navigation and Surveillance 1349 Conference (ICNS), pp. 1-13, Herndon, VA, USA , 2019. 1351 [FAN2019] Pierattelli, S., Fantappie, P., Tamalet, S., van den 1352 Einden, B., Rihacek, C., and T. Graeupl, "LDACS Deployment 1353 Options and Recommendations", SESAR2020 PJ14-02-01 1354 D3.4.020 , 2019. 1356 [MAE20182] Maeurer, N. and A. Bilzhause, "A Cybersecurity 1357 Architecture for the L-band Digital Aeronautical 1358 Communications System (LDACS)", IEEE 37th Digital Avionics 1359 Systems Conference (DASC), pp. 1-10, London, UK , 2017. 1361 [GRA2011] Graeupl, T. and M. Ehammer, "L-DACS1 Data Link Layer 1362 Evolution of ATN/IPS", 30th IEEE/AIAA Digital Avionics 1363 Systems Conference (DASC), pp. 1-28, Seattle, WA, USA , 1364 2011. 1366 [GRA2018] Graeupl, T., Schneckenburger, N., Jost, T., Schnell, M., 1367 Filip, A., Bellido-Manganell, M.A., Mielke, D.M., Maeurer, 1368 N., Kumar, R., Osechas, O., and G. Battista, "L-band 1369 Digital Aeronautical Communications System (LDACS) flight 1370 trials in the national German project MICONAV", Integrated 1371 Communications, Navigation, Surveillance Conference 1372 (ICNS), pp. 1-7, Herndon, VA, USA , 2018. 1374 [ICA2018] International Civil Aviation Organization (ICAO), "L-Band 1375 Digital Aeronautical Communication System (LDACS)", 1376 International Standards and Recommended Practices Annex 10 1377 - Aeronautical Telecommunications, Vol. III - 1378 Communication Systems , 2018. 1380 [SAJ2014] Haindl, B., Meser, J., Sajatovic, M., Mueller, S., 1381 Arthaber, H., Faseth, T., and M. Zaisberger, "LDACS1 1382 Conformance and Compatibility Assessment", IEEE/AIAA 33rd 1383 Digital Avionics Systems Conference (DASC), pp. 1-11, 1384 Colorado Springs, CO, USA , 2014. 1386 [RIH2018] Rihacek, C., Haindl, B., Fantappie, P., Pierattelli, S., 1387 Graeupl, T., Schnell, M., and N. Fistas, "L-band Digital 1388 Aeronautical Communications System (LDACS) Activities in 1389 SESAR2020", Integrated Communications Navigation and 1390 Surveillance Conference (ICNS), pp. 1-8, Herndon, VA, 1391 USA , 2018. 1393 [BEL2019] Bellido-Manganell, M. A. and M. Schnell, "Towards Modern 1394 Air-to-Air Communications: the LDACS A2A Mode", IEEE/AIAA 1395 38th Digital Avionics Systems Conference (DASC), pp. 1-10, 1396 San Diego, CA, USA , 2019. 1398 [TS33.401] Zhang, D., "3GPP System Architecture Evolution (SAE); 1399 Security architecture", T33.401, 3GPP , 2012. 1401 [CRO2016] Crowe, B., "Proposed AeroMACS PKI Specification is a Model 1402 for Global and National Aeronautical PKI Deployments", 1403 WiMAX Forum at 16th Integrated Communications, Navigation 1404 and Surveillance Conference (ICNS), pp. 1-19, New York, 1405 NY, USA , 2016. 1407 [MAE2020] Maeurer, N., Graeupl, T., and C. Schmitt, "Comparing 1408 Different Diffie-Hellman Key Exchange Flavors for LDACS", 1409 IEEE/AIAA 39th Digital Avionics Systems Conference (DASC), 1410 pp. 1-10, San Antonio, TX, USA , 2020. 1412 [STR2016] Strohmeier, M., Schaefer, M., Pinheiro, R., Lenders, V., 1413 and I. Martinovic, "On Perception and Reality in Wireless 1414 Air Traffic Communication Security", IEEE Transactions on 1415 Intelligent Transportation Systems, 18(6), pp. 1338-1357, 1416 New York, NY, USA , 2016. 1418 [BIL2017] Bilzhause, A., Belgacem, B., Mostafa, M., and T. Graeupl, 1419 "Datalink Security in the L-band Digital Aeronautical 1420 Communications System (LDACS) for Air Traffic Management", 1421 IEEE Aerospace and Electronic Systems Magazine, 32(11), 1422 pp. 22-33, New York, NY, USA , 2017. 1424 [MAE20181] Maeurer, N. and A. Bilzhause, "Paving the Way for an IT 1425 Security Architecture for LDACS: A Datalink Security 1426 Threat and Risk Analysis", IEEE Integrated Communications, 1427 Navigation, Surveillance Conference (ICNS), pp. 1-11, New 1428 York, NY, USA , 2018. 1430 [FAA2020] FAA, "Federal Aviation Administration. ADS-B Privacy.", 1431 August 2020, 1432 . 1434 [GNU2021] GNU Radio project, "GNU radio", October 2021, 1435 . 1437 [SIT2020] SITA, "Societe Internationale de Telecommunications 1438 Aeronautiques", August 2020, . 1440 [ARI2020] ARINC, "Aeronautical Radio Incorporated", August 2020, 1441 . 1443 [DO350A] RTCA SC-214, "Safety and Performance Standard for Baseline 1444 2 ATS Data Communications (Baseline 2 SPR Standard)", May 1445 2016, . 1448 [ICAO2019] International Civil Aviation Organization (ICAO), "Manual 1449 on VHF Digital Link (VDL) Mode 2, Doc 9776", January 2019, 1450 . 1453 [KAMA2010] Kamali, B., "An Overview of VHF Civil Radio Network and 1454 the Resolution of Spectrum Depletion", Integrated 1455 Communications, Navigation, and Surveillance Conference, 1456 pp. F4-1-F4-8 , May 2010. 1458 [SON2021] Soni, D., Basu, K., Nabeel, M., Aaraj, N., Manzano, M., 1459 and R. Karri, "FALCON", Hardware Architectures for Post- 1460 Quantum Digital Signature Schemes, pp. 31-41 , November 1461 2021. 1463 [KOB1987] Koblitz, N. and M. Hellman, "Elliptic Curve 1464 Cryptosystems", Mathematics of Computation, 1465 48(177):203-209. , January 1987. 1467 [SIK2021] SIKE, "SIKE – Supersingular Isogeny Key Encapsulation", 1468 October 2021, . 1470 [ROY2020] Roy, S.S.. and A. Basso, "High-Speed Instruction-Set 1471 Coprocessor For Lattice-Based Key Encapsulation Mechanism: 1472 Saber In Hardware", IACR Transactions on Cryptographic 1473 Hardware and Embedded Systems, 443-466. , August 2020. 1475 [RAW-TECHNOS] 1476 Thubert, P., Cavalcanti, D., Vilajosana, X., Schmitt, C., 1477 and J. Farkas, "Reliable and Available Wireless 1478 Technologies", Work in Progress, Internet-Draft, draft- 1479 ietf-raw-technologies-04, 3 August 2021, 1480 . 1483 [RAW-USE-CASES] 1484 Papadopoulos, G. Z., Thubert, P., Theoleyre, F., and C. J. 1485 Bernardos, "RAW use cases", Work in Progress, Internet- 1486 Draft, draft-ietf-raw-use-cases-03, 20 October 2021, 1487 . 1490 [I-D.haindl-lisp-gb-atn] 1491 Haindl, B., Lindner, M., Rahman, R., Comeras, M. P., 1492 Moreno, V., Maino, F., and B. Venkatachalapathy, "Ground- 1493 Based LISP for the Aeronautical Telecommunications 1494 Network", Work in Progress, Internet-Draft, draft-haindl- 1495 lisp-gb-atn-06, 6 March 2021, 1496 . 1499 [I-D.ietf-rtgwg-atn-bgp] 1500 Templin, F. L., Saccone, G., Dawra, G., Lindem, A., and V. 1501 Moreno, "A Simple BGP-based Mobile Routing System for the 1502 Aeronautical Telecommunications Network", Work in 1503 Progress, Internet-Draft, draft-ietf-rtgwg-atn-bgp-11, 6 1504 July 2021, . 1507 [ICAO2018] International Civil Aviation Organization (ICAO), 1508 "Handbook on Radio Frequency Spectrum Requirements for 1509 Civil Aviation, Doc 9718, Volume 1, ICAO Spectrum 1510 Strategy, Policy Statements and Related Information", July 1511 2018, . 1514 [EURO2021] European Organization for Civil Aviation Equipment 1515 (EUROCAE), "Radio Frequency Function 2020 report", March 1516 2021, . 1518 [ARI2019] ARINC, "AOC Air-Ground Data And Message Exchange Format, 1519 ARINC 633", January 2019, 1520 . 1523 [VIR2021] Virdia, A., Stea, G., and G. Dini, "SAPIENT: Enabling 1524 Real-Time Monitoring and Control in the Future 1525 Communication Infrastructure of Air Traffic Management", 1526 IEEE Transactions on Intelligent Transportation Systems, 1527 22(8):4864-4875 , August 2021. 1529 [SHU2013] Shutin, D., Schneckenburger, N., Walter, M., and M. 1530 Schnell, "LDACS1 Ranging Performance - An Analysis Of 1531 Flight Measurement Results", IEEE 32th Digital Avionics 1532 Systems Conference (DASC), pp. 1-10, East Syracuse, NY, 1533 USA , October 2013. 1535 [BEL2021] Bellido-Manganell, M.A., Graeupl, T., Heirich, O., 1536 Maeurer, N., Filip-Dhaubhadel, A., Mielke, D.M., Schalk, 1537 L.M., Becker, D., Schneckenburger, N., and M. Schnell, 1538 "LDACS Flight Trials: Demonstration and Performance 1539 Analysis of the Future Aeronautical Communications 1540 System", IEEE Transactions on Aerospace and Electronic 1541 Systems, pp. 1-19 , September 2021. 1543 [MAE2021] Maeurer, N., Graeupl, T., Gentsch, C., Guggemos, T., 1544 Tiepelt, M., Schmitt, C., and G. Dreo Rodosek, "A Secure 1545 Cell-Attachment Procedure for LDACS", 1st Workshop on 1546 Secure and Reliable Communication and Navigation in the 1547 Aerospace Domain (SRCNAS), pp. 1-10, Vienna, Austria , 1548 September 2021. 1550 [MAE20211] Maeurer, N., Graeupl, T., Bellido-Manganell, M.A., Mielke, 1551 D.M., Filip-Dhaubhadel, A., Heirich, O., Gerberth, D., 1552 Flux, M., Schalk, L.M., Becker, D., Schneckenburger, N., 1553 and M. Schnell, "Flight Trial Demonstration of Secure GBAS 1554 via the L-band Digital Aeronautical Communications System 1555 (LDACS)", IEEE Aerospace and Electronic Systems Magazine, 1556 36(4), pp. 8-17 , April 2021. 1558 [BOE2019] Boegl, T., Rautenberg, M., Haindl, R., Rihacek, C., Meser, 1559 J., Fantappie, P., Pringvanich, N., Micallef, J., 1560 Klauspeter, H.., MacBride, J., Sacre, P., v.d. Eiden, B., 1561 Graeupl, T., and M. Schnell, "LDACS White Paper - A Roll- 1562 out Scenario", International Civil Aviation Organization, 1563 Communications Panel - Data Communications Infrastructure 1564 Working Group - Third Meeting, pp. 1-8, Montreal, Canada , 1565 October 2019. 1567 Appendix A. Selected Information from DO-350A 1569 This appendix includes the continuity, availability, and integrity 1570 requirements applicable for LDACS defined in [DO350A]. 1572 The following terms are used here: 1574 CPDLC Controller Pilot Data Link Communication 1575 DT Delivery Time (nominal) value for RSP 1576 ET Expiration Time value for RCP 1577 FH Flight Hour 1578 MA Monitoring and Alerting criteria 1579 OT Overdue Delivery Time value for RSP 1580 RCP Required Communication Performance 1581 RSP Required Surveillance Performance 1582 TT Transaction Time (nominal) value for RCP 1583 +========================+=============+=============+ 1584 | | RCP 130 | RCP 130 | 1585 +========================+=============+=============+ 1586 | Parameter | ET | TT95% | 1587 +------------------------+-------------+-------------+ 1588 | Transaction Time (sec) | 130 | 67 | 1589 +------------------------+-------------+-------------+ 1590 | Continuity | 0.999 | 0.95 | 1591 +------------------------+-------------+-------------+ 1592 | Availability | 0.989 | 0.989 | 1593 +------------------------+-------------+-------------+ 1594 | Integrity | 1E-5 per FH | 1E-5 per FH | 1595 +------------------------+-------------+-------------+ 1597 Table 1: CPDLC Requirements for RCP 130 1599 +==============+==========+==============+=========+=========+ 1600 | | RCP 240 | RCP 240 | RCP 400 | RCP 400 | 1601 +==============+==========+==============+=========+=========+ 1602 | Parameter | ET | TT95% | ET | TT95% | 1603 +--------------+----------+--------------+---------+---------+ 1604 | Transaction | 240 | 210 | 400 | 350 | 1605 | Time (sec) | | | | | 1606 +--------------+----------+--------------+---------+---------+ 1607 | Continuity | 0.999 | 0.95 | 0.999 | 0.95 | 1608 +--------------+----------+--------------+---------+---------+ 1609 | Availability | 0.989 | 0.989 | 0.989 | 0.989 | 1610 | | (safety) | (efficiency) | | | 1611 +--------------+----------+--------------+---------+---------+ 1612 | Integrity | 1E-5 per | 1E-5 per FH | 1E-5 | 1E-5 | 1613 | | FH | | per FH | per FH | 1614 +--------------+----------+--------------+---------+---------+ 1616 Table 2: CPDLC Requirements for RCP 240/400 1618 RCP Monitoring and Alerting Criteria in case of CPDLC: 1620 - MA-1: The system shall be capable of detecting failures and 1621 configuration changes that would cause the communication service 1622 no longer meet the RCP specification for the intended use. 1623 - MA-2: When the communication service can no longer meet the RCP 1624 specification for the intended function, the flight crew and/or 1625 the controller shall take appropriate action. 1627 +==============+=====+=====+==========+==============+======+=======+ 1628 | | RSP | RSP | RSP 180 | RSP 180 | RSP |RSP 400| 1629 | | 160 | 160 | | | 400 | | 1630 +==============+=====+=====+==========+==============+======+=======+ 1631 | Parameter | OT |DT95%| OT | DT95% | OT | DT95% | 1632 +--------------+-----+-----+----------+--------------+------+-------+ 1633 | Transaction | 160 | 90 | 180 | 90 | 400 | 300 | 1634 | Time (sec) | | | | | | | 1635 +--------------+-----+-----+----------+--------------+------+-------+ 1636 | Continuity |0.999| 0.95| 0.999 | 0.95 |0.999 | 0.95 | 1637 +--------------+-----+-----+----------+--------------+------+-------+ 1638 | Availability |0.989|0.989| 0.989 | 0.989 |0.989 | 0.989 | 1639 | | | | (safety) | (efficiency) | | | 1640 +--------------+-----+-----+----------+--------------+------+-------+ 1641 | Integrity | 1E-5| 1E-5| 1E-5 per | 1E-5 per FH | 1E-5 | 1E-5 | 1642 | | per | per | FH | |per FH| per FH| 1643 | | FH | FH | | | | | 1644 +--------------+-----+-----+----------+--------------+------+-------+ 1646 Table 3: ADS-C Requirements 1648 RCP Monitoring and Alerting Criteria: 1650 - MA-1: The system shall be capable of detecting failures and 1651 configuration changes that would cause the ADS-C service no longer 1652 meet the RSP specification for the intended function. 1653 - MA-2: When the ADS-C service can no longer meet the RSP 1654 specification for the intended function, the flight crew and/or 1655 the controller shall take appropriate action. 1657 Authors' Addresses 1659 Nils Maeurer (editor) 1660 German Aerospace Center (DLR) 1661 Muenchner Strasse 20 1662 82234 Wessling 1663 Germany 1665 Email: Nils.Maeurer@dlr.de 1667 Thomas Graeupl (editor) 1668 German Aerospace Center (DLR) 1669 Muenchner Strasse 20 1670 82234 Wessling 1671 Germany 1672 Email: Thomas.Graeupl@dlr.de 1674 Corinna Schmitt (editor) 1675 Research Institute CODE, UniBwM 1676 Werner-Heisenberg-Weg 28 1677 85577 Neubiberg 1678 Germany 1680 Email: corinna.schmitt@unibw.de