Home' RTCA Documents for Review : DO-343B Contents © RTCA, 2018
3.3.3 Security Layer for ATN/OSI, ACARS, and VoIP
To provide additional security controls, a VPN may operate between the aircraft and
the ground, and tunnels over the majority of the Inmarsat network (satellite, RAN and
CN). An AES supporting ACARS (but not ATN/OSI) is permitted but not required to
use the VPN. AES supporting ATN/OSI (including AES supporting both ATN/OSI and
ACARS) are required to use the VPN. An AES utilizing the VPN for ACARS and/or
ATN/OSI is also required to use the VPN for VoIP. The VPN terminates within the AES
on the aircraft and within a security gateway within the ground aero rack which also
houses the gateways for ATN/OSI, ACARS, and VoIP. The VPN ensure mutual
authentication of the endpoints and integrity of data using IPSec. Access to ATN/OSI,
ACARS, and VoIP services is controlled using a PKI system, which is responsible for
enrolling aircraft and ground gateways onto the system and producing signed
certificates to vouch for their authenticity. Due to the constantly changing population of
aircraft the enrolment process and distribution of certificates needs to be dynamic.
Similarly, VPNs are required with each of the connecting ANSP/ACSP partners for
delivery of ATS Datalink traffic - these VPNs can be statically established.
3.3.4 ACARS and ATN/OSI
184.108.40.206 Introduction (ACARS)
This service is primarily an IP packetization of ACARS messaging whereby ARINC
618/620 messages and protocols are maintained outside both the ground and aircraft
ACARS over SBB uses a prioritized Standard IP connection. One of the main roles of
the gateways is to set up the PDP contexts required to send these IP packets. These
PDP contexts are set up with a Priority or Assured Access level above that of other
BGAN users. The service handles one ACARS block at a time to an aircraft due to the
ARINC 620 limitation of being ‘stop and wait’ protocol.
The gateway function (the Aircraft Datalink Gateway (ADGW)) on the aircraft
(incorporated within the AES) and another on the ground (the Ground Datalink
Gateway (GDGW)) encapsulate ACARS messages and select the appropriate satellite
link. The SBB 3G components in the AES, RAN and CN provide a transport
mechanism with priority / pre-emption capability but otherwise are no different to the
SBB non-priority IP service.
The interface to the CMU re-uses Williamsburg over ARINC 429, allowing integration
on the aircraft for the ACARS service without changes to the CMU or Aircraft End
System. This interface is unchanged from that currently defined in the ARINC 741 and
ARINC 781 Characteristics for AESs. The intention is that the SBB ACARS service
may easily be implemented by AES conforming to these standards.
The interface from the Inmarsat infrastructure to the CNPs is a small extension of the
interface used for the Classic aero service operating over the Inmarsat-3 and Inmarsat-
220.127.116.11 Introduction (ATN/OSI)
The ATN/OSI service is similar to the ACARS service. ATN/OSI CLNP datagrams are
encapsulated within a prioritized Standard IP connection in the same way as ACARS
messages and sent between the ADGW and GDGW. In addition, the AeGGW contains
an Air-Ground Router that is the peer of the ATN/OSI router functionality in the CMU.
The ground side interface to ANSPs and CNPs is the same as for VDL Mode 2 and is
defined in the ICAO ATN manual. The airside interface to the CMU is an evolution of
the equivalent ACARS CMU to SDU interface.
18.104.22.168 SBB ACARS and ATN/OSI service architecture overview
Figure 3-12 34 is an overview of the ACARS and ATN/OSI data service architecture.
34 For those AES not implementing a VPN, the architecture is similar but without the ASGW, GSGW and smart
Links Archive Navigation Previous Page Next Page