1. 24/25 September 2002ATN2002 (London)1 Delivering CNS/ATM Services to the Aircraft Presented by Forrest Colliver A discussion of the FANS/ATN accommodation question, in the context of ground Air Traffic Service provider communication architectures

2. 24/25 September 2002ATN2002 (London)2 The CNS/ATM Deployment Problem Statement (1 of 2) Deploying CNS/ATM…what we’d like… We all implement CNS/ATM the same way… at the same pace… based on “master plan”, standardized on a global basis. The reality… Regional stakeholders implement pieces of the CNS/ATM puzzle  based on local political & industrial priorities;  using available technologies & tailored operational procedures;  on an ad hoc basis. Meanwhile, ICAO, IATA, et. al. create the “real” CNS/ATM  international operational service & technology standards;  broad user consensus and on longer-term benefits models

3. 24/25 September 2002ATN2002 (London)3 The CNS/ATM Deployment Problem Statement (2 of 2) The result… Competing non-interoperable CNS/ATM technologies & services Costly & inefficient process for stakeholders & vendors Compromised long-term CNS/ATM benefits No obvious growth path And of course…a lot of shouting… !

4. 24/25 September 2002ATN2002 (London)4 Data Link Implementation… the Status Quo ATN : the ICAO, EUROCAE & RTCA standard for CNS/ATM European & US trials from 1992+; operational deployment in US from 2003-2005; planning in progress in Europe CPDLC is the benefits driver, based on positive business cases (C/AFT, RTCA, EUROCONTROL) plus user demand Uses modern data links (VDL, SATCOM, ATM, IP etc.), thus integrity & performance suitable for high density airspaces Point-to-Point Data Link Services Trials in Europe & US from 1995+ have matured a variety of broadcast link technologies (VDL4; Mode S, UAT) Main user of broadcast data links remains surveillance applications based on ADS-B: from basic air/ground surveillance to autonomous aircraft surveillance systems Broadcast media optimized for surveillance, not “data link” Broadcast Data Link Services FANS 1/A: de-facto oceanic data link standard Pacific region trials from 1993+; first operational use from 1998+ (for routes in remote/oceanic airspaces) Services include FANS versions of ADS & CPDLC Uses ACARS/AIRCOM as data link; performance and integrity acceptable in non-dense airspaces Oceanic Data Link Services

5. 24/25 September 2002ATN2002 (London)5 The point-to-point data link problem in focus… FANS 1/A & ATN look fairly similar on the surface… Both are point-to-point  sessions between controller, pilot and automated equipment Both support similar applications  context management, ADS & controller/pilot communication dialogs However… FANS 1/A constrained by ACARS/AIRCOM and legacy architectures  Result: performance and application limitations ATN designed for digital data links & future CNS/ATM architectures  Result: fit for ICAO CNS/ATM purpose with architectural growth potential Although significant application & performance differences exist between FANS & ATN, strong motivation for “accommodation” of FANS-equipped aircraft in ATN airspace exists, to better amortize FANS investments in these aircraft to-date.

6. 24/25 September 2002ATN2002 (London)6 FANS “Accommodation” Scenarios and Consequences (1 of 4) FANS accommodation issues thoroughly studied… by ICAO, IATA, IRRF & other industry groups The conclusions, unchanged since 1995 ICAO analysis: 1. Current FANS 1/A airborne systems cannot be accommodated transparently in an ATN (EUROCAE ED-110) airspace implementing profile-changing messages without some form of operational workaround (procedural, voice read-back, etc.) 2. If FANS 1/A & ATN aircraft share ATN airspace without workarounds or upgrades:  ATN services must be limited to those common with current FANS 1/A  Profile-changing messages must be excluded  Ground gateways or multi-protocol ground hosts will be required In the case of FANS accommodation in dense/continental ATN airspace, ICAO CNS/ATM data link benefits will necessarily be constrained.

7. 24/25 September 2002ATN2002 (London)7 FANS “Accommodation” Scenarios and Consequences (2 of 4) However, given that “FANS accommodation” transparent to the Air Traffic Service provider is not viable, but that the coexistence of FANS & ATN aircraft in the same airspace is required, what are the available communication architectural choices ?

8. 24/25 September 2002ATN2002 (London)8 FANS “Accommodation” Scenarios and Consequences (3 of 4) External Gateways External to the CNS/ATM provider perimeter & control Likely operated by communication service provider, like store & forward message switch, performing FANS/ATN application conversion Internal Gateways Internal to the CNS/ATM provider perimeter & control Likely operated by ATS provider, performing mainly protocol conversion Multi-Protocol CNS/ATM Host Implemented within CNS/ATM provider perimeter & control Part of ATS provider ATM host system; includes both application & communication functions; preserves end-to-end service relationships with no intermediate translation functions

9. 24/25 September 2002ATN2002 (London)9 FANS “Accommodation” Scenarios and Consequences (4 of 4) CharacteristicExternal GatewayInternal GatewayMulti-Protocol Host Acquisition CostRelatively high per gateway (due to technical complexity and certification issues) Medium per gateway (similar to External, but with reduced technical complexity) Relatively low (integrated/optimized for host) Lifecycle CostHigh (limited control over operating costs and network tariffs) Medium to Low (better control over operating costs and network tariffs) Technical ComplexityHigh (completely generic) Medium (partly optimized for ATS center needs) Low (fully optimized for ATS center needs) PerformanceRelatively lower (due to complex functionality & sessions per aircraft) Medium (partly optimized for ATS center needs) Relatively higher (fully optimized for ATS center needs) Security IssuesSignificant (due to scope of control and technical complexity) Moderate (partly optimized for ATS center needs) Low (optimized for ATS center needs; operated by ATS authority) Liability & Certification Complexity High (due to application gateway role in end-to-end services) Medium (due to design assurance requirements) Low (based on integration with ATS host system & center) Maintains ATN Baseline 1 Service Benefits No (due to conversion of FANS to ATN application messages) Possible (depends on “application” nature, or not, of gateway) Yes (maintains separate ATN/FANS end-to-end thread)

10. 24/25 September 2002ATN2002 (London)10 Ground Data Link Architecture Basic ATN ATN G/G BIS Local ATN G/G BIS ATN A/G BIS WAN (X.25, IP, FR, …) ATCC Local ATN G/G BIS ATCC ATN G/G BIS ATSO ATN A/G BIS ATN A/G BIS ATN ES/BIS CSP WAN (X.25, IP, FR, …) WAN (X.25, IP, FR, …)

11. 24/25 September 2002ATN2002 (London)11 Ground Data Link Architecture General ATN Backbone Extension ATN G/G BIS ATN G/G BIS ATSO CSP ATN G/G BIS ATSO Backbone BIS Backbone BIS Backbone BIS WAN (X.25, IP, FR, …) WAN (X.25, IP, FR, …) ATN A/G BIS WAN (X.25, IP, FR, …) ATN ES/BIS To other domains… To network management systems

12. 24/25 September 2002ATN2002 (London)12 Ground Data Link Architecture FANS Accommodation using Gateways ATN G/G BIS ATN G/G BIS ATN A/G BIS WAN ATCC ATN G/G BIS ATS WAN CSP FANS ATN GTW FANS access ACARS Network ATN G/G BIS ATCC FANS ATN GTW Internal External ATN FANS 1/A

13. 24/25 September 2002ATN2002 (London)13 Ground Data Link Architecture Multi-Protocol Host FDPS SDPS HMI VDL 4 VDL Mode 4 Stations National Networks UAT Mode S ‘ Extended Squitter ’ Mode S Radarnet Mode S CAERAF CTS Satcom ATN ATN ES Aircraft data VDL Mode 2 Meteo Data ATIS Meteo Access VHF Satcom ACARS Networks SITA-ARINC CPDLCADS FANS-1 ATCC Access

14. 24/25 September 2002ATN2002 (London)14 Ground Data Link Architecture ATN Design Tradeoffs ATS Service Providers o End-Systems Only o End-Systems and ATN Routers Only o End-Systems, ATN Routers and some Subnetworks o End-Systems, ATN Routers and most Subnetworks Communication Service Providers o Full ATN Internet Service o Partial ATN Internet Service &/or Subnetwork Service o Most Ground-Ground Subnetwork & Air-Ground Subnetwork Service o Some Ground-Ground Subnetwork & Air-Ground Subnetwork Service Increase capital investment Decrease ATS operating costs Increase ATS control of communications Balance between ATS providers and Communication Service providers to provide ATN service interfaces

15. 24/25 September 2002ATN2002 (London)15 Conclusions Numerous analyses have shown that current FANS 1/A aircraft cannot be accommodated transparently in ATN Baseline 1 airspace, without loss of benefits available to ATN aircraft. However, FANS 1/A aircraft may be able to obtain benefits in mixed airspaces without comprising services to ATN aircraft, if ATS providers communicate to each aircraft type directly. This approach eliminates the viability of the “external gateway”, but can be supported by the internal gateway, if properly implemented and operated. The best ground architecture for FANS accommodation is the multi-protocol ATS host:  Since FANS and ATN aircraft can be clearly distinguished for air traffic management and communication purposes, and,  Since ATS services can be tailored to local needs.

16. 24/25 September 2002ATN2002 (London)16