24/25 September 2002 ATN2002 (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
24/25 September 2002 ATN2002 (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
24/25 September 2002 ATN2002 (London) 3
The CNS/ATM DeploymentProblem 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… !
24/25 September 2002 ATN2002 (London) 4
Data Link Implementation… the Status Quo
ATN : the ICAO, EUROCAE & RTCA standard for CNS/ATMEuropean & US trials from 1992+; operational deployment in US from 2003-2005; planning in progress in EuropeCPDLC is the benefits driver, based on positive business cases (C/AFT, RTCA, EUROCONTROL) plus user demandUses 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 systemsBroadcast media optimized for surveillance, not “data link”
Broadcast Data Link Services
FANS 1/A: de-facto oceanic data link standardPacific region trials from 1993+; first operational use from 1998+ (for routes in remote/oceanic airspaces)Services include FANS versions of ADS & CPDLCUses ACARS/AIRCOM as data link; performance and integrity acceptable in non-dense airspaces
Oceanic Data Link Services
24/25 September 2002 ATN2002 (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.
24/25 September 2002 ATN2002 (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.
24/25 September 2002 ATN2002 (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 ?
24/25 September 2002 ATN2002 (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
conversionMulti-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
24/25 September 2002 ATN2002 (London) 9
FANS “Accommodation” Scenarios and Consequences (4 of
4)
Characteristic External Gateway
Internal Gateway Multi-Protocol Host
Acquisition Cost Relatively 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 Cost High(limited control over operating costs and
network tariffs)
High(limited control over operating costs and
network tariffs)
Medium to Low(better control over
operating costs and network tariffs)
Technical Complexity High(completely generic)
Medium(partly optimized for ATS
center needs)
Low(fully optimized for ATS
center needs)
Performance Relatively lower(due to complex
functionality & sessions per aircraft)
Medium(partly optimized for ATS
center needs)
Relatively higher(fully optimized for ATS
center needs)
Security Issues Significant(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)
24/25 September 2002 ATN2002 (London) 10
Ground Data Link Architecture
Basic ATN
ATNG/G BIS
Local ATNG/G BIS
ATNA/G BIS
WAN(X.25, IP, FR, …)
ATCC
Local ATNG/G BIS
ATCC
ATNG/G BIS
ATSO
ATNA/G BIS
ATNA/G BIS
ATN ES/BIS
CSP
WAN(X.25, IP, FR, …)
WAN(X.25, IP, FR, …)
24/25 September 2002 ATN2002 (London) 11
Ground Data Link Architecture
General ATN Backbone Extension
ATNG/G BIS
ATNG/G BIS
ATSO
CSP
ATNG/G BIS
ATSO
BackboneBIS
Backbone BIS
Backbone BISWAN
(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
24/25 September 2002 ATN2002 (London) 12
Ground Data Link Architecture
FANS Accommodation using Gateways
ATNG/G BIS
ATNG/G BIS
ATNA/G BIS
WAN
WAN
ATCC
ATNG/G BIS
ATS
WAN
CSP
FANS ATNGTW
FANSaccess
ACARSNetwork
ATNG/G BIS
ATCC
FANS ATNGTW
Internal
External
ATNFANS 1/A
24/25 September 2002 ATN2002 (London) 13
Ground Data Link Architecture
Multi-Protocol Host
FDPSSDPSHMI
VDL 4
VDL Mode 4Stations
NationalNetworks
UAT
Mode S‘ ExtendedSquitter ’Mode S
Radarnet
Mode S
CAERAFCTS
Satcom
ATN
ATN ES
Aircraft data
VDL Mode 2
MeteoData
ATIS
Meteo Access
VHF Satcom
ACARS NetworksSITA-ARINC
CPDLCADS
FANS-1
ATCC Access
24/25 September 2002 ATN2002 (London) 14
Ground Data Link Architecture
ATN Design Tradeoffs
ATS Service Providers
End-Systems Only
End-Systems and ATN Routers Only
End-Systems, ATN Routers and some Subnetworks
End-Systems, ATN Routers and most Subnetworks
Communication Service Providers
Full ATN Internet Service
Partial ATN Internet Service&/or Subnetwork Service
Most Ground-Ground Subnetwork & Air-Ground Subnetwork Service
Some Ground-Ground Subnetwork & Air-Ground Subnetwork Service
Incre
ase
cap
ital in
vestm
en
tD
ecre
ase
ATS o
pera
ting co
stsIn
crease
ATS co
ntro
l of co
mm
unica
tions
Balance between ATS providers and Communication Service providers to provide ATN
service interfaces
24/25 September 2002 ATN2002 (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.
24/25 September 2002 ATN2002 (London) 16