idnits 2.17.00 (12 Aug 2021) /tmp/idnits9927/draft-ietf-raw-ldacs-10.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 document date (21 March 2022) is 54 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'KOB1987' is mentioned on line 1211, but not defined -- Obsolete informational reference (is this intentional?): RFC 6347 (Obsoleted by RFC 9147) == 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-14 Summary: 0 errors (**), 0 flaws (~~), 4 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: 22 September 2022 C. Schmitt, Ed. 6 Research Institute CODE, UniBwM 7 21 March 2022 9 L-band Digital Aeronautical Communications System (LDACS) 10 draft-ietf-raw-ldacs-10 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 22 September 2022. 40 Copyright Notice 42 Copyright (c) 2022 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 Revised BSD License text as 51 described in Section 4.e of the Trust Legal Provisions and are 52 provided without warranty as described in the Revised 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 . . . . . . . . . . . . . . . . . . . . . . 10 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 . . . . . . . . . . . . . 11 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 . . . . . . . . . . . . . . . . . . . . . . . . 13 74 7. Characteristics . . . . . . . . . . . . . . . . . . . . . . . 14 75 7.1. LDACS Sub-Network . . . . . . . . . . . . . . . . . . . . 14 76 7.2. Topology . . . . . . . . . . . . . . . . . . . . . . . . 15 77 7.3. LDACS Protocol Stack . . . . . . . . . . . . . . . . . . 16 78 7.3.1. LDACS Physical Layer . . . . . . . . . . . . . . . . 17 79 7.3.2. LDACS Data Link Layer . . . . . . . . . . . . . . . . 18 80 7.3.3. LDACS Sub-Network Layer and Protocol Services . . . . 19 81 7.4. LDACS Mobility . . . . . . . . . . . . . . . . . . . . . 20 82 8. Reliability and Availability . . . . . . . . . . . . . . . . 20 83 8.1. Below Layer 1 . . . . . . . . . . . . . . . . . . . . . . 20 84 8.2. Layer 1 and 2 . . . . . . . . . . . . . . . . . . . . . . 20 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 . . . . . . . . . . . . . . . . . . . 28 102 Appendix A. Selected Information from DO-350A . . . . . . . . . 34 103 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 36 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 the Reliable and Available Wireless (RAW) working 172 group, developing options, such as intelligent switching between 173 datalinks, for reliably delivering content from and to endpoints, is 174 foreseen. As LDACS is part of such a concept, the work of RAW is 175 immediately applicable. In general, with the aeronautical 176 communications system transitioning to ATN/IPS, and data being 177 transported via IPv6, closer cooperation and collaboration between 178 the aeronautical and IETF community is desirable. 180 LDACS standardization within the framework of ICAO started in 181 December 2016. The ICAO standardization group has produced an 182 initial Standards and Recommended Practices (SARPS) document 183 [ICA2018]. It defines the general characteristics of LDACS. The 184 ICAO standardization group plans to produce an ICAO technical manual 185 - the ICAO equivalent to a technical standard - within the next 186 years. Generally, the group is open to input from all sources and 187 encourages cooperation between the aeronautical and the IETF 188 community. 190 2. Terminology 192 The following terms are used in the context of RAW in this document: 194 A/A Air/Air 195 A/G Air/Ground 196 A2G Air-to-Ground 197 ACARS Aircraft Communications Addressing and Reporting System 198 ADS-B Automatic Dependent Surveillance - Broadcast 199 ADS-C Automatic Dependent Surveillance - Contract 200 AeroMACS Aeronautical Mobile Airport Communications System 201 ANSP Air Traffic Network Service Provider 202 AOC Aeronautical Operational Control 203 AR Access Router 204 ARINC Aeronautical Radio, Incorporated 205 ARQ Automatic Repeat reQuest 206 AS Aircraft Station 207 ATC Air Traffic Control 208 ATM Air Traffic Management 209 ATN Aeronautical Telecommunication Network 210 ATS Air Traffic Service 211 BCCH Broadcast Channel 212 CCCH Common Control Channel 213 CM Context Management 214 CNS Communication Navigation Surveillance 215 COTS Commercial Off-The-Shelf 216 CPDLC Controller Pilot Data Link Communications 217 CRL Certificate Revocation List 218 CSP Communications Service Provider 219 DCCH Dedicated Control Channel 220 DCH Data Channel 221 DiffServ Differentiated Services 222 DLL Data Link Layer 223 DLS Data Link Service 224 DME Distance Measuring Equipment 225 DSB-AM Double Side-Band Amplitude Modulation 226 DTLS Datagram Transport Layer Security 227 EUROCAE European Organization for Civil Aviation Equipment 228 FAA Federal Aviation Administration 229 FCI Future Communications Infrastructure 230 FDD Frequency Division Duplex 231 FL Forward Link 232 GANP Global Air Navigation Plan 233 GBAS Ground Based Augmentation System 234 GNSS Global Navigation Satellite System 235 GS Ground-Station 236 G2A Ground-to-Air 237 HF High Frequency 238 ICAO International Civil Aviation Organization 239 IP Internet Protocol 240 IPS Internet Protocol Suite 241 kbit/s kilobit per second 242 LDACS L-band Digital Aeronautical Communications System 243 LLC Logical Link Control 244 LME LDACS Management Entity 245 MAC Medium Access Control 246 MF Multi Frame 247 OFDM Orthogonal Frequency-Division Multiplexing 248 OFDMA Orthogonal Frequency-Division Multiplexing Access 249 OSI Open Systems Interconnection 250 PHY Physical Layer 251 QPSK Quadrature Phase-Shift Keying 252 RACH Random Access Channel 253 RL Reverse Link 254 RTCA Radio Technical Commission for Aeronautics 255 SARPS Standards and Recommended Practices 256 SDR Software Defined Radio 257 SESAR Single European Sky ATM Research 258 SF Super-Frame 259 SNP Sub-Network Protocol 260 VDLm2 VHF Data Link mode 2 261 VHF Very High Frequency 262 VI Voice Interface 264 3. Motivation and Use Cases 266 Aircraft are currently connected to Air Traffic Control (ATC) and 267 Aeronautical Operational Control (AOC) services via voice and data 268 communications systems through all phases of flight. ATC refers to 269 communication for flight guidance. AOC is a generic term referring 270 to the business communication of airlines. It refers to the mostly 271 proprietary exchange of data between the aircraft of the airline, its 272 operation centers, and its service partners. ARINC document 633 was 273 developed and first released in 2007 [ARI2019] with the goal to 274 standardize these messages for interoperability, e.g., messages 275 between the airline and fueling or de-icing companies. Within the 276 airport terminal, connectivity is focused on high bandwidth 277 communications, while during en-route, high reliability, robustness, 278 and range is the main focus. Voice communications may use the same 279 or different equipment as data communications systems. In the 280 following, the main differences between voice and data communications 281 capabilities are summarized. The assumed use cases for LDACS 282 complements the list of use cases stated in [RAW-USE-CASES] and the 283 list of reliable and available wireless technologies presented in 284 [RAW-TECHNOS]. 286 3.1. Voice Communications Today 288 Voice links are used for Air/Ground (A/G) and Air/Air (A/A) 289 communications. The communications equipment is either ground-based 290 working in the High Frequency (HF) or VHF frequency band or 291 satellite-based. All VHF and HF voice communications are operated 292 via open broadcast channels without authentication, encryption or 293 other protective measures. The use of well-proven communications 294 procedures via broadcast channels, such as phraseology or read-backs, 295 requiring well-trained personnel, help to enhance the safety of 296 communications, but does not replace necessary cryptographical 297 security mechanisms. The main voice communications media is still 298 the analogue VHF Double Side-Band Amplitude Modulation (DSB-AM) 299 communications technique, supplemented by HF single side-band 300 amplitude modulation and satellite communications for remote and 301 oceanic regions. DSB-AM has been in use since 1948, works reliably 302 and safely, and uses low-cost communication equipment. These are the 303 main reasons why VHF DSB-AM communications are still in use, and it 304 is likely that this technology will remain in service for many more 305 years. This however, results in current operational limitations and 306 impediments in deploying new ATM applications, such as flight-centric 307 operation with point-to-point communications between pilots and air 308 traffic control officers. [BOE2019] 310 3.2. Data Communications Today 312 Like for voice, data communications into the cockpit, are currently 313 provided by ground-based equipment operating either on HF or VHF 314 radio bands or by legacy satellite systems. All these communication 315 systems are using narrowband radio channels with a data throughput 316 capacity in the order of kilobits per second. While the aircraft is 317 on ground, some additional communications systems are available, like 318 the Aeronautical Mobile Airport Communications System (AeroMACS) or 319 public cellular networks, operating in the Airport (APT) domain and 320 able to deliver broadband communications capability. [BOE2019] 321 For regulatory reasons, the data communications networks, used for 322 the transmission of data relating to the safety and regularity of 323 flight, must be strictly isolated from those providing entertainment 324 services to passengers. This leads to a situation that the flight 325 crews are supported by narrowband services during flight while 326 passengers have access to inflight broadband services. The current 327 HF and VHF data links cannot provide broadband services now or in the 328 future, due to the lack of available spectrum. This technical 329 shortcoming is becoming a limitation to enhanced ATM operations, such 330 as trajectory-based operations and 4D trajectory negotiations. 331 [BOE2019] 333 Satellite-based communications are currently under investigation and 334 enhanced capabilities are under development which will be able to 335 provide inflight broadband services and communications supporting the 336 safety and regularity of flight. In parallel the ground-based 337 broadband data link technology LDACS is being standardized by ICAO 338 and has recently shown its maturity during flight tests [MAE20211] 339 [BEL2021]. The LDACS technology is scalable, secure and spectrum 340 efficient and provides significant advantages to the users and 341 service providers. It is expected that both - satellite systems and 342 LDACS - will be deployed to support the future aeronautical 343 communication needs as envisaged by the ICAO Global Air Navigation 344 Plan (GNAP). [BOE2019] 346 4. Provenance and Documents 348 The development of LDACS has already made substantial progress in the 349 Single European Sky ATM Research (SESAR) framework and is currently 350 being continued in the follow-up program SESAR2020 [RIH2018]. A key 351 objective of these activities is to develop, implement and validate a 352 modern aeronautical data link able to evolve with aviation needs over 353 long-term. To this end, an LDACS specification has been produced 354 [GRA2020] and is continuously updated; transmitter demonstrators were 355 developed to test the spectrum compatibility of LDACS with legacy 356 systems operating in the L-band [SAJ2014]; and the overall system 357 performance was analyzed by computer simulations, indicating that 358 LDACS can fulfil the identified requirements [GRA2011]. 360 Up to now LDACS standardization has been focused on the development 361 of the physical layer and the data link layer. Only recently have 362 higher layers have come into the focus of the LDACS development 363 activities. There is currently no "IPv6 over LDACS" specification 364 publicly available; however, SESAR2020 has started the testing of 365 IPv6-based LDACS testbeds. 367 The IPv6 architecture for the aeronautical telecommunication network 368 is called the FCI. The FCI will support quality of service, 369 diversity, and mobility under the umbrella of the "multi-link 370 concept". This work is led by ICAO Communication Panel working group 371 WG-I. 373 In addition to standardization activities several industrial LDACS 374 prototypes have been built. One set of LDACS prototypes has been 375 evaluated in flight trials confirming the theoretical results 376 predicting the system performance [GRA2018] [MAE20211] [BEL2021]. 378 5. Applicability 380 LDACS is a multi-application cellular broadband system capable of 381 simultaneously providing various kinds of Air Traffic Services (ATS) 382 including ATS-B3, and AOC communications services from deployed 383 Ground-Stations (GS). The physical layer and data link layer of 384 LDACS are optimized for controller-pilot data link communications, 385 but the system also supports digital air-ground voice communications. 387 LDACS supports communications in all airspaces (airport, terminal 388 maneuvering area, and en-route), and on the airport surface. The 389 physical LDACS cell coverage is effectively de-coupled from the 390 operational coverage required for a particular service. This is new 391 in aeronautical communications. Services requiring wide-area 392 coverage can be installed at several adjacent LDACS cells. The 393 handover between the involved LDACS cells is seamless, automatic, and 394 transparent to the user. Therefore, the LDACS communications concept 395 enables the aeronautical communication infrastructure to support 396 future dynamic airspace management concepts. 398 5.1. Advances Beyond the State-of-the-Art 400 LDACS offers several capabilities, not yet provided in contemporarily 401 deployed aeronautical communications systems. 403 5.1.1. Priorities 405 LDACS is able to manage service priorities, an important feature not 406 available in some of the current data link deployments. Thus, LDACS 407 guarantees bandwidth availability, low latency, and high continuity 408 of service for safety critical ATS applications while simultaneously 409 accommodating less safety-critical AOC services. 411 5.1.2. Security 413 LDACS is a secure data link with built-in security mechanisms. It 414 enables secure data communications for ATS and AOC services, 415 including secured private communications for aircraft operators and 416 Air traffic Network Service Providers (ANSP). This includes concepts 417 for key and trust management, mutual authentication and key 418 establishment protocols, key derivation measures, user and control 419 message-in-transit protection, secure logging and availability and 420 robustness measures [MAE20182] [MAE2021]. 422 5.1.3. High Data Rates 424 The user data rate of LDACS is 315 kbit/s to 1428 kbit/s on the 425 Forward Link (FL) for the Ground-to-Air (G2A) connection, and 294 426 kbit/s to 1390 kbit/s on the Reverse Link (RL) for the Air-to-Ground 427 (A2G) connection, depending on coding and modulation. This is up to 428 two orders of magnitude greater than current terrestrial digital 429 aeronautical communications systems, such as the VHF Data Link mode 2 430 (VDLm2), provide [ICAO2019] [GRA2020]. 432 5.2. Application 434 LDACS will be used by several aeronautical applications ranging from 435 enhanced communications protocol stacks (multi-homed mobile IPv6 436 networks in the aircraft and potentially ad-hoc networks between 437 aircraft) to broadcast communication applications (sending Ground 438 Based Augmentation System (GBAS) correction data) and integration 439 with other service domains (using the communications signal for 440 navigation) [MAE20211]. 442 5.2.1. Air/Ground Multilink 444 It is expected that LDACS, together with upgraded satellite-based 445 communications systems, will be deployed within the FCI and 446 constitute one of the main components of the multilink concept within 447 the FCI. 449 Both technologies, LDACS and satellite systems, have their specific 450 benefits and technical capabilities which complement each other. 451 Especially, satellite systems are well-suited for large coverage 452 areas with less dense air traffic, e.g. oceanic regions. LDACS is 453 well-suited for dense air traffic areas, e.g., continental areas or 454 hot-spots around airports and terminal airspace. In addition, both 455 technologies offer comparable data link capacity and, thus, are well- 456 suited for redundancy, mutual back-up, or load balancing. 458 Technically the FCI multilink concept will be realized by multi- 459 homed mobile IPv6 networks in the aircraft. The related protocol 460 stack is currently under development by ICAO, within SESAR, and the 461 IETF [I-D.haindl-lisp-gb-atn] [I-D.ietf-rtgwg-atn-bgp]. 463 5.2.2. Air/Air Extension for LDACS 465 A potential extension of the multi-link concept is its extension to 466 the integration of ad-hoc networks between aircraft. 468 Direct A/A communication between aircraft in terms of ad-hoc data 469 networks are currently considered a research topic since there is no 470 immediate operational need for it, although several possible use 471 cases are discussed (Automatic Dependent Surveillance - Broadcast 472 (ADS-B), digital voice, wake vortex warnings, and trajectory 473 negotiation) [BEL2019]. It should also be noted, that currently 474 deployed analog VHF voice radios support direct voice communication 475 between aircraft, making a similar use case for digital voice 476 plausible. 478 LDACS A/A is currently not part of the standardization process and 479 will not be covered within this document. 481 5.2.3. Flight Guidance 483 The FCI (and therefore LDACS) is used to provide flight guidance. 484 This is realized using three applications: 486 1. Context Management (CM): The CM application manages the automatic 487 logical connection to the ATC center currently responsible to 488 guide the aircraft. Currently this is done by the air crew 489 manually changing VHF voice frequencies according to the progress 490 of the flight. The CM application automatically sets up 491 equivalent sessions. 492 2. Controller Pilot Data Link Communications (CPDLC): The CPDLC 493 application provides the air crew with the ability to exchange 494 data messages similar to text messages with the currently 495 responsible ATC center. The CPDLC application takes over most of 496 the communication currently performed over VHF voice and enables 497 new services that do not lend themselves to voice communication 498 (i.e., trajectory negotiation). 499 3. Automatic Dependent Surveillance - Contract (ADS-C): ADS-C 500 reports the position of the aircraft to the currently active ATC 501 center. Reporting is bound to "contracts", i.e., pre-defined 502 events related to the progress of the flight (i.e., the 503 trajectory). ADS-C and CPDLC are the primary applications used 504 for implementing in-flight trajectory management. 506 CM, CPDLC, and ADS-C are available on legacy datalinks, but are not 507 widely deployed and with limited functionality. 509 Further ATC applications may be ported to use the FCI or LDACS as 510 well. A notable application is GBAS for secure, automated landings: 511 The Global Navigation Satellite System (GNSS) based GBAS is used to 512 improve the accuracy of GNSS to allow GNSS based instrument landings. 513 This is realized by sending GNSS correction data (e.g., compensating 514 ionospheric errors in the GNSS signal) to the aircraft's GNSS 515 receiver via a separate data link. Currently the VDB data link is 516 used. VDB is a narrow-band single-purpose datalink without advanced 517 security only used to transmit GBAS correction data. This makes VDB 518 a natural candidate for replacement by LDACS [MAE20211]. 520 5.2.4. Business Communications of Airlines 522 In addition to air traffic services, AOC services are transmitted 523 over LDACS. AOC is a generic term referring to the business 524 communication of airlines, between the airlines and service partners 525 on the ground and their own aircraft in the air. Regulatory-wise, 526 this is considered related to safety and regularity of flight and may 527 therefore be transmitted over LDACS. AOC communication is considered 528 the main business case for LDACS communications service providers 529 since modern aircraft generate significant amounts of data (e.g., 530 engine maintenance data). 532 5.2.5. LDACS-based Navigation 534 Beyond communications, radio signals can always also be used for 535 navigation. This fact is used for the LDACS navigation concept. 537 For future aeronautical navigation, ICAO recommends the further 538 development of GNSS based technologies as primary means for 539 navigation. Due to the large separation between navigational 540 satellites and aircraft, the power of the GNSS signals received by 541 the aircraft is, however, very low. As a result, GNSS disruptions 542 might occasionally occur due to unintentional interference, or 543 intentional jamming. Yet the navigation services must be available 544 with sufficient performance for all phases of flight. Therefore, 545 during GNSS outages, or blockages, an alternative solution is needed. 546 This is commonly referred to as Alternative Positioning, Navigation, 547 and Timing (APNT). 549 One of such APNT solutions consists of exploiting the built-in 550 navigation capabilities of LDACS operation. That is, the normal 551 operation of LDACS for ATC and AOC communications would also directly 552 enable the aircraft to navigate and obtain a reliable timing 553 reference from the LDACS GSs. 555 LDACS navigation has already been demonstrated in practice in two 556 flight measurement campaigns [SHU2013] [BEL2021] [MAE20211]. . 558 6. Requirements 560 The requirements for LDACS are mostly defined by its application 561 area: Communications related to safety and regularity of flight. 563 A particularity of the current aeronautical communication landscape 564 is that it is heavily regulated. Aeronautical data links (for 565 applications related to safety and regularity of flight) may only use 566 spectrum licensed to aviation and data links endorsed by ICAO. 567 Nation states can change this locally, however, due to the global 568 scale of the air transportation system, adherence to these practices 569 is to be expected. 571 Aeronautical data links for the ATN are therefore expected to remain 572 in service for decades. The VDLm2 data link currently used for 573 digital terrestrial internetworking was developed in the 1990ies (the 574 use of the Open Systems Interconnection (OSI) stack indicates that as 575 well). VDLm2 is expected to be used at least for several decades. 576 In this respect aeronautical communications (for applications related 577 to safety and regularity of flight) is more comparable to industrial 578 applications than to the open Internet. 580 Internetwork technology is already installed in current aircraft. 581 Current ATS applications use either Aircraft Communications 582 Addressing and Reporting System (ACARS) or the OSI stack. The 583 objective of the development effort of LDACS, as part of the FCI, is 584 to replace legacy OSI stack and proprietary ACARS internetwork 585 technologies with industry standard IP technology. It is anticipated 586 that the use of Commercial Off-The-Shelf (COTS) IP technology mostly 587 applies to the ground network. The avionics networks on the aircraft 588 will likely be heavily modified versions of Ethernet or proprietary. 590 AOC applications currently mostly use the same stack (although some 591 applications, like the graphical weather service may use the 592 commercial passenger network). This creates capacity problems 593 (resulting in excessive amounts of timeouts) since the underlying 594 terrestrial data links do not provide sufficient bandwidth (i.e., 595 with VDLm2 currently in the order of 10 kbit/s). The use of non- 596 aviation specific data links is considered a security problem. 597 Ideally the aeronautical IP internetwork, hence the ATN over which 598 only communications related to safety and regularity of flight is 599 handled, and the Internet should be completely separated at Layer 3. 601 The objective of LDACS is to provide a next generation terrestrial 602 data link designed to support IP addressing and provide much higher 603 bandwidth to avoid the currently experienced operational problems. 605 The requirement for LDACS is therefore to provide a terrestrial high- 606 throughput data link for IP internetworking in the aircraft. 608 In order to fulfil the above requirement LDACS needs to be 609 interoperable with IP (and IP-based services like Voice-over-IP) at 610 the gateway connecting the LDACS network to other aeronautical ground 611 networks (i.e., the ATN). On the avionics side, in the aircraft, 612 aviation specific solutions are to be expected. 614 In addition to these functional requirements, LDACS and its IP stack 615 need to fulfil the requirements defined in RTCA DO-350A/EUROCAE ED- 616 228A [DO350A]. This document defines continuity, availability, and 617 integrity requirements at different scopes for each air traffic 618 management application (CPDLC, CM, and ADS-C). The scope most 619 relevant to IP over LDACS is the Communications Service Provider 620 (CSP) scope. 622 Continuity, availability, and integrity requirements are defined in 623 [DO350A] volume 1 Table 5-14, and Table 6-13. Appendix A presents 624 the required information. 626 In a similar vein, requirements to fault management are defined in 627 the same tables. 629 7. Characteristics 631 LDACS will become one of several wireless access networks connecting 632 aircraft to the ATN implemented by the FCI. 634 The current LDACS design is focused on the specification of layer one 635 and two. However, for the purpose of this work, only layer two 636 details are discussed here. 638 Achieving the stringent continuity, availability, and integrity 639 requirements defined in [DO350A] will require the specification of 640 layer 3 and above mechanisms (e.g. reliable crossover at the IP 641 layer). Fault management mechanisms are similarly undefined. 643 7.1. LDACS Sub-Network 645 An LDACS sub-network contains an Access Router (AR) and several GS, 646 each of them providing one LDACS radio cell. 648 User plane interconnection to the ATN is facilitated by the AR 649 peering with an A/G Router connected to the ATN. 651 The internal control plane of an LDACS sub-network interconnects the 652 GSs. An LDACS sub-network is illustrated in Figure 1. 654 wireless user 655 link plane 656 AS-------------GS---------------AR---A/G-----ATN 657 . | Router 658 . control | 659 . plane | 660 . | 661 GS---------------| 662 . | 663 . | 664 GS---------------+ 666 Figure 1: LDACS sub-network with three GSs and one AS 668 7.2. Topology 670 LDACS is a cellular point-to-multipoint system. It assumes a star- 671 topology in each cell where Aircraft Stations (AS) belonging to 672 aircraft within a certain volume of space (the LDACS cell) is 673 connected to the controlling GS. The LDACS GS is a centralized 674 instance that controls LDACS A/G communications within its cell. The 675 LDACS GS can simultaneously support multiple bi-directional 676 communications to the ASs under its control. LDACS's GSs themselves 677 are connected to each other and the AR. 679 Prior to utilizing the system an aircraft has to register with the 680 controlling GS to establish dedicated logical channels for user and 681 control data. Control channels have statically allocated resources, 682 while user channels have dynamically assigned resources according to 683 the current demand. Logical channels exist only between the GS and 684 the AS. 686 7.3. LDACS Protocol Stack 688 The protocol stack of LDACS is implemented in the AS and GS: It 689 consists of the Physical Layer (PHY) with five major, functional 690 blocks above it. Four are placed in the Data Link Layer (DLL) of the 691 AS and GS: (1) Medium Access Control (MAC) Layer, (2) Voice Interface 692 (VI), (3) Data Link Service (DLS), and (4) LDACS Management Entity 693 (LME). The last entity resides within the sub-network layer: the 694 Sub-Network Protocol (SNP). The LDACS network is externally 695 connected to voice units, radio control units, and the ATN network 696 layer. 698 LDACS is considered an ATN/IPS radio access technology, from the view 699 of ICAO's regulatory framework. Hence, the interface between ATN and 700 LDACS must be IPv6 based, as regulatory documents, such as ICAO Doc 701 9896 [ICAO2015] and DO-379 [RTCA2019] clearly foresee that. The 702 translation between IPv6 layer and SNP layer is currently subject of 703 ongoing standardization efforts and at the time of writing not 704 finished yet. 706 Figure 2 shows the protocol stack of LDACS as implemented in the AS 707 and GS. Acronyms used here are introduced throughout the upcoming 708 sections. 710 IPv6 Network Layer 711 | 712 | 713 +------------------+ +----+ 714 | SNP |--| | Sub-Network 715 | | | | Layer 716 +------------------+ | | 717 | | LME| 718 +------------------+ | | 719 | DLS | | | LLC Layer 720 +------------------+ +----+ 721 | | 722 DCH DCCH/CCCH 723 | RACH/BCCH 724 | | 725 +--------------------------+ 726 | MAC | Medium Access 727 | | Layer 728 +--------------------------+ 729 | 730 +--------------------------+ 731 | PHY | Physical Layer 732 +--------------------------+ 733 | 734 | 735 ((*)) 736 FL/RL radio channels 737 separated by FDD 739 Figure 2: LDACS protocol stack in AS and GS 741 7.3.1. LDACS Physical Layer 743 The physical layer provides the means to transfer data over the radio 744 channel. The LDACS GS supports bi-directional links to multiple 745 aircraft under its control. The FL direction at the G2A connection 746 and the RL direction at the A2G connection are separated by Frequency 747 Division Duplex (FDD). FL and RL use a 500 kHz channel each. The GS 748 transmits a continuous stream of Orthogonal Frequency-Division 749 Multiplexing Access (OFDM) symbols on the FL. In the RL different 750 aircraft are separated in time and frequency using Orthogonal 751 Frequency-Division Multiple Access (OFDMA). Aircraft thus transmit 752 discontinuously on the RL via short radio bursts sent in precisely 753 defined transmission opportunities allocated by the GS. 755 7.3.2. LDACS Data Link Layer 757 The data-link layer provides the necessary protocols to facilitate 758 concurrent and reliable data transfer for multiple users. The LDACS 759 data link layer is organized in two sub-layers: The medium access 760 sub-layer and the Logical Link Control (LLC) sub-layer. The medium 761 access sub-layer manages the organization of transmission 762 opportunities in slots of time and frequency. The LLC sub-layer 763 provides acknowledged point-to-point logical channels between the 764 aircraft and the GS using an Automatic Repeat reQuest (ARQ) protocol. 765 LDACS supports also unacknowledged point-to-point channels and G2A 766 Broadcast transmission. 768 7.3.2.1. Medium Access Control (MAC) Services 770 The MAC time framing service provides the frame structure necessary 771 to realize slot-based time-division multiplex-access on the physical 772 link. It provides the functions for the synchronization of the MAC 773 framing structure and the PHY Layer framing. The MAC time framing 774 provides a dedicated time slot for each logical channel. 776 The MAC sub-layer offers access to the physical channel to its 777 service users. Channel access is provided through transparent 778 logical channels. The MAC sub-layer maps logical channels onto the 779 appropriate slots and manages the access to these channels. Logical 780 channels are used as interface between the MAC and LLC sub-layers. 782 7.3.2.2. Data Link Service (DLS) Services 784 The DLS provides acknowledged and unacknowledged (including broadcast 785 and packet mode voice) bi-directional exchange of user data. If user 786 data is transmitted using the acknowledged DLS, the sending DLS 787 entity will wait for an acknowledgement from the receiver. If no 788 acknowledgement is received within a specified time frame, the sender 789 may automatically try to retransmit its data. However, after a 790 certain number of failed retries, the sender will suspend further 791 retransmission attempts and inform its client of the failure. 793 The DLS uses the logical channels provided by the MAC: 795 1. A GS announces its existence and access parameters in the 796 Broadcast Channel (BCCH). 797 2. The Random Access Channel (RACH) enables AS to request access to 798 an LDACS cell. 799 3. In the FL the Common Control Channel (CCCH) is used by the GS to 800 grant access to data channel resources. 801 4. The reverse direction is covered by the RL, where ASs need to 802 request resources before sending. This happens via the Dedicated 803 Control Channel (DCCH). 804 5. User data itself is communicated in the Data Channel (DCH) on the 805 FL and RL. 807 Access to the FL and RL data channel is granted by the scheduling 808 mechanism implemented in the LME discussed below. 810 7.3.2.3. Voice Interface (VI) Services 812 The VI provides support for virtual voice circuits. Voice circuits 813 may either be set-up permanently by the GS (e.g., to emulate voice 814 party line) or may be created on demand. 816 7.3.2.4. LDACS Management Entity (LME) Services 818 The mobility management service in the LME provides support for 819 registration and de-registration (cell entry and cell exit), scanning 820 RF channels of neighboring cells and handover between cells. In 821 addition, it manages the addressing of aircraft within cells. 823 The resource management service provides link maintenance (power, 824 frequency and time adjustments), support for adaptive coding and 825 modulation, and resource allocation. 827 The resource management service accepts resource requests from/for 828 different AS and issues resource allocations accordingly. While the 829 scheduling algorithm is not specified and a point of possible vendor 830 differentiation, it is subject to the following requirements: 832 1. Resource scheduling must provide channel access according to the 833 priority of the request 834 2. Resource scheduling must support "one-time" requests. 835 3. Resource scheduling must support "permanent" requests that 836 reserve a resource until the request is canceled e.g. for digital 837 voice circuits. 839 7.3.3. LDACS Sub-Network Layer and Protocol Services 841 Lastly, the SNP handles the transition from IPv6 packts to LDACS 842 internal packet structures. This work is ongoing and not part of 843 this document. The DLS provides functions required for the transfer 844 of user plane data and control plane data over the LDACS sub-network. 845 The security service provides functions for secure user data 846 communication over the LDACS sub-network. Note that the SNP security 847 service applies cryptographic measures as configured by the GS. 849 7.4. LDACS Mobility 851 LDACS supports layer 2 handovers to different LDACS cells. Handovers 852 may be initiated by the aircraft (break-before-make) or by the GS 853 (make-before-break). Make-before-break handovers are only supported 854 between GSs connected to each other. 856 External handovers between non-connected LDACS sub-networks or 857 different aeronautical data links are handled by the FCI multi- link 858 concept. 860 8. Reliability and Availability 862 8.1. Below Layer 1 864 Below Layer 2, aeronautics usually relies on hardware redundancy. To 865 protect availability of the LDACS link, an aircraft equipped with 866 LDACS will have access to two L-band antennae with triple redundant 867 radio systems as required for any safety relevant aeronautical 868 systems by ICAO. 870 8.2. Layer 1 and 2 872 LDACS has been designed with applications related to the safety and 873 regularity of flight in mind. It has therefore been designed as a 874 deterministic wireless data link (as far as this is possible). 876 Based on channel measurements of the L-band channel LDACS was 877 designed from the PHY layer up with robustness in mind. Channel 878 measurements of the L-band channel [SCH2016] confirmed LDACS to be 879 well adapted to its channel. 881 In order to maximize the capacity per channel and to optimally use 882 the available spectrum, LDACS was designed as an OFDM-based FDD 883 system, supporting simultaneous transmissions in FL in the G2A 884 connection and RL in the A2G connection. The legacy systems already 885 deployed in the L-band limit the bandwidth of both channels to 886 approximately 500 kHz. 888 The LDACS physical layer design includes propagation guard times 889 sufficient for the operation at a maximum distance of 200 nautical 890 miles from the GS. In actual deployment, LDACS can be configured for 891 any range up to this maximum range. 893 The LDACS physical layer supports adaptive coding and modulation for 894 user data. Control data is always encoded with the most robust 895 coding and modulation (FL: Quadrature Phase-Shift Keying (QPSK), 896 coding rate 1/2, RL: QPSK, coding rate 1/3). 898 LDACS medium access layer on top of the physical layer uses a static 899 frame structure to support deterministic timer management. As shown 900 in Figure 3 and Figure 4, LDACS framing structure is based on Super- 901 Frames (SF) of 240ms duration corresponding to 2000 OFDM symbols. FL 902 and RL boundaries are aligned in time (from the GS perspective) 903 allowing for deterministic slots for control and data channels. This 904 initial AS time synchronization and time synchronization maintenance 905 is based on observing the synchronization symbol pairs that 906 repetitively occur within the FL stream, being sent by the 907 controlling GS [GRA2020]. 909 ^ 910 | +------+------------+------------+------------+------------+ 911 | FL | BCCH | MF | MF | MF | MF | 912 F +------+------------+------------+------------+------------+ 913 r <---------------- Super-Frame (SF) - 240ms ----------------> 914 e 915 q +------+------------+------------+------------+------------+ 916 u RL | RACH | MF | MF | MF | MF | 917 e +------+------------+------------+------------+------------+ 918 n <---------------- Super-Frame (SF) - 240ms ----------------> 919 c 920 y 921 | 922 ----------------------------- Time ------------------------------> 923 | 925 Figure 3: SF structure for LDACS 927 ^ 928 | +-------------+------+-------------+ 929 | FL | DCH | CCCH | DCH | 930 F +-------------+------+-------------+ 931 r <---- Multi-Frame (MF) - 58.32ms --> 932 e 933 q +------+---------------------------+ 934 u RL | DCCH | DCH | 935 e +------+---------------------------+ 936 n <---- Multi-Frame (MF) - 58.32ms --> 937 c 938 y 939 | 940 -------------------- Time ------------------> 941 | 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 minimize latency and 987 overhead without losing reliability. It ensures correct order of 988 packet delivery without duplicates. In case of transmission errors, 989 it identifies lost fragments with deterministic timers synced to the 990 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. While the deployment of a larger number 1000 of small cells is one possible solution, this also suffers from the 1001 spectrum scarcity. 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 certainly highly desirable but needs to be adapted to the specific 1020 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 will need additional embedded security features to fulfill modern 1070 information security requirements like authentication and integrity. 1071 These security features require sufficient bandwidth which is beyond 1072 the capabilities of currently deployed VHF narrowband communications 1073 systems. For voice and data communications, sufficient data 1074 throughput capability is needed to support the security functions 1075 while not degrading performance. LDACS is a data link technology 1076 with sufficient bandwidth to incorporate security without losing too 1077 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 [GRA2020] 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 wireless link. 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 13. Informative References 1256 [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing 1257 Architecture", RFC 4291, DOI 10.17487/RFC4291, February 1258 2006, . 1260 [RFC4301] Kent, S. and K. Seo, "Security Architecture for the 1261 Internet Protocol", RFC 4301, DOI 10.17487/RFC4301, 1262 December 2005, . 1264 [RFC6012] Salowey, J., Petch, T., Gerhards, R., and H. Feng, 1265 "Datagram Transport Layer Security (DTLS) Transport 1266 Mapping for Syslog", RFC 6012, DOI 10.17487/RFC6012, 1267 October 2010, . 1269 [RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer 1270 Security Version 1.2", RFC 6347, DOI 10.17487/RFC6347, 1271 January 2012, . 1273 [RFC7136] Carpenter, B. and S. Jiang, "Significance of IPv6 1274 Interface Identifiers", RFC 7136, DOI 10.17487/RFC7136, 1275 February 2014, . 1277 [RFC7296] Kaufman, C., Hoffman, P., Nir, Y., Eronen, P., and T. 1278 Kivinen, "Internet Key Exchange Protocol Version 2 1279 (IKEv2)", STD 79, RFC 7296, DOI 10.17487/RFC7296, October 1280 2014, . 1282 [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol 1283 Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, 1284 . 1286 [GRA2020] Graeupl, T., Rihacek, C., and B. Haindl, "LDACS A/G 1287 Specification", SESAR2020 PJ14-02-01 D3.3.030 , 2020, 1288 . 1292 [ARI2021] ARINC, "Internet Protocol Suite (IPS) For Aeronautical 1293 Safety Services Part 1- Airborne IP System Technical 1294 Requirements, ARINC SPECIFICATION 858 P1", June 2021, 1295 . 1297 [EURO2019] European Organization for Civil Aviation Equipment 1298 (EUROCAE), "Technical Standard of Aviation Profiles for 1299 ATN/IPS, ED-262", September 2019, 1300 . 1303 [ICAO2015] International Civil Aviation Organization (ICAO), "Manual 1304 on the Aeronautical Telecommunication Network (ATN) using 1305 Internet Protocol Suite (IPS) Standards and Protocols, Doc 1306 9896", January 2015, 1307 . 1309 [RTCA2019] Radio Technical Commission for Aeronautics (RTCA), 1310 "Internet Protocol Suite Profiles, DO-379", September 1311 2019, . 1313 [SCH2016] Schneckenburger, N., Jost, T., Shutin, D., Walter, M., 1314 Thiasiriphet, T., Schnell, M., and U.C. Fiebig, 1315 "Measurement of the L-band Air-to-Ground Channel for 1316 Positioning Applications", IEEE Transactions on Aerospace 1317 and Electronic Systems, 52(5), pp.2281-229 , 2016. 1319 [MAE20191] Maeurer, N., Graeupl, T., and C. Schmitt, "Evaluation of 1320 the LDACS Cybersecurity Implementation", IEEE 38th Digital 1321 Avionics Systems Conference (DACS), pp. 1-10, San Diego, 1322 CA, USA , 2019. 1324 [MAE20192] Maeurer, N. and C. Schmitt, "Towards Successful 1325 Realization of the LDACS Cybersecurity Architecture: An 1326 Updated Datalink Security Threat- and Risk Analysis", IEEE 1327 Integrated Communications, Navigation and Surveillance 1328 Conference (ICNS), pp. 1-13, Herndon, VA, USA , 2019. 1330 [MAE20182] Maeurer, N. and A. Bilzhause, "A Cybersecurity 1331 Architecture for the L-band Digital Aeronautical 1332 Communications System (LDACS)", IEEE 37th Digital Avionics 1333 Systems Conference (DASC), pp. 1-10, London, UK , 2017. 1335 [GRA2011] Graeupl, T. and M. Ehammer, "L-DACS1 Data Link Layer 1336 Evolution of ATN/IPS", 30th IEEE/AIAA Digital Avionics 1337 Systems Conference (DASC), pp. 1-28, Seattle, WA, USA , 1338 2011. 1340 [GRA2018] Graeupl, T., Schneckenburger, N., Jost, T., Schnell, M., 1341 Filip, A., Bellido-Manganell, M.A., Mielke, D.M., Maeurer, 1342 N., Kumar, R., Osechas, O., and G. Battista, "L-band 1343 Digital Aeronautical Communications System (LDACS) flight 1344 trials in the national German project MICONAV", Integrated 1345 Communications, Navigation, Surveillance Conference 1346 (ICNS), pp. 1-7, Herndon, VA, USA , 2018. 1348 [ICA2018] International Civil Aviation Organization (ICAO), "L-Band 1349 Digital Aeronautical Communication System (LDACS)", 1350 International Standards and Recommended Practices Annex 10 1351 - Aeronautical Telecommunications, Vol. III - 1352 Communication Systems , 2018. 1354 [SAJ2014] Haindl, B., Meser, J., Sajatovic, M., Mueller, S., 1355 Arthaber, H., Faseth, T., and M. Zaisberger, "LDACS1 1356 Conformance and Compatibility Assessment", IEEE/AIAA 33rd 1357 Digital Avionics Systems Conference (DASC), pp. 1-11, 1358 Colorado Springs, CO, USA , 2014. 1360 [RIH2018] Rihacek, C., Haindl, B., Fantappie, P., Pierattelli, S., 1361 Graeupl, T., Schnell, M., and N. Fistas, "L-band Digital 1362 Aeronautical Communications System (LDACS) Activities in 1363 SESAR2020", Integrated Communications Navigation and 1364 Surveillance Conference (ICNS), pp. 1-8, Herndon, VA, 1365 USA , 2018. 1367 [BEL2019] Bellido-Manganell, M. A. and M. Schnell, "Towards Modern 1368 Air-to-Air Communications: the LDACS A2A Mode", IEEE/AIAA 1369 38th Digital Avionics Systems Conference (DASC), pp. 1-10, 1370 San Diego, CA, USA , 2019. 1372 [CRO2016] Crowe, B., "Proposed AeroMACS PKI Specification is a Model 1373 for Global and National Aeronautical PKI Deployments", 1374 WiMAX Forum at 16th Integrated Communications, Navigation 1375 and Surveillance Conference (ICNS), pp. 1-19, New York, 1376 NY, USA , 2016. 1378 [MAE2020] Maeurer, N., Graeupl, T., and C. Schmitt, "Comparing 1379 Different Diffie-Hellman Key Exchange Flavors for LDACS", 1380 IEEE/AIAA 39th Digital Avionics Systems Conference (DASC), 1381 pp. 1-10, San Antonio, TX, USA , 2020. 1383 [STR2016] Strohmeier, M., Schaefer, M., Pinheiro, R., Lenders, V., 1384 and I. Martinovic, "On Perception and Reality in Wireless 1385 Air Traffic Communication Security", IEEE Transactions on 1386 Intelligent Transportation Systems, 18(6), pp. 1338-1357, 1387 New York, NY, USA , 2016. 1389 [BIL2017] Bilzhause, A., Belgacem, B., Mostafa, M., and T. Graeupl, 1390 "Datalink Security in the L-band Digital Aeronautical 1391 Communications System (LDACS) for Air Traffic Management", 1392 IEEE Aerospace and Electronic Systems Magazine, 32(11), 1393 pp. 22-33, New York, NY, USA , 2017. 1395 [MAE20181] Maeurer, N. and A. Bilzhause, "Paving the Way for an IT 1396 Security Architecture for LDACS: A Datalink Security 1397 Threat and Risk Analysis", IEEE Integrated Communications, 1398 Navigation, Surveillance Conference (ICNS), pp. 1-11, New 1399 York, NY, USA , 2018. 1401 [FAA2020] FAA, "Federal Aviation Administration. ADS-B Privacy.", 1402 August 2020, 1403 . 1405 [GNU2021] GNU Radio project, "GNU radio", October 2021, 1406 . 1408 [SIT2020] SITA, "Societe Internationale de Telecommunications 1409 Aeronautiques", August 2020, . 1411 [ARI2020] ARINC, "Aeronautical Radio Incorporated", August 2020, 1412 . 1414 [DO350A] RTCA SC-214, "Safety and Performance Standard for Baseline 1415 2 ATS Data Communications (Baseline 2 SPR Standard)", May 1416 2016, . 1419 [ICAO2019] International Civil Aviation Organization (ICAO), "Manual 1420 on VHF Digital Link (VDL) Mode 2, Doc 9776", January 2019, 1421 . 1424 [KAMA2010] Kamali, B., "An Overview of VHF Civil Radio Network and 1425 the Resolution of Spectrum Depletion", Integrated 1426 Communications, Navigation, and Surveillance Conference, 1427 pp. F4-1-F4-8 , May 2010. 1429 [SON2021] Soni, D., Basu, K., Nabeel, M., Aaraj, N., Manzano, M., 1430 and R. Karri, "FALCON", Hardware Architectures for Post- 1431 Quantum Digital Signature Schemes, pp. 31-41 , November 1432 2021. 1434 [SIK2021] SIKE, "SIKE – Supersingular Isogeny Key Encapsulation", 1435 October 2021, . 1437 [ROY2020] Roy, S.S.. and A. Basso, "High-Speed Instruction-Set 1438 Coprocessor For Lattice-Based Key Encapsulation Mechanism: 1439 Saber In Hardware", IACR Transactions on Cryptographic 1440 Hardware and Embedded Systems, 443-466. , August 2020. 1442 [RAW-TECHNOS] 1443 Thubert, P., Cavalcanti, D., Vilajosana, X., Schmitt, C., 1444 and J. Farkas, "Reliable and Available Wireless 1445 Technologies", Work in Progress, Internet-Draft, draft- 1446 ietf-raw-technologies-05, 2 February 2022, 1447 . 1450 [RAW-USE-CASES] 1451 Bernardos, C. J., Papadopoulos, G. Z., Thubert, P., and F. 1452 Theoleyre, "RAW use-cases", Work in Progress, Internet- 1453 Draft, draft-ietf-raw-use-cases-05, 23 February 2022, 1454 . 1457 [I-D.haindl-lisp-gb-atn] 1458 Haindl, B., Lindner, M., Rahman, R., Comeras, M. P., 1459 Moreno, V., Maino, F., and B. Venkatachalapathy, "Ground- 1460 Based LISP for the Aeronautical Telecommunications 1461 Network", Work in Progress, Internet-Draft, draft-haindl- 1462 lisp-gb-atn-06, 6 March 2021, 1463 . 1466 [I-D.ietf-rtgwg-atn-bgp] 1467 Templin, F. L., Saccone, G., Dawra, G., Lindem, A., and V. 1468 Moreno, "A Simple BGP-based Mobile Routing System for the 1469 Aeronautical Telecommunications Network", Work in 1470 Progress, Internet-Draft, draft-ietf-rtgwg-atn-bgp-14, 14 1471 February 2022, . 1474 [ICAO2018] International Civil Aviation Organization (ICAO), 1475 "Handbook on Radio Frequency Spectrum Requirements for 1476 Civil Aviation, Doc 9718, Volume 1, ICAO Spectrum 1477 Strategy, Policy Statements and Related Information", July 1478 2018, . 1481 [ARI2019] ARINC, "AOC Air-Ground Data And Message Exchange Format, 1482 ARINC 633", January 2019, 1483 . 1486 [VIR2021] Virdia, A., Stea, G., and G. Dini, "SAPIENT: Enabling 1487 Real-Time Monitoring and Control in the Future 1488 Communication Infrastructure of Air Traffic Management", 1489 IEEE Transactions on Intelligent Transportation Systems, 1490 22(8):4864-4875 , August 2021. 1492 [SHU2013] Shutin, D., Schneckenburger, N., Walter, M., and M. 1493 Schnell, "LDACS1 Ranging Performance - An Analysis Of 1494 Flight Measurement Results", IEEE 32th Digital Avionics 1495 Systems Conference (DASC), pp. 1-10, East Syracuse, NY, 1496 USA , October 2013. 1498 [BEL2021] Bellido-Manganell, M.A., Graeupl, T., Heirich, O., 1499 Maeurer, N., Filip-Dhaubhadel, A., Mielke, D.M., Schalk, 1500 L.M., Becker, D., Schneckenburger, N., and M. Schnell, 1501 "LDACS Flight Trials: Demonstration and Performance 1502 Analysis of the Future Aeronautical Communications 1503 System", IEEE Transactions on Aerospace and Electronic 1504 Systems, pp. 1-19 , September 2021. 1506 [MAE2021] Maeurer, N., Graeupl, T., Gentsch, C., Guggemos, T., 1507 Tiepelt, M., Schmitt, C., and G. Dreo Rodosek, "A Secure 1508 Cell-Attachment Procedure for LDACS", 1st Workshop on 1509 Secure and Reliable Communication and Navigation in the 1510 Aerospace Domain (SRCNAS), pp. 1-10, Vienna, Austria , 1511 September 2021. 1513 [MAE20211] Maeurer, N., Graeupl, T., Bellido-Manganell, M.A., Mielke, 1514 D.M., Filip-Dhaubhadel, A., Heirich, O., Gerberth, D., 1515 Flux, M., Schalk, L.M., Becker, D., Schneckenburger, N., 1516 and M. Schnell, "Flight Trial Demonstration of Secure GBAS 1517 via the L-band Digital Aeronautical Communications System 1518 (LDACS)", IEEE Aerospace and Electronic Systems Magazine, 1519 36(4), pp. 8-17 , April 2021. 1521 [BOE2019] Boegl, T., Rautenberg, M., Haindl, R., Rihacek, C., Meser, 1522 J., Fantappie, P., Pringvanich, N., Micallef, J., 1523 Klauspeter, H.., MacBride, J., Sacre, P., v.d. Eiden, B., 1524 Graeupl, T., and M. Schnell, "LDACS White Paper - A Roll- 1525 out Scenario", International Civil Aviation Organization, 1526 Communications Panel - Data Communications Infrastructure 1527 Working Group - Third Meeting, pp. 1-8, Montreal, Canada , 1528 October 2019. 1530 Appendix A. Selected Information from DO-350A 1532 This appendix includes the continuity, availability, and integrity 1533 requirements applicable for LDACS defined in [DO350A]. 1535 The following terms are used here: 1537 CPDLC Controller Pilot Data Link Communication 1538 DT Delivery Time (nominal) value for RSP 1539 ET Expiration Time value for RCP 1540 FH Flight Hour 1541 MA Monitoring and Alerting criteria 1542 OT Overdue Delivery Time value for RSP 1543 RCP Required Communication Performance 1544 RSP Required Surveillance Performance 1545 TT Transaction Time (nominal) value for RCP 1546 +========================+=============+=============+ 1547 | | RCP 130 | RCP 130 | 1548 +========================+=============+=============+ 1549 | Parameter | ET | TT95% | 1550 +------------------------+-------------+-------------+ 1551 | Transaction Time (sec) | 130 | 67 | 1552 +------------------------+-------------+-------------+ 1553 | Continuity | 0.999 | 0.95 | 1554 +------------------------+-------------+-------------+ 1555 | Availability | 0.989 | 0.989 | 1556 +------------------------+-------------+-------------+ 1557 | Integrity | 1E-5 per FH | 1E-5 per FH | 1558 +------------------------+-------------+-------------+ 1560 Table 1: CPDLC Requirements for RCP 130 1562 +========================+=========+=========+=========+=========+ 1563 | | RCP 240 | RCP 240 | RCP 400 | RCP 400 | 1564 +========================+=========+=========+=========+=========+ 1565 | Parameter | ET | TT95% | ET | TT95% | 1566 +------------------------+---------+---------+---------+---------+ 1567 | Transaction Time (sec) | 240 | 210 | 400 | 350 | 1568 +------------------------+---------+---------+---------+---------+ 1569 | Continuity | 0.999 | 0.95 | 0.999 | 0.95 | 1570 +------------------------+---------+---------+---------+---------+ 1571 | Availability | 0.989 | 0.989 | 0.989 | 0.989 | 1572 +------------------------+---------+---------+---------+---------+ 1573 | Integrity | 1E-5 | 1E-5 | 1E-5 | 1E-5 | 1574 | | per FH | per FH | per FH | per FH | 1575 +------------------------+---------+---------+---------+---------+ 1577 Table 2: CPDLC Requirements for RCP 240/400 1579 RCP Monitoring and Alerting Criteria in case of CPDLC: 1581 - MA-1: The system shall be capable of detecting failures and 1582 configuration changes that would cause the communication service 1583 no longer meet the RCP specification for the intended use. 1584 - MA-2: When the communication service can no longer meet the RCP 1585 specification for the intended function, the flight crew and/or 1586 the controller shall take appropriate action. 1588 +==============+========+========+========+========+========+=======+ 1589 | | RSP | RSP | RSP | RSP | RSP | RSP | 1590 | | 160 | 160 | 180 | 180 | 400 | 400 | 1591 +==============+========+========+========+========+========+=======+ 1592 | Parameter | OT | DT95% | OT | DT95% | OT | DT95% | 1593 +--------------+--------+--------+--------+--------+--------+-------+ 1594 | Transaction | 160 | 90 | 180 | 90 | 400 | 300 | 1595 | Time (sec) | | | | | | | 1596 +--------------+--------+--------+--------+--------+--------+-------+ 1597 | Continuity | 0.999 | 0.95 | 0.999 | 0.95 | 0.999 | 0.95 | 1598 +--------------+--------+--------+--------+--------+--------+-------+ 1599 | Availability | 0.989 | 0.989 | 0.989 | 0.989 | 0.989 | 0.989 | 1600 +--------------+--------+--------+--------+--------+--------+-------+ 1601 | Integrity | 1E-5 | 1E-5 | 1E-5 | 1E-5 | 1E-5 | 1E-5 | 1602 | | per FH | per FH | per FH | per FH | per | per | 1603 | | | | | | FH | FH | 1604 +--------------+--------+--------+--------+--------+--------+-------+ 1606 Table 3: ADS-C Requirements 1608 RCP Monitoring and Alerting Criteria: 1610 - MA-1: The system shall be capable of detecting failures and 1611 configuration changes that would cause the ADS-C service no longer 1612 meet the RSP specification for the intended function. 1613 - MA-2: When the ADS-C service can no longer meet the RSP 1614 specification for the intended function, the flight crew and/or 1615 the controller shall take appropriate action. 1617 Authors' Addresses 1619 Nils Maeurer (editor) 1620 German Aerospace Center (DLR) 1621 Muenchner Strasse 20 1622 82234 Wessling 1623 Germany 1624 Email: Nils.Maeurer@dlr.de 1626 Thomas Graeupl (editor) 1627 German Aerospace Center (DLR) 1628 Muenchner Strasse 20 1629 82234 Wessling 1630 Germany 1631 Email: Thomas.Graeupl@dlr.de 1632 Corinna Schmitt (editor) 1633 Research Institute CODE, UniBwM 1634 Werner-Heisenberg-Weg 28 1635 85577 Neubiberg 1636 Germany 1637 Email: corinna.schmitt@unibw.de