idnits 2.17.00 (12 Aug 2021) /tmp/idnits45637/draft-ietf-raw-ldacs-00.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: ---------------------------------------------------------------------------- No issues found here. 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 == Line 618 has weird spacing: '...uration chang...' -- The document date (20 October 2020) is 578 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- No issues found here. Summary: 0 errors (**), 0 flaws (~~), 2 warnings (==), 1 comment (--). 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: 23 April 2021 C. Schmitt, Ed. 6 Research Institute CODE, UniBwM 7 20 October 2020 9 L-band Digital Aeronautical Communications System (LDACS) 10 draft-ietf-raw-ldacs-00 12 Abstract 14 This document provides 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 shall provide 19 a data link for IP network-based aircraft guidance. High reliability 20 and availability for IP connectivity over LDACS are therefore 21 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 23 April 2021. 40 Copyright Notice 42 Copyright (c) 2020 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 . . . . . . . . . . . . . . . . . . . . . . . . . 3 58 3. Motivation and Use Cases . . . . . . . . . . . . . . . . . . 5 59 3.1. Voice Communications Today . . . . . . . . . . . . . . . 5 60 3.2. Data Communications Today . . . . . . . . . . . . . . . . 6 61 4. Provenance and Documents . . . . . . . . . . . . . . . . . . 7 62 5. Applicability . . . . . . . . . . . . . . . . . . . . . . . . 8 63 5.1. Advances Beyond the State-of-the-Art . . . . . . . . . . 8 64 5.1.1. Priorities . . . . . . . . . . . . . . . . . . . . . 8 65 5.1.2. Security . . . . . . . . . . . . . . . . . . . . . . 8 66 5.1.3. High Data Rates . . . . . . . . . . . . . . . . . . . 9 67 5.2. Application . . . . . . . . . . . . . . . . . . . . . . . 9 68 5.2.1. Air-to-Ground Multilink . . . . . . . . . . . . . . . 9 69 5.2.2. Air-to-Air Extension for LDACS . . . . . . . . . . . 9 70 5.2.3. Flight Guidance . . . . . . . . . . . . . . . . . . . 10 71 5.2.4. Business Communication of Airlines . . . . . . . . . 11 72 5.2.5. LDACS Navigation . . . . . . . . . . . . . . . . . . 11 73 6. Requirements to LDACS . . . . . . . . . . . . . . . . . . . . 12 74 7. Characteristics of LDACS . . . . . . . . . . . . . . . . . . 15 75 7.1. LDACS Sub-Network . . . . . . . . . . . . . . . . . . . . 16 76 7.2. Topology . . . . . . . . . . . . . . . . . . . . . . . . 16 77 7.3. LDACS Physical Layer . . . . . . . . . . . . . . . . . . 17 78 7.4. LDACS Data Link Layer . . . . . . . . . . . . . . . . . . 17 79 7.5. LDACS Mobility . . . . . . . . . . . . . . . . . . . . . 17 80 8. Reliability and Availability . . . . . . . . . . . . . . . . 18 81 8.1. Layer 2 . . . . . . . . . . . . . . . . . . . . . . . . . 18 82 8.2. Beyond Layer 2 . . . . . . . . . . . . . . . . . . . . . 20 83 9. Protocol Stack . . . . . . . . . . . . . . . . . . . . . . . 21 84 9.1. Medium Access Control (MAC) Entity Services . . . . . . . 22 85 9.2. Data Link Service (DLS) Entity Services . . . . . . . . . 24 86 9.3. Voice Interface (VI) Services . . . . . . . . . . . . . . 25 87 9.4. LDACS Management Entity (LME) Services . . . . . . . . . 25 88 9.5. Sub-Network Protocol (SNP) Services . . . . . . . . . . . 25 89 10. Security Considerations . . . . . . . . . . . . . . . . . . . 25 90 10.1. Reasons for Wireless Digital Aeronautical 91 Communications . . . . . . . . . . . . . . . . . . . . . 25 92 10.2. Requirements for LDACS . . . . . . . . . . . . . . . . . 26 93 10.3. Security Objectives for LDACS . . . . . . . . . . . . . 27 94 10.4. Security Functions for LDACS . . . . . . . . . . . . . . 27 95 10.5. Security Architectural Details for LDACS . . . . . . . . 28 96 10.5.1. Entities in LDACS Security Model . . . . . . . . . . 28 97 10.5.2. Matter of LDACS Entity Identification . . . . . . . 28 98 10.5.3. Matter of LDACS Entity Authentication and Key 99 Negotiation . . . . . . . . . . . . . . . . . . . . . 29 100 10.5.4. Matter of LDACS Message-in-transit Confidentiality, 101 Integrity and Authenticity . . . . . . . . . . . . . 29 102 10.6. Security Architecture for LDACS . . . . . . . . . . . . 30 103 11. Privacy Considerations . . . . . . . . . . . . . . . . . . . 30 104 12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 30 105 13. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 30 106 14. Normative References . . . . . . . . . . . . . . . . . . . . 30 107 15. Informative References . . . . . . . . . . . . . . . . . . . 31 108 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 34 110 1. Introduction 112 One of the main pillars of the modern Air Traffic Management (ATM) 113 system is the existence of a communication infrastructure that 114 enables efficient aircraft control and safe separation in all phases 115 of flight. Current systems are technically mature but suffering from 116 the VHF band's increasing saturation in high-density areas and the 117 limitations posed by analogue radio communications. Therefore, 118 aviation globally and the European Union (EU) in particular, strives 119 for a sustainable modernization of the aeronautical communication 120 infrastructure. 122 In the long-term, ATM communication shall transition from analogue 123 VHF voice and VDLM2 communication to more spectrum efficient digital 124 data communication. The European ATM Master Plan foresees this 125 transition to be realized for terrestrial communications by the 126 development (and potential implementation) of the L-band Digital 127 Aeronautical Communications System (LDACS). LDACS shall enable IPv6 128 based air- ground communication related to the aviation safety and 129 regularity of flight. The particular challenge is that no additional 130 spectrum can be made available for terrestrial aeronautical 131 communication. It was thus necessary to develop co-existence 132 mechanism/procedures to enable the interference free operation of 133 LDACS in parallel with other aeronautical services/systems in the 134 same frequency band. 136 Since LDACS shall be used for aircraft guidance, high reliability and 137 availability for IP connectivity over LDACS are essential. 139 2. Terminology 141 The following terms are used in the context of RAW in this document: 143 A2A Air-to-Air 144 LDACS A2A LDACS Air-to-Air 145 AeroMACS Aeronautical Mobile Airport Communication System 146 A2G Air-to-Ground 147 ACARS Aircraft Communications Addressing and Reporting System 148 ADS-C Automatic Dependent Surveillance - Contract 149 AM(R)S Aeronautical Mobile (Route) Service 150 ANSP Air traffic Network Service Provider 151 AOC Aeronautical Operational Control 152 AS Aircraft Station 153 ATC Air-Traffic Control 154 ATM Air-Traffic Management 155 ATN Aeronautical Telecommunication Network 156 ATS Air Traffic Service 157 CCCH Common Control Channel 158 COTS IP Commercial Off-The-Shelf 159 CM Context Management 160 CNS Communication Navigation Surveillance 161 CPDLC Controller Pilot Data Link Communication 162 DCCH Dedicated Control Channel 163 DCH Data Channel 164 DLL Data Link Layer 165 DLS Data Link Service 166 DME Distance Measuring Equipment 167 DSB-AM Double Side-Band Amplitude Modulation 168 FAA Federal Aviation Administration 169 FCI Future Communication Infrastructure 170 FDD Frequency Division Duplex 171 FL Forward Link 172 GANP Global Air Navigation Plan 173 GNSS Global Navigation Satellite System 174 GS Ground Station 175 GSC Ground-Station Controller 176 G2A Ground-to-Air 177 HF High Frequency 178 ICAO International Civil Aviation Organization 179 IP Internet Protocol 180 kbit/s kilobit per second 181 LDACS L-band Digital Aeronautical Communications System 182 LLC Logical Link Layer 183 LME LDACS Management Entity 184 MAC Medium Access Layer 185 MF Multi Frame 186 OFDM Orthogonal Frequency-Division Multiplexing 187 OFDMA Orthogonal Frequency-Division Multiplexing Access 188 OSI Open Systems Interconnection 189 PDU Protocol Data Units 190 PHY Physical Layer 191 QoS Quality of Service 192 RL Reverse Link 193 SARPs Standards And Recommended Practices 194 SDR Software Defined Radio 195 SESAR Single European Sky ATM Research 196 SF Super-Frame 197 SNP Sub-Network Protocol 198 SSB-AM Single Side-Band Amplitude Modulation 199 TBO Trajectory-Based Operations 200 TDM Time Division Multiplexing 201 TDMA Time-Division Multiplexing-Access 202 VDLM1 VHF Data Link mode 1 203 VDLM2 VHF Data Link mode 2 204 VHF Very High Frequency 205 VI Voice Interface 207 3. Motivation and Use Cases 209 Aircraft are currently connected to Air-Traffic Control (ATC) and 210 Aeronautical Operational Control (AOC) via voice and data 211 communications systems through all phases of a flight. Within the 212 airport terminal, connectivity is focused on high bandwidth 213 communications, while during en-route high reliability, robustness, 214 and range is the main focus. Voice communications may use the same 215 or different equipment as data communications systems. In the 216 following the main differences between voice and data communications 217 capabilities are summarized. The assumed use cases for LDACS 218 completes the list of use cases stated in [RAW-USE-CASES] and the 219 list of reliable and available wireless technologies presented in 220 [RAW-TECHNOS]. 222 3.1. Voice Communications Today 224 Voice links are used for Air-to-Ground (A2G) and Air-to-Air (A2A) 225 communications. The communication equipment is either ground-based 226 working in the High Frequency (HF) or Very High Frequency (VHF) 227 frequency band or satellite-based. All VHF and HF voice 228 communications is operated via open broadcast channels without 229 authentication, encryption or other protective measures. The use of 230 well-proven communication procedures via broadcast channels helps to 231 enhance the safety of communications by taking into account that 232 other users may encounter communication problems and may be 233 supported, if required. The main voice communications media is still 234 the analogue VHF Double Side-Band Amplitude Modulation (DSB-AM) 235 communications technique, supplemented by HF Single Side-Band 236 Amplitude Modulation (SSB-AM) and satellite communications for remote 237 and oceanic areas. DSB-AM has been in use since 1948, works reliably 238 and safely, and uses low-cost communication equipment. These are the 239 main reasons why VHF DSB-AM communications is still in use, and it is 240 likely that this technology will remain in service for many more 241 years. This however results in current operational limitations and 242 impediments in deploying new Air-Traffic Management (ATM) 243 applications, such as flight-centric operation with Point-to-Point 244 communications. 246 3.2. Data Communications Today 248 Like for voice, data communications into the cockpit is currently 249 provided by ground-based equipment operating either on HF or VHF 250 radio bands or by legacy satellite systems. All these communication 251 systems are using narrowband radio channels with a data throughput 252 capacity in order of kilobits per second. While the aircraft is on 253 ground some additional communications systems are available, like 254 Aeronautical Mobile Airport Communication System (AeroMACS; as of now 255 not widely used) or public cellular networks, operating in the 256 Airport (APT) domain and able to deliver broadband communication 257 capability. 259 The data communication networks used for the transmission of data 260 relating to the safety and regularity of the flight must be strictly 261 isolated from those providing entertainment services to passengers. 262 This leads to a situation that the flight crews are supported by 263 narrowband services during flight while passengers have access to 264 inflight broadband services. The current HF and VHF data links 265 cannot provide broadband services now or in the future, due to the 266 lack of available spectrum. This technical shortcoming is becoming a 267 limitation to enhanced ATM operations, such as Trajectory-Based 268 Operations (TBO) and 4D trajectory negotiations. 270 Satellite-based communications are currently under investigation and 271 enhanced capabilities are under development which will be able to 272 provide inflight broadband services and communications supporting the 273 safety and regularity of flight. In parallel, the ground-based 274 broadband data link technology LDACS is being standardized by ICAO 275 and has recently shown its maturity during flight tests [SCH20191]. 276 The LDACS technology is scalable, secure and spectrum efficient and 277 provides significant advantages to the users and service providers. 278 It is expected that both - satellite systems and LDACS - will be 279 deployed to support the future aeronautical communication needs as 280 envisaged by the ICAO Global Air Navigation Plan (GANP). 282 4. Provenance and Documents 284 The development of LDACS has already made substantial progress in the 285 Single European Sky ATM Research (SESAR) framework, and is currently 286 being continued in the follow-up program, SESAR2020 [RIH2018]. A key 287 objective of the SESAR activities is to develop, implement and 288 validate a modern aeronautical data link able to evolve with aviation 289 needs over long-term. To this end, an LDACS specification has been 290 produced [GRA2019] and is continuously updated; transmitter 291 demonstrators were developed to test the spectrum compatibility of 292 LDACS with legacy systems operating in the L-band [SAJ2014]; and the 293 overall system performance was analyzed by computer simulations, 294 indicating that LDACS can fulfil the identified requirements 295 [GRA2011]. 297 LDACS standardization within the framework of the ICAO started in 298 December 2016. The ICAO standardization group has produced an 299 initial Standards and Recommended Practices (SARPs) document 300 [ICA2018]. The SARPs document defines the general characteristics of 301 LDACS. The ICAO standardization group plans to produce an ICAO 302 technical manual - the ICAO equivalent to a technical standard - 303 within the next years. Generally, the group is open to input from 304 all sources and develops LDACS in the open. 306 Up to now LDACS standardization has been focused on the development 307 of the physical layer and the data link layer, only recently have 308 higher layers come into the focus of the LDACS development 309 activities. There is currently no "IPv6 over LDACS" specification 310 publicly available; however, SESAR2020 has started the testing of 311 IPv6-based LDACS testbeds. 313 The IPv6 architecture for the aeronautical telecommunication network 314 is called the Future Communications Infrastructure (FCI). FCI shall 315 support quality of service, diversity, and mobility under the 316 umbrella of the "multi-link concept". This work is conducted by ICAO 317 Communication Panel working group WG-I. 319 In addition to standardization activities several industrial LDACS 320 prototypes have been built. One set of LDACS prototypes has been 321 evaluated in flight trials confirming the theoretical results 322 predicting the system performance [GRA2018] [SCH20191]. 324 5. Applicability 326 LDACS is a multi-application cellular broadband system capable of 327 simultaneously providing various kinds of Air Traffic Services 328 (including ATS-B3) and Aeronautical Operational Control (AOC) 329 communications services from deployed Ground Stations (GS). The 330 LDACS A2G sub-system physical layer and data link layer are optimized 331 for data link communications, but the system also supports digital 332 air-ground voice communications. 334 LDACS supports communication in all airspaces (airport, terminal 335 maneuvering area, and en-route), and on the airport surface. The 336 physical LDACS cell coverage is effectively de-coupled from the 337 operational coverage required for a particular service. This is new 338 in aeronautical communications. Services requiring wide-area 339 coverage can be installed at several adjacent LDACS cells. The 340 handover between the involved LDACS cells is seamless, automatic, and 341 transparent to the user. Therefore, the LDACS A2G communications 342 concept enables the aeronautical communication infrastructure to 343 support future dynamic airspace management concepts. 345 5.1. Advances Beyond the State-of-the-Art 347 LDACS offers several capabilities that are not provided in 348 contemporarily deployed aeronautical communication systems. 350 5.1.1. Priorities 352 LDACS is able to manage services priorities, an important feature not 353 available in some of the current data link deployments. Thus, LDACS 354 guarantees bandwidth, low latency, and high continuity of service for 355 safety critical ATS applications while simultaneously accommodating 356 less safety-critical AOC services. 358 5.1.2. Security 360 LDACS is a secure data link with built-in security mechanisms. It 361 enables secure data communications for ATS and AOC services, 362 including secured private communications for aircraft operators and 363 ANSPs (Air Navigation Service Providers). This includes concepts for 364 key and trust management, mutual authenticated key exchange 365 protocols, key derivation measures, user and control message-in- 366 transit confidentiality and authenticity protection, secure logging 367 and availability and robustness measures [MAE20181], [MAE20191], 368 [MAE20192]. 370 5.1.3. High Data Rates 372 The user data rate of LDACS is 315 kbit/s to 1428 kbit/s on the 373 forward link (Ground-to-Air), and 294 kbit/s to 1390 kbit/s on the 374 reverse link (Air-to-Ground), depending on coding and modulation. 375 This is 50 times the amount terrestrial digital aeronautical 376 communications systems such as VDLM2 provide [SCH20191]. 378 5.2. Application 380 LDACS shall be used by several aeronautical applications ranging from 381 enhanced communication protocol stacks (multi-homed mobile IPv6 382 networks in the aircraft and potentially ad-hoc networks between 383 aircraft) to classical communication applications (sending GBAS 384 correction data) and integration with other service domains (using 385 the communication signal for navigation). 387 5.2.1. Air-to-Ground Multilink 389 It is expected that LDACS together with upgraded satellite-based 390 communications systems will be deployed within the Future 391 Communication Infrastructure (FCI) and constitute one of the main 392 components of the multilink concept within the FCI. 394 Both technologies, LDACS and satellite systems, have their specific 395 benefits and technical capabilities which complement each other. 396 Especially, satellite systems are well-suited for large coverage 397 areas with less dense air traffic, e.g. oceanic regions. LDACS is 398 well-suited for dense air traffic areas, e.g. continental areas or 399 hot-spots around airports and terminal airspace. In addition, both 400 technologies offer comparable data link capacity and, thus, are well- 401 suited for redundancy, mutual back-up, or load balancing. 403 Technically the FCI multilink concept shall be realized by multi- 404 homed mobile IPv6 networks in the aircraft. The related protocol 405 stack is currently under development by ICAO and SESAR. 407 5.2.2. Air-to-Air Extension for LDACS 409 A potential extension of the multi-link concept is its extension to 410 ad-hoc networks between aircraft. 412 Direct Air-to-Air (A2A) communication between aircrafts in terms of 413 ad-hoc data networks is currently considered a research topic since 414 there is no immediate operational need for it, although several 415 possible use cases are discussed (digital voice, wake vortex 416 warnings, and trajectory negotiation) [BEL2019]. It should also be 417 noted that currently deployed analog VHF voice radios support direct 418 voice communication between aircraft, making a similar use case for 419 digital voice plausible. 421 LDACS direct A2A is currently not part of standardization. 423 5.2.3. Flight Guidance 425 The FCI (and therefore LDACS) shall be used to host flight guidance. 426 This is realized using three applications: 428 1. Context Management (CM): The CM application shall manage the 429 automatic logical connection to the ATC center currently 430 responsible to guide the aircraft. Currently this is done by the 431 air crew manually changing VHF voice frequencies according to the 432 progress of the flight. The CM application automatically sets up 433 equivalent sessions. 434 2. Controller Pilot Data Link Communication (CPDLC): The CPDLC 435 application provides the air crew with the ability to exchange 436 data messages similar to text messages with the currently 437 responsible ATC center. The CPDLC application shall take over 438 most of the communication currently performed over VHF voice and 439 enable new services that do not lend themselves to voice 440 communication (e.g., trajectory negotiation). 441 3. Automatic Dependent Surveillance - Contract (ADS-C): ADS-C 442 reports the position of the aircraft to the currently active ATC 443 center. Reporting is bound to "contracts", i.e. pre-defined 444 events related to the progress of the flight (i.e. the 445 trajectory). ADS-C and CPDLC are the primary applications used to 446 implement in-flight trajectory management. 448 CM, CPDLC, and ADS-C are available on legacy datalinks, but not 449 widely deployed and with limited functionality. 451 Further ATC applications may be ported to use the FCI or LDACS as 452 well. A notable application is GBAS for secure, automated landings: 453 The Global Navigation Satellite System (GNSS) based Ground Based 454 Augmentation System (GBAS) is used to improve the accuracy of GNSS to 455 allow GNSS based instrument landings. This is realized by sending 456 GNSS correction data (e.g., compensating ionospheric errors in the 457 GNSS signal) to the airborne GNSS receiver via a separate data link. 458 Currently the VDB data link is used. VDB is a narrow-band single- 459 purpose datalink without advanced security only used to transmit GBAS 460 correction data. This makes VDB a natural candidate for replacement 461 by LDACS. 463 5.2.4. Business Communication of Airlines 465 In addition to air traffic services AOC services shall be transmitted 466 over LDACS. AOC is a generic term referring to the business 467 communication of airlines. Regulatory this is considered related to 468 the safety and regularity of flight and may therefore be transmitted 469 over LDACS. 471 AOC communication is considered the main business case for LDACS 472 communication service providers since modern aircraft generate 473 significant amounts of data (e.g., engine maintenance data). 475 5.2.5. LDACS Navigation 477 Beyond communication radio signals can always also be used for 478 navigation. LDACS takes this into account. 480 For future aeronautical navigation, ICAO recommends the further 481 development of Global Navigation Satellite System (GNSS) based 482 technologies as primary means for navigation. However, the drawback 483 of GNSS is its inherent single point of failure - the satellite. Due 484 to the large separation between navigational satellites and aircraft, 485 the received power of GNSS signals on the ground is very low. As a 486 result, GNSS disruptions might occasionally occur due to 487 unintentional interference, or intentional jamming. Yet the 488 navigation services must be available with sufficient performance for 489 all phases of flight. Therefore, during GNSS outages, or blockages, 490 an alternative solution is needed. This is commonly referred to as 491 Alternative Positioning, Navigation, and Timing (APNT). 493 One of such APNT solution consists of integrating the navigation 494 functionality into LDACS. The ground infrastructure for APNT is 495 deployed through the implementation of LDACS ground stations and the 496 navigation capability comes "for free". 498 LDACS navigation has already been demonstrated in practice in a 499 flight measurement campaign [SCH20191]. 501 6. Requirements to LDACS 503 The requirements to LDACS are mostly defined by its application area: 504 Communication related to safety and regularity of flight. 506 A particularity of the current aeronautical communication landscape 507 is that it is heavily regulated. Aeronautical data links (for 508 applications related to safety and regularity of flight) may only use 509 spectrum licensed to aviation and data links endorsed by ICAO. 510 Nation states can change this locally, however, due to the global 511 scale of the air transportation system adherence to these practices 512 is to be expected. 514 Aeronautical data links for the Aeronautical Telecommunication 515 Network (ATN) are therefore expected to remain in service for 516 decades. The VDLM2 data link currently used for digital terrestrial 517 internetworking was developed in the 1990es (the use of the OSI 518 internetwork stack indicates that as well). VDLM2 is expected to be 519 used at least for several decades. In this respect aeronautical 520 communication (for applications related to safety and regularity of 521 flight) is more comparable to industrial applications than to the 522 open Internet. 524 Internetwork technology is already installed in current aircraft. 525 Current ATS applications use either the Aircraft Communications 526 Addressing and Reporting System (ACARS) or the Open Systems 527 Interconnection (OSI) stack. The objective of the development effort 528 LDACS is part of (FCI) is to replace legacy (OSI) and proprietary 529 (ACARS) internetwork technologies with industry standard IP 530 technology. It is anticipated that the use of Commercial Off-The- 531 Shelf (COTS) IP technology mostly applies to the ground network. The 532 avionics networks on the aircraft will likely be heavily modified or 533 proprietary. 535 AOC applications currently mostly use the same stack (although some 536 applications, like the graphical weather service may use the 537 commercial passenger network). This creates capacity problems 538 (resulting in excessive amounts of timeouts) since the underlying 539 terrestrial data links (VDLM1/2) do not provide sufficient bandwidth. 540 The use of non-aviation specific data links is considered a security 541 problem. Ideally the aeronautical IP internetwork and the Internet 542 should be completely separated. 544 The objective of LDACS is to provide a next generation terrestrial 545 data link designed to support IP and provide much higher bandwidth to 546 avoid the currently experienced operational problems. 548 The requirement for LDACS is therefore to provide a terrestrial high- 549 throughput data link for IP internetworking in the aircraft. 551 In order to fulfil the above requirement LDACS needs to be 552 interoperable with IP (and IP-based services e.g. VoIP) at the 553 gateway connecting the LDACS network to other aeronautical ground 554 networks (the totality of them being the ATN). On the avionics side 555 in the aircraft aviation specific solutions are to be expected. 557 In addition to the functional requirements LDACS and its IP stack 558 need to fulfil the requirements defined in RTCA DO-350A/EUROCAE ED- 559 228A [DO350A]. This document defines continuity, availability, and 560 integrity requirements at different scopes for each air traffic 561 management application (CPDLC, CM, and ADS-C). The scope most 562 relevant to IP over LDACS is the CSP (Communication Service Provider) 563 scope. 565 The upcoming Figures Figure 1 and Figure 2 summarize the main 566 seetings based on volume 1 Table 5-14, and Table 6-13 defined in 567 [DO350A]. In a similar vein, requirements to fault management are 568 defined in the same tables. 570 +--------------+----------------+---------------------+----------------+ 571 | | ECP 130 | RCP 240 | RCP 400 | 572 +--------------+-------+--------+----------+----------+-------+--------+ 573 | Parameter | ET | TT_95% | ET | TT_95% | ET | TT_95% | 574 +--------------+-------+--------+----------+----------+-------+--------+ 575 | Transaction | 130 | 67 | 240 | 210 | 400 | 350 | 576 | Time (Sec) | | | | | | | 577 +--------------+-------+--------+----------+----------+-------+--------+ 578 | Continuity | 0.999 | 0.95 | 0.999 | 0.95 | 0.999 | 0.95 | 579 +--------------+-------+--------+----------+----------+-------+--------+ 580 | Availability | 0.989 | 0.989 (safety) | 0.989 | 581 | | | 0.9899 (efficiency) | | 582 +--------------+----------------+---------------------+----------------+ 583 | Integrity | 1E-5 per FH | 1E-5 per FH | 1E-5 per FH | 584 +--------------+----------------+---------------------+----------------+ 585 | RCP Monitoring and Alerting Criteria | 586 +--------------+-------------------------------------------------------+ 587 | MA-1 | The system shall be capable of detecting failures | 588 | | and configuration changes that would cause the | 589 | | communication service no longer meet the RCP | 590 | | specification for the intended use. | 591 +--------------+-------------------------------------------------------+ 592 | MA-2 | When the communication service can no longer | 593 | | meet the RCP specification for the intended | 594 | | function, the flight crew and/or the controller | 595 | | shall take appropriate action. | 596 +--------------+-------------------------------------------------------+ 598 Figure 1: Requirements for CPDLC 600 +--------------+----------------+---------------------+----------------+ 601 | | RSP 160 | RSP 180 | RSP 400 | 602 +--------------+-------+--------+----------+----------+-------+--------+ 603 | Parameter | OT | DT 95% | OT | DT 95% | OT | DT 95% | 604 +--------------+-------+--------+----------+----------+-------+--------+ 605 | Transaction | 160 | 90 | 180 | 90 | 400 | 300 | 606 | time (sec) | | | | | | | 607 +--------------+-------+--------+----------+----------+-------+--------+ 608 | Continuity | 0.999 | 0.95 | 0.999 | 0.95 | 0.999 | 0.95 | 609 +--------------+-------+--------+----------+----------+-------+--------+ 610 | Availability | 0.989 | 0.989 (safety) | 0.989 | 611 | | | 0.9899 (efficiency) | | 612 +--------------+----------------+---------------------+----------------+ 613 | Integrity | 1E-5 per FH | 1E-5 per FH | 1E-5 per FH | 614 +--------------+----------------+---------------------+----------------+ 615 | RCP Monitoring and Alerting Criteria | 616 +--------------+-------------------------------------------------------+ 617 | MA-1 | The system shall be capable of detecting failures | 618 | | and configuration changes that would cause the | 619 | | ADS-C service no longer meet the RSP | 620 | | specification for the intended function. | 621 +--------------+-------------------------------------------------------+ 622 | MA-2 | When the ADS-C service can no longer meet the RSP | 623 | | specification for the intended function, the | 624 | | flight crew and/or the controller | 625 | | shall take appropriate action. | 626 +--------------+-------------------------------------------------------+ 628 Figure 2: Requirements for ADS-C 630 7. Characteristics of LDACS 632 LDACS will become one of several wireless access networks connecting 633 aircraft to the ATN implemented by the FCI and possibly ACARS/FANS 634 networks [FAN2019]. 636 The current LDACS design is focused on the specification of layer 2. 638 Achieving stringent the 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. Input 642 from the working group will be appreciated here. 644 7.1. LDACS Sub-Network 646 An LDACS sub-network contains an Access Router (AR), a Ground-Station 647 Controller (GSC), and several Ground-Stations (GS), each of them 648 providing one LDACS radio cell. 650 User plane interconnection to the ATN is facilitated by the Access 651 Router (AR) peering with an Air-to-Ground Router (A2G Router) 652 connected to the ATN. It is up to implementer's choice to keep 653 Access Router and Air-Ground Router functions separated, or to merge 654 them. 656 The internal control plane of an LDACS sub-network is managed by the 657 GSC. An LDACS sub-network is illustrated in Figure 3. 659 wireless user 660 link plane 661 A--------------G-------------Access---A2G-----ATN 662 S..............S Router Router 663 . control . | 664 . plane . | 665 . . | 666 GSC..............| 667 . | 668 . | 669 GS---------------+ 671 Figure 3: LDACS sub-network with two GSs and one AS 673 7.2. Topology 675 LDACS operating in A2G mode is a cellular point-to-multipoint system. 676 The A2G mode assumes a star-topology in each cell where Aircraft 677 Stations (AS) belonging to aircraft within a certain volume of space 678 (the LDACS cell) is connected to the controlling GS. The LDACS GS is 679 a centralized instance that controls LDACS A2G communications within 680 its cell. The LDACS GS can simultaneously support multiple bi- 681 directional communications to the ASs under its control. LDACS 682 ground stations themselves are connected to a GSC controlling the 683 LDACS sub-network. 685 Prior to utilizing the system an AS has to register with the 686 controlling GS to establish dedicated logical channels for user and 687 control data. Control channels have statically allocated resources, 688 while user channels have dynamically assigned resources according to 689 the current demand. Logical channels exist only between the GS and 690 the AS. 692 The LDACS wireless link protocol stack defines two layers, the 693 physical layer and the data link layer. 695 7.3. LDACS Physical Layer 697 The physical layer provides the means to transfer data over the radio 698 channel. The LDACS GS supports bi-directional links to multiple 699 aircraft under its control. The forward link direction (FL; G2A) and 700 the reverse link direction (RL; A2G) are separated by frequency 701 division duplex. Forward link and reverse link use a 500 kHz channel 702 each. The ground-station transmits a continuous stream of Orthogonal 703 Frequency-Division Multiplexing (OFDM) symbols on the forward link. 704 In the reverse link different aircraft are separated in time and 705 frequency using a combination of Orthogonal Frequency-Division 706 Multiple-Access (OFDMA) and Time-Division Multiple-Access (TDMA). 707 Aircraft thus transmit discontinuously on the reverse link with radio 708 bursts sent in precisely defined transmission opportunities allocated 709 by the ground-station. 711 7.4. LDACS Data Link Layer 713 The data-link layer provides the necessary protocols to facilitate 714 concurrent and reliable data transfer for multiple users. The LDACS 715 data link layer is organized in two sub-layers: The medium access 716 sub-layer and the logical link control sub-layer. The medium access 717 sub-layer manages the organization of transmission opportunities in 718 slots of time and frequency. The logical link control sub-layer 719 provides acknowledged point-to-point logical channels between the 720 aircraft and the ground-station using an automatic repeat request 721 protocol. LDACS supports also unacknowledged point-to-point channels 722 and G2A broadcast. 724 7.5. LDACS Mobility 726 LDACS supports layer 2 handovers to different LDACS channels. 727 Handovers may be initiated by the aircraft (break-before-make) or by 728 the GS (make-before-break). Make-before-break handovers are only 729 supported for ground-stations connected to the same GSC. 731 External handovers between non-connected LDACS sub-networks or 732 different aeronautical data links shall be handled by the FCI multi- 733 link concept. 735 8. Reliability and Availability 737 8.1. Layer 2 739 LDACS has been designed with applications related to the safety and 740 regularity of flight in mind. It has therefore been designed as a 741 deterministic wireless data link (as far as this is possible). 743 Based on channel measurements of the L-band channel [SCHN2016] and 744 respecting the specific nature of the area of application, LDACS was 745 designed from the PHY layer up with robustness in mind. 747 In order to maximize the capacity per channel and to optimally use 748 the available spectrum, LDACS was designed as an OFDM-based FDD 749 system, supporting simultaneous transmissions in Forward Link (FL; 750 G2A) and Reverse Link (RL; A2G). The legacy systems already deployed 751 in the L-band limit the bandwidth of both channels to approximately 752 500 kHz. 754 The LDACS physical layer design includes propagation guard times 755 sufficient for the operation at a maximum distance of 200 nautical 756 miles from the GS. In actual deployment, LDACS can be configured for 757 any range up to this maximum range. 759 The LDACS FL physical layer is a continuous OFDM transmission. LDACS 760 RL transmission is based on OFDMA-TDMA bursts, with silence between 761 such bursts. The RL resources (i.e. bursts) are assigned to 762 different users (ASs) on demand by the ground station (GS). 764 The LDACS physical layer supports adaptive coding and modulation for 765 user data. Control data is always encoded with the most robust 766 coding and modulation (QPSK coding rate 1/2). 768 LDACS medium access on top of the physical layer uses a static frame 769 structure to support deterministic timer management. As shown in 770 figure 3 and 4, LDACS framing structure is based on Super-Frames (SF) 771 of 240ms duration corresponding to 2000 OFDM symbols. FL and RL 772 boundaries are aligned in time (from the GS perspective) allowing for 773 deterministic sending windows for KEEP ALIVE messages and control and 774 data channels in general. 776 LDACS medium access is always under the control of the GS of a radio 777 cell. Any medium access for the transmission of user data has to be 778 requested with a resource request message stating the requested 779 amount of resources and class of service. The GS performs resource 780 scheduling on the basis of these requests and grants resources with 781 resource allocation messages. Resource request and allocation 782 messages are exchanged over dedicated contention-free control 783 channels. 785 The purpose of QoS in LDACS medium access is to provide prioritized 786 medium access at the bottleneck (the wireless link). The signaling 787 of higher layer QoS requirements to LDACS is yet to be defined. A 788 DiffServ-based solution with a small number of priorities is to be 789 expected. 791 LDACS has two mechanisms to request resources from the scheduler in 792 the GS. 794 Resources can either be requested "on demand" with a given priority. 795 On the forward link, this is done locally in the GS, on the reverse 796 link a dedicated contention-free control channel is used called 797 Dedicated Control Channel (DCCH; roughly 83 bit every 60 ms). A 798 resource allocation is always announced in the control channel of the 799 forward link (Common Control Channel (CCCH); variably sized). Due to 800 the spacing of the reverse link control channels every 60 ms, a 801 medium access delay in the same order of magnitude is to be expected. 803 Resources can also be requested "permanently". The permanent 804 resource request mechanism supports requesting recurring resources in 805 given time intervals. A permanent resource request has to be 806 canceled by the user (or by the ground-station, which is always in 807 control). 809 User data transmissions over LDACS are therefore always scheduled by 810 the GS, while control data uses statically (i.e. at cell entry) 811 allocated recurring resources (DCCH and CCCH). The current 812 specification specifies no scheduling algorithm. Scheduling of 813 reverse link resources is done in physical Protocol Data Units (PDU) 814 of 112 bit (or larger if more aggressive coding and modulation is 815 used). Scheduling on the forward link is done Byte- wise since the 816 forward link is transmitted continuously by the GS. 818 In addition to having full control over resource scheduling, the GS 819 can send forced Handover (HO) commands for off-loading or RF channel 820 management, e.g. when the signal quality declines and a more suitable 821 GS is in the AS reach. With robust resource management of the 822 capacities of the radio channel, reliability and robustness measures 823 are therefore also anchored in the LDACS management entity. 825 In addition, to radio resource management, the LDACS control channels 826 are also used to send keep-alive messages, when they are not 827 otherwise used. Since the framing of the control channels is 828 deterministic, missing keep-alive messages can thus be immediately 829 detected. This information is made available to the multi-link 830 protocols for fault management. 832 The protocol used to communicate faults is not defined in the LDACS 833 specification. It is assumed that vendors would use industry 834 standard protocols like the Simple Network Management Protocol or the 835 Network Configuration Protocol where security permits. 837 The LDACS data link layer protocol running on top of the medium 838 access sub-layer uses ARQ to provide reliable data transmission on 839 layer 2. 841 It employs selective repeat ARQ with transparent fragmentation and 842 reassembly to the resource allocation size to achieve low latency and 843 a low overhead without losing reliability. It ensures correct order 844 of packet delivery without duplicates. In case of transmission 845 errors it identifies lost fragments with deterministic timers synced 846 to the medium access frame structure and initiates retransmission. 847 Additionally, the priority mechanism of LDACS ensures the timely 848 delivery of messages with high importance. 850 8.2. Beyond Layer 2 852 LDACS availability can be increased by appropriately deploying LDACS 853 infrastructure: This means proliferating the number of terrestrial 854 base stations. However, the scarcity of aeronautical spectrum for 855 data link communication (in the case of LDACS: tens of MHz in the 856 L-band) and the long range (in the case of LDACS: up to 400 km) make 857 this quite hard. The deployment of a larger number of small cells is 858 certainly possible, suffers, however, also from the scarcity of 859 spectrum. An additional constraint to take into account, is that 860 Distance Measuring Equipment (DME) is the primary user of the 861 aeronautical L-band. That is, any LDACS deployment has to take DME 862 frequency planning into account, too. 864 The aeronautical community has therefore decided not to rely on a 865 single communication system or frequency band. It is envisioned to 866 have multiple independent data link technologies in the aircraft 867 (e.g. terrestrial and SatCom) in addition to legacy VHF voice. 869 However, as of now no reliability and availability mechanisms that 870 could utilize the multi-link have been specified on Layer 3 and 871 above. 873 Below Layer 2 aeronautics usually relies on hardware redundancy. To 874 protect availability of the LDACS link, an aircraft equipped with 875 LDACS will have access to two L-band antennae with triple redundant 876 radio systems as required for any safety relevant system by ICAO. 878 9. Protocol Stack 880 The protocol stack of LDACS is implemented in the AS, GS, and GSC: It 881 consists of the Physical Layer (PHY) with five major functional 882 blocks above it. Four are placed in the Data Link Layer (DLL) of the 883 AS and GS: (1) Medium Access Layer (MAC), (2) Voice Interface (VI), 884 (3) Data Link Service (DLS), (4) LDACS Management Entity (LME). The 885 last entity resides within the Sub-Network Layer: Sub-Network 886 Protocol (SNP). The LDACS network is externally connected to voice 887 units, radio control units, and the ATN Network Layer. 889 Figure 4 shows the protocol stack of LDACS as implemented in the AS 890 and GS. 892 IPv6 Network Layer 893 | 894 | 895 +------------------+ +----+ 896 | SNP |--| | Sub-Network 897 | | | | Layer 898 +------------------+ | | 899 | | LME| 900 +------------------+ | | 901 | DLS | | | Logical Link 902 | | | | Control Layer 903 +------------------+ +----+ 904 | | 905 DCH DCCH/CCCH 906 | RACH/BCCH 907 | | 908 +--------------------------+ 909 | MAC | Medium Access 910 | | Layer 911 +--------------------------+ 912 | 913 +--------------------------+ 914 | PHY | Physical Layer 915 +--------------------------+ 916 | 917 | 918 ((*)) 919 FL/RL radio channels 920 separated by FDD 922 Figure 4: LDACS protocol stack in AS and GS 924 9.1. Medium Access Control (MAC) Entity Services 926 The MAC time framing service provides the frame structure necessary 927 to realize slot-based Time Division Multiplex (TDM) access on the 928 physical link. It provides the functions for the synchronization of 929 the MAC framing structure and the PHY Layer framing. The MAC time 930 framing provides a dedicated time slot for each logical channel. 932 The MAC Sub-Layer offers access to the physical channel to its 933 service users. Channel access is provided through transparent 934 logical channels. The MAC Sub-Layer maps logical channels onto the 935 appropriate slots and manages the access to these channels. Logical 936 channels are used as interface between the MAC and LLC Sub-Layers. 938 The LDACS framing structure for FL and RL is based on Super-Frames 939 (SF) of 240 ms duration. Each SF corresponds to 2000 OFDM symbols. 940 The FL and RL SF boundaries are aligned in time (from the view of the 941 GS). 943 In the FL, an SF contains a Broadcast Frame of duration 6.72 ms (56 944 OFDM symbols) for the Broadcast Control Channel (BCCH), and four 945 Multi-Frames (MF), each of duration 58.32 ms (486 OFDM symbols). 947 In the RL, each SF starts with a Random Access (RA) slot of length 948 6.72 ms with two opportunities for sending reverse link random access 949 frames for the Random Access Channel (RACH), followed by four MFs. 950 These MFs have the same fixed duration of 58.32 ms as in the FL, but 951 a different internal structure 953 Figure 5 and Figure 6 illustrates the LDACS frame structure. 955 ^ 956 | +------+------------+------------+------------+------------+ 957 | FL | BCCH | MF | MF | MF | MF | 958 F +------+------------+------------+------------+------------+ 959 r <---------------- Super-Frame (SF) - 240ms ----------------> 960 e 961 q +------+------------+------------+------------+------------+ 962 u RL | RACH | MF | MF | MF | MF | 963 e +------+------------+------------+------------+------------+ 964 n <---------------- Super-Frame (SF) - 240ms ----------------> 965 c 966 y 967 | 968 ----------------------------- Time ------------------------------> 969 | 971 Figure 5: LDACS super-frame structure 973 ^ 974 | +-------------+------+-------------+ 975 | FL | DCH | CCCH | DCH | 976 F +-------------+------+-------------+ 977 r <---- Multi-Frame (MF) - 58.32ms --> 978 e 979 q +------+---------------------------+ 980 u RL | DCCH | DCH | 981 e +------+---------------------------+ 982 n <---- Multi-Frame (MF) - 58.32ms --> 983 c 984 y 985 | 986 ----------------------------- Time ------------------------------> 987 | 989 Figure 6: LDACS multi-frame (MF) structure 991 9.2. Data Link Service (DLS) Entity Services 993 The DLS provides acknowledged and unacknowledged (including broadcast 994 and packet mode voice) bi-directional exchange of user data. If user 995 data is transmitted using the acknowledged data link service, the 996 sending DLS entity will wait for an acknowledgement from the 997 receiver. If no acknowledgement is received within a specified time 998 frame, the sender may automatically try to retransmit its data. 999 However, after a certain number of failed retries, the sender will 1000 suspend further retransmission attempts and inform its client of the 1001 failure. 1003 The data link service uses the logical channels provided by the MAC: 1005 1. A ground-stations announces its existence and access parameters 1006 in the Broadcast Channel (BC). 1007 2. The Random Access Channel (RA) enables AS to request access to an 1008 LDACS cell. 1009 3. In the Forward Link (FL) the Common Control Channel (CCCH) is 1010 used by the GS to grant access to data channel resources. 1011 4. The reverse direction is covered by the Reverse Link (RL), where 1012 aircraft-stations need to request resources before sending. This 1013 happens via the Dedicated Common Control Channel (DCCH). 1014 5. User data itself is communicated in the Data Channel (DCH) on the 1015 FL and RL. 1017 9.3. Voice Interface (VI) Services 1019 The VI provides support for virtual voice circuits. Voice circuits 1020 may either be set-up permanently by the GS (e.g., to emulate voice 1021 party line) or may be created on demand. The creation and selection 1022 of voice circuits is performed in the LME. The VI provides only the 1023 transmission services. 1025 9.4. LDACS Management Entity (LME) Services 1027 The mobility management service in the LME provides support for 1028 registration and de-registration (cell entry and cell exit), scanning 1029 RF channels of neighboring cells and handover between cells. In 1030 addition, it manages the addressing of aircraft/ ASs within cells. 1031 It is controlled by the network management service in the GSC. 1033 The resource management service provides link maintenance (power, 1034 frequency and time adjustments), support for adaptive coding and 1035 modulation (ACM), and resource allocation. 1037 9.5. Sub-Network Protocol (SNP) Services 1039 The data link service provides functions required for the transfer of 1040 user plane data and control plane data over the LDACS sub-network. 1042 The security service provides functions for secure communication over 1043 the LDACS sub-network. Note that the SNP security service applies 1044 cryptographic measures as configured by the ground station 1045 controller. 1047 10. Security Considerations 1049 10.1. Reasons for Wireless Digital Aeronautical Communications 1051 Aviation will require secure exchanges of data and voice messages for 1052 managing the air-traffic flow safely through the airspaces all over 1053 the world. Historically Communication Navigation Surveillance (CNS) 1054 wireless communications technology emerged from military and a threat 1055 landscape where inferior technological and financial capabilities of 1056 adversaries were assumed [STR2016]. The main communication method 1057 for ATC today is still an open analogue voice broadcast within the 1058 aeronautical VHF band. Currently, the information security is purely 1059 procedural based by using well-trained personnel and proven 1060 communications procedures. This communication method has been in 1061 service since 1948. However since the emergence of civil 1062 aeronautical CNS application and today, the world has changed. First 1063 of all civil applications have significant lower spectrum available 1064 than military applications. This means several military defense 1065 mechanisms such as frequency hopping or pilot symbol scrambling and 1066 thus a defense-in-depth approach starting at the physical layer is 1067 impossible for civil systems. With the rise of cheap Software 1068 Defined Radios (SDR), the previously existing financial barrier is 1069 almost gone and open source projects such as GNU radio [GNU2012] 1070 allow the new type of unsophisticated listeners and possible 1071 attackers. Furthermore most CNS technology developed in ICAO relies 1072 on open standards, thus syntax and semantics of wireless digital 1073 aeronautical communications can be common knowledge for attackers. 1074 Finally with increased digitization and automation of civil aviation 1075 the human as control instance is being taken gradually out of the 1076 loop. Autonomous transport drones or single piloted aircraft 1077 demonstrate this trend. However without profound cybersecurity 1078 measures such as authenticity and integrity checks of messages in- 1079 transit on the wireless link or mutual entity authentication, this 1080 lack of a control instance can prove disastrous. Thus future digital 1081 communications waveforms will need additional embedded security 1082 features to fulfill modern information security requirements like 1083 authentication and integrity. However, these security features 1084 require sufficient bandwidth which is beyond the capabilities of a 1085 VHF narrowband communications system. For voice and data 1086 communications, sufficient data throughput capability is needed to 1087 support the security functions while not degrading performance. 1088 LDACS is a data link technology with sufficient bandwidth to 1089 incorporate security without losing too much user throughput. 1091 As digitalization progresses even further with LDACS and automated 1092 procedures such as 4D-Trajectories allowing semi-automated en-route 1093 flying of aircraft, LDACS requires stronger cybersecurity measures. 1095 10.2. Requirements for LDACS 1097 Overall there are several business goals for cybersecurity to protect 1098 in future communication infrastructure in civil aviation: 1100 1. Safety: The system must sufficiently mitigate attacks, which 1101 contribute to safety hazards. 1102 2. Flight regularity: The system must sufficiently mitigate attacks, 1103 which contribute to delays, diversions, or cancellations of 1104 flights. 1105 3. Protection of business interests: The system must sufficiently 1106 mitigate attacks which result in financial loss, reputation 1107 damage, disclosure of sensitive proprietary information, or 1108 disclosure of personal information. 1110 To further analyze assets and derive threats and thus protection 1111 scenarios several Threat-and Risk Analysis were performed for LDACS 1112 [MAE20181] , [MAE20191]. These results allowed deriving security 1113 scope and objectives from the requirements and the conducted Threat- 1114 and Risk Analysis. 1116 10.3. Security Objectives for LDACS 1118 Security considerations for LDACS are defined by the official ICAO 1119 SARPS [ICA2018]: 1121 1. LDACS shall provide a capability to protect the availability and 1122 continuity of the system. 1123 2. LDACS shall provide a capability including cryptographic 1124 mechanisms to protect the integrity of messages in transit. 1125 3. LDACS shall provide a capability to ensure the authenticity of 1126 messages in transit. 1127 4. LDACS should provide a capability for nonrepudiation of origin 1128 for messages in transit. 1129 5. LDACS should provide a capability to protect the confidentiality 1130 of messages in transit. 1131 6. LDACS shall provide an authentication capability. 1132 7. LDACS shall provide a capability to authorize the permitted 1133 actions of users of the system and to deny actions that are not 1134 explicitly authorized. 1135 8. If LDACS provides interfaces to multiple domains, LDACS shall 1136 provide capability to prevent the propagation of intrusions within 1137 LDACS domains and towards external domains. 1139 10.4. Security Functions for LDACS 1141 These objectives were used to derive several security functions for 1142 LDACS required to be integrated in the LDACS cybersecurity 1143 architecture: (1) Identification, (2) Authentication, (3) 1144 Authorization, (4) Confidentiality, (5) System Integrity, (6) Data 1145 Integrity, (7) Robustness, (8) Reliability, (9) Availability, and 1146 (10) Key and Trust Management. Several works investigated possible 1147 measures to implement these security functions [BIL2017], [MAE20181], 1148 [MAE20191]. Having identified security requirements, objectives and 1149 functions now we must look at the scope of the applicability of these 1150 functions. 1152 10.5. Security Architectural Details for LDACS 1154 With requirements out of the way, we want to have a look at the scope 1155 of the LDACS security model. This includes looking at the entities, 1156 identification, authentication and authorization of entities, 1157 integrity, authenticity and confidentiality of data in-transit and 1158 more. 1160 10.5.1. Entities in LDACS Security Model 1162 First of all the question is what entities do we have in a simplified 1163 LDACS architectural model: Network operators such as the Societe 1164 Internationale de Telecommunications Aeronautiques (SITA) [SIT2020] 1165 and ARINC [ARI2020] are providing access to the (1) Ground IPS 1166 network via an (2) A2G LDACS Router. This router is attached to a 1167 closed off LDACS Access Network (3) which connects via further (4) 1168 Access Routers to the different (5) LDACS Cell Ranges, each 1169 controlled by a (6) Ground Station Controller (GSC) and spanning a 1170 local LDACS Access Network connecting to the (7) Ground Stations (GS) 1171 that serve one LDACS cell. Via the (8) A2G wireless LDACS data link 1172 (9) Airborne Stations (AS) the aircraft is connected to the ground 1173 network and via the (10) airborne voice interface and (11) airborne 1174 network interface, airborne data can be sent via the AS back to the 1175 GS and the forwarded back via GSC, LDACS local access network, access 1176 routers, LDACS access network, A2G LDACS router to the ground IPS 1177 network. 1179 10.5.2. Matter of LDACS Entity Identification 1181 Each entity described in the sections above must be uniquely 1182 identified within the LDACS network thus we need LDACS specific 1183 identities for (1) the Aircraft Station (AS), (2) Ground Station 1184 (GS), (3) Ground Station Controller (GSC) and (4) Network Operator 1185 (NO). The aircraft itself can be identified using the ICAO unique 1186 address of an aircraft, the call sign of that aircraft or the 1187 recently founded Privacy ICAO Address (PIA) program [FAA2020]. It is 1188 conceivable that the LDACS AS will use a combination of aircraft 1189 identification, radio component identification such as MAC addresses 1190 and even operator features identification to create a unique AS LDACS 1191 identification tag. Similar to a 4G's eNodeB Serving Network (SN) 1192 Identification tag, a GS could be identified using a similar field. 1193 And again similar to 4G's Mobility Management Entities (MME), a GSC 1194 could be identified using similar identification fields within the 1195 LDACS network. The identification of the network operator is again 1196 similar to 4G (e.g., E-Plus, AT&T, TELUS, ...), in the way that the 1197 aeronautical network operators are listed (e.g., ARINC [ARI2020] and 1198 SITA [SIT2020]). 1200 10.5.3. Matter of LDACS Entity Authentication and Key Negotiation 1202 In order to anchor Trust within the system all LDACS entities 1203 connected to the ground IPS network shall be rooted in an LDACS 1204 specific chain-of-trust and PKI solution, quite similar to AeroMACS 1205 approach [CRO2016]. These X.509 certificates [RFC5280] residing at 1206 the entities and incorporated in the LDACS PKI proof the ownership of 1207 their respective public key, include information about the identity 1208 of the owner and the digital signature of the entity that has 1209 verified the certificate's content. First all ground infrastructures 1210 must mutually authenticate to each other, negotiate and derive keys 1211 and thus secure all ground connections. How this process is handled 1212 in detail is still an ongoing discussion. However, established 1213 methods to secure user plane by IPSec [RFC4301] and IKEv2 [RFC7296] 1214 or the application layer via TLS 1.3 [RFC8446] are conceivable. The 1215 LDACS PKI with their chain-of-trust approach, digital certificates 1216 and public entity keys lay the groundwork for this step. In a second 1217 step the aircraft with the LDACS radio (AS) approaches an LDACS cell 1218 and performs a cell entry with the corresponding groundstation (GS). 1219 Similar to the LTE cell attachment process [TS33.401], where 1220 authentication happens after basic communication has been enabled 1221 between AS and GS (step 5a in the UE attachment process [TS33.401]), 1222 the next step is mutual authentication and key exchange. Thus in 1223 step three using the identity based Station-to-Station (STS) protocol 1224 with Diffie-Hellman Key Exchange [MAE2020], AS and GS establish 1225 mutual trust by authenticating each other, exchanging key material 1226 and finally both ending up with derived key material. A key 1227 confirmation is mandatory before the communication channel AS-GS can 1228 be opened for user-data communications. 1230 10.5.4. Matter of LDACS Message-in-transit Confidentiality, Integrity 1231 and Authenticity 1233 The subsequent key material from the previous step can then be used 1234 to protect LDACS Layer 2 communications via applying encryption and 1235 integrity protection measures on the SNP layer of the LDACS protocol 1236 stack. As LDACS transports AOC and ATS data, the integrity of that 1237 data is most important, while confidentiality only needs to be 1238 applied to AOC data to protect business interests [ICA2018]. This 1239 possibility of providing low layered confidentiality and integrity 1240 protection ensures a secure delivery of user data over the air gap. 1241 Furthermore it ensures integrity protection of LDACS control data. 1243 10.6. Security Architecture for LDACS 1245 Summing up all previous paragraphs, a draft of the cybersecurity 1246 architecture of LDACS can be found in [ICA2018], [MAE20182] and 1247 updates in [MAE20191], [MAE20192], [MAE2020]. It proposes the use of 1248 an own LDACS PKI, identity management based on aircraft identities 1249 and network operator identities (e.g., SITA and ARINC), public key 1250 certificates incorporated in the PKI based chain-of-trust and stored 1251 in the entities allowing for mutual authentication and key exchange 1252 procedures, key derivation mechanisms for perfect forward secrecy and 1253 user/control plane message-in-transit integrity and confidentiality 1254 protection. This secures data traveling over the airgap between 1255 aircraft and groundstation and also between groundstation and Air 1256 Navigation Service Provider regardless of the secure or unsecure 1257 nature of application data. Of course application data itself must 1258 be additionally secured to achieve end-to-end security (secure 1259 dialogue service), however the LDACS datalinks aims to provide an 1260 additional layer of protection just for this network segment. 1262 11. Privacy Considerations 1264 LDACS provides a Quality of Service (QoS), and the generic 1265 considerations for such mechanisms apply. 1267 12. IANA Considerations 1269 This memo includes no request to IANA. 1271 13. Acknowledgements 1273 Thanks to all contributors to the development of LDACS and ICAO PT-T. 1275 Thanks to Klaus-Peter Hauf, Bart Van Den Einden, and Pierluigi 1276 Fantappie for further input to this draft. 1278 Thanks to SBA Research Vienna for fruitful discussions on 1279 aeronautical communications concerning security incentives for 1280 industry and potential economic spillovers. 1282 14. Normative References 1284 [RFC4301] Kent, S. and K. Seo, "Security Architecture for the 1285 Internet Protocol", RFC 4301, DOI 10.17487/RFC4301, 1286 December 2005, . 1288 [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., 1289 Housley, R., and W. Polk, "Internet X.509 Public Key 1290 Infrastructure Certificate and Certificate Revocation List 1291 (CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008, 1292 . 1294 [RFC7296] Kaufman, C., Hoffman, P., Nir, Y., Eronen, P., and T. 1295 Kivinen, "Internet Key Exchange Protocol Version 2 1296 (IKEv2)", STD 79, RFC 7296, DOI 10.17487/RFC7296, October 1297 2014, . 1299 [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol 1300 Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, 1301 . 1303 15. Informative References 1305 [SCHN2016] Schneckenburger, N., Jost, T., Shutin, D., Walter, M., 1306 Thiasiriphet, T., Schnell, M., and U.C. Fiebig, 1307 "Measurement of the L-band Air-to-Ground Channel for 1308 Positioning Applications", IEEE Transactions on Aerospace 1309 and Electronic Systems, 52(5), pp.2281-229 , 2016. 1311 [MAE20191] Maeurer, N., Graeupl, T., and C. Schmitt, "Evaluation of 1312 the LDACS Cybersecurity Implementation", IEEE 38th Digital 1313 Avionics Systems Conference (DACS), pp. 1-10, San Diego, 1314 CA, USA , 2019. 1316 [MAE20192] Maeurer, N. and C. Schmitt, "Towards Successful 1317 Realization of the LDACS Cybersecurity Architecture: An 1318 Updated Datalink Security Threat- and Risk Analysis", IEEE 1319 Integrated Communications, Navigation and Surveillance 1320 Conference (ICNS), pp. 1-13, Herndon, VA, USA , 2019. 1322 [GRA2019] Graeupl, T., Rihacek, C., and B. Haindl, "LDACS A/G 1323 Specification", SESAR2020 PJ14-02-01 D3.3.030 , 2019. 1325 [FAN2019] Pierattelli, S., Fantappie, P., Tamalet, S., van den 1326 Einden, B., Rihacek, C., and T. Graeupl, "LDACS Deployment 1327 Options and Recommendations", SESAR2020 PJ14-02-01 1328 D3.4.020 , 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 [SCH20191] Schnell, M., "DLR Tests Digital Communications 1349 Technologies Combined with Additional Navigation Functions 1350 for the First Time", 2019. 1352 [ICA2018] International Civil Aviation Organization (ICAO), "L-Band 1353 Digital Aeronautical Communication System (LDACS)", 1354 International Standards and Recommended Practices Annex 10 1355 - Aeronautical Telecommunications, Vol. III - 1356 Communication Systems , 2018. 1358 [SAJ2014] Haindl, B., Meser, J., Sajatovic, M., Mueller, S., 1359 Arthaber, H., Faseth, T., and M. Zaisberger, "LDACS1 1360 Conformance and Compatibility Assessment", IEEE/AIAA 33rd 1361 Digital Avionics Systems Conference (DASC), pp. 1-11, 1362 Colorado Springs, CO, USA , 2014. 1364 [RIH2018] Rihacek, C., Haindl, B., Fantappie, P., Pierattelli, S., 1365 Graeupl, T., Schnell, M., and N. Fistas, "L-band Digital 1366 Aeronautical Communications System (LDACS) Activities in 1367 SESAR2020", Integrated Communications Navigation and 1368 Surveillance Conference (ICNS), pp. 1-8, Herndon, VA, 1369 USA , 2018. 1371 [BEL2019] Bellido-Manganell, M. A. and M. Schnell, "Towards Modern 1372 Air-to-Air Communications: the LDACS A2A Mode", IEEE/AIAA 1373 38th Digital Avionics Systems Conference (DASC), pp. 1-10, 1374 San Diego, CA, USA , 2019. 1376 [TS33.401] Zhang, D., "3GPP System Architecture Evolution (SAE); 1377 Security architecture", T33.401, 3GPP , 2012. 1379 [CRO2016] Crowe, B., "Proposed AeroMACS PKI Specification is a Model 1380 for Global and National Aeronautical PKI Deployments", 1381 WiMAX Forum at 16th Integrated Communications, Navigation 1382 and Surveillance Conference (ICNS), pp. 1-19, New York, 1383 NY, USA , 2016. 1385 [MAE2020] Maeurer, N., Graeupl, T., and C. Schmitt, "Comparing 1386 Different Diffie-Hellman Key Exchange Flavors for LDACS", 1387 IEEE/AIAA 39th Digital Avionics Systems Conference (DASC), 1388 pp. 1-10, San Antonio, TX, USA , 2020. 1390 [STR2016] Strohmeier, M., Schaefer, M., Pinheiro, R., Lenders, V., 1391 and I. Martinovic, "On Perception and Reality in Wireless 1392 Air Traffic Communication Security", IEEE Transactions on 1393 Intelligent Transportation Systems, 18(6), pp. 1338-1357, 1394 New York, NY, USA , 2016. 1396 [BIL2017] Bilzhause, A., Belgacem, B., Mostafa, M., and T. Graeupl, 1397 "Datalink Security in the L-band Digital Aeronautical 1398 Communications System (LDACS) for Air Traffic Management", 1399 IEEE Aerospace and Electronic Systems Magazine, 32(11), 1400 pp. 22-33, New York, NY, USA , 2017. 1402 [MAE20181] Maeurer, N. and A. Bilzhause, "Paving the Way for an IT 1403 Security Architecture for LDACS: A Datalink Security 1404 Threat and Risk Analysis", IEEE Integrated Communications, 1405 Navigation, Surveillance Conference (ICNS), pp. 1-11, New 1406 York, NY, USA , 2018. 1408 [FAA2020] FAA, "Federal Aviation Administration. ADS-B Privacy.", 1409 August 2020, 1410 . 1412 [GNU2012] GNU Radio project, "GNU radio", August 2012, 1413 . 1415 [SIT2020] SITA, "Societe Internationale de Telecommunications 1416 Aeronautiques", August 2020, . 1418 [ARI2020] ARINC, "Aeronautical Radio Incorporated", August 2020, 1419 . 1421 [DO350A] RTCA SC-214, "Safety and Performance Standard for Baseline 1422 2 ATS Data Communications (Baseline 2 SPR Standard)", May 1423 2016, . 1426 [RAW-TECHNOS] 1427 Thubert, P., Cavalcanti, D., Vilajosana, X., Schmitt, C., 1428 and J. Farkas, "Reliable and Available Wireless 1429 Technologies", Work in Progress, Internet-Draft, draft- 1430 thubert-raw-technologies-05, 18 May 2020, 1431 . 1434 [RAW-USE-CASES] 1435 Papadopoulos, G., Thubert, P., Theoleyre, F., and C. 1436 Bernardos, "RAW use cases", Work in Progress, Internet- 1437 Draft, draft-bernardos-raw-use-cases-04, 13 July 2020, 1438 . 1441 Authors' Addresses 1443 Nils Maeurer (editor) 1444 German Aerospace Center (DLR) 1445 Muenchner Strasse 20 1446 82234 Wessling 1447 Germany 1449 Email: Nils.Maeurer@dlr.de 1451 Thomas Graeupl (editor) 1452 German Aerospace Center (DLR) 1453 Muenchner Strasse 20 1454 82234 Wessling 1455 Germany 1457 Email: Thomas.Graeupl@dlr.de 1459 Corinna Schmitt (editor) 1460 Research Institute CODE, UniBwM 1461 Werner-Heisenberg-Weg 28 1462 85577 Neubiberg 1463 Germany 1465 Email: corinna.schmitt@unibw.de