9/17/2018 Boeing ATN/IPS (Aeronautical Telecommunications Network/Internet Protocol Suite) Activities Title Option 1: Environment, Health & Safety Standard Greg Saccone ICAO Communications Panel 1-5 December 2014

Definitions (1) ATN: Aeronautical Telecommunications Network Originally intended to replace ACARS as an “ICAO compliant network” OSI: Open Systems Interconnection Generic data communications framework based on a 7-layer protocol architecture (‘stack’) Each layer has a specific set of functions Data presentation, physical medium access, connection management, etc. Limited COTS availability, not widely used IPS: Internet Protocol Suite Framework based on a 4-layer protocol stack The protocol of the Internet, widely used COTS

Definitions (2) ATN/OSI Defined in ICAO Doc 9705 and Doc 9880 OSI-based ATN used for LINK 2000+ program Also refers to a specific selection of standard and custom specifications for each protocol layer for aviation use ATN/IPS Identified as future ATS/AOC protocol by FAA, SESAR, ICAO Supports Voice over IP (VoIP) Defined in ICAO Doc 9896 Also refers to a specific selection of standard specifications for each protocol layer for aviation use Specifies a Dialog Service as intermediary between LINK 2000+ and Baseline 2 (B2) applications and IPS Allows applications to remain unchanged while using IPS Supports ACARS (e.g., AOC and FANS) applications as well

ATN/IPS Concept Need Current ATN/OSI situation Lack of beyond line of sight network, no multiple subnet capability currently implemented ATN/OSI technical issues in Europe Security provisions are TBD Resource spend on ATN/OSI development/fixes/maintenance Continued concerns about ATN/OSI complexity Protocol for ATS use only, no business case for ATN/OSI AOC OSI unable to support future IP applications and requirements (more data, moving towards simplified/unified aircraft architectures, need for broadband) Obsolescence of OSI, defacto standard of IP-based technology How to leverage work already done without re-inventing the ATS applications, and be able to take advantage of other communication protocols without being tied to legacy OSI?

ATN/IPS Approach Boeing and many others have recognized these ATN/OSI limitations Boeing helped to define ATN/IPS standards via ICAO (Doc 9896) to mitigate these limitations and provide future technology path ATN/IPS provides initial technical provisions for application support over TCP/UDP and IP Also supports legacy ACARS applications (AOC messaging, FANS-1/A) Rudimentary specifications at the network level (no implementation detail…essentially “use IP”, referencing standard RFCs) – done on purpose Goal is to have no changes to the existing applications (e.g. LINK2000+ CPDLC) while moving away from OSI-based protocols Avoids having to re-do flight decks, aircraft applications Removes dependency on applications from OSI protocols Creates a logical transition path to future IP-based communication links Can support B2 service introduction Can provide a common security framework In-line with Boeing enterprise communication strategy

ATN/IPS Dialog Service Concept Created an identical dialog service interface (the interface between the application and the upper protocol layers) regardless of ATN/OSI or ATN/IPS Initial specifications validated by EUROCONTROL via lab trials, LFV (Sweden) via PC-based flight trials ATN/OSI Application and Stack Structure ATN/IPS Application and Stack Structure Application User No difference to the user ATN-App AE Application User CF ATN-App ASE Applications Unchanged ATN-App ASE (e.g. CPDLC) Security ASO ACSE IPS Dialog Service Upper Layers Interfaces Unchanged TCP/UDP TP4 IPS CLNP

Envisaged Boeing ATN/IPS Architecture (DRAFT) EFB Display CMC/ ACMF Cabin Systems FMS AOC/ATC CMF Comm Management Media Routing Logic AOC AOI ACARS Network ATN Network IP Network Air HF SDU VDR SBB/Iridium NEXT/Other AeroMACS LDACS Ground Comm Service Provider

Boeing – Honeywell Activities Boeing Research and Technology and Honeywell Advanced Technology started a Joint Research Project based around identified common interests Determining implementation constraints of ATN/IPS How it would work in current aircraft architectures Prototyping ATN/IPS using realistic hardware and adjacent aircraft systems Testing in live communication environment (SATCOM) Lots of areas for further definition/investigation Routing Mobility Performance Security ATN/OSI – ATN/IPS interoperability and transition ATN/IPS over VDLM2 performance etc

Boeing – Honeywell Activities Current Status Honeywell has provided Boeing with a prototype ATN/IPS CMU Promising results so far… Prototype ATN/IPS CMU swapped for ATN/OSI CMU on Boeing 737 test rack Initial ATN/IPS application-level compatibility proven No changes to ATS functionality from the flight crew and avionics perspective CPDLC, CM behave exactly the same as OSI version No changes to MCDU displays Internal avionics interfaces unchanged Boeing and Honeywell are continuing work to investigate/define other aspects of ATN/IPS Currently performing lab trials with Honeywell and Boeing ATN/IPS ground systems, sending/receiving CM and CPDLC messages Scheduled to perform SATCOM and VDLM2 testing over this year and next Potential flight trials via ecoDemonstrator, 2015-2016

Boeing/Airbus Alignment on ATN/IPS Boeing and Airbus currently have schedule and technical disconnects in this area Airbus, via SESAR/ESA projects, is planning to tunnel ATN/OSI over INMARSAT’s SwiftBroadband service with a trials capability by 2017 Is an acknowledged “interim step”…transition past interim not yet defined Performance benefits of ATN/OSI over SBB still TBD Target fleets and numbers to be defined; very few narrowbodies have SATCOM Boeing would rather go directly to ATN/IPS than do an expensive, complicated interim step that may delay further IP development Looking at ~2022 for ATN/IPS capability, and planning research accordingly No need for interim solution prior to then; understand and solve European issues first rather than introducing additional complexity Work towards accommodating Oceanic/Domestic B2 programs with ATN/IPS Boeing and Airbus are working towards a converged roadmap

Datalink Roadmap (Boeing Vision, DRAFT) 2015 2020 2025 2030 2035 Legacy Com means VHF Voice VHF Data/VDLM2 ? HF ? Satcom Data 2 ? Future Com means 2016 AeroMACS 2030 ? LDACS 2017 Iridium NEXT 2016 SATCOM (SBB/IRIS) Airborne ATS Router ACARS ? ATN/OSI (B1, Europe) ? ATN/IPS Still being worked between Boeing and Airbus and other stakeholders

ATN/IPS Work to be Done Far from being a mature standard Aggressive work needs to be done to validate ATN/IPS and quantify product line impacts Architectural impacts, including CMU/router SATCOM/VDLM2 support, including multiple vendors, multi-media performance Mobility TCP vs UDP Addressing Security Compatibility between ATN/OSI and ATN/IPS and transition needs to be defined Likely a ground gateway, similar to how FANS-1/A – ATN/OSI gateways operate Boeing plans to continue progressing studies in these areas and expand trials

Questions? Thank you!

Backup

Guiding Principles for Migration to Future Comm (network/subnetwork level) Move from ATN/OSI to ATN/IPS and broadband IP Be a single stack, with media management in-line with FANS-1/A (i.e. allow multiple subnets, and not tied to one particular vendor implementation) Have minimal impacts on avionics, at a minimum in terms of application impact, multiple LRU changes, hardware additions Be based on stated and validated performance requirement needs Be a true transition towards the end state ATN/IPS, not an interim short term throw away step Be applicable globally Make maximum use of COTS Have a positive business case for the customer airlines and ANSPs Domestic and Oceanic environments Preserve current investments in ground and aircraft assets Move routing complexities and gateway functionalities to the ground Support ACARS (FANS and AOC) traffic