Aeronautical Communications Panel

navybeansvietnameseΔίκτυα και Επικοινωνίες

24 Οκτ 2013 (πριν από 3 χρόνια και 11 μήνες)

73 εμφανίσεις

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 ana
lysis of alternate scenarios for implementing ground/ground data communication using the TCP/IP
family of protocols. A similar paper is required to addre
ss the air/ground data communic
ations
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
ACARS
1
, 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 Protoco
l (ACP), documented
in ARINC 622

and first implemented in FANS
-
1.

Although th
e 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 F
rame
-
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 AVLC
2

(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, providi
ng CPDLC and ADS services to
numerous Flight
Information

Regions (FIRs) around the world, as shown in Figure 1.


Figure 1, World
-
wide Implementation of ATN and FANS
-
1




1

ACARS = Aviation Communications Addressing and Reporting System

2

AVLC = Aviation VHF Li
nk Control, a variant of High Level Data Link Control (HDLC)


FANS 1
/A

FANS 1/A

U.S. airspace
boundary

ATN

(2009)

FANS 1/A

ATN w/FANS
1/A (2008)

WGN04
-
WP12

Page
3

AOC

ACARS

FANS
-
1

DC

ATIS

OC

ATN

Apps

AMSS

VDL
-
2

VHF

HFDL

ATN

ICS

AOA

Not so visible, but more widely used, are the services of
D
eparture 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 aircr
aft. 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.

Figure 2, Existing Air/Ground Subne
tworks 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 co
nducted
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 a
ir/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.












Figure 3, Combined ATN and ACARS Configuration

Data
-
3

Data
-
2

ACARS

ATN

Apps

AMSS

VDL
-
2

ATN
ICS

AOA

WGN04
-
WP12

Page
4

It is important to recognize that all of the AC
ARS applications, including those providing ATSC, might be
implemented in t
he ACARS portion of Figure 3

(as shown expanded in Figure 2)
. This is useful because a
n
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 betwee
n 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 th
e 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 provide
d

by these competing services is diff
erent for each offering but
they
may be

generally classed as “satellite broadband”.

D
evelopment 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 th
e 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 Ele
ctronic 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 SNDCF
3

being developed by WG
-
N has the potential to provide a viable alternative, and
replacement, for legacy wide
-
area networks (WANs)
4

between gro
und 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
,

tr
ansparently 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 subnetworks
5
, 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

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 availabil
ity 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
existi
ng

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 re
quirements for high data
integrity. Link
-
level error checking and retransmission is performed. Although packet
-
level error
checking a
nd retransmission provided in ISO 8208 is not done, there are adequate error checks at
other layers and broadband perform
ance 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 ro
uting 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 th
e currently
-
defined legacy air/ground subnetworks.

2.2

T
P
4
-
based ATN
A
pplications 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,
ACARS

ATN

Apps

AMSS

VDL
-
2

AOA

GateLink

Broadband
AMSS

IP SNDCF

ATN

ICS

WGN04
-
WP12

Page
6

described in the subsequent section, would be to replace both the Network and Transport layers fro
m 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 lega
cy 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 subnet
work

as part of the routing for the IP Network layer. The former
al
ternative 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.

I
n 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 dash
ed 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.

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
e
quivalent 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 T
P
4
/IP would have to be implemented in both the avionics
systems and the peer ground systems.

6.

Implementation timeframe:

The timeliness of implem
entation is heavily dependent on solving the
challenge of mobile IP to meet aeronautical requirements and any other challenges identified during
the WG
-
N study.

ACARS

ATN
Apps

over

T
P
4
/IP

AMSS

VDL
-
2

AOA

GateLink

Broadband
AMSS

IP SNDCF

WGN04
-
WP12

Page
7

2.3

TCP/
IP
-
based ATN Applications over IP Subnetworks

If ICAO develops standards for ATN applicatio
ns 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 gr
ound
. 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.

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 unk
nown 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.

Implementat
ion 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 in
dustry 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, t
he Airlines Electronic
Engineering Committee (AEEC)
has
studied this issue and has documented the results of their efforts in
ACARS

ATN
Apps

over
TCP/IP

AMSS

VDL
-
2

AOA

GateLink

Broadband
AMSS

IP SNDCF

WGN04
-
WP12

Page
8

ARINC Specifications 656
6

and 660
7
. More recently, the AEEC Aircraft Data Network Working Group
(ADN W/G) has agai
n taken up the issue, documented in various drafts of Project Paper 664, Part 8
8
.

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 al
l 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 effo
rts,



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 AO
C 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 cha
nging, 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



T
he existing ATSC data link c
ommunications applications of FANS
-
1/A,



T
he 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. Therefo
re, 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
gene
rally 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 t
o provide a common user interface.





6

656
Avionics Interface D
efinition for Flight Management and Communicati ons 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 man
ufacturers can partition Air Traffic
Services (ATS) applications and protocols in different manners between various equipment.

7

660
CNS/ATM Avionics, Functional Allocation and Recommended Architectures

Defines a set of standard
aircraft avionics architec
tures 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 s
tandard represents broad airline
consensus for developing avionics equipment providing CNS/ATM operating capabilities

8

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 e
ither the Compliant Network (CN) or the
Profiled Network (PN) using Internet Engineering Task Force (IETF) standard protocols and services.


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.

N
umerous
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 d
ependence 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 implementati
on, 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 communicat
ion 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.