Download Scenario Comparison, Air/Ground Data communication

WGN04-WP12
Page 1
Aeronautical Communications Panel
Working Group N – Networking
New Orleans, 10-19 November 2004
Agenda Item 4: Internet Communication Services
Scenario Comparison, Air/Ground Data Communication
Presented by
Alvin H. Burgemeister
B-twelve Associates, Inc.
Connexion by Boeing
ICCAIA
Summary
Air/ground data communications are provided by a number of different subnetworks today. The proposed
air/ground subnetworks for ATN can be complemented by IP-based subnetworks, either to transport existing
ATN packets or to provide a direct transport of IP packets if they become standardized. The existing and
future air/ground subnetworks are compared.
WGN04-WP12
Page 2
1 Introduction
The paper prepared by Chonlawit Banphawatthanarak for WG-N03 in Montreal (WGN03-WP28) presented
an analysis of alternate scenarios for implementing ground/ground data communication using the TCP/IP
family of protocols. A similar paper is required to address the air/ground data communications
environment, as identified in Action Item SGN1-2/8. This paper completes that Action Item.
1.1 Existing Air/Ground Subnetworks
Civil aviation has been using air/ground data communication for over 25 years, beginning with VHF
ACARS1, and expanding to ACARS over SatCom and HF Data Link. These earlier data link systems were
not designed for bit-oriented communications as envisioned by the ICAO FANS Committees. That
capability was first realized with the introduction of the ACARS Convergence Protocol (ACP), documented
in ARINC 622 and first implemented in FANS-1.
Although the definition of AMSS/SatCom in ICAO, RTCA/EUROCAE, and AEEC documents was initially
written for bit-oriented communications, the only user of the service for many years was character-oriented
ACARS. Therefore, all existing SatCom installations provide a Frame-level service (Data-2) for ACARS
and only a few installations provide the Packet-level service (Data-3) required for an ATN subnetwork.
Similarly, HF Data Links are currently only used for ACARS. VHF Data Link was similarly constrained to
ACARS-only communications (using the original 2400 bps MSK modulation). VDL-2 provides not only a
bit-oriented protocol but also ACARS over AVLC2 (AOA). AOA provided a business incentive to airlines
and data link service providers (DSPs) to equip with VDL-2 radios, finally providing a bit-oriented
air/ground radio link that might also be available for ATN.
The ACARS network provides a number of Air Traffic Service Communications (ATSC) services. The
most visible of these communication services is FANS-1/A, providing CPDLC and ADS services to
numerous Flight Information Regions (FIRs) around the world, as shown in Figure 1.
FANS 1/A
ATN
(2009)
ATN w/FANS
1/A (2008)
U.S. airspace
boundary
FANS 1/A
FANS 1/A
Figure 1, World-wide Implementation of ATN and FANS-1
1
ACARS = Aviation Communications Addressing and Reporting System
2
AVLC = Aviation VHF Link Control, a variant of High Level Data Link Control (HDLC)
WGN04-WP12
Page 3
Not so visible, but more widely used, are the services of Departure Clearance (DC), ATIS, and Oceanic
Clearance (OC). These were first documented in ARINC 623; are now documented in EUROCAE
documents ED-85A, ED-89A, and ED-106A, respectively; and are implemented in numerous States and on
most ACARS-equipped aircraft. Departure Clearance and ATIS are also implemented in the United States
using another, older, ACARS protocol.
Figure 2 illustrates the relationship of the existing air/ground subnetworks with existing applications.
AOC
FANS-1
DC
ATIS
OC
ATN
Apps
ACARS
ATN
ICS
AOA
AMSS
HFDL
VHF
VDL-2
Figure 2, Existing Air/Ground Subnetworks and Applications
Note: All of the figures in this paper are presented from the point of view of the avionics installation.
1.2 Air-Ground Subnetworks for ATN
Except for early experimental installations, all operational ATN data communication has been conducted
over VDL-2, as seen above in Figure 2. The ATN internet communication service (ICS), consisting of
Transport Protocol # 4 (TP4) and Connection-Less Network Protocol (CLNP) plus the related routing
protocols provides the communications path for the ATN air/ground applications, which at this time consists
of only a subset of the Controller-Pilot Data Link Communications (CPDLC). A full ATN implementation,
capable of being used in not only areas served by VDL-2 but also in oceanic areas would appear more like
that shown in Figure 3. The “side ports” in the air-ground subnets depict ACARS subnet service, the “top
ports” depict ATN subnet service.
ACARS
ATN
Apps
AOA
Data-2
VDL-2
ATN
ICS
Data-3
AMSS
Figure 3, Combined ATN and ACARS Configuration
WGN04-WP12
Page 4
It is important to recognize that all of the ACARS applications, including those providing ATSC, might be
implemented in the ACARS portion of Figure 3 (as shown expanded in Figure 2). This is useful because an
airplane may move among multiple control regions providing a variety of available services. For instance,
DC and ATIS may be available at the departure airport using ACARS; domestic en route communications
might be provided using CPDLC over ATN. While still in ATN coverage, an OC (not yet provided as an
ATN service) may be received. An oceanic or remote area portion of the flight might then be flown using
FANS-1 communications. The en route portion of the flight near the destination may be flown using ATN
applications. Destination ATIS may be available by data link from airline dispatch using ACARS.
Although ACARS can be implemented on an aircraft together with either FANS-1/A or ATN, no airplane
currently has the capability to provide both FANS-1/A and ATN in the same aircraft. It is not even possible
to switch from one to the other between flights. The human factors and certification challenges make this a
very difficult and expensive option.
2 IP Subnetworks
Recent offerings of IP-based air/ground subnetworks provide new communication capabilities to not only
the flight crew but also to the passengers back in the cabin. The most visible of these offerings are the
satellite services provided by Connexion by Boeing and ARINC SKYLink, as well as Inmarsat Swift 64 and
Swift Broadband. The bandwidth provided by these competing services is different for each offering but
they may be generally classed as “satellite broadband”.
Development work has also been conducted on providing an IP pathway to the airplane via various
passenger seatback telephone services and via VDL-2. Although the former are intended for non-safety
services, VDL-2 can provide IP-based safety services.
One additional subnetwork being developed and installed is a wireless GateLink, using the WiFi standards
of IEEE 802.11. This link provides broadband connectivity between the aircraft and the ground
environment when the aircraft is on the ground, either parked or while taxiing in an area where WiFi service
is provided with adequate signal strength.
Significant development work is being conducted to enable AOC services and Electronic Flight Bag (EFB)
connectivity over IP air/ground networks. This capability, together with the implementation of passenger
services over IP, creates a new environment that strongly affects the business case for ATS data
communications. As these IP applications, together with the aircraft-ground networks to support them, are
installed, communications over IP will become more cost-effective and any other networking solution will
become even less cost-effective. Therefore, the movement of ATN to make use of the IP environment will
make ATN more likely to be implemented.
2.1 ATN CLNP over IP Subnetworks
The IP SNDCF3 being developed by WG-N has the potential to provide a viable alternative, and
replacement, for legacy wide-area networks (WANs)4 between ground ATN systems. This same
functionality has the potential to be equally useful for air-ground communications. The IP SNDCF provides
the capability to “tunnel” a network protocol, such as CLNP and the other Network-level protocols of the
existing ATN, transparently to and from a peer SNDCF located at an air/ground router. Such IP
subnetworks would be in addition to or in replacement of any existing legacy subnetworks5, with ATN
routing used to select the best routing for a particular packet, as shown in Figure 4.
3
SNDCF = Sub-Network Dependent Convergence Function
4
Most of these WANs use X.25 networks
5
Most of which are designed to use ISO 8208 “Packet-Level Protocol of X.25”
WGN04-WP12
Page 5
ACARS
ATN
Apps
ATN
ICS
AOA
IP SNDCF
VDL-2
AMSS
Broadband
AMSS
GateLink
Figure 4, Addition of IP SNDCF
The following are the attributes of this solution:
1. System performance: The transit delay performance of an IP subnetwork should be at least as good
as legacy ISO 8208-based subnetworks. Some improvement may be achieved due to improved
protocol efficiency. The broadband satellite services will provide significant improvement of
bandwidth by comparison with existing SatCom and VDL.
2. System availability: Broadband satellite system availability is a function of satellite coverage.
Heavily-traveled routes at other than polar latitudes will have adequate coverage because the
commercial users of the service require that availability, including possible redundant coverage.
Less-traveled routes will be less likely to have broadband coverage but can generally fall back to
lower-bandwidth services. Polar coverage is problematic with all but HF (and Iridium if that service
is again offered). VDL coverage would be similar to that provided by existing VDL. The
broadband systems provide adequate bandwidth such that priority, precedence, and pre-emption
may not be required to ensure that safety services have adequate availability.
3. Data integrity: All of the services being considered have commercial requirements for high data
integrity. Link-level error checking and retransmission is performed. Although packet-level error
checking and retransmission provided in ISO 8208 is not done, there are adequate error checks at
other layers and broadband performance minimizes error-caused transit delays.
4. Network management: Modern management tools are used for the IP-based subnets, superior to the
older capabilities of the legacy systems.
5. Interoperability: A peer SNDCF is required at an air/ground router. The routing of the ground IP
network allows significant flexibility of placement for the ground SNDCF and air/ground router.
6. Implementation timeframe: Contingent on market demand, air/ground IP SNDCF implementation
could be done as quickly as that of any of the currently-defined legacy air/ground subnetworks.
2.2 TP4-based ATN Applications over IP Subnetworks
There are two potential ways of communicating with ATN applications over IP networks. The first, and
presumably the less-difficult method would be to replace the ISO Network-layer protocols with IP and its
related routing protocols but retain the Transport layer defined in the existing ATN standards. The second,
WGN04-WP12
Page 6
described in the subsequent section, would be to replace both the Network and Transport layers from the
ISO protocol set with the equivalent protocols of the TCP/IP protocol set.
Since the current ATN air/ground applications were designed to operate over TP4, a least-effort approach
may be to retain TP4 and to run TP4 directly over IP. Any of the legacy subnetworks currently defined for
classic ATN (using CLNP packets) should also be capable of conveying IP packets, probably with a new
SNDCF to handle mapping of priority and other parameters.
There are two subsets of solutions available for IP packet communications. One is the use of tunneling to
move the ATN IP packet inside an IP subnetwork (where some form of IP SNDCF would be required). The
other is to directly use the IP subnetwork as part of the routing for the IP Network layer. The former
alternative has all of the attributes of CLNP over an IP subnetwork, as described above. The latter treats the
IP subnet more like a local area network of an IP network. Further study is required to determine the
relative advantages of these two methods.
In both cases a new IP-based mobile routing algorithm is assumed. The difference between the two solution
subsets would be transparent to the routing algorithm and to the applications. The relationship of the
elements is illustrated in Figure 5. The dashed line represents the second of the two solution subsets, where
an IP SNDCF is not required, and should be interpreted to apply to any IP-based subnetwork.
ACARS
ATN Apps
over
TP4/IP
AOA
IP SNDCF
VDL-2
AMSS
Broadband
AMSS
GateLink
Figure 5, TP4/IP Packets over Air/Ground Subnetworks
The following are the attributes of this solution:
1. System performance: The transit delay performance should be comparable to CLNP over IP. The
efficiency of IP-based mobile routing is unknown until it has been defined.
2. System availability: Availability should be at least equivalent to CLNP over IP. The installation of
new IP subnets would increase the availability of high-quality connections.
3. Data integrity: Data integrity should be comparable between TP4/CLNP and TP4/IP.
4. Network management: The industry experience with IP network management should provide
superior management capability.
5. Interoperability: ATN applications over TP4/IP would have to be implemented in both the avionics
systems and the peer ground systems.
6. Implementation timeframe: The timeliness of implementation is heavily dependent on solving the
challenge of mobile IP to meet aeronautical requirements and any other challenges identified during
the WG-N study.
WGN04-WP12
Page 7
2.3 TCP/IP-based ATN Applications over IP Subnetworks
If ICAO develops standards for ATN applications over TCP/IP the applications will have to be modified to
use the services of TCP rather than TP4. This is illustrated in Figure 6.
As described above, there are two subsets of solutions available to convey the IP packets between the
aircraft and the ground. One is the use of tunneling to move the ATN IP packet inside an IP subnetwork
(where some form of IP SNDCF would be required). The other is to directly use the IP subnetwork as part
of the routing for the IP Network layer.
ACARS
ATN Apps
over
TCP/IP
AOA
IP SNDCF
VDL-2
AMSS
Broadband
AMSS
GateLink
Figure 6, TCP/IP Packets over Air/Ground Subnetworks
The following are the attributes of this solution:
1. System performance: The transit delay performance should be comparable to the other IP solutions.
The efficiency of IP-based mobile routing is unknown until it has been defined.
2. System availability: Availability should be equivalent to other IP solutions.
3. Data integrity: Data integrity should be comparable between TP4/CLNP and TCP/IP except for the
ATN-unique extension of the TP4 checksum.
4. Network management: The industry experience with IP network management should provide
superior management capability.
5. Interoperability: ATN applications over TCP/IP would have to be implemented in both the avionics
systems and the peer ground systems.
6. Implementation timeframe: The timeliness of implementation is heavily dependent on solving the
challenge of mobile IP to meet aeronautical requirements and any other challenges identified during
the WG-N study.
3 Intra-aircraft Gateways and Data Busses
The avionics industry has struggled since the ATN applications were first proposed to find a way to
implement ATN in the aircraft in a way that would provide the necessary functionality, meet certification
requirements, be cost-effective, and provide adequate performance. Over time, the Airlines Electronic
Engineering Committee (AEEC) has studied this issue and has documented the results of their efforts in
WGN04-WP12
Page 8
ARINC Specifications 6566 and 6607. More recently, the AEEC Aircraft Data Network Working Group
(ADN W/G) has again taken up the issue, documented in various drafts of Project Paper 664, Part 88.
4 Transitions
The goal of ATS air-ground data communications development should be to evolve toward a consistent,
possibly integrated, solution that will effectively replace all of the current “interim” solutions. To do that
will require a transition strategy that recognizes:

The long-term nature of transition due to expensive and difficult avionics and ground system
development, procurement, installation and certification efforts,

The fact that not all aircraft, nor all ANSPs, will convert to the new standards at the same time,

A compelling business case cannot be made to convert to the new standards unless the primary
driver for the conversion is to support passenger and/or AOC communications,

A new set of standards will be under development before the previous standards are fully
implemented, and

Unlike the transition challenges of ground-ground applications, the relationships between aircraft
and the ANSPs are constantly changing, sometimes multiple times in a single flight.
Transition to ATN air/ground applications, whether implemented over the ISO protocols currently defined
for ATN or over the TCP/IP family of protocols, will need to consider

The existing ATSC data link communications applications of FANS-1/A,

The FAA ATIS and PDC messages, and

The ATS messages of ED-85A, 89A, and 106A.
Aircraft and ground systems have been installed and certified in response to the FAA CPDLC Build 1 and
the Link 2000+ projects. Therefore, these systems and any more that are built before the target standards are
developed will also have to be included in the transition effort.
Transition solutions are nearly as varied as the standards that need to be converged. However, they can be
generally grouped into two classes.
1. Dual installations, requiring operational integration of the information at the aircraft or ground
system.
2. Gateway installations, translating between the protocols of two or more different protocol sets and
message formats to provide a common user interface.
656 Avionics Interface Definition for Flight Management and Communications Management Functions A
generic data transfer interface is defined for use between avionics computing equipment that exchanges binary
message-oriented data. This interface was developed so that various manufacturers can partition Air Traffic
Services (ATS) applications and protocols in different manners between various equipment.
6
660 CNS/ATM Avionics, Functional Allocation and Recommended Architectures Defines a set of standard
aircraft avionics architectures that support a cost-effective evolution to the fully operational CNS/ATM
environment. These architectures are intended to meet near-term requirements (e.g., FANS-1, SCAT-1, etc.)
and provide growth for supporting the full CNS/ATM function set. This standard represents broad airline
consensus for developing avionics equipment providing CNS/ATM operating capabilities
7
664, Part 8 Upper Layers Protocols and Services This document is a guidance specification for the
implementation of “application” level services or upper layer services as viewed within the context of the OSI
reference model. The purpose of Part 8 is to allow aeronautical applications to interface to transport layer of
the TCP/IP network architecture. These services will be supported by either the Compliant Network (CN) or the
Profiled Network (PN) using Internet Engineering Task Force (IETF) standard protocols and services.
8
WGN04-WP12
Page 9
5 Conclusions and Recommendations
After many years of effort the aeronautical community has recognized that the ISO protocol set selected for
ATN has been bypassed by the industry prominence of the TCP/IP protocol set.
Numerous non-ATN IP-based applications and air-ground subnetworks are being developed and installed on
aircraft today.
Working Group N will need to define an efficient and cost-effective way to allow ATN applications to use
the IP network and to eliminate dependence on the ISO protocol set. There are numerous target and
transitional options from which to choose.
The extremely detailed standards provided in Doc 9705 should not be replicated for an IP-based network
standard. Such detail delays implementation, has the potential for creating standards divergent from the rest
of industry, and increases costs.
The work of Working Group N needs to include transition planning, not only to transition from ATN over
ATN ICS but also from the various other communication systems that have evolved while the industry
waited for completion of the ATN standards.
The meeting is invited to consider the elements described in this paper.