MARK 3 AVIATION SATELLITE

COMMUNICATION SYSTEMS

ARINC CHARACTERISTIC 781-6

PUBLISHED: December 5, 2012

AN DOCUMENT
Prepared by AEEC
Published by
AERONAUTICAL RADIO, INC.
2551 RIVA ROAD, ANNAPOLIS, MARYLAND 21401-7435
 DISCLAIMER

THIS DOCUMENT IS BASED ON MATERIAL SUBMITTED BY VARIOUS PARTICIPANTS

DURING THE DRAFTING PROCESS. NEITHER AEEC, AMC, FSEMC NOR ARINC HAS
MADE ANY DETERMINATION WHETHER THESE MATERIALS COULD BE SUBJECT TO
VALID CLAIMS OF PATENT, COPYRIGHT OR OTHER PROPRIETARY RIGHTS BY
THIRD PARTIES, AND NO REPRESENTATION OR WARRANTY, EXPRESS OR
IMPLIED, IS MADE IN THIS REGARD.

ARINC INDUSTRY ACTIVITIES USES REASONABLE EFFORTS TO DEVELOP AND

MAINTAIN THESE DOCUMENTS. HOWEVER, NO CERTIFICATION OR WARRANTY IS
MADE AS TO THE TECHNICAL ACCURACY OR SUFFICIENCY OF THE DOCUMENTS,
THE ADEQUACY, MERCHANTABILITY, FITNESS FOR INTENDED PURPOSE OR
SAFETY OF ANY PRODUCTS, COMPONENTS, OR SYSTEMS DESIGNED, TESTED,
RATED, INSTALLED OR OPERATED IN ACCORDANCE WITH ANY ASPECT OF THIS
DOCUMENT OR THE ABSENCE OF RISK OR HAZARD ASSOCIATED WITH SUCH
PRODUCTS, COMPONENTS, OR SYSTEMS. THE USER OF THIS DOCUMENT
ACKNOWLEDGES THAT IT SHALL BE SOLELY RESPONSIBLE FOR ANY LOSS, CLAIM
OR DAMAGE THAT IT MAY INCUR IN CONNECTION WITH ITS USE OF OR RELIANCE
ON THIS DOCUMENT, AND SHALL HOLD ARINC, AEEC, AMC, FSEMC AND ANY
PARTY THAT PARTICIPATED IN THE DRAFTING OF THE DOCUMENT HARMLESS
AGAINST ANY CLAIM ARISING FROM ITS USE OF THE STANDARD.

THE USE IN THIS DOCUMENT OF ANY TERM, SUCH AS SHALL OR MUST, IS NOT
INTENDED TO AFFECT THE STATUS OF THIS DOCUMENT AS A VOLUNTARY
STANDARD OR IN ANY WAY TO MODIFY THE ABOVE DISCLAIMER. NOTHING
HEREIN SHALL BE DEEMED TO REQUIRE ANY PROVIDER OF EQUIPMENT TO
INCORPORATE ANY ELEMENT OF THIS STANDARD IN ITS PRODUCT. HOWEVER,
VENDORS WHICH REPRESENT THAT THEIR PRODUCTS ARE COMPLIANT WITH
THIS STANDARD SHALL BE DEEMED ALSO TO HAVE REPRESENTED THAT THEIR
PRODUCTS CONTAIN OR CONFORM TO THE FEATURES THAT ARE DESCRIBED AS
MUST OR SHALL IN THE STANDARD.

ANY USE OF OR RELIANCE ON THIS DOCUMENT SHALL CONSTITUTE AN

ACCEPTANCE THEREOF “AS IS” AND BE SUBJECT TO THIS DISCLAIMER.

This document is published information as defined by 15 CFR Section 734.7 of the Export Administration Regulations (EAR). As publicly available technology under 15 CFR 74.3(b)(3), it is not
subject to the EAR and does not have an ECCN. It may be exported without an export license.
 ©2012 BY
AERONAUTICAL RADIO, INC.
2551 RIVA ROAD ANNAPOLIS, MARYLAND
21401-7435 USA

ARINC CHARACTERISTIC 781-6

MARK 3 AVIATION SATELLITE COMMUNICATION SYSTEMS

Published: December 5, 2012

Prepared by the AEEC

Characteristic 781 Adopted by the AEEC Executive Committee October 4, 2005
Summary of Document Supplements
Supplement Adoption Date Published
Characteristic 781-1 October 11, 2006 November 22, 2006
Characteristic 781-2 September 26, 2007 November 15, 2007
Characteristic 781-3 October 22, 2008 February 9, 2009
Characteristic 781-4 March 31, 2010 May 19, 2010
Characteristic 781-5 May 2, 2012 June 15, 2012
Characteristic 781-6 October 4, 2012 December 5, 2012
A description of the changes introduced by each supplement is included at the end of this document.
 FOREWORD

Aeronautical Radio, Inc., the AEEC, and ARINC Standards

ARINC organizes aviation industry committees and participates in related industry

activities that benefit aviation at large by providing technical leadership and guidance.
These activities directly support aviation industry goals: promote safety, efficiency,
regularity, and cost-effectiveness in aircraft operations.

ARINC Industry Activities organizes and provides the secretariat for international aviation
organizations (AEEC, AMC, FSEMC) which coordinate the work of aviation industry
technical professionals and lead the development of technical standards for airborne
electronic equipment, aircraft maintenance equipment and practices, and flight simulator
equipment used in commercial, military, and business aviation. The AEEC, AMC, and
FSEMC develop consensus-based, voluntary standards that are published by ARINC and
are known as ARINC Standards. The use of ARINC Standards results in substantial
technical and economic benefit to the aviation industry.

There are three classes of ARINC Standards:

a) ARINC Characteristics – Define the form, fit, function, and interfaces of avionics
and other airline electronic equipment. ARINC Characteristics indicate to
prospective manufacturers of airline electronic equipment the considered and
coordinated opinion of the airline technical community concerning the requisites of
new equipment including standardized physical and electrical characteristics to
foster interchangeability and competition.

b) ARINC Specifications – Are principally used to define either the physical

packaging or mounting of avionics equipment, data communication standards, or
a high-level computer language.

c) ARINC Reports – Provide guidelines or general information found by the airlines

to be good practices, often related to avionics maintenance and support.

The release of an ARINC Standard does not obligate any organization or ARINC to
purchase equipment so described, nor does it establish or indicate recognition or the
existence of an operational requirement for such equipment, nor does it constitute
endorsement of any manufacturer’s product designed or built to meet the ARINC
Standard.

In order to facilitate the continuous product improvement of this ARINC Standard, two
items are included in the back of this volume:

An Errata Report solicits any corrections to existing text or diagrams that may be
included in a future Supplement to this ARINC Standard.

An ARINC IA Project Initiation/Modification (APIM) form solicits any proposals for

the addition of technical material to this ARINC Standard.

ii
 ARINC CHARACTERISTIC 781
TABLE OF CONTENTS

1.0 INTRODUCTION AND DESCRIPTION ........................................................................ 1

1.1 Purpose of this Characteristic ...................................................................................... 1
1.2 Relationship of this Document to Other ARINC Standards and Industry Documents ... 1
1.3 Inmarsat System Description ....................................................................................... 3
1.4 Function of Equipment ................................................................................................. 5
1.5 Airborne Avionics Configurations ................................................................................. 5
1.6 Unit Description ........................................................................................................... 6
1.6.1 Satellite Data Unit (SDU)......................................................................................... 6
1.6.2 SDU Configuration Module (SCM) .......................................................................... 6
1.6.3 High Power Amplifier (HPA) .................................................................................... 6
1.6.4 Diplexer/Low Noise Amplifier (DLNA) ...................................................................... 7
1.6.5 HPA LNA Diplexer (HLD) ........................................................................................ 7
1.6.6 Enhanced Low Gain Antenna (ELGA) ..................................................................... 7
1.6.7 Intermediate Gain Antenna (IGA) ............................................................................ 7
1.6.8 High Gain Antenna (HGA) ....................................................................................... 7
1.7 System Performance ................................................................................................... 7
1.7.1 Transmitter Equipment Performance ....................................................................... 7
1.7.2 Receiver Equipment Performance ........................................................................... 8
1.8 Interchangeability......................................................................................................... 9
1.9 Regulatory Approval .................................................................................................... 9
2.0 INTERCHANGEABILITY STANDARDS ..................................................................... 11
2.1 Introduction ................................................................................................................ 11
2.2 Form Factors, Connectors, and Index Pin Coding...................................................... 11
2.2.1 Satellite Data Unit (SDU)....................................................................................... 11
2.2.1.1 SDU Size .......................................................................................................... 11
2.2.1.2 Connectors ....................................................................................................... 11
2.2.1.3 Form Factor ...................................................................................................... 12
2.2.1.4 RF Characteristics for SDU with Integrated HPA .............................................. 12
2.2.1.4.1 Frequency Range ........................................................................................ 12
2.2.1.4.2 RF Output Power ......................................................................................... 12
2.2.1.4.3 Back-off Range, Step Size, and Accuracy .................................................... 12
2.2.1.4.4 Stability ........................................................................................................ 12
2.2.1.4.4.1 RF Output Power Stability ....................................................................... 12
2.2.1.4.4.2 AM/PM Conversion ................................................................................. 13
2.2.1.4.5 Linearity ....................................................................................................... 13
2.2.1.4.5.1 Intermodulation Products......................................................................... 13
2.2.1.4.5.2 EVM2 ....................................................................................................... 14
2.2.1.4.5.3 Spectral Regrowth ................................................................................... 14
2.2.1.4.6 Harmonics, Discrete Spurious Emissions and Noise .................................... 15
2.2.1.4.7 Receiver Noise Figure ................................................................................. 15
2.2.1.4.8 Muting and Carrier Off ................................................................................. 15
2.2.1.4.9 VSWR .......................................................................................................... 16
2.2.1.5 RF Characteristics for SDU with External HPA ................................................. 16
2.2.2 External Flange-mounted High Power Amplifier (HPA).......................................... 16
2.2.2.1 General ............................................................................................................ 16
2.2.2.2 Small Form factor External HPA ....................................................................... 17
2.2.2.3 Large Form Factor External HPA ...................................................................... 17
2.2.3 SDU Configuration Module .................................................................................... 18
2.2.3.1 SCM Form Factor ............................................................................................. 18
2.2.3.2 Connectors ....................................................................................................... 18
2.2.3.3 USIMs .............................................................................................................. 18

iii
 ARINC CHARACTERISTIC 781
TABLE OF CONTENTS

2.2.4 Diplexer/Low-Noise Amplifier (DLNA).................................................................... 18

2.2.4.1 DLNA VSWR .................................................................................................... 20
2.2.4.2 Noise Figure/Gain............................................................................................. 20
2.2.4.3 Insertion Loss and Rejection ............................................................................ 21
2.2.4.3.1 Antenna Port to Receive Port (DLNA Output) .............................................. 21
2.2.4.3.2 Transmit Port to Antenna Port ...................................................................... 21
2.2.4.3.2.1 Type D - Transmit Port to Antenna Port................................................... 21
2.2.4.3.2.2 Type F - Transmit Port to Antenna Port ................................................... 22
2.2.4.3.3 Transmit Port to Receive Port (DLNA Output) .............................................. 22
2.2.4.3.3.1 Type D - Transmit Port to Receive Port (DLNA Output) ........................... 22
2.2.4.3.3.2 Type F - Transmit Port to Receive Port (DLNA Output) ........................... 23
2.2.4.4 DLNA Output Power ......................................................................................... 23
2.2.4.5 DLNA Intermodulation ...................................................................................... 23
2.2.4.5.1 Type F - DLNA Intermodulation Products in Satcom Receive Band ............. 23
2.2.4.5.2 Type F - DLNA Intermodulation Products in GNSS Band ............................. 24
2.2.4.6 DLNA Connectors............................................................................................. 24
2.2.4.7 DLNA Form Factor ........................................................................................... 24
2.2.4.8 DLNA On/Off Control ........................................................................................ 24
2.2.4.9 DLNA BITE ....................................................................................................... 24
2.3 Antenna Specification ................................................................................................ 25
2.3.1 Antenna Coverage Volume ................................................................................... 25
2.3.1.1 Ideal Antenna Coverage Volume ...................................................................... 25
2.3.1.2 Achieved Antenna Coverage Volume ............................................................... 25
2.3.1.3 Antenna Measurement Ground Plane............................................................... 25
2.3.2 High Gain Antenna (HGA) ..................................................................................... 26
2.3.2.1 High Gain Antenna Size ................................................................................... 26
2.3.2.2 High Gain Antenna Connectors ........................................................................ 26
2.3.2.3 High Gain Antenna Form Factor ....................................................................... 26
2.3.2.4 High Gain Antenna Grounding and Bonding ..................................................... 26
2.3.2.5 High Gain Antenna (HGA) Receive System ...................................................... 26
2.3.2.5.1 Frequency of Operation ............................................................................... 26
2.3.2.5.2 Polarization .................................................................................................. 26
2.3.2.5.3 Axial Ratio.................................................................................................... 26
2.3.2.5.4 Receive System Figure of Merit (G/T) .......................................................... 26
2.3.2.5.5 Steering Angle ............................................................................................. 27
2.3.2.5.6 Steering Control ........................................................................................... 27
2.3.2.5.7 Overload Capability...................................................................................... 27
2.3.2.5.8 Receive Antenna VSWR .............................................................................. 28
2.3.2.5.9 Satellite Discrimination ................................................................................. 28
2.3.2.5.10 Phase Discontinuity ..................................................................................... 28
2.3.2.5.11 Carrier-to-Multipath (C/M) Discrimination ..................................................... 28
2.3.2.6 High Gain Antenna Transmit System ................................................................ 28
2.3.2.6.1 Frequency of Operation ............................................................................... 28
2.3.2.6.2 Polarization .................................................................................................. 28
2.3.2.6.3 Axial Ratio.................................................................................................... 28
2.3.2.6.4 Gain ............................................................................................................. 29
2.3.2.6.5 Steering Angle ............................................................................................. 29
2.3.2.6.6 Steering Control ........................................................................................... 29
2.3.2.6.7 Transmit Antenna VSWR ............................................................................. 29
2.3.2.6.8 Output Power Capability .............................................................................. 29
2.3.2.6.9 Satellite Discrimination ................................................................................. 29
2.3.2.6.10 Phase Discontinuity ..................................................................................... 29

iv
 ARINC CHARACTERISTIC 781
TABLE OF CONTENTS

2.3.2.6.11 Carrier-to-Multipath (C/M) Discrimination ..................................................... 30

2.3.2.6.12 L-band System Isolation............................................................................... 30
2.3.2.6.13 Antenna Intermodulation .............................................................................. 31
2.3.2.6.13.1 Antenna Intermodulation Products in Satcom Receive Band ................... 31
2.3.2.6.13.2 Antenna Intermodulation Products in GNSS Band................................... 31
2.3.3 Intermediate Gain Antenna (IGA) .......................................................................... 32
2.3.3.1 Intermediate Gain Antenna Size ....................................................................... 32
2.3.3.2 Intermediate Gain Antenna Connectors ............................................................ 32
2.3.3.3 Intermediate Gain Antenna Form Factor........................................................... 32
2.3.3.4 Intermediate Gain Antenna Grounding and Bonding......................................... 32
2.3.3.5 Intermediate Gain Antenna Receive System .................................................... 32
2.3.3.5.1 Frequency of Operation ............................................................................... 32
2.3.3.5.2 Polarization .................................................................................................. 33
2.3.3.5.3 Axial Ratio.................................................................................................... 33
2.3.3.5.4 Receive System Figure of Merit (G/T) .......................................................... 33
2.3.3.5.5 Steering Angle ............................................................................................. 33
2.3.3.5.6 Steering Control ........................................................................................... 33
2.3.3.5.7 Overload Capability...................................................................................... 34
2.3.3.5.7.1 Receive Antenna VSWR ......................................................................... 34
2.3.3.5.8 Discrimination .............................................................................................. 34
2.3.3.5.9 Phase Discontinuity ..................................................................................... 34
2.3.3.6 Intermediate Gain Transmit System.................................................................. 34
2.3.3.6.1 Frequency of Operation ............................................................................... 34
2.3.3.6.2 Polarization .................................................................................................. 34
2.3.3.6.3 Axial Ratio.................................................................................................... 34
2.3.3.6.4 Gain ............................................................................................................. 35
2.3.3.6.5 Steering Angle ............................................................................................. 35
2.3.3.6.6 Steering Control ........................................................................................... 35
2.3.3.6.7 Transmit Antenna VSWR ............................................................................. 35
2.3.3.6.8 Output Power Capability .............................................................................. 35
2.3.3.6.9 Discrimination .............................................................................................. 35
2.3.3.6.10 Phase Discontinuity ..................................................................................... 35
2.3.3.6.11 L-band System Isolation............................................................................... 35
2.3.3.6.12 Antenna Intermodulation .............................................................................. 36
2.3.3.6.12.1 Antenna Intermodulation Products in Satcom Receive Band ................... 36
2.3.3.6.12.2 Antenna Intermodulation Products in GNSS Band................................... 36
2.3.4 Enhanced Low Gain Antenna (ELGA) ................................................................... 37
2.3.5 Coaxial Cables ...................................................................................................... 37
2.3.5.1 Loss Between SDU and External HPA ............................................................. 37
2.3.5.2 DLNA to Antenna Cable ................................................................................... 37
2.3.5.3 Total Transmit Loss between SDU or HPA and Antenna .................................. 37
2.3.5.4 Loss between LNA and SDU ............................................................................ 37
2.3.6 RF installation issues ............................................................................................ 38
2.4 Standard Interwiring ................................................................................................... 39
2.5 Power Circuitry .......................................................................................................... 40
2.5.1 Primary Power Input .............................................................................................. 40
2.5.2 Power Control Circuitry ......................................................................................... 40
2.6 System Functions and Signal Characteristics ............................................................ 40
2.7 Environmental Conditions .......................................................................................... 40
2.8 Cooling ...................................................................................................................... 41
2.8.1 SDU ...................................................................................................................... 41
2.8.2 Flange Mounted HPA ............................................................................................ 41

v
 ARINC CHARACTERISTIC 781
TABLE OF CONTENTS

2.9 Grounding and Bonding ............................................................................................. 42

2.10 System ATE and BITE Design ................................................................................... 42
2.10.1 General ................................................................................................................. 42
2.10.2 Unit Identification................................................................................................... 42
2.10.3 Built-In Test Equipment (BITE) .............................................................................. 43
2.10.3.1 BITE Display..................................................................................................... 43
2.10.3.2 Fault Monitor .................................................................................................... 44
2.10.3.3 Self-Test Initiation ............................................................................................. 44
2.10.3.4 Monitor Memory Output .................................................................................... 45
2.10.4 Use of Automatic Test Equipment ......................................................................... 45
3.0 SATCOM FUNCTIONS.............................................................................................. 46
3.1 Inmarsat Radio .......................................................................................................... 46
3.1.1 Inmarsat Services ................................................................................................. 46
3.1.1.1 General ............................................................................................................ 46
3.1.1.2 Classic Aero ..................................................................................................... 46
3.1.1.3 Swift64 ............................................................................................................. 47
3.1.1.4 SwiftBroadband ................................................................................................ 48
3.1.2 Management of Radio Interface ............................................................................ 51
3.1.2.1 RF Power ......................................................................................................... 51
3.1.2.2 Antenna ............................................................................................................ 52
3.1.2.3 SwiftBroadband Transmit Burst timing .............................................................. 52
3.1.2.4 GNSS Interference Prevention ......................................................................... 53
3.1.2.4.1 Background.................................................................................................. 53
3.1.2.4.2 Frequency Allocations by Ground Stations................................................... 53
3.1.2.4.3 GNSS Frequency Management in the AES.................................................. 54
3.1.2.4.4 Recommended Frequency Check Algorithm In SDU .................................... 54
3.1.2.5 Mapping User Interfaces to Radio Interfaces .................................................... 55
3.1.2.6 Selection of Inmarsat Services, Satellites, and Ground Stations ....................... 56
3.2 User Interfaces .......................................................................................................... 57
3.2.1 Pilot System Interfaces for Voice Communication ................................................. 57
3.2.1.1 Introduction....................................................................................................... 57
3.2.1.2 Call Control....................................................................................................... 57
3.2.1.2.1 MCDU .......................................................................................................... 57
3.2.1.2.2 ACP ............................................................................................................. 58
3.2.1.2.3 AMS ............................................................................................................. 59
3.2.1.3 Call Annunciation.............................................................................................. 60
3.2.1.4 Call Priority ....................................................................................................... 60
3.2.1.5 Call Routing ...................................................................................................... 61
3.2.1.6 SAT Phone Using Classic Aero Services .......................................................... 61
3.2.1.6.1 General ........................................................................................................ 61
3.2.1.6.2 Air-to-Ground Call ........................................................................................ 61
3.2.1.6.3 Ground-to-Air Call ........................................................................................ 63
3.2.1.7 SAT Phone using SwiftBroadband .................................................................... 63
3.2.1.8 SAT Radio ........................................................................................................ 64
3.2.1.9 Williamsburg SDU Controller ............................................................................ 65
3.2.2 Cockpit ACARS Data ............................................................................................ 65
3.2.3 ISDN Interface ...................................................................................................... 66
3.2.4 Ethernet ................................................................................................................ 66
3.2.4.1 Purpose and Requirements of the Interface...................................................... 66
3.2.4.2 Interface Components ...................................................................................... 67
3.2.4.3 Interface Fundamentals .................................................................................... 68
3.2.4.4 Multiple Ethernet Interfaces .............................................................................. 69

vi
 ARINC CHARACTERISTIC 781
TABLE OF CONTENTS

3.2.5 CEPT-E1 ............................................................................................................... 69

3.2.6 POTS .................................................................................................................... 69
3.3 Software Data Loader Interfaces ............................................................................... 69
3.4 Miscellaneous ............................................................................................................ 69
3.4.1 Dual ...................................................................................................................... 69
3.4.1.1 Classic Aero Operations ................................................................................... 70
3.4.1.1.1 General ........................................................................................................ 70
3.4.1.1.2 Interface Between SDUs .............................................................................. 71
3.4.1.1.3 Cold and Warm Standby .............................................................................. 71
3.4.1.1.4 Cooperative Mode........................................................................................ 72
3.4.1.2 SwiftBroadband & Swift64 Operations .............................................................. 72
3.4.2 Configuration & Identification Data ........................................................................ 72
3.4.2.1 ORT.................................................................................................................. 72
3.4.2.1.1 General ........................................................................................................ 72
3.4.2.1.2 ORT Synchronization ................................................................................... 73
3.4.2.1.3 ORT Contents .............................................................................................. 74
3.4.2.2 System Configuration Pins ............................................................................... 85
3.4.2.3 AES ID ............................................................................................................. 86
3.4.2.4 Forward/Return ID (Swift64) ............................................................................. 86
3.4.2.5 IMSI and IMEI(SV) (SwiftBroadband) ............................................................... 86
3.4.2.6 Addressing for SwiftBroadband Safety Services ............................................... 87
3.4.2.7 Aircraft Type ..................................................................................................... 87
3.4.3 Security ................................................................................................................. 87
3.5 Priority, Precedence, Preemption, and Preference .................................................... 88
3.6 Future Growth ............................................................................................................ 89
3.6.1 ARINC 664 Deterministic Ethernet ........................................................................ 89
3.6.2 Fiber Optic ............................................................................................................ 89
3.6.3 FANS/ATS over SwiftBroadband ........................................................................... 89
3.6.4 Multi-Frequency Band ........................................................................................... 89
3.7 Passive Intermodulation Built-In Test (PIMBIT) .......................................................... 90
3.7.1 Introduction ........................................................................................................... 90
3.7.2 Technical Background ........................................................................................... 90
3.7.3 SDU Functionality ................................................................................................. 91
3.7.3.1 Frequencies Reserved for PIMBIT .................................................................... 91
3.7.3.2 Transmit Test Signal Levels (EIRP) .................................................................. 91
3.7.3.3 Constant EIRP versus Constant Power to the Antenna .................................... 91
3.7.3.4 ORT Parameters .............................................................................................. 91
3.7.3.5 IM Product Order to be Tested ......................................................................... 92
3.7.3.6 Transmit Signal Off/On Sequence for Receive Signal Monitoring ..................... 92
3.7.3.7 Antenna Beam Pointing Angles to be Tested.................................................... 92
3.7.3.8 PIMBIT Assessment Parameter........................................................................ 92
3.7.3.9 Stabilization and Measurement Times .............................................................. 93
3.7.3.10 Measurement Discard Ratio ............................................................................. 93
3.7.3.11 Measurement of Additional IM Product Orders ................................................. 93
3.7.3.11.1 PIMBIT Results Display/Storage and Immediate Clearing of any “Failure” ... 93
3.7.4 Operational Considerations ................................................................................... 94
3.7.4.1 Prerequisite Conditions..................................................................................... 94
3.7.4.2 Aircraft Orientation............................................................................................ 94
3.7.4.3 Test Initiation .................................................................................................... 94
3.7.4.4 Action Following Test Failure ............................................................................ 94
3.7.4.5 Interpreting Results of the PIMBIT .................................................................... 94
3.7.4.6 AMM Recommendations .................................................................................. 95

vii
 ARINC CHARACTERISTIC 781
TABLE OF CONTENTS

ATTACHMENTS
ATTACHMENT 1-1A GENERAL CONFIGURATION OVERVIEW – SINGLE SATCOM
INSTALLATION ................................................................................. 97
ATTACHMENT 1-1B GENERAL CONFIGURATION OVERVIEW – DUAL SATCOM
INSTALLATION ................................................................................. 98
ATTACHMENT 1-2A SATCOM SYSTEM CONFIGURATION – HPA INTEGRATED
INTO SDU ......................................................................................... 99
ATTACHMENT 1-2B SATCOM SYSTEM CONFIGURATION – OPTIONAL FLANGE
MOUNTED HPA ..................................................................................100
ATTACHMENT 1-3 STANDARD INTERWIRING ................................................................101
ATTACHMENT 1-4 NOTES APPLICABLE TO STANDARD INTERWIRING .....................107
ATTACHMENT 1-4A SYSTEM CONFIGURATION PINS DEFINITION AND
INTERPRETATION .............................................................................113
ATTACHMENT 1-5 SDU FORM FACTOR ..........................................................................121
ATTACHMENT 1-5A SDU TOP PLUG CONNECTOR LAYOUT ..........................................122
ATTACHMENT 1-5B SDU MIDDLE PLUG CONNECTOR LAYOUT ....................................123
ATTACHMENT 1-5C SDU BOTTOM PLUG CONNECTOR LAYOUT ..................................124
ATTACHMENT 1-6 SDU CONFIGURATION MODULE FORM FACTOR ..........................125
ATTACHMENT 1-6A SDU CONFIGURATION MODULE CONNECTOR LAYOUT ..............126
ATTACHMENT 1-7A SMALL FLANGE MOUNT HPA FORM FACTOR ...............................127
ATTACHMENT 1-7B LARGE FLANGE MOUNT HPA FORM FACTOR ...............................129
ATTACHMENT 1-7C FLANGE MOUNT HPA CONNECTOR LAYOUT ................................131
ATTACHMENT 1-8 DIPLEXER/LOW NOISE AMPLIFIER FORM FACTOR ......................132
ATTACHMENT 1-9 ANTENNA COVERAGE ......................................................................135
ATTACHMENT 1-10 HIGH GAIN AND INTERMEDIATE GAIN TOP MOUNT
ANTENNA FOOTPRINT MAXIMUM DIMENSIONAL OUTLINE .........136
ATTACHMENT 1-10A ANTENNA COAXIAL CABLE INTERFACE .........................................137
ATTACHMENT 1-11 NOT USED ..........................................................................................138
ATTACHMENT 1-12 HIGH GAIN AND INTERMEDIATE GAIN ANTENNA CONTROL
CONNECTOR LAYOUT ......................................................................139
ATTACHMENT 2 ARINC 429 LABELS AND WORD FORMATS USED IN THE
AVIATION SATELLITE COMMUNICATIONS SYSTEM .....................140
ATTACHMENT 2A ANTENNA CONFIGURATION DATA REPORTING ...........................154
ATTACHMENT 2B BIT-ORIENTED FAULT REPORTING PROTOCOL ...........................161
ATTACHMENT 3 COCKPIT VOICE – SAT PHONE STATE MACHINE FOR
NORMAL OPERATION .......................................................................171
ATTACHMENT 4-A ARINC 781 SDU FUNCTIONS MATRIX .............................................172
ATTACHMENT 4-B ARINC 781 SDU INTERFACES MATRIX............................................174
ATTACHMENT 5 ETHERNET INTERFACE ....................................................................175
ATTACHMENT 6 ARINC 781 HPA OUTPUT POWER USE CASES ..............................237
ATTACHMENT 7 COMPACT SATCOM SYSTEM DEFINITION (SB200) .......................240
ATTACHMENT 8 NETWORK SECURITY FOR SWIFTBROADBAND
SAFETY SERVICES ........................................................................ 257
ATTACHMENT 9 ATTACHMENT REFERENCE GUIDE ................................................281

APPENDICES
APPENDIX A Acronyms .............................................................................................282
APPENDIX B Security Analysis of the Satcom Ethernet Interface .............................290

viii
 ARINC CHARACTERISTIC 781 – Page 1

1.0 INTRODUCTION AND DESCRIPTION

1.0 INTRODUCTION AND DESCRIPTION

1.1 Purpose of this Characteristic
This document sets forth the desired characteristics of the Mark III Aviation Satellite
Communication (satcom) System avionics intended for installation in all types of
commercial transport and business aircraft. The intent of this document is to provide
general and specific guidance on the form factor and pin assignments for the
installation of the avionics primarily for airline use. It also describes the desired
operational capability of the equipment to provide data and voice communications,
as well as additional standards necessary to ensure interchangeability.
This Characteristic specifies equipment using Inmarsat satellites operating in
L-band. Ku-band and Ka-band equipment is specified in ARINC Characteristic 791.
1.2 Relationship of this Document to Other ARINC Standards and Industry Documents
The Aviation Satellite Communication (satcom) System will present standard
interfaces to a number of other aircraft systems. These include legacy ARINC 429
based systems along with newer ARINC 664 deterministic Ethernet network
systems. Cockpit-based systems (ACARS, MCDU, CFDS, etc.) are progressing
towards communicating via ARINC 664 instead of ARINC 429 interfaces, especially
for new aircraft programs. Cabin-based systems are moving towards switched
Ethernet systems performing the functions of onboard networks such as those
described in ARINC Characteristic 763.
ARINC Specification 404A: Air Transport Equipment Cases and Racking
ARINC Report 413A: Guidance for Aircraft Electrical Power Utilization and Transient
Protection
ARINC Specification 429: Digital Information Transfer System
ARINC Specification 600: Air Transport Avionics Equipment Interfaces
ARINC Report 604: Guidance for Design and Use of Built-In Test Equipment
ARINC Specification 608A: Design Guidance for Avionics Test Equipment
ARINC Report 615: Airborne Computer High Speed Data Loader
ARINC Report 615A: Software Data Loader Using Ethernet Interface
ARINC Specification 618: Air/Ground Character-Oriented Protocol Specification
ARINC Specification 619: ACARS Protocols for Avionic End Systems
ARINC Specification 620: Data Link Ground System Standard and Interface
Specification (DGSS/IS)
ARINC Specification 623: Character-Oriented Air Traffic Services (ATS)
Applications
ARINC Report 624: Design Guidance for Onboard Maintenance System
ARINC Specification 626: Standard ATLAS Language for Modular Test
ARINC Report 627: Programmers Guide to SMARTTM Systems Using ARINC 626
ATLAS
ARINC Specification 653: Avionics Application Software Standard Interface
ARINC CHARACTERISTIC 781 – Page 2

1.0 INTRODUCTION AND DESCRIPTION

ARINC Specification 664: Aircraft Data Network, Part 2, Ethernet Physical and
Data Link Layer Specification
ARINC Specification 664: Aircraft Data Network, Part 7, Avionics Full Duplex
Switched Ethernet Network
ARINC Report 665: Loadable Software Standards
ARINC Characteristic 716: Airborne VHF Communications Transceiver
ARINC Characteristic 724B: Aircraft Communications Addressing and Reporting
System (ACARS)
ARINC Characteristic 739: Multi-Purpose Control and Display Unit
ARINC Characteristic 739A: Multi-Purpose Control and Display Unit
ARINC Characteristic 741: Aviation Satellite Communication System, Part 1,
Aircraft Installation Provisions
ARINC Specification 743A: GNSS Sensor
ARINC Characteristic 746: Cabin Communications Systems (CCS)
ARINC Characteristic 758: Communications Management Unit (CMU) Mark 2
ARINC Characteristic 761: Second Generation Aviation Satellite Communication
System, Aircraft Installation Provisions
ARINC Characteristic 763: Network Server Systems
ARINC Characteristic 791: Mark I Aviation Ku-Band and Ka-Band Satellite
Communication System, Part 1, Physical Installation and Aircraft Interfaces
ARINC Specification 801: Fiber Optic Connectors
ARINC Specification 802: Fiber Optic Cables
ARINC Report 803: Fiber Optic System Design Guidelines
ARINC Report 804: Fiber Optic Active Device Specification
ARINC Report 805: Fiber Optic Test Procedures
ARINC Report 806: Fiber Optic Installation and Maintenance
ARINC Specification 808: 3GCN – Cabin Distribution System
ARINC Report 811: Commercial Aircraft Information Security Concepts of Operation
and Process Framework
ARINC Specification 823: Data Link Security, Part 1, ACARS Message Security
EUROCAE ED-12/RTCA DO-178: Software Considerations in Airborne Systems
and Equipment Certification
EUROCAE ED-14/RTCA DO-160: Environmental Conditions and Test Procedures
for Airborne Equipment
EUROCAE ED-202/RTCA DO-326: Airworthiness Security Process Specification
FAA Advisory Circular 20-150: Satellite Voice Equipment
FAA Advisory Circular 20-173: Installation of Electronic Flight Bag (EFB)
Components
 ARINC CHARACTERISTIC 781 – Page 3

1.0 INTRODUCTION AND DESCRIPTION

Inmarsat Aeronautical System Definition Manual (Classic Aero)

Inmarsat Broadband Global Area Network (BGAN) System Definition Manual
ITU-R Recommendation 573: Radio Communication Vocabulary
ITU-T Recommendation Q.850: Digital Subscriber Signalling System No. 1 –
General; Usage of cause and location in the Digital Subscriber Signalling System
No. 1 and the Signalling System No. 7 ISDN User Part
RTCA DO-210: Minimum Operational Performance Standards (MOPS) for
Geosynchronous Orbit Aeronautical Mobile Satellite Services (AMSS) Avionics
(up to and including Change 3)
RTCA DO-229: Minimum Operational Performance Standards for Global Positioning
System/Wide Area Augmentation System Airborne Equipment
RTCA DO-254: Design Assurance Guidance for Airborne Electronic Hardware
RTCA DO-270: Minimum Aviation System Performance Standards (MASPS) for the
Aeronautical Mobile-Satellite (R) Service - AMS(R)S
SAE ARP4754: Guidelines for Development of Civil Aircraft and Systems
1.3 Inmarsat System Description
Inmarsat supports three distinct types of L-band aeronautical services, known as
“Classic Aero,” “Swift64”, and “SwiftBroadband.” All of these services support
different types of voice, fax and data communications to and from an aircraft. An
ARINC 781-compliant Aircraft Earth Station (AES) is intended to support one or
more of these Inmarsat aeronautical services for cockpit and/or cabin use.
The Inmarsat L-band network consists of: a space segment formed by the
Inmarsat-2 (I-2), Inmarsat-3 (I-3), Inmarsat-4 (I-4), and Alphasat (due for launch in
2013) geostationary satellites; a terrestrial ground infrastructure formed by the
Ground Earth Stations (GESs) for Classic Aero, Land Earth Stations (LESs) for
Swift64, and Satellite Access Stations (SASs) for SwiftBroadband; terrestrial
interconnect networks; the AESs; a network control center; and a Business Support
System (BSS). The user links are in L-band (1.5/1.6 GHz). In addition to supporting
services to aeronautical users, the Inmarsat network also supports communications
with land and maritime users.
The latest L-band satellites are the I-4s and Alphasat which support higher data rate
services through the use of a 9-meter (I-4) or 12-meter (Alphasat) satellite antenna
and digital beam forming. The coverage area of the satellites is formed through the
use of a global beam (all satellites), regional beams (I-3 and I-4) and narrow spot
beams (I-4 and Alphasat only). The Inmarsat Classic Aero service is supported
through all generations of Inmarsat satellites; the Swift64 service is supported
through the I-3 and I-4 satellites, and the SwiftBroadband service is supported
through I-4 and Alphasat satellites.
The Inmarsat Classic Aero service supports multiple simultaneous voice channels,
4.8 kbps fax, packet-mode data at a channel-rate of up to 10.5 kbps, and real-time
two-way circuit-mode data at up to 9.6 kbps. The service interfaces with the
international X.25 and public switched telephone and data networks. Furthermore, it
is compliant with the AMSS Standards and Recommended Practices (SARPs)
published by International Civil Aviation Organization (ICAO) to support air traffic
control and distress communications via voice and data link.
ARINC CHARACTERISTIC 781 – Page 4

1.0 INTRODUCTION AND DESCRIPTION

The Inmarsat Swift64 service supports two types of data communications: Mobile
ISDN and an IP-based Mobile Packet Data Service (MPDS). A single Integrated
Services Digital Network (ISDN) channel is a dedicated 64 kbps circuit-switched
connection that may be bonded or multilinked together with other ISDN channels to
support higher data rates. MPDS is a shared 64 kbps connection.
The SwiftBroadband service is designed to deliver cabin and cockpit services for
pilots and cabin crew, together with in-flight Internet access for passengers. The
data rates available on SwiftBroadband are significantly greater than those offered
by Swift64 or Classic Aero. SwiftBroadband supports IP services as well as
traditional circuit-switched voice and ISDN data. The Standard IP data service offers
variable data rates up to 432 kbps (subject to aeronautical terminal capability, link
availability, signaling, and contention). A Streaming IP data service is also available
that offers guaranteed bandwidth-on-demand communications. Typical applications
for SwiftBroadband include:
• Traditional telephony services.
• Internet access, e.g.,
o web browsing
o e-mail
o file transfer
o video conferencing
o Intranet access (i.e., corporate WAN access via secure Virtual Private
Network (VPN) connection).
• ACARS-based and voice Future Air Navigation System (FANS) Air Traffic
Services (ATS).
There are four user terminal types defined for the SwiftBroadband service. They are
referred to as Class 6 (High Gain Antenna), Class 7 (Intermediate Gain Antenna),
Class 15 (Low Gain Antenna), and Class 4 (Enhanced Low Gain Antenna) user
terminal (UTs). An aircraft UT supports one transmit and one return RF channel. An
ARINC 781 AES can contain one or more SwiftBroadband UTs.
COMMENTARY
At WRC-03, additional spectrum, known as Extended L-band, was
allocated for Mobile Satellite Service. The Alphasat satellite will be the
first Inmarsat satellite to use this spectrum. Terminals with this
capability are known as Extended L-band or XL capable. It is
expected that, over time, equipment manufacturers will incorporate
the additional tuning range into their equipment. Before equipment is
designed for Extended L-band capability, the relevant sections of this
Characteristic should be updated.
Table 1-1 – Tuning Range for Standard and Extended L-band Terminals
Terminal Type Receive (MHz) Transmit (MHz)
Standard 1525 to 1559 1626.5 to 1660.5
Extended L-band 1518 to 1559 1626.5 to 1660.5 and 1668 to 1675
 ARINC CHARACTERISTIC 781 – Page 5

1.0 INTRODUCTION AND DESCRIPTION

1.4 Function of Equipment

The function of this equipment is the transmission, reception and processing of
signals via a satellite providing aeronautical services in the L-band (1518 to 1559
MHz for receive and 1626.5 to 1660.5 and 1668 to 1675 MHz for transmit). The
system should provide a capability for aeronautical satellite communications
requirements external to the aircraft.
The equipment should provide one or more of the following classes of
communication services:
• Air Traffic Services (ATS)
• Aeronautical Operational Control (AOC)
• Aeronautical Administrative Communications (AAC)
• Aeronautical Passenger Communications (APC)
The equipment is designed to provide one or more of the following Inmarsat
services:
• Classic Aero (e.g., Aero H, Aero H+, Aero I)
• Swift64
• SwiftBroadband
The exact services to be provided together with the associated numbers of channels
per service are not described in this document and are left to the individual
manufacturers based on their response to market needs.
In addition, the supported interfaces, features (including HPA size and power), and
functions that a specific satcom system supports are left to the individual
manufacturers based on their response to market needs. Hence, the airframers,
airlines, and operators need to specify the exact configuration of the desired ARINC
781 product – the tables in Attachments 4A and 4B are intended to facilitate this
process.
The equipment is optimized to operate with the I-4 series satellites, but for certain
services will also operate with earlier Inmarsat satellites plus similar satellite services
offered by other operators such as Multifunctional Transport Satellite (MTSAT).
COMMENTARY
Inmarsat requires that an AES be able to tune over the full allocated
band for SwiftBroadband and that channels anywhere in the band
may be allocated. Users are cautioned not to incorporate filters that
protect other installed satcom equipment such as Iridium, since such
filters would typically block access to the full band.
1.5 Airborne Avionics Configurations
The general configuration of the satellite avionics and related systems is shown in
Attachment 1-1. A more detailed block diagram (including alternate configurations) is
shown in Attachment 1-2. The typical configuration of equipment consists of an
ARINC 781 Satellite Data Unit (SDU) (which normally contains an integrated High
Power Amplifier (HPA)), its associated SDU Configuration Module (SCM), plus a
Diplexer/Low Noise Amplifier (DLNA), and an ARINC 781 antenna (which contains
an integrated beam steering function). The SDU is also designed to interface with an
external HPA when, for example, the cable run and hence cable loss from the SDU
ARINC CHARACTERISTIC 781 – Page 6

1.0 INTRODUCTION AND DESCRIPTION

to the DLNA is excessive. The SDU is also designed to interface with legacy top and
side mounted ARINC 741 antenna subsystems, to allow a simple upgrade path to
new satcom services for aircraft that are already equipped with ARINC 741
equipment.
High Gain Antennas (HGAs), Intermediate Gain Antennas (IGAs), and Enhanced
Low Gain Antennas (ELGAs) are defined in this Characteristic.
The SDU is capable of sending and receiving various data rates. The rate is
dynamically selected by the individual applications and by pragmatic assessment of
current operating conditions. The signals are transmitted via geostationary satellite
transponders to/from designated supporting earth stations.
1.6 Unit Description
1.6.1 Satellite Data Unit (SDU)
The signal-in-space parameters are determined by the SDU in relation to
modulation/demodulation, error correction, coding, interleaving, and data rates
associated with the communication channel(s). This unit contains circuits for
conversion of digital and/or analog inputs/outputs to/from radio frequency (RF), and
typically contains an HPA module. The SDU interfaces at L-band with the DLNA.
The SDU provides a number of user interfaces including:
• Cockpit 4-wire analog voice
• Cockpit data (e.g., via an ARINC Characteristic 724B ACARS
Management Unit or an ARINC Characteristic 758 Communications
Management Unit)
• Cockpit Ethernet
• Cabin voice and data via CEPT E1
• Cabin voice via 2-wire analog audio
• Cabin ISDN
• Cabin Ethernet, which may support data services as well as voice via
picocells
• The SDU is defined in two form factors: 6 MCU and 2 MCU. The 2 MCU
form factor is known as a Compact SDU (CSDU) and is defined in
Attachment 7.
1.6.2 SDU Configuration Module (SCM)
The SCM provides a location for retaining SDU configuration information and the
Universal Mobile Telecommunications Service (UMTS) Subscriber Identity Modules
(USIMs). The SCM remains with the aircraft whenever the SDU is changed, and
facilitates the swapping of an SDU without the need to reload Owner Requirements
Tables (ORTs) (if stored in the SCM) or to swap USIMs.
1.6.3 High Power Amplifier (HPA)
The HPA is an optional external amplifier unit that provides an adequate RF power
level, by automatic control, to the antenna in order to maintain the aircraft Effective
Radiated Isotropic Power (EIRP) within required limits. The HPA may be used in
installations where the expected cable loss between the SDU power amplifier output
and antenna input is greater than the allowable cable loss. The HPA may be located
 ARINC CHARACTERISTIC 781 – Page 7

1.0 INTRODUCTION AND DESCRIPTION

near the respective antenna to assure minimum loss of energy at the RF operating
frequency and to avoid excessive thermal dissipation in the HPA.
1.6.4 Diplexer/Low Noise Amplifier (DLNA)
The Diplexer/Low Noise Amplifier (DLNA) are combined into one unit for ease of
installation. The Diplexer couples transmit signals from the SDU (or external HPA) to
the antenna, and couples receive signals from the antenna to the LNA while isolating
transmit frequencies from receive frequencies. The DLNA also filters both the
transmit and receive signals.
The LNA amplifies the very low level L-band receive signal from the antenna and
compensates for RF losses in the coaxial cabling to the SDU.
1.6.5 HPA LNA Diplexer (HLD)
The High Power Amplifier/Low Noise Amplifier/Diplexer (HLD) is a combined HPA
and DLNA unit in a compact physical outline for single channel operation. The HLD
is installed near the antenna and accommodates large cable losses between the
SDU and the HLD. The HLD is defined in Attachment 7.
1.6.6 Enhanced Low Gain Antenna (ELGA)
The ELGA provides a nominal gain of 3 dBic above 20 degrees elevation, and 2 dBic
between 5 and 20 degrees elevation, and supports a single channel. The ELGA may
optionally contain the HPA and DLNA function. The ELGA is defined in
Attachment 7.
1.6.7 Intermediate Gain Antenna (IGA)
The IGA provides a nominal gain of 6 dBic. An ARINC 781 IGA is normally top-
mounted and contains an integrated beam steering function (as opposed to an
ARINC 761 IGA).
1.6.8 High Gain Antenna (HGA)
The HGA provides a nominal gain of 12 dBic. The HGA is normally top-mounted and
contains an integrated beam steering function, which in ARINC Characteristic 741,
requires a separate Line Replaceable Unit (LRU).
1.7 System Performance
1.7.1 Transmitter Equipment Performance
Table 1-2 provides an indication of EIRP required per RF carrier to support various
Inmarsat services.
Table 1-2 – Aircraft EIRP (dBW)
Inmarsat 3 Satellite Inmarsat 4 Satellite
Service/Configuration 1
Global beam Spot beam Global beam Regional beam Spot beam
1200 R, T 9.1 - 9.1 - -
10500 R, T 20.4 - 20.4 - -
2
8400 C initial 18.5 14.5 18.5 - -
21000 C initial 19.5 - 19.5 - -
Swift64 - 22.5 - - -
SwiftBroadband ELGA - - - - 10
SwiftBroadband IGA - - - - 15.1
SwiftBroadband HGA - - - - 20.0
ARINC CHARACTERISTIC 781 – Page 8

1.0 INTRODUCTION AND DESCRIPTION

Notes:
1. The regional beams are not currently used on the I-4 satellites for
Classic Aero.
2. Inmarsat does not currently offer C-channels (other than C8400
Aero I) or 10500 R/T-channels in the I-3 spot or I-4 regional
beams.
The transmit system is equipped to adjust the EIRP according to commands from
the earth station.
The transmit gain of an HGA or an IGA may vary as its beam position is changed
while tracking a satellite from an aircraft in motion. To maintain a more constant
EIRP as the antenna's beam position is changed, the antenna provides transmit gain
for the current beam position on its ARINC 429 bus (in the antenna status word) to
the SDU. The antenna should report its gain in the direction currently pointed with a
resolution of 0.5 dB. The SDU should make appropriate HPA adjustments to
maintain a given EIRP whenever an antenna gain change is reported. The SDU
should also monitor HPA output power when one data channel is active or under
other determined signal conditions and make appropriate HPA adjustments to
maintain the EIRP to compensate for drifts in the HPA output power.
The antenna beam steering interface from the SDU to the antenna should be an
ARINC 429 bus.
The antenna beam steering function should be capable of maintaining the
transmitted beam performance with aircraft attitude rates of change of up to 7.5
degrees per second.
1.7.2 Receiver Equipment Performance
The receiver system performance is determined by the characteristics of the antenna
subsystem, the DLNA, the SDU and the interconnecting RF cables. This includes all
of the satcom equipment's RF systems and circuits from the antenna to the
demodulated baseband output. The design parameters of each of these system
elements have been described to achieve the following receiver figure of merit (gain-
to-noise temperature ratio or G/T) values. For a switched beam antenna, this
example corresponds to the main beam for any pointing angle.
IGA HGA ELGA
G/T -19 dB/K -13 dB/K -21 dB/K

The above values for G/T should be achieved under the conditions in Section
2.3.2.5.4. Under the operational RF environment; e.g., when the receive antenna is
illuminated in its operating bandwidth (34 MHz) by a total RF flux density of -100
dBW/m2 the receiver system performance is intended to provide a bit error rate
(BER) of 1x10-5 or better for classic Aero packet-mode data and 1x10-3 or better for
Classic Aero circuit-mode voice.
The receiver system performance is intended to provide a packet error rate (PER) of
1x10-3 or better for SwiftBroadband packet-switched services and
1x10-2 or better for SwiftBroadband circuit-switched voice.
 ARINC CHARACTERISTIC 781 – Page 9

1.0 INTRODUCTION AND DESCRIPTION

1.8 Interchangeability
ARINC Characteristic 781: Mark 3 Aviation Satellite Communication Systems
comprises two major subsystems and a number of individual units. System
interchangeability is desired for each of the major subsystems, and unit
interchangeability is desired for the individual units. The first major subsystem
comprises the SDU and the SCM. The second is the antenna subsystem, comprising
two LRUs: the antenna with its integrated beam steering function, and the DLNA.
Interchangeability is also desired for the external
flange-mounted HPAs.
There are two instances whereby individual units are defined to be functional
doublets. This means that the interwiring and pin-out definitions are interchangeable;
but due to unique protocol implementations, the supply and acquisition of these units
are manufacturer specific. Functional Doublets are different from Matched Pairs in
that each unit of the Functional Doublet may fail and be changed independently;
whereas, in Matched Pairs, both units must be changed regardless of which unit has
failed.
Functional Doublet #1: SDU and SCM.
Functional Doublet #2: SDU and External Flange Mounted HPA or Optional ARINC
741 HPA.
Additional interchangeability standards may be found in Section 2 of this
Characteristic.
COMMENTARY
Even though the overall satellite system avionics suite comprises
subsystems made up of multiple LRUs, each LRU must be
designed to be autonomous for installation purposes. The airlines
will not accept “matched pairs” of units or similar “unbreakable
bonds” which necessitate changing more than the LRU whose
failure actually causes a subsystem malfunction.
1.9 Regulatory Approval
The equipment should meet all applicable aviation and telecommunication regulatory
requirements. This document does not and cannot set forth the specific
requirements that such equipment must meet to be assured of approval. Such
information must be obtained from the regulatory agencies themselves. Reference
RTCA MOPS, RTCA MASPS, ICAO SARPs, and telecommunications regulations.
COMMENTARY
Minimum Operational Performance Standards (MOPS) are
prepared by Special Committees of RTCA. MOPS define the
performance required of equipment certified by the FAA.
Performance above and beyond that specified in MOPS may be
required for certification.
Minimum Aviation System Performance Standards (MASPS) are
also prepared by Special Committees of RTCA. MASPS
document end-to-end system performance requirements including
terrestrial elements where required.
ARINC CHARACTERISTIC 781 – Page 10

1.0 INTRODUCTION AND DESCRIPTION

Standards and Recommended Practices (SARPs) are prepared

by the International Civil Aviation Organization (ICAO). SARPs
define system-level interoperability requirements for safety
services (ATS and AOC).
COMMENTARY
This document does not define service levels provided (i.e., safety
versus non-safety) by any particular system or avionics
implementation.
 ARINC CHARACTERISTIC 781 – Page 11

2.0 INTERCHANGEABILITY STANDARDS

2.0 INTERCHANGEABILITY STANDARDS

2.1 Introduction
This section sets forth the specific form factors, mounting provisions, interwiring,
input and output interfaces, and power supply characteristics desired for the
satellite avionics equipment. These standards should permit the parallel, but
independent design of compatible equipment and airframe installations. Refer to
ARINC Specification 600: Air Transport Avionics Equipment Interfaces for
detailed information on selected form factors, connectors, etc. ARINC 600
standards with respect to mass, racking attachments, front and rear projections,
and cooling apply.
Manufacturers should note that although this Characteristic does not preclude
the use of standards different from those set forth herein, the practical problems
of redesigning a standard airframe installation to accommodate special
equipment could very well make the use of that equipment prohibitively
expensive for the customer. They should recognize, therefore, the practical
advantages of developing equipment in accordance with the standards set forth
in this document.
Interchangeability standards for the CSDU, ELGA, and HLD are defined in
Attachment 7.
2.2 Form Factors, Connectors, and Index Pin Coding
This document defines two distinct form factors of equipment. The original
definition is based on a 6 MCU SDU, an SCM, an optional flange-mount HPA, a
DLNA, and a HGA or IGA that typically supports multi-channel/multi-service (e.g.,
Classic Aero and SwiftBroadband) operation. More recently, a compact version
of equipment was defined, based on a 2 MCU SDU – known as a Compact SDU
(CSDU), an SCM, a small form factor antenna – known as an Enhanced LGA
(ELGA), and an optional DLNA or HLD (where the HLD is a combined
HPA/DLNA) that supports the SB200 single channel SwiftBroadband service
(either safety or non-safety). This compact version is defined in Attachment 7.
2.2.1 Satellite Data Unit (SDU)
2.2.1.1 SDU Size
The SDU should comply with the dimensional standards in ARINC Specification
600 for the 6 MCU size.
2.2.1.2 Connectors
The SDU should be provided with a low insertion force, size 2 shell receptacle in
accordance with ARINC 600 Attachment 19 (see Attachment 1-5). This
connector should accommodate coaxial and signal interconnections in the top
plug (TP) insert, Quadrax and signal interconnections in the middle plug (MP)
insert, and coaxial, fiber, and power interconnections in the bottom plug (BP)
insert.
The contact arrangements should be as follows:
• Insert arrangement 08 receptacles in accordance with ARINC
Specification 600, Attachment 11, for the top insert (Size 1 coax cavity
and Size 22 sockets).
ARINC CHARACTERISTIC 781 – Page 12

2.0 INTERCHANGEABILITY STANDARDS

• Insert arrangement 120Q2 receptacle in accordance with ARINC

Specification 600, Attachment 20, Figure 20-6.5.5, for the middle
insert (Size 8 Quadrax cavities for pin components and Size 22
sockets).
• Insert arrangement 12F5C2 receptacle in accordance with ARINC
Specification 600, Attachment 19, Figure 19-49.19, for the bottom
insert (Size 12 pins, Size 16 pin, Size 5 coax cavities, and Size 16
optical cavities).
• Index pin code 081 in accordance with ARINC Specification 600,
Attachment 18, should be used on both the SDU and the aircraft rack
connectors.
2.2.1.3 Form Factor
See Attachment 1-5.
2.2.1.4 RF Characteristics for SDU with Integrated HPA
2.2.1.4.1 Frequency Range
The SDU should operate over the frequency range of 1525.0 to 1559.0 MHz
(receive) and 1626.5 to 1660.5 MHz (transmit).
2.2.1.4.2 RF Output Power
The SDU output power should be capable of delivering the satellite services for
which the SDU is designed (see Attachment 6, Case 1 and 2). The SDU
maximum total RF output power should be no more than 80 W (average, not
peak envelope) when operating with an HGA and 40 W when operating with an
IGA.
Note: The purpose of the output power limit is to protect the
antenna subsystem including RF cable power handling
capability.
2.2.1.4.3 Back-off Range, Step Size, and Accuracy
The back-off range, step size, and accuracy of the SDU should be compatible
with the Inmarsat satellite services being provided and should also take into
account variations in antenna gains.
2.2.1.4.4 Stability
2.2.1.4.4.1 RF Output Power Stability
SwiftBroadband
The output power stability should be within ± 0.5 dB of the latest setting change
for a period of 1000 bursts, ignoring the first burst.
Note: The first burst transmitted after a period of non-
transmission exceeding 2 seconds should be
considered to be a “first burst.” The first burst is also
after a retune outside the 200 kHz sub-band. All other
bursts are to be included in RF output power stability
requirements.
 ARINC CHARACTERISTIC 781 – Page 13

2.0 INTERCHANGEABILITY STANDARDS

Existing Classic Aero services and Swift64

Output power stability should be within ± 2 dB.
Note: Stability includes the effect of temperature and
frequency.
2.2.1.4.4.2 AM/PM Conversion
The SDU output should not vary by more than 2o/dB and at a rate not exceeding
30o/2 ms when the output level is adjusted by up to 4 dB in any 80 ms period.
Note: This applies to Classic Aero and Swift64 services.
2.2.1.4.5 Linearity
2.2.1.4.5.1 Intermodulation Products
Table 2-1 – Intermodulation Products
1 2
Classic and Swift64 Services SwiftBroadband Services
Intermodulation Intermod Intermod
Spacing of Carriers Spacing of Carriers
Products Levels Levels
5 kHz to 17 MHz 34 MHz
(3rd Order) (e.g., 10 kHz, 100 kHz, -25 dBc (e.g., 200 kHz, 1 MHz, -29.5 dBc
1 MHz, 14 MHz) 10 MHz, 34 MHz)
<13.5 MHz 34 MHz
(5th Order) (e.g., 10 kHz, 100 kHz, -25 dBc (e.g., 200 kHz, 1 MHz, -29.5 dBc
1 MHz, 13 MHz) 10 MHz, 34 MHz)
34 MHz
13.5 MHz to 14.5 MHz
(7th Order) -30 dBc (e.g., 200 kHz, 1 MHz, -35 dBc
(e.g., 14 MHz)
10 MHz, 34 MHz)
<13.5 MHz
(7th Order) (e.g., 10 kHz, 100 kHz, -33 dBc
1 MHz, 13 MHz)
<13.5 MHz 34 MHz
(Greater than 7th Order,
(e.g., 10 kHz, 100 kHz, -35 dBc (e.g., 200 kHz, 1 MHz, -35 dBc
<12 GHz band)
1 MHz, 13 MHz) 10 MHz, 34 MHz)
(Greater than 7th Order,
-70 dBc -70 dBc
12 to 18 GHz band)

Notes:
1. This performance applies when the SDU is transmitting two
unmodulated carriers each at a power level of half the rated
output power measured at the SDU output connector.
2. This performance applies when the SDU is driven by two
unmodulated carriers each at a power level necessary to
provide the EIRP given in Table 1-2 for the SwiftBroadband
services provided by the SDU. The SDU output power should
be calculated from the EIRP based on a 12 dBic HGA or 6
dBic IGA and a loss from the SDU output to the antenna input
of 2.5 dB. As an alternative test condition, modulated carriers
may be used. The required test levels for modulated carriers
are specified in the Inmarsat BGAN System Definition Manual
(SDM).
ARINC CHARACTERISTIC 781 – Page 14

2.0 INTERCHANGEABILITY STANDARDS

2.2.1.4.5.2 EVM2
The mean (Error Vector Magnitude)2 should be no more than 0.01 while
transmitting a SwiftBroadband carrier at the power level necessary to support the
EIRP of the service being provided - as defined in Table 1-2.
Note: This applies to SwiftBroadband services. Error Vector
Magnitude is a measure of the difference between the
(ideal) waveform and the measured waveform. The
difference is called the error vector, usually referred to
with regard to M-ary I/Q modulation schemes like
QPSK, and shown on an I/Q (in-phase and quadrature)
constellation plot of the demodulated symbols.
Modulation characteristics and EVM are further defined
in the Inmarsat BGAN SDM.
2.2.1.4.5.3 Spectral Regrowth
While transmitting with either an IGA or HGA and using either a π/4 QPSK or 16
QAM modulated bearer at the required output power level, the SDU should
comply with the spectral masks defined below.
Note: This applies to SwiftBroadband services.
0

-5

-10
Relative Spectral Density (dB)

-15

-20

-25 -25 dB, F1 kHz

-30
-32 dB, F2 kHz
-35 -37 dB, F3 kHz

-40

-45
-45 dB, F4 kHz
-50
Offset from Carrier (kHz)
Figure 2-1 – Spectral Regrowth Envelope
 ARINC CHARACTERISTIC 781 – Page 15

2.0 INTERCHANGEABILITY STANDARDS

Table 2-2 – Spectral Regrowth

Offset from Carrier (kHz) for Different Channel Types
Relative
T0.5 T1.0 T2 T4.5
Fx Spectral
Data rate Data rate Data rate Data rate
Density
16.8 kSym/s 33.6 kSym/s 67.2 kSym/s 151.2 kSym/s
dB Offset (kHz) Offset (kHz) Offset (kHz) Offset (kHz)
F1 -25 11.0 22.0 44.0 99.0
F2 -32 14.9 29.8 59.6 134.1
F3 -37 24.8 49.6 99.2 223.2
F4 -45 50.0 100.0 200.0 450.0

Note: T0.5, T1.0, etc. are Inmarsat designators of

SwiftBroadband channel types.
2.2.1.4.6 Harmonics, Discrete Spurious Emissions and Noise
The SDU, when connected to a DLNA, should comply with the emission limits
defined in RTCA DO-210D MOPS and other regulatory documents.
2.2.1.4.7 Receiver Noise Figure
The receive path noise figure for the SDU should not exceed 10 dB under
conditions equivalent to a wide-band input signal level of -50 dBm at the SDU
input. For conditions equivalent to larger input levels, the noise figure (in dB) may
increase in proportion to the signal level (in dBm).
COMMENTARY
This SDU noise figure should allow the system installer a
maximum loss as specified in Section 2.3.5 between the DLNA
receive output port and the SDU. This noise figure and a
maximum loss of 25 dB between the SDU and the DLNA adds
0.05 dB to the satcom receiver noise figure.
Interfering RF energy can exist in frequency bands adjacent to
the AES receive band, such as radiation from a mobile system
used in Japan operating in the 1513 to 1525 MHz band. The
diplexer rejection specified in Section 2.2.4 does not provide
specific protection against interference from RF energy in such
a closely-spaced frequency band. Noise figure which is
increased by an Automatic Gain Control (AGC) function
reacting to interfering RF energy can degrade a desired
channel's carrier-to-noise density ratio (C/No), thereby causing
an apparent degradation of the receiver system performance.
2.2.1.4.8 Muting and Carrier Off
When the SDU is muted by signals from ARINC 741 side-mount antennas, from
maximum rated output power, the SDU RF output level should be at or less than
-10 dBW within 1 ms after receiving the mute command (see Attachment 1-4,
Note 32).
When the SDU is muted by the “Tx Mute” discrete, the SDU RF output level
should be at or less than -40 dBW within one second.
In a “Carrier(s) off” state, the SDU RF output should comply with the “Carriers
Off” limits defined in RTCA DO-210D MOPS and other regulatory documents.
ARINC CHARACTERISTIC 781 – Page 16

2.0 INTERCHANGEABILITY STANDARDS

2.2.1.4.9 VSWR
The SDU output port VSWR (i.e., the VSWR measured looking into the SDU
output port) should not exceed 1.5:1. The SDU should be capable of operating
into a load VSWR of 2.0:1 maximum at any phase angle.
Note: Safety circuitry should be provided to protect the
transmitter output stage in the event of an accidental
short or open circuit at its output.
2.2.1.5 RF Characteristics for SDU with External HPA
COMMENTARY
Although the SDU and external flange mounted HPA are
defined as a functional doublet, it is recommended that the
SDU RF output power is nominaly +23 dBm (when the HPA is
delivering full power) with a maximum value of +28 dBm. The
SDU RF characteristics should be such that when driving the
external HPA, the HPA meets the requirements defined in
Section 2.2.1.4.
2.2.2 External Flange-mounted High Power Amplifier (HPA)
2.2.2.1 General
The purpose of this amplifier is to provide a solution to overcome the cable loss
issues associated with the HPA located internal to the SDU on installations
where the SDU is, in general, greater than 1.4 dB (approximately 35 feet) away
from the DLNA. The design of this HPA should be a functional doublet with the
SDU as the gain stages of the HPA internal to the SDU and the flange-mounted
HPA are manufacturer-specific.
Two external HPA form factors are described in this document; a small form
factor external HPA suitable for installation in locations where space is more
restricted e.g., on short-range/narrow-body aircraft and a large form factor
suitable for installation on larger aircraft, typically long-range/wide-body aircraft.
COMMENTARY
It is anticipated that equipment manufacturers will develop
external HPAs with differing RF output power capabilities. The
objective of the output power ranges specified herein is to
encourage manufacturers to maximize RF output power with
the available power and cooling inputs.
COMMENTARY
Although the SDU and external flange mounted HPA are
defined as a functional doublet, it is recommended that the
HPA RF input power is nominally +5 dBm to +15 dBm (when
the HPA is delivering full power) with a maximum value of +20
dBm. The HPA RF characteristics should be such that when
driven by the SDU, the HPA meets the requirements defined in
Section 2.2.1.4.
The form factor and connector pin-out arrangement are shown in Attachment 1-7.
The connector and pin-out arrangement is common to both the large and small
form factor external HPAs.
 ARINC CHARACTERISTIC 781 – Page 17

2.0 INTERCHANGEABILITY STANDARDS

The communication protocol between the SDU and the external Flange Mounted
HPA is manufacturer specific. However, the SDU to HPA communications use
the same multi-control bus to the antenna. Some labels are reserved for SDU to
antenna communications and should not be used for the SDU to HPA
communications. Other labels defined in ARINC Specification 429 are broadcast
on this multi-control bus by the SDU and should not be used for any other
purpose by the HPA. The list of these labels is available in Attachment 2.
COMMENTARY
The external flange-mounted HPA is not intended to be a
substitute for the internal HPA within the SDU for installations
not truly requiring an external HPA. In most installations, this
device is not needed, as the maximum allowed cable loss
between the SDU (with internal HPA) and antenna subsystem
can be met.
2.2.2.2 Small Form Factor External HPA
The output power of the small form factor external HPA should be between 22 W
and 35 W to ensure that the form factor can be met with minimal weight (See
Attachment 6, Case 3, 4, and 5).
The small form factor external HPA design includes an internal plenum to allow
for a flexible hose attachment for additional cooling purposes. Attachment 1-7A
depicts the size and arrangement of this connection.
Continuous operation within the output power range is expected when cooling is
provided. Continuous operation is not expected (but is desirable) in the absence
of cooling.
2.2.2.3 Large Form Factor External HPA
The output power of the large form factor external HPA should be between 30 W
and 60 W to ensure that the form factor can be met with minimal weight (See
Attachment 6, Case 6 and 8).
The large form factor flange-mounted HPA design includes an internal plenum to
allow for a flexible hose attachment for additional cooling purposes. Attachment
1-7B depicts the size and arrangement of this connection.
When cooling air is available, the unit will operate in an actively-cooled manner;
but when cooling is lost the unit will revert to a passively-cooled operation but at
a reduced services mode of a minimum of 9 W and will inform the SDU of it being
in such a mode (See Attachment 6, Case 7). A minimum clearance of one inch
beyond the envelope defined in Attachment 1-7A and 1-7B should be provided to
facilitate the passively cooled nature of this design when in “loss of cooling
mode.”
The specific design of each installation should be discussed with the installer to
ensure adequate natural cooling around the device.
Continuous operation within the output power range is expected when cooling is
provided. An acceptable duty cycle restriction could then be applied as
necessary and could consist of the SDU restricting services to match the HPA
capability to retain cockpit functions in instances where the ambient temperature
is at an extreme.
ARINC CHARACTERISTIC 781 – Page 18

2.0 INTERCHANGEABILITY STANDARDS

2.2.3 SDU Configuration Module

2.2.3.1 SCM Form Factor
The SCM form factor should comply with Attachment 1-6.
2.2.3.2 Connectors
The SCM should include a 15-pin D-type male connector and locking screws.
The connector layout is defined in Attachment 1-6A.
2.2.3.3 USIMs
The SCM should be able to accommodate at least 4 USIMs.
2.2.4 Diplexer/Low-Noise Amplifier (DLNA)
The following characteristics apply to both the Type D and to the Type F DLNA
unless otherwise stated.
COMMENTARY
Please note that the Type D DLNA is not suitable for
SwiftBroadband since its passband does not extend down to
1626.5 MHz. The Type D DLNA has been retained in ARINC
Characteristic 781 since a few units have been built and
installed on aircraft for use with Classic Aero and Swift64
services.
COMMENTARY
HISTORICAL DEVELOPMENT OF THE DIPLEXER
The overall AES transmitter system Harmonics, Spurious, and
Noise (HSN) and Intermodulation (IM) Product requirements
are predicated on performance characteristics of the transmit
filter in the diplexer that is described in ARINC Characteristics
741, 761, and 781 for AES system configurations and on the
HSN and IM levels that are allowed to be output as byproducts
of the signal generation and amplification processes, i.e.,
primarily the HSN and IM generated in the SDU and HPA.
Since the development of the first versions of the RTCA DO-
210 MOPS and ARINC Characteristic 741, several different
diplexer specifications have been developed. Historically, at
this point in time, there have been six versions of diplexer filter
specifications developed. These are known as Type A,
Modified Type A, Type B, Type C (initially called by the
nickname "Jane" when first introduced), Type D, and Type F.
The Type E nomenclature has been applied to a different
diplexer application and that nomenclature is not being used
for an Inmarsat system diplexer in order to avoid confusion
with the diplexer used in the other application.
The Type A and modified Type A diplexers have been installed
in numerous Inmarsat satcom installations in aircraft. The
Type B diplexer, a proposed pre-HPA filter, and the Type C
diplexer were never commercially developed, qualified, or
installed in aircraft. The Type D and Type F diplexers are
 ARINC CHARACTERISTIC 781 – Page 19

2.0 INTERCHANGEABILITY STANDARDS

more recent developments with a few Type D diplexers having

been developed and installed.
These different diplexer designs were developed over time to
meet changing requirements (1) to protect other services that
operate outside, but nearby and adjacent to, the allocated
Inmarsat satcom transmit band, i.e., 1626.5 to 1660.5 MHz
and (2) to support different parts of the Inmarsat band –
specifically some of the diplexers do not support the bottom
part of the Inmarsat transmit and/or receive band. Diplexers
for SwiftBroadband operation are required to support the full
receive (1525 to 1559 MHz) and full transmit band (1626.5 to
1660.5 MHz). The services to be protected initially included
GPS, GLONASS, Radio Astronomy, and Iridium. More
recently the need for protection has been more completely
recognized as applying to GNSS in general which also now
includes the Galileo system.
The original diplexer design was the Type A model and it
offered sufficient protection only for GPS. The following
Modified Type A diplexer design was developed to give more
protection to GLONASS as well as protecting GPS, thus
covering the entire allocated GNSS frequency band.
At about the same time that the Modified Type A diplexer
specification was being developed, there was concern about
protection for the TFTS system. TFTS operated in the
spectrum immediately above the Inmarsat satcom transmit
band. The Type B diplexer design specification was
developed for ARINC Characteristic 741 to offer protection to
GPS, GLONASS, and TFTS. The Type B diplexer
specifications were not involved in derivation of the
specifications in any of the various RTCA DO-210() MOPS
versions or any of the Changes to the MOPS.
The Type C diplexer specification was developed to provide
additional protection for Aeronautical Mobile-Satellite (Route)
Service (AMS(R)S) services operating in the 1610 MHz to
1626.5 MHz bands. It did not address TFTS. In particular it
was developed to provide an additional 10 dB of protection for
the Iridium system at 1624.5 MHz and below. Along with the
Type C diplexer design, a pre-HPA filter was designed to
further reduce any broadband noise and spurious signals in
the Iridium frequency band that might originate prior to the
HPA in the AES system. Although the Type C diplexer could
have been used in conjunction with the pre-HPA filter to
provide additional HSN out-of-band filtering, the pre-HPA filter
would not have provided significant additional attenuation of
intermodulation products because intermodulation products
originate primarily in the HPA which follows the pre-HPA filter
in the system configuration. At the time the Type C diplexer
design was introduced, Inmarsat committed to not using
transmit frequencies below 1631.5 MHz for Classic Aero and
ARINC CHARACTERISTIC 781 – Page 20

2.0 INTERCHANGEABILITY STANDARDS

Swift64 services in order to provide a “guard band” in which

the Type C diplexer filter rejection response could “roll-off” to
the 10 dB rejection level commencing at 1624.5 MHz and
below.
More recently Inmarsat found it has developed a need for
increased operating spectrum in order to service the higher
speed (hence, wider bandwidth) communications channels
used in SwiftBroadband. To add to its available spectrum,
Inmarsat chose to extend its operational aeronautical
frequencies for SwiftBroadband below 1631.5 MHz, lowering
their operating lower band edge down to 1628.5 MHz. To this
end the Type D diplexer was developed and a few units were
installed. The Type D diplexer design rejection “roll-off” was
designed to begin at 1628.5 MHz and provide significant
rejection to frequencies below 1626.5 MHz, thus protecting
against unwanted emissions affecting the other services below
1626.5 MHz. Specifically, the Type D diplexer provides at
least 10 dB rejection at and below 1625.5 MHz to protect the
Iridium spectrum at the Iridium satellite receivers in orbit (but
potentially not providing sufficient protection for aircraft-
installed Iridium receivers that are on an aircraft with an
Inmarsat system to allow interference-free, simultaneous
operation of both systems).
After a relatively short time since the Type D diplexer was
developed, Inmarsat found that they have a need for even
more spectrum for their SwiftBroadband service than the Type
D diplexer allows. Hence, a Type F diplexer design was
developed to allow Inmarsat operation down to the bottom end
of the allocated Inmarsat satcom transmit frequency band, i.e.,
providing sufficiently low transmission insertion loss all the way
down to 1626.5 MHz while providing at least 10 dB rejection at
1625.5 MHz and below to protect the Iridium spectrum at the
Iridium satellite receivers similar to the Type D diplexer (like
the Type D diplexer, the Type F diplexer potentially does not
provide sufficient protection for on-board Iridium receivers that
are on the same aircraft as an Inmarsat system to allow
interference-free, simultaneous operation of both systems).
2.2.4.1 DLNA VSWR
The VSWR of the DLNAs antenna-port and transmit-port (Tx) should be 1.3:1
maximum. The DLNAs receive port (Rx) VSWR should be 1.5:1 maximum.
Note: In all DLNA performance measurements, any unused
port should be terminated with its characteristic
impedance.
2.2.4.2 Noise Figure/Gain
The DLNA noise figure should be less than 1.2 dB at temperatures below 25° C.
The noise figure may increase with temperature to a maximum of 1.6 dB at the
maximum operating temperature (70° C). The gain should be between 53 and
60 dB under all operating conditions.
 ARINC CHARACTERISTIC 781 – Page 21

2.0 INTERCHANGEABILITY STANDARDS

2.2.4.3 Insertion Loss and Rejection

2.2.4.3.1 Antenna Port to Receive Port (DLNA Output)
The rejection from the antenna-port to the receive port (DLNA output) relative to
the 1525 to 1559 MHz passband level should be:
Frequency (MHz) Rejection
0.0 to 1450.0 > 75 dB
1626.5 to 1660.5 > 120 dB
1660.5 to 18000.0 > 75 dB

2.2.4.3.2 Transmit Port to Antenna Port

2.2.4.3.2.1 Type D - Transmit Port to Antenna Port
The path from the transmit port to the antenna port should have the following
characteristics:
Frequency (MHz) Rejection
0.0 to 1525.0 > 80 dB
1525.0 to 1559.0 > 120 dB
1559.0 to 1585.0 > 111 dB
1585.0 to 1605.0 > 95 dB
1605.0 to 1610.0 > 62 dB
1610.0 to 1614.0 > 40 dB
1614.0 to 1620.0 > 20 dB
1620.0 to 1625.5 > 10 dB
1625.5 to 1629.5 Decreases
1629.5 to 1633.0 Insertion loss < 1.3 dB
1633.0 to 1660.5 Insertion loss < 0.8 dB
1660.5 to 1735.0 Increases
1735.0 to 12000.0 > 50 dB
12000.0 to 18000.0 > 15 dB

The above should be met over the DLNAs operating temperature range.
In addition, the path from the transmit port to the antenna port should have the
following characteristics at ambient and cold temperatures:
Frequency (MHz) Insertion loss
1628.7 to 1629.1 < 1.8 dB
1629.1 to 1629.5 < 1.3 dB
ARINC CHARACTERISTIC 781 – Page 22

2.0 INTERCHANGEABILITY STANDARDS

2.2.4.3.2.2 Type F - Transmit Port to Antenna Port

The path from the transmit port to the antenna port should have the following
characteristics:
Frequency (MHz) Rejection
0.0 to 1525.0 > 80 dB
1525.0 to 1559.0 > 120 dB
1559.0 to 1585.0 > 111 dB
1585.0 to 1605.0 > 95 dB
1605.0 to 1610.0 > 62 dB
1610.0 to 1614.0 > 40 dB
1614.0 to 1620.0 > 30 dB
1620.0 to 1624.5 > 20 dB
1624.5 to 1625.5 > 10 dB
1625.5 to 1626.5 Decreases
1626.5 to 1633.0 Insertion loss < 1.3 dB
1633.0 to 1660.5 Insertion loss < 0.8 dB
1660.5 to 1735.0 Increases
1735.0 to 1865.0 > 50 dB
1865.0 to 3250.0 > 20 dB
3250.0 to 3330.0 > 50 dB
3330.0 to 4000.0 > 40 dB
4000.0 to 12000.0 > 50 dB
12000.0 to 18000.0 > 15 dB

The above should be met over -55°C to +55°C.

Between +55°C to +70°C, the characteristics above may be degraded as follows:

Frequency (MHz) Rejection

1625.0 to 1625.5 > 2.5 dB
2.2.4.3.3 Transmit Port to Receive Port (DLNA Output)
2.2.4.3.3.1 Type D - Transmit Port to Receive Port (DLNA Output)
The rejection from the transmit port to the receive port (DLNA output) relative to
the passband level from the antenna port to the receive port should be as
follows:
Frequency (MHz) Rejection
0.0 to 1350.0 > 100 dB
1350.0 to 1525.0 > 80 dB
1525.0 to 1559.0 > 120 dB
1559.0 to 1565.0 > 80 dB
1565.0 to 1585.0 > 100 dB
1585.0 to 1626.5 > 40 dB
1626.5 to 1660.5 > 120 dB
1660.5 to 2000.0 > 80 dB
2000.0 to 18000.0 > 50 dB
 ARINC CHARACTERISTIC 781 – Page 23

2.0 INTERCHANGEABILITY STANDARDS

2.2.4.3.3.2 Type F - Transmit Port to Receive Port (DLNA Output)

The rejection from the transmit port to the receive port (DLNA output) relative to
the passband level from the antenna port to the receive port should be as
follows:
Frequency (MHz) Rejection
0.0 to 1515.0 > 135 dB
1515.0 to 1580.0 > 125 dB
1580.0 to 2000.0 > 135 dB
2000.0 to 18000.0 > 50 dB

2.2.4.4 DLNA Output Power

The output power capability of the DLNA receive output port should be 10 dBm
minimum at the 1 dB gain compression point. This set of parameters establishes
the linearity for the receive system and is directly related to its two-tone
intermodulation performance.
COMMENTARY
This LNA output should allow the system installer a maximum
loss between the LNA and the SDU as described in Section
2.3.5.3.
Interfering RF energy can exist in frequency bands adjacent to
the AES receive band, such as radiation from a mobile system
used in Japan operating in the 1513 to 1525 MHz band. The
DLNA rejection specified in Section 2.2.4.3 does not provide
specific protection against interference from RF energy in such
a closely-spaced frequency band. Interfering signals
exceeding the output capability of the LNA may cause
suppression of desired weak signals and, thereby, cause an
apparent degradation of the receiver system performance.
2.2.4.5 DLNA Intermodulation
COMMENTARY
D/LNA intermodulation is only specified for the Type F DLNA.
2.2.4.5.1 Type F - DLNA Intermodulation Products in Satcom Receive Band
With two CW carriers, each of power 10.2 dBW anywhere in the band 1626.5 to
1660.5 MHz, the 7th and higher intermodulation product should be less than -133
dBm in the band 1525 to 1559 MHz as measured at the receive port, but with the
power level referenced to the antenna port.
COMMENTARY
The test carrier levels are based on the carrier power level for
the IGA antenna spec level (Section 2.3.3.6.12.1) but
increased by 0.8 dB for the DLNA insertion loss and increased
by 0.3 dB for the DLNA to antenna cable loss.
The required intermodulation level to protect the satcom
receive band are based on a degradation of 6% to the system
noise figure (i.e., ∆T/T=6%) which is equivalent to 0.25 dB. An
interference bandwidth of 170 kHz is assumed, which is
ARINC CHARACTERISTIC 781 – Page 24

2.0 INTERCHANGEABILITY STANDARDS

equivalent to a seventh order intermodulation product formed

by SwiftBroadband (151.2 kSym/s) and Classic (10.5 kSym/s)
bearers.
2.2.4.5.2 Type F - DLNA Intermodulation Products in GNSS Band
With two CW carriers, each of power 10.2 dBW anywhere in the band 1626.5 to
1660.5 MHz, the 5th and higher intermodulation products should each be less
than -100 dBm in the band 1555 to 1595.42 MHz as measured at the antenna
port.
COMMENTARY
The test carrier levels are the same as those used for the
intermodulation products into the satcom receive band.
The intermodulation level is based on the IGA/HGA
intermodulation level at the GPS carrier frequency (1575.42
MHz) but reduced by 40 dB to reflect the satcom to GNSS
antenna isolation, and reduced by approximately an additional
12 dB to partition the intermodulation budget between the
various system components (antenna, cable, and DLNA). To
ease DLNA test, the intermodulation level is not a function of
frequency.
2.2.4.6 DLNA Connectors
The DLNA should use the following connectors for its RF ports:
Port Connector Type
Transmit Port (SDU or HPA) N Jack (Female)
Receive Port (SDU) TNC Jack (Female)
Antenna Port TNC Jack (Female)

The DLNA should use a MIL-C-26482 Series 2 type connector for control and
power interconnections.
Shell size and insert arrangement as per Attachment 1-8A.
2.2.4.7 DLNA Form Factor
See Attachment 1-8 for the form factor of the DLNAs.
Note: The form factor of the two DLNAs are slightly different –
principally in the position of the transmit connector. The
mounting hole locations are the same.
2.2.4.8 DLNA On/Off Control
Provisions are needed to switch the LNA on and off. Note 6 to the Standard
Interwiring in Attachment 1-4 of this Characteristic describes the switching signal.
2.2.4.9 DLNA BITE
Provisions are needed for the DLNA to provide BITE to the antenna. Note 5 to
the Standard Interwiring in Attachment 1-4 of this Characteristic describes the
switching signal.
 ARINC CHARACTERISTIC 781 – Page 25

2.0 INTERCHANGEABILITY STANDARDS

2.3 Antenna Specification

This section sets forth the Antenna characteristics and the need for physical
isolation between L-band antennas. The Antenna system radiates and receives
radio frequency signals between the aircraft and the satellite to enable
communications to and from the aircraft.
Various types of antenna configurations can be utilized as follows:
• An HGA as defined in this document, mounted on top of the fuselage
that is electrically steerable. Top-mount HGAs are mounted on an
adapter plate, which is generally customized for each aircraft type.
The adapter plate should provide a mechanical interface to the aircraft
and facilitate using the same antenna part number across a number of
aircraft types of various fuselage curvatures.
• HGA systems as defined in ARINC Characteristic 741.
• An IGA as defined in this document, mounted on top of the fuselage
that is electrically steerable. Top-mount IGAs are mounted on an
adapter plate, which is generally customized for each aircraft type.
The adapter plate should provide a mechanical interface to the aircraft
and facilitate using the same antenna part number across a number of
aircraft types of various fuselage curvatures.
• An LGA as defined in this document, mounted on top of the fuselage,
providing hemispherical coverage.
This Characteristic does not describe the form factor of mechanically steered
antennas. Providers of mechanically steered antennas should comply with the
performance characteristics, the ARINC 429 control and BITE interface and
electrical interfaces as defined in this Characteristic.
2.3.1 Antenna Coverage Volume
2.3.1.1 Ideal Antenna Coverage Volume
The antennas should achieve the desired performance over an ideal coverage
volume (relative to the aircraft's horizontal line of flight) defined by an elevation
range of 5° to 90° and an azimuth range of 360°. This ideal coverage volume is
illustrated in Attachment 1-9.
2.3.1.2 Achieved Antenna Coverage Volume
The achieved coverage volume over which all the performance characteristics
are satisfied may be less than the ideal antenna coverage volume. As a
minimum, an LGA or IGA subsystem should achieve the required performance
over at least 85% and an HGA over at least 75%, of the ideal coverage volume.
Antenna manufacturers are encouraged to exceed this minimum specification to
enhance communications performance and availability.
2.3.1.3 Antenna Measurement Ground Plane
An antenna ground plane should be used to simulate the conductive mounting
surface on the intended aircraft. The ground plane size should be 94.5 inches
[2.4 m] (L) x 65 inches [1.65 m] (W) ±5%. In addition, the active portion of the
antenna under test should be mounted in the center of the ground plane. The
ground plane should be curved to simulate the radius of curvature of the aircraft
on which it is intended to mount the antenna. This radius should be 120 inches
ARINC CHARACTERISTIC 781 – Page 26

2.0 INTERCHANGEABILITY STANDARDS

[3.05 m] ±5%. Where the antenna is to be installed on an aircraft with a radius of

curvature which differs by more than 20% from that used in the antenna tests,
validity of the results should be justified by analysis and/or measurement.
2.3.2 High Gain Antenna (HGA)
2.3.2.1 High Gain Antenna Size
The top mounted HGA footprint should be a maximum of 43 inches [1092 mm]
long and 14.4 inches [366 mm] wide.
2.3.2.2 High Gain Antenna Connectors
The HGA Control connector should conform to Mil Spec part number MIL-C-
38999 Series III or equivalent, with pin layout as shown in Attachment 1-12.
The HGA RF connector on the antenna should be a TNC jack (female).
2.3.2.3 High Gain Antenna Form Factor
The leading edge of the antenna should be tapered, the height of the antenna
should be minimized (within the constraints of required RF performance) and the
overall shape should be designed to minimize aerodynamic drag. The antenna
should be designed to minimize weight.
The maximum allowable HGA footprint dimensions are presented in Attachment
1-10.
2.3.2.4 High Gain Antenna Grounding and Bonding
The attention of equipment and airframe manufacturers is drawn to the guidance
material in Section 6 and Appendix 2 of ARINC Specification 404A on the subject
of equipment and radio rack grounding and bonding. Particular attention should
be given to bonding and grounding requirements of the antenna system,
especially components mounted outside the airframe.
2.3.2.5 High Gain Antenna (HGA) Receive System
2.3.2.5.1 Frequency of Operation
The HGA receive antenna system should operate on any frequency within the
band 1525 to 1559 MHz.
2.3.2.5.2 Polarization
The polarization should be right-hand circular. The definition of ITU-R
Recommendation 573 applies.
2.3.2.5.3 Axial Ratio
The axial ratio should be less than 6.0 dB for all steering angles and frequencies
of operation. Axial ratio values greater than 6 dB need to be compensated by
additional G/T margin. A value of 2.5 dB should be assumed for the satellite
antenna axial ratio, with the polarization ellipse major axes orthogonal.
2.3.2.5.4 Receive System Figure of Merit (G/T)
The receive antenna should perform such that an overall receive system figure of
merit of at least -13 dB/K is achieved under the following conditions:
 ARINC CHARACTERISTIC 781 – Page 27

2.0 INTERCHANGEABILITY STANDARDS

• Clear sky climatic conditions.

• Satellite elevation angles greater than or equal to 5 degrees within the
coverage volume of the antenna.
• With residual antenna pointing errors (including effects of errors
introduced by the antenna beam steering system).
• With a DLNA noise figure and gain as described in Section 2.2.4.2 at
a temperature of 290 K.
• With a receiver having a noise figure described in Section 2.2.1.4.7 at
the SDU interface at a temperature of 290 K.
• With coaxial cable losses as described in Section 2.3.5 at a
temperature of 290K.
• With the transmitter power of 60 watts (17.8 dBW) at the HGA
antenna connector.
• With noise contribution from passive and active intermodulation
effects and spurious signals associated with multi-carrier operation.
• Including the loss and noise contribution of a radome where a radome
is fitted.
2.3.2.5.5 Steering Angle
The main beam of the antenna should be steerable in accordance with the
coverage specifications.
2.3.2.5.6 Steering Control
The antenna receive beam performance specifications should be maintained on
a wanted satellite that is within the antenna coverage volume described in
Section 2.3.1.1 for aircraft motions that do not cause the aircraft itself to obstruct
the beam. The antenna should point to the commanded direction to within 0.5 dB
of its final gain value within 3 seconds from any initial condition. For switched
beam systems, the signal should not be interrupted by more than 50
microseconds when switching beams.
The HGA should position beams in accordance with the azimuth and elevation
positions given in the ARINC Specification 429 Open Loop Steering Word. If the
antenna is mounted offset the top centerline of the aircraft, the SDU should
adjust the azimuth and elevation to account for the offset.
A current beam is one assigned to optimally point to the chosen satellite for a
given aircraft attitude/heading. When the azimuth and/or elevation angles to the
satellite change to the extent that one or more phase shifters change state, the
new beam is defined as an adjacent beam.
COMMENTARY
Inmarsat Classic Aero SDM (Module 2, Paragraph 3.4.6)
specifies a 3 second acquisition time for open-loop steering.
2.3.2.5.7 Overload Capability
The receive antenna system should be able to survive power in the receive band
of 0 dBm at the antenna port.
ARINC CHARACTERISTIC 781 – Page 28

2.0 INTERCHANGEABILITY STANDARDS

2.3.2.5.8 Receive Antenna VSWR

The antenna VSWR measured at the single antenna input/output port should be
less than 1.5:1 (with respect to a 50 ohm characteristic impedance) for all
antenna beam positioning angles over the receive frequency band (see Section
2.3.2.5.1).
2.3.2.5.9 Satellite Discrimination
The radiation pattern should discriminate by not less than 13 dB between wanted
and unwanted satellite positions over the declared coverage volume and not less
than 5 dB outside the declared coverage volume. This specification assumes
that: (1) satellites are in geostationary orbit, (2) unwanted satellites are not less
than 45 degrees longitude away from the wanted satellite, and (3) the aircraft is
in a straight and level attitude.
Note: Adequate discrimination is vital to satellite L-band
spectrum reuse. Testing should be conducted with a
ground plane representative of the HGA installation on
the aircraft.
2.3.2.5.10 Phase Discontinuity
When switching adjacent beams in a switched beam antenna, the signal phase
over the receive frequency range should not change by more than:
1. Eight degrees for a minimum of 90 percent of all combinations of
adjacent beams.
2. Twelve degrees for a minimum of 99 percent of all combinations of
adjacent beams.
Note: Adjacent beams are defined as beams which have the
minimum spatial separation in a given direction and
whose corresponding phase shifter states differ for at
least one element.
2.3.2.5.11 Carrier-to-Multipath (C/M) Discrimination
The HGA should attenuate the reflected signal from a sea surface relative to the
main signal in the direction of the satellite so as to achieve a minimum C/M of 10
dB at 5° elevation and 12 dB at 20° elevation.
2.3.2.6 High Gain Antenna Transmit System
2.3.2.6.1 Frequency of Operation
The antenna transmit subsystem should operate on any frequency within the
band 1626.5 to 1660.5 MHz.
2.3.2.6.2 Polarization
The polarization should be right-hand circular. The definition of ITU-R
Recommendation 573 applies.
2.3.2.6.3 Axial Ratio
The axial ratio should be less than 6.0 dB for all steering angles and frequencies
of operation. For axial ratio values of greater than 6 dB, compensation in the form
of additional gain is required. A satellite antenna axial ratio of 2.5 dB should be
assumed with the polarization ellipse axes orthogonal.
 ARINC CHARACTERISTIC 781 – Page 29

2.0 INTERCHANGEABILITY STANDARDS

2.3.2.6.4 Gain
The HGA should have a minimum gain of 12 dBic within the achieved antenna
coverage volume.
The antenna reported gain sent from the antenna to the SDU shall be based on
the minimum gain value of the antenna measured at ambient for the highest,
lowest and central frequencies in the transmit band for that pointing angle. This
value shall be rounded to the nearest 0.5 dB and have an accuracy (before
rounding) of -0.5 to +0.5 dB (including gain variation with frequency and
measurement accuracy). This accuracy is required over 80% of the declared
coverage volume.
2.3.2.6.5 Steering Angle
The main beam of the antenna transmit subsystem should be steerable as
necessary to fulfill coverage specifications.
2.3.2.6.6 Steering Control
See Section 2.3.2.5.6.
2.3.2.6.7 Transmit Antenna VSWR
The antenna VSWR measured at the single antenna input/output port should be
less than 1.5:1 (with respect to a 50 ohm characteristic impedance) for all
antenna beam pointing angles over the transmit frequency band.
2.3.2.6.8 Output Power Capability
The antenna system should be able to transmit a continuous single carrier of up
to 60 W (i.e., 17.8 dBW) at the HGA input connector. Peak Envelope Power
(PEP) may exceed 150 watts due to the presence of multiple carriers.
2.3.2.6.9 Satellite Discrimination
The radiation pattern should discriminate by not less than 13 dB between wanted
and unwanted satellite positions over the declared coverage volume and not less
than 5 dB outside the declared coverage volume. This specification assumes
that: (1) satellites are in geostationary orbit, (2) unwanted satellites are not less
than 45 degrees longitude away from the wanted satellite, and (3) the aircraft is
in a straight and level attitude.
Note: Testing should be conducted with a ground plane
representative of the HGA installation on the aircraft.
2.3.2.6.10 Phase Discontinuity
When switching adjacent beams in a switched beam antenna, the signal phase,
over the transmit frequency range should not change by more than:
1. Eight degrees for a minimum of 90 percent of all combinations of
adjacent beams.
2. Twelve degrees for a minimum of 99 percent of all combinations of
adjacent beams.
Note: Adjacent beams are defined as beams which have the
minimum spatial separation in a given direction and
whose corresponding phase shifter states differ for at
least one element.
ARINC CHARACTERISTIC 781 – Page 30

2.0 INTERCHANGEABILITY STANDARDS

2.3.2.6.11 Carrier-to-Multipath (C/M) Discrimination

The HGA should attenuate the reflected signal from a sea surface relative to the
main signal in the direction of the satellite so as to achieve a minimum C/M of 10
dB at 5° elevation and 12 dB at 20° elevation.
2.3.2.6.12 L-band System Isolation
The installation designer should be aware of the need for physical and electrical
isolation between L-band antennas at the following frequencies:
1565 to 1616 MHz GPS/Galileo/GLONASS (GNSS) band
1626.5 to 1660.5 MHz Satcom band
Electrical Isolation - The electrical isolation at GNSS frequencies should be not
less than 40 dB between the HGA and GNSS antenna ports with the HGA
steered toward the GNSS antenna. This 40 dB of electrical isolation is equivalent
to approximately 200 inches of physical isolation between the closest points of
the HGA and other L-band antennas.
COMMENTARY
Prime consideration should be given to providing as much
separation as possible between satcom and GNSS antennas.
The electrical isolation specified above is the same value as in
previous characteristics for satcom (ARINC Characteristics
741 and 761). This isolation, together with use of the Type D
DLNA, provides protection to GPS and Galileo receivers
against 5th and higher satcom intermodulation products.
Examples of measured electrical isolation versus physical
separation of an HGA (12 dBi) and a GPS antenna mounted
on top of the aircraft are shown below. It should be noted that
these levels of isolation were for the worst case where the
beam of the HGA was steered toward the GPS Antenna.

Aircraft Separation Isolation

B777 970 inches 52 dB: Top HGA to GPS
B767 400 inches 46 dB: Top HGA to GPS
From the above it can be concluded that 200 inches provides
40 dB of isolation for a HGA (cutting the distance in half
reduces the isolation by 6 dB). For systems with lower power
and antennas with less gain the distance could be reduced
further (e.g., Aero I with a 20 watt HPA and a 6 dBi IGA could
achieve isolation sufficient to protect GPS with 100 inches of
separation).
On-aircraft measurements have also shown that interfering in-
band signals (intermodulation products from satcom) received
at the GPS antenna that are on the order of -105 dBm can
degrade the GPS C/N by approximately 6 dB. Signals at -116
dBm produced no degradation.
The legacy of 40 dB isolation from ARINC Characteristic 741
stems from the anticipated levels of intermodulation products
 ARINC CHARACTERISTIC 781 – Page 31

2.0 INTERCHANGEABILITY STANDARDS

from a high gain antenna, and the amount of isolation required

to keep the signal received at the GPS antenna at an
acceptable level.
2.3.2.6.13 Antenna Intermodulation
COMMENTARY
The inherent non-linearities associated with RF coaxial
connectors play a significant role in the generation of
intermodulation products. If the end user is not using coaxial
cables and connectors which are specifically made or
recommended by the equipment system supplier, the choice of
coaxial cables and connectors should be made carefully.
Studies have concluded that there are significant differences in
the levels of nonlinear properties depending on the connector
conductor materials used. More specifically, connectors which
employ the use of ferromagnetic materials such as stainless
steel and nickel plated metal should be avoided. Instead, the
use of non-ferromagnetic materials should be used (e.g., silver
plated brass, etc.).
In addition, insulating layers from oxidation and dissimilar
material migration at the connector interface further degrade
linearity and increase with time. Therefore, connectors should
be tightened to the connector manufacturer's recommended
value and checked periodically.
2.3.2.6.13.1 Antenna Intermodulation Products in Satcom Receive Band
For multi-carrier operation, the receive system figure of merit (G/T) of Section
2.3.2.5.4 should include the effects of passive and active seventh and higher
order intermodulation products generated when operating with two carriers, each
with a power of 6.3 watts (8 dBW), anywhere between 1626.5 and 1660.5 MHz.
COMMENTARY
The effect of intermodulation products is an increase in the
equivalent noise temperature in the receive band. This is
usually determined based on measurements with unmodulated
carriers and application of a spreading factor related to the
modulation and the order of the intermodulation product. For
intermodulation products produced from SwiftBroadband (at a
symbol rate of 151.2 kSym/s) and a Classic Aero channel (at a
symbol rate of 10.5 kSym/s) the spreading factor is 52.4 dB for
seventh order products and 52.8 dB for ninth order products.
8 dBW is equivalent to 20 dBW EIRP and 12dBic antenna.
2.3.2.6.13.2 Antenna Intermodulation Products in GNSS Band
For multi-carrier operation, when operating two unmodulated carriers, each with
a power of 8 dBW, anywhere between 1626.5 and 1660.5 MHz, the HGA should
not generate intermodulation products with levels and frequencies as follows:
In the frequency range 1555 to 1575.92 MHz, the level of the intermodulation
product should not exceed -158.5 dBW.
ARINC CHARACTERISTIC 781 – Page 32

2.0 INTERCHANGEABILITY STANDARDS

In the frequency range 1575.92 to 1595.42 MHz, the level of the intermodulation
product may linearly increase with frequency from -158.5 dBW at 1575.92 MHz
to -138.5 dBW at 1595.42 MHz.
Intermodulation levels should be referenced to the output port of an external 1/4-
wave monopole GNSS antenna mounted on a common ground plane with the
HGA under test. The isolation between the monopole and the HGA shall be 40
dB, or suitable compensation to the measurement shall be applied.
COMMENTARY
The antenna intermodulation requirements to protect GNSS
are based on Figures C-1 and C-2 of RTCA DO-229C using
the curve for “Terminal area, enroute & acquisition for all,” and
assuming a safety margin of 6 dB and a multiple equipment
margin of 6 dB. The satcom intermodulation assumes 20 dBW
EIRP, 12 dBic antenna, and interference bandwidth between
100 kHz and 1 MHz.
2.3.3 Intermediate Gain Antenna (IGA)
2.3.3.1 Intermediate Gain Antenna Size
The top mounted IGA footprint should be a maximum of 43 inches [1092 mm]
long and 14.4 inches [366 mm] wide.
2.3.3.2 Intermediate Gain Antenna Connectors
The IGA Control connector should conform to Mil Spec part number MIL-C-
38999 Series III or equivalent, as shown in Attachment 1-12.
The IGA RF connector should be a TNC jack (female).
2.3.3.3 Intermediate Gain Antenna Form Factor
The leading edge of the antenna should be tapered, the height of the antenna
should be minimized (within the constraints of required RF performance), and the
overall shape should be designed to minimize aerodynamic drag. The antenna
should be designed to minimize weight.
The maximum allowable IGA footprint dimensions are presented in Attachment
1-10.
2.3.3.4 Intermediate Gain Antenna Grounding and Bonding
The attention of equipment and airframe manufacturers is drawn to the guidance
material in Section 6 and Appendix 2 of ARINC Specification 404A on the subject
of equipment and radio rack grounding and bonding. Particular attention should
be given to bonding and grounding requirements of the antenna system
especially components mounted outside the airframe.
2.3.3.5 Intermediate Gain Antenna Receive System
2.3.3.5.1 Frequency of Operation
The IGA receive antenna system should operate on any frequency within the
band 1525 to 1559 MHz.
 ARINC CHARACTERISTIC 781 – Page 33

2.0 INTERCHANGEABILITY STANDARDS

2.3.3.5.2 Polarization
The polarization should be right-hand circular. The definition of ITU-R
Recommendation 573 applies.
2.3.3.5.3 Axial Ratio
The axial ratio should be less than 6.0 dB for all steering angles and frequencies
of operation.
2.3.3.5.4 Receive System Figure of Merit (G/T)
The receive antenna should perform such that an overall receive system figure of
merit of at least -19 dB/K is achieved under the following conditions:
• Clear sky climatic conditions.
• Satellite elevation angles greater than or equal to 5 degrees within the
coverage volume of the antenna.
• With residual antenna pointing errors (including effects of errors
introduced by the antenna beam steering system).
• With a DLNA noise figure and gain as described in Section 2.2.4.2 at
a temperature of 290 K.
• With a receiver having a noise figure described in Section 2.2.1.4.7 at
the SDU interface at a temperature of 290 K.
• With coaxial cable losses as described in Section 2.3.5 at a
temperature of 290 K.
• With the transmitter power of 30 watts (14.8 dBW) at the HGA
antenna connector.
• With noise contribution from passive and active intermodulation
effects and spurious signals associated with multi-carrier operation.
• Including the loss and noise contribution of a radome where a radome
is fitted.
2.3.3.5.5 Steering Angle
The main beam of the antenna should be steerable in accordance with the
coverage specifications.
2.3.3.5.6 Steering Control
The antenna receive beam performance specifications should be maintained on
a wanted satellite that is within the antenna coverage volume described in
Section 2.3.1.1 for aircraft motions that do not cause the aircraft itself to obstruct
the beam. The antenna should point to the commanded direction to within 0.5 dB
of its final gain value within 3 seconds from any initial condition. For switched
beam systems, the signal should not be interrupted by more than 50
microseconds when switching beams.
The IGA should position beams in accordance with the azimuth and elevation
positions given in the ARINC 429 Open Loop Steering Word. If the antenna is
mounted offset the top centerline of the aircraft, the SDU should adjust the
azimuth and elevation to account for the offset.
A current beam is one assigned to optimally point to the chosen satellite for a
given aircraft attitude/heading. When the azimuth and/or elevation angles to the
ARINC CHARACTERISTIC 781 – Page 34

2.0 INTERCHANGEABILITY STANDARDS

satellite change to the extent that one or more phase shifters change state, the
new beam is defined as an adjacent beam.
COMMENTARY
Inmarsat Classic Aero SDM (Module 2, Paragraph 3.4.6)
specifies a three-second acquisition time for open-loop
steering.
2.3.3.5.7 Overload Capability
The receive antenna system should be able to survive power in the receive band
of 0 dBm at the antenna port.
2.3.3.5.7.1 Receive Antenna VSWR
The antenna VSWR measured at the single antenna input/output port should be
less than 1.5:1 (with respect to a 50 ohm characteristic impedance) for all
antenna beam positioning angles over the receive frequency band
(see Section 2.3.3.5.1).
2.3.3.5.8 Discrimination
The radiation pattern should discriminate by not less than 7 dB between wanted
and 85% of unwanted satellite positions for all antenna steering angles above 5
degrees elevation. This specification assumes that (1) satellites are in
geostationary orbits, (2) unwanted satellites are not less than 80 degrees
longitude away from the wanted satellite, and (3) the aircraft is in straight and
level flight.
Note: Testing should be conducted with a ground plane
representative of the IGA installation on the aircraft.
2.3.3.5.9 Phase Discontinuity
When switching adjacent beams in a switched beam antenna, the signal phase,
of the receive frequency range, should not change by more than 30 degrees for a
minimum of 99% of all combinations of adjacent beams.
Note: Adjacent beams are defined as beams which have the
minimum spatial separation in a given direction and
whose corresponding phase shifter states differ for at
least one element.
2.3.3.6 Intermediate Gain Transmit System
2.3.3.6.1 Frequency of Operation
The antenna transmit subsystem should operate on any frequency within the
band 1626.5 to 1660.5 MHz.
2.3.3.6.2 Polarization
The polarization should be right-hand circular. The definition of ITU-R
Recommendation 573 applies.
2.3.3.6.3 Axial Ratio
The axial ratio should be less than 6.0 dB for all steering angles and frequencies
of operation.
 ARINC CHARACTERISTIC 781 – Page 35

2.0 INTERCHANGEABILITY STANDARDS

2.3.3.6.4 Gain
The IGA transmit antenna should have a minimum gain of 6 dBic within the
achieved antenna coverage volume.
The antenna reported gain sent from the antenna to the SDU shall be based on
the minimum gain value of the antenna measured at ambient for the highest,
lowest and central frequencies in the transmit band for that pointing angle. This
value shall be rounded to the nearest 0.5 dB and have an accuracy (before
rounding) of -0.5 to +0.5 dB (including gain variation with frequency and
measurement accuracy). This accuracy is required over 80% of the declared
coverage volume.
2.3.3.6.5 Steering Angle
The main beam of the antenna transmit subsystem should be steerable as
necessary to fulfill coverage requirements.
2.3.3.6.6 Steering Control
See Section 2.3.3.5.6.
2.3.3.6.7 Transmit Antenna VSWR
The antenna VSWR measured at the single antenna input/output port should be
less than 1.5:1 (with respect to a 50 ohm characteristic impedance) for all
antenna beam pointing angles over the transmit frequency band.
2.3.3.6.8 Output Power Capability
The antenna system should be able to transmit a continuous single carrier of up
to 30 W (i.e., 14.8 dBW). Peak Envelope Power (PEP) may exceed 75 watts due
to the presence of multiple carriers.
2.3.3.6.9 Discrimination
The radiation pattern should discriminate by not less than 7 dB between wanted
and 85% of unwanted satellite positions for all antenna steering angles above 5
degrees elevation. This specification assumes that (1) satellites are in
geostationary orbits, (2) unwanted satellites are not less than 80 degrees
longitude away from the wanted satellite, and (3) the aircraft is in straight and
level flight.
Note: Testing should be conducted with a ground plane
representative of the IGA installation on the aircraft.
2.3.3.6.10 Phase Discontinuity
When switching adjacent beams in a switched beam antenna, the signal phase,
of the transmit frequency range, should not change by more than 30 degrees for
a minimum of 99% of all combinations of adjacent beams.
Note: Adjacent beams are defined as beams which have the
minimum spatial separation in a given direction and
whose corresponding phase shifter states differ for at
least one element.
2.3.3.6.11 L-band System Isolation
The installation designer should be aware of the need for physical and electrical
isolation between L-band antennas at the following frequencies:
ARINC CHARACTERISTIC 781 – Page 36

2.0 INTERCHANGEABILITY STANDARDS

1565 to 1616 MHz GPS/Galileo/GLONASS band

1626.5 to 1660.5 MHz Satcom band
Electrical Isolation: The electrical isolation at GNSS frequencies should be not
less than 40 dB between the IGA and GNSS antenna ports with the IGA steered
toward the GNSS antenna. This 40 dB of electrical isolation is equivalent to
approximately 100 inches of physical isolation between the closest points of the
IGA and other L-band antennas.
Also refer to commentary in Section 2.3.2.6.12.
2.3.3.6.12 Antenna Intermodulation
2.3.3.6.12.1 Antenna Intermodulation Products in Satcom Receive Band
For multi-carrier operation, the receive system figure of merit (G/T) of Section
2.3.3.5.4 should include the effects of passive and active seventh and higher
order intermodulation products generated when operating with two carriers, each
with a power of 8.1 watts (9.1 dBW), anywhere between 1626.5 and 1660.5 MHz.
COMMENTARY
The effect of intermodulation products is an increase in the
equivalent noise temperature in the receive band. This is
usually determined based on measurements with unmodulated
carriers and application of a spreading factor related to the
modulation and the order of the intermodulation product. For
intermodulation products produced from SwiftBroadband (at a
symbol rate of 151.2 kSym/s) and a Classic aero channel (at a
symbol rate of 10.5 kSym/s) the spreading factor is 52.4 dB for
seventh order products and 52.8 dB for ninth order products.
9.1 dBW is equivalent to 15.1 dBW EIRP and 6 dBic antenna.
2.3.3.6.12.2 Antenna Intermodulation Products in GNSS Band
For multi-carrier operation, when operating two unmodulated carriers, each with
a power of 9.1 dBW, anywhere between 1626.5 and 1660.5 MHz, the IGA should
not generate intermodulation products with levels and frequencies as follows:
In the frequency range 1555 to 1575.92 MHz, the level of the intermodulation
product should not exceed -158.5 dBW.
In the frequency range 1575.92 to 1595.42 MHz, the level of the intermodulation
product may linearly increase with frequency from -158.5 dBW at 1575.92 MHz
to -138.5 dBW at 1595.42 MHz.
Intermodulation levels should be referenced to the output port of an external
1/4-wave monopole GNSS antenna mounted on a common ground plane with
the IGA under test. The isolation between the monopole and the IGA shall be
40 dB, or suitable compensation to the measurement shall be applied.
COMMENTARY
The antenna intermodulation requirements to protect GNSS
are based on Figures C-1 and C-2 of RTCA DO-229C using
the curve for “Terminal area, enroute & acquisition for all”, and
assuming a safety margin of 6 dB and a multiple equipment
margin of 6 dB. The satcom intermodulation assumes 15.1
 ARINC CHARACTERISTIC 781 – Page 37

2.0 INTERCHANGEABILITY STANDARDS

dBW EIRP, 6 dBic antenna and interference bandwidth

between 100 kHz and 1 MHz.
2.3.4 Enhanced Low Gain Antenna (ELGA)
The ELGA characteristics are defined in Attachment 7.
2.3.5 Coaxial Cables
2.3.5.1 Loss Between SDU and External HPA
The loss between the SDU output and optional external HPA input should fall
within the range 8 to 18 dB.
2.3.5.2 DLNA to Antenna Cable
The coaxial cable loss between the antenna system and the DLNA should not
exceed 0.3 dB.
For multicarrier operation, when operating with two CW carriers, each of power
9.4 dBW anywhere in the band 1626.5 to 1660.5, the cable should not generate
(1) fifth or higher intermodulation product greater than -100 dBm in the frequency
range of 1555 to 1595.42 MHz and (2) seventh or higher intermodulation product
greater than -133 dBm in the frequency range of 1525 to 1559 MHz.
COMMENTARY
The test power levels are based on the IGA intermodulation
requirement (Section 2.3.3.6.12) adjusted by the cable loss.
The intermodulation levels are the same as those for the Type
F DLNA (Section 2.2.4.5).
2.3.5.3 Total Transmit Loss between SDU or HPA and Antenna
The maximum values of the transmit cable/insertion losses for the antenna
systems are:
SDU or HPA to DLNA less than 1.4 dB
DLNA Insertion Loss less than 0.8 dB
DLNA to antenna less than 0.3 dB
Therefore:
Total SDU or HPA to Antenna less than 2.5 dB
Note: The DLNA insertion loss may be higher at the bottom
of the transmit band by up to an additional 0.5 dB.
There will be a consequent increase in the overall loss.
2.3.5.4 Loss between LNA and SDU
The total loss between the LNA output and the SDU input should fall within the
range 6 to 25 dB, including the cable and connectors.
COMMENTARY
Interfering RF energy can exist in frequency bands adjacent to
the AES receive band, such as radiation from a mobile system
used in Japan operating in the 1513 to 1525 MHz band. The
diplexer rejection specified in Section 2.2.4.3 does not provide
specific protection against interference from RF energy in such
ARINC CHARACTERISTIC 781 – Page 38

2.0 INTERCHANGEABILITY STANDARDS

a closely-spaced frequency band. Use of a low loss cable may

increase the likelihood that strong interfering RF signals may
have a degrading effect on the apparent receiver system
performance.
2.3.6 RF installation issues
COMMENTARY
The intent of this Characteristic is to define subsystem
components which, when installed on an aircraft equipped with
a multi-channel satcom system with at least one
SwiftBroadband carrier, should provide satcom services in
accordance with systems specifications. Specifically, the
deployment of multi-channel SwiftBroadband requires more
stringent control of intermodulation levels – both passive and
active. The use of antennas, diplexer/low noise amplifiers
(DLNA) and DLNA to antenna RF cables specifically designed
for SwiftBroadband operation are recommended and suitable
requirements are found in other parts of this document (see
Sections 2.3.2.6.13, 2.3.3.6.12 and 2.2.4.5). In addition, the
installation of the DLNA, DLNA to antenna RF cable, and the
antenna (including adaptor plate) may cause PIM and this
section presents some best practices to obtain a low PIM
installation and general maintenance guidelines for aluminum
aircraft fuselages. The installation best practices have not
been specifically addressed in this section for composite
fuselage due to the limited experience and proprietary
technology used in the construction of composite fuselages.
Section 3.7 discusses passive intermodulation built-in test
(PIMBIT) and provides additional technical background into the
sources of intermodulation.
The following items should be considered during installation of a SwiftBroadband
satcom system:
a. Antennas - The antenna should be located on the fuselage such that
the distance between it and other potential intermodulation generators
is assessed. Potential intermodulation generators include:
1. Active ADF antenna (contains ferrites)
2. Passive antennas
3. Magnetic materials
4. Semiconductors
When RF currents radiating from the antenna flow through these
materials intermodulation products may be generated and be coupled
back into the antenna. The resulting signals may interfere with the
reception of the desired incoming signal.
b. Adapter Plates - Adapter plates are often used to provide a mating
interface between the curved aircraft fuselage and the flat mounting
surface of an antenna. The interfaces between the adapter plate and
the fuselage and between the adapter plate and the antenna should
be free of metal particles. When using the adapter plate as a drilling
 ARINC CHARACTERISTIC 781 – Page 39

2.0 INTERCHANGEABILITY STANDARDS

fixture for “zero tolerance” installations, it is especially important to

ensure all surfaces are clean and free of metal particles.
c. DLNA-to-Antenna RF Cable - A single RF cable carries both the high
power transmit signal and the low power received signal between the
DLNA and the antenna. The potential for high intermodulation levels
is great because the transmit power is high. The cable should use
connectors that are non-magnetic and the cable construction should
be designed for low PIM. Each RF cable should be production tested
for low PIM. The minimum bend radius must be observed during cable
installation and in its final configuration. If the minimum bend radius
of the cable is violated, the cable may be damaged (i.e. inner core
could be collapsed, outer shield cracked, etc.) and become a source
of PIM.
d. RF Connectors - The mating surfaces between the male and female
connector represent a metal-to-metal contact that could result in PIM
if the pressure between the mating surfaces is too low. It is
recommended that the RF connectors be tightened using a torque
wrench to torque values recommended in the installation manual. It is
not recommended to only finger-tighten connectors. To prevent
contamination, during storage, equipment that has RF connectors
should have the dust caps left on. Prior to installation the dust caps
should be removed and the connector should be cleaned with an
appropriate applicator and cleaning agent, such as isopropyl alcohol.
The following maintenance guidelines are recommended:
a. If the antenna, DLNA or RF cable is modified (i.e. cables unfastened,
antenna/adapter plate removed for aircraft repainting, etc.), it is
recommended that a PIMBIT test be executed to ensure proper
operation of the satcom system.
b. The antenna radome should not be painted during aircraft re-painting,
as the paint used on aircraft may contain metal particles that could
cause PIM and affect the transmit/reception properties of the antenna.
It is recommended that the antenna either be masked or removed
from the aircraft during (re)painting. If there are small chips or
scratches in the radome, the operator should consult the component
maintenance manual for specific repair instructions.
c. Steel wool should not be used for cleaning of the fuselage, adapter
plate or antenna. Small metal particulate can be difficult to remove
and can cause high levels of PIM.
2.4 Standard Interwiring
The standard interwiring to be installed for the aeronautical satellite system
avionics is set forth in Attachment 1-3 with the applicable notes in Attachment
1-4. This interwiring is designed to provide the degree of interchangeability
specified for the system in Section 1.8 of this document. Manufacturers are
cautioned not to rely on special wires, cabling or shielding for use with particular
units because they may not exist in a standard installation.
ARINC CHARACTERISTIC 781 – Page 40

2.0 INTERCHANGEABILITY STANDARDS

COMMENTARY
Why standardize interwiring?
The standardized interwiring is perhaps the heart of all ARINC
Characteristics. It is this feature which allows the airline
customer to complete his negotiation with the airframe
manufacturer so that the latter can proceed with installation
engineering and initial fabrication prior to airline commitment
on a specific source of equipment. This provides the
equipment manufacturer with many valuable months in which
to put final “polish” on his equipment in development.
2.5 Power Circuitry
2.5.1 Primary Power Input
The aeronautical satellite system should be designed to use 115 V variable
frequency single phase ac power. Aircraft power supply characteristics,
utilization, equipment design limitations and general guidance material are set
forth in ARINC Report 413A: Guidance for Aircraft Electrical Power Utilization
and Transient Protection. The primary power input should be protected by circuit
breakers of the size described in Attachment 1-4.
The equipment should have a power consumption less than or equal to that
shown below.
Normal Operation Normal Operation Loss of Cooling Mode
Equipment
(Internal HPA) (External HPA) (refer to Section 2.2.2.3)
SDU 255 VA max 150 VA max 180 VA max
Antenna/DLNA 60 VA max 60 VA max 60 VA max
Small Form
Factor External Not Applicable 240 VA max Not Applicable
HPA
Large Form
Factor External Not Applicable 440 VA max 150 VA max
HPA

2.5.2 Power Control Circuitry

There should be no master on/off power switching within the avionics. Any user
desiring on/off control should provide, through the medium of a switching function
installed in the airframe, means of interrupting the primary power to the system. It
is probable, however, that on/off switching will not be needed in most installations
and that power will be wired to the system from the circuit breaker panel.
2.6 System Functions and Signal Characteristics
A list of the system functions and signal characteristics for the desired level of
interchangeability for the subsystems comprising the aeronautical satellite
system is set forth in Attachment 1-4.
2.7 Environmental Conditions
The avionics should be specified environmentally in terms of the requirements of
EUROCAE ED-14E/RTCA DO-160E: Environmental Conditions and Test
Procedures for Airborne Equipment, and additional airframe-manufacturer-
specific requirements.
 ARINC CHARACTERISTIC 781 – Page 41

2.0 INTERCHANGEABILITY STANDARDS

2.8 Cooling
COMMENTARY
Equipment failures in aircraft due to inadequate thermal
management have plagued the airlines for many years.
Section 3.5 of ARINC Specification 600 contains everything
airframe and equipment manufacturers need to know to
prevent such problems in the future. They regard this material
as “required reading” for all potential suppliers of satellite
communication equipment and aircraft installations.
Equipment manufacturers should note that airlines may retrofit
satellite equipment into aircraft in which forced air cooling is
not available. They should therefore design their equipment
such that the thermal interface limits set forth in Section 3.5 of
ARINC Specification 600 can be met without such forced
cooling air being provided, or persuade their customers to
accept the presence of a cooling fan inside the component.
For non-ARINC 600 devices such as the flange mounted HPA,
the thermal design, temperature and testing requirements
should comply with ARINC Specification 628, Part 7, Section 4
for Forced Air Cooled and Stand Alone Cooled Equipment, but
with the local environment amended as described in Sections
2.2.2.2 and 2.2.2.3.
2.8.1 SDU
The SDU should be designed to accept, and airframe manufacturers should
configure the installation to provide, forced air cooling as defined in Section 3.5 of
ARINC Specification 600. The airflow rate provided to the SDU in the aircraft
installation should be 50 kg/hr of 40°C (max.) air, and the pressure drop through
the SDU should be 5 ±3 mm of water at this rate. The SDU should be designed
to dissipate less than 225 W and to expend this pressure drop to maximize the
cooling effect. Adherence to the pressure drop standard is necessary to allow
interchangeability of the equipment.
It should be noted that in emergency situations the cooling for the SDU may be
lost. The SDU should be able to detect this situation (without an external input)
and assume it is in “Loss of Cooling Mode.” If required, the SDU should shut
down lower priority communications so that service is still maintained for ATS
and AOC. Information on detailed requirements such as the length of time over
which service is required, and the service required in terms of number and type
of communications, EIRP and duty cycles should be obtained from airframe
manufacturers and regulatory authorities.
2.8.2 Flange Mounted HPA
The small and large form factor flange mounted HPAs should be designed to
accept, and airframe manufacturers should configure the installation to provide,
forced air-cooling.
The airflow rate provided to the small form factor flange mounted HPA in the
aircraft installation should be 50 kg/hr of 60° C (max) air (inlet temperature), and
the pressure drop through the small form factor flange mounted HPA should be
ARINC CHARACTERISTIC 781 – Page 42

2.0 INTERCHANGEABILITY STANDARDS

51 ±5 mm of water at this rate. The small form factor flange mounted HPA should
be designed to expend this pressure drop to maximize the cooling effect.
The airflow rate provided to the large form factor flange mounted HPA in the
aircraft installation should be 72 kg/hr of 60° C (max) air (inlet temperature), and
the pressure drop through the large form factor flange mounted HPA should be
51 ±5 mm of water at this rate. The large form factor flange mounted HPA should
be designed to expend this pressure drop to maximize the cooling effect.
Adherence to these pressure drop standards is necessary to allow
interchangeability of the equipment.
It should be noted that some aircraft may operate with pressure drops other than
51mm. Installations in these aircraft must be discussed with the installer.
It should be noted that in emergency situations the cooling for the flange
mounted HPAs may be lost. The large form factor flange mounted HPA should
be able to detect this situation (without an external discrete input), inform the
SDU and should assume that it is in a “loss of cooling mode.” If required, the
large form factor flange mounted HPA should auto-bias itself to a lower rated
output (minimum 9 W) to ensure that the heat dissipated can be passively cooled
so that service is still maintained for cockpit and some basic cabin services.
Information on detailed requirements such as the length of time over which
service is required, and the service required in terms of number and type of
communications, EIRP and duty cycles should be obtained from airframe
manufacturers and regulatory authorities. The small form factor flange mounted
HPA is not expected to operate in the absence of forced air-cooling.
In addition to the above requirements, the large form factor flange mounted HPA
should be capable of minimum 9 W rated output operations at 35 C° ambient,
with a pressure altitude of up to 25,000 ft. and no cooling air.
2.9 Grounding and Bonding
The attention of equipment and airframe manufacturers is drawn to the guidance
material in Section 6 and Appendix 2 of ARINC Specification 404A on the subject
of equipment and radio rack grounding and bonding. Particular attention should
be given to bonding and grounding requirements of the antenna system
especially components mounted outside the airframe.
2.10 System ATE and BITE Design
2.10.1 General
To enable automatic test equipment (ATE) to be used in the bench maintenance
of the SDU, those internal circuit functions not available at active interconnection
pins and considered by the equipment manufacturer to be needed for automatic
test purposes, should be brought to ATE Reserved pins on the upper insert (TP)
of the connector (see Attachment 1-3).
2.10.2 Unit Identification
The SDU, antenna, and optional HPA should report their equipment identification
codes and serial numbers as defined in ARINC Specification 429 and ARINC
Report 665. The SDU should also provide all satcom LRU software and
hardware revision levels when requested by a centralized fault display unit on the
aircraft or when queried by ATE in the shop.
 ARINC CHARACTERISTIC 781 – Page 43

2.0 INTERCHANGEABILITY STANDARDS

2.10.3 Built-In Test Equipment (BITE)

The SDU described in this Characteristic should contain Built-In Test Equipment
(BITE) capable of detecting and annunciating a minimum of 95% of the faults or
failures which can occur within the SDU and as many faults as possible
associated with the HPA (if fitted), antenna, SCM (if fitted), and the DLNA.
BITE should operate continuously during flight. Monitoring of the results should
be automatic. The BITE should automatically test, detect, isolate, and record
intermittent and steady state failures. The BITE should display system condition
and indicate any faulty LRUs upon activation of the self-test routine. In addition,
BITE should display faults which have been detected during in-flight monitoring.
No failure occurring within the BITE subsystem should interfere with the normal
operation of the SDU.
COMMENTARY
Sufficient margins should be used in choosing BITE
parameters to preclude nuisance warnings. Discrepancies in
SDU operation caused by power bus transients, EMI ground
handling, servicing interference, abnormal accelerations, or
turbulence should not be recorded as faults.
The SDU should be designed to be compatible with a
centralized fault display system as described in ARINC Report
604: Guidance for Design and Use of Built-In Test Equipment
(BITE). The philosophy expressed in ARINC Report 604 is that
on-board avionic systems such as satcom should provide an
interactive, “user friendly,” aid to maintenance. The SDU
should provide a listing of BITE options in menu format for
operator selection. By menu selection, the operator should be
capable of requesting fault status (current and previous),
initiating self-tests and requesting detailed failure information
for diagnostics.
2.10.3.1 BITE Display
BITE information should be made available on all applicable data buses for use
in the centralized fault display as described in ARINC Report 604 and
Attachment 2B (for the Boeing label 35X fault bits). This data will be presented to
the maintenance technician on the display contained within that system. As an
option, the SDU could also have a System/LRU fault status display on the front
panel. This option could be beneficial for local troubleshooting in the electronics
equipment bay.
COMMENTARY
Most users desire an alpha-numeric display to present fault
information to line maintenance personnel. The desire includes
presentation of the information in the form of easily
understandable text -- not coded! The airlines do not want the
maintenance personnel to be burdened with carrying a library
of code translations. The airlines would like to have the fault
analysis capability of BITE using the alpha-numeric display
ARINC CHARACTERISTIC 781 – Page 44

2.0 INTERCHANGEABILITY STANDARDS

equal to or surpassing the capability currently realized with

shop Automatic Test Equipment.
2.10.3.2 Fault Monitor
The results of in-flight or ground operations of BITE should be stored in non-
volatile memory. The size of the memory should be sufficient to retain detected
faults during the previous ten flight legs. The data in the memory should include
flight leg identification, fault description, and faulty LRU identification.
The contents of the memory should be retrievable by BITE operation or by shop
maintenance equipment. Refer to ARINC Report 604 for further guidance on fault
recording.
ARINC Report 604 also specifies that fault data should be sent to the centralized
fault display interface unit on an ARINC 429 data bus at regular intervals. The
SDU should output BITE fault data on all applicable data buses.
COMMENTARY
The airlines have expressed an interest in having BITE data
from as many as 64 previous flight legs available in memory.
A question which must be considered by the equipment
designer is, “What is the scope/purpose of BITE?” It appears
from the unconfirmed failure data that is available from repair
shop operations, that there is merit in considering storage of
data which will identify the Shop Replaceable Unit (SRU).
BITE should be used to detect and isolate faults to the LRU
level.
2.10.3.3 Self-Test Initiation
At the time of equipment turn-on, a power-up self-test should be initiated
automatically as described in ARINC Report 604. In addition, the SDU should,
where practical, provide self-test capability for troubleshooting and installation
verification. The initiation of all test sequences should be possible from the
control portion of the centralized fault display system.
As an aid to shop maintenance and local trouble-shooting on the line, a self-test
mechanism should be provided on the SDU front panel. The momentary
depression of the push button on the front panel of the LRU should initiate a
unit/system self-test. The self-test routine should start with an indicator test in
which all indicator elements are activated simultaneously. If the self-test routine
detects a fault, the “all on” indication should be deactivated leaving the
appropriate “fault” indication activated. If no fault is found, the contents of the
intermittent fault memory should be reviewed. Only the four most recent flight
legs should be considered. If no fault is recorded, the “all on” indication should be
deactivated leaving the “normal” indication visible. If an occurrence of a fault on
one of the four earlier flight legs is detected, the appropriate “fault” indication
should be activated. The activated indications should remain visible until the line
maintenance mechanic presses the self-test button a second time or a “time-out”
period of approximately ten minutes expires. Selection of four as the number of
flight legs, for which intermittent fault memory should be examined for the line
maintenance BITE function, was made in the belief that it could be reduced as
 ARINC CHARACTERISTIC 781 – Page 45

2.0 INTERCHANGEABILITY STANDARDS

confidence in the BITE was built up. Manufacturers are urged to make this
number easily alterable in their BITE implementation.
2.10.3.4 Monitor Memory Output
The BITE monitor memory output should consist of the following:
• An output on all low-speed ARINC 429 data buses to the centralized
fault display interface unit, when so requested, as described in ARINC
Report 604 using the format described therein.
• An output to the display (if provided) located on the SDU, indicating
system and LRU status. An English language alpha-numeric display is
preferred over Light-Emitting Diodes (LEDs) or coded messages.
• An output of undefined format which should be made available at the
ATE reserved pins of the upper connector located on the SDU.
The monitor memory should be capable of being reset in order that stored faults
will not be carried over once an LRU replacement or repair has been affected.
The reset should be initiated only by shop maintenance.
2.10.4 Use of Automatic Test Equipment
Equipment manufacturers should note that the airlines desire to have
maintenance procedures shop verified on automatic test equipment which
conforms to ARINC Specification 608: Standard Modular Avionics Repair and
Test System. The automatic test equipment is expected to execute software with
maintenance procedures written in accordance with ARINC Specification 626:
Standard ATLAS Language for Modular Test and ARINC Report 627:
Programmers Guide for SMARTTM Systems using ARINC 626 ATLAS.
ARINC CHARACTERISTIC 781 – Page 46

3.0 SATCOM FUNCTIONS

3.0 SATCOM FUNCTIONS

3.1 Inmarsat Radio
3.1.1 Inmarsat Services
3.1.1.1 General
The Inmarsat radio function consists of all the required means to transmit and
receive over the Inmarsat satellites in accordance with the Inmarsat
specifications defined in the Inmarsat System Definition Manuals for each of the
services (Classic Aero, Swift64, and SwiftBroadband). The Inmarsat radio
function includes antenna, antenna control, DLNA, RF circuitry, modulation and
demodulation to/from baseband, protocol stacks, any required gateway
functions, and the corresponding control and signaling.
The various services, and channels within services, are supported by some
shared components (e.g., antenna) and by some dedicated components. In
particular “channel units” within the AES may be dedicated to a particular service
or they could be generic and the different service implemented by different
software running within the “channel units.”
The three services and their RF carriers are briefly described below.
3.1.1.2 Classic Aero
The service capability is described in Section 1.3.
Classic Aero is based around four channel types, each of which has a number of
defined data rates:
P-Channel. A packet mode time division multiplexed (TDM) channel used in the
forward direction (ground-to-air) to carry signaling and packet-mode data. The
transmission is continuous from each GES in the satellite network.
R-Channel. A random access (slotted Aloha) channel, used in the return
direction (aircraft to ground) to carry signaling and packet mode data, specifically
the initial signals of a transaction, typically request signals.
T-Channel. A reservation Time Division Multiple Access (TDMA) channel used in
the return direction only. The receiving GES reserves times slots for
transmissions requested by AESs according to length. The sending AES
transmits the messages in the reserved time slots according to priority.
C-Channel. A circuit-mode single channel per carrier (SCPC), used in both
forward and return directions to carry digital voice or data/facsimile traffic. The
use of the channel is controlled by assignment and release signaling at the start
and end of each call.
All channels are digital, use interleaving and forward error correction, and use
either Aviation Binary Phased Shift Keying (ABPSK) modulation or Aviation
Quadrature Phased Shift Keying (AQPSK) modulation.
A Classic Aero AES may use three types of antennas: LGA (nominally 0 dBic),
IGA (nominally 6 dBic) and HGA (nominally 12 dBic), and these support the
following sub-services.
 ARINC CHARACTERISTIC 781 – Page 47

3.0 SATCOM FUNCTIONS

Table 3-1 – Classic Aero AES Services

C-Channels P-Channels R-Channels T-Channels
Service Antenna
Supported Supported Supported Supported
Aero L LGA None 600*, 1200 600*, 1200* 600#, 1200#
Aero H HGA 21000 600*, 1200 600*, 1200* 600#, 1200#
Aero I IGA 8400 600*, 1200 600*, 1200* 600#, 1200#
Aero H+ HGA 21000, 8400 600*, 1200, 10500 600*, 1200*, 10500 600#, 1200#, 10500
* = mandatory, # = mandatory if AES supports a packet data service.

An AES typically has a dedicated P-Channel, a channel that is switchable between

R- and T-channels, and a C-Channel pair for each voice channel supported.
Voice is coded at either 9600 bits per second (21000 C-Channel) or 4800 bits per
second (8400 C-Channel).
600 and 1200 channels operate in the global beams of the satellites, while other
channels can operate in either global or spot beams depending on system settings.
Aero L and Aero H AESs operate in the global beam of the satellite. Aero I and Aero
H+ AESs are spot beam (e.g., regional spot beam) capable.
P-, R- and T-Channels operate at fixed power levels which depend on the channel
data rate. C-Channels use power control in both the forward and return direction
under the control of the GES, where the GES reduces the power when the link
conditions are good (as determined by the link Bit Error Rate) and increase the
power when the link conditions are poor. The C-Channel in the return direction is
continuous for the duration of a call while in the forward direction, discontinuous
transmission (DTX) is used (the carrier is not transmitted when the ground party is
not speaking).
Priority and preemption are supported in both the AES and GES.
Two types of packet data service are supported: data 2 which operates over the
ACARS ground network, and data 3 which operates over the X-25 network.
Channel frequencies are assigned to each GES in the network. Network
Coordination Stations, whose function is to demand assign frequencies from a
common pool, are not currently implemented.
The GESs are dedicated to the Classic Aero services.
3.1.1.3 Swift64
The Swift64 service capability is described in Section 1.3 and consists of a circuit-
switched service known as Mobile ISDN and a PPP-based service (over which IP
can run) known as Mobile Packet Data Service (MPDS).
A Swift64 channel within an AES containing Swift64 functionality supports either
MPDS or Mobile ISDN (i.e., not both simultaneously). The address for the Swift64
channel uses the same Forward and Return IDs for both services. A Swift64 channel
implements one transmit RF carrier and one receive RF carrier. An AES can support
one or more Swift64 channels.
Mobile ISDN and MPDS are operated through different ground infrastructure. The
ground infrastructure of both mobile ISDN and MPDS is also used to support other
Inmarsat markets (land and maritime).
Mobile ISDN uses M/B Land Earth Stations (LES) operated by Inmarsat LES
ARINC CHARACTERISTIC 781 – Page 48

3.0 SATCOM FUNCTIONS

Operators (LESOs) and there are a number of stations per ocean region. Network
Coordination Station (NCS) control frequency assignments to the LES in real time to
maximize spectrum efficiency.
MPDS is operated via Inmarsat operated Satellite Base Stations (SBSs) and there is
one station per ocean region (plus a redundant station).
MPDS uses 33.6 kilo symbols per second (kSym/s) 16 QAM carriers for aeronautical
users with a fixed coding rate in both forward and return directions. RF channels are
multiplexed – that is they carry both signaling and traffic and are shared between
users. MPDS uses power control of the RF carriers in the return direction (from
aircraft) only.
Mobile ISDN uses 33.6 kSym/s 16 QAM carriers for traffic channels with a fixed
coding rate in both forward and return directions. Traffic channels are allocated on a
call by call basis to an individual terminal. Power control of the RF carriers for mobile
ISDN is mandatory in the return direction and optional in the forward direction.
The mobile ISDN and MPDS ground networks do not (currently) support priority and
preemption for aeronautical users.
3.1.1.4 SwiftBroadband
The SwiftBroadband service capability is described in Section 1.3 and summarized
in Figure 3-1.
SwiftBroadband supports both safety and non-safety services and the expected use
of the services to the classes of applications is shown below:
Service APC AAC AOC ATS
SBB Non-safety   
SBB Safety  

For non-safety services, multiple packet switched services and one circuit switched
service are available at a time to a SBB channel in an AES. Circuit switched and
streaming class services are delivered to a user via dedicated bandwidth (using
Quality of Service (QoS) mechanisms in the network). The available streaming rates
to a user depend on terminal class, elevation to satellite and link conditions. Offered
streaming rates are 8, 16, 32, 64, 128 kbps, and X-Stream. The X-Stream mode of
operation assigns a dedicated 200 kHz bearer to the requesting AES for its exclusive
use.
SwiftBroadband safety service delivers ACARS, two voice channels, IP data, and a
position reporting service on one 200 kHz AES channel. ORT item G1 determines if
SwiftBroadband safety service is activated in the AES and, if so, what SBB channel
supports it. The primary voice channel is implemented on the air interface as circuit
switched, whereas for a second voice channel (for both air-to-ground and ground-to-
air) VoIP is used – in both cases, the voice appears as circuit switched when
delivered into the ground networks and aircraft. For both ACARS and safety voice,
the 24-bit AES ID is used as the addressing mechanism.
The detailed requirements and implementation of SwiftBroadband safety are not
described in this document. Further details are described in RTCA DO-210 which is
being produced by RTCA SC-222. For the voice (both circuit-switched and VoIP-
based) and ACARS safety service, the SDU presents
 ARINC CHARACTERISTIC 781 – Page 49

3.0 SATCOM FUNCTIONS

SwiftBroadband Services

Circuit Switched Packet Switched

3G SERVICES
INMARSAT NETWORK CAPABILITY

64kbps AMBE+2 Voice Streaming Standard

(4kbps) 8kbps
16kbps
32kbps
64kbps
128kbps
X-Stream
X-Stream Half Channel
Full Channel
APPLICATION
SERVICES

VoIP Server AGGW

INMARSAT DELIVERED
SERVICE

3.1kHz ISDN ISDN Voice Service Prioritized IP Standard ACARS

Audio UDI RDI *# Service IP Service Service
* * * *# *# #

* Non-safety service
# Safety service
*# Safety & Non-safety service

Figure 3-1 – SwiftBroadband Services

interfaces to the aircraft that are the same as for Classic Aero, and hence functions
such as the ACARS Aircraft Gateway (AAGW) and the VoIP server are contained in
the SDU. The VoIP server implements the RTP and SIP VoIP protocols to deliver
voice over the PS domain, as well as handling priority and preemption.
COMMENTARY
The IP safety service interface is being developed.
The above voice service using VoIP may also be used for the cabin. In this case,
priority and preemption is not provided, and the addressing does not use the
24-bit AES ID.
SwiftBroadband is a satellite component of the Third Generation IMT-2000/Universal
Mobile Telecommunications System (3G UMTS). SwiftBroadband is a UMTS
Release 4 network just like any other with one key difference being: SwiftBroadband
has a proprietary satellite radio interface (IAI-2) instead of the terrestrial WCDMA
radio interface. In addition, to support safety services, the SwiftBroadband ground
network contains various gateway functions (specifically, an ACARS Ground
Gateway (AGGW)).
ARINC CHARACTERISTIC 781 – Page 50

3.0 SATCOM FUNCTIONS

SwiftBroadband shares the same ground infrastructure that is used to deliver similar
services to other market segments (enterprise (also known as land portable), land
mobile and maritime). The enterprise service is known as Broadband Global Area
Network (BGAN), and this term is often used to describe the totality of the system
across all market segments. Unlike Classic Aero and Swift64 Mobile ISDN, Inmarsat
owns and operate the ground infrastructure which primarily consists of the Satellite
Access Station (SAS), the Data Communication Network (DCN), the Business
Support System (BSS), the Network Operations Center (NOC), the Satellite Control
Center (SCC), the Telemetry Tracking and Control system (TT&C – not shown in
figure below), and the Payload Control System (PCS) - not shown in Figure 3-2. The
SAS contains the satellite dishes, up down conversion, the Radio Access Network
(RAN) and the Core Network (CN). Inmarsat sells service on a wholesale basis to
Distribution Partners (DPs) who then sell service to service providers or end users.
Service providers sell service to end users.
The overall SwiftBroadband architecture is shown in Figure 3-2.

I4 Satellites
I-4 Satellites

Aircraft User Terminal Functions Inmarsat Ground Infrastructure

HPA SAS Site

function
Aircraft
Service SDU Antenna RAN
Access function RF/IF
Point DLNA
Core Network

USIM
USIM VoIP
VOIP AGGW
AGGW

USIM
Module
SDM Business
Business Network
Network Satellite
Satellite
Support
Support Operations
Operations Control
Control
System
System Center
Centre Center
Centre DCN
(BSS)
BSS (NOC)
NOC (SCC)
SCC
Inmarsat London

Ground Service IP PSTN/ISDN

Access Point Interconnect Interconnect

Figure 3-2 – Overall SwiftBroadband Architecture

 ARINC CHARACTERISTIC 781 – Page 51

3.0 SATCOM FUNCTIONS

SwiftBroadband RF bearers in the forward (to aircraft) direction are a continuous

transmission of time division multiplexed (TDM) carriers shared between a number of
users. RF bearers in the return direction (from aircraft) are based on TDMA between
a number of users.
Power efficient QPSK (Quadrature Phase Shift Keying) and bandwidth efficient 16
QAM (Quadrature Amplitude Modulation) modulation is used, together with a
number of frame burst durations. Symbol rates between 8.4 kilo symbols per second
(kSym/s) and 151.2 kSym/s are used with each symbol rate being a fraction or
multiple of 33.6 kSym/s. A variable coding rate is used with rates corresponding to 1
dB changes in C/No. In the main the bearers operate at constant power and as the
C/No varies the coding rate (and hence the user data rate) is adjusted accordingly.
The forward and return bearer types are shown in Table 3-2.
Table 3-2 – Forward and Return Bearer Types
Symbol Rate/
Forward Return
33.6 kSym/s
Modulation QPSK QAM QPSK QAM
Frame Period 80 ms 5 ms 20 ms 80 ms 5 ms 20 ms 80 ms
Shared Access Bearers
0.25 Y
0.5 Y Y
1.0 Y Y Y Y Y Y
2.0 Y Y Y Y
4.5 Y Y Y Y Y
Dedicated (High Data Rate) Bearers
2.5 Y Y Y
5.0 Y Y Y

SwiftBroadband uses three types of satellite beam: global, regional and narrow spot.
The global beam is only used in the forward direction, while the regional and narrow
beams are used in forward and return directions. User traffic is carried in the narrow
beams, while the global and regional beams are used for log on and other signaling.
Handover between beams within a satellite is supported.
The SwiftBroadband ground network supports priority and preemption for the
SwiftBroadband safety services.
3.1.2 Management of Radio Interface
3.1.2.1 RF Power
The primary objectives of the SDU RF power management algorithm are to:
• Maintain the Aircraft EIRPs for established carriers.
• Determine the availability of RF power for additional RF carriers.
• Maintain the HPA within its operating limits (e.g., to satisfy
intermodulation products requirements).
• Ensure reservation of power for on-demand transmissions, (e.g., Classic
R or T channels).
• Prioritize the allocation of available RF power to multiple carriers, with
regard to the priority of each related service.
The Aircraft EIRP is either the EIRP assigned by the ground station, or a value
stored within the SDU.
ARINC CHARACTERISTIC 781 – Page 52

3.0 SATCOM FUNCTIONS

The SDU should provide independent power adjustment for the EIRP of each RF
carrier, plus optionally, overall power adjustment (e.g., by means of the HPA).
Calculation of the RF carrier adjustment should take into account factors such as:
• Power Control commands from the ground station (dynamically variable).
• Antenna transmit gain (dynamically variable).
• DLNA and RF cable losses (potentially frequency dependent).
• HPA (internal or external) gain variations or adjustments (dynamically
variable).
Carrier 1
Aircraft EIRP

Carrier 1
Carrier 1 Carrier (n)
Adjustment
Aircraft EIRP
High Power DLNA and
Amplifier Antenna Gain
Cable Losses
(internal or external)

Carrier (n)
Carrier (n)
Adjustment

Figure 3-3 – RF Carrier Adjustment

3.1.2.2 Antenna
The SDU receives aircraft navigation data (position and attitude) and based on the
satellite location, computes the required antenna elevation and azimuth. The
azimuth and elevation data is then transmitted to the antenna.
3.1.2.3 SwiftBroadband Transmit Burst timing
The SwiftBroadband system requires that transmit bursts from AES are tightly
synchronized in time and that they are received at the ground within ±120 µs of the
expected arrival time. This requires that the AES synchronizes its transmit timing
based on the aircraft position, the received signal and knowledge of the satellite
position which is broadcast by the ground.
The normal mode of operation is that the AES uses GPS derived 3D position and
has a burst timing accuracy of 10 µs (include timing uncertainty in both receive and
transmit chain).
A special timing mode may be used by AES where GPS derived position data is not
available, but a position source with a slowly varying error is available
(e.g., from an Inertial Reference System (IRS)). In this mode, transmit timing is
controlled by a closed loop control system involving the (Radio Access Network)
RAN. This control system requires that the underlying 3D navigation data (1) has an
error characteristic similar to that of an Inertial Reference System (error of no more
than 2 nautical miles per hour and is slowly varying), (2) is updated frequently e.g. at
least once per second (3) has adequate relative accuracy and resolution and (4) is
compatible with WGS-84.
It is recommended that if GPS is fitted to an aircraft, then GPS based position data is
provided to the SDU.
 ARINC CHARACTERISTIC 781 – Page 53

3.0 SATCOM FUNCTIONS

3.1.2.4 GNSS Interference Prevention

3.1.2.4.1 Background
The AES operates in a frequency band such that combinations of transmit frequency
assignments could result in intermodulation products falling into the GNSS band. If
these intermodulation products are at a sufficient power level, they could interfere
with a GNSS receiver on the same or nearby aircraft.
The mitigations against the above scenarios are:
1. The GNSS receiver is designed to operate in the interference environment as
defined in the ICAO GNSS SARPs, RTCA GNSS MOPS, and ARINC
Characteristic 743A.
2. Isolation is required on the aircraft between the satcom and GNSS antennas.
The required isolation is defined in Sections 2.3.2.6.12 and 2.3.3.6.11.
3. The SDU, and external HPA if fitted, are specified to have low levels of
intermodulation products.
4. The DLNA provides filtering against such intermodulation products.
5. The satcom antenna is specified to have low levels of passive
intermodulation products in the GNSS band.
6. The Inmarsat channel assignments for certain services and combinations of
services are frequency managed to ensure that 3rd and 5th order
intermodulation products do not fall into the GNSS band.
7. The AES rejects combinations of frequency assignments that could result in
harmful interference to the GNSS receiver. Such frequency checks are
needed in case of erroneous ground station channel assignments.
The combination of items 1 through 5 above ensures that the 7th and higher order
intermodulation products are at a sufficiently low level to not cause harmful
interference to the GNSS receiver. Items 6 and 7 ensure that 3rd and 5th order
intermodulation products are not in the GNSS band.
3.1.2.4.2 Frequency Allocations by Ground Stations
Classic Aero channel frequencies operate in the band 1545 to 1555 MHz and 1646.5
to 1656.5 MHz as allocated in ITU Radio Regulations for AMS(R)S services. Hence
any combination of R, T, and C channels do not produce 3rd and 5th order
intermodulation products at frequencies below 1616 MHz.
SwiftBroadband channels are allocated any frequency in the assigned band.
Swift64 channels are allocated in two categories. The category is stored in the
ground station’s database and is entered into the database during the terminal
registration process:
• Category A allocations and from 1 Jan 2009 Cat B allocations may be at any
frequency in the band 1530 to 1559 MHz and 1631.5 to 1660.5 MHz, such
that any combination of Swift64, R-, T-, and C-channels do not produce 3rd
and 5th order intermodulation products at frequencies below 1585 MHz.
• Category B allocations until 1 Jan 2009 may be at any frequency in the band
1530 to 1559 MHz, and 1631.5 to 1660.5 MHz, such that any combination of
Swift64, R-, T-, and C-channels do not produce 3rd and 5th order
intermodulation products at frequencies below 1610 MHz.
ARINC CHARACTERISTIC 781 – Page 54

3.0 SATCOM FUNCTIONS

3.1.2.4.3 GNSS Frequency Management in the AES

ORT item E5 or the configuration pins determines if the GNSS frequency
management function is activated in the SDU and if so the value of f limit .
The following guidance is provided so that the airframer, installer, or aircraft operator
can determine how to set the ORT item or configuration pin.
GNSS frequency management in the AES is only required if the 3rd and 5th order
intermodulation products generated by the AES (as received at the GNSS receiver)
are greater than the GNSS receiver susceptibility (plus safety margins).
The intermodulation products received at the GNSS receiver will be the sum (in dB)
of the intermodulation products generated in the SDU (or external HPA), the filtering
in the DLNA and the RF isolation between the satcom antenna and GNSS antenna.
Hence reducing the SDU (or external HPA) intermodulation products, or increasing
the DLNA rejection or increasing the RF antenna isolation could remove the
necessity of GNSS frequency management checks in the SDU.
Single channel systems (e.g., one channel Swift64 only or one channel
SwiftBroadband only) do not produce intermodulation products and hence frequency
checks are not required for single channel systems.
Since SwiftBroadband channels are allocated anywhere in the band, installations
with SwiftBroadband must have adequate RF performance and should not require
any GNSS frequency checks. Adequate RF performance can be achieved with
either a Type F DLNA or improved HPA intermodulation products or increasing the
RF isolation between the satcom and GNSS antennas. Note that a Type D DLNA
does not support the whole frequency band and hence is not suitable for
SwiftBroadband.
For the recommended RF isolation between the GNSS and satcom antennas, and
for GPS only installations:
1. If a Type D or Type F DLNA is fitted then the GNSS frequency check is
not required and should be deactivated.
2. For other DLNAs (e.g., Type A or Modified Type A), the GNSS frequency
check is required (and f limit should be set to 1585 MHz) if the HPA only
meets the ARINC 741/ARINC 761/ARINC 781 intermodulation
requirements.
3. For other DLNAs (e.g., Type A or Modified Type A), and with an HPA with
improved intermodulation performance, then the GNSS frequency check
is not required and should be deactivated. Please consult the HPA
manufacturer on whether it’s HPA has adequate performance.
For installations with GLONASS, consult the manufacturers of the avionics for
guidance.
3.1.2.4.4 Recommended Frequency Check Algorithm In SDU
1. If no transmit channel is presently assigned, a new channel assignment is
to be processed normally.
2. If one or more channels are already assigned, the SDU determines the
highest and lowest frequency assignments of the existing and the “to be
assigned” channels.
If 3F L - 2FH > f limit then the new frequency assignment is accepted by the SDU.
 ARINC CHARACTERISTIC 781 – Page 55

3.0 SATCOM FUNCTIONS

If 3F L - 2FH ≤ f limit then the SDU must not transmit on either the newly assigned
frequency or a previously assigned frequency. In the latter case, the SDU must
ensure that the channels remaining satisfy 3F L - 2F H > f limit . Note that no recovery
mechanism is specified. F H and F L are the highest and lowest frequency
assignments, respectively.
f limit is 1605 MHz when GLONASS is fitted to the aircraft and 1585 MHz when
GLONASS is not fitted to the aircraft.
The need for a frequency check algorithm and the value of f limit is determined by ORT
settings or the System Configuration pins (see Section 3.2.2.4.3).
3.1.2.5 Mapping User Interfaces to Radio Interfaces
The SDU should include a function to map user interfaces to Inmarsat Services.
The potential mapping of user interfaces to compatible Inmarsat Services is outlined
in Table 3-3. This is a superset of interface capabilities and a specific SDU may have
only a subset of these.
Table 3-3 – Potential Mapping of User Interfaces to Compatible Inmarsat Services
Inmarsat Service SwiftBroadband Swift64 Classic Aero
SBB SBB
SBB SBB M-ISDN M-ISDN Classic PS
PS PS Classic CS
CS CS CS CS Data
Data Data MPDS Voice
Data Voice Data Voice (P-/R-/T-
Streaming Background (C-Channel)
User Interfaces Channel)
Class Class
Non-ATC 4-wire Analog +
Y3 Y1, 3 Y5, 3 Y2, 3
Cockpit Voice discretes
ATC Cockpit 4-wire Analog +
Y3 Y1, 3 Y5, 3 Y2, 3
Voice discretes
2-wire Analog
Y F1 F5 Y Y
POTS/SLIC
Cabin Voice
CEPT-E1 Y F1 F5 Y Y
ISDN Y Y Y
ARINC 429 3
Y Y2, 3
ACARS
Non-ATC ARINC 429
Y3
Cockpit Data Data-3
ARINC 664/
Y Y Y Y Y F
Ethernet
ARINC 429
Y3 Y2, 3
ACARS
ATC Cockpit ARINC 429
Data Data-3
ARINC 664/
F F F F
Ethernet
CEPT-E1 Y F F Y F Y Y
Cabin Data ISDN Y Y
(incl. Fax,
Modem & Ethernet Y Y4 Y4 Y Y
Packet Data) 2-wire Analog
Y Y Y
POTS/SLIC
ARINC CHARACTERISTIC 781 – Page 56

3.0 SATCOM FUNCTIONS

Notes:
“Y” indicates that a particular service can be supported via a particular
user interface.
“F” indicates potential “Future Support” pending definition or approval.
1. Requires Voice over IP (VoIP) conversion within the SDU.
2. Expected combination for cockpit Classic Aero system.
3. Expected combination for cockpit SBB and Classic Aero
system.
4. Expected combination for (digital) cabin voice (e.g., Global
System for Mobiles (GSM)) and data (wired or Wi-Fi).
5. For voice signaling.
3.1.2.6 Selection of Inmarsat Services, Satellites, and Ground Stations
The SDU should include a function to (1) select Inmarsat services, (2) select the
satellites and (3) select the ground stations. This function should also manage
handovers between satellites and ground stations.
This function should take into account priority, precedence and preference (see
Section 3.5) for the following items:
• Service type: Classic, Swift64, SwiftBroadband
• Service sub-type:
o For Classic Aero: Aero H, Aero H+, Aero I, Aero L
o For Swift64: M-ISDN, MPDS
o For SwiftBroadband: Packet-switched, ISDN, other circuit-switched
o Satellite beam: Global, I-3 spot, I-4 regional spot, I-4 narrow spot
• Service provider for Classic and Swift64 by choosing the appropriate
GES/LES
• Application: Voice, fax, PC modem, ISDN audio, packet data
• Application/service variants:
o Voice:
• Classic: 9.6 kbps Aero H BTRL, 4.8 kbps Aero H+/I AMBE
• SwiftBroadband: 64 kbps ISDN, 4 kbps AMBE+2, VoIP
o Fax:
• Classic: Group 3 TIF, Group 3 DIU
• Swift64: Group 3, Group 4
o PC modem data: Classic: TIF, DIU
o Packet data:
• Classic: 600 bps, 1200 bps, 10,500 bps
• SwiftBroadband class: Conversation (currently not supported),
Streaming, Interactive (currently not supported), Background
o ISDN Multilink/Bonding: 1B, 2B, 3B, 4B, 1B & 3B, 2B & 2B
• Physical interface: Ethernet 1-10, ISDN 1-2, POTS 1-2, Cabin CEPT-E1
• Duration (time since establishment) of circuit-mode call or packet-mode
session
 ARINC CHARACTERISTIC 781 – Page 57

3.0 SATCOM FUNCTIONS

• Satellite type in use: I-3, I-4, Alphasat, MTSAT

• Ocean region location: AOR-W, AOR-E, IOR, POR, MTSAT
• Called terminal Id
• IP address
A way to implement such NS/PC preferences may be to use ORT parameters.
3.2 User Interfaces
3.2.1 Pilot System Interfaces for Voice Communication
3.2.1.1 Introduction
The design of the installation (including equipment) for satellite voice services should
consist of four major components to satisfy flight deck voice requirements.
Additionally, special consideration has been made to accommodate FAA AC 20-
150: Satellite Voice Equipment as a Means for Air Traffic Services. The four
components are:
• Call Control
• Call Annunciation
• Call Priority
• Call Routing
Satcom voice operations use SAT Phone (Sections 3.2.1.6 and 3.2.1.7). These
sections describe Satellite communications by way of a telephony service to AOC
and ATS. The SDU should provide two channels of audio for pilot use plus
appropriate control/signaling. Both audio channels (1 and 2) should be wired to the
flight crew audio management system. Two types of audio services are defined in
the following sections:
• SAT Phone using Inmarsat Aero H/H+/I services
• SAT Phone using Inmarsat SwiftBroadband services
The audio output levels provided should be consistent with those provided by VHF
radio services such that minimal level adjustment is required by the flight crew (see
Section 3.2.1.2.3).
3.2.1.2 Call Control
The call control components include interfaces between the satcom system, MCDU,
ACP and AMS. The MCDU provides the capability to place, receive, change priority,
and access contact numbers. The ACP provides the capability to select the channel
MIC and CALL controls. The AMS provides the capability to tie in the two cockpit
channels to the flight deck audio.
3.2.1.2.1 MCDU
ARINC 739/739A-compatible MCDUs or satcom control/display units (SCDUs) are
used for functions such as selection of the called party phone number. The menu
layouts as displayed on the MCDU are based on unique Human-Machine Interface
(HMI) requirements from different airframe manufacturers.
COMMENTARY
It is suggested that each equipment supplier obtain the
appropriate controlling specification from airframe manufacturers.
ARINC CHARACTERISTIC 781 – Page 58

3.0 SATCOM FUNCTIONS

Specific menus are defined using the diagram below, whereby each airframe
manufacturer identifies which pages are bound by the unique HMI requirements for
fleet commonality and certification. All other menus may be described by the
individual avionics equipment manufacturers.

Figure 3-4 – Menus Expected to Have Airframe Manufacturer-specific Definitions

3.2.1.2.2 ACP
The Audio Control Panel provides a “CALL” light indication when a ground-to-air
(GTA) call is detected or an air-to-ground (ATG) call is in progress. The “MIC” light
indication provides the indication to identify which channel the flight crew is
communicating over. In some aircraft, pressing the “MIC” on light will answer and
terminate the voice call.
The discrete signaling between the SDU and ACP consists of:
• Cockpit Voice mic-on Inputs #1 and #2 (i.e., one per audio channel).
These inputs may be driven by latched mic-on or press-to-talk (PTT)
signals (refer to ORT item D7).
• Cockpit Voice Call Light Output #1 and #2 (i.e., one per audio channel).
• Call Place/End Discrete Inputs #1 and #2 (i.e., one per audio channel).
• Cockpit Voice Chime Signal Contacts 1 and 2 (shared between audio
channels).
 ARINC CHARACTERISTIC 781 – Page 59

3.0 SATCOM FUNCTIONS

• Cockpit Voice Go Ahead Chime Reset (an optional input shared between
audio channels for silencing a multi-stroke chime without answering the
annunciated call).
The electrical definition of the above (e.g., voltage, current and impedance) is
defined in Attachment 1-4.
The Cockpit Voice mic-on inputs can operate in one of two modes as defined by
ORT item D7 defined in Section 3.4.2.1.3. These modes are “Latched ACP satcom
mic switch” and “Switched PTT.”
COMMENTARY
The use of discrete signaling is optional with the Williamsburg SDU
controller interface (WSCI) described in Section 3.2.1.9 (WSCI is
capable of handling all signaling on the ARINC Specification 429
signaling interface).
The use of ARINC Specification 429 signaling is to support more
complex text or graphical user interaction (such as phone number
selection) via ARINC 739 and 739A MCDUs/SCDUs or ARINC 741
Williamsburg SDU controllers (WSCs). The latter use the
Williamsburg SDU controller interface (WSCI) as described in
Section 3.2.1.9.
3.2.1.2.3 AMS
The Audio Management System (AMS) is responsible for connecting the flight deck
audio to each of the satcom voice channels.
The audio output from the SDU should:
1. Drive an analog balanced 600 ohm circuit at a nominal output level of
10mW RMS for a digital voice level of -22 dBm0.
2. Be adjustable over at least the range 5 mW to 40 mW (-3 dB to +6 dB),
via the ORT, for a digital voice level of -22 dBm0.
3. Be capable of driving an unbalanced load.
The input is a “carbon microphone” interface, which is the same as that of the VHF
radio (see ARINC Characteristic 716, Section 3.7.4).
In order to assess headset audio levels during installation, the SDU should be able
to, on demand via an MCDU or alternative HMI, generate a 1 kHz tone, at a level of
at least between 5 mW to 40 mW, determined by the ORT (Cockpit Headset Audio
Gain parameter).
The SDU should provide sidetone at a level dictated by the ORT. The maximum
level should match that of the incoming audio and there should be a number of back-
off levels, at multiples of 3 dB. There should also be a “Sidetone Off”
setting to accommodate installations where sidetone is provided by the AMS.
COMMENTARY
Previous definitions of audio output level have referred to a
“nominal 10 mW RMS” level. This is open to interpretation and
has been clarified. “Nominal” operating level is the level applicable
to typical operating conditions throughout the system (i.e.,
comfortable speech level and all controls in their usual operating
ARINC CHARACTERISTIC 781 – Page 60

3.0 SATCOM FUNCTIONS

positions). The digital voice level is the level within the terrestrial
networks. Normalization of the SDU audio output levels with that
from other services should be set via the ORT.
It should be noted that in order to present a sidetone level
matching that of the incoming audio, significant amplification of the
low-level carbon microphone signal is required.
A 1 kHz sine wave can be used to approximate the digital voice
referenced in the text above.
The following table provides a set of A-law samples, sampling at 8
kHz, which represents a 1 kHz sine wave with a power level of
-22 dBm0 into an A-law Pulse Code Modulation (PCM) decoder.
A-law Coded A-law Coded
Binary Hex
1001 0011 93
1000 1111 8F
1000 1111 8F
1001 0011 93
0001 0011 13
0000 1111 0F
0000 1111 0F
0001 0011 13

3.2.1.3 Call Annunciation

The satcom system should provide the ability for any aircraft to provide aural and
visual indications to the flight crew during GTA and ATG satcom calls. Aircraft
functions such as EICAS, SELCAL & chimes should be provided for. Call status
information should be provided to the EICAS/ECAM/EDU or equivalent as described
in ARINC 741, Part 2, Section 4.7.3.1, in label 270 content.
• Chime/SELCAL: Occurs whenever a GTA call is detected or when a flight
deck call has been released from the camp on queue or when an ATG
call is connected through to the ground.
• EICAS: For some airframe manufacturers, a Flight Deck Effect (FDE)
“Comm” message should be displayed for the duration of the call.
• For SwiftBroadband safety, the satcom system shall additionally provide
caller line identification to the pilot.
3.2.1.4 Call Priority
The satcom system should provide the means to change the priority prior to making
the call. Four levels of priority (defined as 1 through 4 or Emergency, High, Low,
Public, respectively) should be made available for the flight crew to select
(programmable via ORT item F3). The lowest priority means that the flight crew call
is being placed at the same level of contention as cabin calls from aircraft in the
same satellite beams. Selection of priorities above 4 or Public will allow for the flight
deck call to preempt existing calls in the space segment that have a lower priority if
satellite or AES or GES resource limits have been reached.
Preemption is also achieved within the aircraft due to a facility for the flight crew to
terminate a cabin call or queue the flight deck call as desired for a given duration.
 ARINC CHARACTERISTIC 781 – Page 61

3.0 SATCOM FUNCTIONS

This queuing facility is defined as camp-on. This action is achieved either manually
or automatically.
3.2.1.5 Call Routing
The satcom system, by way of ORT item D4, provides the means to prevent ground-
to-air Priority 4 or Public calls being routed to the cockpit. This advice is being made
due to concerns about safety and access to the flight deck.
The satcom system, by way of ORT item D3, provides the means to route a ground-
to-air call to either channel 1 or channel 2 reserved for the cockpit when the two
channels are not already in use.
3.2.1.6 SAT Phone Using Classic Aero Services
3.2.1.6.1 General
This mode of operations has been previously defined as the traditional telephony
service for cockpit voice. Currently, satellite telephony utilizes Inmarsat Aero H/H+/I
services over the C-Channel protocol using either the 9.6 kbps or 4.8 kbps codecs.
The definition below is based on ARINC Characteristic 741, but various
options/functions from ARINC Characteristic 741 (Part 2, Section 4.4.4.3.2, and
Attachment 2F-42) are not described in ARINC Characteristic 781. These “not
described” options/functions are listed below. This does not preclude an avionics
manufacturer to implement them in the SDU:
• Multi-stroke chime
• Flashing lights
• Call via ACP to a number stored in ATC call register
• Generation of in-band tones and/or speech messages
• Call light activation upon call initiation
The SDU implementation for normal operation is described below as a state
machine, and this state machine is shown in Attachment 3. The SDU implements
procedures for interworking between the Cockpit “Lamp/Chime” and “Cockpit Voice
mic-on Input” control lines and the satellite network protocol for the provision of
cockpit voice services.
COMMENTARY
Although the AES presents as much as possible the same man-
machine interface as for HF and VHF radio, it nonetheless
operates as an addressed, point-to-point telephony service.
Call progress and completion/failure annunciations should be displayed on the
SCDU.
3.2.1.6.2 Air-to-Ground Call
Call Initiation State
A call is initiated via the SCDU or via the Audio Control Panel (Cockpit Voice mic-on
Discrete in ground state) after selection of the destination on the SCDU by means of
user menus (Section 3.2.1.4). If two channels are available, the request should
include the desired channel number.
ARINC CHARACTERISTIC 781 – Page 62

3.0 SATCOM FUNCTIONS

Ground-to-Air Connected State

Upon receipt of the Call Attempt Result SU (S6D) or Connect SU (S6B) from the
GES (whichever occurs first, but not both) the lamp is set steady and the chime is
sounded once. At this point, ground- to-air voice is connected but air-to-ground
voice is not connected.
Connected State
The SDU enters the connected state and voice is connected in both ground-to-air
and air-to-ground when any of the following signals are received by the SDU:
1. An “answer call” line select key switch is activated on the SCDU. (Case
(c) is required for aircraft having no PTT or mic-on switch available for the
SDU.)
2. The Cockpit Voice mic-on Input (channel #1 or #2, as appropriate) makes
a transition (the first one after the Lamp/Chime call annunciation) from an
open circuit to a ground closure, provided that ORT item D7 (Section
3.4.2.1.3) is set to the “Switched PTT” option.
3. The Cockpit Voice mic-on Input (channel #1 or #2, as appropriate) has
continuity to ground, provided ORT item D7 is set to the “Latched ACP
satcom mic switch” option.
Air Initiated Clear
The call is cleared and the SDU transitions to the idle state when any of the following
signals are received by the SDU:
a. An “End Call” button selected on the SCDU, provided that ORT item D7,
is set to the “Switched PTT” option.
b. The Cockpit Voice mic-on Input (channel #1 or #2, as appropriate) is
open circuit, provided that ORT item D7 is set to the “Latched ACP
satcom mic switch” option.
c. Activating the Place/End Call discrete (channel #1 or #2, as appropriate).
The chime is not used in an air initiated clear. The lamp is extinguished upon call
termination.
Ground Initiated Clear
A channel Release signal unit from the satellite channel causes the SDU to
disconnect the voice channel and transition to the idle state.
The chime is not used in a ground initiated clear. The lamp is extinguished upon call
termination.
General
If the call cannot be connected, the lamp and chime are activated in the normal
manner, and the SCDU/WSC displays a brief description of the reason; a manually
selected option could be provided to automatically redial such a call until the
connection is made. If all available AES resources for making the call are "busy,” the
call may automatically enter into a "camp-on" state (with the option of manually
preempting or canceling the call), or it may simply immediately and automatically
preempt an appropriate existing call.
 ARINC CHARACTERISTIC 781 – Page 63

3.0 SATCOM FUNCTIONS

3.2.1.6.3 Ground-to-Air Call

Ground-to-Air calls are handled largely by the ACP, with little involvement of the
SCDU/WSC. However, the SDU may display call information on the SCDU/WSC;
e.g., priority of the incoming call.
Incoming Call State
Receipt of the Call Announcement signal unit triggers the interworking process at the
SDU. The SDU routes the call according to priority. Priority 1, 2, and 3 calls are
routed to the cockpit.
Priority 4 calls are either rejected or routed to the cockpit AMS (using the preferred
channel if available), analog cabin telephones, or digital cabin telephones, according
to ORT item D4 (see Section 3.4.2.1.3).
The lamp is set steady and the chime is sounded once as soon as the satellite voice
channel has been assigned and its continuity verified.
Note: Call priorities and associated Q precedence levels are
defined in ARINC Characteristic 741, Part 2, Attachment
2F-42.
If available resources for a new ground-initiated call are all busy and the new call
has a higher priority than an existing call, the new call is accommodated by
preempting the lowest priority existing call. If the new call has the same or lower
priority than all existing calls, the SDU indicates “busy” to the GES.
Connected State
The conditions to transition to the connected state, and the behavior of the lights,
chime and voice circuits are the same as for an air-to-ground call.
Air and Ground Initiated Clearing
The conditions to clear the call and hence transition to the idle state, and the
behavior of the lights, chime and voice circuits are the same as for an air-to-ground
call.
3.2.1.7 SAT Phone using SwiftBroadband
SwiftBroadband offers three types of voice service:
1. The 4 kbps AMBE+2 codec for SwiftBroadband services running as non-
safety. In this case, there is no priority and preemption capability, and
ground-to-air call using the ICAO 24-bit address is not supported. A
number of initial certifications of this functionality were made to provide
AOC voice.
2. The 4 kbps AMBE+2 codec for SwiftBroadband services running as
safety using the circuit switched air interface. Priority and preemption is
supported, and ground-to-air call addressing uses the ICAO 24-bit
address.
3. A G729 codec for SwiftBroadband services running as safety using the
packet switched air interface. Priority and preemption is supported, and
ground-to-air call addressing uses the ICAO 24-bit address. In this case,
the SDU includes a VoIP server. On the ground side, the calls are
converted from VoIP to circuit switched and are delivered into the
ARINC CHARACTERISTIC 781 – Page 64

3.0 SATCOM FUNCTIONS

terrestrial networks as circuit switched. The SDU only uses this voice
service when a second cockpit voice channel is required.
The pilot input method for placing all three types of voice calls on SAT Phone from
the MCDU should be no different to that when placing an Aero H+/H/I voice call.
3.2.1.8 SAT Radio
Note: At the time of this writing, SAT Radio has not been
implemented within SwiftBroadband due to low customer
demand. The text below has been retained for reference
only.
This mode of operation is a newly defined concept by which satcom voice
communications operates in a similar manner to a VHF Radio effectively a PTT radio
service over a satellite link. This service is referred to as the “Netted Voice” feature
described in the Inmarsat BGAN SDM. Candidates for the use of this service could
be AOC Voice (to be used as private company voice use, airline
oceanic/international fleet communications etc.), Military command operations
(Air/Ground/Sea) and possible ATS use. The use of SAT Radio can also be
restricted to private and secured user groups. This service is not expected to be
used for communications between aircraft since there is the issue of a double
satellite latency hop making communications difficult to remain coherent.
The underlying technology is a combination of IP Multicast services for the forward
link and a high priority VoIP service for the return link. Actual implementation of the
SAT Radio service is still being defined with studies to determine the best tradeoff
between the most efficient pilot HMI requirements and satellite resource usage.
Some of the candidates for return link protocols could be Virtual Circuit, Packet
Switched and Dedicated Contention VoIP modes. Among the three modes are
aspects of considerations for voice latencies, ability to preempt pilots, thus
eliminating “Stuck MIC” situations. Other enhancements include minimization of
bandwidth requirements, traffic loading, introduction of emergency pilot interrupts
and preventing pilot to pilot “step-on” situations.
Figure 3-5 is a concept diagram of how the system could be implemented.

Figure 3-5 – Baseline Operational Concept for SAT Radio

 ARINC CHARACTERISTIC 781 – Page 65

3.0 SATCOM FUNCTIONS

For air-to-ground communications, one method of operation would be for a pilot to

“tune” (via the SCDU/WSC) into the subscriber group that he/she is interested in (for
possible ATS communications it could be the current FIR they are transiting like
Shanwick-Center, in an AOC environment, their company’s Maintenance Watch
channel or for Military/Government use, their specific coded operations mission
group). Once this subscriber group is selected and authentication is granted, any
voice traffic is multicast to the cockpit. When the pilot wishes to speak, they could
select a command on the SCDU/WSC that automatically assigns a forward link
based on who else is in the queue requesting to talk. If no other aircraft is actively
engaged in a conversation, then the pilot would get an indication to start transmitting,
otherwise their request will be placed in a queue (controlled by the ground
subscriber group) until the existing radio exchange is completed. This will prevent
pilot to pilot step-on problems encountered in VHF radio communications. This
method also allows the forward link satellite channel resources to be free and not
used if there is no active transmission. Once radio conversation is completed, the
person coordinating the ground subscriber group releases the aircraft and the next
aircraft in the queue is automatically given the signal to start transmitting. For
ground-to-air operations, the ground subscriber operator would broadcast any
information (such as turbulence reports) and only aircraft that are already subscribed
to that group will receive that information. The subscriber operator would have a list
showing which aircraft are currently listening into that group. Since an aircraft usually
has two cockpit voice channels, it is conceivable to have one channel listening into
the AOC communication and the other channel listening into the ATS channel to aid
in situational awareness.
As mentioned previously, the above example offers just one method or concept of
operation. A full study is outside the scope of this standard.
3.2.1.9 Williamsburg SDU Controller
Pilot interaction with the satcom system is typically performed via one or more
ARINC 739-compliant MCDUs/SCDUs. For aircraft without MCDUs/SCDUs, an
alternative means of control/display is the Williamsburg SDU Controller Interface
(WSCI), which may be used between the SDU and cockpit systems such as radio
management panels or primary display systems with keypads and cursor control
devices. The same physical ARINC Specification 429 ports are used on the SDU for
either MCDUs/SCDUs or WSCs, with SDU configuration pin programming defined in
Attachment 1-4A or ORT items B11, B12, B13, and B14 determining which interface
standard pertains for a given installation. The WSCI standard permits the human
factors of the pilot interface (text, icons, colors, etc.) and the phone number data
base to be completely independent from the SDU design, as it is based on the
transfer of system control/status primitives (messages) using the ARINC
Specification 429, Part 3, Version 1 (Williamsburg) file transfer protocol. The
standard message suite may be expanded as necessary to meet new requirements.
Reference ARINC Characteristic 741, Part 1, Attachment 2F-42.1 for details of this
interface.
3.2.2 Cockpit ACARS Data
An ARINC 429 data bus provides communications between the satcom system and
the ACARS MU/CMU system. ACARS data can be transmitted over either Classic
Aero or SwiftBroadband.
ARINC CHARACTERISTIC 781 – Page 66

3.0 SATCOM FUNCTIONS

For the description of the operation between the SDU and ACARS MU/CMU refer to
ARINC Characteristic 741, Part 2, with the exception of the ARINC 429 Bus speed
selection. This parameter is set as ORT item B9 (Section 3.4.2.1.3) rather than
configuration pin strapping.
3.2.3 ISDN Interface
The SDU should accommodate two BRI interfaces for use of Swift64 and
SwiftBroadband circuit-switched services.
The signaling protocols used on the interfaces are ITU Q.921 and ITU Q.931 for
layer 2 and 3 of the signaling link, respectively. The SDU acts as the NT device.
Both (the aircraft user and the ground user) can terminate an established call by
using the signaling protocols on the ITU Q.921 and ITU Q.931 for layers 2 and 3 of
the signaling link.
For an M-ISDN call initiated from one of the two ISDN BRIs interfaces, when
appropriate, a Q.850 error code should be generated by the SDU.
3.2.4 Ethernet
This section summarizes the way Ethernet ports can be used for SwiftBroadband
and Swift64 services. A fully detailed interface description is available in Attachment
5. Other uses of the Ethernet ports (e.g., CFDS) may be described in future
supplements (see Sections 3.6.1 and 3.6.2)
COMMENTARY
The Ethernet interface defined in this section and in Attachment
5 was designed for non-safety applications. It has not yet been
determined if this interface definition is suitable for the SBB
Safety Priority IP service.
COMMENTARY
It is expected that this interface will be used by not only ARINC 781
SDUs but also non-ARINC 781 form factor LRUs that support
SwiftBroadband.
3.2.4.1 Purpose and Requirements of the Interface
Depending on the functions supported, the SDU should interface directly to
onboard communication networks using its Ethernet ports to access the following
telecommunication services:
• SwiftBroadband Circuit Switched service.
• SwiftBroadband Packet Switched service.
• Swift64 Mobile ISDN service.
• Swift64 MPDS service.
The interface can also use be used to retrieve the status of the SDU and
communication services/links.
The following requirements specify the proposed use of this interface:
• The interface needs to be scalable/extendable to architectures that
include:
 ARINC CHARACTERISTIC 781 – Page 67

3.0 SATCOM FUNCTIONS

o Commercial of the shelf (COTS) network client devices (Terminal

Equipment (TE)) such as a Laptop.
o Direct connection to the SDU for basic functionality.
o Aeronautical Servers/Routers that host applications and services.
o Services and connectivity to TEs that can run custom software to
control one or many SDUs providing full functionality.
o Aircraft that host one or many SDUs.
o SDUs that host one or many SwiftBroadband channels.
• A SwiftBroadband channel may support up to 11 simultaneous packet
data services (PDP Contexts) simultaneously:
o Each PDP Context may be configured to operate with a specific traffic
class (Streaming and Background are initially supported).
o Quality of Service (QoS) properties for Streaming class PDP Contexts
may be requested by an external device. QoS includes the
guaranteed bit rates in the forward (to aircraft) and return (from
aircraft) directions.
o The QoS properties of each PDP context may be modified after the
PDP Context has been established.
• The interface should have adequate security for the intended applications
and aircraft environment.
• The interface should be suitable for Air Transport, Business and
Government aircraft.
Based on the above, the purpose of this interface can be summarized as:
• Set up, control, & transfer of packet data using SwiftBroadband packet
data service. With control equating to set up, modify & terminate primary
contexts and set-up, modify & terminate secondary contexts.
• Access the SwiftBroadband Circuit Switched service
• Obtain operational status of AES and communications link providing the
above service.
• Be used (backwards compatible) for set up, termination & transfer of
packet data using Swift64 (packet & circuit switched services).
• Be suitable for use with communication networks containing unmodified
COTS protocol stacks.
3.2.4.2 Interface Components
The proposed interface consists of:
1. Using PPPoE to set up SwiftBroadband primary contexts and Swift64
packet data (packet switched services) by using pre-defined Access
Concentrator (AC) service names in PPPoE frames (configurable through
the SDU ORT section C to define the type of service and associated QoS
when applicable).
and/or
2. Using PPPoE to set up SwiftBroadband primary contexts using
3G/Inmarsat AT commands for AC Service names in PPPoE frames.
ARINC CHARACTERISTIC 781 – Page 68

3.0 SATCOM FUNCTIONS

and (if there is a need to set-up secondary PDP context and modify established one)
3. An out of band control function using 3G/Inmarsat AT commands over
Telnet/TCPIP/Ethernet. Out of band means independent of the PPPoE
session carrying the user data.
and/or
4. Providing an IP router interface with Network/Port address translation to
route traffic to a SwiftBroadband primary context that is “always-on”
subject to service availability. This is called “Routed Interface.”
and (if required)
5. Using PPPoE to set up Swift64 and SwiftBroadband Circuit Switched UDI
data calls by using service names in PPPoE frames.
and (if required)
6. SNMP to retrieve SDU operational status of the AES and communication
links.
3.2.4.3 Interface Fundamentals
Based on the above, the interface fundamentals are:
• For the “Routed Interface”:
o Router functionality is limited to:
 DHCP and NAT/PAT services to the TE.
o Functionality is provided as a Primary PDP Background context.
o When the SDU is successfully attached to the core network, it should
activate the context associated to the “Routed Interface” and continue
to re-connect in instances where service is lost due to aircraft
maneuvering, etc.
• For PPPoE:
o Each primary context is supported in a separate PPPoE session, and
is allocated an IP address by either the Inmarsat ground network or
the DP’s network. Secondary context traffic is supported via the
PPPoE session of the parent primary and shares the parent’s IP
address.
Note: SwiftBroadband supports up to 11 total contexts per
channel (i.e., sum of the primary and secondary contexts.)
o Error codes should be generated in the PPPoE error tags.
o If primary PDP context is cleared, then SDU should initiate a PPPoE
Active Discovery Termination (PADT).
• For the out of band control function:
o Secondary contexts can only be set up (and controlled) via the out of
band control function.
o Traffic Flow Templates (TFTs) (based on 3G plus Inmarsat
extensions) are a mechanism to specify the packet filter parameters
between parent primary and its secondary PDP contexts.
o Each control function equates to a single telnet session. There is no
mandated pairing between PPPoE sessions/PDP contexts and control
 ARINC CHARACTERISTIC 781 – Page 69

3.0 SATCOM FUNCTIONS

functions. The method for a control function to address a particular

PDP context is a special AT command within a Telnet session.
o The SDUs IP address can either be stored in the ORT (item C11) or
can be dynamically assigned using DHCP.
o The interface supports one to many and many to one (servers to
SwiftBroadband channels) on one (or more) Ethernet interface.
3.2.4.4 Multiple Ethernet Interfaces
Further work is required to define how multiple Ethernet interfaces to an SDU
operate on an aircraft in terms of how/if they can access a single RF channel. A key
driver is security considerations.
3.2.5 CEPT-E1
For cabin communications services, the Cabin Communications System (CCS),
described in ARINC Characteristic 746, is interconnected to the SDU by means of a
CEPT E1 digital link. The E1 link is capable of supporting 30 PCM channels.
The SDU access protocol for call control of circuit-mode services to the CCS is the
ITU-T Q.931/932 network layer protocol. The detailed implementation of this protocol
for the SDU as well as the CCS is defined in ARINC Characteristic 746,
Attachment 11.
3.2.6 POTS
The SDU should provide two 2-wire interfaces for connection to a Plain Old
Telephone Service (POTS) standard telephone handset. A POTS interface is also
known as a Subscriber Line Interface Circuit (SLIC). Each interface should support a
Ringer Equivalent Number (REN) of 1. Further guidance on this interface can be
found in international telecommunications standards such as the various pertinent
ITU-T Recommendations and in the U.S. Code of Federal Regulations (CFR) Title
47 (Telecommunication) Volume 3, Chapter 1 (Federal Communications
Commission (FCC)) Part 68 (Connection of Terminal Equipment to the Telephone
Network).
3.3 Software Data Loader Interfaces
The SDU should be designed so that all embedded software components
(operational software, User and Secure ORTs) can be loaded through industry
standards ARINC 615 and ARINC 615A data loaders.
It should also be possible to download the ORTs from the SDU to a data loader.
SDU software files should be compliant with ARINC 665.
3.4 Miscellaneous
3.4.1 Dual
Dual satcom can be implemented in a variety of ways as shown in the table below.
The main reason for this is due to the nature of how Classic Aero and
SwiftBroadband/Swift64 services are provided. Classic Aero channels are
dependent on a single AES ID (ICAO Code) and sharing of those channels has been
extensively explored and described in ARINC Characteristic 741. The combined
services of Classic Aero and SwiftBroadband/Swift64 into the one LRU has
complicated the original definition of dual satcom, but has also provided some
ARINC CHARACTERISTIC 781 – Page 70

3.0 SATCOM FUNCTIONS

additional operational benefits or advantages in the simplification of controlling

Classic Aero channels.
It should be noted that the different functional components of the SDU could at a
particular instance provide different types of dual functionality. For example the
Classic component could be operating in dual co-operative, while the
SwiftBroadband component could be operating in dual independent.
It is further noted, that an SDU implementation may support many dual modes and
the SDU could transition from one mode to another depending on, for example, the
dual status discretes.
Table 3-4 – Various Dual Satcom Implementations
Generic Name Key Characteristics Notes
No or minimal interaction between the two systems. Two For Classic Aero, the
Dual –
systems can have different functions and come from aircraft would require two
Independent
different suppliers. ICAO codes.
Dual – Cold Standby system is powered off until needed. A “control
Standby function” is required to power up the system.
Standby system is powered on. No interaction between
the radio functions of two systems (e.g., log on context
Dual – Warm
is not passed between systems). A dual control function
Standby
is required (but could be external). The radio function of
the standby does not modulate or demodulate signals.
Standby system is powered on. The context (e.g., log on
info, SwiftBroadband spot beam maps) is passed from
Dual – Hot
one system to the other to allow “fast recovery” after a
Standby
switchover. The radio function of the standby does not
modulate or demodulate signals.
There is no standby system since both systems are Defined per ARINC
providing some functionality. Typically uses “Master- Characteristic 741.
Dual –
Slave” concept. Both systems are modulating and Channel units in the
Cooperative
demodulating signals. The radio functions of the two standby system are
(Master/Slave)
systems are interacting (i.e., the radio control channel of active and controlled by
the slave unit is being provided by the master unit). the Master unit.

Each of the dual satcom implementations can be separated into the definition of key
functions:
• Radio Function
• Interface Function
• BITE Function
• Control Function
Interface functions in a dual system are described in sections below of this
document. The Radio and Control functions are dependent on the degree of desired
dual operation and are described in relation to each of the services being provided,
i.e., Classic Aero and or SwiftBroadband/Swift64 operations.
3.4.1.1 Classic Aero Operations
3.4.1.1.1 General
The choice of which dual SDU mode to implement should be based on the expected
use of the SDU (including redundancy considerations) on its target aircraft.
 ARINC CHARACTERISTIC 781 – Page 71

3.0 SATCOM FUNCTIONS

There are three key issues that determine the appropriate dual mode.
Firstly, at each power up cycle, both SDUs should perform a self-test of itself and if
no BITE errors are detected, the SDUs should each attempt to perform a logon to
verify correct operation. If any of the SDUs at power-up in a dual installation (other
than Cooperative Mode) fails to logon in a valid manner, the SDU that failed to log
on should declare itself inoperative and require manual intervention.
Secondly the interface between the AMS and satcom must be considered. If an AMS
can support four satcom voice inputs then the complexity in the SDU can be reduced
and for example Dual-Hot Standby can be used. However if the AMS can only
support two voice channels and it is required that (1) in normal operation the aircraft
has two voice channels and (2) on failure of either SDU, some voice functionality is
required (e.g., support for one voice channel), then only the Dual-Cooperative mode
may be appropriate.
Thirdly, only one ICAO address can normally be allocated to an aircraft. Hence in
this case dual independent mode is not appropriate.
Based on the above considerations, classic aero could be implemented as “dual-
warm standby”, “dual-hot standby”, or “dual-cooperative” depending on the aircraft
installation.
3.4.1.1.2 Interface Between SDUs
The Control & Interface Function that is implemented by the Cold/Warm/Hot
Standby/Dual Cooperative implementations use signaling that must be performed via
the dual satcom crosstalk buses (9C, 9D & 9G, 9H). This interface should be used to
provide an indication of the health between each system with the protocol and
interface definition being manufacturer specific.
3.4.1.1.3 Cold and Warm Standby
In the case of Cold and Warm Standby implementations, each SDU need not be
aware of what state the other SDU is in. Switching between each system is
achieved manually, either by software or a physical switch. In the case of Hot
Standby implementations, each SDU should monitor the health or the log on status
of the other SDU. Only one system is logged on to the Classic Aero services at any
one time, outputting valid indications to such systems such as the CMUs and
MCDUs. For the CMU, the standby SDU sets bit 11 of label 270 to indicate that it is
not available for the CMU to use. For the MCDU the ARINC Characteristic 739 data
would still be sent, but when the LSK is pressed for <SAT-R or <SAT-2 or
equivalent, then the satcom menu should show that the voice channels are not
available.
In normal operations, where both SDUs receive valid inputs from each other, the
SDU that is program pinned to be SDU number 1 should log on and SDU number 2
should remain logged off. If SDU number 2 receives an indication that SDU number
1 reports a failure (and is logged off), then SDU number 2 should proceed to log on.
If an SDU does not receive a valid input from the other system, then that SDU
should not attempt to log on or continue to be active. This could result in both SDUs
being in the standby mode. In this scenario, the situation requires pilot intervention
and a manual log on of the system that is deemed healthy.
ARINC CHARACTERISTIC 781 – Page 72

3.0 SATCOM FUNCTIONS

3.4.1.1.4 Cooperative Mode

In the case of Cooperative Mode, the channel units in the Slave system are
controlled and can modulate as determined by the Master. The complete definition
of this cooperative operation is described in ARINC Characteristic 741.
3.4.1.2 SwiftBroadband & Swift64 Operations
It is expected that Dual Independent mode is most appropriate for
SwiftBroadband/Swift64 operations. The SwiftBroadband/Swift64 channel units that
are installed in each of the SDUs can operate completely independently of each
other as determined by the onboard router.
3.4.2 Configuration & Identification Data
3.4.2.1 ORT
3.4.2.1.1 General
The Owner Requirements Table (ORT) is a table of configuration data that is used to
customize the operation of the AES. The ORT is split in to two sub ORTs known as
the “Secure ORT” and the “User ORT.” The Secure ORT holds configuration data
which if changed would affect the certification of the aircraft. The User ORT holds
configuration data which if changed would not affect the certification of the aircraft.
Based on the definitions in RTCA DO-178B, the Secure and User ORT are both
“software programmed options.” The Secure ORT is typically managed by the
airframe manufacturer. The User ORT is considered as User Modifiable Software
(UMS) and is managed by the airline or operator.
The Secure ORT can be stored in one of three places:
• Type (1) within the SCM.
• Type (2) within the SDU but can be changed independently of the
software.
• Type (3) as an integral part of the SDU software and hence cannot be
changed without a software change.
The User ORT can be stored in one of two places:
• Type (4) within the SCM.
• Type (5) within the SDU, but can be changed independently of the
software.
A mandatory system configuration pin (see Attachment 1-4A) determines the
location of both the Secure and User ORT.
Since certification criteria may be different between aircraft, an individual ORT
parameter could be within the Secure ORT on one aircraft and within the User ORT
on another aircraft. Hence a flexible software design approach should be
implemented such that a parameter can be defined as Secure or User.
For a Secure ORT of types (1) or (2) above, the Secure ORT will have its own part
number and this part number will be certified as part of the Aircraft Certification. For
a type (3) secure ORT, the ORT does not have its own part number, but instead the
secure ORT contents are defined within the SDU part number. The SDU should also
contain within its software load a default User ORT.
 ARINC CHARACTERISTIC 781 – Page 73

3.0 SATCOM FUNCTIONS

The data contained in the ORTs is shown in Section 3.4.2.1.3. One type of data is
the equivalent data to that determined by the optional system configuration pin. A
mandatory system configuration pin determines whether the SDU uses ORT data or
the optional system configuration pins customize the SDU operation.
A data loader is used to upload to the SDU and download from the SDU ORTs which
can be changed (i.e., ORTs (1), (2), (4), and (5)). Only complete User ORTs or
complete Secure ORTs should be uploaded/downloaded. When an ORT of type (1)
or (4) is uploaded to the SDU, the SDU should automatically (a) store within the SDU
a “local copy” of the ORT in case the SDU finds that an SCM held ORT is not valid,
(b) copy the ORT to the SCM, and (c) overwrite the old Secure ORTs or User ORTs
respectively held within both the SCM and as an SDU local copy. When an ORT of
type (1) or (4) is downloaded from the SDU, the SDU should download its local copy
of the Secure ORT or User ORT.
A “valid ORT” is an ORT whose: CRC is OK, is of the right format, and is not empty.
A valid ORT may have parameters within it or combinations of parameters within it
which will cause the SDU to not function or only to partially function on a particular
aircraft. A “correct ORT” is an ORT that is appropriate for that aircraft – appropriate
for a secure ORT is equivalent to it being certified for that aircraft. The SDU cannot
determine if its ORT is correct for a given aircraft; this can be only be determined by
manually comparing the part number of an ORT with the approved/certified ORT part
number for that aircraft.
3.4.2.1.2 ORT Synchronization
For ORTs that are held in the SCM (i.e., types (1) and (4)), the SDU should read the
ORT from the SCM after each power-up. Assuming it is valid, the SDU should
compare the just read SCM ORT with its “local copy” ORT. Normally, they are the
same, but if different, the SDU should overwrite its “local copy ORT” with the ORT
just read from the SCM. The SDU uses that ORT until the SDU is powered down.
The SDU should store the local copy of type (1) and (4) ORTs over a
power-down in case an ORT from the SCM is not valid when the SDU next
powers up.
The operation of the SDU when it determines that an ORT is not valid is as follows:
• For type (1) and (4): If the ORT read from the SCM is not valid then the
SDU should attempt to read the ORT from the SCM again. If the ORT is
still not valid after a number of such attempts, the SDU should use its
“local copy” ORT and the SDU should also declare a failure (but keep
operating). If the SDU has no valid local copy Secure ORT and it cannot
read a valid Secure ORT from the SCM, then the SDU should declare a
failure and stop operating. If the SDU has no valid local copy User ORT
and it cannot read a valid User ORT from the SCM, then the SDU should
(a) use the default User ORT, (b) declare a failure and (c) continue
operating.
• For types (2) and (3) – the SDU should declare a failure and stop
operating.
• For type (5) – the SDU should (a) use the default User ORT, (b) declare a
failure, and (c) continue operating.
ORT failures described above are “cleared” when the appropriate new ORT is
uploaded to the SDU as described in Section 3.4.2.1.1.
ARINC CHARACTERISTIC 781 – Page 74

3.0 SATCOM FUNCTIONS

This operation is summarized in Table 3-5 for type (1) and type (4) ORTs.
Table 3-5 – Operation of Type (1) and Type (4) ORTs
State of SDU Local Copy Logic for Type (1) ORT Logic for Type (4) ORT
ORT and SCM ORT (Secure ORT stored in SCM) (User ORT stored in SCM)
a Both ORTs valid & same Normal operation. Normal operation.
b Both ORTs valid but Use SCM ORT & transfer SCM ORT Same as for type (1).
different --> SDU Local Copy. Keep
operating. No failures raised.
c Only SCM ORT valid Use SCM ORT & transfer SCM ORT Same as for type (1).
--> SDU Local Copy. Keep
operating. No failures raised.
d Only SDU Local Copy Use SDU local copy. Do not transfer Same as for type (1).
ORT valid to SCM. Raise failure. Keep
operating. Failure cleared by
uploading new ORT.
e Neither ORT valid Raise failure. Do not operate. Use default User ORT. Do
Failure cleared by uploading new not transfer to SCM. Raise
secure ORT. failure. Keep operating.
Failure cleared by uploading
new user ORT.

3.4.2.1.3 ORT Contents

This table may accommodate the following items. It is left to the terminal
manufacturer to implement the appropriate ORT items required to support the
functionality provided. This table is held in non-volatile memory. The table
information can be updated and verified with the SDU connected on the aircraft.
These updates are incorporated by means of a portable or connected data loading
device. Due to the large number of ORT items, it is considered impractical to
manually edit the ORT on the aircraft.
ORT Section A: Log-on Parameter Configuration
1. Log-on/Handover policy
a. Automatic
b. User commanded
2. Ground Earth Station (GES)/Land Earth Station (LES) Preferences
The SDU should include a GES/LES Preferences function to order the
selection of GESs or LESs logons for the Inmarsat Classic and Swift64
services.
GES/LES preference settings should be available to the owner to
prioritize GES/LES selections across Inmarsat Classic and Swift64
services. GES/LES preferences should be defined in decimal values as
follows: Highest preference “1,” Lowest preference “9,” and Null (delisted)
“0.”
GES/LES station identifications should be enterable in octal format.
3. Channel Unit Default Mode of Operation (one for each channel)
a. Classic
b. SwiftBroadband with Swift64 Reversion
c. SwiftBroadband
d. Swift64
 ARINC CHARACTERISTIC 781 – Page 75

3.0 SATCOM FUNCTIONS

Note: This item determines the operating mode of the associated

channel module immediately after the power-up self-test
sequence.
4. Psid frequency bootstrap table
Note: This table contains two initial P channel frequencies for
each satellite ocean region. After the power-on self-test
sequence, the SDU should use this frequency table to
determine the initial frequency to tune the receiver in order
to initiate the log-on sequence to the appropriate satellite
based on current aircraft position. The SDU attempts to
use the primary frequency in a particular ocean region first.
If a P channel signal is not received on the primary
frequency, the SDU tunes the receiver to the secondary
frequency.
ORT Section B: Interfacing Systems Configuration
1. ICAO code source (Reference Attachment 1-4 Note 1)
a. ARINC 429 data bus – AES ID Input
b. ARINC 429 data bus – CMU Input
c. MCDU entry
2. AES ID Input bus speed (Reference Attachment 1-4 Note 1)
a. ARINC 429 high-speed data bus
b. ARINC 429 low-speed data bus
3. Deleted
4. AES ID Input – Presence of GPS Position Data (Reference Attachment 1-
4 Notes 1 and 27)
a. GPS position data present
b. GPS position data not present
5. Primary IRS Input (Reference Attachment 1-4 Notes 4 and 15)
a. Inertial data present
b. GPS position data present
c. Hybrid inertial and GPS data present
6. Secondary IRS Input (Reference Attachment 1-4 Notes 4 and 15)
a. Inertial data present
b. GPS position data present
c. Hybrid inertial and GPS data present
7. CMU 1
a. Connected
b. Not connected
Note: This ORT item is not applicable if strap pin TP3G
indicates to use other strap pins per Attachment 1-4A.
8. CMU 2
a. Connected
b. Not connected
ARINC CHARACTERISTIC 781 – Page 76

3.0 SATCOM FUNCTIONS

Note: This ORT item is not applicable if strap pin TP3G

indicates to use other strap pins per Attachment 1-
4A.
9. ARINC 429 bus speed between SDU and CMUs
a. High-speed
b. Low-speed
10. Central Fault Display System (CFDS) type
a. CFDS not connected
b. Airbus type CFDS
c. Boeing type CFDS
d. Other Airframe Manufacturers CFDS
11. MCDU/SCDU/WSC #1
a. Connected
b. Not connected
Note: This ORT item is not applicable if strap pin TP3G
indicates to use other strap pins per Attachment 1-
4A.
12. MCDU/SCDU/WSC #2
a. Connected
b. Not connected
Note: This ORT item is not applicable if strap pin TP3G
indicates to use other strap pins per Attachment 1-
4A.
13. MCDU/SCDU/WSC #3
a. Connected
b. Not connected
Note: This ORT item is not applicable if strap pin TP3G
indicates to use other strap pins per Attachment 1-
4A.
14. MCDU/SCDU/WSC Controller Type
a. SCDU
b. WSC
Note: This ORT item is not applicable if strap pin TP3G
indicates to use other strap pins per Attachment 1-
4A.
15. ARINC 429 bus speed to MCDU/SCDU/WSC #1, #2, and #3
a. High-speed
b. Low-speed
Note: This ORT item is not applicable if strap pin TP3G
indicates to use other strap pins per Attachment 1-
4A.
 ARINC CHARACTERISTIC 781 – Page 77

3.0 SATCOM FUNCTIONS

16. CCS connection

a. Connected
b. Not connected
Note: This ORT item is not applicable if strap pin TP3G
indicates to use other strap pins per Attachment 1-
4A.
17. CCS type
a. ITU Standard
b. ARINC 746
18. SCM
a. Connected
b. Not connected
Note: This ORT item is not applicable if strap pin TP3G
indicates to use other strap pins per Attachment 1-
4A.
19. ISDN 1
a. Connected
b. Not connected
Note: This ORT item is not applicable if strap pin TP3G
indicates to use other strap pins per Attachment 1-
4A.
20. ISDN 2
a. Connected
b. Not connected
Note: This ORT item is not applicable if strap pin TP3G
indicates to use other strap pins per Attachment 1-
4A.
21. Data from GNSS to SDU
a. Connected
b. Not connected
ORT Section C: Ethernet Ports Configuration
1. Ethernet port 1 configuration
a. Not Connected
b. Connected – speed auto detect
c. Connected – speed 10BASE-T
d. Connected – speed 100BASE-T
Note: If strap pin TP3G indicates to use other strap pins
per Attachment 1-4A, then this ORT item only
applies for the Ethernet bus speed.
2. Ethernet port 2 configuration
a. Not Connected
ARINC CHARACTERISTIC 781 – Page 78

3.0 SATCOM FUNCTIONS

b. Connected – speed auto detect

c. Connected – speed 10BASE-T
d. Connected – speed 100BASE-T
Note: If strap pin TP3G indicates to use other strap pins
per Attachment 1-4A, then this ORT item only
applies for the Ethernet bus speed.
3. Ethernet port 3 (Quadrax) configuration
a. Connected (and whether IEEE 802.3 or ARINC 664)
b. Not connected
Note: If strap pin TP3G indicates to use other strap pins
per Attachment 1-4A, then this ORT item only
applies for the type of Ethernet/ARINC 664.
4. Ethernet port 4 (Quadrax) configuration
a. Connected (and whether IEEE 802.3 or ARINC 664)
b. Not connected
Note: If strap pin TP3G indicates to use other strap pins
per Attachment 1-4A, then this ORT item only
applies for the type of Ethernet/ARINC 664.
5. Ethernet port 5 (spare) configuration
a. Connected
b. Not connected
6. Ethernet port 6 (fiber) configuration (note port 6 refers to the fiber
channel
A – pin 8 of ARINC 600 connector)
a. Connected
b. Not connected
7. Ethernet port 7 (fiber) configuration (note port 7 refers to the fiber channel
B – pin 9 of ARINC 600 connector)
a. Connected
b. Not connected
8. Ethernet port 8 (fiber) configuration (note port 8 refers to the fiber channel
spare – pin 10 of ARINC 600 connector)
a. Connected
b. Not connected
9. Fiber Ethernet port 9 configuration (note port 9 refers to the fiber channel
spare – pin 11 of ARINC 600 connector)
a. Connected
b. Not connected
10. Fiber Ethernet port 10 configuration (note port 10 refers to the fiber
channel spare – pin 12 of ARINC 600 connector)
a. Connected
b. Not connected
11. IP Settings
 ARINC CHARACTERISTIC 781 – Page 79

3.0 SATCOM FUNCTIONS

a. IPv4 address for LAN

Note: This setting defines the IP address of an interface
on the SDU. This setting is not applicable when
the DHCP client is enabled.
b. Subnet mask for LAN
Note: This setting defines the subnetwork mask of an
interface on the SDU. This setting is not applicable
when the DHCP client is enabled.
c. Default gateway for LAN
Note: This setting defines the default gateway of an
interface on the SDU. This setting is not applicable
when the DHCP client is enabled.
d. MAC addresses
e. DHCP Client
1. Enabled
2. Disabled
Note: Defines whether or not the interface receives an IP
settings from an external DHCP server
f. Host Name
12. PPPoE Settings
a. PPPoE Access Concentrator (AC) name
Note: This setting defines the PPPoE access
concentrator name for the interface. The SDU
uses this feature, but it is optional for the client to
use it.
b. Default Service Name Mapping
Note: When a PPPoE client requests a session to the
SDU and does not specify the service name the
SDU shall pick the service type based on this ORT
value. This value is any Service name(s) as
defined in Attachment 5, Section 3.3.11.
c. PPPoE Service Name Mapping to AT Commands
Note: This ORT item defines for each Service Name, the
AT string that is sent over the air interface. This
ORT item can also be used to define owner
specific Service Names. In addition, ORT item
C16 defines an APN that the SDU will use to
replace the APN in these ORT based AT strings.
13. Telnet access (control function)
a. Enabled (including TCP port (default 22222))
b. Disabled
14. DHCP Server Options
ARINC CHARACTERISTIC 781 – Page 80

3.0 SATCOM FUNCTIONS

a. Minimum IP Address (default 192.168.x.x)

b. Number of host IPs (default 50)
Note: The DHCP server will issue IP address between
'a' and 'a + b' above.
c. IP address of Default Gateway
Note: The default for this ORT parameter is to use the
same IP address of the DHCP server’s Ethernet
interface
d. Subnet Mask
Note: The default for this ORT parameter is to use the
same subnet mask of the DHCP server’s Ethernet
interface
15. SNMP Server Options
a. Community String (default public)
Note This option is used to access protected
parameters within the SNMP server.
16. APN
Note: This ORT item defines the APN that the SDU will
use to replace the APN in the ORT based AT
strings (reference ORT item C12).
17. Cockpit Ethernet Port
a. None reserved
b. Ethernet port X
Note: This could be used for the Safety IP Data as
mentioned in Section 3.1.1.4, or other cockpit
applications.
ORT Section D: Cockpit Voice Configuration
1. SDU codec #1 dedication
a. Cockpit audio system only
b. Cabin analog phone system only
c. Automatic sharing between cockpit and cabin
d. Not connected to cockpit audio or cabin analog phone system
2. SDU codec #2 dedication
a. Cockpit audio system only
b. Cabin analog phone system only
c. Automatic sharing between cockpit and cabin
d. Not connected to cockpit audio or cabin analog phone system
3. Ground-initiated cockpit call routing
This item determines the preferred cockpit voice channel for ground-
initiated calls when two channels are available. In a dual satcom system,
 ARINC CHARACTERISTIC 781 – Page 81

3.0 SATCOM FUNCTIONS

this item refers to a single AMS/ACP logical channel in the context of the
combined dual system. Reference ORT items D1, D2, and D12.
a. Channel 1
b. Channel 2
4. Ground-initiated Public Correspondence call routing
a. Cabin Communication System (CCS)
b. Cabin analog phone system
c. Disallowed
d. Cockpit audio management system
COMMENTARY
The installer should consider regulatory and operational
requirements for security before allowing public calls to the
cockpit.
5. Cockpit air-to-ground call camp-on timer
This item determines if camped-on cockpit calls should stay camped-on
indefinitely, or only until a timeout, and if the latter case, what the timeout
period should be
a. Indefinite
b. Timed (allow entry of timeout period)
Note: Timeout period of “0” implies no camp-
on/immediate preemption.
6. Noise insertion
This item determines whether noise is inserted in the ground-to-air
direction for cockpit calls to prevent total silence when no audio is
present. (minimize noise modulation effects).
a. -40 dBm0
b. -50 dBm0
c. -60 dBm0
d. Off
7. Cockpit hookswitch signaling method
a. Switched PTT and/or SCDU line switch(es)
b. Latched Audio Control Panel (ACP) satcom Mic-Switch
8. Telephone number pre-select
This item determines whether an air-to-ground cockpit call is immediately
initiated when the number is selected on an MCDU menu; or the MCDU
action merely “pre-selects” the number, with the call not initiated until
after activation of the Audio Control Panel satcom mic select switch,
whereupon the call to the pre-selected number is initiated. The latter case
requires that ORT item D7 Cockpit hookswitch signaling method be in the
“Latched ACP satcom Mic Switch” state.
a. Telephone number pre-select enabled
b. Telephone number dialed upon selection
9. SCDU line select key prompts for cockpit air-to-ground call
ARINC CHARACTERISTIC 781 – Page 82

3.0 SATCOM FUNCTIONS

In the case of system configuration ORT item D7 Cockpit hookswitch

signaling method set to the B state (latched ACP satcom Mic-Switch hook
switch signaling), this item determines whether SCDU line select key
prompts should be provided for air-initiated cockpit call setup
acknowledgement and call clear, and for ground-initiated call answer and
call reject; or whether all such prompts should be blanked (due to being
redundant to discrete signaling provisions).
a. SCDU line select key prompts provided
b. SCDU line select key prompts not provided
10. Chime for cockpit air-to-ground call
This item determines whether bit 14 of label 270, SDU to ACARS, and
the chime discrete is set for air-to-ground calls upon call set up. The
options to set bit 14 and the chime discrete for air-to-ground calls should
be:
a. Always
b. Only after a camp on
c. Never
11. Placement of Cockpit Call using Place/End Call Discretes
This item determines whether or not the SDU provides the Place Cockpit
Call capability, by interpreting the mic-on inputs as a function of the Call
Light as described below. ORT item D8 Telephone Number Pre-select
must be enabled in order to enable this ORT item.
If ORT item D7 is set to Latched mic-on input, the mic-on input going low
while the Call Light is off means Place Cockpit Call to a pre-selected
number.
If ORT item D7 is set to Switched ‘PTT, the Place/End Call discretes are
interpreted as Place Cockpit Call when exercised with the call light off.
If enabled, Cockpit Call initiation should be available from either channel.
If resources are tied up by the cabin, then the Cockpit Call should either
camp-on preempt the cabin call, depending on ORT item D5.
a. Enabled
b. Disabled
12. Dual satcom cockpit voice channel mapping to AMS/ACP
For a dual satcom system, whether the cockpit voice functional
interfacing between the SDU physical channels and the AMS/ACP logical
channels is fixed (i.e., each logical channel is interfaced with only one
physical channel in only one SDU) or shared (i.e., each logical channel is
interfaced with the same numbered physical channel in both SDUs).
a. Fixed
b. Shared
13. Manual dial of number not in directory
a. Enabled
b. Disabled (except for short codes)
14. Cockpit Headset Audio Gain
 ARINC CHARACTERISTIC 781 – Page 83

3.0 SATCOM FUNCTIONS

This item determines the headset audio level (both operational audio and
test tone) with respect to the nominal level of 10mW.
a. -3 dB
b. -2 dB
c. -1 dB
d. 0 dB
e. +1 dB
f. +2 dB
g. +3 dB
h. +4 dB
i. +5 dB
j. +6 dB
15. Cockpit Headset Sidetone Gain
This item determines the headset sidetone level, with respect to the
microphone input audio level.
a. 0 dB
b. -3 dB
c. -6 dB
d. -9 dB
e. -12 dB
f. Sidetone off
ORT Section E: Miscellaneous Configuration Settings
1. Use of flight ID (i.e., airline identifier and flight number)
a. Enabled
b. Disabled
2. Use of circuit-mode data on ground-to-air calls
a. Enabled
b. Disabled
3. High rate return data channel in global beam
This item determines, for an AES capable of high-rate packet data
service, whether the AES should request not to be assigned high-rate
return data channels while operating in the global beam.
a. High rate return data channel enabled in global beam
b. High rate return data channel disabled in global beam
4. Antenna configuration
a. ARINC 781 HGA
b. ARINC 781 IGA
c. LGA + LGA HPA
d. ARINC 741 Top BSU + Top HGA + HGA HPA
e. ARINC 741 Port BSU + Port HGA + STARBOARD BSU +
STARBOARD HGA + HGA HPA + HPR
ARINC CHARACTERISTIC 781 – Page 84

3.0 SATCOM FUNCTIONS

Note: This ORT item is not applicable if strap pin

TP3G is grounded. Refer to Attachment 1-4A.
5. GNSS Frequency Check Algorithm
a. Not required
b. Required with f limit = 1585 MHz
c. Required with f limit = 1605 MHz
6. Position reporting
a. Enabled
b. Disabled
7. Reserved
8. Minimum initial EIRP for Swift64
9. Weight on wheels input configuration
a. Not connected
b. Ground on pin MP7D = Aircraft on ground
c. Ground on pin MP7D = Aircraft in air
Note: This ORT item is not applicable if strap pin TP3G
indicates to use other strap pins per Attachment 1-
4A. Reference Attachment 1-4 Note 19.
10. PIMBIT failure threshold level (reference Sections 3.7.2, 3.7.3.5, 3.7.3.8,
and 3.7.3.12)
a. X dB channel degradation. The recommended default value is 3 dB.
11. PIMBIT antenna beam pointing angles to be used (reference Section
3.7.3.7)
a. Azimuth angles relative to true-north or true-south (depending on
whether the aircraft is located in the northern or southern hemisphere,
respectively). The recommended default values are -15, 0, +15
degrees for an HGA, and -10, 0 and +10 degrees for an IGA.
b. Elevation angles relative to the horizon. The recommended default
values are +12.5 and +27.5 degrees for an HGA, and +12.5 and +18
degrees for an IGA.
COMMENTARY
Similar commentary as for the azimuth angles. IGA values are tighter
in order to prevent unintended radiation into the geostationary orbit
arc.
Note: This results in a total of six beam pointing angles
being used for the test.
12. PIMBIT antenna beam pointing angles failure threshold (reference
Section 3.7.4)
a. Any X or more angles “failed” out of Y angles total. The
recommended default value is 1 or more out of 6.
13. PIMBIT measurement sample discard ratio (reference Section 3.7.3.10)
 ARINC CHARACTERISTIC 781 – Page 85

3.0 SATCOM FUNCTIONS

a. X %. The recommended default value is 5%. The computed number

of samples to discard should be rounded up to the nearest integer as
long as at least two samples are available.
ORT Section F: Telephone Directory
1. Telephone numbers
2. Telephone directory headings
3. Priority associated with each stored telephone number
COMMENTARY
The table and the method of update are handled by the AES owner.
“Connected” is defined to mean that the interface is wired to the SDU
and that the interfacing equipment is connected.
Additional manufacturer-specific ORT items (mapping of Ethernet
ports to channel cards, etc.) may be required.
ORT Section G: SwiftBroadband Safety Services Configuration
1. Safety Channel Identifier
a. No Safety Channel
b. Channel 1
c. Channel 2
d. Channel 3
e. Channel 4
2. Position Reporting Service
a. Enabled
b. Disabled
Note: This is separate from ORT Item E-6 and is used to
enable/disable the Safety Position Reporting
Service.
3. Safety Channel Access Class (0-15) – used to give priority network
access to Safety
4. ACARS Data APN
5. Voice over IP APN
6. AGGW DNS Lookup Name
7. Aircraft Type (e.g., 747-400, 747-8, 330-500, 737-NG, 737-MAX)
3.4.2.2 System Configuration Pins
Certain pins have been reserved so that the SDU can determine the system
configuration. These pins and the functions implemented by pin-programming are
further described in Attachment 1-4A.
The use of these pins is mandatory in order to determine:
• If an external HPA is fitted or not
• The location of the ORTs
ARINC CHARACTERISTIC 781 – Page 86

3.0 SATCOM FUNCTIONS

• If other configuration pins should be used by the SDU

• Installed SDU number (1 or 2)
3.4.2.3 AES ID
The Classic Aero service and SwiftBroadband safety service require the SDU to use
the Aircraft’s ICAO Code identification. The ARINC 429 label definition and interface
is described in ARINC Characteristic 781 Attachment 1-4, Note 1 and can be
received on an aircraft bus. Alternatively, the AES ID can be entered via the MCDU
and stored in the SCM.
3.4.2.4 Forward/Return ID (Swift64)
Inmarsat Swift64 operation requires a 24-bit Forward ID for each Swift64 channel
and a corresponding 24-bit Return ID, which the SDU may derive from the Forward
ID via an internal look-up table.
For certain aircraft that have the capability to broadcast information such as Forward
IDs from a centralized source of aircraft data, the digital implementation is described
in Attachment 2, Figures 8 and 9. This scheme allows an operator to enter all of their
aircraft unique identification (such as ICAO Code, Tail Number, SELCAL, Forward ID,
etc.) at one time to be broadcast and received by the intended equipment by the use
of defined labels.
The SDU should expect only one base Forward ID per SDU and perform a lookup
for the subsequent Forward IDs and all Return IDs for all Swift64 channels as
defined in Attachment 2, Figures 8 and 9.
This base Forward ID is expected to be received on either the AES ID bus, CMU bus
or the CFDS bus on the SDU.
Alternatively, the base Forward ID can be entered via the MCDU and stored in the
SCM.
3.4.2.5 IMSI and IMEI(SV) (SwiftBroadband)
The International Mobile Subscriber Identity (IMSI) and International Mobile
Equipment Identifier (IMEI) are used in SwiftBroadband in a similar manner to their
use in GSM and UMTS.
The IMSI is used within SwiftBroadband to uniquely identify each SwiftBroadband
channel within the AES. Each IMSI is stored on a USIM (in a secure manner) and
the USIM(s) are housed in the SCM. The IMSI is the primary identification for
addressing and billing within SwiftBroadband for non-safety services. The IMSI
numbers are allocated by Inmarsat, and are provided to the avionics suppliers.
Avionics suppliers should inform their customers which IMSI(s) are installed in each
delivered SCM.
The IMEI is used within SwiftBroadband to uniquely identify each SwiftBroadband
hardware channel within an SDU as well as the manufacturer of the SDU. The
International Mobile Subscriber Identity Software Version (IMEISV) is used to
uniquely identify the software within the SDU. The IMEIs are allocated by British
Approvals Board for Telecommunications (BABT) to the avionics suppliers, who then
program the IMEIs into the SDU. The expected uses of IMEI and IMEISV are to
allow the barring of stolen (or cloned) terminals and to identify the manufacturer and
software version of faulty terminals.
 ARINC CHARACTERISTIC 781 – Page 87

3.0 SATCOM FUNCTIONS

3.4.2.6 Addressing for SwiftBroadband Safety Services

SwiftBroadband safety services use the ICAO AES ID as the identifier for both
ACARS and voice services, thus ensuring commonality with Classic Aero as well as
compliance to ICAO SARPs. The SDU uses both the IMSI and AES ID in signaling.
Terrestrial side ACARS and voice signaling only uses the AES ID.
3.4.2.7 Aircraft Type
The Aircraft Type parameter allows the SDU to determine if there are any unique
dependencies that the satcom system has to adjust to, based upon which airframe
type it is installed in. For instance one airframe type may have an MCDU
implementation that is different to another MCDU format on another airframe type.
Upon receipt of this digital label and coordination with Aircraft OEMs, the SDU could
adjust to their new environment with pre-programmed MCDU menu settings.
Attachment 2, Figure 10 describes the ARINC 429 implementation for decoding
which airframe type the SDU is being installed on.
This ARINC 429 word is expected to be received on either the AES ID bus, CMU
bus, or the CFDS bus on the SDU.
3.4.3 Security
From a security perspective, the aircraft network systems are divided into
three domains being: Aircraft Control (AC) Domain, Airline Information
Services (AIS) Domain and Passenger Information and Entertainment Services
(PIES) Domain. The satcom system should satisfy security requirements and
this is particularly the case when the satcom system is providing service to
both the AC domain and AIS/PIES domain.
FANS services (e.g., ADS-C, CPDLC, and voice) to the cockpit, as provided by
Classic Aero or SBB, is viewed as AC domain while, for example, EFB is
viewed as AIS domain.
The security requirements are to demonstrate, by an appropriate security
process, that the functions (shared or independent) contained within the SDU
can provide adequate segregation between domains of traffic and withstand
potential threats that are introduced by its use in an open network
environment.
The security threats associated with the satcom system include, in order of
severity, (1) impersonation or modification of FANS messages to/from the
cockpit, (2) interruption or loss of satellite communications, and (3)
interception of communications by unauthorized parties. Additional, and
potentially significant, risks are introduced from the ground network against
the airborne resources and must be considered in any implementation of
layered security, but are out of scope for this document and not addressed
here.
It is recommended that EUROCAE ED-202/RTCA DO-326: Airworthiness
Security Process Specification be used as the basis of the security process; it
defines the following steps in the security process.
• Identify the security scope
• Identify the security threats
ARINC CHARACTERISTIC 781 – Page 88

3.0 SATCOM FUNCTIONS

• Develop the security architecture

• Assess the preliminary security risk
• Assess the final security risk
• Verify the implementation
• Ensure the security of the final product
Attachment 8 includes guidance on security considerations for SBB safety
service terminals including the type of segregation that is expected to be
acceptable to regulatory authorities and airframers for such terminals.
Appendix B is a security analysis of the Ethernet interface as defined in
Attachment 5.

Shared INTERFACE SDU CONTROL PARTITION

Shared PARTITION
Dual Use IO Ports SDU System Processor & Memory

Cockpit Ports IO Ports

MCDU/IRS/CMC/
IO Controllers

CMU/EICAS/EFB IO Ports
Channel Proc
& Memory RF Tuners
IO Ports

HPA
Cabin Ports IO Ports
Channel Proc
& Memory
RF Tuners
IF E/picocell
IO Ports

SDU OPERATIONAL PARTITION

3.5 Priority, Precedence, Preemption, and Preference

Priority, precedence and preemption are defined for Classic Aero services in the
ICAO Annex 10, Chapter 4 AMSS SARPs, the RTCA DO-210 AMSS MOPS, and the
RTCA DO-270 MASPS for AMS(R)S. For priorities higher than non-safety/public
communications (NS/PC), those definitions only pertain to the Classic interfaces for
Cockpit Audio and CMU packet-mode data, as they are the only interfaces capable
of specifying explicit priority/precedence levels for their associated communications.
With the exception of satellite link signaling for the initial-phase establishment of
Classic non-safety circuit-mode channels (which are afforded higher precedence
levels for the sake of overall system efficiency), all other services on all other
interfaces are handled as NS/PC
(voice priority “4,” or packet data subnetwork connection priority "none").
However, although there are no means for the aforementioned NS/PC
communications to compete among themselves for satellite link and terrestrial
resources other than on a first-come, first-served basis, it is desirable to facilitate
such functionality within each aircraft for the benefit of that aircraft's users. In order
to preclude confusion with regulatory definitions of priority and precedence, this
functionality is defined in this document in terms of "preferences.” For example, it
may be preferred to establish an air-to-ground cabin voice call using SwiftBroadband
instead of using Swift64 M-ISDN or a Classic Aero H+ C-channel, or to route a
ground-to-air call to a particular Ethernet interface instead of the other possibilities.
Priority, Precedence, Preemption, and Preference should apply for the selection of
the Inmarsat services, satellites, and ground stations defined in Section 3.1.2.6.
 ARINC CHARACTERISTIC 781 – Page 89

3.0 SATCOM FUNCTIONS

3.6 Future Growth

3.6.1 ARINC 664 Deterministic Ethernet
For newer generation of aircraft, the traditional ARINC 429 based interfaces are
being superseded by ARINC 664 implementations. The benefits of this are that the
wiring interfaces are greatly simplified by making use of existing data networks
onboard the aircraft, thus allowing for greater weight savings. The physical medium
for ARINC 664 can be simple twisted pair interfaces (for low bandwidth interfaces) or
the newer Quadrax (ARINC Specification 600) and fiber (ARINC 801, 802, 803, 804,
805, and 806) definitions. Currently, the ARINC 664 interfaces defined in
Attachments 1-3 and 1-4 specify two Quadrax and five fiber ports.

ARINC 664 Network

Switch A

ARINC 664 Network

Switch B

Figure 3-7 – ARINC 664 Interface Topology

3.6.2 Fiber Optic

Fiber Optic is the ARINC 664 interface medium by which higher data rates are
accommodated. Each airframe manufacturer has its own policies for the use of Fiber
Optic. The use of ARINC 664 also helps reduce wiring interface weight depending
on how far the SDU is situated from the aircraft’s avionics bay. ARINC 781 specifies
five fiber optic ports of which only two ports are defined for cockpit interfaces.
Channels A and B provide the redundancy for most of the above ARINC 664-based
systems and functionalities.
3.6.3 FANS/ATS over SwiftBroadband
COMMENTARY
FANS/ATS over SwiftBroadband is now specified in the main body of
this Characteristic.
3.6.4 Multi-Frequency Band
This section deleted by Supplement 5.
ARINC CHARACTERISTIC 781 – Page 90

3.0 SATCOM FUNCTIONS

3.7 Passive Intermodulation Built-In Test (PIMBIT)

The material in this section is applicable to multi-channel system installations that
support at least one SwiftBroadband channel. For the case of multiple system
installations, each system can be treated independently of the others (in view of the
assumed minimum propagation loss between the multiple systems’ antennas).
3.7.1 Introduction
Intermodulation occurs whenever two or more RF signals at different frequencies mix
together in any non-linear passive or active system element. Examples are beam-
switching diodes in electronically-steered antennas, inherently nonlinear conductors
such as nickel or stainless steel, corroded metallic contacts in materials such as
cables (including their shields and connectors), the aircraft skin and rivets, nearby
structures, etc. Passive Intermodulation in system elements preceding the DLNA
(e.g., in the SDU/HPA) can be minimized by filtering it in the diplexer. However,
(P)IM occurring in or after the diplexer cannot be filtered, so it must be managed in
other ways. (Reference Section 2.3.6 regarding installation guidelines for minimizing
the impact of PIM.)
3.7.2 Technical Background
For Classic Aero and Swift64 channels, frequency management as has been
implemented in the past by Inmarsat (i.e., restriction of AES-transmitted frequencies
to a relatively narrow bandwidth of about 4 MHz) has resulted in PIM being of little
concern with those services. However, with high-EIRP SwiftBroadband (SBB)
signals being transmitted from the AES/UT at much greater frequency spacing
(potentially up to the full bandwidth allocated to Inmarsat), and with Inmarsat
discontinuing frequency management of Swift64, it is possible for relatively high-
power, low-order PIM products (e.g., 5th, 7th, 9th, and 11th) to fall into the AES receive
band, with the potential to interfere with active receive channels. As a result,
Inmarsat and airframe manufacturers have required that the SDU perform a built-in
test (BIT) to measure PIM (PIMBIT).
At a minimum, a manually-initiated two-tone CW form of PIMBIT is required in order
to measure the PIM level from a pre-determined IM product (e.g., 9th order) under
controlled test conditions. This PIM test can be performed at the time of initial
system installation or upgrade, periodically, or whenever indicated by performance
degradation that cannot be attributed to any other cause. If the PIMBIT fails,
corrective maintenance action will be required to restore the system performance to
a level sufficient for the test to pass.
It should be noted that a limitation of the manually-initiated two-tone CW PIMBIT is
that it only utilizes three frequencies out of the many used in actual operation,
checking against a threshold that may not correlate closely with the actual receiver
robustness and is a function of the antenna G/T performance. As a result, it is
possible that the manually-initiated two-tone CW PIMBIT could fail, but that the
system could be operating satisfactorily, with or without resorting to the data link
layer and higher-layer automatic-retransmission protocols. To help minimize this
possibility (which would result in nuisance failures), the failure criteria for the CW test
are set such that any failure is most likely indicative of a problem of sufficient
magnitude that it would affect normal operations under at least some, if not all,
conditions. It is also recommended to not use the result of this test in isolation, but
rather to use it as a means of confirmation of a PIM problem after another indication
 ARINC CHARACTERISTIC 781 – Page 91

3.0 SATCOM FUNCTIONS

occurs, such as noticeable system performance degradation in the absence of any

other failures in the system that could result in the performance degradation.
3.7.3 SDU Functionality
The subsections below summarize the issues that should be taken into consideration
in the manually-initiated two-tone CW PIMBIT implementation in the SDU.
3.7.3.1 Frequencies Reserved for PIMBIT
From the perspective of the AES/UT, Inmarsat reserves one receive and two
transmit frequencies for PIMBIT usage in each satellite region (or at least in each I-4
and Alphasat satellite region). (It is possible that a receive frequency may not be
able to be reserved in each region.) This information is made available to the
SDU/UT via the SwiftBroadband bulletin board broadcasts and the Classic Aero
system table broadcasts, and is guaranteed to be usable for at least 168 hours
(seven 24-hour periods) after being broadcast (for possible use in AESs/UTs that
have not received an update within that time period immediately prior to PIMBIT
initiation). The frequencies are chosen such that the receive frequency corresponds
to the nth-order IM product from the two transmit frequencies (n typically being 9).
This allows the AES/UT to transmit CW test signals on the two transmit frequencies
without interfering with other system users, and to monitor the receive frequency
(nominally “quiet”) for any signal power that results from (P)IM from the two transmit
frequencies.
3.7.3.2 Transmit Test Signal Levels (EIRP)
Test signal levels transmitted away from the geostationary orbit arc should be at 20
dBW EIRP per carrier (to emulate SBB transmissions). Any and all test signal levels
transmitted toward the geostationary orbit arc must be limited to no more than 7
dBW EIRP per carrier (to limit side-lobe as well as intentionally-directed EIRP
levels). (Any intentional transmission at such low levels usually results in PIM
products being below the background noise level, so as a practical matter,
transmission toward the geostationary arc at such low levels is generally useless for
PIMBIT purposes. As a result, test transmissions are recommended to be only
generally directed toward the north in the northern hemisphere, and only generally
south in the southern hemisphere.)
3.7.3.3 Constant EIRP versus Constant Power to the Antenna
As long as the HGA gain equals or exceeds its nominal 12 dBic, then constant EIRP
(20 dBW) should be used per CW test carrier during the test (i.e., the SDU/HPA
output power should be adjusted as appropriate to compensate for reported antenna
gain variations). If the HGA gain falls below 12 dBic, then constant HPA power of 8
dBW at the antenna input should be used at all such antenna gain levels. For the
case of an IGA, the antenna gain threshold is 6 dBic, the constant EIRP case is 15.1
dBW, and the constant SDU/HPA output power case is 9.1 dBW at the antenna
input.
3.7.3.4 ORT Parameters
Any PIMBIT parameters that may be subject to future change (as experience is
gained with PIM and PIMBIT) should be stored as ORT items. Examples include
failure threshold(s), the antenna beam pointing angles to be used during the test, the
number of antenna beam pointing angles that must fail before declaring the overall
PIMBIT test to have failed (e.g., any 1 or more out of 6), and the measurement
ARINC CHARACTERISTIC 781 – Page 92

3.0 SATCOM FUNCTIONS

sample discard ratio for the measurements taken for each antenna beam pointing
angle. Reference ORT items 10E, 11E, 12E, and 13E (see Section 3.4.2.1.3).
3.7.3.5 IM Product Order to be Tested
The IM product order that was pre-determined in Inmarsat’s choice of test
frequencies should be computed by the SDU and used for making appropriate
adjustments to failure thresholds that are a function of the IM product order being
tested. IM product orders of at least 7 through 19 should be able to be taken into
account by the PIMBIT.
3.7.3.6 Transmit Signal Off/On Sequence for Receive Signal Monitoring
Monitoring of the receive frequency should be performed with the transmit
frequencies both “on” and “off” during adjacent time periods in order to be able to
attribute measured “on” signal levels to being from AES/UT-caused (P)IM (as
opposed to other possible sources of signal power at that frequency at the same
time). An off/on/off sequence of three measurements would further help to confirm
that conditions are stable during the measurement (by confirming that the two “off”
measurements are essentially identical).
3.7.3.7 Antenna Beam Pointing Angles to be Tested
Monitoring should be performed at a number of different antenna beam pointing
angles in order to aid with fault isolation. Reference ORT item 11E for the angles to
be used, and item 12E for the number of beam angles that must fail in order to
declare the PIM test to have failed.
3.7.3.8 PIMBIT Assessment Parameter
The industry-common parameter to be assessed by PIMBIT should be ∆T/T channel
degradation (if expressed as a simple ratio), where T = the normal system noise
temperature in Kelvins (316 for the system G/T spec of -13 dB/K and a minimum
antenna gain of 12 dB), and where ∆T = T 2 – T (where ∆T is the increase in system
noise temperature that is assumed to be due to PIM, T is the initial system noise
temperature without PIM degradation (from the system G/T requirement), and T 2 is
the effective system PIM-degraded noise temperature). Expressed as decibels (as
preferred for the PIMBIT application), this degradation is:
• 10 log 10 (T2/T) = 10 log 10 ((T + ∆T)/T) = 10 log 10 (1 + ∆T/T).
• E.g., for a 100% increase in system noise temperature
(T 2 = 632 Kelvins, T 2 /T = 2, ∆T/T = 1), channel degradation = 3 dB.
COMMENTARY
One recommended way of getting to this parameter is to make a
determination of the ratio of (PIM + N)/N, where PIM is the averaged
CW signal power level assumed to be from PIM during transmission
of the two CW test signals, and N is the averaged power level of the
noise floor (when the two CW test signals are not being transmitted).
Such a ratio derived from measurements that can be made by the
SDU eliminates installation variables such as the gain of the LNA and
the losses in the rest of the receive signal path (which would
otherwise need to be known if simply dealing with absolute signal
levels at the SDU and attempting to relate them to levels at the
antenna port). This is similar to how one would determine the channel
 ARINC CHARACTERISTIC 781 – Page 93

3.0 SATCOM FUNCTIONS

degradation manually using a spectrum analyzer, by measuring the

difference between the signal levels (assumed to be PIM) when the
two CW test signals are transmitting versus the noise floor when no
test signals are transmitting. For the recommended discard ratio,
reference ORT item E13.
3.7.3.9 Stabilization and Measurement Times
The CW test transmissions should be sustained for at least one second after any
change in order to allow thermal stability to be achieved in the antenna elements.
The CW test transmissions must also be sustained for a sufficiently long time for the
receiving demodulator to stabilize and to be able to take accurate measurements
(this being modem-design-dependent). (These stabilization times proceed
concurrently.) The total stabilization time should be kept to the minimum necessary
in order to minimize satellite illumination/interference time. Test measurements
should then be taken for 10 seconds after achieving stabilization, and the
subsequently-obtained results then processed appropriately.
3.7.3.10 Measurement Discard Ratio
It is permissible to discard a certain percentage of the worst test measurements for
each beam pointing angle, and to perform the appropriate processing on the
remaining best test samples. For the recommended discard ratio, reference ORT
item E13.
3.7.3.11 Measurement of Additional IM Product Orders
As the antenna will presumably always be pointed away from the geostationary
satellite arc (per Section 3.7.2 above), then unless there is some other L-band signal
source present during the PIM test, the AES/UT could opt to measure PIM products
at orders other than the one prescribed by the frequencies assigned for the CW test
transmissions, by tuning the receiver to other appropriate frequencies (e.g.,
corresponding to the 7th, 11th, etc. products, even though the assigned frequencies
were intended to allow for measurement of the 9th product). The need or advantage
for doing such additional measurements remains to be determined.
3.7.3.11.1 PIMBIT Results Display/Storage and Immediate Clearing of any “Failure”
As the PIMBIT is a “snapshot” test, the detailed results should be stored (with certain
relevant related parameters) for future reference, as well as displayed after
completion of the test (until the test is fully terminated and normal operation is
resumed), and a “pass” or “failure” declaration may be required by some OEMs. The
stored relevant related parameters should include, but not be limited to, the
following:
• Aircraft-relative azimuth and elevation antenna beam pointing angles
• Test frequencies used
• ICAO address
• Average channel degradation results for each antenna beam
• Antenna serial number (as available)
• Date and time
• PIMBIT ORT item settings
• Standard deviation (1σ) of the measurement results for each antenna beam
ARINC CHARACTERISTIC 781 – Page 94

3.0 SATCOM FUNCTIONS

Any failure should be immediately cleared following the test, as the test status is only
relevant at the time of its execution, such that any such failure has no impact on
normal system operation or on any subsequent reports to the central maintenance
system/function.
3.7.4 Operational Considerations
3.7.4.1 Prerequisite Conditions
Certain prerequisite conditions should be confirmed to be met before initiating the
test. These include having the satcom system successfully log-on or register
recently (within the previous 168 hours (seven 24-hour periods)), having the
IRS/ADIRS/GNSS operational/aligned/outputting valid data to the satcom system,
having no other failures in the satcom system that could affect the PIM test (e.g.,
HPA, DLNA, antenna/BSU/ACU, interconnections (RF coax, discretes, ARINC 429,
etc.), having the satcom system frequency reference being within its specified
operating temperature range, etc.).
3.7.4.2 Aircraft Orientation
No special aircraft orientation requirements pertain for systems using an HGA, nor
for those using an IGA with multi-dimensional beam steering. However, for testing
with an IGA using one-dimensional beam steering (i.e., one that produces a fan-
shaped beam), the aircraft must be oriented such that the nose is pointing toward
true north or south (either way), along with steering the antenna as defined in
Section 3.7.3.7.
3.7.4.3 Test Initiation
The PIMBIT should be initiated from the central maintenance system interface in the
cockpit or similar (e.g., MCDU or maintenance terminal). Ideally, the test should be
conducted while the aircraft is outside and at least 50 meters away from any
adjacent structures, other aircraft, or other large vehicles. The test will typically take
several minutes to execute.
3.7.4.4 Action Following Test Failure
If the test should fail when initiated inside a hangar or near large structures or
vehicles (including other aircraft), the test should be repeated in an open area at
least 50 meters away from any such adjacent structure/vehicle. If the re-test passes,
the initial failure can probably be attributed to (additional) PIM from the other
structures. If the re-test still fails, then corrective maintenance action should be
taken until subsequent re-tests pass.
3.7.4.5 Interpreting Results of the PIMBIT
This is an area where experience conducting the test will be helpful. Note that PIM
levels can vary considerably over time – repeated test attempts may be helpful in
interpreting the results.
Some guidelines are provided below based on early limited experience with PIMBIT.
• Failure at only some antenna beam pointing angles would tend to indict the
antenna, or possibly the aircraft skin.
• Failure at all angles would tend to indict a component such as the DLNA-to-
antenna coaxial cable assembly or its mating connectors.
 ARINC CHARACTERISTIC 781 – Page 95

3.0 SATCOM FUNCTIONS

• High PIM levels at high elevation angles may indict the antenna. This could
be true if the PIM levels are variable with beam azimuth.
• High PIM levels at low elevation could indict the antenna or the installation
(adapter plate, etc.). There also may be an incompatibility with nearby
installed systems. This could be especially true if the PIM is present if beams
are steered fore and aft at low elevation along the axis of the aircraft.
• High PIM levels that are beam-independent might be indicative of a bad
DLNA or cable from the antenna to the DLNA. Depending on the severity of
the problem, they may be evident at the lower orders but in severe cases
may persist to, e.g., the 45th order. In cases like this, it may be useful to
remove the antenna from the chain and replace it with a low PIM load (e.g., a
long cable bundle). This could serve to isolate the DLNA and cable. This will
not be possible when the system is in service.
• Repeating the test after rotating the aircraft, or changing the antenna beam
pointing angles via the respective ORT item, will typically give at least
somewhat different results and may provide additional insight to the source of
the PIM.
3.7.4.6 AMM Recommendations
Recommended corrective actions to be performed when the test fails should be
included in the aircraft maintenance manual (AMM). It should be noted that PIM can
be intermittent, and that PIMBIT may indicate a PIM failure on the aircraft but that it
is very limited in its ability to isolate the failure to a specific area or to indicate the
specific required corrective action. The AMM information should include but not be
limited to the following (in the preferred order of execution for most aircraft – adjust
as appropriate for the specific aircraft type):
• Visually inspect the DLNA-to-antenna coaxial cable for physical damage
(cable jacket abrasion or cuts), violation of the minimum specified bend
radius or the presence of kinking, loose or over-tight cable clamps, corrosion,
etc.
• Check the DLNA-to-antenna cable assembly:
o Disconnect the cable assembly between the DLNA and the antenna.
o Inspect and clean (e.g., with isopropyl alcohol) the connectors on the
cable assembly and on the DLNA & antenna (starting with the DLNA end
first).
o Reconnect and torque the connectors on the coaxial cable between the
DLNA and the antenna.
• Clean the mating surfaces between the fuselage and the antenna adapter
plate, and between the adapter plate and the antenna. Treat aluminum
surfaces with chromate conversion coating (e.g., Alodine®).
Before performing any of the following replacement actions, it may be preferable to
perform one or more of the “additional actions” listed further below if the necessary
resources (personnel, equipment, and flight test opportunity) are available.
• Replace the antenna.
• Replace the DLNA.
• Replace the DLNA-to-antenna coaxial cable assembly.
ARINC CHARACTERISTIC 781 – Page 96

3.0 SATCOM FUNCTIONS

Additional actions that may be taken by OEM and/or equipment provider engineering
personnel for fault isolation include but are not limited to the following:
• Affix a low-PIM dummy load at the antenna port of the DLNA and repeat the
PIM test.
• Affix a low-PIM dummy load at the antenna end of the DLNA-to-antenna
coaxial cable assembly.
• Launch the PIMBIT while the aircraft is in-flight using special engineering test
interfaces/modes.
The maximum recommended azimuth and elevation angle settings for the ORT
items should be specified, based on the characteristics of the installed antenna.
 ARINC CHARACTERISTIC 781 – Page 97

ATTACHMENT 1-1A
GENERAL CONFIGURATION OVERVIEW – SINGLE SATCOM INSTALLATION

Voice Channel 2

AMS
Analog Audio
,
Discretes
Voice Channel1

Wheels
Weight
Discrete

On
ISDN
CEPT-E1

Cabin Services
LAN
Cabin
Antenna

SwiftBroadband

Services
Cockpit
LAN
Satcom System

Cockpit
DLNA

EFB
615A
ARI NC

Loader
Data

ARINC 615
EI CAS
CMU
#1, #2

ARINC758
SDU

CFDS/
CMC

ARINC604
#1, #2
I RS

ARINC429
#1, #2, #3
SCM

SCDU

ARINC 739 or WSCI

ARINC CHARACTERISTIC 781 – Page 98

ATTACHMENT 1-1B
GENERAL CONFIGURATION OVERVIEW – DUAL SATCOM INSTALLATION

Voice Channel2 Voice Channel

2

AMS
Analog Audio
, Analog Audio
,
Discretes Discretes
Voice Channel
1 Voice Channel
1

Wheels
Weight
On
Discrete Discrete

ISDN ISDN
CEPT-E1 CEPT-E1

Cabin Services
LAN

LAN
Cabin

Cabin
Antenna

Antenna
SwiftBroadband

Services
Cockpit
LAN

LAN
Cockpit

Cockpit
Satcom System #1

Satcom System #2
DLNA

DLNA
EFB
ARINC

ARINC
615A

615A
Loader
Data

ARINC615 ARINC615
EICAS
CMU
#1, #2

ARINC758 ARINC758
SDU

SDU
CFDS/
CMC

ARINC604 ARINC604
#1, #2
IRS

ARINC429 ARINC429
SCM

#1, #2, #3

SCM
SCDU

ARINC 739 or WSCI ARINC 739 or WSCI

Crosstalk Buses Disable Discretes

, Select/
 ARINC CHARACTERISTIC 781 – Page 99

ATTACHMENT 1-2A
SATCOM SYSTEM CONFIGURATION – HPA INTEGRATED IN SDU

Power Power Power

RF Rx

RF

RF Tx DLNA
ARINC 781
BITE / Control IGA or HGA
SDU
(contains
BSU
functions)
ARINC 429 (Multicontrol)

ARINC 429 (BITE from Antenna)

Power Signaling

SCM
ARINC CHARACTERISTIC 781 – Page 100

ATTACHMENT 1-2B
SATCOM CONFIGURATION – OPTIONAL FLANGE MOUNTED HPA

Power Power Power

RF Rx

Power RF

RF Tx RF Tx DLNA
BITE / ARINC 781
Control IGA or HGA
HPA
SDU ARINC 429
(contains
(BITE from HPA) BSU
functions)

ARINC 429 (Multicontrol)

ARINC 429 (BITE from Antenna)

Power Signaling

SCM

Note: This configuration is expected to be used on those few aircraft

where the installation loss between the SDU and antenna
does not meet the 2.5 dB loss requirement.
 ARINC CHARACTERISTIC 781 – Page 101

ATTACHMENT 1-3
STANDARD INTERWIRING

SDU SIGNAL NAME PIN SIGNAL TYPE SOURCE/SINK NOTES

SDU RF Output to DLNA (or HPA). TP71 50 ohm coax DLNA/J3 or HPA/J2 11
Input/output for ELGA (SB200 Configuration 3) or ELGA/J1

ATE Pins TP01A

ATE Pins TP01B
ATE Pins TP01C
ATE Pins TP01D
ATE Pins TP01E
ATE Pins TP01F
ATE Pins TP01G
ATE Pins TP01H
ATE Pins TP01J
ATE Pins TP01K

ATE Pins TP02A

ATE Pins TP02B
ATE Pins TP02C
ATE Pins TP02D
ATE Pins TP02E
ATE Pins TP02F
ATE Pins TP02G
ATE Pins TP02H
ATE Pins TP02J
ATE Pins TP02K

Ethernet 1 from SDU to User + TP03A 100BASE-TX 37

Ethernet 1 from User to SDU + TP03B 100BASE-TX 37
Ethernet Empty Cavity TP03C 100BASE-TX
Config Pin 1 TP03D 0V common 17
Config Pin 2 TP03E Discrete 17
Config Pin 3 TP03F Discrete 17
Config Pin 4 TP03G Discrete 17
Spare TP03H
ISDN 1 from SDU to User + TP03J ISDN
ISDN 1 from User to SDU + TP03K ISDN

Ethernet 1 from User to SDU - TP04A 100BASE-TX 37

Ethernet 1 from SDU to User - TP04B 100BASE-TX 37
Ethernet Empty Cavity TP04C 100BASE-TX
Config Pin 5 TP04D Discrete 17
Config Pin 6 TP04E Discrete 17
Config Pin 7 TP04F Discrete 17
Config Pin 8 TP04G Discrete 17
Spare TP04H
ISDN 1 from User to SDU - TP04J ISDN
ISDN 1 from SDU to User - TP04K ISDN

Ethernet Empty Cavity TP05A 100BASE-TX

Ethernet Empty Cavity TP05B 100BASE-TX
Ethernet Empty Cavity TP05C 100BASE-TX
Config Pin 9 TP05D Discrete 17
Config Pin 10 TP05E Discrete 17
Config Pin 11 TP05F Discrete 17
Config Pin 12 TP05G Discrete 17
Spare TP05H
Spare TP05J
Spare TP05K
 ARINC CHARACTERISTIC 781 – Page 102

ATTACHMENT 1-3
STANDARD INTERWIRING

SDU SIGNAL NAME PIN SIGNAL TYPE SOURCE/SINK NOTES

Ethernet 2 from SDU to User + TP06A 100BASE-TX 37

Ethernet 2 from User to SDU + TP06B 100BASE-TX 37
Ethernet Empty Cavity TP06C 100BASE-TX
Config Pin 13 TP06D Discrete 17
Config Pin 14 (Spare) TP06E Discrete 17
Config Pin 15 (Spare) TP06F Discrete 17
Config Pin 16 (Spare) TP06G Discrete 17
Spare TP06H
ISDN 2 from SDU to User + TP06J ISDN
ISDN 2 from User to SDU + TP06K ISDN

Ethernet 2 from User to SDU - TP07A 100BASE-TX 37

Ethernet 2 from SDU to User - TP07B 100BASE-TX 37
Ethernet Empty Cavity TP07C 100BASE-TX
Config Pin 17 (Spare) TP07D Discrete 17
Config Pin 18 (Spare) TP07E Discrete 17
Config Pin 19 (Spare) TP07F Discrete 17
Config Pin 20 (Spare) TP07G Discrete 17
Spare TP07H
ISDN 2 from User to SDU - TP07J ISDN
ISDN 2 from SDU to User - TP07K ISDN

Data from MCDU 1 A MP01A A429 3, 12

Data from MCDU 1 B MP01B A429 3, 12
Call Place/End Discrete Input 1 MP01C Discrete 23, 28
CONFIG MODULE Power Source (+ 8 to 15V) MP01D SCM/8 33
Multi-Control Output A MP01E A429 HPA/P HGA/6 or 4
IGA/6
Multi-Control Output B MP01F A429 HPA/R HGA/8 or 4
IGA/8
Reserved External Reset Discrete Input MP01G Discrete 7
Call Place/End Discrete Input 2 MP01H Discrete 23, 28
Data from MCDU 2 A MP01J A429 3, 12
Data from MCDU 2 B MP01K A429 3, 12
36
Data from Primary IRS/GNSS A MP02A A429 4, 15, 21
Data from Primary IRS/GNSS B MP02B A429 4, 15, 21
Cockpit Voice Chime Signal Contact 1 MP02C Discrete 9
CONFIG MODULE Power Return MP02D SCM/15 33
BITE Input from HPA A MP02E A429 HPA/A 3
BITE Input from HPA B MP02F A429 HPA/B 3
Reserved Mfr. Specific 0-28V Discrete Output MP02G Discrete 36
Cockpit Voice Chime Signal Contact 2 MP02H Discrete 9
Data from Secondary IRS/GNSS A MP02J A429 4, 15, 21
Data from Secondary IRS/GNSS B MP02K A429 4, 15, 21
 ARINC CHARACTERISTIC 781 – Page 103

ATTACHMENT 1-3
STANDARD INTERWIRING

SDU SIGNAL NAME PIN SIGNAL TYPE SOURCE/SINK NOTES

Data from CMU 1 A MP03A A429 1, 2, 24

Data from CMU 1 B MP03B A429 1, 2, 24
Cockpit Voice Call Light Output 1 MP03C Discrete 6, 28
Data to SCM A MP03D RS422 SCM/3 33
Discrete Output (Spare) MP03E 6
Discrete Input (Spare) MP03F 7
Spare MP03G
Cockpit Voice Call Light Output 2 MP03H Discrete 6, 28
Data from CMU 2 A MP03J A429 1, 2, 24
Data from CMU 2 B MP03K A429 1, 2, 24

Cockpit Audio Input 1 Hi MP04A Analog 10, 28

Cockpit Audio Input 1 Lo MP04B Analog 10, 28
Cockpit Voice Mic On Input 1 MP04C Discrete 7, 28
Data to SCM B MP04D RS422 SCM/4 33
Spare Discrete Output MP04E 6
Spare Discrete Input MP04F 7
Spare MP04G
Cockpit Voice Mic On Input 2 MP04H Discrete 7, 28
Cockpit Audio Input 2 Hi MP04J Analog 10, 28
Cockpit Audio Input 2 Lo MP04K Analog 10, 28

Cockpit Audio Output 1 Hi MP05A Analog 10, 28

Cockpit Audio Output 1 Lo MP05B Analog 10, 28
Cockpit Voice Go Ahead Chime Reset 1 MP05C Discrete 7
Data from SCM A MP05D RS422 SCM/1 33
Spare Discrete Output MP05E 6
Spare Discrete Input MP05F 7
Spare ARINC 429 Output A MP05G A429 29
Spare ARINC 429 Output B MP05H A429 29
Cockpit Audio Output 2 Hi MP05J Analog 10, 28
Cockpit Audio Output 2 Lo MP05K Analog 10, 28

Spare Discrete Input MP06A 7

Spare Discrete Input MP06B 7
Spare Discrete Input MP06C 7
Data from SCM B MP06D RS422 SCM/2 33
Ethernet 5 (Spare) from SDU to User + MP06E 10BaseT
Ethernet 5 (Spare)from SDU to User - MP06F 10BaseT
Spare ARINC 429 Input A MP06G A429 29
Spare ARINC 429 Input B MP06H A429 29
Data from GNSS to SDU A MP06J A429 4
Data from GNSS to SDU B MP06K A429 4

AES ID Input A MP07A A429 1, 27

AES ID Input B MP07B A429 1, 27
Spare Discrete Input MP07C Discrete 7
WOW Input 1 MP07D Discrete 19
Ethernet 5 (Spare)from User to SDU + MP07E 10BaseT
Ethernet 5 (Spare)from User to SDU - MP07F 10BaseT
Spare ARINC 429 Output A MP07G A429 29
Spare ARINC 429 Output B MP07H A429 29
Data to CMU 1 & 2 A MP07J A429 2, 24, 25
Data to CMU 1 & 2 B MP07K A429 2, 24, 25
 ARINC CHARACTERISTIC 781 – Page 104

ATTACHMENT 1-3
STANDARD INTERWIRING

SDU SIGNAL NAME PIN SIGNAL TYPE SOURCE/SINK NOTES

Data from CFDS A MP08A A429 3

Data from CFDS B MP08B A429 3
BITE Input Top/Port BSU/Ant A MP08C A429 HGA/3 or IGA/3 3
BITE Input Top/Port BSU/Ant B MP08D A429 HGA/5 or IGA/5 3
Data Loader Link A MP08E Discrete 14
TX Mute Input MP08F Discrete 7
BITE Input STBD BSU A MP08G A429 3
BITE Input STBD BSU B MP08H A429 3
Data to CFDS A MP08J A429 3
Data to CFDS B MP08K A429 3

From Airborne Data Loader A MP09A A429 4, 14

From Airborne Data Loader B MP09B A429 4, 14
Crosstalk from Other SDU A MP09C A429 Other SDU/MP09G 4, 22
Crosstalk from Other SDU B MP09D A429 Other SDU/MP09H 4, 22
Dual System Select Discrete I/O MP09E Discrete Other SDU/MP09F 31
Dual System Disable Discrete I/O MP09F Discrete Other SDU/MP09E 31
Crosstalk to Other SDU A MP09G A429 Other SDU/MP09A 4, 22
Crosstalk to Other SDU B MP09H A429 Other SDU/MP09B 4, 22
To Airborne Data Loader A MP09J A429 4, 14
To Airborne Data Loader B MP09K A429 4, 14

Data from MCDU 3 A MP10A A429 3, 12

Data from MCDU 3 B MP10B A429 3, 12
Port BSU HPA Mute Input A MP10C A429 32
Port BSU HPA Mute Input B MP10D A429 32
LGA LNA On/Off Control MP10E Discrete 6
BITE Input from LGA LNA MP10F Discrete 5
STBD BSU HPA Mute Input A MP10G A429 32
STBD BSU HPA Mute Input B MP10H A429 32
Data to MCDU 1,2,3 A MP10J A429 12, 18
Data to MCDU 1,2,3 B MP10K A429 12, 18

POTS 1 A MP11A Analog 8

POTS 1 B MP11B Analog 8
Cabin CEPT-E1 Data Output A MP11C 20
Cabin CEPT-E1 Data Output B MP11D 20
Service Availability Discrete 1 MP11E Discrete 30
Service Availability Discrete 2 MP11F Discrete 30
Cabin CEPT-E1 Data Input A MP11G 20
Cabin CEPT-E1 Data Input B MP11H 20
POTS 2 A MP11J Analog 8
POTS 2 B MP11K Analog 8

Service Availability Discrete 3 MP12E Discrete 30

Service Availability Discrete 4 MP12F Discrete 30

Service Availability Discrete 5 MP13E Discrete 30

Service Availability Discrete 6 MP13F Discrete 30

Service Availability Discrete 7 MP14E Discrete 30

Service Availability Discrete 8 MP14F Discrete 30

Service Availability Discrete 9 MP15E Discrete 30

Service Availability Discrete 10 MP15F Discrete 30
 ARINC CHARACTERISTIC 781 – Page 105

ATTACHMENT 1-3
STANDARD INTERWIRING

SDU SIGNAL NAME PIN SIGNAL TYPE SOURCE/SINK NOTES

Ethernet 3 from SDU to User + MP1T1 Quadrax

Ethernet 3 from SDU to User - MP1T3 Quadrax
Ethernet 3 from User to SDU + MP1T2 Quadrax
Ethernet 3 from User to SDU - MP1T4 Quadrax

Ethernet 4 from SDU to User + MP2T1 Quadrax

Ethernet 4 from SDU to User - MP2T3 Quadrax
Ethernet 4 from User to SDU + MP2T2 Quadrax
Ethernet 4 from User to SDU - MP2T4 Quadrax

115 Vac Cold BP01

Reserved +28 Vdc Hot BP02
Chassis Ground BP03
Reserved +28 Vdc Ground BP04
115 Vac Hot BP05 16
Coax (antenna control for CSDU) BP06 ELGA/J2 11
Coax (from DLNA) BP07 DLNA/J2 11
Ethernet 6 (Channel A) BP08 Fiber 34
Ethernet 7 (Channel B) BP09 Fiber 34
Ethernet 8 (Spare) BP10 Fiber 34
Ethernet 9 (Spare) BP11 Fiber 34
Ethernet 10 (Spare) BP12 Fiber 34

DLNA SIGNAL NAME PIN SIGNAL TYPE SOURCE/SINK NOTES

Antenna Port J1 50 ohm coax HGA or IGA 11

LNA Control B Discrete HGA/11 or IGA/11 35

LNA BITE H Discrete HGA/9 or IGA/9 35
LNA BITE Ground J HGA/10 or IGA/10 35

Chassis Ground A
115 Vac Cold E 16
115 Vac Hot F
+28 Vdc Hot G
+28 Vdc Return K
See also coaxial cable from SDU or from HPA and to
SDU

HGA or IGA SIGNAL NAME PIN SIGNAL TYPE SOURCE/SINK NOTES

+28 Vdc Hot 1

+28 Vdc Return 2
115 Vac Hot 18 16
115 Vac Return 19
Chassis Ground 22
See also ARINC 429 wires to/from SDU and coaxial
cable from/to DLNA and discrete wires from the DLNA
 ARINC CHARACTERISTIC 781 – Page 106

ATTACHMENT 1-3
STANDARD INTERWIRING

HPA SIGNAL NAME PIN SIGNAL TYPE SOURCE/SINK NOTES

RF Out J3 50 ohm coax DLNA/J3 11

115 Vac Hot X 16

115 Vac Return Y
Chassis Ground J
See also ARINC 429 interwiring from SDU and coax
from SDU

SCM SIGNAL NAME PIN SIGNAL TYPE SOURCE/SINK NOTES

SCM Signals are shown in SDU section.

 ARINC CHARACTERISTIC 781 – Page 107

ATTACHMENT 1-4
NOTES APPLICABLE TO STANDARD INTERWIRING

1. The 24-bit ICAO SSR Mode S Address (used as the AES ID) should be read from the Data Bus
from CMU #1 (SDU pins MP3A and MP3B) or the Data Bus from CMU #2 (SDU pins MP3J and
MP3K) or the AES ID input (SDU pins MP7A and MP7B) if available. The Owner Requirements
Table (ORT) item B1 identifies whether ARINC 429 data is available. Data from the CMUs is
available on Labels 214 and 216 (as specified in ARINC Specification 429, Attachment 6), or on
the AES ID input bus on Labels 275 and 276 (at 5 to 10 words per second) as specified in
ARINC Specification 429 for the Mode-S Transponder to TCAS. ORT item B2 specifies the bus
speed for the AES ID input. If the address is not available on any 429 input, it should be read
from the ORT database or entered manually on the SCDU. If a Configuration Module is
installed, the ICAO address should be stored on the module for use by the SDU if the ICAO
Address is not available on a subsequent power-up.
The AES ID input may contain additional position labels (Latitude on label 310, Longitude on
label 311), depending upon the setting of ORT item B4 AES ID Input – Presence of GNSS
Position Data. When present on the AES ID input, label 310 (Present Position Latitude) and
311 (Present Position Longitude) will be formatted per ARINC 429. These labels are intended
to support SwiftBroadband transmit signal timing requirements on a B777 aircraft.
COMMENTARY
Installers wishing to use the Mode-S transponder as the source of the
ICAO address should ensure that the transponder will continue to
transmit a valid ICAO address when in standby mode. The satcom
system may be rendered inoperative if a valid ICAO address cannot
be obtained due to satcom attempting to read the ICAO address when
the transponder is in standby mode Transponders set the Sign/Status
Matrix (SSM), bits 30 and 31, to No Computed Data (NCD) when in
standby mode, so it is necessary that the SDU interpret ICAO data as
valid when the SSM is set to NCD.
2. The CMU is an optional system that may not be available on all aircraft whereas the
transponders are required equipment for Air Transport category aircraft. The Communications
Management Unit (CMU) or equivalent is responsible for integrating data communications via
the satellite communications system with data communications via other data links on the
aircraft. It exchanges data with the SDU at the physical layer on an ARINC 429 data bus, and
at the link layer using the bit-oriented file transfer protocol. It utilizes the ISO 8208 subnetwork
layer (packet level) protocol, as described in that international standard.
3. ARINC 429 low-speed data bus.
4. ARINC 429 high-speed data bus.
5. Units functioning normally should annunciate this fact by placing a voltage between +15 Vdc
and +36 Vdc relative to airframe dc ground, defined as 0 ± 3V dc, on the connector pins
assigned to the BITE discrete output. Absence of this voltage will be interpreted as a fault
annunciation. BITE annunciation is not required when the unit has been commanded “off.”
6. The SDU should provide an internal switch closure to ground. The switch “contact” should be
open for (i) LNA off, (ii) no cockpit voice call annunciation, and closed for (i) LGA LNA on, (ii)
cockpit voice call annunciation active, (iii) the polarity logic of spare outputs will be defined when
the spare output functionality is defined. The “open” voltage hold-off should be 36 Vdc max.,
the potential across the “closed” switch should be 1 Vdc or less and the cold in-rush current
handling capacity should be 500 mA max and the steady state value should be 50 mA max.
The cockpit voice call annunciation is to be steady until reset.
ARINC CHARACTERISTIC 781 – Page 108

ATTACHMENT 1-4
NOTES APPLICABLE TO STANDARD INTERWIRING

7. The SDU should sense the closure of an external switch to dc ground. The resistance to
airframe dc ground, defined as 0 ± 3V dc, presented to the SDU connector pins should be
100,000 ohms or more when the external switch is open and 10 ohms or less when the switch is
closed. The closed state of the external switches will indicate that (i) a cockpit microphone is in
use with satcom, (ii) the Voice Go-Ahead (Chime) output should be reset, (iii) the satcom RF
output should be muted, (iv) reset the SDU, (v) the polarity logic of spare inputs will be defined
when the spare input functionality is defined. In the case of (i), this input can be wired to either
the satcom-selected PTT switch, or to an ACP satcom mic transmit key switch suitably latched
for the duration of the call as specified by ORT setting D7.
LATCHED Mic-On OPERATION (ORT setting D7)
If the Call Light is ON, the Mic-steady ground is interpreted as off-hook, which answers an
incoming call when the signal goes low and ends the call when the signal goes high.
If the ORT (item D8) is set for ACP initiated Cockpit Calls and, if the Call Light is OFF, the Mic-
On discrete going to ground is interpreted as Place Cockpit Call. Refer to ARINC Characteristic
741, Part 2, Section 4.13.
8. These SDU pins are intended to support two-wire analog POTS (plain old telephone service)
circuit mode equipment such as telephones, fax machines, and circuit-mode data equipment
including personal computers and secure voice terminals connected directly to the satcom
system. Reference the Inmarsat Aeronautical System Definition Manual, Modules 1, 2, and 5,
and the relevant vendors for specific options and details.
9. When enabled by ORT item D10 and a cockpit air to ground call is placed, or upon receiving a
ground to air cockpit call, the SDU should close a circuit between pins MP2C and MP2H when
the voice go-ahead (chime) output is to be activated such that a current of 1 amp may flow
through an external device fed from a 28 Vdc source. The current should flow “from” the chime
“to” MP2C, and the current should flow “to” the chime “from” MP2H. Maximum hold-off voltage
in the open circuit condition should be 36 Vdc. The minimum hold time (for both the on and off
states) should be 250 ms. The chime should be single stroke.
10. The shields of twisted and shielded pairs of wires used for audio signal transfer should be
grounded at the transmitter end only. While it is preferable to utilize two cockpit audio channels,
the SDU is only required to interface with one channel.
11. The characteristic impedance of each coaxial interface should be 50 ohms.
12. This Satellite Control/Display Unit (SCDU) interface is required to permit the SDU to be
managed by a cockpit control panel. The SDU should be capable of exchanging command and
control information with the SCDU using the MCDU protocol standards defined in ARINC
Characteristic 739 or WSCI (see ARINC 741 Part 2, Attachment 2F-42.1). Display and control
details are manufacturer-specific. Note that no messages for the air-ground link will originate in
or be routed to the SCDU over this interface. The details of this interface are manufacturer-
specific.
13. All TNC and N type connectors should be provided with means to prevent the effects of
vibration from causing the threaded collar with which the mating halves are secured together
from becoming loose.
14. Interface details are per ARINC Report 615. Interwiring is only required on those aircraft having
an ARINC 615 Airborne Computer High Speed Data Loader installed. The Data Loader Link A
discrete is used to enable the SDU to determine whether or not an ARINC 615 ADL is
connected. A resistance to airframe dc ground, defined as 0 ±3 Vdc, presented to the SDU
connector pin of 100,000 ohms or more should be interpreted as the ADL is not connected, and
a resistance of 1,500 ohms or less should be interpreted as the ADL is connected.
 ARINC CHARACTERISTIC 781 – Page 109

ATTACHMENT 1-4
NOTES APPLICABLE TO STANDARD INTERWIRING

15. There are four ARINC 429 inputs defined on the SDU connector for the purpose of receiving
inertial data and GNSS data. The airframe manufacturer should provide a definition of what
data is available on each of these four ports to the SDU manufacturer. The following table lists
the possible functionality available on each ARINC 429 input:

SDU Middle Plug Pins Pin Definition Functionality

A2, B2 Data from Primary IRS Inertial and/or GNSS Data
J2, K2 Data from Secondary IRS Inertial and/or GNSS Data
J6, K6 Data from GNSS to SDU GNSS Data
A7, B7 AES ID Input Lat/Long (see Interwiring Note 1)

The following table defines the inertial and GNSS parameters and labels available from various
aircraft inertial and GNSS systems. For inertial data and GNSS data available on IRS inputs for
antenna control steering and computed Doppler correction, the ARINC 429 Octal labels in the
left hand column of the table below should be transmitted from an inertial system, such as IRS,
ADIRS, ADSU, or equivalent equipment. In addition to the inertial labels, when the
SwiftBroadband function is supported by the SDU, it is strongly recommended that the SDU
obtain GNSS corrected position data (latitude/longitude). Depending on the aircraft, GNSS data
may be obtained from various sources. If a hybrid inertial/GNSS system is available on the
aircraft, the IRS input(s) should be wired to provide both inertial data and GNSS position data
according to the right hand column of the following table. If a hybrid inertial/GNSS system is not
available on the aircraft, then one of the IRS inputs may be used to provide inertial data to the
SDU while the other IRS input may be used to obtain autonomous GNSS data, or GNSS data
may be provided on the Data from GNSS data to SDU input while maintaining primary and
secondary IRS inputs for inertial data. If provided on the aircraft, GNSS data may also be
obtained from the AES ID input per Interwiring Note 1. Each IRS input may be configured per
ORT items B5 and B6 to receive the labels in any one column of the following table:

Inertial Data GNSS Data Hybrid Inertial/GNSS Data

Parameter Label Parameter Label Parameter Label
Present Position 310 Latitude GNSS, 110 Latitude GNSS, Hybrid or 254 or
– Latitude Autonomous Autonomous 110
Present Position 311 Longitude GNSS, 111 Longitude GNSS, Hybrid 255 or
– Longitude Autonomous or Autonomous 111
Ground Speed 312 Ground Speed GNSS, 112 Ground Speed GNSS, 175 or
Autonomous Hybrid or Autonomous 112
Track Angle – True 313 Track Angle True 103 Track Angle True GNSS, 137 or
GNSS, Autonomous Hybrid or Autonomous 103
True Heading 314 True Heading N/A True Heading, Hybrid or 132 or
Inertial 314
Pitch Angle 324 Pitch Angle N/A Pitch Angle 324
Roll Angle 325 Roll Angle N/A Roll Angle 325
Inertial Altitude 361 GNSS Height (HAE) or 370 or Hybrid Altitude MSL or 261, or
GNSS Altitude 076 GNSS Altitude 076
UTC N/A GNSS UTC (Binary) 150 GNSS UTC (Binary) 150
Date N/A GNSS Date 260 GNSS Date 260
GNSS Sensor N/A GNSS Sensor Status 273 GNSS Sensor Status 273
Status
GNSS HDOP N/A GNSS HDOP 101 GNSS HDOP 101
ARINC CHARACTERISTIC 781 – Page 110

ATTACHMENT 1-4
NOTES APPLICABLE TO STANDARD INTERWIRING

Refer to ARINC 429 for the format of labels in the above table.
Systems providing classic aeronautical services and Swift64 may only need to use the inertial
labels in the left hand column for inertial data. An SDU may be wired to any one or two of up to
three IRSs. It is strongly recommended that systems providing SwiftBroadband service is wired
to receive GNSS data to support SwiftBroadband transmit signal timing requirements in addition
to receiving inertial data.
The hybrid inertial and GNSS data solution is preferred, as it allows for redundant Inertial and
GNSS inputs to the SDU using the primary and secondary IRS inputs to the SDU.
If the aircraft is not equipped with hybrid inertial systems providing inertial and GNSS data on
the same data bus, then the SDU should be wired to receive separate inertial and GNSS inputs.
a. If the aircraft provides two inertial inputs to the SDU, then the primary and secondary
IRS SDU inputs should be wired to receive inertial data. The Data from GNSS to SDU
input should be wired to receive GNSS Data (unless lat/long is available on the AES
Input Bus).
b. If the aircraft provides one inertial input to the SDU, then the primary IRS input to the
SDU should be wired to receive inertial data and either the secondary IRS input or the
Data from GNSS to SDU Input can be used to receive GNSS data.
ORT items B4, B5, and B21 define which IRS pins on the SDU are wired to sources of IRS data
and whether the GNSS to SDU bus is enabled.
For aircraft with hybrid inertial/GNSS systems inputs, label 370 should not be used for altitude
because it can be defined to be acceleration. Hybrid inertial/GNSS systems should use altitude
label 261 for altitude when available. If label 261 is not available, then label 076 should be used
for altitude.
For aircraft that do not have hybrid inertial/GNSS systems inputs, label 370 from GNSS should
be used for altitude over labels 076, and 361. If altitude label 370 is not available, label 076
should be used. If neither label 370 nor label 076 is available, then label 361 should be used for
altitude.
Track angle may not be available on the ground. The SDU should not declare a fault due to a
lack of track angle or no computed data for track angle when the aircraft is on the ground.
16. Circuit breaker protection information for the single satcom system is as follows:
• One (1) 115 Vac 5 amp, circuit breaker is provided for SDU-1, DLNA-1 and Antenna-1
for the majority of configurations.
• Two (2) 115 Vac 5 amp circuit breakers are provided, one for SDU-1 and one for HPA-1,
DLNA-1 and Antenna-1 for aircraft with a long distance between the SDU and antenna
components requiring an FMHPA installation.
The system installer should conduct a load analysis to ensure the total current draw of the total
system does not exceed approximately 80% of the current rating of the circuit breaker, and
in-rush current should be taken into consideration. After conducting the load analysis, a larger
circuit breaker may be chosen or an additional circuit breaker used to power the antenna
components (DLNA, Antenna) if the above circuit breaker recommendations are insufficient.
Each circuit breaker should have a Type A (short delay) response. When dual satcom systems
are installed, the circuit breakers utilized in each system are the same as those given above. It
should be noted that the pin size for the high gain antenna connector allows a maximum of 22
gage wire to be installed to power the antenna. This wire size limits the antenna circuit breaker
to a maximum of 5 amps in order to ensure that the circuit breaker protects the wire in the event
of a short circuit.
 ARINC CHARACTERISTIC 781 – Page 111

ATTACHMENT 1-4
NOTES APPLICABLE TO STANDARD INTERWIRING

17. The System Configuration Pins definition and interpretation details are shown in
Attachment 1-4A. A small number of System Configuration Pins are mandatory. The others
may be optionally used by installers to define additional configuration details. If the optional
System Configuration Pins are not used then the configuration information may be found in the
ORT. TP3G is used to define whether the optional System Configuration Pins should be read
by the SDU. The SDU should attempt to read the System Configuration Pins upon power-up.
It should be noted that the System Configuration Pins use ‘multiplexed pin programming’ and
that 7 of the Service Availability Discretes are used to provide the multiplexed matrix select
strapping. Although unlikely, the optional System Configuration Pins could be used on aircraft
that also use the Service Availability Discretes. It is therefore recommended that (1) the SDU’s
System Configuration Pins are open circuit except when they are being read so that Service
Availability lamps/LEDs are not partially illuminated, and (2) diode isolation (external to the
SDU) of each Service Availability lamp/LED power may be needed to stop misreading of
System Configuration Pins by the SDU if (and only if) the external power source of the
lamps/LEDs could be grounded in the “off state” and the Service Availability Discrete is
connected to a System Configuration Pin.
18. Reference Attachment 1-4A or ORT item B15 for the definition of the speed (high or low) of this
ARINC 429 bus.
19. This discrete will be used to enable the SDU to determine whether or not the aircraft is airborne.
The WOW Input should be programmable such that the “true” state may be annunciated by
either an airframe dc ground, defined as 0 ±3 Vdc or a resistance to airframe dc ground of less
than 1500 ohms at the SDU connector pin MP7D, or an open circuit or voltage. An open circuit
is defined as a resistance of 100,000 ohms or more between pin MP7D and airframe dc ground.
The voltage, relative to airframe dc ground, at an input for a “true” indication should be 7 Vdc or
more (max 30 Vdc). For this condition, the SDU should present a load of at least 10,000 ohms
at the input. Resistance sensing should be based on current flow from the SDU to airframe dc
ground.
Programming should be either achieved by means of SDU system configuration pin TP6D or
ORT item E6. This discrete is only required to be wired if equivalent information is not strapped
as being available to the SDU on an ARINC 429 input, for example, IRS or the CFDS.
Appropriate fail-safe logic (assuming airborne when the air/ground state is unknown, or when
multiple ARINC 429 sources contradict each other) should be used in most cases; however,
when two or more ARINC 429 sources are wired and no valid data is available (including
reception of invalid data), the on-ground state may be assumed in order to enable normal
ground maintenance activities independent of other aircraft equipment.
20. CEPT-E1 data bus defined in CCITT G.703 and G.704 and ARINC 746.
The SDU designer should be aware that some aircraft will use 100 ohm “star quad” cable rather
than 120 ohm shielded twisted pair for this interface.
21. Deleted. Content consolidated into Note 15.
22. The protocol used on these interfaces is manufacturer specific.
23. The SDU should sense a momentary (typically no less than 100 milliseconds) closure of
external switches to dc ground. The resistance to airframe dc ground presented to the SDU
connector pins should be 100,000 ohms or more when open, and less than 10 ohms when
grounded. The transition from open to ground on the external switches will indicate End Call for
any ongoing call on the respective channel. If there is no ongoing call, and if ORT item D8
telephone number pre-select is enabled and ORT item D7 cockpit/hookswitch signaling is set to
latched, then the transition from open to ground shall indicate Place Cockpit Call if a telephone
number has been pre-selected.
ARINC CHARACTERISTIC 781 – Page 112

ATTACHMENT 1-4
NOTES APPLICABLE TO STANDARD INTERWIRING

24. Reference ORT item B9 for the definition of the speed (high or low) of these ARINC 429 buses.
25. This SDU output may also be wired to the EICAS/ECAM/EDU to permit that unit to monitor the
Label 270 word, which is specified in ARINC Characteristic 741, Part 2, Section 4.7.3.1.
26. Reserved.
27. Reference ORT item B2 for the definition of the speed (high or low) of this ARINC 429 bus.
28. In a dual system, the physical channel 1 and 2 interfaces on each SDU map to the AMS/ACP
logical channel interfaces per ORT items D1 and D2 (CODEC dedication) and D12 (codecs
fixed/shared. The SDU cockpit telephony signaling outputs in a dual system should only be
asserted by the SDU supporting a call with one of its physical channels. AMS/ACP systems with
interfaces for two Satcom audio channels typically use one physical channel from each SDU to
provide two operational cockpit voice channels. AMS/ACP systems with interfaces for four
Satcom audio channels typically connect both physical channels from each SDU to the
AMS/ACP system, providing redundancy for both cockpit voice channels in the event of a single
channel failure.
29. These interfaces should support both ARINC 429 low-speed and high-speed.
30. The SDU should provide an internal switch closure to ground. The “open” voltage hold-off
should be 36 Vdc max., the potential across the “closed” switch should be 1 Vdc or less and the
cold in-rush current handling capacity should be 500 mA max and the steady state value should
be 50 mA max. Some of these outputs will also be used as part of the System Configuration
Pins – see note 17 and Attachment 1-4A.
31. These two pins are cross coupled with the corresponding pins on the other SDU in a dual
system. That is SDU#1 MP09E is connected to SDU#2 MP09F and SDU#1 MP09F is
connected to SDU#2 MP09E. In addition a switch closure to airframe dc ground, defined as 0
±3 Vdc, can also be wire OR-ed with either SDU’s Dual System Disable Select and this switch
closure should disable that SDU and hence the other SDU becomes master.
32. This input is defined in ARINC Characteristic 741, Part 1.
33. The protocol used on these interfaces is manufacturer specific. The length of the cable
between the SDU and SCM should be no more than 10 m. The current on the SCM’s power
and power return lines should be limited by the SDU to no more than 300 mA. The choice of
SCM and SDU power values is manufacturer specific but they should be a value in the range
8-15 V. Furthermore the SCM should not be damaged by dc power values of up to 18 Vdc, in
case one manufacturer’s SCM is accidentally connected to another manufacturer’s SDU.
34. Fiber optic contacts are bi-directional.
35. Screen twisted triple.
36. The electrical characteristics should be as in Note 30. The functionality is manufacturer
specific.
37. Refer to Section 3.4.2.1.3, ORT items C1 and C2, regarding actual operating speed of these
interfaces.
 ARINC CHARACTERISTIC 781 – Page 113

ATTACHMENT 1-4A
SYSTEM CONFIGURATION PINS DEFINITION AND INTERPRETATION

1.0 INTRODUCTION
1.1 Pins Used for Programming
The following 20 rear connector pins should be used for configuration
programming:
• Configuration Pin #1 - TP3D (note that this pin is a 0 V output from the
SDU).
• Configuration Pin #2 - TP3E
• Configuration Pin #3 - TP3F
• Configuration Pin #4 - TP3G
• Configuration Pin #5 - TP4D
• Configuration Pin #6 - TP4E
• Configuration Pin #7 - TP4F
• Configuration Pin #8 - TP4G
• Configuration Pin #9 - TP5D
• Configuration Pin #10 - TP5E
• Configuration Pin #11 - TP5F
• Configuration Pin #12 - TP5G
• Configuration Pin #13 - TP6D
• Configuration Pin #14 - TP6E
• Configuration Pin #15 - TP6F
• Configuration Pin #16 - TP6G
• Configuration Pin #17 - TP7D
• Configuration Pin #18 - TP7E
• Configuration Pin #19 - TP7F
• Configuration Pin #20 - TP7G
Configuration Pins #1 and #2 are used for determining if an external HPA is fitted.
Configuration Pins #3 through #20 are implemented (electrically) in the same way
and they use ‘multiplexed pin programming’, that is where each input pin can be
connected to one of the seven service availability discretes or left not connected.
Hence each of these input pin can have 8 possible states and thus, for example,
can indicate 3 independent binary configuration options.
The following discrete outputs provide the multiplexed matrix select strapping:
• Service availability discrete #1 (MP11E)
• Service availability discrete #2 (MP11F)
• Service availability discrete #3 (MP12E)
• Service availability discrete #4 (MP12F)
• Service availability discrete #5 (MP13E)
• Service availability discrete #6 (MP13F)
• Service availability discrete #7 (MP14E)
ARINC CHARACTERISTIC 781 – Page 114

ATTACHMENT 1-4A
SYSTEM CONFIGURATION PINS DEFINITION AND INTERPRETATION

Mandatory Configuration Pins

Pins TP3D and TP3E should be used on all aircraft installations since they may
be used by SDU manufacturers as a hardware-implemented safety override to
force the internal HPA function into low power mode when connected to an
external HPA.
Pin TP3F should be used on all aircraft installations since it indicates that the
number of all configuration pins (excluding TP3D) including the parity pin itself
connected to a service availability discrete (or TP3D) is odd.
Pin TP3G should be used on all aircraft installations since one of its functions is to
indicate whether all other configuration pins (excluding TP3D, TP3E, TP3F,
TP3G, and TP4D) should be used by the SDU.
Pin TP4D should be used on all aircraft installations since it indicates the SDU
number (1 or 2).
Optional Configuration Pins
All other configurations pins are optional and will not be used by the SDU if TP3G
is connected appropriately.
1.2 Functions Implemented By Pin Programming
The following provides a brief description of each programmable configuration,
together with the SDU ARINC 600 pin that is used for programming:
TP3D and TP3E
• External HPA installed – Identifies if an external HPA is fitted or not. If an
external HPA is fitted, this can be used to limit the SDU RF output power.
Note that TP3D is a 0 V output from the SDU.
TP3F
• Program Pin Parity concerning pins TP3E, TP3G, TP4D, TP4E, TP4F,
TP4G, TP5D, TP5E, TP5F, TP5G, TP6D, TP6E, TP6F, TP6G, TP7D,
TP7E, TP7F, and TP7G.
TP3G
• SCM Presence – Identifies if a SCM is fitted or not.
• Use other straps – Identifies whether configuration pin, TP4E,
TP4F, TP4G, TP5D, TP5E, TP5F, TP5G, TP6D, TP6E, TP6F, TP6G,
TP7D, TP7E, TP7F, and TP7G should be read or not. If they are not read,
then information for these parameters may be found in the ORT. In all
cases configuration pins TP3D, TP3E, TP3F, TP3G, and TP4D should be
used by the SDU.
• Secure ORT location – Identifies whether the secure ORT is located in the
SDU (and is modifiable or not) or in the SCM.
• User ORT location – Identifies whether the user ORT is located in the
SDU or in the SCM.
 ARINC CHARACTERISTIC 781 – Page 115

ATTACHMENT 1-4A
SYSTEM CONFIGURATION PINS DEFINITION AND INTERPRETATION

Note: Although this pin defines 4 variables, they are not fully
independent. The five most likely combinations have been
defined in the table below.
TP4D
• SDU Number – Identifies the SDU number installed onboard the aircraft.
TP4E
• CCS Presence – Identifies whether or not a CCS is wired to the SDU
CEPT-E1 port.
• CMU #1 Configuration – Identifies if CMUI #1 is installed.
• CMU #2 Configuration – Identifies if CMUI #2 is installed.
TP4F and TP4G
• Antenna Subsystem Configuration – Identifies the antenna subsystem
configuration.
TP5D
• SDU Controller Type – Identifies whether the controller type is ARINC 739
MCDU/SCDU or ARINC 741P2 ATT.2F-42.1 WSC.
• SCDU/WSCI #1 Configuration – Identifies if SCDU/WSCI #1 is installed.
• SCDU/WSCI #2 Configuration – Identifies if SCDU/WSCI #2 is installed.
TP5E
• SCDU/WSCI #3 Configuration – Identifies if SCDU/WSCI #3 is installed.
• ARINC 429 Bus Speed to SCDU/WSCI #1, #2, #3 – Identifies the ARINC
429 Bus Speed to SCDU/WSCI #1, #2, #3.
• Swift64 Activation – Enables the Swift64 functionality.
TP5F
• ISDN #1 Presence – Identifies whether or not this port is wired.
• ISDN #2 Presence – Identifies whether or not this port is wired.
• Ethernet #1 Presence – Identifies whether or not this port is wired.
TP5G
• Ethernet #2 Presence – Identifies whether or not this port is wired.
• Ethernet #3 Presence – Identifies whether or not this port is wired.
• Ethernet #4 Presence – Identifies whether or not this port is wired.
ARINC CHARACTERISTIC 781 – Page 116

ATTACHMENT 1-4A
SYSTEM CONFIGURATION PINS DEFINITION AND INTERPRETATION

TP6D
• WOW logic – Identifies the meaning of the WOW signal received by MP7D
(WOW input) based on a TRUE/FALSE status of pin TP6D:
Signal received by MP7D TP6D Meaning
DC ground Not connected or connected to Aircraft on ground
MP11E or MP11F or MP12E
(WOW True)
Open circuit Not connected or connected to Aircraft in air
MP11E or MP11F or MP12E
(WOW True)
DC ground Connected to MP12F or Aircraft in air
MP13E or MP13F or MP14E
(WOW False)
Open circuit Connected to MP12F or Aircraft on ground
MP13E or MP13F or MP14E
(WOW False)
• SDU Configuration – Identifies whether or not the second SDU is installed.
• Swift Broadband Activation – Enables the Swift Broadband functionality.
TP6E
• WOW Input Presence – Identifies whether or not the MP7D
(WOW input) is wired.
• GNSS frequency check – Identifies whether or not the GNSS frequency
check is implemented, and if so the value of f limit
(1585 MHz or 1605 MHz - see Section 3.1.2.4)
• Swift Broadband Safety Activation – Enables the SwiftBroadband Safety
functionality. (Note: Swift Broadband must already be activated (TP6D).)
TP6F, 6G, 7D, 7E, 7F, 7G
• These pins are spares.
 ARINC CHARACTERISTIC 781 – Page 117

ATTACHMENT 1-4A
SYSTEM CONFIGURATION PINS DEFINITION AND INTERPRETATION

2.0 TP3D AND TP3E: TYPE OF HPA

These pins indicate if an external HPA is connected.
TP3D should be connected to 0 V inside the SDU.
TP3D connected to TP3E in aircraft wiring TP3D not connected to TP3E in aircraft wiring
Meaning External HPA not fitted External HPA fitted

3.0 TP3F: PROGRAM PIN PARITY:

This pin represents the parity concerning pins TP3E, TP3G, TP4D, TP4E, TP4F,
TP4G, TP5D, TP5E, TP5F, TP5G, TP6D, TP6E, TP6F, TP6G, TP7D, TP7E,
TP7F, and TP7G.
TP3F not connected TP3F connected to MP11E
Meaning Number of all other straps (TP3E, TP3G, Number of all other straps (TP3E, TP3G,
TP4D, TP4E, TP4F, TP4G, TP5D, TP5E, TP4D, TP4E, TP4F, TP4G, TP 5D, TP 5E,
TP5F, TP5G, TP6D, TP6E, TP6F, TP6G, TP5F, TP5G, TP6D, TP6E, TP6F, TP6G,
TP7D, TP7E, TP7F, TP7G) connected to a TP7D, TP7E, TP7F, TP7G) connected to a
Service Availability discrete (or TP3D in the Service Availability discrete (or TP3D in the
case of TP3E) is odd. case of TP3E) is even.

Note: A more advanced and robust scheme could be defined for the
parity in the future. Consequently, the SDU should be able to
interpret when TP3F is connected to any service availability
discrete used for strapping (MP11F, MP12E, MP12F, MP13E,
MP13F, and MP14E).
4.0 TP3G, TP4D, TP4E, TP4F, TP4G, TP5D, TP5E, TP5F, TP5G, TP6D, AND TP6E: VARIOUS
FUNCTIONS
Example (for pin TP4E)
If TP4E is not connected then the SDU’s interpretation should be:
• A CCS is not installed, CMU#1 is not installed, and CMU#2 is not installed.
• If TP4E is connected to MP12F then the SDU’s interpretation should be:
• A CCS is installed, CMU#1 is not installed, and CMU#2 is not installed.
 ARINC CHARACTERISTIC 781 – Page 118

ATTACHMENT 1-4A
SYSTEM CONFIGURATION PINS DEFINITION AND INTERPRETATION

Config
Pin not connected MP11E MP11F MP12E MP12F MP13E MP13F MP14E
Inputs

SDU Interpretation of Config Pins When Config Pin Input is Connected to The Selected Service Availability Discrete

TP3G Do not use other Use other Use other Use other Use other Not defined Not defined Not defined
straps – info in straps straps straps straps
ORT
SCM SCM SCM SCM SCM Not defined Not defined Not defined
installed not installed installed not installed installed
Secure ORT in Secure ORT in Secure ORT in Secure ORT in Secure ORT in Not defined Not defined Not defined
SCM SDU SDU SDU SDU
(non-modifiable) (non-modifiable) (modifiable) (modifiable)
User ORT in User ORT in User ORT in User ORT in User ORT in Not defined Not defined Not defined
SCM SDU SCM SDU SCM
TP4D This is SDU1 This is SDU1 This is SDU1 This is SDU1 This is SDU2 This is SDU2 This is SDU2 This is SDU2
Spare 1 Spare 1 Spare 1 Spare 1 Spare 1 Spare 1 Spare 1 Spare 1
Not installed Not installed installed installed Not installed Not installed installed installed
Spare 2 Spare 2 Spare 2 Spare 2 Spare 2 Spare 2 Spare 2 Spare 2
Not installed installed Not installed installed Not installed installed Not installed installed

TP4E CCS CCS CCS CCS CCS CCS CCS CCS

Not Installed Not Installed Not Installed Not Installed Installed Installed Installed Installed
CMU #1 CMU #1 CMU #1 CMU#1 CMU #1 CMU #1 CMU #1 CMU #1
Not Installed Not Installed Installed Installed Not Installed Not Installed Installed Installed
CMU #2 CMU #2 CMU #2 CMU #2 CMU #2 CMU #2 CMU #2 CMU #2
Not Installed Installed Not Installed Installed Not Installed Installed Not Installed Installed
TP5D SDU Controller SDU Controller is SDU Controller is SDU Controller SDU Controller is SDU Controller SDU Controller SDU Controller
is MCDU/SCDU MCDU/SCDU MCDU/SCDU is MCDU/SCDU WSCI is WSCI is WSCI is WSCI
SCDU#1 SCDU#1 SCDU#1 SCDU#1 WSCI#1 WSCI#1 Not WSCI#1 WSCI#1
Not Installed Not Installed Installed Installed Not Installed Installed Installed Installed
SCDU#2 SCDU#2 Installed SCDU#2 SCDU#2 WSCI#2 WSCI#2 WSCI#2 WSCI#2
Not Installed Not Installed Installed Not Installed Installed Not Installed Installed
TP5E SCDU/WSCI#3 SCDU/WSCI#3 SCDU/WSCI#3 SCDU/WSCI#3 SCDU/WSCI#3 SCDU/WSCI#3 SCDU/WSCI#3 SCDU/WSCI#3
Not Installed Not Installed Not Installed Not Installed Installed Installed Installed Installed
Low Speed Low Speed High Speed High Speed Low Speed Low Speed High Speed High Speed
ARINC 429 Bus ARINC 429 Bus ARINC 429 Bus to ARINC 429 Bus ARINC 429 Bus ARINC 429 Bus ARINC 429 Bus ARINC 429 Bus
to SCDU/WSCI to SCDU/WSCI SCDU/WSCI to SCDU/WSCI to SCDU/WSCI to SCDU/WSCI to SCDU/WSCI to SCDU/WSCI
#1,#2,#3 #1,#2,#3 #1,#2,#3 #1,#2,#3 #1,#2,#3 #1,#2,#3 #1,#2,#3 #1,#2,#3
Swift64 Swift64 Swift64 Swift64 Swift64 disabled Swift64 Swift64 Swift64
disabled enabled disabled enabled enabled disabled enabled
TP5F ISDN #1 ISDN #1 ISDN #1 ISDN #1 ISDN #1 ISDN #1 ISDN #1 ISDN #1
Not Wired Not Wired Not Wired Not Wired Wired Wired Wired Wired
ISDN #2 ISDN #2 ISDN #2 ISDN #2 ISDN #2 ISDN #2 ISDN #2 ISDN #2
Not Wired Not Wired Wired Wired Not Wired Not Wired Wired Wired
Ethernet #1 Ethernet #1 Ethernet #1 Ethernet #1 Ethernet #1 Ethernet #1 Ethernet #1 Ethernet #1
Not Wired Wired Not Wired Wired Not Wired Wired Not Wired Wired
TP5G Ethernet #2 Ethernet #2 Ethernet #2 Ethernet #2 Ethernet #2 Ethernet #2 Ethernet #2 Ethernet #2
Not Wired Not Wired Not Wired Not Wired Wired Wired Wired Wired
Ethernet #3 Ethernet #3 Ethernet #3 Ethernet #3 Ethernet #3 Ethernet #3 Ethernet #3 Ethernet #3
Not Wired Not Wired Wired Wired Not Wired Not Wired Wired Wired
Ethernet #4 Ethernet #4 Ethernet #4 Ethernet #4 Ethernet #4 Ethernet #4 Ethernet #4 Ethernet #4
Not Wired Wired Not Wired Wired Not Wired Wired Not Wired Wired
TP6D WOW True WOW True WOW True WOW True WOW False WOW False WOW False WOW False
2nd SDU 2nd SDU 2nd SDU 2nd SDU 2nd SDU 2nd SDU 2nd SDU 2nd SDU
Not Installed Not Installed Installed Installed Not Installed Not Installed Installed Installed
Swift Broadband Swift Broadband Swift Broadband Swift Broadband Swift Broadband Swift Broadband Swift Broadband Swift Broadband
Disabled Enabled Disabled Enabled Disabled Enabled Disabled Enabled
TP6E WOW Not Wired WOW Not Wired WOW Not Wired WOW Not Wired WOW Wired WOW Wired WOW Wired WOW Wired
No GNSS GNSS frequency GNSS frequency GNSS frequency No GNSS GNSS GNSS frequency GNSS
frequency check with f limit check with f limit check with f limit frequency check frequency check check with f limit frequency check
check =1585MHz =1605MHz =1585MHz with f limit =1605MHz with f limit
=1585MHz =1585MHz
Swift Broadband Swift Broadband Swift Broadband Swift Broadband Swift Broadband Swift Broadband Swift Broadband Swift Broadband
Safety Disabled Safety Enabled Safety Disabled Safety Enabled Safety Disabled Safety Enabled Safety Disabled Safety Enabled
 ARINC CHARACTERISTIC 781 – Page 119

ATTACHMENT 1-4A
SYSTEM CONFIGURATION PINS DEFINITION AND INTERPRETATION

5.0 TP4F AND TP4G: ANTENNA SUBSYSTEM CONFIGURATION

These pins are used to indicate one of 64 possible antenna configurations.
Configuration Connect TP4F Connect TP4G
Antenna Subsystem Configuration
Number to: to:
1 ARINC 781 HGA Open Open
2 ARINC 781 IGA Open MP11E
3 LGA + LGA HPA Open MP11F
4 ARINC 741 TOP BSU + TOP HGA + HGA HPA Open MP12E
5 ARINC 741 PORT BSU + PORT HGA + Open MP12F
STARBOARD BSU + STARBOARD HGA + HGA
HPA + HPR
6 Reserved for future use. Open MP13E
7 Reserved for future use. Open MP13F
8 Reserved for manufacturer. Open MP14E
9 Reserved for future use. MP11E Open
10 Reserved for future use. MP11E MP11E
11 Reserved for future use. MP11E MP11F
12 Reserved for future use. MP11E MP12E
13 Reserved for future use. MP11E MP12F
14 Reserved for future use. MP11E MP13E
15 Reserved for future use. MP11E MP13F
16 Reserved for future use. MP11E MP14E
17 Reserved for future use. MP11F Open
18 Reserved for future use. MP11F MP11E
19 Reserved for future use. MP11F MP11F
20 Reserved for future use. MP11F MP12E
21 Reserved for future use. MP11F MP12F
22 Reserved for future use. MP11F MP13E
23 Reserved for future use. MP11F MP13F
24 Reserved for future use. MP11F MP14E
25 Reserved for future use. MP12E Open
26 Reserved for future use. MP12E MP11E
27 Reserved for future use. MP12E MP11F
28 Reserved for future use. MP12E MP12E
29 Reserved for future use. MP12E MP12F
30 Reserved for future use. MP12E MP13E
31 Reserved for future use. MP12E MP13F
32 Reserved for future use. MP12E MP14E
33 Reserved for future use. MP12F Open
34 Reserved for future use. MP12F MP11E
35 Reserved for future use. MP12F MP11F
36 Reserved for future use. MP12F MP12E
37 Reserved for future use. MP12F MP12F
38 Reserved for future use. MP12F MP13E
39 Reserved for future use. MP12F MP13F
40 Reserved for future use. MP12F MP14E
41 Reserved for future use. MP13E Open
42 Reserved for future use. MP13E MP11E
43 Reserved for future use. MP13E MP11F
44 Reserved for future use. MP13E MP12E
ARINC CHARACTERISTIC 781 – Page 120

ATTACHMENT 1-4A
SYSTEM CONFIGURATION PINS DEFINITION AND INTERPRETATION

Configuration Connect TP4F Connect TP4G

Antenna Subsystem Configuration
Number to: to:
45 Reserved for future use. MP13E MP12F
46 Reserved for future use. MP13E MP13E
47 Reserved for future use. MP13E MP13F
48 Reserved for future use. MP13E MP14E
49 Reserved for future use. MP13F Open
50 Reserved for future use. MP13F MP11E
51 Reserved for future use. MP13F MP11F
52 Reserved for future use. MP13F MP12E
53 Reserved for future use. MP13F MP12F
54 Reserved for future use. MP13F MP13E
55 Reserved for future use. MP13F MP13F
56 Reserved for future use. MP13F MP14E
57 Reserved for future use. MP14E Open
58 Reserved for future use. MP14E MP11E
59 Reserved for future use. MP14E MP11F
60 Reserved for future use. MP14E MP12E
61 Reserved for future use. MP14E MP12F
62 Reserved for future use. MP14E MP13E
63 Reserved for future use. MP14E MP13F
64 Reserved for future use. MP14E MP14E

6.0 TP6F, TP6G, TP7D, TP7E, TP7F, AND TP7G: SPARES

These pins are reserved for future growth, and will be implemented using the same
multiplexed scheme as defined for TP3F, TP3G, TP4D, TP4E, TP4F, TP4G, TP5D,
TP5E, TP5F, TP5G, TP6D, and TP6E.
 ARINC CHARACTERISTIC 781 – Page 121

ATTACHMENT 1-5
SDU FORM FACTOR

SIZE 6 MCU
#2 Shell Connector

A B C D E F G H J

1 1

5 5

7 7

A B C D E F G H J

1 A B C D E F G H J

9
1
0
1
1
1
2
1
1 2 3 2 3
1
4 3 4 1 4
1
1T 5 2T

Index code
81 (5,2,2)

9 8
2 1

11 10

4 3

12
5

7 6

For the index code pins above, the dark color represents the post.
 ARINC CHARACTERISTIC 781 – Page 122

ATTACHMENT 1-5A
SDU TOP PLUG CONNECTOR LAYOUT

A B C D E F G H J K

RF TX

Pin 71

To HPA, DLNA, or ELGA

ATE ATE ATE ATE ATE ATE ATE ATE ATE ATE
1
Pin 1 Pin 2 Pin 3 Pin 4 Pin 5 Pin 6 Pin 7 Pin 8 Pin 9 Pin 10

ATE ATE ATE ATE ATE ATE ATE ATE ATE ATE
2
Pin 11 Pin1 2 Pin 13 Pin 14 Pin 15 Pin 16 Pin 17 Pin 18 Pin 19 Pin 20

Ethernet 1 Ethernet 1 ISDN 1 ISDN 1

from SDU from User Empty Config Config Config Config from SDU from User
3 SPARE
to User to SDU Cavity Pin 1 Pin 2 Pin 3 Pin 4 To User to SDU
+ + + +

Ethernet 1 Ethernet 1 ISDN 1 ISDN 1

from User from SDU Empty Config Config Config Config from User from SDU
4 SPARE
to SDU to User Cavity Pin 5 Pin 6 Pin 7 Pin 8 To SDU to User
- - - -

Empty Empty Empty Config Config Config Config

5 SPARE SPARE SPARE
Cavity Cavity Cavity Pin 9 Pin 10 Pin 11 Pin 12

Ethernet 2 Ethernet 2 ISDN 2 ISDN 2

Config Config Config Config
from SDU from User Empty from SDU from User
6 Pin 13 Pin 14 Pin 15 Pin 16 SPARE
to User to SDU Cavity to User to SDU
[SPARE] [SPARE] [SPARE] [SPARE]
+ + + +
Ethernet 2 Ethernet 2 ISDN 2 ISDN 2
Config Config Config Config
from User from SDU Empty from User from SDU
7 Pin 17 Pin 18 Pin 19 Pin 20 SPARE
to SDU to User Cavity to SDU to User
[SPARE] [SPARE] [SPARE] [SPARE]
- - - -
 ARINC CHARACTERISTIC 781 - Page 123
ATTACHMENT 1-5B
SDU MIDDLE PLUG CONNECTOR LAYOUT

A B C D E F G H J K
Call Resv Ext Call
Data from Data from Multi-Control Multi-Control Data from Data from
Place/End SCM Pwr Reset Place/End
1 MCDU 1 MCDU 1 Output Output MCDU 2 MCDU 2
Discrete +8 to +15V Discrete Discrete
A B A B A B
Input 1 Input Input 2
Rsvd
Data from Data from BITE BITE
Cockpit Voice Mfr - Specific Cockpit Voice Data from Data from
Primary Primary SCM Pwr Input Input
2 Chime Signal 0-28V Chime Signal Secondary Secondary
IRS/GNSS IRS/GNSS Return 0V From HPA From HPA
Contact 1 Discrete Contact 2 IRS A IRS B
A B A B
Output
Data from Data from Cockpit Voice SDU Data Spare Spare Cockpit Voice Data from Data from
3 CMU 1 CMU 1 Call Light to SCM Discrete Discrete SPARE Call Light CMU 2 CMU 2
A B Output 1 A Output Input Output 2 A B
Cockpit Cockpit Cockpit Cockpit
Cockpit Voice SDU Data Spare Spare Cockpit Voice
Audio Audio Audio Audio
4 Mic-On to SCM Discrete Discrete SPARE Mic-On
Input 1 Input 1 Input 2 Input 2
Input 1 B Output Input Input 2
High Low High Low
Cockpit Cockpit Cockpit Voice Spare Spare Cockpit Cockpit
SCM Data Spare Spare
Audio Audio Go Ahead ARINC ARINC Audio Audio
5 to SDU Discrete Discrete
Output 1 Output 1 Chime 429 Output 429 Output Output 2 Output 2
A Output Input
High Low Reset 1 A B High Low
Ethernet 5 Ethernet 5 Spare Spare
Spare Spare Spare SCM Data Data from Data from
10 Ethernet T 10 Ethernet T ARINC ARINC
6 Discrete Discrete Discrete to SDU GNSS to GNSS to
(Spare) from (Spare) from 429 Input 429 Input
Input Input Input B SDU A SDU B
SDU to User+ SDU to User- A B
Ethernet 5 Ethernet 5 Spare Spare Data to Data to
Spare
AES ID AES ID WOW 10 Ethernet T 10 Ethernet T ARINC ARINC CMU CMU
7 Discrete
Input A Input B Input 1 (Spare) from (Spare) from 429 Output 429 Output 1&2 1&2
Input
User to SDU+ User to SDU- A B A B
BITE BITE BITE BITE
Data from Data from Data Loader Data to Data to
Input Input TX Mute Input Input
8 CFDS CFDS Link CFDS CFDS
Top/Port Top/Port Input STBD BSU STBD BSU
A B A A B
BSU/Ant A BSU/Ant B A B
From From Crosstalk Crosstalk Dual System Dual System Crosstalk Crosstalk
To Airborne To Airborne
Airborne Airborne from other from other Select Disable to other to other
9 Data Loader Data Loader
Data Loader Data Loader SDU SDU Discrete Discrete SDU SDU
A B
A B A B I/O I/O A B
STBD STBD Data to Data to
Data from Data from Port BSU Port BSU LGA LNA BITE
BSU BSU MCDU MCDU
10 MCDU 3 MCDU 3 HPA Mute HPA Mute On/Off Input from
HPA Mute HPA Mute 1, 2, 3 1, 2, 3
A B Input A Input B Control LGA LNA
Input A Input B A B
Cabin Cabin Cabin Cabin
Service Service
CEPT-E1 CEPT-E1 CEPT-E1 CEPT-E1
POTS 1 POTS 1 Availability Availability POTS 2 POTS 2
11 Data Data Data Data
A B Discretes Discretes A B
Output Output input Input
1 2
A B A B
Service Service
Availability Availability
12
Discretes Discretes
3 4
1 2 2 3
Service Service
Ethernet 3 Ethernet 3 Ethernet 4 Ethernet 4
Availability Availability
13 from SDU from User from User from SDU
Discretes Discretes
to User + to SDU + to SDU + to User -
5 6
4 3 Service Service 1 4
Ethernet 3 Ethernet 3 Availability Availability Ethernet 4 Ethernet 4
14 from SDU from User
from User from SDU Discretes Discretes
to SDU - to User – 7 8 to User + to SDU –

Service Service
Availability Availability
15 1T 2T
Discretes Discretes
9 10
ARINC CHARACTERISTIC 781 - Page 124

ATTACHMENT 1-5C
SDU BOTTOM PLUG CONNECTOR LAYOUT

9 8
2 1

28V 115V
HOT Ethernet 7 Ethernet 6 COLD
11 10

4 3
Ethernet 9 Ethernet 8
28V CHASSIS
GND GROUND
12
Ethernet 10

115v 5
HOT

Antenna
Control
DLNA (CSDU
only)

7 6
 ARINC CHARACTERISTIC 781 – Page 125
ATTACHMENT 1-6
SDU CONFIGURATION MODULE FORM FACTOR

Label Top Surface

4 off fixing holes “MEMORY DEVICE”
Dia 0.125 (3.2)

0.106 (2.7)
MAX

M3 Earth stud

4.0 3.0
(101.6) 3.75 3.5 3.25 (76.2) 15 way D type male with
(nom) (95.25) (88.9) (82.55) (nom) locking screws

0.25 (6.35)
0.25 (6.35)

0.6 (15.24)

3.3 (83.82)

3.9 (99.06)

1.0 (25.4)

4.5 (114.3)
(nom)

Note:
1. All dimensions in inches (mm) unless otherwise stated. Tolerance of
fixing centers ±0.004 (±0.1).
Tolerance of fixing holes +0.004, -0.0 (+0.1, -0.0).
All other tolerances ±0.015 (±0.4).
Fixing holes are designed for either M3 or 4-40 UNC screws. Earth
stud is metric.
ARINC CHARACTERISTIC 781 – Page 126

ATTACHMENT 1-6A
SDU CONFIGURATION MODULE CONNECTOR LAYOUT

SCM Connector is 15-pin D-type male.

Reserved Power
Data to Data to Data from Data from RS-232 Spare Chassis Input +8 to
SDU A SDU B SDU A SDU B Gnd Ground +15V

1 8

Reserved Reserved Reserved Reserved

Enable 0V strap Spare RS-232 RS-232 Spare Power
RS-232 output Tx Rx Return 0V

9 15

• 1 Data to SDU A (RS-422)

• 2 Data to SDU B (RS-422)
• 3 Data from SDU A (RS-422)
• 4 Data from SDU B (RS-422)
• 5 Reserved – RS-232 Gnd Used for shop loading
• 6 Spare
• 7 Chassis Ground
• 8 Power Input +8 to +15V
• 9 Reserved – Enable RS-232* Used for shop loading
• 10 Reserved – 0V strap output Used for shop loading
• 11 Spare
• 12 Reserved – RS-232 Tx Used for shop loading
• 13 Reserved – RS-232 Rx Used for shop loading
• 14 Spare
• 15 Power Return 0V

* To be used for shop loading of ORT (open = normal operation,

connect to pin 10 = shop load and allow use of RS-232 port)
 ARINC CHARACTERISTIC 781 – Page 127
ATTACHMENT 1-7A
SMALL FLANGE MOUNT HPA FORM FACTOR
ARINC CHARACTERISTIC 781 – Page 128

ATTACHMENT 1-7A
SMALL FLANGE MOUNT HPA FORM FACTOR

Notes:
1. Small form factor FMHPA may be mounted in any orientation using
the mounting surface defined.
2. Possible alternative cooling spud orientation to accommodate
installation constraints.
3. The flange-mount HPA will have three connectors, located as shown:
a. J1 - Power/Control MIL-DTL-38999 Series III Insert Arrangement
17-26
b. J2 - RF Input; TNC Female
c. J3 - RF Output; N Type Female
4. Air filter/mesh may be necessary to prevent debris interference in
applications with drawn airflow.
 ARINC CHARACTERISTIC 781 – Page 129
ATTACHMENT 1-7B
LARGE FLANGE MOUNT HPA FORM FACTOR

Notes:
1. The mounting configuration is critical to operation in conditions of loss
of cooling (See Section 2.2.2.3). The natural air flow shown
represents that of a horizontally mounted FMHPA. Alternative
mounting configurations should be discussed with FMHPA
manufacturers.
2. Key features are the four mounting holes and the locations of the
connectors and airflow adaptor. Clear and unobstructed access to
mounting fasteners should be provided to facilitate aircraft installation.
ARINC CHARACTERISTIC 781 – Page 130

ATTACHMENT 1-7B
LARGE FLANGE MOUNT HPA FORM FACTOR

The envelope shown encompasses any mounting feet protruding from

the main body of the unit.
3. A clearance of approximately 1” on top, bottom and sides of the large
form factor HPA is recommended to facilitate natural cooling
particularly in ‘loss of cooling mode’. See Section 2.2.2.3. Minor
structure intrusions into this clearance may be accommodated with
the agreement of both FMHPA manufacturer and installer
4. The flange-mount HPA has three connectors, located as shown:
a. J1 - Power/Control MIL-DTL-38999 Series III Insert Arrangement
17-26
b. J2 - RF Input; TNC Female
c. J3 - RF Output; N Type Female
5. Air filter/mesh may be necessary to prevent debris interference in
applications with drawn airflow.
 ARINC CHARACTERISTIC 781 – Page 131
ATTACHMENT 1-7C
FLANGE MOUNT HPA CONNECTOR LAYOUT

MIL-DTL-38999 Series III Insert Arrangement 17-26

External Flange Mounted HPA Connector Pin Layout:
Pin Note Signal Description
A * HPA BITE A ARINC 429 from HPA
B * HPA BITE B ARINC 429 from HPA
C RS422 RXD A Serial data to HPA +
D RS422 RXD B Serial data to HPA -
E RS422 TXD A Serial data from HPA +
F RS422 TXD B Serial data from HPA -
G SPARE SPARE
H SPARE SPARE
J * Chassis Ground Chassis Ground
K SPARE SPARE
L SPARE SPARE
M Discrete BITE #1 Discrete BITE #1 from HPA
N Discrete BITE #2 Discrete BITE #2 from HPA
P * HPA Control A ARINC 429 to HPA
R * HPA Control B ARINC 429 to HPA
S * HPA Control Shield Shield For ARINC 429
T * HPA BITE Shield Shield For ARINC 429
U RS422 Shield RS422 Shield
V SPARE SPARE
W SPARE SPARE
X * 115 Vac Hot Aircraft ac power
Y * 115 Vac Return Aircraft ac power
Z SPARE SPARE
A Discrete BITE #3 Discrete BITE #3 from HPA
B ATE Pin Manufacturer-Specific
C SPARE SPARE

Note: * Normally wired in an aircraft

Note that the pins in the connector are believed to not have sufficient
current carrying capability for 28 Vdc.
ARINC CHARACTERISTIC 781 – Page 132
ATTACHMENT 1-8
DIPLEXER/LOW NOISE AMPLIFIER FORM FACTOR

Figure 1 – Type D – Modified Type A DLNA Outline

 ARINC CHARACTERISTIC 781 - Page 133
ATTACHMENT 1-8
DIPLEXER/LOW NOISE AMPLIFIER FORM FACTOR

Figure 2 – Type F DLNA Outline

ARINC CHARACTERISTIC 781 – Page 134
ATTACHMENT 1-8
DIPLEXER/LOW NOISE AMPLIFIER FORM FACTOR

Pin Description
Pin A Chassis Ground
Pin B LNA Control
Pin C Future Spare
Pin D Future Spare
Pin E 115 Vac Cold
Pin F 115 Vac Hot
Pin G +28 Vdc Hot
Pin H LNA BITE
Pin J LNA BITE Ground
Pin K +28 Vdc Return

H A B

G K J C

F E D

The DLNA connector is MS3470L1210P or equivalent, which mates with

MS3476L1210S or equivalent.
 ARINC CHARACTERISTIC 781 – Page 135
ATTACHMENT 1-9
ANTENNA COVERAGE

90°

-90°
ARINC CHARACTERISTIC 781 – Page 136

ATTACHMENT 1-10
HIGH GAIN AND INTERMEDIATE GAIN TOP MOUNT ANTENNA FOOTPRINT
MAXIMUM DIMENSIONAL OUTLINE

HGA & IGA maximum length: 43" (1092.2 mm)

5.91" [MIN]
(150.0 mm)

2.95"
KEEP-AWAY ZONE (75.0 mm)
HGA & IGA:
maximum width
14.4" 2.95" [MIN]
(365.8 mm) (75.0 mm)

ANTENNA AFT END

FORE AFT

Notes:
1. The Antenna should have a removable aft radome fairing to allow
access to connectors, cables and aircraft skin penetration area.
2. Connecting Control and RF cables should be routed through a feed-
through skin penetration hole on the aircraft fuselage, which can be
anywhere within the “keep away zone.”
3. The antenna should be installable or removable while the aircraft
cable installation remains in place.
4. The cable routing design should allow the cables to be routed from
the skin penetration area to the antenna bulkhead connectors.
5. Sufficient access volume should be provided for cable routing and
hand/tool access to prevent over bending the cabling beyond its bend
allowances. As general guidance, coaxial cable should not be bent at
a radius of less than 10 times its diameter for permanent installation,
or less than 5 times its diameter during the connecting (insertion or
removal) process.
6. Should a tool be required for cable installation, such tool should be
clearly identified in the manufacturer’s installation and maintenance
procedures, and be supplied upon request by the antenna
manufacturer.
7. Antenna adapter plate design may need to be customized to
accommodate the keep-away zone requirements.
 ARINC CHARACTERISTIC 781 – Page 137
ATTACHMENT 1-10A
ANTENNA COAXIAL CABLE INTERFACE

RADOME / REMOVABLE FAIRING

BASEPLATE

RF CONNECTOR SINGLE ADAPTER

PLATE FUSELAGE
CONTROL CONNECTOR FEED-THRU
PENETRATION
(RF & CONTROL)
ARINC CHARACTERISTIC 781 – Page 138

ATTACHMENT 1-11
NO LONGER USED

This section deleted by Supplement 5

 ARINC CHARACTERISTIC 781 – Page 139
ATTACHMENT 1-12
HIGH GAIN AND INTERMEDIATE GAIN ANTENNA CONTROL CONNECTOR LAYOUT

14 1

13 2

15
12 3
21

11 16 4
20
22

17
10 19 5

18
9 6

8 7

HGA and IGA Connector PIN Layout

HGA and IGA pin assignments should conform to the table below.
HGA and IGA Connector Pin Assignments
PIN No SIGNAL DESCRIPTION
1 +28 Vdc Aircraft dc Power
2 28 Vdc RTN Aircraft dc Power
3 Antenna BITE A ARINC 429 from antenna
4 Antenna BITE Shield Screen for ARINC 429
5 Antenna BITE B ARINC 429 from antenna
6 Antenna Control A ARINC 429 to antenna
7 Antenna Control Shield Screen for ARINC429
8 Antenna Control B ARINC 429 to antenna
9 DLNA BITE BITE from DLNA
10 DLNA Shield Screen/RTN for DLNA
11 DLNA CTL DLNA on/off control from antenna
1
12 Serial Shield Serial Screen/GND
1
13 RS-422 RX A Serial data to antenna +
1
14 RS-422 RX B Serial data to antenna -
1
15 RS-422 TX A Serial data from antenna +
1
16 RS-422 TX B Serial data from antenna -
17 ATE Pin Manufacturer Specific
18 115 Vac Hot Aircraft ac power
19 115 Vac Return Aircraft ac power
20 -- Spare
21 -- Spare
22 Chassis Ground Chassis Ground

Connector Type - 13-35 insert of the MIL-DTL-38999 Series III family

Note 1: These pins may be used to provide manufacturer-specific
extended BITE/troubleshooting/software upload.
ARINC CHARACTERISTIC 781 – Page 140

ATTACHMENT 2
ARINC 429 LABELS AND WORD FORMATS USED IN THE AVIATION SATELLITE COMMUNICATIONS SYSTEM

Figure 1 - Deleted
Figure 2 - Deleted
Figure 3 - Deleted
 ARINC CHARACTERISTIC 781 – Page 141
ATTACHMENT 2
ARINC 429 LABELS AND WORD FORMATS USED IN THE AVIATION SATELLITE COMMUNICATIONS SYSTEM

BIT 32 31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1
Label 144
Function P SSM Undefined Reserved DIS SDI
[23] [4]
0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 1 0 0 1 1 0
4 4 1

Sign/Status Matrix [19] [20] [21]

Bits Coding
31 30
0 0 Failure Warning
0 1 No Computed Data
1 0 Functional Test
1 1 Normal Operation

Discretes [22] Values

BIT Description 0 1
11 Antenna System Select LGA HGA/IGA
12 HPR Present No Yes

SDI Code [35]

Bits Coding
10 9
0 0 All Call
0 1 Port/Top
1 0 Starboard
1 1 Reserved

See Note 49 for reserved labels on this bus

Figure 4 – Antenna Control Word - ARINC 781 SDU to ARINC 741/781 Antenna
ARINC CHARACTERISTIC 781 – Page 142

ATTACHMENT 2
ARINC 429 LABELS AND WORD FORMATS USED IN THE AVIATION SATELLITE COMMUNICATIONS SYSTEM

BIT 32 31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1
E S
G
Q p
a Label 144
Function P SSM I a Discretes Gain SDI
I [4]
D r
n
[43] e
1 0 0 0 0 0 0 0 0 0 0 0 1 0 0 1 0 0 1 1 0
4 4 1

Sign/Status Matrix [17]

Bits
Coding
31 30
0 0 Failure Warning
0 1 No Computed Data
1 0 Functional Test
1 1 Normal Operation

Discretes Values
Bit Description 0 1
18 Antenna Location Top Reserved
19 Antenna Type HGA IGA
20 Reserved
21 Reserved
22 Reserved
23 Reserved
24 HGA/IGA LNA Status Disabled Enabled
25 Reserved
26 Tracking Mode Open Reserved

Note: Tracking mode is always set to 0.

Antenna Tx Gain [36]
Bits 28 BITS 15-11 Coding
0 00000 0 dBic
1 00000 0.5 dBic
0 00001 1 dBic
Etc. Etc.
1 11111 31.5 dBic

SDI Code [18]

Bits Coding
10 9
0 0 Reserved
0 1 Top
1 0 Reserved
1 1 Reserved

Figure 5 – Antenna Status Word - ARINC 781 Antenna to ARINC 741/781 SDU
 ARINC CHARACTERISTIC 781 – Page 143
ATTACHMENT 2
ARINC 429 LABELS AND WORD FORMATS USED IN THE AVIATION SATELLITE COMMUNICATIONS SYSTEM

BIT 32 31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1
Label 350
Function P SSM C Undefined Discretes SDI
[4]
0 0 0 0 0 0 0 1 0 0 0 1 0 1 1 1
0 5 3

Sign/Status Matrix [41]

Bits
Coding
31 30
0 0 Failure Warning
0 1 No Computed Data
1 0 Functional Test
1 1 Normal Operation

Discretes [41] Values

Bit Description 0 1 SDI Code [18]
Bits
11 Class 1 HGA/IGA Failure [14] OK Failed Coding
12 Reserved for A741 compatibility 10 9
13 Control Bus Input OK Inactive 0 0 Reserved
14 Internal RAM [14] OK Failed 0 1 Top
15 Internal ROM [14] OK Failed 1 0 Reserved
16 Power Supply Function [14] OK Failed 1 1 Reserved
17 Reserved for A741 compatibility
18 Beam Steering Function [46] [14] OK Failed
19 Antenna Array Function [14] OK Failed
20 LNA/Diplexer [38] [40] OK Failed
21 Reserved
22 Class 1 Temperature [14] OK Over
23 Class 3 Temperature [14] OK Warning
24 Antenna Reset [44] OK Occurred
25 Class 3 HGA/IGA Failure [14] OK Warning

Configuration Data Values

Bit Description 0 1
29 Antenna configuration data being sent [45] Not in progress In progress

Figure 6 – Antenna Maintenance Word - ARINC 781 Antenna to ARINC 741/781 SDU
ARINC CHARACTERISTIC 781 – Page 144

ATTACHMENT 2
ARINC 429 LABELS AND WORD FORMATS USED IN THE AVIATION SATELLITE COMMUNICATIONS SYSTEM

BIT 32 31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1
(MSB) Azimuth (LSB) (MSB) Elevation (LSB) Label 152
Function P SSM
[25] [24] [26] [32]
0 1 0 1 0 1 1 0
2 5 1

Sign/Status Matrix
Bits
Coding
31 30
0 0 Failure Warning
0 1 No Computed Data
1 0 Functional Test
1 1 Normal Operation

See Note 49 for reserved labels on this bus.

Figure 7 – Open Loop Steering Word - ARINC 781 SDU to ARINC 741/781 Antenna
 ARINC CHARACTERISTIC 781 – Page 145
ATTACHMENT 2
ARINC 429 LABELS AND WORD FORMATS USED IN THE AVIATION SATELLITE COMMUNICATIONS SYSTEM

32 31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1
P SSM A16-----------------------------------------------------------------------------------------------A1 Octal Label
MSB 220
[50]
0 0 0 0 1 0 0 1

Bit Function Coding Notes

1 Label 1
2 . 2 0
3 . 0
4 . 1
5 . 2 0
6 . 0
7 . 0
8 Label 0 0
9 PAD 47
10 . 47
11 . 47
12 . 47
13 PAD 47
14 Swift64 Base Fwd ID (Part 1) A1 (MSB) 48
15 . A2 48
16 . A3 48
17 . A4 48
18 . A5 48
19 . A6 48
20 . A7 48
21 . A8 48
22 . A9 48
23 . A10 48
24 . A11 48
25 . A12 48
26 . A13 48
27 . A14 48
28 . A15 48
29 Swift64 Base Fwd ID (Part 1) A16 48
30 SSM
31 SSM
32 Parity Odd

Sign/Status Matrix (SSM) Definition per ARINC Specification 429 for DISC discrete
data words.
Bits
Meaning
31 30
0 0 Normal Operation
0 1 NCD
1 0 Functional Test (Not Used)
1 1 Failure Warning (Not Used)
Figure 8 – Label 220 Inmarsat Swift64 Base Forward ID Word #1 - (Discrete)
ARINC CHARACTERISTIC 781 – Page 146

ATTACHMENT 2
ARINC 429 LABELS AND WORD FORMATS USED IN THE AVIATION SATELLITE COMMUNICATIONS SYSTEM

32 31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1
P SSM A24------------------------------------------A17 Octal Label
LSB 221
[50]
1 0 0 0 1 0 0 1

Bit Function Coding Notes

1 Label 1
2 . 2 0
3 . 0
4 . 1
5 . 2 0
6 . 0
7 . 0
8 Label 1 1
9 PAD 47
10 . 47
11 . 47
12 PAD 47
13 Swift64 Base Fwd ID (Part 2) A17 48
14 . A18 48
15 . A19 48
16 . A20 48
17 . A21 48
18 . A22 48
19 . A23 48
20 Swift64 Base Fwd ID (Part 2) A24 (LSB) 48
21 PAD 47
22 . 47
23 . 47
24 . 47
25 . 47
26 . 47
27 . 47
28 . 47
29 PAD 47
30 SSM
31 SSM
32 Parity Odd
Sign/Status Matrix (SSM) Definition per ARINC Specification 429 for DISC discrete
data words.
Bits
Meaning
31 30
0 0 Normal Operation
0 1 NCD
1 0 Functional Test (Not Used)
1 1 Failure Warning (Not Used)

Figure 9 – Label 221 Inmarsat 24-Bit Swift64 Base Forward ID Word #2 - (Discrete)
 ARINC CHARACTERISTIC 781 – Page 147
ATTACHMENT 2
ARINC 429 LABELS AND WORD FORMATS USED IN THE AVIATION SATELLITE COMMUNICATIONS SYSTEM

SATCOM AIRFRAME TYPE - LABEL 167 RATE = 1 SEC

PAR SSM PAD AIRFRAME TYPE PAD LABEL
Bit 32 Bits 31-30 Bits 29 – 25 Bits 24 – 11 Bits 10 – 9 Bits 8 – 1
[51]
p ss xxxxx dddcccxbbbaaaa xx xxx xxx xx

Where:
• aaaa = Minor Model (e.g., -400, -800, -500).
• xbbb = Major Model (e.g., 787, 777).
• ccc = Airframe Manufacturer Specific.
• ddd = Airframe Manufacturer Specific.
The following xbbb have been reserved by Boeing:
x bbb Aircraft Type
0 000 Boeing A/C #1
0 001 Boeing A/C #2
0 010 Boeing A/C #3
0 011 Boeing A/C #4
0 100 Boeing A/C #5
0 101 Boeing A/C #6
0 110 Boeing A/C #7
0 111 Boeing A/C #8
1 000 RSV
1 --- RSV
1 111 RSV

Sign/Status Matrix (SSM) Definition per ARINC Specification 429 for discrete data
words.
Bits
Meaning
31 30
0 0 Normal Operation
0 1 NCD
1 0 Functional Test (Not Used)
1 1 Failure Warning (Not Used)

Figure 10 – Aircraft Type Label

 ARINC CHARACTERISTIC 781 – Page 148

ATTACHMENT 2
ARINC 429 LABELS AND WORD FORMATS USED IN THE AVIATION SATELLITE COMMUNICATIONS SYSTEM

BIT 32 31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1
Function P Spare Satellite System Type SDU SAL Label 172
X 0 0 0 0 0 0 0 0 0 0 0 X X X 1 X X X X X X X X 0 1 0 1 1 1 1 0
2 7 1

SDU Equipment Identifier Code: 041 (HEX)

Bit Description Coding
1 Label 172 0
2 . 1
3 . 1
4 . 1
5 . 1
6 . 0
7 . 1
8 Label 172 0
9 SDU SAL ( 307 for SDU #1 or 173 for SDU #2) (MSB) 1 or 0
10 . 1 1
11 . 0 1
12 . 0 1
13 . 0 1
14 . 1 0
15 . 1 1
16 SAL (LSB) 1 1
17 Classic Aero 1
18 Spare 0
19 Iridium X
20 Spare 0
21 Spare 0
22 Spare 0
23 Spare 0
24 Spare 0
25 Spare 0
26 Spare 0
27 Spare 0
28 Spare 0
29 Spare 0
30 Spare 0
31 Spare 0
32 Parity X

See Note 52 for ARINC 761 multi-bearer systems.

Figure 11 – SDU Label 172

 ARINC CHARACTERISTIC 781 – Page 149
ATTACHMENT 2
ARINC 429 LABELS AND WORD FORMATS USED IN THE AVIATION SATELLITE COMMUNICATIONS SYSTEM

Notes
Notes 1-41 are numbered the same as the notes in ARINC 741, Attachment 2.
0. The SDU to/from antenna interface is based on ARINC 741, and supports the following
combinations of equipment:
SDU Antenna
ARINC 781 ARINC 781
ARINC 781 ARINC 741 (top mount or side mount)
ARINC 741 ARINC 781
This attachment specifies the output words from the ARINC 781 SDU and antenna, and these
have been designed to allow ARINC 781 and ARINC 741 equipment to interoperate. For the
definition of output words from ARINC 741 equipment, please refer to ARINC 741. The
antenna does not need to know what type of SDU it is connected to.
1. Not used.
2. Not used.
3. Not used.
4. RATE: 5-10 words per second. This implies that the interval between the start of two words
with the same label number should always be between 100 and 200 ms.
5. Not used.
6. Not used.
7. Not used.
8. Reserved.
9. Not used.
10. Not used.
11. Not used.
12. Not used.
13. Not used.
14. When Bit 11 or 25 is set, bits 14, 15, 16, 18, 19, and 22 are used to provide further detail (if
known). “Failed” indicates that an immediate maintenance action is recommended (class 1).
‘Warning’ indicates that the system is expected to continue to operate but with degraded
capability (class 3).
15. Reserved.
16. Not used.
17. The SSM should be used as follows:
FUNCTIONAL TEST = Test in Progress (ignore
DISCRETE field, invalid).
NORMAL OPERATION = No failures detected in Antenna.
FAILURE WARNING = Failure(s) detected in the Antenna and indicated in DISCRETE
field; does not include failures in the LNA/Diplexer, Control
ARINC CHARACTERISTIC 781 – Page 150

ATTACHMENT 2
ARINC 429 LABELS AND WORD FORMATS USED IN THE AVIATION SATELLITE COMMUNICATIONS SYSTEM

bus input, CLASS 3 TEMP, ANTENNA RESET, or CLASS 3

HGA/IGA FAILURE
NO COMPUTED DATA = No BSU Control Word or no BSU
Open Loop Steering Word has been received from
the SDU for one or more seconds.
The Antenna shall indicate Functional Test following initiation, and during execution, of its
Functional Test, whether commanded by the SDU or by any other means such as power-on
or a front panel test switch. Upon the completion of Functional Test, the Antenna shall
indicate Normal Operation if no failures were detected or Failure Warning if one or more
failures were detected. Failure Warning shall also be indicated at any time outside of
Functional Test when a monitored (or otherwise tested) parameter is in its failure state.
18. An ARINC 781 antenna should set its SDI bits to TOP.
19. The state “Functional Test” in the SSM will command the destination Antenna to conduct a
self-test and respond with the appropriate data. These data are included in the Antenna
MAINTENANCE WORD, which is output continuously at the rate specified.
20. While commanding the Functional Test mode, the SDU will continuously send the CONTROL
WORD with the SSM set to “Functional Test.” The Antenna will continue to perform the self-
test until the test is completed. The Antenna will then automatically return to normal
operation. Functional test will not be re-initiated by the antenna until after receipt of SSM
fields in the antenna control word from the SDU containing normal operation followed by
functional test.
21. The states “Failure Warning” and “No Computed Data” are not used and should be ignored.
22. The antenna should use the Antenna System Select discrete to turn on and off the DLNA.
23. ARINC 429 labels 270 through 274 (octal) are reserved on all BSU ARINC 429 buses for
testing and crosstalk.
24. Elevation data, bits 9-18, has a range of approximately +89.8 to -90 degrees. Bit 18 is used
as the sign bit. A positive angle is considered upward toward the zenith. Resolution of angle
is approximately 0.17 degrees. The elevation data is provided with reference to the antenna
axes. The SDU should perform transformation for installation offset angles, as provided in
the ORT.
25. Azimuth data, bits 19-29, has a range of approximately +179.8 to -180 degrees. Bit 29 is
used as the sign bit. A positive angle is considered right of the nose reference. Resolution of
the angle is approximately 0.17 degrees. The azimuth data is provided with reference to the
antenna axes. The SDU should perform transformation for installation offset angles, as
provided in the ORT.
26. Data is encoded in BNR, two's complement as defined in ARINC 429; with the exception of
Note 24 above.
27. Reserved.
28. Not used.
29. Reserved.
30. Not used.
31. Not used.
 ARINC CHARACTERISTIC 781 – Page 151
ATTACHMENT 2
ARINC 429 LABELS AND WORD FORMATS USED IN THE AVIATION SATELLITE COMMUNICATIONS SYSTEM

32. RATE: 10-20 words per second. This implies that the interval between the start of two words
with the same label number should always be between 50 and 100 ms.
33. Reserved.
34. Not used.
35. The SDI bits should be set to the code of the Antenna (s) intended to receive and process the
Control Word. An ARINC 781 antenna should always respond to SDI bits set to ALL CALL or
TOP.
36. The Antenna TX Gain field is used to report gain variations at different steering angles to the
SDU. The SDU will use this information from the selected subsystem to vary the HPA gain
accordingly so as to maintain the same effective transmitted power from position to position,
except for changes commanded by the GES.
37. Not used.
38. “If a parameter can only be tested in certain circumstances (e.g., LNA/Diplexer Failed
[Antenna Maintenance Word bit 20] while the LNA is switched on), the failure indication
should persist until a subsequent test or until the next monitored result indicates that the
status has changed to “OK.”
39. Not Used.
40. If the LNA was being commanded “off” before performing a Functional Test, the LNA should
only be turned “on” momentarily (< 100 ms) during Functional Test.
41. Same as Note 17 except that there is no application for the No Computed Data State, which
therefore should not be used. The same requirements as for the Failure Warning indication
apply to the respective Discretes failure bit indications in the Maintenance Word. Failure
Warning and respective DISCRETES failure bit indications should persist until all conditions
and parameters are subsequently re-tested by appropriate tests and are found to be “OK.”
42. Not used.
43. The Equipment Identifier Bit (EQID) bit No 29 should always be set to “1”, identifying the
antenna as ARINC 781 compliant.
44. After the antenna has performed a reset it should set bit 24 for 10 consecutive antenna
maintenance words.
45. The antenna should set Bit 29 and respond with Configuration Data as per Attachment 2A.
At conclusion of Configuration Data reporting the antenna should clear this bit.
46. Bit 18 is equivalent to “Any Other BSU Parameter” in ARINC 741.
47. All PAD bits are set to binary 0.
48. A1 - A24 represent Forward ID “address” bits 1 - 24.
49. The following list provides the labels that are reserved to SDU/antenna manufacturers for
SDU to antenna communications on the SDU multicontrol bus common to both the antenna
and external HPA when fitted. These labels shall not be used by SDU/external HPA
manufacturers for communications from the SDU to the external HPA on the multicontrol bus:
• Labels 145 to 149
• Label 153
The following table provides the list of labels that are used by SDU/antenna manufacturers
for SDU to antenna communications on the SDU multicontrol bus common to both the
antenna and external HPA when fitted. These labels could be used by SDU/external HPA
ARINC CHARACTERISTIC 781 – Page 152

ATTACHMENT 2
ARINC 429 LABELS AND WORD FORMATS USED IN THE AVIATION SATELLITE COMMUNICATIONS SYSTEM

manufacturers for communications from the SDU to the external HPA on the multicontrol bus
as far as they are used for their intended purpose as defined in the Label description field:
ARINC Label Label Description
110 GNSS Latitude
111 GNSS Longitude
125 Universal Time Coordinated
150 Universal Time Coordinated
Manufacturer- specific Status
171 Note: the antenna or external HPA should consider labels 371 and 377 when
processing this label
214 ICAO Address Part 1
216 ICAO Address Part 2
227 CFD BITE Summary
251 Flight Leg Counter
254 Hybrid Latitude
255 Hybrid Longitude
257 Hybrid Latitude, Fine
258 Hybrid Longitude, Fine
260 Date
251 Flight Number
275 Discrete #6 ICAO Address Part 1
276 Discrete #7 ICAO Address Part 2
277 General Test Label
310 Present Position, Longitude
311 Present Position, Latitude
361 Altitude (Inertial)
371 General Aviation Equipment Identifier
Equipment ID
Note: the Antenna Equipment ID is 341 (corresponding to ACU in ARINC 429
377
characteristic) and the external HPA equipment ID is 241 (as defined in ARINC
Characteristic 429)

50. The following labels are used for Swift64 Forward IDs that are obtained from a centralized
source on certain aircraft:
• SDU #1: FWD ID #1 Word #1 = Label 220, Word #2 = Label 221.
• SDU #1: Reserved FWD ID #2 Word #1 = Label 222, Word #2 = Label 223.
• SDU #2: FWD ID #3 Word #1 = Label 224, Word #2= Label 225.
• SDU #2: Reserved FWD ID #4 Word #1 = Label 226, Word #2 = Label 227.
Labels 220 - 221 (and 222 - 227) Inmarsat Swift64 Base Forward ID Words #1 and #2 -
(Discrete)
Swift64 operation requires a 24-bit Forward ID for each Swift64 channel and a corresponding
24-bit Return ID, which the SDU may derive from the Forward ID via an internal look-up table.
Some aircraft are able to supply Forward ID data from a centralized source to the SDU on its
AES ID and/or CMU ARINC 429 inputs. The Swift64 Forward ID is structured and
communicated similarly to the ICAO Aircraft Address (reference labels 214 and 216). It
should be transmitted by the source system at a nominal rate of 1 Hz.
For a multi-channel SDU, labels 220 and 221 communicate the Forward ID for the first (base)
Swift64 channel of the SDU number 1, and the SDU may derive its additional Forward IDs
from this base ID via an internal look-up table. Alternatively, labels 222/223, formatted
identically to labels 220/221, may be used to explicitly communicate the Forward IDs for
Swift64 channel number 2 of the SDU number 1.
 ARINC CHARACTERISTIC 781 – Page 153
ATTACHMENT 2
ARINC 429 LABELS AND WORD FORMATS USED IN THE AVIATION SATELLITE COMMUNICATIONS SYSTEM

In a dual satcom installation, labels 224/225 and 226/227, formatted identically to labels
220/221, may be used to explicitly communicate the Forward IDs for Swift64 channel numbers
1 and 2 of the SDU number 2.
The Forward ID is typically specified as a six-digit hexadecimal number (rarely as a seven-
digit decimal number). In written form, it follows the usual big-endian convention of placing
the most-significant bit (MSB) and most-significant digit first (left-most), and the least-
significant bit (LSB) and least-significant digit right-most. Note, however, that the MSB is
designated as ID (address) bit A1, and the LSB is designated as A24.
The following example illustrates the coding for "Normal Operation" labels 220 and 221 for
Forward ID 23 A5 1F hex (2 336 031 decimal, 10 722 437 octal, 0010 0011 1010 0101 0001
1111 binary):
32 31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1
P SSM A16--------------------------------------------------------------- A1 Octal Label
MSB 220
0 0 0 1 0 1 0 0 1 0 1 1 1 0 0 0 1 0 0 0 0 0 0 0 0 0 0 0 1 0 0 1

32 31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1
P SSM A24--------------------------A17 Octal Label
LSB 221
1 0 0 0 0 0 0 0 0 0 0 0 1 1 1 1 1 0 0 0 0 0 0 0 1 0 0 0 1 0 0 1

51. This label is used for Aircraft type definition that is obtained from a centralized source on
certain aircraft.
Note: labels to be confirmed by AEEC (Boeing to coordinate). The objective is to have these
labels specified in ARINC 429 P2 but in the interim, these labels are described in this
supplement.
52. For full details, reference ARINC Characteristic 761 Attachment 2 Item 2, which defines a
satcom multi-bearer system (MBS), wherein the ARINC 761 SDU may support multiple
satellite systems (e.g., Inmarsat and Iridium). This capability is also defined from the CMU
perspective in ARINC Characteristic 758 (Supplement 2 and subsequent, including in
Attachment 6 Table 6-16). Included in this capability is the MBS SDU's use of the ARINC 429
label 172 subsystem identifier word, transmitted at a nominal rate of 1 Hz on its output bus to
the CMU (and EICAS/ECAM/EDU), to indicate the satellite systems through which it is
capable of providing service. In ARINC 761, label 172 thus has a unique definition and usage
of bits 17-29 that are only defined as pad (zero) bits in the generic ARINC Specification 429
definition of label 172. (ARINC 758 has similar unique definitions for some of the bits in its
label 172 output to the SDU and other air/ground data link equipment.)
The details of an MBS SDU beyond this definition of label 172 are beyond the scope of
ARINC Characteristic 781. However, at a minimum, an ARINC 781 SDU will set bit 17 to
indicate support of the Classic Aero service, and may also set other bits in the Satellite
System Type field as applicable to the specific SDU design.
ARINC CHARACTERISTIC 781 – Page 154

ATTACHMENT 2A
ANTENNA CONFIGURATION DATA REPORTING

1.0 INTRODUCTION
This attachment defines how an ARINC 781 intermediate or high-gain antenna, on
request from an ARINC 781 SDU or a compatible ARINC 741/761 SDU, provides
configuration data to the SDU for onward transmission to the central maintenance
system.
The configuration data includes:
• LRU name
• LRU part number
• LRU serial number
• Software application name
• Software part number
• Optional additional undefined configuration data

2.0 PROTOCOL
This protocol is based on a subset of that specified in ARINC Report 604,
Appendix 2.
The antenna configuration data may be requested by the SDU at any time once the
antenna resets and initializes. This data is typically requested once per power cycle.
Configuration data is requested by the SDU via the label 227 command word, using
the “Configuration” function select code (see Section 3.2). Upon receipt of the
“Configuration” function in label 227, the antenna should set the “In Progress” bit
(29) in its Antenna Maintenance Words (label 350) within two seconds. When the
SDU notes the set “In Progress” bit from the antenna, it sends Label 227 with the
“Null” function selected as an acknowledgement. The antenna then proceeds with
its data transmission. The antenna may alternatively proceed with its data
transmission directly after setting the “In Progress” bit, without waiting for the “Null”
function in Label 227.
The above definition regarding Label 227 represents the minimum functionality for
SDU compatibility with the protocol. The SDU may transmit label 227 as described
above (i.e., a minimum of two times per power cycle), or it may transmit short bursts
(e.g., four words with minimum inter-word time gaps of four bit times) of each
Configuration/Null command to help ensure reception, or it may periodically transmit
label 227 continuously (with the “Null” function indicated when configuration data is
not being requested). If the SDU does transmit label 227 periodically, the
transmission interval should nominally be one second (100 ms minimum), e.g.,
between Null words or between a Configuration word and the subsequent Null word.
For compatibility with ARINC 741/761 SDUs not implementing this protocol, the
antenna must be tolerant with not receiving any label 227 words. The antenna
should not raise any ARINC 429 bus inactivity failure (or any other failure) based on
label 227.
After the “In Progress” bit in the antenna Maintenance Word (Label 350) has been
set by the antenna (and possibly after waiting for acknowledgement by the SDU with
a label 227 “Null” word), the antenna transmits its configuration data using label 356
(see Section 3). The STX word should be initiated no later than two seconds after
either (1) the antenna sets its Label 350 word bit 29 to 1; or, if it is required by the
antenna, (2) the antenna’s receipt of the SDU’s “Null” acknowledgement word. The
 ARINC CHARACTERISTIC 781 – Page 155
ATTACHMENT 2A
ANTENNA CONFIGURATION DATA REPORTING

transmission interval of label 356 words (while they are active) should be between
50-250 ms.
Although the application of this protocol is intended for Antenna/SDU
communications, its original ARINC 604 application was oriented to ARINC 739A
MCDU displays. The response data transmitted is formatted so that it can be
displayed with up to 24 characters per row and up to 10 rows per “page”. All data is
transferred using a subset of the ISO 8859-5 alphabet. Only one “page” of data
should be sent from the antenna to non-specific SDUs using the protocol defined
here. If it is desired to send more than one “page” of data to specific SDU models
(e.g., for enhanced maintenance functionality between a same-manufacturer or
otherwise compatible antenna and SDU, which is beyond the scope of this
definition), then one or more manufacturer-specific label 227 Function Select codes
should be used by the SDU to request such additional information from a compatible
antenna.
The data response words are transmitted in the following order:
1. The STX word is sent.
2. The SYN word is sent.
3. The first three characters (starting with information for row 1 column 1) are
sent.
4. The next three characters for this row are sent. (More words are transmitted
as required for row 1.)
5. At the conclusion of row one, the ETX word is sent, indicating that the
character that follows it is for column 1 of the next row.
6. The first three characters (starting with information for the next row column 1)
are sent.
7. The next three characters for this row are sent. (More words are transmitted
as needed for this row.)
8. The ETX word is sent indicating that the character that follows it is for column
1 of the next row.
Steps 6 through 8 are repeated as needed to transmit all of the information except
the information for the last word of the last row. The ETX word is not transmitted for
the last row, and an EOT word is sent instead, indicating the end of block.
When all of the configuration data has been transmitted to the SDU, the antenna
resets the “In Progress” bit (29) in the antenna Maintenance Word (Label 350).
The SDU should record all received configuration data, including any that it has no
specific knowledge of from “rows” 6 through 10. The additional data should simply
be recorded verbatim and made available for inspection
(e.g., via a maintenance port).
The SDU should not raise any failures due to the non-successful receipt of the
antenna configuration data (including protocol errors). Lack of this data should be
indicated in a manner consistent with the central maintenance system’s
requirements (e.g., as all “dash” (-) characters).
ARINC CHARACTERISTIC 781 – Page 156

ATTACHMENT 2A
ANTENNA CONFIGURATION DATA REPORTING

3.0 DEFINITION OF ARINC 429 WORDS

1.3 3.1 Antenna Maintenance Word – Antenna to SDU (Label 350)
Reference Attachment 2, Figure 6. Bit 29 in label 350 indicates that the antenna is
in the process of sending configuration data to the SDU.
BIT DESCRIPTION BIT = 0 BIT = 1
29 IN PROGRESS NOT IN PROGRESS IN PROGRESS

1.4 3.2 Command Summary Word (SDU to Antenna)

The antenna receives this word from the SDU and responds according to the
command contained in the Function Select field.
COMMAND SUMMARY WORD LABEL 227

32 31  25 24  13 12  11 10  09 08  01

P FUNCTION SELECT EQUIPMENT ID PAD SDI LABEL

PAR XXXXXXX YYYYYYYYYYYY 00 00 11101001

Function Select
000 0000 (0 10 ) = Null
000 0001 (1 10 ) = Reserved for future use
000 0010 (2 10 ) = Configuration Data
000 0011 (3 10 ) = Manufacturer-specific (see Section 2)
000 0100 (4 10 ) through 000 1100 (12 10 ) = Reserved for future use
000 1101 (13 10 ) through 111 1111 (127 10 ) = Manufacturer-specific
Equipment ID
0001 1000 0001 (181 H = ARINC 781 satcom antenna)

SDI
SDI CODE
BITS
CODING
10 9
0 0 All Call
0 1 Top
1 0 Reserved
1 1 Reserved

1. When the antenna receives a “Null” command word from the SDU, it takes no
action.
2. When the antenna receives a “Configuration” command word from the SDU,
it responds with its configuration data.
An ARINC 781-compliant antenna responds to Command words with the satcom
equipment ID set to 181 H when the appropriate SDI code is set. If the SDI code ‘All
Call’ or ‘Top’ is encoded in the SDI field, the antenna responds to the command
 ARINC CHARACTERISTIC 781 – Page 157
ATTACHMENT 2A
ANTENNA CONFIGURATION DATA REPORTING

word. If the SDI code is not equal to ‘All Call’ or ‘Top’, the antenna does not
respond.
1.5 3.3 STX Word (Start of Text)
CONFIGURATION DATA LABEL 356

32 31  25 24  19 18  17 16  09 08  01

P STX SPARE SDI NUMBER OF WORDS LABEL

PAR 0000010 XXXXXX 00 YYYYYYYY 01110111

BITS DEFINITIONS
1-8 Octal Label 356
9 - 16 Number of 32-bit words to be transmitted including the initial and final words.
17 - 18 SDI
19 - 24 Unused
25 - 31 ISO 8859-5 code for “STX”

1.6 3.4 SYN Word (Synchronization Word)

CONFIGURATION DATA LABEL 356

32 31  25 24 23  17 16 15  09 08  01

P SYN PAD # OF DATA PAGES PAD PAGE NUMBER LABEL

PAR 0010110 UNUSED XXXXXXX UNUSED YYYYYYY 01110111

BITS DEFINITIONS
1–8 Octal Label 356
9 – 15 Present Data Page Number (normally 1 – see Section 2)
16 Unused
17 - 23 Total Number of Data Pages Available (normally 1 – see Section 2)
24 Unused
25 - 31 ISO 8859-5 code for “SYN”
ARINC CHARACTERISTIC 781 – Page 158

ATTACHMENT 2A
ANTENNA CONFIGURATION DATA REPORTING

1.7 3.5 Intermediate Word

CONFIGURATION DATA LABEL 356

32 31  25 24 23  17 16 15  09 08  01

P NEXT +1 CHAR PAD NEXT CHAR PAD 1ST CHAR LABEL

PAR XXXXXXX UNUSED XXXXXXX UNUSED XXXXXXX 01110111

BITS DEFINITIONS
1–8 Octal Label 356
9 – 15 First/Next Character of the Configuration Data
16 Unused
17 - 23 Next Character of the Configuration Data
24 Unused
25 - 31 Next + 1 Character of the Configuration Data

1.8 3.6 ETX Word (End of Text)

CONFIGURATION DATA LABEL 356

32 31  25 24 23  17 16 15  09 08  01

P ETX PAD CHAR or NUL PAD CHAR or NUL LABEL

PAR 0000011 0 XXXXXXX 0 XXXXXXX 01110111

The ETX word is used to indicate that the next character is to be displayed in column
1 of the next row (similar to CR/LF). All data is transferred using a subset of the ISO
8859 #5 alphabet as specified in Section 4. The ETX code must appear in bits 25-
31 of the word. Any character positions in the ETX word not needed to complete the
current row should be filled with the NUL code (0000000).

1.9 3.7 EOT Word (End of Transmission)

CONFIGURATION DATA LABEL 356

32 31  25 24 23  17 16 15  09 08  01

P EOT PAD CHAR or NUL PAD CHAR or NUL LABEL

PAR 0000100 0 XXXXXXX 0 XXXXXXX 01110111

The EOT code must appear in bits 25-31 of the word. Any character positions in the
EOT word not needed to complete the current row should be filled with the NUL
code (0000000).
 ARINC CHARACTERISTIC 781 – Page 159
ATTACHMENT 2A
ANTENNA CONFIGURATION DATA REPORTING

BITS DEFINITIONS
1–8 Octal Label 356
9 – 15 Configuration Data character or NUL
16 Unused
17 – 23 Configuration Data character or NUL
24 Unused
25 - 31 ISO 8859-5 code for “EOT”

1.10 3.8 BASIC (NORMAL OPERATION) SEQUENCE DIAGRAM

SDU Antenna
Label 227 Function Select =
Configuration
2 sec max Label 350 Bit 29 = 1 (Config Data In Progress)
Label 227 Function Select = Null -- Note 1--
2 sec max Label 356 = STX (Start of Transmission)
50- 250 ms Label 356 = SYN (Page Sync)
Label 356 = Intermediate Word (Text)
Label 356 = Intermediate Word (Text)

... ...
Label 356 = ETX (End of Text/Line)
Label 356 = Intermediate Word (Text)
Label 356 = Intermediate Word (Text)

... ...
Label 356 = ETX (End of Text/Line)
Label 356 = Intermediate Word (Text)

... ...
Label 356 = Intermediate Word (Text)
Label 356 = EOT (End of Transmission/Page)
Label 350 Bit 29 = 0 (Config Data Complete)

Notes:
1. The antenna may start transmitting STX directly after transmitting
Label 350 with Bit 29 set (i.e., without requiring the SDU’s “Null”
acknowledgement word).
ARINC CHARACTERISTIC 781 – Page 160

ATTACHMENT 2A
ANTENNA CONFIGURATION DATA REPORTING

4.0 CONFIGURATION DATA

All data is transferred using a subset of the ISO 8859-5 alphabet plus the STX, ETX,
EOT, NUL and SYN control codes, as specified in ARINC Specification 429 Part 1
Attachment 5. The character subset should consist of upper-case-only A-Z, 0-9,
space, hash (#), and the symbols corresponding to hex codes 25-2F [% & ‘ ( ) * + ,
- . /].

The standard page of configuration data provided by the antenna is as follows:

Row Data Type Characters (max.)

1 LRU name 11
2 LRU part number 15
3 LRU serial number 15
4 Software application name 15
5 Software part number 15
6 up to 10 Manufacturer-specific (optional) 24 max

All rows are left justified and contain no more than the maximum number of
characters for each line as listed in the table.
 ARINC CHARACTERISTIC 781 – Page 161

ATTACHMENT 2B
BIT-ORIENTED FAULT REPORTING PROTOCOL

Staff Note: The BIT-ORIENTED FAULT REPORTING

PROTOCOL (Fault Summary Words 1-9 for Satcom) in
this attachment will eventually be incorporated into
ARINC Report 604. When incorporated, ARINC Report
604 will have precedence over this attachment.
ARINC CHARACTERISTIC 781 – Page 162

ATTACHMENT 2B
BIT-ORIENTED FAULT REPORTING PROTOCOL

BIT-ORIENTED FAULT REPORTING PROTOCOL

Fault Summary Word #1 for Satcom
Bit Status
Bit No. Function
1 0
1
2
3
4 Label 350
5 (Octal)
6
7
8
9
SDI
10
11 Satellite Data Unit Failure OK
12 Reserved for ARINC 741 Radio Frequency Unit (Note 2) Failure OK
13 Reserved for ARINC 741 HGA High Power Amp (Note 2) Failure OK
14 Reserved for ARINC 741 LNA to External HSDU1 Rx Path (Note 2) Failure OK
15 Reserved for ARINC 741 LGA High Power Amp (Note 2) Failure OK
16 Top/Port Diplexer/LNA (Note 4) Failure OK
17 ARINC 741 Starboard Diplexer/LNA (Note 3) Failure OK
18 Reserved for ARINC 741 LGA Diplexer/LNA (Note 2) Failure OK
19 ARINC 741 ACU or Top/Port BSU (Note 3) Failure OK
20 ARINC 741 Starboard BSU (Note 3) Failure OK
21 Top/Port High Gain or Intermediate Gain Antenna (Note 5) Failure OK
22 ARINC 741 Starboard High Gain Antenna (Note 3) Failure OK
23 Reserved for ARINC 741 HPA to LGA VSWR (Note 2) Failure OK
24 ARINC 741 High Power Relay (Note 3) Failure OK
25 System Configuration Pins Error OK
26 Reserved for ARINC 741 LNA to RFU Rx Path (Note 2) Failure OK
27 Reserved for ARINC 741 RFU to HPA Tx Path (Note 2) Failure OK
28 BITE Test Inhibit Inhibit Enable
29 Command Word Acknowledge ACK NAK
30
SSM
31
32 Parity (Odd)

Notes:
1. "OK" status shall always be indicated for equipment not installed or data not used, as
determined by the Satellite Data Unit system configuration pins or its design.
2. Bit reserved in ARINC 781 to preserve compatibility with Central Maintenance Computers
designed per ARINC 741. Bits should always be set to “OK” in an ARINC 781 SDU.
3. Implementation required if the SDU is designed to interface with ARINC 741 antenna systems.
4. Applicable to any top-mount diplexer in an ARINC 781 antenna system (high gain, intermediate
gain, low gain) or a top-mount diplexer in an ARINC 741 top-mount high gain antenna system or
a port diplexer in an ARINC 741 side-mount high gain antenna system.
5. Applicable to a top-mount high gain or intermediate gain antenna in an ARINC 781 antenna
system or a top/port antenna in an ARINC 741 top-mount high gain antenna system.
 ARINC CHARACTERISTIC 781 – Page 163

ATTACHMENT 2B
BIT-ORIENTED FAULT REPORTING PROTOCOL

BIT-ORIENTED FAULT REPORTING PROTOCOL

Fault Summary Word #2 for Satcom
Bit Status
Bit No. Function
1 0
1
2
3
4 Label 351
5 (Octal)
6
7
8
9
SDI
10
11 CMC to SDU Bus Inactive OK
12 SCDU-1 to SDU Bus Inactive OK
13 Primary IRS to SDU Bus Inactive OK
14 CMU-1 to SDU Bus Inactive OK
15 CMU-2 to SDU Bus Inactive OK
16 SCDU-2 to SDU Bus Inactive OK
17 SCDU-3 to SDU Bus Inactive OK
18 Reserved for ARINC 741 FMC-1 to SDU Bus (Note 4) Inactive OK
19 SDU Crosstalk Input Bus Inactive OK
20 Secondary IRS to SDU Bus Inactive OK
21 Reserved for ARINC 741 HGA HPA to SDU Bus (Note 4) Inactive OK
22 Reserved for ARINC 741 CPDF to SDU Bus (Note 4) Inactive OK
23 Reserved for ARINC 741 LGA HPA to SDU Bus (Note 4) Inactive OK
24 ARINC 741 ACU or Top/Port BSU to SDU Bus (Note 5) Inactive OK
25 ARINC 741 Starboard BSU to SDU Bus (Note 5) Inactive OK
26 Reserved for ARINC 741 RFU to SDU Bus (MP9E/F) (Note 4) Inactive OK
27 CTU to SDU Bus (CEPT-E1) Inactive OK
28 Reserved for ARINC 741 External HSDU #1 to SDU Bus (Note 4) Inactive OK
29 Reserved for ARINC 741 FMC-2 to SDU Bus (Note 4) Inactive OK
30
SSM
31
32 Parity (Odd)

Notes:
1. "OK" status shall always be indicated for equipment not installed or buses not used, as
determined by the Satellite Data Unit system configuration pins or its design.
2. An "Inactive Bus" report, if applicable, will supersede a data input "Failure" report.
3. Bits reserved in ARINC 781 to preserve compatibility with Central Maintenance Computers
designed per ARINC 741.
4. Implementation required if the SDU is designed to interface with ARINC 741 antenna systems.
ARINC CHARACTERISTIC 781 – Page 164

ATTACHMENT 2B
BIT-ORIENTED FAULT REPORTING PROTOCOL

BIT-ORIENTED FAULT REPORTING PROTOCOL

Fault Summary Word #3 for Satcom
BIT ERROR RATE WORD Label 352
PAR SSM SPARE BIT ERROR RATE LABEL
odd 352
MSB LSB
32 30 31 29 25 24 9 8 1
p x x 00000 bbbbbbbbbbbbbbbb 01010111

Note: The use of this word is optional. The format is being defined only to document the word.
The field "Bit Error Rate" indicates the number of raw bit errors detected since the last report
was generated. The report should be generated every 3000 channel bits, at a 600 bps P-
channel rate, this would be a new word every 5 seconds. The data will be in binary format
(positive only), and range from 0 to 3000 maximum.
 ARINC CHARACTERISTIC 781 – Page 165

ATTACHMENT 2B
BIT-ORIENTED FAULT REPORTING PROTOCOL

BIT-ORIENTED FAULT REPORTING PROTOCOL

Fault Summary Word #4 for Satcom
Bit Status
Bit No. Function
1 0
1
2
3
4 Label 353
5 (Octal)
6
7
8
9
SDI
10
11 Reserved for ARINC 741 SDU to RFU Bus (Note 4) Inactive OK
12 Reserved for ARINC 741 SDU/RFU Input Bus MP9J/K (Notes 1 and 4) Inactive OK
13 Reserved for ARINC 741 SDU/RFU Input Bus MP10A/B (Notes 1 and 4) Inactive OK
14 Reserved for ARINC 741 SDU/RFU Input Bus MP10C/D (Notes 1 and 4) Inactive OK
15 Reserved for ARINC 741 SDU/RFU Input Bus MP10E/F (Notes 1 and 4) Inactive OK
16 Reserved for ARINC 741 SDU/RFU Input Bus MP10G/H (Notes 1 and 4) Inactive OK
17 Reserved for ARINC 741 SDU/RFU Input Bus MP10J/K (Notes 1 and 4) Inactive OK
18 ARINC 741 SDU to HGA HPA Multi-Control Bus (Note 6) Inactive OK
19 ARINC 741 HGA HPA Over Temperature (Note 6) Over Temp OK
20 Reserved for ARINC 741 SDU to LGA HPA Multi-Control Bus (Note 4) Inactive OK
21 ARINC 741 SDU to ACU or Top/Port BSU Multi Control Bus (Note 5) Inactive OK
22 ARINC 741 SDU to Starboard BSU Multi-Control Bus (Note 5) Inactive OK
23 Aircraft ID (ICAO Address) 429 Data to SDU Bus Inactive OK
24 Reserved for ARINC 741 Redundant Weight-on-Wheels Discrete (Note 4) Failure OK
25 Reserved for ARINC 741 (ICAO) Address Bits (straps) (Note 4) Error OK
26 ARINC 741 Starboard BSU to Port BSU Crosstalk Bus (Note 5) Inactive OK
27 ARINC 741 Port BSU to Starboard BSU Crosstalk Bus (Note 5) Inactive OK
28 Reserved for ARINC 741 External HSDU1 to HPA Tx Path (Note 4) Failed OK
29 Reserved for ARINC 741 LGA HPA Over Temperature (Note 4) Over Temp OK
30
SSM
31
32 Parity (Odd)

Notes:
1. Pin numbers are relative to the SDU.
2. "OK" status shall always be indicated for equipment not installed or buses not used, as
determined by the Satellite Data Unit system configuration pins or its design.
3. An "Inactive Bus" report, if applicable, will supersede a data input "Failure" report.
4. Bit reserved in ARINC 781 to preserve compatibility with Central Maintenance Computers
designed per ARINC 741. ARINC 781 SDUs should always set this bit to “OK.”
5. Bit used if the SDU is designed to interface with ARINC 741 high gain antenna systems.
6. Bit used if the SDU is designed to interface with ARINC 741 HPAs.
 ARINC CHARACTERISTIC 781 – Page 166

ATTACHMENT 2B
BIT-ORIENTED FAULT REPORTING PROTOCOL

BIT-ORIENTED FAULT REPORTING PROTOCOL

Fault Summary Word #5 for Satcom
Bit Status
Bit No. Function
1 0
1
2
3
4 Label 354
5 (Octal)
6
7
8
9
SDI
10
11 Reserved for ARINC 741 SDU to External HSDU #1 Bus (Note 3) Inactive OK
12 Voice/Data Channel Module 1 Failed OK
13 Voice/Data Channel Module 2 Failed OK
14 Voice/Data Channel Module 3 Failed OK
15 Voice/Data Channel Module 4 Failed OK
16 Voice/Data Channel Module 5 Failed OK
17 Voice/Data Channel Modules 6 and beyond Note 2 Note 2
18 ARINC 741 HPA to HGA VSWR (Note 4) Failed OK
19 DLNA to SDU Rx Path Failed OK
20 ARINC 741 SDU to HPA Tx Path (Note 4) Failed OK
21 Reserved for ARINC 741 External HSDU #1 (Note 3) Failed OK
22 Reserved for ARINC 741 SDU to External HSDU #1 Disable discrete (Note 3) Failed OK
23 Reserved for ARINC 741 External HSDU #1 APM/CDM/FID Straps (Note 3) Failed OK
24 Reserved for ARINC 741 External HSDU #2 to SDU Bus (Note 3) Inactive OK
25 Reserved for ARINC 741 SDU to External HSDU #2 Bus (Note 3) Inactive OK
26 Reserved for ARINC 741 External HSDU #2 (Note 3) Failed OK
27 Reserved for ARINC 741 SDU to External HSDU #2 Disable discrete (Note 3) Failed OK
28 Reserved for ARINC 741 External HSDU #2 APM/CDM/FID Straps (Note 3) Failed OK
29 Shop Faults Mode Supported Yes No
30
SSM
31
32 Parity (Odd)

Notes:
1. “OK” status should always be indicated for equipment not installed or buses not used, as
determined by the Satellite Data Unit system configuration pins or its design.
2. Logic “1” state = one or more of channel modules 6 and beyond have failed;
Logic “0” state = all of channel modules 6 and beyond are OK.
3. Bits reserved in ARINC 781 to preserve compatibility with Central Maintenance Computers
designed per ARINC 741.
4. Used if the SDU is designed to interface with ARINC 741 HPAs.
 ARINC CHARACTERISTIC 781 – Page 167

ATTACHMENT 2B
BIT-ORIENTED FAULT REPORTING PROTOCOL

BIT-ORIENTED FAULT REPORTING PROTOCOL

Fault Summary Word #6 for Satcom
Bit Status
Bit No. Function
1 0
1
2
3
4 Label 355
5 (Octal)
6
7
8
9
SDI
10
11 Reserved for ARINC 741 LNA to external HSDU2 Rx Path (Note 4) Failed OK
12 Reserved for ARINC 741 External HSDU2 to HPA Tx Path (Note 4) Failed OK
13 Reserved for ARINC 741 External HSDU1 Ethernet Port (Note 4) Inactive OK
14 Reserved for ARINC 741 External HSDU2 Ethernet Port (Note 4) Inactive OK
15 Reserved for ARINC 741 SDU to RFU HSDU Disable Discrete (Notes 2 and 4) Failed OK
16 Reserved for ARINC 741 Straps for RFU HSDU (Notes 2 and 4) Failed OK
17 Reserved for ARINC 741 RFU HSDU Fail (Notes 2 and 4) Failed OK
18 Reserved for ARINC 741 SDU to RFU HSDU Bus (Notes 2 and 4) Inactive OK
19 Reserved for ARINC 741 RFU HSDU Channel #1 Fail (Notes 2 and 4) Failed OK
20 Reserved for ARINC 741 RFU HSDU Channel #2 Fail (Notes 2 and 4) Failed OK
21 Reserved for ARINC 741 RFU HSDU Channel #3 Fail (Notes 2 and 4) Failed OK
22 Reserved for ARINC 741 RFU HSDU Channel #4 Fail (Notes 2 and 4) Failed OK
23 Reserved for ARINC 741 RFU HSDU to SDU Bus (Notes 2 and 4) Inactive OK
24 Reserved for ARINC 741 LNA to RFU HSDU Rx Path (Notes 2 and 4) Failed OK
25 Reserved for ARINC 741 RFU HSDU to HPA Tx Path (Notes 2 and 4) Failed OK
26 Reserved for ARINC 741 RFU HSDU Ethernet Port 1 (Notes 2 and 4) Inactive OK
27 Reserved for ARINC 741 RFU HSDU Ethernet Port 2 (Notes 2 and 4) Inactive OK
28 Reserved for External HSDU 1 to SDU Tx Path (Notes 3 and 4) Failed OK
29 Reserved for External HSDU 2 to SDU Tx Path (Notes 3 and 4) Failed OK
30
SSM
31
32 Parity (Odd)

Notes:
1. “OK” status should always be indicated for equipment not installed or buses not used, as
determined by the Satellite Data Unit system configuration pins or its design.
2. RFU HSDU refers to a High Speed Data Unit LRU that conforms in general to the wiring and
form factor of a Radio Frequency Unit.
3. Intended for SDUs with internal high power amplifiers.
4. Bits reserved in ARINC 781 to preserve compatibility with Central Maintenance Computers
designed per ARINC 741.
ARINC CHARACTERISTIC 781 – Page 168

ATTACHMENT 2B
BIT-ORIENTED FAULT REPORTING PROTOCOL

BIT-ORIENTED FAULT REPORTING PROTOCOL

Fault Summary Word #7 for Satcom
Bit Status
Bit No. Function
1 0
1
2
3
4 Label 357
5 (Octal)
6
7
8
9
SDI
10
11 SDU HSDU Channel Module #1 Failed OK
12 SDU HSDU Channel Module #2 Failed OK
13 SDU HSDU Channel Module #3 Failed OK
14 SDU HSDU Channel Module #4 Failed OK
15 External ARINC 781 HPA Failed OK
16 External ARINC 781 HPA to Antenna VSWR Failed OK
17 Reserved Inactive OK
18 Reserved Inactive OK
19 Reserved Inactive OK
20 HGA Over Temperature Over Temp OK
21 ARINC 781 Antenna to SDU Data Bus Inactive OK
22 SDU to ARINC 781 Antenna Data Bus Inactive OK
23 SDU Over Temperature Over Temp OK
24 SDU to Antenna VSWR Failed OK
25 SDU to External ARINC 781 HPA Tx Path Failed OK
26 SDU to External ARINC 781 HPA Data Bus Inactive OK
27 SDU Configuration Module (SCM) Failed OK
28 SDU to SCM Data Bus Inactive OK
29 SCM to SDU Data Bus Inactive OK
30
SSM
31
32 Parity (Odd)

Notes:
1. “OK” status should always be indicated for equipment not installed or buses not used, as
determined by the Satellite Data Unit system configuration pins or its design.
 ARINC CHARACTERISTIC 781 – Page 169

ATTACHMENT 2B
BIT-ORIENTED FAULT REPORTING PROTOCOL

BIT-ORIENTED FAULT REPORTING PROTOCOL

Fault Summary Word #8 for Satcom
Bit Status
Bit No. Function
1 0
1
2
3
4 Label 360
5 (Octal)
6
7
8
9
SDI
10
11 Reserved for ARINC 741 HPA HSDU FID Straps (Note 3) Failed OK
12 Reserved for ARINC 741 HPA HSDU Ethernet Port 1 (Note 3) Inactive OK
13 Reserved for ARINC 741 HPA HSDU Ethernet Port 2 (Note 3) Inactive OK
14 Reserved for ARINC 741 HPA HSDU Channel #1 (Note 3) Failed OK
15 Reserved for ARINC 741 HPA HSDU Channel #2 (Note 3) Failed OK
16 Reserved for ARINC 741 HPA HSDU Channel #3 (Note 3) Failed OK
17 Reserved for ARINC 741 HPA HSDU Channel #4 (Note 3) Failed OK
18 Reserved for ARINC 741 HPA HSDU to SDU Bus (Note 3) Inactive OK
19 Reserved for ARINC 741 LNA to HPA HSDU Rx Path (Note 3) Failed OK
20 Reserved for ARINC 741 SDU to HPA HSDU Bus (Note 3) Inactive OK
21 Reserved for ARINC 741 HPA HSDU APM/CDM (Note 3) Failed OK
22 Reserved for ARINC 741 SDU to HPA HSDU Disable (Note 3) Failed OK
23 USIM #1 Failed OK
24 USIM #2 Failed OK
25 USIM #3 Failed OK
26 USIM #4 Failed OK
27 External ARINC 781 HPA to SDU Data Bus Inactive OK
28 External ARINC 781 HPA Over Temperature Over Temp OK
29 Reserved for ARINC 741 RFU HSDU APM/CDM (Notes 2 and 3) Failed OK
30
SSM
31
32 Parity (Odd)

Notes:
1. “OK” status should always be indicated for equipment not installed or buses not used, as
determined by the SDU system configuration pins or the SDU design.
2. RFU HSDU refers to a High Speed Data Unit LRU that conforms in general to the wiring and
form factor of a Radio Frequency Unit.
3. Bits reserved in ARINC 781 to preserve compatibility with Central Maintenance Computers
designed per ARINC 741.
ARINC CHARACTERISTIC 781 – Page 170

ATTACHMENT 2B
BIT-ORIENTED FAULT REPORTING PROTOCOL

BIT-ORIENTED FAULT REPORTING PROTOCOL

Fault Summary Word #9 for Satcom
Bit Status
Bit No. Function
1 0
1
2
3
4 Label 361
5 (Octal)
6
7
8
9
SDI
10
11 SDU Ethernet Port #6 (fiber channel A) Inactive OK
12 SDU Ethernet Port #7 (fiber channel B) Inactive OK
13 SDU Ethernet Port #8 (fiber spare) Inactive OK
14 SDU Ethernet Port #9 (fiber spare) Inactive OK
15 SDU Ethernet Port #10 (fiber spare) Inactive OK
16 SDU Ethernet Port #1 (Size 22 Pins) Inactive OK
17 SDU Ethernet Port #2 (Size 22 Pins) Inactive OK
18 SDU Ethernet Port # 5 (Size 22 Pins, Spare) Inactive OK
19 SDU Ethernet Port #3 (Quadrax) Inactive OK
20 SDU Ethernet Port #4 (Quadrax) Inactive OK
21 Data from GNSS to SDU Inactive OK
22 Reserved for PIM Failure Failed OK
23 Reserved Failed OK
24 Reserved for ARINC 741 SDU HSDU Ethernet Port #1 Inactive OK
25 Reserved for ARINC 741 SDU HSDU Ethernet Port #2 Inactive OK
26 Reserved for ARINC 741 SDU HSDU Ethernet Port #3 Inactive OK
27 Reserved for ARINC 741 SDU HSDU Ethernet Port #4 Inactive OK
28 Reserved Failed OK
29 Reserved Failed OK
30
SSM
31
32 Parity (Odd)

Notes:
1. “OK” status should always be indicated for equipment not installed or buses not used, as
determined by the Satellite Data Unit system configuration pins or its design.
 ARINC CHARACTERISTIC 781 – Page 171
ATTACHMENT 3
COCKPIT VOICE – SAT PHONE STATE MACHINE FOR NORMAL OPERATION

Air to Ground Call Ground to Air Call

Number selected from MCDU/RMP Idle
Call initiation is either via MCDU or via
Cockpit Voice Mic On Discrete = closed Call announcement
SU from GES
Lights: Off
Chime: None Call Initiation
Voice: Not connected
Call Attempt Result or
Connect SU from GES
Lights: Steady
Lights:
Chime:
Steady
Singlestroke
G->A Incoming Call Chime: Singlestroke
Voice: G->A only connected Connected Voice: Not connected
a Answer Call Button On MCDU
b Cockpit Voice Mic On Discrete open-to-closed
transition
c Cockpit Voice Mic On Discrete = closed
(choice of a, b or c set by ORT)
Lights: Steady Lights: Steady
Chime:
Voice:
None
G->A & A->G
Connected Stimulus same for
A->G and G->A Connected Chime: None
Voice: G->A & A->G
Connected Air Clear Connected
a End Call Button On MCDU
b Cockpit Voice Mic On Discrete = open
c Place/End Call Discrete
(choice of a, b or c set by ORT)
Ground Clear
Channel Release from GES
Lights: Off Lights: Off
Chime: None Chime: None
Voice: Not connected Idle Voice: Not connected
ARINC CHARACTERISTIC 781 – Page 172

ATTACHMENT 4-A
ARINC 781 SDU FUNCTIONS MATRIX

The SDU functions matrix seeks to define what features and functions are typically
included in which model or version of satcom systems. ARINC 781 differs from
previous satcom specifications in that various features of the system can be optional.
The following provides two examples of representative versions of satcom systems.
Cockpit & Cabin Cabin-Only
Options/
Section Feature/Function Satcom Satcom
Comments
(Example) (Example)
2.10 BITE (CFDS interface) OEM CFDSs All None
3.1.1 Inmarsat Services
1
3.1.1.2 Classic Aero Channels: 0-4 2 0
1
3.1.1.3 Swift64 Channels: 0-4 2 4
1
3.1.1.4 SwiftBroadband Channels: 0-4 2 4
3.1.2 Radio Interfaces
3.1.2.5 User/Radio Interfaces
Mapping
Non-ATC 4-wire Analog Yes No
Cockpit Voice
ATC Cockpit 4-wire Analog Yes No
Voice
Cabin Voice 2-wire POTS/SLIC Yes Yes
Non-ATC Data-2/3, Ethernet/ Ethernet/
Cockpit Data Ethernet/ARINC 664 ARINC 664 ARINC 664
ATC Cockpit Data-2/3, Data-2/3 None
Data Ethernet/ARINC 664
Cabin Data CEPT-E1, ISDN, Ethernet Only All
Ethernet, 2 Wire
POTS/SLIC
3.2.1 Pilot System Interfaces
for Voice
3.2.1.2 MCDU Menus OEM Specific OEM Compliant None
3.2.1.6 SAT Phone – Aero-H/H+/I Yes None
Classic Aero
3.2.1.7 SAT Phone - 4 kbps AMBE+2, VoIP Both None
SwiftBroadband
3.2.1.8 SAT Radio – VoIP Yes None
SwiftBroadband
3.2.1.9 Williamsburg Yes None
SDU Controller
3.2.4 Ethernet PPPoE, DHCP, SNMP, All All
Telnet, Routed IP
3.3 Software Data Loader ARINC 615-3/4, Both ARINC 615A
ARINC 615A
3.4.1 Dual Satcom
3.4.1.1 Classic Aero Independent, Cold Warm Standby, None
Operations Standby, Warm Cooperative
Standby, Hot Standby,
Cooperative
3.4.1.2 SwiftBroadband & Independent, Cold Independent, Independent,
Swift64 Standby, Warm Cooperative Cooperative
Operations Standby, Hot Standby,
Cooperative
3.4.3 Security Incorporated Yes No
3.6 Future Growth
 ARINC CHARACTERISTIC 781 – Page 173
ATTACHMENT 4-A
ARINC 781 SDU FUNCTIONS MATRIX

Cockpit & Cabin Cabin-Only

Options/
Section Feature/Function Satcom Satcom
Comments
(Example) (Example)
3.6.1 ARINC 664 Yes – Future No
Deterministic Ethernet
3.6.3 FANS/ATS over SBB Yes – Future No
3.6.4 Multi-Frequency Band Yes – Future Yes – Future

Notes:
1. SDU manufacturers should clearly state what combination of channels is supported.
ARINC CHARACTERISTIC 781 – Page 174
ATTACHMENT 4-B
ARINC 781 SDU INTERFACES MATRIX

The SDU interfaces matrix seeks to define which interfaces are typically included in
which model or version of satcom systems. ARINC Characteristic 781 differs from
previous satcom specifications in that various interfaces of the system can be
optional. The following provides two examples of representative versions of satcom
systems.
Cockpit & Cabin Cabin-Only
Options/
Interfaces on ARINC 600 Connector Satcom Satcom
Comments
(Example) (Example)
Power
115 Vac V/F Yes Yes
28 Vdc No No
Satcom Interfaces
Tx RF (Power) 30W 25W
BSU Control A781 HGA/IGA,
A741 Top, All A781 HGA/IGA
A741 Side
LGA Control No No
External HPA Control A741, A781 A781 No
HPA Mute Yes No
SCM Yes Yes
Other SDU (dual) Yes No
User Interfaces 2 2
10/100BaseT on size 22 pins 2 2
10/100BaseT (Cockpit data) on Quadrax No No
ARINC 664 Copper (Cockpit voice & data) No No
ARINC 664 Fiber (Cockpit voice & data) No No
ISDN 2 2
CEPT-E1 No No
(C)MU 2 No
Cockpit Voice (4-wire & discretes) Yes No
MCDU 3 No
POTS/SLIC No No
BITE/Maintenance Interfaces
CFDS / CMC on ARINC 429 Yes Yes
ADL (ARINC 615/429) Yes Yes
Service Availability Status discretes Yes Yes
ATE pins Yes Yes
Miscellaneous Interfaces
AES ID (ARINC 429) Yes No
IRS/GNSS 2 2
Configuration Straps Yes No
WOW Yes Yes
Tx Mute No No
 ARINC CHARACTERISTIC 781 – Page 175

ATTACHMENT 5
ETHERNET INTERFACE

ARINC CHARACTERISTIC 781

TABLE OF CONTENTS

1.0 INTRODUCTION ..................................................................................................... 178

1.1 Purpose and Scope ................................................................................................. 178
1.2 End to End Architecture Overview ........................................................................... 178
2.0 OVERVIEW OF INTERFACE .................................................................................. 180
2.1 Interface Purpose .................................................................................................... 180
2.2 Aircraft Architecture ................................................................................................. 180
2.3 SwiftBroadband PDP Concepts ............................................................................... 181
2.3.1 Primary PDP Context .......................................................................................... 181
2.3.2 Secondary PDP Context ..................................................................................... 181
2.3.3 Background Class ............................................................................................... 181
2.3.4 Streaming Class .................................................................................................. 181
2.4 Interface Fundamentals ........................................................................................... 181
2.4.1 Ethernet .............................................................................................................. 181
2.4.2 TCP/IP ................................................................................................................ 181
2.4.3 PPPoE ................................................................................................................ 181
2.4.4 PPP Server ......................................................................................................... 181
2.4.5 PPPoE Context Relationship ............................................................................... 182
2.4.6 Control Line via Telnet ........................................................................................ 182
2.4.7 Traffic Flow Templates ........................................................................................ 182
3.0 PPPOE .................................................................................................................... 183
3.1 Description............................................................................................................... 183
3.2 Protocol Layering ..................................................................................................... 183
3.2.1 Layer 2 (Switched) Model - PPPoE Presentation at TE ....................................... 183
3.2.2 Layer 3 (Routed) Model - IP Presentation at TE .................................................. 184
3.3 Protocol Operation for BGAN Context Setup ........................................................... 184
3.3.1 PPPoE Sequence ............................................................................................... 184
3.3.2 PPPoE Session ................................................................................................... 185
3.3.3 Discovery Stage .................................................................................................. 185
3.3.4 Link Control Protocol ........................................................................................... 187
3.3.5 Authentication ..................................................................................................... 187
3.3.6 Network-layer Control Protocol............................................................................ 187
3.3.6.1 PPP Parameters Interfacing to UMTS During NCP......................................... 188
3.3.7 Data Transfer ...................................................................................................... 188
3.3.8 Call Termination .................................................................................................. 188
3.3.8.1 PADT Error code........................................................................................ 188
3.3.9 Access Concentrator Name ................................................................................ 188
3.3.10 PPPoE to Core SBB Network .............................................................................. 189
3.3.11 PPPoE Service Names ....................................................................................... 190
3.3.11.1 Service Descriptor String ........................................................................... 190
3.3.11.1.1 Service ....................................................................................................... 191
3.3.11.2 Channel ..................................................................................................... 191
3.3.11.3 Parameters ................................................................................................ 191
3.3.11.3.1 Parameters Field for SBB .......................................................................... 191
3.3.11.3.1.1 SBB Options (optional) .......................................................................... 192
3.3.11.3.2 Parameter Field for MPDS ......................................................................... 192
3.3.11.3.3 Parameter Field for ISDN ........................................................................... 192
3.3.11.4 Hunt Group Syntax for Service Names ...................................................... 192
3.3.12 Offered Service-Name......................................................................................... 193
ARINC CHARACTERISTIC 781 – Page 176

ATTACHMENT 5
ETHERNET INTERFACE

ARINC CHARACTERISTIC 781

TABLE OF CONTENTS
4.0 PDP CONTEXT CONTROL ..................................................................................... 194
4.1 No Out of Band Control Line .................................................................................... 194
4.1.1 Interface Stage 1 Implementation (No Control Line) Single TE............................ 194
4.1.2 Interface Stage 1 Implementation (No Control Line) Multi-User ........................... 194
4.2 Out of Band Control Line ......................................................................................... 195
4.2.1 Control Line Concept and Stack Diagram ........................................................... 195
4.2.2 Interface Stage 2 Implementation (With Control Line) ......................................... 195
4.2.2.1 Pairing of PPPoE Session and PDP Contexts............................................ 196
4.2.3 Stage 3 Implementation ...................................................................................... 197
4.2.4 Telnet Server ...................................................................................................... 197
4.2.4.1 AT Handler................................................................................................. 197
4.2.4.2 Welcome Message .................................................................................... 198
4.2.4.3 Local Echo ................................................................................................. 198
4.2.5 Control Line IP Addressing .................................................................................. 198
4.2.6 Pairing of Control and Data Lines ........................................................................ 198
4.3 Scaling PDP Contexts Concepts.............................................................................. 198
4.3.1 Scaling a PDP Context Without a Control Line .................................................... 199
4.3.1.1 Replacing a Primary Context ..................................................................... 199
4.3.1.2 Adding an Additional Primary Context ........................................................ 199
4.3.2 Scaling a PDP Context with a Control Line.......................................................... 200
4.3.2.1 Additional Secondary Context .................................................................... 200
4.3.2.2 Modify PDP Context................................................................................... 200
4.4 AT Commands ......................................................................................................... 201
4.4.1 AT Command Interface Support .......................................................................... 201
4.4.2 ARINC 781 Defined AT Commands .................................................................... 205
4.4.2.1 IPDS AT Command Extension for Binding a TCP Session to PDP Primary
Context ...................................................................................................... 205
4.4.2.1.1 Set Command ............................................................................................ 205
4.4.2.1.2 Read Command ......................................................................................... 206
4.4.2.1.3 Test Command .......................................................................................... 206
4.4.2.1.4 Unsolicited Result Code ............................................................................. 206
4.4.2.1.5 Defined Values .......................................................................................... 206
4.5 Virtual Context IDs ................................................................................................... 206
4.6 Service Name Tag ................................................................................................... 206
5.0 Editor’s Comment .................................................................................................... 208
5.1 Public Standards...................................................................................................... 208
5.1.1 Institute of Electrical and Electronics Engineers Documents ............................... 208
5.1.2 Internet Engineering Task Force Standard Documents ....................................... 208
5.2 Basic Structure ........................................................................................................ 209
5.2.1 MIB-II Objects and Enterprise OID ...................................................................... 209
5.2.2 MIB Entry Point ................................................................................................... 210
5.2.3 General MIB Branches ........................................................................................ 210
5.3 Detailed MIB Definition ............................................................................................ 211
5.3.1 Object Types ....................................................................................................... 211
5.3.1.1 Health Status Type Definition ..................................................................... 211
5.3.1.2 Test Status Type Definition ........................................................................ 211
5.3.1.3 Link Status Type Definition ........................................................................ 211
5.3.1.4 Satellite Lock State Type Definition ............................................................ 211
5.3.1.5 Restart Reason Type Definition ................................................................. 212
5.3.1.6 LRU Thermal State Type Definition ............................................................ 213
 ARINC CHARACTERISTIC 781 – Page 177

ATTACHMENT 5
ETHERNET INTERFACE

ARINC CHARACTERISTIC 781

TABLE OF CONTENTS
5.3.1.7 Thermal Antenna State Type Definition...................................................... 213
5.3.2 Mandatory Branches ........................................................................................... 213
5.3.2.1 MIB Version Related Objects ..................................................................... 213
5.3.2.2 Link Related Objects .................................................................................. 214
5.3.2.2.1 Service Availability Related Sub Branch .................................................... 214
5.3.2.2.1.1 Object Structure .................................................................................... 214
5.3.2.2.1.2 Object Behavior ..................................................................................... 215
5.3.2.2.2 Link Related Information Sub Branch ......................................................... 216
5.3.2.2.2.1 Object Structure .................................................................................... 216
5.3.2.2.2.2 Object Behavior ..................................................................................... 220
5.3.2.3 System Related Objects............................................................................. 223
5.3.2.3.1 System Configuration Related Sub Branch ................................................ 223
5.3.2.3.2 System Information Related Sub Branch ................................................... 223
5.3.2.3.2.1 System Trap Related Sub Branch ......................................................... 224
5.3.2.3.3 System Self-Test Related Sub Branch ....................................................... 224
5.3.2.4 Unit Related Objects .................................................................................. 225
5.3.2.4.1 SDU Unit Related Objects.......................................................................... 226
5.3.2.4.1.1 Information Sub Branch for the SDU Unit Related Objects .................... 226
5.3.2.4.1.2 Configuration Sub Branch for the SDU Unit Related Objects ................. 228
5.3.2.4.1.3 Trap Sub Branch for the SDU Unit Related Objects .............................. 229
5.3.2.4.2 SCM unit Related Objects .......................................................................... 229
5.3.2.4.2.1 Information Sub Branch for the SCM Unit Related Objects.................... 229
5.3.2.4.2.2 Configuration Sub Branch for the SCM Unit Related Objects ................ 230
5.3.2.4.2.3 Trap Sub Branch for the SCM Unit Related Objects .............................. 230
5.3.2.4.3 DLNA Unit Related Objects........................................................................ 230
5.3.2.4.3.1 Information Sub Branch for the DLNA Unit Related Objects .................. 231
5.3.2.4.3.2 Configuration Sub Branch for the DLNA Unit Related Objects ............... 231
5.3.2.4.3.3 Trap Sub Branch for the DLNA Unit Related Objects ............................ 231
5.3.2.4.4 Antenna Unit Related Objects .................................................................... 232
5.3.2.4.4.1 Information Sub Branch for the Antenna Unit Related Objects .............. 232
5.3.2.4.4.2 Configuration Sub Branch for the Antenna Unit Related Objects ........... 233
5.3.2.4.4.3 Trap Sub Branch for the Antenna Unit Related Objects ......................... 233
5.3.2.4.5 Future units ................................................................................................ 233
5.3.2.5 User Defined Area ..................................................................................... 233
6.0 ERROR CODES FOR PADT PPPOE MESSAGES ................................................ 234
7.0 ASN.1 SNMP MIB CODE ........................................................................................ 236
8.0 TO BE ADDRESSED IN A FUTURE REVISION ...................................................... 236
8.1 Quality of Service Entries ......................................................................................... 236
8.2 Owner Requirement Table Branch ........................................................................... 236
8.3 Optional Features Flags........................................................................................... 236
ARINC CHARACTERISTIC 781 – Page 178

ATTACHMENT 5
ETHERNET INTERFACE

1.0 INTRODUCTION
1.1 Purpose and Scope
This attachment describes how an SDU should set up, control, terminate and
transfer packet data using the BGAN/SwiftBroadband packet data service via an
IEEE 802.3 Ethernet interface(s) to Terminal Equipment. Services offered by the
Terminal Equipment are out of scope of this document. Other uses of the physical
interface, such as BITE and control of the SDU are outside the scope of this
document.
The following uses of the interface as stated in Section 3.2.4 do not (currently) have
detailed requirements described in this attachment.
• Routed Interface
• Security requirements
1.2 End to End Architecture Overview
The architecture below closely resembles that which would occur in an aircraft with a
SwiftBroadband SDU. This represents a single channel. The interface to be
implemented must support such architecture.

Future Network Architecture

Note that in this model:
• PPP over Ethernet is carrying the PPP session between the TE/Router and
the SDU.
• Multiple devices are attached to a network to access the SDU via a
TE/Router device.
• Wireless devices may be deployed.
• Multiple sessions are in operation to different devices.
• Different services (for instance voice) may be offered (additional terrestrial
infrastructure required and shown).
 ARINC CHARACTERISTIC 781 – Page 179

ATTACHMENT 5
ETHERNET INTERFACE

Note: The diagram does not show multiple SDUs or Channel Units,
but these may be attached to the Router as an extension of
this configuration. In addition, there may be scenarios where
PPPoE originates in one or more TE/Router devices attached
to the network.
ARINC CHARACTERISTIC 781 – Page 180

ATTACHMENT 5
ETHERNET INTERFACE

2.0 OVERVIEW OF INTERFACE

2.1 Interface Purpose
To set up, control, and transfer packet data using SwiftBroadband packet data
service.
The interface can also be used (backwards compatible) for the setup, termination
and transfer of packet data using Swift64 (packet & circuit switched service)
Suitable for use with Terminal End Points containing unmodified COTS protocol
stacks
Note: Control equates to: set up, modification and termination of
primary contexts, and modification and termination of
secondary contexts.
2.2 Aircraft Architecture
This Interface concept supports a wide variety of aircraft architectures including
those:
• With or without servers
• With single or multi-channel SDUs
• With single or multiple SDUs
• With single or multiple servers

Area of Interest is
between the TE and SDU

User SDU User SDU

A TE
(TE) CU
CU
User
TE SDU F CU
B User
CU
User
TE
User
TE SDU User
C
CU
User
User Switch/Hub SDU
(TE) CU
SDU G
User
TE CU User
D (TE)
User CU

TE SDU
User
CU
User SDU H
TE
E CU
User User TE SDU
CU
SDU
CU

Scenarios to be Supported by the Interface.

 ARINC CHARACTERISTIC 781 – Page 181

ATTACHMENT 5
ETHERNET INTERFACE

2.3 SwiftBroadband PDP Concepts

SwiftBroadband provides packet data services via Packet Data Protocol (PDP)
contexts. Each SDU channel can support up to 11 concurrent contexts. Each context
can be either a Background Class or Streaming Class.
2.3.1 Primary PDP Context
Each Primary PDP Context has a unique IP address. A Primary Context can have
up to 10 Secondary Class Contexts within it.
2.3.2 Secondary PDP Context
A secondary context can only exist within a parent Primary PDP Context. It has the
same IP as the Primary context. A secondary context needs a Traffic Flow Template
(TFTs) to specify what traffic it should transport. Any traffic that is not specified in this
template is sent over the Primary Context. Secondary Contexts are generally only
utilized with a TE that employs a control line to the SDU.
2.3.3 Background Class
This class provides a shared IP service. The data rate is dependent on the class of
the SDU and the number of other terminals operating on the channel. The operator
pays only for the data sent and received using this service. This type of context is
useful for general Internet access, email, Web surfing and VPN connections where
guaranteed bandwidth is not required.
2.3.4 Streaming Class
This Class provides dedicated data in rates of between 8 and 128 kbps in 8 kbps
increments per Channel Unit. In addition, an X-Stream mode is available that
assigns a 200 kHz bearer to the requesting AES for its exclusive use. The maximum
data rate is dependent on the class of SDU. The operator is charged for the amount
of time the Context is active. This context is used for a guaranteed data rate that
ensures uniform latency (jitter) for applications such as videoconferencing, streaming
video and voice over IP applications.
Note: X-Stream only supports one PDP context per channel.
2.4 Interface Fundamentals
2.4.1 Ethernet
IEEE 802.3 Ethernet is the physical interface.
2.4.2 TCP/IP
SDU shall implement a TCP/IP V4 network stack.
2.4.3 PPPoE
PPPoE is the protocol used to establish a PDP Context. The SDU shall implement a
RFC 2516 compliant PPPoE Access Concentrator.
2.4.4 PPP Server
PPP is terminated in the SDU. The SDU shall implement a RFC 1661 compliant PPP
Server.
ARINC CHARACTERISTIC 781 – Page 182

ATTACHMENT 5
ETHERNET INTERFACE

2.4.5 PPPoE Context Relationship

Each primary context is supported in a separate PPPoE session, and is allocated an
IP address by either Inmarsat or the DP. Secondary context traffic is supported via
the PPPoE session of the parent primary and shares the parent’s IP address.
Secondary contexts are established and controlled via a telnet service hosted by the
SDU or with a Primary PDP Context request that is established via an AT string in a
PPPoE service name.
2.4.6 Control Line via Telnet
The SDU shall accept TCP connections over port 22222 for establishing, modifying
and creating secondary contexts.
Each control line equates to a single TCP session. The control line addresses a
particular PDP context using a special AT command within a TCP session.
The name “telnet” is legacy from earlier implementations. See Section 4.2.4 for
further details.
2.4.7 Traffic Flow Templates
Traffic Flow Templates (TFTs) (based on 3G plus Inmarsat extensions) is the
mechanism to specify the packet filter parameters between parent primary and
secondary PDP contexts. They can be defined with PPPoE and Control Line via
Telnet.
 ARINC CHARACTERISTIC 781 – Page 183

ATTACHMENT 5
ETHERNET INTERFACE

3.0 PPPOE
3.1 Description
Extract from introduction of RFC2516:
“PPP over Ethernet (PPPoE) provides the ability to connect a network of hosts over
a simple bridging access device to a remote Access Concentrator. With this model,
each host utilizes its own PPP stack and the user is presented with a familiar user
interface. Access control, billing and type of service can be done on a per-user,
rather than a per-site, basis.”
For SwiftBroadband, IP traffic between the SDU and end user (TE) will be via PPP
over Ethernet (PPPoE). Multiple PPPoE sessions will be supported. This will allow
multiple end users, each having a separate connection. It is assumed that each
PPPoE client will be assigned the IP address associated with the packet data call
(PDP context) and that each Primary PDP context will have a different IP address.
3.2 Protocol Layering
There are two conceptual models for operation of the protocols: Ethernet
presentation to TE and IP presentation to TE.
The SDU interface remains the same in either case, and hence can support either
model.
3.2.1 Layer 2 (Switched) Model - PPPoE Presentation at TE
The following diagram shows the user plane protocol stack for a single device
attached to an SDU using PPPoE, where all the applications run on the Mobile
Network Node TE and Fixed Network Node (FNN) TE.
MNN SDU SAS GGSN FNN
TE DTE

App App

TCP TCP

IP IP IP

PPP PPP PDCP PDCP GTP GTP

PPPoE PPPoE IAI-2 IAI-2 UDP UDP

Protocol Stack for User Plane for Routed Multiple TE Devices

In multiple user operation, a bridge, hub or switch is placed between the MNN TE
devices (each of which runs a PPPoE stack) and the SDU. The SDU is aware of all
devices on the network.
ARINC CHARACTERISTIC 781 – Page 184

ATTACHMENT 5
ETHERNET INTERFACE

3.2.2 Layer 3 (Routed) Model - IP Presentation at TE

MNN Router SDU SAS GGSN FNN
DTE DTE

App App

TCP TCP

IP IP IP IP

PPP PPP PDCP PDCP GTP GTP

PPPoE PPPoE IAI-2 IAI-2 UDP/IP UDP/IP

Protocol Stack for User Plane for Routed Multiple TE Devices

In this case there is only a single device (the Router) that is requesting service – the
SDU does not need to know that there are multiple MNN TEs. The advantage of this
approach is that it does not require PPPoE in the TE.
3.3 Protocol Operation for BGAN Context Setup
The following describes the PPPoE set up message sequencing including specific
messaging that should be expected when implementing a PPPoE interface to a SBB
SDU.
3.3.1 PPPoE Sequence
The sequence diagram below shows in broad terms the stages needed to establish
an IP call from a PPPoE client (TE).
 ARINC CHARACTERISTIC 781 – Page 185

ATTACHMENT 5
ETHERNET INTERFACE

PPPoE Client PPPoE Server

TE SDU (SBB/MPDS)

Session Request

LCP

Authentication

NCP MSG_T_AM

MSG_A_AM

IP Data (SBB) / PPP data (MPDS)

Call Clear
MSG_T_AP

MSG_A_AP

PPPoE IP Call

3.3.2 PPPoE Session

A PPPoE session needs to be established between the TE (PPPoE client) and the
SDU (PPPoE server). This would involve the discovery protocol, Link Control
Protocol (LCP), authentication and Network-layer Control Protocol (NCP) stages.
3.3.3 Discovery Stage
The discovery stage is initiated by the PPPoE client (TE) to find out if there are any
PPPoE servers attached.
ARINC CHARACTERISTIC 781 – Page 186

ATTACHMENT 5
ETHERNET INTERFACE

PPPoE
PPPoE Client
Client PPPoE
PPPoEServer
Server
TEuser)
(End SDU
(CCA)

PADI

PADO

PADR

PADS

PADT

PPPoE Discovery

Stage Comment
1 The PPPoE client (TE) broadcasts a PPPoE Active Discovery Initiation (PADI) packet. As it is a
broadcast packet all attached devices on the network, including the SDU, will receive it.
2 The PPPoE server (SDU) receives the PADI and responds to the PPPoE client with a PPPoE
1
Active Discovery Offer (PADO) packet if the requested service is available . The PADO must
uniquely identify the SDU. Additionally the PADO may contain a number of Service-Name TAGs.
3 The PPPoE client (TE) sends a PPPoE Active Discovery Request (PADR) packet to the PPPoE
server. This is analogous to a call request. It will also contain a Service-Name TAG_TYPE to
indicate the SBB bearer type required.
4 The PPPoE server (SDU) responds with a PPPoE Active Discovery Session-confirmation (PADS)
packet.
5 The session is now established. PPP traffic can pass between the PPPoE client (TE) and PPPoE
server (SDU).
6 To terminate the session a PPPoE Active Discovery Terminate (PADT) packet is sent from either
the PPPoE client (TE) or PPPoE server (SDU).

1
Since a PADO is only returned if there is service availability, the use of PADI is not a reliable method of getting a list of available
services. The service availability table (Section 5.3.2.2.1) accessible via SNMP is the recommended method. PADI is still a legitimate
method for checking for the availability of a specific service. Sending a PADI does not infer any reservation of service; this is done
through a PADR.
 ARINC CHARACTERISTIC 781 – Page 187

ATTACHMENT 5
ETHERNET INTERFACE

3.3.4 Link Control Protocol

LCP negotiates link configuration parameters between the SDU and PPPoE client
(TE). Refer to RFC 1661 for further details. Failure of this phase will result in the
PPPoE session being terminated.
3.3.5 Authentication
The authentication phase may include exchange of a user name and password
between the TE’s PPPoE client and the SDU’s PPP Server. The SDU does not know
if a user name and passwords is required by the APN prior to making the PDP
Context activation request.
The SDU shall successfully authenticate the TE regardless of what it has been
presented with. (Spoof Authentication)
The SDU shall store the username and credentials from the TE for the PDP Context
activation. Failure of the PDP Context activation authentication shall result in the
SDU terminating the PPPoE session with a PADT. The PADT shall contain a
specific failure code defined in Error codes section of this document.
The SDU shall support the following authentication protocols: PAP.
3.3.6 Network-layer Control Protocol
NCP is responsible for establishing the IP addresses that the TE’s PPPoE client and
SDU will use to exchange information between them.
Note that the IP address to assign to the PPPoE client will not be known until the
PDP session has been established. The SDU will not respond to IPCP Config-Req’s
messages from the TE until the SDU has received an Activate PDP Context Accept
message from the network. The Activate PDP Context contains the PPP IP
parameters.
ARINC CHARACTERISTIC 781 – Page 188

ATTACHMENT 5
ETHERNET INTERFACE

3.3.6.1 PPP Parameters Interfacing to UMTS during NCP

Failure of this phase will result in the PPPoE session being terminated
During the IPCP negotiations PPP parameters need to be passed or obtained from
the SBB network.
PDP Activate Context
Parameters PPP
Message
IP Address IPCP protocol RFC 1332 This is passed using the
PDP Address IE detailed in
PPP Type = 3 3GPP 24.008
Length = 6
IP address = 4 bytes

If the IP address bytes are set to 0.0.0.0, then it

is requesting a dynamic allocated address.
Primary DNS IPCP protocol Extensions for Name Server This is passed using the
Addresses Addresses RFC 1877 Protocol Configuration
PPP Type = 129 Options IE detailed in 3GPP
Length = 6 24.008
IP address = 4 octets
Secondary IPCP protocol Extensions for Name Server This is passed using the
DNS Addresses RFC 1877 Protocol Configuration
Addresses PPP Type = 131 Options IE detailed in 3GPP
Length = 6 24.008
IP address = 4 octets

3.3.7 Data Transfer

The SDU’s PPP/PPPoE stack will deliver IP packets to the SBB network by bridging
the PPP session and the PDP context(s).
3.3.8 Call Termination
The PPPoE client will usually initiate call termination. The PADT packet sent by the
PPPoE client will cause SDU to terminate the PDP Context. The call will then be
cleared in an orderly manner. If the call clears for any other reason, a PADT will be
sent from the PPPoE server to the PPPoE client to terminate the PPPoE session.
3.3.8.1 PADT Error code
The PADT will contain a reason code that is mapped from the message derived from
the Inmarsat cause code. These are documented in Section 6 of this document.
3.3.9 Access Concentrator Name
The SDU shall support the configuration of an Access Concentrator name via the
ORT. This is needed where there are multiple SDU on a network.
A client can specify an AC-Name in a PADI. This field may be used by the SDU to
determine whether the request was directed to itself. That is, if the AC-Name in the
PADI does not match the AC-Name of the SDU, the SDU may simply ignore it.
 ARINC CHARACTERISTIC 781 – Page 189

ATTACHMENT 5
ETHERNET INTERFACE

3.3.10 PPPoE to Core SBB Network

PPPoE PPPoE Access PPP PPP Control Core

SDU Modem
Client (TE) Concetrator (SDU) Server (SDU) (SDU) Network

PADI

PADO

PADR ServiceName = BGAN128

PADS

LCP Negotiation

IPCP Configure-Request
SET IP Address, MSG_T_AM PacketSwitch “QoS, PDP” PDP Activate Context
DNS
MSG_A_PS
MSG_A_PR
MSG_A_PC PDP Activate Context Accept
MSG_T_AS
Get MSG_T_AS_BGANPDPCONTEXT
MSG_A_AS
Get MSG_T_AS_BGANPDPCONTEXT “PDP
Context Data”
IPCP Configure-Ack
SET IP Address,
DNS

IP Packet RabDataReq(data)
IPData (data) MSG_P_PP (data)
IP Packet IPData (data) MSG_A_PD (data) RabDataInd(data)

IPCP Terminate-Request

IPCP Terminate-Ack

LCP Termination

PADT Disconnect MSG_T_AP PDP Deactivate Context

MSG_A_PX PDP Deactivate Context Accept

Message Sequencing Chart

ARINC CHARACTERISTIC 781 – Page 190

ATTACHMENT 5
ETHERNET INTERFACE

Stage Comment
1 The PPPoE (TE) client requests a PPPoE session. Included in the request is the service type, which
will be used to map to a SBB bearer type and QOS. The PPPoE access concentrator (SDU)
completes the discovery stage.

2 With the call established, the PPPoE server can now configure the PPPoE client by continuing with
LCP, authentication.

3 Once the NCP stage has requested an IP address, the SDU Channel Unit is instructed to start the
packet data call, and is passed the PDP context information, required for the PDP context to be
requested.

The NCP request is acknowledged once the PDP context has accepted.
4 Data is passed between the PPPoE client and PPPoE server using PPPoE. Data is passed
between the PPPoE server and Channel Unit SBB stack using IP packets.

5 The session terminates, usually at the request of the PPPoE client.

3.3.11 PPPoE Service Names

The PPPoE Service-Name is a string used to describe to the PPPoE Access
Concentrator what service is being requested.
This string is commonly formed of a single Service Descriptor string, described
below.
3.3.11.1 Service Descriptor String
The Service Descriptor string is being described separately from the Service-Name
field, as the “Hunt Group” functionality described later calls for multiple Service
Descriptor strings to be supplied within a Service-Name field.
The Service Descriptor shall be parsed as follows:
service[-channel][:parameters]
This is: the optional name of the service, optionally followed by a channel specifier
(separated by a dash), optionally followed by either a single SBB option name or an
AT string (separated by a colon). Some services require parameters.
Example: SBB:STREAM64K
 ARINC CHARACTERISTIC 781 – Page 191

ATTACHMENT 5
ETHERNET INTERFACE

3.3.11.1.1 Service
The PPPoE Client (TE) needs to be able to specify the type of service desired. The
SDU shall parse the first part of the Service Descriptor to determine which this is:
Service Description
SBB SwiftBroadband
MPDS Swift 64 MPDS
ISDN 64K UDI CS Call

3.3.11.2 Channel
The PPPoE Client (TE) may wish to direct the request to a specific channel.
If no channel number is provided, the SDU is free to provide the service on whatever
channel it deems appropriate.
If a channel is specified in the string, only this channel is considered for the service.
To provide an order of preference (such as “use channel 2 if available, but fall back
to channel 1 if it’s not available”), the “Hunt Group” functionality should be used.
Example: SBB-2
3.3.11.3 Parameters
Parameters are dependent on the service being requested.
Parameters provided as part of a PPPoE string will have precedence over
configuration provided by an ORT or factory defaults.
3.3.11.3.1 Parameters Field for SBB
This documents the parameters field for the SBB call type. If no parameters are
supplied, the default service level will be supplied (usually BACKGROUND, but this
could be overridden through an ORT parameter).
SBB Option Name Description
BACKGROUND Places a Primary Background PDP Context
STREAM8K Places a Primary Streaming class PDP Context at the data rate of 8k
STREAM16K Places a Primary Streaming class PDP Context at the data rate of 16k
STREAM32K Places a Primary Streaming class PDP Context at the data rate of 32k
STREAM64K Places a Primary Streaming class PDP Context at the data rate of 64k
STREAM128K Places a Primary Streaming class PDP Context at the data rate of 128k
XSTREAM Places a Primary Streaming class PDP Context with a dedicated 200 kHz bearer
AT String This allows the TE PPPoE client to enter a full AT Context activation string. The
letters “AT” must be present and the command string need to specify both
CGEQREQ and CGEQMIN to ensure the desired QoS is provided.

Example of full PPPoE service name string:

SBB:AT+CGDCONT=1,"bgan.inmarsat.com";+CGEQREQ=1,1,64,64,64,64,2,0,“0
E0”,”0E0”,3,0,0;+CGEQMIN=1,1,64,64,64,64,2,0,“0E0”,”0E0”,3,0

Example of full PPPoE service name string for X-Stream:

SBB:AT+CGDCONT=1,"bgan.inmarsat.com";+CGEQREQ=1,1,512,512,512,512,2
,0,“0E0”,”0E0”,3,0,0;+CGEQMIN=1,1,512,512,512,512,2,0,“0E0”,”0E0”,3,0
ARINC CHARACTERISTIC 781 – Page 192

ATTACHMENT 5
ETHERNET INTERFACE

3.3.11.3.1.1 SBB Options (optional)

Although defaults will usually be adequate, it is sometimes necessary to specify a
user name, password and/or APN while starting a SBB PPPoE session. These can
be passed either by supplying a full AT Context activation string (see above), or by
appending these tagged options at the end with the syntax @tag=value:
Tag Value
USER User Name
PASS Password
APN Access Point Name

For example: SBB:BACKGROUND@USER=myuser@APN=bgan.inmarsat.org

These are equivalent to injecting these parameters into the AT Context activation’s
+CGDCONT command.
This syntax extension is optional, and may not be present in all boxes. Applications
which need to be compatible with a variety of SDUs (including those which predate
this extension) should instead provide AT command script.
Manufacturers may add new tags following the same @tag=value convention.
Unknown tags should be ignored.
No mechanism is defined to programmatically determine which tags are supported.
3.3.11.3.2 Parameter Field for MPDS
This documents the Option field for the MPDS call type. Presenting it is optional
MPDS Option Name Description
“AT String” This allows the TE PPPoE client to enter a full AT Context activation string.

3.3.11.3.3 Parameter Field for ISDN

This documents the Option field for the ISDN call type. An option must always be
presented for ISDN service.

ISDN Option Name Description

Dial Number This allows the TE PPPoE client to enter a dial string for the CS call.
The trailing pound (#) character is optional.

Example of full PPPoE service name string:

ISDN:011555555555#

3.3.11.4 Paragraph not used

3.3.11.5 Hunt Group Syntax for Service Names
This feature is for use where the SDU may not support the preferred service and the
PPPoE Client is willing to connect with another service. The PPPoE Client will
specify a service name that conforms to the Hunt Group Syntax.
To do this, specify multiple Service Descriptor strings separated by the three
characters: {?}.
Example:
SBB-1:STREAM128K {?}ISDN-2:28# {?}MPDS-2
 ARINC CHARACTERISTIC 781 – Page 193

ATTACHMENT 5
ETHERNET INTERFACE

The SDU will treat this request as being one for the first service it deems available
(i.e.: one which it would respond with a PADO in response to a PADI). The SDU will
not automatically attempt the next service in the list in the event the selected service
fails (for example, the SDU thought SBB was available, but it failed due to network
congestion).
3.3.12 Offered Service-Name
PPPoE must, in response to a PADI for an available service, provide all available
services. Since it is not possible to provide every possible combination of every
service with every set of parameters, the PADO is only expected to provide:
• Firstly, the Service-Name as requested (complete with parameters) as per
RFC2516 requirements.
• All combination of Service and Channel (see Service Request description)
that is available.
The SDU is free to offer services beyond this required list. The list may be cut short if
there is insufficient space in the Ethernet frame to provide a full list. Because of this
limitation, PADI is not a recommended way to get a list of available services; SNMP
should be used instead.
ARINC CHARACTERISTIC 781 – Page 194

ATTACHMENT 5
ETHERNET INTERFACE

4.0 PDP CONTEXT CONTROL

The following describes three options for interfacing a TE to a BGAN SDU utilizing
PPPoE.
4.1 No Out of Band Control Line
This section details how a TE should operate with the SDU when the TE does not
employ a control line.
4.1.1 Interface Stage 1 Implementation (No Control Line) Single TE
This section documents the relationship between a single TE and a SDU, where the
TE does not employ a control line. The PDP context can be set up and initiated
either by the use of ORT profiles stored at the SDU, or by placing a full context
definition AT string in the PADR PPPoE message.

Router/TE
Stage 1, No Control Line, Single User

4.1.2 Interface Stage 1 Implementation (No Control Line) Multi-User

The following shows the relationship between a single TE and a SDU, but with
multiple Primary PDP contexts open. Again, each primary context is initiated then
supported in a separate PPPoE Session.

Router/TE SDU
Stage 1, No Control Line, Multiple PPPoE Sessions
 ARINC CHARACTERISTIC 781 – Page 195

ATTACHMENT 5
ETHERNET INTERFACE

4.2 Out of Band Control Line

4.2.1 Control Line Concept and Stack Diagram
The ability to readily modify and initiate additional secondary PDP contexts is a
required feature of a scaleable SwiftBroadband based system. The following
introduces and explains the concept of an ‘out of band control line’ between TE and
SDU.
Using PPPoE as an interface mechanism between a TE and a SDU does have
limitations. The PDP context definition, QoS and activation AT command strings
have to be presented together via the PADR tag during the initial PPPoE Active
Discovery Phase. Once this phase is complete, then no further transport mechanism
is available. This does pose a problem. Should the need arise for further TE to SDU
transaction such as establishing a Secondary Context and Traffic Flow template,
then PPPoE itself is not sufficient. This limitation highlights the need for a dedicated
out of band TE to SDU control line.
To address this limitation, a Telnet session shall be used at the application layer to
handle the AT commands for the purpose of implementing a control line. This
requires the SDU to implement a Telnet server to pass AT commands to the SDU,
and a TE with a Telnet based application to interact with it.

MNN
Protocol Stack for a TE to SDU Control Line

4.2.2 Interface Stage 2 Implementation (With Control Line)

Router/TE SDU
Stage 2, Control Line Added, Single PPPoE Session
ARINC CHARACTERISTIC 781 – Page 196

ATTACHMENT 5
ETHERNET INTERFACE

In addition to the standard PPPoE handler, a Command Line Interface (CLI) client is
required on both the TE and SDU, as is a TFT handler. The CLI handler, via the
command line, is used to pass further ‘AT’ commands to the SDU. As previously
discussed, this facilitates PDP context modification and also provides a mechanism
for creating secondary PDP contexts. The TFT handler has to be included in order to
interpret the TFT as passed via the control line, and then route the upstream IP
traffic between any active PDP contexts. The full format of the UT and GGSN TFT is
described in 3GPP 27.00.7
4.2.2.1 Pairing of PPPoE Session and PDP Contexts
The use of PPPoE makes it possible to route the IP traffic from multiple PDP
contexts via a single virtual PPPoE interface. It is considered that each Primary
context and its associated Secondary contexts must share a single PPPoE session.
This scheme is shown in the next figure.

Router/TE SDU
Control Line 1
CLI CLI
Client Control Line 2 Client

Control Line 3

Stage 2, Control Line Added, Multiple Contexts/PPPoE Sessions Sharing

In the previous diagram, the SDU has seven active contexts. Following the
convention described, three PPPoE sessions are required. This scheme should also
be used with a stage 1 implementation as well, where each separate primary context
would therefore have its own PPPoE session.
The number of control lines shown in the diagram is not mandatory.
 ARINC CHARACTERISTIC 781 – Page 197

ATTACHMENT 5
ETHERNET INTERFACE

4.2.3 Stage 3 Implementation

As a further development, using the same interface as in the previous section, it may
be desirable for a single/multiple SDUs to support multiple router/TEs. The diagram
below shows such a configuration.

SDU

Router/TE

CLI CLI
Control Line
Client Client

PPPoE/AT PPPoE/AT TFT P

PPPoE
H dl
Stage 3, Multiple Router/TE’s With a Single SDU
It is possible that each router/TE could be connected to the SDU via separate
physical Ethernet ports and also use pre-defined separate SDU channel cards. This
arrangement could be used to separate cabin and cockpit connections for instance.
As with previous interface concepts the number of control lines employed is optional,
and could be one or many.
4.2.4 Telnet Server
The SDU shall implement a Telnet Server. Refer to RFC 854. The Server should
allow at least one TCP client session for each primary PDP context which can be
brought up. This is to allow each primary to be controlled via its own session.
None of RFC854 is required to support the interface defined in UMTS 27.007, but it
won’t conflict with it either. The term “telnet” is retained in this document for
historical purposes.
If a product already has a telnet service running on port 23, port 22222 is used as a
fallback port. A client implementation should try 22222 first, and then port 23 to
avoid having to parse an unexpected interface.
4.2.4.1 AT Handler
The TCP session shall be implemented to accept UMTS TS 27.007 commands and
defined extensions for the purpose of command and control of Secondary PDP
Context and Traffic Flow Templates.
ARINC CHARACTERISTIC 781 – Page 198

ATTACHMENT 5
ETHERNET INTERFACE

4.2.4.2 Welcome Message

The TCP session may contain a welcome message sent by the SDU upon initial
connection. This message should not exceed a few lines.
A client application should discard this data before issuing AT commands.
COMMENTARY
Provisions should be included in the terminal to disable or modify the
welcome message.
4.2.4.3 Local Echo
An application can send an “ATE0” command to turn echo off. “ATE1” can be used
to turn in back on. 2
4.2.5 Control Line IP Addressing
The TE shall know the IP address of the SDU(s). The SDU shall derive its IP
address from the ORT.
Optionally the SDU may be configured via the ORT to obtain its IP address from a
DHCP server. In this scenario, the TE shall address the SDU(s) via Host Name. This
implies that there is a mechanism for name resolution, such as DNS.
4.2.6 Pairing of Control and Data Lines
It is not suggested that there be any mandated matching or pairing of PPPoE
session/PDP Contexts and the control line. It is desirable that a single control line be
capable of addressing multiple and single contexts. See IPDS in AT Command set.
4.3 Scaling PDP Contexts Concepts
Presented below are four examples of how one might wish to scale the BGAN
service mid connection:
1. Replacing a primary context with a new primary context
2. Adding an additional primary
3. Adding an additional secondary
4. Modifying an existing primary or secondary context
In the following simplified examples an initial Primary PDP context of streaming class
32 kbps is negotiated and activated via the initial PPPoE connection. The need
arises for a higher bandwidth streaming class connection.

2
The default echo state is currently undefined. Some manufacturers have it on (as per V.250) while others have opted to have it off (as
per Internet service convention). Applications which need it in one specific state should send an appropriate command to put it in the
desired state upon connection and be ready to discard potential echo (i.e., a response line which starts with AT).
 ARINC CHARACTERISTIC 781 – Page 199

ATTACHMENT 5
ETHERNET INTERFACE

4.3.1 Scaling a PDP Context without a Control Line

4.3.1.1 Replacing a Primary Context
In this scenario no out of band control line to the SDU is available. The only method
available to scale up the bandwidth is to specify and activate a new primary context.
Here, the current PDP context is terminated and a new higher bandwidth context is
defined and activated. Though this is a valid method of scaling up the bandwidth
available, it does require that the controlling server handling IP traffic have the ability
to buffer the IP traffic in order to suspend the session whilst the new context is
initiated. Ideally the same IP address would be allocated to the new context by
means of a static IP request in the PDP context definition. Though the actual time to
carry out this exchange is minimal, this is unacceptable to certain traffic types,
transcoded GSM voice calls and other application types may be intolerant of the
momentary interruption in end-to-end IP connectivity.

32 kb/s streaming class Primary PDP context

PPPoE 1

PPPoE 1 Signal PDP context terminate ‘PAD T’

PPPoE 1 Define Primary PDP context PAD R

<‘AT+ CGDCONT…’>
Activate Primary Context

PPPoE 1 64 kb/s streaming class Primary PDP context

Scaling with New Primary Context

4.3.1.2 Adding an Additional Primary Context

In this example, bandwidth scaling is achieved by defining and activating an
additional primary context. The IP addresses of the two connections will not be the
same. This calls for the ‘management entity/server’ to provide intelligent bandwidth
sharing capabilities in order to make best use of the aggregate bandwidth available.

PPPoE 1 32 kb/s streaming class Primary PDP context

PPPoE 2 Define Primary PDP context ‘AT + CGDCONT…’

Activate Primary Context

.
.

PPPoE 1 32 kb/s streaming class Primary PDP context

PPPoE 2 32 kb/s streaming class Primary PDP context

Scaling with Additional Primary Context

ARINC CHARACTERISTIC 781 – Page 200

ATTACHMENT 5
ETHERNET INTERFACE

4.3.2 Scaling a PDP Context with a Control Line

4.3.2.1 Additional Secondary Context
This next example shows a secondary context being attached to the initial primary
context. Though the two contexts will share the same IP address, the necessity for a
Traffic Flow Template (TFT) may be problematic. The TFT specifies a method of IP
traffic separation and routing across the two contexts. So, if it is a single application
that requires the larger scaled up bandwidth, and then enforced traffic separation, by
port address for example, is not desirable.

PPPoE 1 32 kb/s streaming class Primary PDP context

Control Line Define MT Traffic Flow Template (TFT) ‘AT_ITFT…’

Define GGSN Traffic Flow Template (TFT) ‘AT+CGTFT…’
Define Secondary PDP context; ‘;AT+CGDSCONT…’
Activate Secondary Context
.
.
TFT
PPPoE 1 Handler 32 kb/s streaming class Primary PDP context

32 kb/s streaming class Secondary PDP context

Scaling with Additional Secondary Context

4.3.2.2 Modify PDP Context

With a control line available, it is possible to signal to ‘Modify’ the current PDP
context by using the +CGCMOD command and hence scale up the available
bandwidth.
As the mobile essentially maintains the same Primary context there is no change of
IP address that may necessitate more complex routing schemes in order to maintain
user data continuity.

PPPoE 1 32 kb/s streaming class Primary PDP context

Modify PDP Context ‘AT+CGEQREQ,
Control line AT+CGCMOD…’
.
.
PPPoE 1 64 kb/s streaming class Primary PDP context

Scaling By Modifying the Primary Context

 ARINC CHARACTERISTIC 781 – Page 201

ATTACHMENT 5
ETHERNET INTERFACE

4.4 AT Commands
Editor’s comment: The AT command section of this document has been replaced
with a table that defines the supported AT commands that are documented in 3GPP
27.0007 with the exception of the ARINC 781 defined AT commands. This change
is not marked with track changes in order to improve readability.
4.4.1 AT Command Interface Support
M = Mandatory
O = Optional
N = Not required/Not defined or Not Supported
Table 1 - Inmarsat UT-TE Interface Spec and ARINC 781 Cross Reference [D.G.2]
Inmarsat BGAN ARINC 781
3 GPP AT
Description UT-TE Interface Attachment
Command
Spec 5
SMS SERVICE - GENERAL
CONFIGURATION AT-COMMANDS (3GPP
TS 27.005)
+CSMS Select Message Service M O
+CPMS Preferred Message Storage M O
+CMGF Message Format M O
+CMS ERROR Message Service Failure Result Code M O
MESSAGE CONFIGURATION AT-
COMMANDS (3GPP TS 27.005)
+CSCA Service Centre Address M O
+CSMP Set Text Mode Parameters O O
+CSDH Show Text Mode Parameters O O
+CSAS Save Settings O O
+CRES Restore Settings O O
MESSAGE RECEIVING AND READING AT-
COMMANDS (3GPP TS 27.005)
+CNMI New Message Indications to TE M O
+CMGL List Messages M O
+CMGR Read Messages M O
MESSAGE SENDING AND W RITING AT-
COMMANDS (3GPP TS 27.005)
+CMGS Send Message M O
+CMSS Send Message from Storage M O
+CMGW Write Message to Memory M O
+CMGD Delete Message M O
GENERAL AT-COMMANDS (3GPP TS
27.007)
+CGMI Request Manufacturer Identification M M
+CGMM Request Model Identification M M
+CGMR Request Revision Identification M M
+CGSN Request Product Serial Number M M
Identification
+CSCS Select TE Character Set O O
ARINC CHARACTERISTIC 781 – Page 202

ATTACHMENT 5
ETHERNET INTERFACE

Inmarsat BGAN ARINC 781

3 GPP AT
Description UT-TE Interface Attachment
Command
Spec 5
+CIMI Request International Mobile Subscriber M M
Identity
+CMUX Multiplexing mode O O
ITU-T V.25TER TE-TA INTERFACE
COMMANDS
S0 Number of rings until auto-answer N O
S2 Escape character N O
S3 Command line termination character M O
S4 Response formatting character M O
S5 Command line editing character M O
S6 Pause before blind dialing N O
S7 Connection completion timeout N O
S8 Comma dial modifier time N O
S10 Automatic disconnect delay N O
S12 Escape guard time (0.02s) N O
A Go on-line in answer mode N O
D Go on-line in originating mode N O
E Echo M O
H Hang up N O
O Return to on-line state N O
P Set pulse dial N O
Q Result code display M O
S S registers N O
T Set tone dial N O
V Select word or digit result code M O
X Select result codes M O
&C Select DCD options M O
&D Select DTR options M O
&V View configuration profile N O
&W Store current configuration profile N O
= Write to selected S register N O
? Read from selected S register N O
+IPR Fixed TE data rate O O
+ICF TE-TA character framing O O
+IFC TE-TA local flow control O O
+ILRR Report local TE-TA data rate O O
ITU-T V.25TER GENERIC TA CONTROL
COMMANDS
Z Reset M O
&F Fetch factory defaults M O
I Request Manufacturer Information O O
+GMI Request Manufacturer Identification M O
+GMM Request Model Identification M O
+GMR Request Revision Identification M O
+GSN Request Product Serial Number O O
+GOI Request ISO Identification O O
+GCAP Request Overall Capabilities of TA M O
+GCI Selects the country of installation O O
CALL CONTROL COMMANDS AND METHODS
D ITU-T V.25ter dial command M O
 ARINC CHARACTERISTIC 781 – Page 203

ATTACHMENT 5
ETHERNET INTERFACE

Inmarsat BGAN ARINC 781

3 GPP AT
Description UT-TE Interface Attachment
Command
Spec 5
+CHUP Hangup call O O
+CEER Extended error report O O
+CSDF Settings date format O O
+CSIL Silence Command O O
+CSTF Settings time format O O
. NETWORK SERVICE RELATED AT-
COMMANDS
+CNUM Subscriber Number O O
+CREG Network registration M O
+COPS PLMN Selection O O
+CLCK Facility Lock M O
+CPWD Change Password M O
+CLIP Calling line identification presentation O O
+CLIR Calling line identification restriction O O
+COLP Connected line identification presentation O O
+CDIP Called line identification presentation O O
+CCUG Closed User Group O O
+CCFC Call forwarding number and conditions O O
+CCWA Call waiting O O
+CHLD Call related supplementary services O O
+CTFR Call deflection O O
+CUSD Unstructured Supplementary Service O O
Data
+CAOC Advice of Charge O O
+CSSN Supplementary service notifications O O
+CLCC List current calls O O
+CAEMLPP eMLPP Priority Registration and O O
Interrogation
+CPPS eMLPP subscriptions O O
+CFCS Fast call setup conditions O O
+CAAP Automatic answer for eMLPP Service O O
MOBILE TERMINATION CONTROL AND
STATUS AT-COMMANDS (3GPP TS
27.007)
+CPAS Phone Activity Status O O
+CFUN Set Phone Functionality M O
+CPIN Enter PIN M O
+CBC Battery Charge M O
+CSQ Signal Quality O O
+CMEC Mobile Termination control mode O O
+CKPD Keypad control O O
+CDIS Display control O O
+CIND Indicator Control O O
+CMER Mobile Termination event reporting M O
+CCLK Clock O O
+CSIM Generic SIM access O O
+CRSM Restricted SIM access M O
+CALM Alert sound mode O O
ARINC CHARACTERISTIC 781 – Page 204

ATTACHMENT 5
ETHERNET INTERFACE

Inmarsat BGAN ARINC 781

3 GPP AT
Description UT-TE Interface Attachment
Command
Spec 5
+CRSL Ringer sound level O O
+CMUT Mute control O O
+CACM Accumulated call meter O O
+CSVM Set Voice Mail Number O O
+CMAR Master Reset O O
+CLAC List all available AT commands N O
MOBILE EQUIPMENT ERRORS
+CMEE Report Mobile Termination error M O
PDP CONTEXT AT-COMMANDS (3GPP TS
27.007)
+CGDCONT Define PDP Context M M
+CGDSCONT Define Secondary PDP Context M M
+CGTFT Traffic Flow Template M M
+CGQREQ Quality of Service Profile (Requested) O M
+CGQMIN Quality of Service Profile (Minimum O O
acceptable)
+CGEQREQ 3G Quality of Service Profile, Requested M M
+CGEQMIN 3G Quality of Service Profile, Minimum M M
+CGEQNEG 3G Quality of Service Profile, Negotiated M M
+CGATT PS Attach or Detach O M
+CGACT PDP Context Activate or Deactivate M M
+CGCMOD PDP Context Modify M O
+CGDATA Enter data state O O
+CGPADDR Show PDP Address O M
+CGCLASS GPRS mobile station class O O
+CGEREP Packet Domain Event Reporting M M
+CGREG GPRS Network Registration Status O M
+CGSMS Select service for MO SMS messages O O
MODEM COMPATIBILITY COMMANDS
D*98# Request Packet Domain IP service M O
VOICE CONTROL COMMANDS
+VTS DTMF and tone generation O O
BGAN SPECIFIC AT-COMMANDS
_IPOINT Antenna Pointing M O
_IGPS GPS Location Information M O
_INIS Network Interface Status O O
BLUETOOTH COMMANDS
_IBLTH Manage Bluetooth Pairing O O
_IBTIF Configure UT Bluetooth Interface O O
_IBTINQ Sets the Bluetooth Interface in Device O O
Inquiry Mode
ADDITIONAL BGAN COMMANDS
_ITFT UT Traffic Flow Template M M
_ITEMP UT Temperature M O
_ILOG Retrieve UT log file N O
_ISLEEP UT Sleep Mode Timeout O O
_IMETER Call Metering M O

_ISIG Signal quality indication M O

 ARINC CHARACTERISTIC 781 – Page 205

ATTACHMENT 5
ETHERNET INTERFACE

Inmarsat BGAN ARINC 781

3 GPP AT
Description UT-TE Interface Attachment
Command
Spec 5
_IBALARM Report the Alarm State of the Terminal M O
_IBNOTIFY Control the sending of unsolicited result O O
codes
_ICSEV Circuit Switch Domain Event reporting O O
ARINC 781 Attachment 5
2
_IPDPS Binding Telnet session to PPPoE context N M

Note: Former Section 4.4.1.1 - AT Command Timeouts was deleted

for further consideration in the next supplement.
4.4.2 ARINC 781 Defined AT Commands
4.4.2.1 IPDS AT Command Extension for Binding a TCP Session to PDP Primary Context
The AT command for binding between a TCP Session and one or more PPPoE
Sessions is “_IPDPS.”
• “_I” means it is part of the Inmarsat BGAN AT command extension.
• “PDPS” means Primary PDP Context Select.
The purpose of this select command is to select a particular PPPoE Session from
one or more PPPoE Sessions established with the Server.
This AT command / response shall be used over a TCP session; it shall not available
via PPPoE.
Command Possible response(s)
_IPDPS=<IP_addr> OK
Set Command
_IPDPS=PPPoE_Session_ID ERROR
_IPDPS:
Read Command _IPDPS?
<PPPoE_Session_ID>,<IP_addr>
Test Command _IPDPS=? ERROR
Unsolicited result code _IPDPS: <PPPoE_Session_ID, IP_addr>

4.4.2.1.1 Set Command

The set command specifies one primary PDP to be selected with the TCP Session
that sends the set command. Each primary PDP has a corresponding PPPoE
Session ID. All subsequent PDP Context related AT commands from the TCP
Session are applicable to the specified PPPoE Session.
AT commands that are unrelated to PDP Context are not affected by the set
command.
Returns ERROR if the primary PDP does not exist.
If the primary PDP is already in use, the previous owner of the primary PDP is
notified of the loss of ownership through at spontaneous _IPDPS:0,0.0.0.0 message.
ARINC CHARACTERISTIC 781 – Page 206

ATTACHMENT 5
ETHERNET INTERFACE

The same _IPDPS:0,0.0.0.0 is also used when the call is torn down (as it is not
possible to send further commands to a call which no longer exists).
4.4.2.1.2 Read Command
The read command returns the currently selected primary PDP by the TCP
Session that sends the read command. If no PPPoE Session selected, 0, 0.0.0.0 is
returned.
4.4.2.1.3 Test Command
Not supported.
4.4.2.1.4 Unsolicited Result Code
(Section deleted as it contradicted programming model and introduced unnecessary
complexity).
4.4.2.1.5 Defined Values
<PDP_addr>: a string parameter that identifies the PPPoE by the address of the
Primary PDP Context.
Two values are possible, the PPPoE session ID or the IP address associated with
that primary PDP. The two are recognized by their format. The PPPoE session ID is
a simple number, while the IP address is an IPv4 address in the form
aaa.bbb.ccc.ddd.

4.5 Virtual Context IDs

A method of making the equipment shareable between multiple users without
requiring manual configuration or cooperating between these users is to simulate
each of them being alone on the system (as far as context IDs go).
To achieve this, the system maintains a map of requested IDs (logical IDs), versus
those actually used (actual IDs) for each user. Each user is represented by a PPPoE
session (which infers a primary PDP, which infers an IP address).
For example, a user might issue a command such as:
AT+CGEQMIN=2,1,32,32,32,32,"0E0","0E0",3,0,0
The first parameter is a secondary context ID, the second one is a primary context
ID. Assuming this user’s logical ID 1 was mapped to actual ID 10 and logical ID 2
was mapped to actual ID 17, this command would be modified to the following
before being processed by the BGAN stack:
AT+CGEQMIN=17,10,32,32,32,32,"0E0","0E0",3,0,0
Responses to commands must also go through the same mapping, to maintain the
illusion of exclusivity.
The actual numbers are effectively reserved until the user terminates the PPPoE
connection. The filter should fail (return ERROR) if there is no actual context ID
available. This should not be a problem in normal usage.

4.6 Service Name Tag

The ServiceName TAG_value shall be a concatenation of one or more of the AT
commands specified in 3GPP 27.0007. Each AT command shall be separated by a
semicolon. The entire ServiceName TAG_value string is not null terminated.
 ARINC CHARACTERISTIC 781 – Page 207

ATTACHMENT 5
ETHERNET INTERFACE

The following rules apply:

• The ServiceName TAG_value shall include exactly one +CGDCONT
• Optionally the service name tag may include one or more +CGDSCONT
commands to create secondary contexts. For each +CGDSCONT there shall
be at least one +CGTFT command to associate a traffic flow template with
the secondary context.
• Optionally the ServiceName TAG_value may include commands such as
+CGEQREQ to specify the quality of service
 ARINC CHARACTERISTIC 781 – Page 208

ATTACHMENT 5
ETHERNET INTERFACE

5.0 Editor’s Comment

This section describes the mechanism for how the satcom systems provide status
information to the client systems (e.g., a cabin server).
5.1 Public Standards
5.1.1 Institute of Electrical and Electronics Engineers Documents

Table 2 - IEEE Documents

Reference Title / Content
IEEE 802.3 10 base T full duplex

5.1.2 Internet Engineering Task Force Standard Documents

Table 3 - Applicable IETF Standards and RFC’s

IETF STD Reference Title / Content Relevant
STD0016 IETF - RFC 1155 Structure and Identification of Management Information for TCP/IP-based Yes
Internets
IETF - RFC 1212 Concise MIB Definitions Yes
STD0017 IETF - RFC 1213 Management Information Base for Network Management of TCP/IP-based Yes
internets: MIB-II
STD0043 IETF - RFC 1042 Standard for the transmission of IP datagrams over IEEE 802 networks Yes
STD0051 IETF - RFC 1661 The Point to Point Protocol (PPP) Yes
STD0058 IETF - RFC 2578 Structure of Management Information Version 2 (SMIv2) Yes
IETF - RFC 2579 Textual Conventions for SMIv2 Yes
IETF - RFC 2580 Conformance Statements for SMIv2 Yes
STD0062 IETF - RFC 3411 An Architecture for Describing Simple Network Management Protocol Yes
(SNMP) Management Frameworks
IETF - RFC 3412 Message Processing and Dispatching for the Simple Network Management Yes
Protocol (SNMP)
IETF - RFC 3413 Simple Network Management Protocol (SNMP) Applications Yes
IETF - RFC 3414 User-based Security Model (USM) for version 3 of the Simple Network No
Management Protocol (SNMPv3)
IETF - RFC 3415 View-based Access Control Model (VACM) for the Simple Network No
Management Protocol (SNMP)
IETF - RFC 3416 Version 2 of the Protocol Operations for the Simple Network Management Yes
Protocol (SNMP)
IETF - RFC 3417 Transport Mappings for the Simple Network Management Protocol (SNMP) Yes
IETF - RFC 3418 Management Information Base (MIB) for the Simple Network Management Yes
Protocol (SNMP)
none IETF - RFC 1471 The Definitions of Managed Objects for the Link Control Protocol of the Yes
Point-to-Point Protocol
none IETF - RFC 2516 A Method for Transmitting PPP Over Ethernet (PPPoE) Yes
none IETF - RFC 3339 Date and Time on the Internet: Timestamps Yes
none IETF - RFC 3410 Introduction and Applicability Statements for Internet-Standard Management Yes
Framework

Table 4 -
 ARINC CHARACTERISTIC 781 – Page 209

ATTACHMENT 5
ETHERNET INTERFACE

Useful IETF Best Common Practice Documents

IETF
Reference Title / Content
BCP
BCP0074 IETF - RFC Coexistence between Version 1, Version 2, and Version 3 of the Internet-standard
3584 Network Management Framework

5.2 Basic Structure

In a segregated environment (multiple network stacks) there is no requirement to
provide information of one stack to the other.
5.2.1 MIB-II Objects and Enterprise OID
The basic SNMP MIB II based object structure shall be defined as shown in the
following figure:

.iso(1)
└─ .org(3)
└─ .dod(6)
└─ .internet(1)
├─ .mgmt(2)
│ └─ .mib-2(1)
│ ├─ .system(1)
│ │ └─ ... (as defined in RFC1213-MIB)
│ ├─ .interfaces(2)
│ │ └─ ... (as defined in RFC1213-MIB)
│ ├─ .ip(4)
│ │ └─ ... (as defined in RFC1213-MIB)
│ ├─ .icmp(5)
│ │ └─ ... (as defined in RFC1213-MIB)
│ ├─ .tcp(6)
│ │ └─ ... (as defined in RFC1213-MIB)
│ ├─ .udp(7)
│ │ └─ ... (as defined in RFC1213-MIB)
│ ├─ .transmission(10)
│ │ └─ .ppp(23)
│ │ └─ ... (as defined in PPP-LCP-MIB as defined in RFC1471)
│ └─ .snmp(11)
│ └─ ... (as defined in RFC1213-MIB)
└─ .private(4)
└─ .enterprises(1)
└─ .aeec(13712)

Basic Used SNMP MIB Structure

The enterprise OID for all ARINC 781 related MIB’s is .aeec(13712). Each ARINC
781 MIB has to be located under this branch.
COMMENTARY
The industry already uses an alternative MIB under entry number
1.3.6.1.4.1.16727.3.3. This alternative MIB should be used for
existing SBB-only modems and client applications connecting them.
Some entries in RFC1213 are defined as read/write, although read-only is generally
desired for this implementation (for security purposes). Standard SNMP
implementations may not have a simple mechanism to make these read-only. For
the time being, this issue is left unresolved (left up to the vendor).
ARINC CHARACTERISTIC 781 – Page 210

ATTACHMENT 5
ETHERNET INTERFACE

5.2.2 MIB Entry Point

The level 1 OID’s under that branch will be managed by the AEEC NIS group. The
primary structure of the MIB entry is defined as shown in the following figure:

.iso(1)
└─ .org(3)
└─ .dod(6)
└─ .internet(1)
└─ .private(4)
└─ .enterprises(1)
└─ .aeec(13712)
└─ .arincSwift(781)
└─ ...

MIB Entry Point

All definitions in this document are related to the MIB Entry Point. Inside this
definition all structures will only be shown with the shortened prefix
".arincSwift(781)".
5.2.3 General MIB Branches
The basic Structure shall be defined as shown in the following figure:

Figure to be defined in a future supplement

ARINC Swift MIB Structure

 ARINC CHARACTERISTIC 781 – Page 211

ATTACHMENT 5
ETHERNET INTERFACE

5.3 Detailed MIB Definition

5.3.1 Object Types
This ARINC 781 MIB uses some additional Types, which are not defined in the
SNMP and MIB standards. All used Types are described in this section. Each type
definition has a prefix of AS (which means arinc swift).
5.3.1.1 Health Status Type Definition
The SNMP Type ASHealthState indicates the health status of the system, a unit
or applications hosted on units. The possible values are:

Table 5 - Health Status Type Definition

SNMP Type Number Description
pass 1 The system is working.
fail 2 The system has an error.
absent 3 The system is not reachable.

5.3.1.2 Test Status Type Definition

The SNMP Type ASTestState indicates the status of an initiated test or a finished
test. It is an enumerated Integer value with the following Structure:
Table 6 - Test Status Type Definition
SNMP Type Number Description
pass 1 The test was successfully finished.
fail 2 The test was stopped with an error.
ongoing 3 The test is still running.
aborted 4 The test was stopped before it had a chance to
complete.

5.3.1.3 Link Status Type Definition

The SNMP Type ASLinkState indicates the status of a link (e.g. Ethernet, context,
etc.). It is an enumerated Integer value with the following Structure:
Table 7 - Link Status Type Definition
SNMP Type Number Description
up 1 Link is working correct and in use
down 2 Link is working correct but down
unconnected 3 No cable is plugged to the port
errorHW 4 Link has a hardware error

5.3.1.4 Satellite Lock State Type Definition

The satellite Lock State will be reflected by the Type ASSatLockState. It is an
enumerated Integer value with the following Structure:
Table 8 -
ARINC CHARACTERISTIC 781 – Page 212

ATTACHMENT 5
ETHERNET INTERFACE

Satellite Lock State Type Definition

SNMP Type Number Description
inLock 1 This value indicates that the satcom system is
connected to a satellite and correctly decoding
receives data.
notInLock 2 This value indicates that the satcom system is not
connected to a satellite or that it is connected, but
is not correctly decoding received data.

5.3.1.5 Restart Reason Type Definition

The restart reason of the unit or their software will be reflected by the Type
ASRestartReason. It is an enumerated Integer value with the following
Structure:
Table 9 - Restart Reason Type Definition
SNMP Type Number Description
longPowerCut 1 The system has been reset due to a long power
interruption
shortPowerCut 2 The system has been reset due to a short power
interruption
safetyTest 3 The system has been reset due to a safety test
lruReconfig 4 The system has been reset due to a reconfiguration
dataloadCompl 5 The system has been reset after a completed data loading
process
dataloadComplCSW 6 The system has been reset after a completed data loading
process including CSW
fpButtonRequest 7 The system has been reset after pushing a reset button
snmpTestRequest 8 The system has been reset after a Self-Test request via
SNMP
atCommand 9 The system has been reset after a request per AT
command
maintEquipSelfTest 10 The system has been reset after a maintenance
equipment self-test
maintEquipDefSet 11 The system has been reset after resetting the default
settings during maintenance process.
snmpResetRequest 12 The system has been reset after a SNMP reset request.
maintEquipRequest 13 The system has been reset after an equipment
maintenance request
osFailDetect 14 The system has been reset after an operating system
failure detection
externalDiscrete 15 The system has been reset after a discrete request
 ARINC CHARACTERISTIC 781 – Page 213

ATTACHMENT 5
ETHERNET INTERFACE

5.3.1.6 LRU Thermal State Type Definition

The thermal state of a LRU will be reflected by the Type ASUnitThermState. It is
an enumerated Integer value with the following Structure:
Table 10 - LRU Thermal State Type Definition
SNMP Type Number Description
normal 1 The unit is working within its normal operational
temperature
overheat 2 The unit is non-critical working outside its normal
operational temperature
shutdown 3 The unit is critical working outside its normal
operational temperature and has to be shutdown.

5.3.1.7 Thermal Antenna State Type Definition

The thermal antenna state will be reflected by the Type ASAntThermState. It is an
enumerated Integer value with the following structure:
Table 11 - Thermal Antenna State Type Definition
SNMP Type Number Description
ok 1 The antenna works fine
class1 2 The thermal antenna state is in class1 mode
class3 3 The thermal antenna state is in class3 mode

5.3.2 Mandatory Branches

The Structure is divided into five mandatory main branches, which are shown in the
following figure:

.arincSwift(781)
├─ .asVersion(1)
├─ .asLinks(2)
├─ .asSystem(3)
├─ .asUnits(4)
└─ .asUserDefArea(5)

Main Branches
5.3.2.1 MIB Version Related Objects
The .asVersion(1) folder contains only two objects. The first object is the major
version number. The second object is the minor version number. Both objects are
from the Type Integer32 and the sub version is limited to the range from 0 to 99.
The following table shows the object details of this folder:
Table 12 -
ARINC CHARACTERISTIC 781 – Page 214

ATTACHMENT 5
ETHERNET INTERFACE

Version Object Details

Object Identifier Type Range Description
.asvMajor(1) Integer3 This object defines the major version of the arincSwift MIB
2 definition. The current major version number is 1.
.asvMinor(2) Integer3 0..99 This object defines the minor version of the arincSwift MIB
2 definition. The current minor version number is 0.

5.3.2.2 Link Related Objects

The .asLinks(2) folder contains the most important objects to monitor the satellite
link. The objects are grouped in the two subfolders showed in the following figure.

.arincSwift(781)
├─ ....
└─ .asLinks(2)
├─ .aslServices(1)
└─ .aslInfos(2)

Link Related Subfolders

5.3.2.2.1 Service Availability Related Sub Branch
5.3.2.2.1.1 Object Structure
The first subfolder in the .asLinks(2) branch is .aslServices(1). It contains
one table and one Integer32 object. The integer object is called
.aslsNumbers(1). It indicates the number of entries in the table and has a range
from 0 to 100.
The table object is called .aslsTable(2) and shows the available services, which
a client can currently establish. The table is a sequence of the column entries shown
in Table 13.
It is not required to have channel-specific entries. If these are present, they must
appear after the general ones.
For BGAN services, each streaming class (Stream32K, Stream64K…) will have a
separate entry, to show the availability of each of these services.
Table 13 -
 ARINC CHARACTERISTIC 781 – Page 215

ATTACHMENT 5
ETHERNET INTERFACE

Service Related Object Details

Object Identifier Type Range Unit Description
.aslsIndex(1) Integer32 1..32767 none This column contains a unique identifier
for this entry.
.aslsName(2) DisplayString 0..63 none This column contains the name of the
service in the following form:
“Service:Subservice.”
These are expected to match the PPPoE
Service-Names. User-defined services
and sub-services will not necessarily be
present in this table, as it may not be
possible to determine their availability.
.aslsInUse(3) Integer32 0..127 none Number of instances of this service
currently in use.
.aslsAvailable(4) Integer32 0..127 none Number of instances potentially
remaining.
Note that number of remaining instances
are not necessarily max-in_use, as other
services may consume resources
required by this service.
Due to system dynamics, there is no
guarantee that the user will be able to
place this many additional calls, even if it
is alone on the system. This value can be
seen as a best-case scenario.
.aslsMaxChannels(5) Integer32 0..127 none This value indicates, how many instances
of this service type are maximum
available.
Must be zero for invalid entries.
.aslsMaxBWPerChannel(6) Interger32 0..32767 kbps This value indicates the maximum
bandwidth available on one instance of
this service.
.aslsMaxBW(7) Integer32 0..32767 kbps This value indicates the maximum
bandwidth available to all instances of this
service.

5.3.2.2.1.2 Object Behavior

The value of the .aslsNumbers(1) object has to be constant.
The table has to be initialized after the start of the unit. It has to contain all services
that the unit can support.
The following table shows a content example, how the service availability can look
like for a two channel unit:
Table 14 - Example Link Service Table Content 3
Row .aslsIndex(1) .aslsName(2) .aslsAvailabile(4) .aslsMaxChannels(5) .aslsMaxBW(7)
1 1 ISDN 0 4 256
2 2 MPDS 0 2 128
3 3 SBB:BACKGROUND 22 22 864
4 4 SBB:STREAM32K 14 14 448

3
In practice, there will be many more entries than this. There will be separate entries for each streaming class, and separate entries for
each channel (i.e.: SBB-2:STREAM64K). These names follow the PPPoE service-name convention. SDUs may include non-data
services (such as voice) as this information would help diagnose scenarios where services are not available due to non-data usage of
the SDU.
ARINC CHARACTERISTIC 781 – Page 216

ATTACHMENT 5
ETHERNET INTERFACE

Row .aslsIndex(1) .aslsName(2) .aslsAvailabile(4) .aslsMaxChannels(5) .aslsMaxBW(7)

5 5 SBB:STREAM64K 6 6 384
6 6 SBB:STREAM128K 2 2 256
7 7 SBB:XSTREAM 1 2 512

The value of .aslsNumbers(1) is 4 in this case. The content of the table indicates
that Swift 64 services MISDN and MPDS can be supported by the unit, but are not
available and that the SwiftBroadband services are available. The client can
establish up to 22 background channels with up to 864 kbps, up to 14 32K streaming
channels with up to 448 kbps, up to 2 128K streaming channels, or a mixture of
thereof.
If for example an application opens a 128 kbps SBB Streaming class, available
background channels will go down by one (as a primary slot is being used),
STREAM32K channels will go down by 4, etc.
5.3.2.2.2 Link Related Information Sub Branch
5.3.2.2.2.1 Object Structure
The second subfolder in the .asLinks(2) branch is .aslInfos(2). It contains
two tables and four objects.

Table 15 - Satellite Related Object Details

Object Identifier Type Range Description
.asliSatState(1) ASSatLockState This object shows, if the satellite is locked or not. The
type is an enumerated integer value.
.asliSatID(2) DisplayString 0..32 This object shows, which satellite is connected by the
Satcom system (e.g., “IOR”)
.asliSatIDNum(3) Integer32 0..63 Unique numeric identifier for the connected satellite.
.asliSatHandoverPending(8) TruthValue Set if the system believes it will need to do a handover
soon.
.asliSatNetworkName(9) DisplayString 0..16 This object indicates to which satellite network the SDU
is connected, because the satellite identification
numbers may not be unique between the different
networks (I3 and I4) Possible values should be for
example "GAN" for I3 and "BGAN" for I4.

The Integer32 object .asliActLinkEntryNumbers(4) indicates the number of

the entries in the first table and has a range from 0 to 50.
The first table object is called .asliActLinkTable(5) and shows the currently
established links.
Another Integer32 object .asliHistLinkEntryNumbers(6) indicates the
number of the entries in the second table and has an open range.
The second table object is called .asliHistLinkTable(7) and shows the
terminated links.
The tables are a sequence of the column entries shown in Table 16. The first
identifier is related to the link table for the actual links and the second identifier is
related to the link table for the history entries.
 ARINC CHARACTERISTIC 781 – Page 217

ATTACHMENT 5
ETHERNET INTERFACE

Table 16 - Link Information Table Related Object Details

Object Identifier Type Range Unit Description
.asliActLinkIndex(1) Integer32 1..32767 none This object is a unique identifier for
.asliHistLinkIndex(1) the current link entry and can be
considered a handle for the session.
With each new link, this number is to
be incremented by one, wrapping
around (but avoiding conflicts).
.asliActLinkReleaseType(2) Integer32 none This object shows the release type
.asliHistLinkReleaseType(2) of the current link as numeric codes
as described in Attachment 5,
Section 6.
.asliActLinkReleaseReason(3) DisplayString 0..128 none This object shows the reason for the
.asliHistLinkReleaseReason(3) release type in a displayable form.
.asliActLinkStatus(4) ASLinkState none This object shows if the current link
.asliHistLinkStatus(4) is up or not.
Because entries are only removed
30 seconds after going down, it is
important to check this field while
reading the active link table.
.asliActLinkChanNo(5) Integer32 0..31 none This object shows which channel is
.asliHistLinkChanNo(5) used on the card by the current link.
Might be zero if a request for service
failed before it was assigned to a
channel.
.asliActLinkContextID(6) Integer32 0..255 none In case of a SBB link, this object
.asliHistLinkContextID(6) shows which context ID is assigned
to this link. If the current link is a
swift 64 link, this entry has to be set
to zero.
These are virtual (logical) context ID
specific to that user session (tied to
a primary PDP). For primary PDPs
initiated through the normal service
names (i.e., SBB: BACKGROUND),
this number will be 1. Secondaries
will show up with the number
supplied by the user. The user could
also use a different primary ID if
initiating a SBB primary through an
AT command string. For detailed
information to the virtual context IDs
refer to Section 4.2.2.1.
.asliActLinkActualContextID(7) Integer32 0..255 none The context ID used over the air.
.asliHistLinkActualContextID(7) This ID is unique per channel card in
the system while it is active.
The association between a
ContextID and the ActualContextID
remains for the duration of the
primary PDP.
A zero indicates that the actual entry
is not mapped to a PDP context (e.g.
in case of S64 link).
ARINC CHARACTERISTIC 781 – Page 218

ATTACHMENT 5
ETHERNET INTERFACE

Object Identifier Type Range Unit Description

.asliActLinkConnectionID(8) DisplayString 0..128 none This object shows information about
.asliHistLinkConnectionID(8) the connection (e.g., initialization
string of the current link in form of
the used AT command)
If the original string was longer than
can fit in this field, it will be
truncated.
.asliActLinkNegotiatedBW(9) Integer32 0-2048 kbps This object shows the currently
.asliHistLinkNegotiatedBW(9) negotiated bandwidth of the link in
this table entry.
Variable-rate connections
(SBB:BACKGROUND, MPDS) are
best-effort connections and do not
have specifically negotiated, fixed,
symmetric bandwidth.
.asliActLinkIpAddress(10) IpAddress 0.0.0.0/0 none This object contains the IP-Address
.asliHistLinkIpAddress(10) of the current link. If this link is a
sub-link of another entry, which does
not have an own IP address (e.g., a
part of a bundle or a secondary
context), this field must contain the
address of the primary context to
which it is related.
.asliActLinkTxTrafficVol(11) Integer32 kBytes This object contains the information
.asliHistLinkTxTrafficVol(11) about the total transmitted bytes
over this link in kBytes. See Note 1.
.asliActLinkRxTrafficVol(12) Integer32 kBytes This object contains the information
.asliHistLinkRxTrafficVol(12) about the total received bytes over
this link in kBytes. See Note 1.
.asliActLinkBeamID(13) Integer32 0-255 none This object shows, which spot beam
.asliHistLinkBeamID(13) is connected by the current link.
.asliActLinkSigQual(14) Integer32 dBHz*10 This object shows the Quality in
.asliHistLinkSigQual(14) dBHz*10 of the current link.
.asliActLinkMaxSigQual(15) Integer32 dBHz*10 Expected maximum/ideal values for
.asliHistLinkMaxSigQual(15) Link Signal Quality. See Note 2.
.asliActLinkMainIndex(16) Integer32 0..32767 none If this link entry is part of bundle
.asliHistLinkMainIndex(16) (e.g., a secondary context), this
object refers the main entry (e.g., the
primary context) in this table to
which this subentry is related.
.asliActLinkServiceIndex(17) Integer32 0..100 none This object is a link to the
.asliHistLinkServiceIndex(17) aslsServiceTable by referring the
used Service. A “3” defines in
accordance with “Example Link
Service Table Contect”, that the Link
is from the type SBB:Background.
For links not related to an PPPoE
service, this value is 0.
For streaming services which don’t
fit one of the standard services, this
should point to generic SBB or to the
closest streaming class.
 ARINC CHARACTERISTIC 781 – Page 219

ATTACHMENT 5
ETHERNET INTERFACE

Object Identifier Type Range Unit Description

.asliActLinkContrInterfIndex(18) Integer32 0..32767 none This object contains the index
.asliHistLinkContrInterfIndex(18) number of the PPP control interface,
which is related to this link. It is a
crosslink into the
pppLinkStatusTable of the PPP-
LCP-MIB by referring the value of
the according
pppLinkStatusPhysicalIndex.
For links not related to PPP
connections (voice calls, for
example), this value is 0. Also zero
for secondary PDP’s.
.asliActLinkPhysInterfIndex(19) Integer32 0..32767 none This object contains the index
.asliHistLinkPhysInterfIndex(19) number of the physical interface,
where this link is related to. The
value is a crosslink into the ifTable of
the RFC1213-MIB by referring the
according value ifIndex.
For links not related to an IP
interface (analog POTS, for
example), this value is 0.
.asliActLinkStartTime(20) ASDateTime RFC3339 Time at which the link was brought
.asliHistLinkStartTime(20) up.
.asliActLinkEndTime(21) ASDateTime RFC3339 Time at which the link was brought
.asliHistLinkEndTime(21) down. If the link is still connected
this field has to contain the same
value as the start time.
.asliActLinkPPPoEID(22) Integer32 none PPPoE Session ID which started the
.asliHistLinkPPPoEID(22) call.
For links not started through PPPoE,
this value is zero.
For secondary PDP’s, this value is
the one from the related primary
PDP.
.asliActLinkQueueTotalSize(23) Integer32 -1..32767 kBytes This value defines the queue size for
.asliHistLinkQueueTotalSize(23) the current air-to-ground link. It can
be set to zero if the actual link is a
sub link of another entry and has no
own queue (e.g. a secondary
context). See Note 1.
.asliActLinkQueueFreeSize(24) Integer32 -1..32767 kBytes This value defines how much space
.asliHistLinkQueueFreeSize(24) is available in the air to ground
queue. See Note 1.

Note 1: The values of the previous table referring to this note can also
be set to -1, if the system (e.g., for temporary design reasons)
cannot provide it. Due to the fact that all these values are very
useful for the client applications to calculate the throughput,
the satcom systems shall implement this feature as soon as
possible.
Note 2: Recommended values for MaxSigQual are as follows:
64 dBHz BGAN Global Beam
68 dBHz BGAN Regional Beam
80 dBHz BGAN Spot Beam
ARINC CHARACTERISTIC 781 – Page 220

ATTACHMENT 5
ETHERNET INTERFACE

75 dBHz Swift64 (Spot/Regional Beam)

65 dBHz Swift64 NCS (Global beam)
5.3.2.2.2.2 Object Behavior
The .asliActLinkTable(4) is the main table in the MIB. It contains all relevant
information of the established links. Due to the fact that new links will be established
or established links will be updated or closed, this table has to be updated very
often. It has a very dynamic content. This section describes how the values in one
entry have to be updated, how a new entry has to be attached, and how an entry has
to be removed.
The following table shows a content example of the table:
Table 17 - Example 1 of the Actual Link Table Content
Table .asliActLink…
Row …Index(1) …Status(4) …LinkNegotiatedBW(10) …BeamID(14) …MainIndex(16) …ServiceIndex(17)
1 1 up 0 101 0 3
2 9 up 128 101 0 6
3 11 up 64 101 9 5

The following table shows a content example of the history table:

Table 18 - Example 1 of History Link Table Content
Table .asliActLink…
Row …Index(1) …Status(4) …LinkNegotiatedBW(10) …BeamID(14) …MainIndex(16) …ServiceIndex(17)
1 3 down 0 100 0 3
2 2 down 128 100 0 6
3 4 down 64 100 3 5
4 8 down 0 100 0 3
5 5 down 0 100 0 3
6 6 down 64 101 8 5
7 7 down 64 101 5 5
8 10 down 0 101 6 3

In accordance with Table 14 – Example Link Service Table Content, the values
are indicating the following scenario:
The satcom has established two primary contexts:
• One primary context is located in row 1 with index 1 and is related to service
index 3 (SBB:Background).
• The other primary context is located in row 2 with index 9 and is related to
service index 4 (SBB: STREAM32K).
• The entry in row 3 indicates a secondary context with a current allocated
bandwidth of 64 kbps on spot beam 101 from the type SBB: STREAM32K.
This entry is related to the one in row 2, because the asliLinkServiceIndex is
set to 9.
5.3.2.2.2.2.1 Insertion of a New Entry into the Table
A new entry has to be attached on the end of the table. The first entry, which will be
attached, has to start with a .asliActLinkIndex(1) of “1”. Each time, where a
new service entry will be inserted, the .asliActLinkIndex(1) of the new entry
has to be increased. If the maximum value has been reached, the index has to start
with 1 again. If the table already has an entry with the index 1, the value has to be
 ARINC CHARACTERISTIC 781 – Page 221

ATTACHMENT 5
ETHERNET INTERFACE

increased to 2. This has to continued, until a free index value has been found. Index
numbers are unique across both tables (the active and terminated calls).
The new content with a new secondary background link for the bundle in row 2 and 3
in beam 101 has to look as shown in the following table:
Table 19 - Example 2 of the Actual Link Table Content
Table .asliActLink…
Row …Index(1) …Status(4) …LinkNegotiatedBW (10) …BeamID(14) …MainIndex(16) …ServiceIndex(17)
1 1 up 0 101 0 3
2 9 up 128 101 0 6
3 11 up 64 101 9 5
4 12 up 0 101 9 3

The history table still has the same content. This is shown in the following table:
Table 20 - Example 2 of the History Link Table Content
Table .asliHistLink…
Row …Index(1) …Status(4) …LinkNegotiatedBW(10) …BeamID(14) …MainIndex(16) …ServiceIndex(17)
1 3 down 0 100 0 3
2 2 down 128 100 0 6
3 4 down 64 100 3 5
4 8 down 0 100 0 3
5 5 down 0 100 0 3
6 6 down 64 101 8 5
7 7 down 64 101 5 5
8 10 down 0 101 6 3

5.3.2.2.2.2.2 Removal of an Entry in the Table

If a link goes down, the corresponding .asliActLinkStatus(5) values have to be
changed and a timer has to be started for 30 seconds.
A link’s lifetime is defined by its activation and deactivation. This also applies to
secondary PDPs. If a secondary PDP is torn down and later re-activated, a separate
link entry will be created for the re-activation. 4 As mentioned in
asliActLinkActualContextID’s entry, a re-activated secondary will have the same
actual context ID as its first activation.
When the timer expires, the system has to send an .assLinkRemovedTrap(6) (if
the trap mechanism is activated) and the corresponding table entry has to be moved
to the end of the .asliHistLinkTable(7).
When an entry is removed, the next scan of the active link table will no longer
contain it (that is, there will be no hole). This is normal SNMP behavior.
If the link with the Index 1 will be closed, the .asliActLinkStatus(5) value of
the according row has to be changed to down. After the timer has expired, that entry
is moved to the history link table.

4
In an earlier version of the document, the lifetime of a link was not explicitly defined and could have allowed a secondary to be re-
activated within the 30 second timer and be considered the same link instance.
ARINC CHARACTERISTIC 781 – Page 222

ATTACHMENT 5
ETHERNET INTERFACE

The new table looks as shown below:

Table 21 - Example 3 of the Actual Link Table Content
Table .asliActLink…
Row …Index(1) …Status(4) …LinkNegotiatedBW(10) …BeamID(14) …MainIndex(16) …ServiceIndex(17)
1 9 up 128 101 0 6
2 11 up 64 101 9 5
3 12 up 0 101 9 3

The history table now has one entry more at the end of the table. This is shown in
the following table:
Table 22 - Example 3 of the History Link Table Content
Table .asliHistLink…
Row …Index(1) …Status(4) …LinkNegotiatedBW(10) …BeamID(14) …MainIndex(16) …ServiceIndex(17)
1 3 down 0 100 0 3
2 2 down 128 100 0 6
3 4 down 64 100 4 5
4 8 down 0 100 5 3
5 5 down 0 100 0 3
6 6 down 64 101 8 5
7 7 down 64 101 6 5
8 10 down 0 101 6 3
9 1 down 0 101 0 3

If a primary context with bundled secondary contexts will be closed, all

corresponding secondary contexts have to be closed as well. In this case, only one
timer can be used, for the removal of the according rows.
Table 23 - Example 4 of the Actual Link Table Content
Table .asliActLink…
Row …Index(1) …Status(4) …LinkNegotiatedBW(10) …BeamID(14) …MainIndex(16) …ServiceIndex(17)

The history table now has one entry more at the end of the table. This is shown in
the following table:
Table 24 - Example 3 of the History Link Table Content
Table .asliHistLink…
Row …Index(1) …Status(4) …LinkNegotiatedBW(10) …BeamID(14) …MainIndex(16) …ServiceIndex(17)
1 3 down 0 100 0 3
2 2 down 128 100 0 6
3 4 down 64 100 4 5
4 8 down 0 100 5 3
5 5 down 0 100 0 3
6 6 down 0 101 8 3
7 7 down 0 101 6 3
8 10 down 0 101 6 3
9 1 down 0 101 0 3
10 9 down 128 101 0 6
11 11 down 64 101 9 5
12 12 down 0 101 9 3

Note: If after that a new link will be opened, it has to be attached to

row 1 and the corresponding index value would be 13.
 ARINC CHARACTERISTIC 781 – Page 223

ATTACHMENT 5
ETHERNET INTERFACE

5.3.2.2.2.2.3 Identifying a PDP bundle

A PDP bundle is a primary PDP and its associated secondaries. The recommended
way of locating which secondaries are associated to a primary is through the
MainIndex field.
The IP address will typically be unique to the primary PDP (and copied to the
secondaries) and this does look like an alternate way of finding this association, but
the IP address is a parameter defined by the ground infrastructure and is not
guaranteed to be unique in all cases (two APNs could be using NAT-type technology
and serving up the same IP addresses).
The PPPoE session ID is another alternative. A PPPoE session ID could get re-used
(if a call was up while 32000 others went up and down), but there will not be two
active sessions with the same PPPoE session ID.
5.3.2.3 System Related Objects
The .asSystem(3) folder contains all system relevant information and some
configurable parameters that can be set by a client application. The structure is
shown in Figure 23.

.arincSwift(781)
├─ ....
└─ .asSystem(3)
├─ .assConfig(1)
├─ .assInfos(2)
├─ .assTraps(3)
├─ .assSelfTestAvailable(4)
└─ .assSelfTest(5)

Figure 23 – System Subfolders and Objects

5.3.2.3.1 System Configuration Related Sub Branch

The .assConfig(1) sub folder is mandatory and contains objects for the
configuration of the trap behavior of the satcom system. The objects are shown in
Table 25 - System Configuration Related Object Details.
Table 25 - System Configuration Related Object Details.
Object Identifier Type Range
Description
.asscTrapDest(1) IpAddress A client can define the destination of the traps by setting this object
to the expected address. The default value of this entry is 0.0.0.0,
indicating no client.
.asscTrapDestPort(2) Integer32 0..65535 A client can define the destination port on which the traps are
expected. The standard SNMP Trap port is 162, but any other can
be used. The default value is 0.

5.3.2.3.2 System Information Related Sub Branch

The .assInfos(2) sub folder is mandatory and contains some general objects for
the identification and the overall status of the SNMP-providing system.
ARINC CHARACTERISTIC 781 – Page 224

ATTACHMENT 5
ETHERNET INTERFACE

Table 26 - System Information Related Object Details

Object Identifier Type Range Description
.assiHealthStatus(1) ASHealthState This object shows the health state of the whole system.
.assiVendor(2) DisplayString 0..64 This object contains information about the system vendor.
.assiHWPN(3) DisplayString 0..32 This object contains the hardware part number.
.assiSerialNumber(4) DisplayString 0..32 This object contains the serial number of the system.
.assiHWFunction(5) DisplayString 0..32 This object contains a string to describe the general hardware
function (e.g. ‘High Speed SBB Satellite Modem’).
.assiShortName(6) DisplayString 0..16 This object contains a short name (e.g. ‘HS720’).

5.3.2.3.2.1 System Trap Related Sub Branch

The following Trap Objects are mandatory for the .assTraps(3)sub tree:
Table 27 - System Traps
Trap (OID) Monitored Objects Description
.asstHealthStatusTrap(1) .assiHealthStatus This trap has to be sent, if the health status of the system
changes.
.asstLinkSatusTrap(2) .asliActLinkIndex, This trap has to be sent, if one of the objects related to the
.asliActLinkReleaseType, Link status changes. If the Satcom system changes more than
.asliActLinkStatus one object within 1 second, it may only send the trap once.

.asstLinkBeamIDTrap(3) .asliSatID, This trap has to be sent, if the system changes the beam or
.asliActLinkIndex, the satellite. It has also to be sent, if the lock state changes.
.asliActLinkBeamID,
.asliSatState
.asstServiceAvailabilityTrap(4) .aslsIndex, This trap has to be sent, if the availability status of a service
.aslsAvailable changes in the service table.
.asstLinkInsertedTrap(5) .asliActLinkIndex This trap has to be sent, when the system inserts a new entry
into the link table.
.asstLinkRemovedTrap(6) .asliActLinkIndex This trap has to be sent, if the timer for the deletion of a link
table entry has expired. After this trap, the according entry has
been moved to the link table.
.asstSatHandoverPending(7) .asliSatHandoverPending This trap will be sent if the system knows it may need to do a
handover soon.

5.3.2.3.3 System Self-Test Related Sub Branch

The .assSelfTest(4) sub folder and its containing objects are optional, so it is
not required to implement it. Due to the fact that a client application has to know if
the objects are available or not, a helper object is included in the .asSystem(3)
branch. This object is mandatory and is called .assSelfTestAvailable(4). The
type of the object is TruthValue. If this value is true, the objects of
.assSelfTest(5) sub branch are accessible. The basic structure is shown in
Figure 24 - .assSelfTest Subfolders.
 ARINC CHARACTERISTIC 781 – Page 225

ATTACHMENT 5
ETHERNET INTERFACE

.arincSwift(781)
├─ ....
└─ .asSystem(3)
├─ ....
├─ .assSelfTestAvailable(4)
└─ .assSelfTest(5)
└─ .asssTestcaseTable(2)

.assSelfTest Subfolders
The .assSelfTest(5) folder itself has a Table, some readable and two writable
objects.
Table 28 - System Self-Test Related Object Details
Object Identifier Content Type
Range Description
.asssTestcaseNumber(1) Integer32
0..100 This object indicates how many entries are in the test
case table.
.asssTestCommand(3) Integer32 0..100 This is a writable object. By setting this value to a non-
zero value, the corresponding test case of the test case
table will be started. Starting a test will stop a previously
running one. Setting it to zero will stop any running test.
.asssTestUpTime(4) TimeTicks This is a writable object. A client application can control
the run time of the test case.
.asssTestStatus(5) ASTestState This value shows the status of the current running self-
test.
.asssTestLastResult(6) ASTestState This value indicates the result of the last finished test.
.asssTestReturnCode(7) Integer32 This field covers a unique return code of the self-test,
which can easily be validated.
.asssTestReturnMessage(8) DisplayString 0..256 This field contains a textual result message of the last
self-test, which can be logged.

The .asssTestcaseTable has the following columns:

Table 29 - System Test-case Table Related Object Details
Object Identifier Content Type Range Description
.asssTestCaseIndex(1) Integer32 1..100 This object defines a unique identifier for the according test
case.
.asssTestCaseName(2) DisplayString (1..50) This object shows the name of the test case (e.g. ’Link-Test’).
IF the system will offer the possibility to reset it via this
interface, it has to insert a entry with the name ’Reset-System’.

5.3.2.4 Unit Related Objects

This folder contains information about the components in the system. The
subfolders are optional. Each sub folder has a related object that indicates if the
folder information is implemented or not. Each folder has to contain three sub
folders (one with writable objects to configure the unit itself, one with information
about the unit and one with trap objects).
ARINC CHARACTERISTIC 781 – Page 226

ATTACHMENT 5
ETHERNET INTERFACE

The objects in the Configuration and Information folder are grouped in a table. For
each subunit connected to the system, an entry has to be inserted into the
Information table. An Integer32 object related to each table shows the number of
table entries.
Due to security reasons, it may be that a sub unit is not allowed to be configured. If
so, it has no entry in this table. Both tables (configuration and information) have
their own index values. These index values have to be the same for one unit. For
example: if “Antenna1” is not configurable and “Antenna2” is configurable, the table
entries in the .asuAntConfig(2) and .asuAntInfo(1) tables are shown as in
the tables below:
Table 30 - Relation Between Unit Config and Unit Info Table
Table asuAntConfig… Table asuAntInfo…
Row …Index …Name Row …Index …Name
1 32 Antenna2 1 17 Antenna1
2 32 Antenna2

5.3.2.4.1 SDU Unit Related Objects

This subsection contains all objects related to the SDU. They are grouped in tables
to cover that the unit can be available multiple times. Due to the fact, that the SDU
is mainly the unit providing this MIB, the tables should only have one entry, because
the SDU will provide its own MIB on a separate IP address.
5.3.2.4.1.1 Information Sub Branch for the SDU Unit Related Objects
The .asuSduInfo(1) sub branch shows all objects, which are related to the
information part of the SDU related objects. These objects are read only values to
provide more detailed information about the unit status itself.
The basic substructure of this MIB section defined as follows:
Table 31 - SDU Info Sub Structure

.arincSwift(781)
├─ ....
└─ .asUnits(4)
├─ .asuSDUAvailable(1)
└─ .asuSDU(2)
└─ .asuSduInfo(1)
├─ .asuSduInfoTableNumbers(1)
└─ .asuSduInfoTable(2)

This object has to be implemented, if a vendor decides to support the optional

.asuSDU(2) sub branches by setting the .asuSDUAvailable(1) object to “True.”
The object .asuSduInfoTableNumbers(1) indicates the number of entries in the
table. It is from the Type Integer32 and has a value range of 0..10. It has at to
contain 1 entry per connected unit.
 ARINC CHARACTERISTIC 781 – Page 227

ATTACHMENT 5
ETHERNET INTERFACE

The objects in the table are defined as shown below:

Table 32 - SDU Unit Information Table Object Details
Object Identifier Content Type Range Description
.asuSduInfoIndex(1) Integer32 1..10 This object describes the unique
identifier for the current unit.
.asuSduInfoVendor(2) DisplayString 0..22 ASCII String with up to 22 characters
to show the short name of the LRU
vendor.
.asuSduInfoHWPN(3) DisplayString 0..22 ASCII String with up to 22 characters
to show the Hardware Part number of
the LRU.
.asuSduInfoSN(4) DisplayString 0..22 ASCII String with up to 22 characters
to show the Hardware Serial Number
of the LRU.
.asuSduInfoHWFunction(5) DisplayString 0..22 ASCII String with up to 22 characters
to show the Functional description of
the SDU unit itself.
.asuSduInfoDesignation(6) DisplayString 0..22 ASCII String with up to 22 characters
to show the Short Name of the LRU.
.asuSduInfoSWVersion(7) DisplayString 0..22 ASCII String with up to 22 characters
to show the Software Version of the
LRU.
.asuSduInfoOverallStatus(8) ASHealthState General Status of the LRU.
.asuSduInfoPowerOnSelfTest(9) ASTestState Shows the Power On Self-Test Results
of the SDU.
.asuSduInfoInteractiveSelfTest(10) ASTestState Shows interactive self-test results of
the SDU.
.asuSduInfoFailureCode(11) Integer32 This object defines a unique failure
code for a test. The values are
grouped. 0..999 is reserved for general
standard codes which have to be
defined later. Values greater 999 are
vendor specific fault code of latest
system error.
.asuSduInfoFailureReason(12) DisplayString 0..255 Human readable vendor specific
failure message related to the latest
system error.
.asuSduInfoTemperature(13) Integer32 -65..150 The temperature of the SDU in °C.
.asuSduInfoThermalState(14) ASUnitThermState Shows the thermal state of the SDU.
.asuSduInfoCC1Status(15) ASHealthState Status of the channel card 1.
.asuSduInfoCC2Status(16) ASHealthState Status of the channel card 2.
.asuSduInfoIntHPAState(17) ASHealthState Status of the internal high power
amplifier.
.asuSduInfoQuadrax1Status(18) ASLinkState Status of the Ethernet quadrax port 1.
.asuSduInfoQuadrax2Status(19) ASLinkState Status of the Ethernet quadrax port 2.
.asuSduInfoIRS1BusStatus(20) ASHealthState Status of the IRS1 Bus.
.asuSduInfoIRS1SystemStatus(21) ASHealthState Status of the IRS1 Equipment.
.asuSduInfoPSMState(22) ASHealthState Status of the Power Supply Module.
.asuSduInfoOcxoState(23) ASHealthState Status of the Oven Controlled Crystal
Oscillator.
.asuSduInfoSecureORTStatus(24) ASHealthState Status of the secured Owner
Requirements Table.
.asuSduInfoUserORTStatus(25) ASHealthState Status of the user based Owner
Requirements Table.
ARINC CHARACTERISTIC 781 – Page 228

ATTACHMENT 5
ETHERNET INTERFACE

Object Identifier Content Type Range Description

.asuSduInfoStrapsState(26) TruthValue This value indicates, if the parity of
configuration straps is valid or not. A
true means it is valid and a false
indicates that it is not valid.
.asuSduInfoMultiControlBus(27) ASHealthState This object indicates availability of
ARINC 429 bus from CSDU to
Antenna.
.asuSduInfoCPUStatus(28) ASHealthState Status of the main Central Processing
Unit.
.asuSduInfoTxMuteActual(29) TruthValue Actual value of the TX mute discrete.
True means muted and false means
not muted.
.asuSduInfoRetLossToAntenna(30) Integer32 VSWR towards the Antenna in dB.
.asuSduInfoOutputFwdPower(31) Integer32 The output forward power in dB.
.asuSduInfoOutputRetPower(32) Integer32 The output return power in dBW.
.asuSduInfoAntennaBus(33) ASHealthState State of the antenna bus.
.asuSduInfoRestartReason(34) ASRestartReason The reason for the SDU's last restart.
.asuSduInfoUTCDateTime(35) ASDateTime RFC3339 Current UTC date and time in
RFC3339 format.
.asuSduInfoSWInstallDate(36) ASDateTime RFC3339 The install date of the software in
RFC3339 format. An empty string
indicates that this value is not
available.
.asuSduInfoInspectionDate(37) ASDateTime RFC3339 The inspection date of the SDU in
RFC3339 format. An empty string
indicates that this value is not
available.
.asuSduInfoOnGroundState(38) TruthValue This value provides the SDU’s version
of the Air/Ground State. True means
on ground.

5.3.2.4.1.2 Configuration Sub Branch for the SDU Unit Related Objects
This sub section shows all objects, which are related to the configuration part of the
.asuSDU(2) sub branch.
The basic substructure of this MIB section defined as follows:

.arincSwift(781)
├─ ....
└─ .asUnits(4)
├─ .asuSDUAvailable(1)
└─ .asuSDU(2)
├─ ...
└─ .asuSduConfig(2)
├─ .asuSduConfigTableNumbers(1)
└─ .asuSduConfigTable(2)

.asuSDU Configuration Sub Structure

These objects have to be implemented if a vendor decides to support the
optional .asuSDU(2) sub branch by setting the .asuSduAvailable(2) object
to “True”. The object .asuSduConfigTableNumbers(1) indicates the number
 ARINC CHARACTERISTIC 781 – Page 229

ATTACHMENT 5
ETHERNET INTERFACE

of entries in the table It is from Type Integer32 and has a value range of 0..10.
If for security reasons no configuration shall be available, the table can be empty.
The objects in the table are defined as shown below:
Table 33 - SDU Configuration Table Object Details
Object Identifier Content Type Range Description
.asuSduConfIndex(1) Integer32 1..10 Unique identifier of the table entry.
.asuSduConfUTCDateTime(2) ASDateTime RFC3339 This value allows a client to set the time in
the SDU according to RFC3339.
.asuSduConfTxMuteRequested(3) TruthValue Allows external equipment to request a state
change of the TX mute discrete.
.asuSduConfTailNumber(4) DisplayString 0..30 This field allows a client to provide the tail
number of the current plane to the SDU.
.asuSduConfCityPair(5) DisplayString 0..30 This field allows a client to provide the city-
pair of the current flight to the SDU.
.asuSduConfFlightNumber(6) DisplayString 0..30 This field allows a client to provide the Flight
Number of the current flight to the SDU.
.asuSduConfFlightPhase(7) DisplayString 0..30 This field allows a client to provide the actual
flight phase to the SDU.
.asuSduConfClientOnGroundSate(8) TruthValue This field allows a client Application to
provide its on ground state to the SDU. True
means on ground. If the SDU has no other
possibility to set its own on ground state it
can copy this value into the info table value.

5.3.2.4.1.3 Trap Sub Branch for the SDU Unit Related Objects
In the moment no Traps are identified for the SDU. This sub section is a placeholder
for future updates and can be used to insert trap objects in the .asuSDUTraps(3)
subfolder.
5.3.2.4.2 SCM unit Related Objects
This subsection contains all objects related to the SCM. They are grouped in tables
to cover that the unit can be available multiple times.
5.3.2.4.2.1 Information Sub Branch for the SCM Unit Related Objects
This sub section shows all objects, which are related to the information part of the
.asuSCM(4) sub branch.
The basic substructure of this MIB section defined as follows:

...
├─ .asuSCMAvailable(3)
└─ .asuSCM(4)
├─ .asuScmInfo(1)
├─ .asuScmInfoTableNumbers(1)
└─ .asuScmInfoTable(2)

SCU Info Sub Structure

These objects have to be implemented, if a vendor decides to support the optional
.asuSCM(4) sub branch by setting the .asuSCMAvailable(3) object to “True”.
ARINC CHARACTERISTIC 781 – Page 230

ATTACHMENT 5
ETHERNET INTERFACE

The object .asuScmInfoTableNumbers(1) indicates the number of entries in the

table. It is from Type Integer32 and has a value range of 0...10 and should contain
at least one entry.
The objects in the table are defined as shown below:
Table 34 - asuSCM Unit Information Table Object Details
Object Identifier Content Type Range Description
.asuScmInfoIndex(1) Integer32 1..100 This object describes the unique identifier for the
current unit.
.asuScmInfoVendor(2) DisplayString 0..22 ASCII String with up to 22 characters to show the short
name of the LRU vendor.
.asuScmInfoHWPN(3) DisplayString 0..22 ASCII String with up to 22 characters to show the
Hardware Part number of the LRU.
.asuScmInfoSN(4) DisplayString 0..22 ASCII String with up to 22 characters to show the
Hardware Serial Number of the LRU.
.asuScmInfoHWFunction(5) DisplayString 0..22 ASCII String with up to 22 characters to show the
Functional description of the unit itself.
.asuScmInfoDesignation(6) DisplayString 0..22 ASCII String with up to 22 characters to show the Short
Name of the LRU.
.asuScmInfoSWversion(7) DisplayString 0..22 ASCII String with up to 22 characters to show the
Software Version of the LRU.
.asuScmInfoOverallStatus(8) ASHealthState General Status of the unit.
.asuScmInfoSimsInstalled(9) Integer32 0..4 The number of SIMS installed in the SCM. The
following four objects are containing useful IMSI
numbers depending on this object.
.asuScmInfoIMSI1(10) DisplayString 0..30 ASCII String with up to 30 characters to show the IMSI
number of SIM card 1 (e.g. +17659850986). If less
than one SIMS, are installed this parameter must
contain an empty string.
.asuScmInfoIMSI2(11) DisplayString 0..30 ASCII String with up to 30 characters to show the IMSI
number of SIM card 2 (e.g. +17659850987). If less
than two SIMS are installed, this parameter must
contain an empty string.
.asuScmInfoIMSI3(12) DisplayString 0..30 ASCII String with up to 30 characters to show the IMSI
number of SIM card 3 (e.g. +17659850988). If less
than three SIMS are installed, this parameter must
contain an empty string.
.asuScmInfoIMSI4(13) DisplayString 0..30 ASCII String with up to 30 characters to show the IMSI
number of SIM card 4 (e.g. +17659850989). If less
than four SIMS are installed, this parameter must
contain an empty string.

5.3.2.4.2.2 Configuration Sub Branch for the SCM Unit Related Objects
In the moment no configuration items are identified for the SCM. This sub section is
a placeholder for future updates and can be used to insert configuration objects in
the .asuScmConfig(2) subfolder.
5.3.2.4.2.3 Trap Sub Branch for the SCM Unit Related Objects
In the moment no Traps are identified for the SCM. This sub section is a
placeholder for future updates and can be used to insert trap objects in the
.asuSCMTraps(3) subfolder.
5.3.2.4.3 DLNA Unit Related Objects
This subsection contains all objects related to the DLNA. They are grouped in tables
to cover that the unit can be available multiple times.
 ARINC CHARACTERISTIC 781 – Page 231

ATTACHMENT 5
ETHERNET INTERFACE

5.3.2.4.3.1 Information Sub Branch for the DLNA Unit Related Objects
This sub section shows all objects, which are related to the information part of the
.asuDLNA(6) sub branch.
The basic substructure of this MIB section defined as follows:

...
├─ .asuDLNAAvailable(5)
└─ .asuDLNA(6)
└─ .asuDlnaInfo(1)
├─ .asuDlnaInfoTableNumbers(1)
└─ .asuDlnaInfoTable(2)

DLNA Info Sub Structure

These objects have to be implemented, if a vendor decides to support the optional
.asuDLNA(6) sub branch by setting the .asuDLNAAvailable(5) object to
“True”. The object .asuDlnaInfoTableNumbers(1) indicates the number of
entries in the table. It is from Type Integer32 and has a value range of 0...10 and
should then contain at least 1 entry.
The objects in the table are defined as shown below:
Table 35 - DLNA Unit Information Table Object Details
Object Identifier Content Type Range Description
.asuDlnaInfoIndex(1) Integer32 1..100 This object describes the unique identifier for the current unit.
.asuDlnaInfoVendor(2) DisplayString 0..22 ASCII String with up to 22 characters to show the Short name of
the LRU vendor.
.asuDlnaInfoHWPN(3) DisplayString 0..22 ASCII String with up to 22 characters to show the Hardware Part
number of the LRU.
.asuDlnaInfoSN(4) DisplayString 0..22 ASCII String with up to 22 characters to show the Hardware
Serial Number of the LRU.
.asuDlnaInfoHWFunction(5) DisplayString 0..22 ASCII String with up to 22 characters to show the Functional
description of the LRU itself.
.asuDlnaInfoDesignation(6) DisplayString 0..22 ASCII String with up to 22 characters to show the Short Name of
the LRU.
.asuDlnaInfoSWVersion(7) DisplayString 0..22 ASCII String with up to 22 characters to show the Software
Version of the LRU.
.asuDlnaInfoOverallStatus(8) ASHealthState General status of the LRU.

5.3.2.4.3.2 Configuration Sub Branch for the DLNA Unit Related Objects
In the moment no configuration items are identified for the DLNA. This sub section is
a placeholder for future updates and can be used to insert configuration objects in
the .asuDlnaConfig(2) subfolder.
5.3.2.4.3.3 Trap Sub Branch for the DLNA Unit Related Objects
In the moment no Traps are identified for the DLNA. This sub section is a
placeholder for future updates and can be used to insert trap objects in the
.asuDlnaTraps(3) subfolder.
ARINC CHARACTERISTIC 781 – Page 232

ATTACHMENT 5
ETHERNET INTERFACE

5.3.2.4.4 Antenna Unit Related Objects

This subsection contains all objects related to the Antenna. They are grouped in
tables to cover that the unit can be available multiple times.
5.3.2.4.4.1 Information Sub Branch for the Antenna Unit Related Objects
This sub section shows all objects, which are related to the information part of the
.asuAntenna(8) sub branch.
The basic substructure of this MIB section is defined as follows:

...
├─ .asuAntennaAvailable(7)
└─ .asuAntenna(8)
└─ .asuAntInfo(1)
├─ .asuAntInfoTableNumbers(1)
└─ .asuAntInfoTable(2)

Antenna Info Sub Structure

These objects have to be implemented, if a vendor decides to support the optional
.asuAntenna(8) sub branch by setting the .asuAntAvailable(7) object to
“True”. The object .asuAntInfoTableNumbers(1) indicates the number of
entries in the table. It is from Type Integer32 and has a value range of 0...10 and
should contain at least 1 entry.
The objects in the table are defined as shown below:
Table 36 - Antenna Unit Information Table Object Details
Object Identifier Content Type Range Unit Description
.asuAntInfoIndex(1) Integer32 1..100 none This object describes the unique identifier for
the current antenna.
.asuAntInfoVendor(2) DisplayString 0..22 none ASCII String with up to 22 characters to show
the short name of the vendor from the referred
antenna.
.asuAntInfoHWPN(3) DisplayString 0..22 none ASCII String with up to 22 characters to show
the Hardware Part number of the antenna.
.asuAntInfoSN(4) DisplayString 0..22 none ASCII String with up to 22 characters to show
the Hardware Serial Number of the Antenna.
.asuAntInfoHWFunction(5) DisplayString 0..22 none ASCII String with up to 22 characters to show
the Functional description of the antenna.
.asuAntInfoDesignation(6) DisplayString 0..22 none ASCII String with up to 22 characters to show
the Short Name of the antenna.
.asuAntInfoSWVersion(7) DisplayString 0..22 none ASCII String with up to 22 characters to show
the Software Version of the antenna.
.asuAntInfoOverallStatus(8) ASHealthState none General Status of the antenna.
.asuAntInfoTemperatureStatus(9) ASAntThermState none Thermal state of the antenna.
.asuAntInfoGain(10) Integer32 - dB/10 The antenna gain currently utilized from 0.0 to
1..315 31.5 dB. (“-1” indicates invalid data).
 ARINC CHARACTERISTIC 781 – Page 233

ATTACHMENT 5
ETHERNET INTERFACE

5.3.2.4.4.2 Configuration Sub Branch for the Antenna Unit Related Objects
In the moment no configuration items are identified for the Antenna. This sub section
is a placeholder for future updates and can be used to insert configuration objects in
the .asuAntConfig(2) subfolder.
5.3.2.4.4.3 Trap Sub Branch for the Antenna Unit Related Objects
In the moment no Traps are identified for the Antenna. This sub section is a
placeholder for future updates and can be used to insert trap objects in the
.asuAntTraps(3) subfolder.
5.3.2.4.5 Future units
If a new unit will be identified to be added in the unit sub branch, this structure can
be extended by adding a new .asu<Unitname>(OID) sub branch with the same
restrictions, as described in Unit Related Objects.
5.3.2.5 User Defined Area
This MIB structure has a sub branch to insert vendor specific information. A supplier
is free to bring any kind of readable and writable objects in any user defined
structure. The only restriction to be covered is to use a dedicated subfolder. The
following subfolders are identified until now within the .asUserDefArea(5) sub
branch.
Table 37 - User Defined Area Vendor OID’s
Vendor Name <Vendor> Vendor sub OID complete Vendor OID
EMS EMS .asudaEMS(1) 1.3.6.1.4.1.13712.781.5.1
Honeywell Honeywell .asudaHoneywell(2) 1.3.6.1.4.1.13712.781.5.2
Rockwell/Collins RockColl .asudaRockColl(3) 1.3.6.1.4.1.13712.781.5.3
Thales Thales .asudaThales(4) 1.3.6.1.4.1.13712.781.5.4
Thrane Thrane Thrane .asudaThrane(5) 1.3.6.1.4.1.13712.781.5.5
Chelton Chelton .asudaChelton(6) 1.3.6.1.4.1.13712.781.5.6

If a new vendor needs its own place for user defined and vendor specific information
(and is not covered by the table above), he has to request an entry ID for its own
objects from Air/Ground Communication Systems Subcommittee to avoid OID
conflicts within the whole structure.
Each of the vendor sub OID’s contains two mandatory objects to define the version
of the sub folder. The first object is the major version number. The second object is
the minor version number. Both objects are from the Type Integer32 and the sub
version is limited to the range from 0 to 99.
The following table shows the object details of this folder:

Table 38 - Vendor Related Version Objects

Object Identifier Type Range Description

.asuda<VENDOR>VersMajor(1) Integer32 This object defines the major version of the vendor specific
sub branch. The current predefined default major version
number is 0 to indicate an empty sub branch.
.asuda<VENDOR>VersMinor(2) Integer32 0..99 This object defines the minor version of the vendor specific
sub branch. The current predefined default minor version
number is 0.
ARINC CHARACTERISTIC 781 - Page 234

ATTACHMENT 5
ETHERNET INTERFACE

6.0 ERROR CODES FOR PADT PPPOE MESSAGES

The ARINC 781 SDU 5 will provide a PPPoE Active Discovery Termination (PADT)
packet in response to termination of the PPPoE session.
The PPPoE session may be terminated by the SDU or by a PADT from the host.
The SDU will send periodic Echo-Request packets to the host to assess continued
connectivity.
The SDU will generate a Generic Error tag upon termination of every session,
including those that terminate normally. The Generic-Error tag is of the following
format: 6
SLCV – nnnn/dddd: SLCV_cause_string [detailed_cause_string]
• Where:
o nnnn is, for Swift64 M-ISDN, the Inmarsat SLCV termination code as
defined in the mini-M SDM Section A Table 15 Element #8 (Cause
Indication) and Section B-4.21.2 & 4.21.3. Certain SLCV codes may be
manufacturer-specific. For MPDS, this value is always 0000, with the dddd
field providing further error description (see below). For BGAN, reference
3GPP TS 24.008, 27.005, 27.007 and the BGAN SDM Volume 2, Chapter
2, Section 3.1.4.3.
o dddd is a detailed cause code. For Swift64 M-ISDN, this value is defined
by the equipment manufacturer. For MPDS, this value is derived from the
IPDS SDM Volume 2 Chapter 2 Section 7.2.11 Tables 21 and 22, Volume
2 Chapter 3 Section 4.12.10 Table 12, Volume 2 Chapter 11 Tables 7 and
8, and Volume 3 Chapter 2 Table 4. (AT +WQ cause code decimal values
are converted to hexadecimal).
SLCV_cause_string is the (modified) Inmarsat standard cause code text defined for
Swift64 M-ISDN in the mini-M SDM Section B Section 4.21.4 Table 4.9. For MPDS,
the text is the +WQ cause code string associated with the cause code derived from
the AT +WQ values in the IPDS SDM Volume 2 Chapter 11 Tables 7 and 8. For
BGAN, reference 3GPP TS 24.008, 27.005, 27.007 and the BGAN SDM Volume 2,
Chapter 2, Section 3.1.4.3 detailed_cause_string is extended cause description as
defined by the equipment manufacturer.
The SDU will generate an AC-System-Error tag upon termination of every session,
including those that terminate normally. The AC-System-Error tag is as defined
below.
If the PPPoE session was a Swift64 64k UDI session, the AC-System-Error tag will
be of the following format:
Q850 – qqq: Q.850_string
• Where:
o qqq is the ISDN Q.850 cause code defined in ITU-T Q.850 Table 1.
o Q.850_string is the Q.850 cause string defined in ITU-T Q.850 Table 1.

5
For ARINC 741 architectures, replace “SDU” with “HSDU”.
6
Manufacturers may utilize non-standard formats in addition to the standard/generic formats shown, but they should not use the
following reserved names: “SLCV”, “Q850”, “MPDS”, “BGAN”. Consult Inmarsat for further details.
 ARINC CHARACTERISTIC 781 - Page 235

ATTACHMENT 5
ETHERNET INTERFACE

If the PPPoE session was a Swift64 MPDS session, the AC-System-Error tag will be
of the following format:
MPDS – mmm: +WQ_cause_string
• Where:
o mmm is the MPDS cause code defined in the IPDS SDM Volume 2 Chapter
11 Tables 7 and 8.
o +WQ_cause_string is the MPDS AT +WQ cause string defined in the IPDS
SDM Volume 2 Chapter 11 Tables
7and 8.
If the PPPoE session was a SwiftBroadband PS session, the AC-System-Error tag
will be of the following format:
BGAN – bbb: BGAN_string
• Where:
o bbb and BGAN_string are defined in 3GPP TS 24.008, 27.005, 27.007 and
the BGAN SDM Volume 2, Chapter 2, Section 3.1.4.3
Example terminations:
1. ISDN termination due to SDU:
• Generic Error:
o SLCV – 12B1/00XX: call cleared by MES for unspecified reason [Channel
cleared, SDU reporting system failure]
• AC-System Error:
o Not Applicable
Note: Text in [square brackets] is manufacturer-specific.
2. ISDN termination due to network issue:
• Generic Error:
o SLCV – 1F11/0000: call failed, terrestrial party busy
•
• AC-System Error:
o Q850 - 17: User busy
3. MPDS protocol error:
• Generic Error:
o SLCV - 0000/031c: MPDS channel cleared [Control sub-layer protocol
failure]
• AC-System Error:
o MPDS - 796: Control sub-layer protocol failure
4. BGAN PDP Context activation failure protocol error:
• Generic Error:
o Not Applicable
• AC-System Error:
ARINC CHARACTERISTIC 781 - Page 236

ATTACHMENT 5
ETHERNET INTERFACE

o BGAN - 033: requested service option not subscribed

5. BGAN CS call failure:
•
Generic Error:
o SLCV – 3711/0000: international call busy
• AC-System Error:
o Not Applicable
7.0 ASN.1 SNMP MIB CODE
The ASN.1 SNMP MIB source code is available via a binary file from www.aviation-
ia.com/aeec/SupportFiles/781-2.
8.0 TO BE ADDRESSED IN A FUTURE REVISION
The following were brought up for discussion during finalization of the specification,
and were deemed to be useful, but to be added in a future revision. They are
recorded here for future consideration.
8.1 Quality of Service Entries
The asli*LinkNegotiatedBW field doesn’t match well the four bandwidth parameters
used in 3GPP (min up, min down, max up, max down).
8.2 Owner Requirement Table Branch
SDUs generally have a configured configuration block with their own version, date
and part number. It would be useful to be able to verify these through SNMP.
8.3 Optional Features Flags
There is currently no way for an application to verify whether certain optional
features are present on the SDU.
One way to implement this is through a new SNMP table which would have a string
indicating the feature and a numeric value indicating support level. The use of the
table means that the MIB will not need to be changed every time a new feature is
made, and that manufacturers can put their own flags.
Feature flags that were brought up: PPPoE BGAN Options (@APN, @USER,
@PASS, …), over-the-air compression control, over-the-air crypto control.
 ARINC CHARACTERISTIC 781 - Page 237

ATTACHMENT 6
ARINC 781 OUTPUT POWER USE CASES

The table below contains various scenarios and service combinations used as a
basis for developing the RF output power ranges for the Internal, Small Form Factor
External and Large Form Factor External HPA using the EIRPs defined in Section
1.7.1, Table 1-2 and noted below.

Cable Loss Aero

Ant. HPA
(including Aero R/T-
Gain SBB Output
Case Description DLNA loss) C-Channels Channel
Channels Power
(Global beam) (Global
(dBic) (Watts)
(dB) beam)
Classic Only
1 HGA 12.0 2.5 2 x 8400 10.5K - 28
Internal HPA
SBB Only
2 IGA 6.0 2.5 - - 2 x Class 7 29
Internal HPA
SBB Only
HGA
3 11.5 1.5 - - 2 x Class 6 20
Small Form
Factor FMHPA
SBB Only
IGA
4 6.5 1.5 - - 2 x Class 7 21
Small Form
Factor FMHPA
Multi-Service
HGA
5 11 1.5 1 x 8400 1200 1 x Class 6 20
Small Form
Factor FMHPA
Multi-Service
HGA
6 11.5 1.5 1 x 8400 10.5K 1 x Class 6 28
Large Form
Factor FMHPA
Loss of
Cooling
7 HGA 11 1.5 1 x 8400 1200 - 9
Large Form
Factor FMHPA
HGA
8 Large Form 11 2.2 2 x 8400 10.5K 2 x Class 6 60
Factor FMHPA

Note: The following EIRP requirements (dBW per channel) are

assumed in these Use Cases.
Aero Aero Aero
SBB SBB SBB
C-Channels R/T-Channel R/T-Channel
Channels Channels Channels
(8400) (1.2K) (10.5K)
Class 6 Class 7 Class 4
(Global beam) (Global beam) (Global beam)
18.5 9.1 20.4 20.0 15.1 10.0

Note: For SB200 (Class 4), there is an example in Attachment 7.

ARINC CHARACTERISTIC 781 – Page 238

ATTACHMENT 6
ARINC 781 OUTPUT POWER USE CASES

Other use cases of HPA Output Powers (watts) can be calculated using the following
tables and formula:
(X/10)
Antenna Gain (dB) [X] Antenna Gain Factor [10 ]
12.0 15.85
11.5 14.13
11.0 12.59
6.5 4.47
6.0 3.98

(Y/10)
Cable Loss (dB) [Y] Cable Loss Factor [10 ]
2.5 1.78
2.2 1.66
1.5 1.41

(Z/10)
Channel (use case) EIRP Power/Channel (dBW) [Z] EIRP Power/Channel (watts) [10 ]
1
Aero C (8.4 kbps) initial 18.50 70.79
Aero C (8.4 kbps) settled * ~ 13.50 ~ 22.39
Aero R/T (1.2 kbps) 9.10 8.13
Aero R/T (10.5 kbps) 20.40 109.65
1
Swift64 initial 22.50 177.83
1
Swift64 settled ~ 18.50 ~ 70.79
SBB Channels (Class 6) 20.00 100.00
SBB Channels (Class 7) 15.10 32.36

Note:
1. For this channel type, there is typically no more than one channel at a
time at the initial power level (for only a few seconds), with any other
channels of the same type typically at the settled power level. The
worst (unrealistic) case would be for all such channels to be at the
initial power level simultaneously; the best (unrealistic) case would be
for all such channels to be at the settled power level simultaneously.
Realistic cases involving more than one channel of this type may be
estimated as desired by selecting an appropriate mix of the power
levels in the overall desired Use Case. Settled power levels are
approximate.

HPA Output Power (watts) for a desired Use Case

CLfactor
= [(#channels)(UseCasewatts )]
AGfactor

Where:
CL factor = Cable Loss Factor
AG factor = Antenna Gain Factor
 ARINC CHARACTERISTIC 781 - Page 239

ATTACHMENT 6
ARINC 781 OUTPUT POWER USE CASES

#channels = number of channels for a given Use Case

UseCase watts = Watts per channel of the desired Use Case
Total HPA Output Power (watts) = The sum of the output power (watts) for each
Use Case calculated above.
Example: For 12 dB Ant Gain, 2.5 dB cable loss, 2 channels Aero C (8.4 kbps), 4
channels SBB (Class 6), and 1 channel Aero R/T (10.5 kbps):

Total HPA Output Power (watts)

1.78 CLfactor
= [(2 channels)(70.79 watts Aero C 8.4 kbps)
15.85 AGfactor
+ (4 channels)(100 watts SBB Class 6)
+ (1 channel)(109.65 watts Aero RT 10.5 kbps)]

= 73.13 watts
COMMENTARY
When multiple channels are in operation simultaneously, the Peak-to-
Average Power Ratio (PAPR) should be examined. In the example
above , the multiple channels also include 4 SBB channels. The SBB
channel uses both π/4-QPSK modulation for the power efficiency and
16-QAM modulation for the bandwidth efficiency. The 16-QAM
modulation, however, will generate high PAPR. The component
(including power amplifier) and system designers need take the PAPR
into account to avoid deteriorating the system performance.
The Power Complementary Cumulative Distribution Function (CCDF)
curves provide critical information about the signals encountered in
the digital modulation systems. The CCDF display shows the peak
powers and how often they occur, or how many symbols require those
power levels. The CCDF plays an important role in characterizing of
power amplifiers and predicting BER/PER performance.
For more information on PAPR and CCDF see:
• Agilent Technologies Application Note , Characterizing Digital
Modulated Signals with CCDF Curves, Agilent Technologies,
Copyright 2000
• Rumney, Moray (Editor), Agilent Technologies Staff. LTE and
the Evolution to 4G Wireless: Design and Measurement
Challenges , Padstrow, Corrwall Great Britain for Agilent
Technologies by John Wiley & Sons, Ltd, 2009
ARINC CHARACTERISTIC 781 – Page 240

ATTACHMENT 7
COMPACT SATCOM DEFINITION (SB200)

1.0 Introduction
This attachment describes a Compact Satcom System. It is intended as a small
form-factor, lower-cost alternative configuration, aimed primarily at delivering safety
services to the cockpit.
The Compact Satcom System is particularly suited to deliver the Inmarsat
SwiftBroadband SB200 Evolution service, operating in Class 4 over the Inmarsat I-4
and Alphasat satellites. A Class 4 is by definition a single-channel system, allowing
reduced size, power dissipation and cost. The Compact System is therefore not
suitable for providing multi-channel services such as Classic Aero.
The interfaces to the aircraft as well as wiring provisions are designed to have a high
level of commonality with the full-size ARINC 781 system. Due to the high similarity
with the full-sized system, the detail definitions of various interfaces are not repeated
in this attachment. This attachment aims to describe the differences found in the
compact system.
While a single system configuration for all aircraft types is highly desirable, this was
found to be difficult to achieve due to varying and conflicting requirements in different
airframes. Multiple configuration options are therefore described.
While the focus of this standard is on the provision of safety services to the cockpit,
the system may also be suitable for providing limited cabin services, perhaps more
suitable for non-airline applications. The compact system is well suited to airline
applications where segregation is required between the cockpit and cabin from a
network security perspective. Cabin connectivity may then be provided by a
separate satcom system.

2.0 SB200 Evolution Safety Service (Class 4) Overview

The Inmarsat Class 4 service is designed to enable compact airborne equipment,
particularly the antenna. The main characteristics are:
• Service down to 5 degrees elevation (The SB200 Class 15 service provides
coverage only above 20 degrees elevation.)
• Provided over I-4 satellites and Alphasat
• ACARS messaging service
• Dual voice channels, for safety or non-safety services
• IP data connection, up to 200 kb/s. Safety or non-safety use.
• Streaming service up to 32 kb/s to support multi-voice services
• Priority and pre-emption of safety voice and data services
• Small antenna (e.g. a blade antenna)
 ARINC CHARACTERISTIC 781 - Page 241

ATTACHMENT 7
COMPACT SATCOM DEFINITION (SB200)

3.0 Airborne Terminal Configurations

Despite the desire to standardize one configuration of the Compact Satcom System,
conflicting requirements for different airframes led to three configurations.
• Configuration 1 is included for those aircraft that can provide cooling air in the
crown of the aircraft. For these aircraft it is optimal to co-locate the HPA
function (high-power amplifier) with the DLNA function in the crown of the
aircraft. This allows for the use of medium-loss coaxial cables leading to a
weight saving. The HPA and DLNA functions are combined into a single
HLD (high-power amplifier/low-noise amplifier/diplexer) unit.
• Configuration 2 is included for those aircraft that cannot provide cooling air in
the crown of the aircraft, making the location of the HPA function in the crown
impossible. In this case the HPA function should be located in the equipment
bay where adequate cooling air is generally available. For the sake of
installation simplicity and cost, it is desirable that the HPA function is included
inside the SDU. It is desirable in most, if not all, airframes to place the SDU
in the avionics bay or similar location, remote from the antenna. In this case a
low-loss transmit coaxial cable is required. The requirement for low cable
loss can be alleviated somewhat by the capability for the HPA to provide
more power. A DLNA (diplexer / low-noise amplifier) needs to be situated
close to the antenna to minimize receive-path cable loss between the
antenna and the DLNA.
• Configuration 3 is included for those aircraft that wish to minimize the number
of components installed as part of the Compact Satcom System. In this case
the DLNA and HPA functions are contained within the ELGA antenna.
The system configurations each consist of a Compact SDU (CSDU), an Enhanced
Low Gain Antenna (ELGA), an SCM, an optional HLD or DLNA, and associated
wiring. A CSDU should support an external SCM (see Attachment 1-6), and may
optionally include an internal SCM. The three configurations are shown in Section 7.
Configurations 1 and 2 have baseline and alternate aircraft wiring defined, while
Configuration 3 has only one aircraft wiring defined. The equipment manufacturer
should be consulted to determine which configurations and/or wiring is appropriate.
ARINC CHARACTERISTIC 781 – Page 242

ATTACHMENT 7
COMPACT SATCOM DEFINITION (SB200)

Configuration 1 Configuration 2 Configuration 3

ELGA ELGA ELGA

Outside the aircraft
Antenna only Antenna only Antenna, HLD

Inside the aircraft,

HLD DLNA close to the antenna

CSDU Equipment rack

CSDU CSDU
Includes HPA

Figure 1 – Compact Satcom System Configurations

4.0 LRU Definitions

4.1 Compact Satcom Data Unit (CSDU)
The CSDU is functionally similar to the full-sized (6 MCU) SDU described in Section
1.6.1. The major differences are:
• The form factor is a 2 MCU ARINC 600 enclosure (as opposed to 6 MCU for
the full-sized SDU)
• It provides one channel of service only
The connector definition of the CSDU is identical to that on the 6 MCU (full-sized)
SDU.
Like the full-sized SDU, the CSDU can operate with high RF power when the CSDU
is used with a DLNA, or low RF power when used with an HLD. Manufacturers may
choose to include these two modes of operation in a single part number.
4.1.1 CSDU Form Factor
The SDU should comply with the dimensional standards in ARINC Specification 600
for the 2 MCU size.
4.1.2 CSDU Interfaces
The connector, index pin coding, and pin definitions are identical to that of the full-
sized (6 MCU) SDU, as defined in section 2.2.1.2.
The following table gives a subset of the electrical interfaces defined for this
connector which are considered as essential for a CSDU. Other interfaces are
considered optional.
 ARINC CHARACTERISTIC 781 - Page 243

ATTACHMENT 7
COMPACT SATCOM DEFINITION (SB200)

Required for
INTERFACES ON ARINC 600
SB200 safety Comments
CONNECTOR
system?
Power
115 Vac Variable Frequency Yes
28 Vdc No Required for business jets.
SATCOM System Interfaces
Tx RF (Power) Yes For single-channel SB200.
BSU Control Yes For A781 HGA / IGA. Optional for ELGA.
ELGA Control No Optional via co-ax or ARINC 429.
External HPA Control (A429) If required for
HLD
HPA Mute No
SCM Yes Per A781 wiring provisions.
Other SDU (dual) No
User Interfaces
10/100BaseT on size 22 pins Yes – 2 for cabin
10/100BaseT on Quadrax Yes – 2 for
cockpit
ARINC 664 copper (Cockpit voice No
& data)
ARINC 664 fiber (Cockpit voice & No
data)
ISDN No
CEPT-E1 No
(C)MU Yes – 2 Two for B777. Two ACRs in A350/380.
Cockpit Voice (4-wire & discretes) Yes – 2 sets
MCDU Yes – 3
POTS/SLIC No
BITE/Maintenance Interfaces
CFDS/CMC on ARINC 429 Yes
ADL (ARINC 615/429) Ethernet & For Ethernet: Quadrax Ethernet 3 preferred.
ARINC 429
Service Availability Status discrete No Optional. Desirable for certain business jet
applications.
ATE pins No
ARINC 664 copper or fiber No ARINC 664 copper desirable for A350/380.
Miscellaneous Interfaces
AES ID (429) Yes
IRS/GNSS Yes – 3
Configuration Straps Yes
WOW Yes
Tx Mute Yes
ARINC 664 copper or fiber No ARINC 664 copper desirable for A350/380.
 ARINC CHARACTERISTIC 781 – Page 244

ATTACHMENT 7
COMPACT SATCOM DEFINITION (SB200)

4.1.3 CSDU Services and Features

The following table indicates services and features which should be supported as a
minimum. Others are optional at manufacturer’s discretion.
Required for SB200
Section Feature/Function Comments
safety system?
2.10 BITE (CFDS interface) Yes – 1 ARINC 429 Used on selected airframes.
Rx/Tx
3.1.1 Inmarsat Services
3.1.1.2 Classic Aero No
3.1.1.3 Swift64 No
3.1.1.4 SwiftBroadband 1 channel
3.1.2 Radio Interfaces
Non-ATC Cockpit Voice Yes – 2 Two cockpit voice interfaces with priority &
ATC Cockpit Voice Yes – 2 pre-emption.
Cabin Voice No
Non-ATC Cockpit Data Yes Ethernet for EFB.
ATC Cockpit Data Yes SBB ACARS over A429.
Cabin Data Ethernet See Attachment 8 for security
considerations.
3.2.1 Pilot System Interfaces for
Voice
3.2.1.2 MCDU Menus Yes – 3 MCDUs
3.2.1.6 SAT Phone – Classic No
Aero
3.2.1.7 SAT Phone – Yes. 2 channels Some require DTMF dialing.
SwiftBroadband (AMBE+2 & VOIP)
3.2.1.8 SAT Radio – No Not defined to date.
SwiftBroadband
3.2.1.9 Williamsburg SDU (WSCI) No Used on selected airframes (A350, A380,
Controller Dassault).
3.2.4 Ethernet Yes, all
3.3 Software Dataloader Both. S/W & ORT
3.4.1 Dual Satcom No Interest from one OEM noted.
3.4.1.1 Classic Aero Operations No Would have required multiple channels.
3.4.1.2 SwiftBroadband & Swift64 N/A
Operations
3.4.3 Security No PIES support See Attachment 8 for security
required. considerations.
3.5 Future Growth
3.5.1 ARINC 664 No
3.5.4 Multi-Frequency Band No

4.1.4 CSDU Cooling

The CSDU with internal HPA requires forced air cooling. Due to the compact design
the required airflow may be higher than that specified in ARINC Specification 600.
Manufacturers should specify cooling airflow requirements.
The CSDU without active HPA may be sufficiently cooled by convection.
Manufacturers should specify any additional cooling airflow requirements.
 ARINC CHARACTERISTIC 781 - Page 245

ATTACHMENT 7
COMPACT SATCOM DEFINITION (SB200)

4.1.5 CSDU Loss of Cooling

The CSDU with internal HPA should be designed to deliver service in a case where
cooling air is lost in flight. There is no need to deliver service in the case of loss of
cooling when the aircraft is on the ground.
An acceptable duty cycle restriction could then be applied as necessary and could
consist of the CSDU restricting services to retain cockpit functions where the
ambient temperature is at an extreme.
The system should continue to provide ACARS messaging and 1 voice channel at
100% duty cycle as a minimum.
4.2 SDU Configuration Module (SCM)
The SCM in the compact system is identical to that for the full-sized system, as
defined in section 1.6.2. In this case, however, the SCM is only required to contain a
single USIM to support one channel of SwiftBroadband service. The SCM also
contains memory to store system configuration parameters.
4.3 HLD
4.3.1 HLD Description
The HLD (High-power Amplifier/LNA/Diplexer) combines the functions of the HPA
and the DLNA (as described in Sections 1.6.3 and 1.6.4) into one unit. The HLD is
intended for installation inside the fuselage, close to the antenna.
The HLD is required to provide RF power for transmission of one radio channel.
Hence no intermodulation requirements are specified for the HLD. The HLD should
satisfy all the relevant Inmarsat requirements.
The choice of the method to provide power to the HLD is at the manufacturer’s
discretion. Options for providing power are (1) the aircraft AC or DC power bus or (2)
from the SDU via the coaxial cables, or (3) both. The HLD may also make provision
for powering the antenna through the coaxial cable.
If the HLD is powered through coaxial cables then control and BITE communications
between the SDU and HLD, and between the HLD and ELGA should also be
through the coaxial cables. This simplifies the installation.
As an alternative, manufacturers may choose to use ARINC 429 buses for control
and BITE communications to the HLD. In this case a multi-pin connector provides
for power and ARINC 429 connections. If manufacturers opt for supplying power,
control and BITE connections through the coaxial cables, the multi-pin connector
may be omitted.
If ARINC 429 is used for control and BITE, an additional ARINC 429 input should be
provided on the HLD. The BITE output from the antenna is then routed to the HLD,
which then relays the antenna’s BITE information, along with its own, to the CSDU.
4.3.2 HLD Form Factor
The HLD form factor is shown in Figure 2.
The outline resembles that of a Type F DLNA, but it uses a different multi-pin
connector. The position of the connectors and cooling spigot may be positioned in
the areas shown.
ARINC CHARACTERISTIC 781 – Page 246

ATTACHMENT 7
COMPACT SATCOM DEFINITION (SB200)

NOTE: Baseline drawing – Consult manufacturer to confirm outline.

Figure 2 – HLD outline

4.3.3 HLD Connectors

The DLNA uses the following connectors for its RF ports:
• Transmit Port (from SDU): N Jack (Female)
• Receive Port (to SDU): TNC Jack (Female)
• Antenna Port: TNC Jack (Female)
The optional power/control connector type is D38999/20ME26PA or equivalent
which mates with a D38999/26ME26SA. It has a 17-26 insert arrangement, which is
shown in Figure 3. The pin allocations are shown in the table below.

Figure 3 – HLD Multi-pin Connector Insert Arrangement

 ARINC CHARACTERISTIC 781 - Page 247

ATTACHMENT 7
COMPACT SATCOM DEFINITION (SB200)

Pin Signal Description

A * HLD ARINC 429 BITE A ARINC 429 from HLD (to SDU)
B * HLD ARINC 429 BITE B ARINC 429 from HLD (to SDU)
C Antenna/BSU ARINC 429 BITE A ARINC 429 to HLD from Antenna/BSU
D Antenna/BSU ARINC 429 BITE B ARINC 429 to HLD from Antenna/BSU
E RS-232 from HLD For shop use – not expected to be wired on
aircraft
F RS-232 to HLD For shop use – not expected to be wired on
aircraft
G (spare#1)
H (spare#2)
J * Chassis Ground
K +28 Vdc Hot
L +28 Vdc Return
M Reserved (LNA BITE Discrete)
N Reserved (LNA Control Discrete)
P * HLD ARINC 429 Control A ARINC 429 to HLD from SDU (multi-control)
R * HLD ARINC 429 Control B ARINC 429 to HLD from SDU (multi-control)
S * HLD ARINC 429 Control Shield/Strap Ground
T * HLD ARINC 429 BITE Shield/Strap Ground
U Antenna ARINC 429 BITE Shield/Strap Ground
V Reserved (attenuator #3)
W Reserved (disable autosense)
X * 115 Vac Hot
Y * 115 Vac Return
Z Reserved (parity)
a Reserved (LNA BITE Discrete Ground)
b Reserved (attenuator #1)
c Reserved (attenuator #2)

Note: Configuration 1 baseline does not require the multi-pin connector. Signals
marked “*” are standard wiring for Configuration 1 – Alternate wiring
ARINC CHARACTERISTIC 781 – Page 248

ATTACHMENT 7
COMPACT SATCOM DEFINITION (SB200)

4.3.4 HLD Cooling

A spigot for cooling air should be provided on the HLD. The cooling air flow rate
should be 25 kg/hr at 60°C (max) air (inlet temperature), and the pressure drop
through the HLD should be 51 ± 5 mm of water at this rate.
When cooling air is available, the unit will operate in an actively-cooled manner; but
when cooling is lost the unit will revert to a passively-cooled operation and will inform
the SDU of it being in such a mode. The system will then operate at a reduced
services mode.
A minimum clearance of 1-inch beyond the envelope defined in Figure 2 should be
provided to facilitate the passively cooled nature of this design when in ‘loss of
cooling mode’.
4.3.5 HLD Loss of Cooling
The HLD should also be designed to deliver service in a case where cooling air is
lost in flight. There is no need to deliver service in the case of loss of cooling when
the aircraft is on the ground.
Continuous operation within the output power range is expected when cooling is lost.
An acceptable duty cycle restriction could then be applied as necessary and could
consist of the CSDU restricting services to match the HLD capability to retain cockpit
functions where the ambient temperature is at an extreme.
The system should continue to provide ACARS messaging and 1 voice channel at
100% duty cycle as a minimum.
4.3.6 HLD Grounding and Bonding
The HLD should provide a flat surface underneath around each of the 4 mounting
holes for direct bonding to the airframe.
A 10-32UNF thread grounding stud should be provided to allow fixing of a bonding
strap lug.
4.4 DLNA
As the RF performance of individual units of the RF Satcom System is not specified,
there are no specific RF performance requirements for the DLNA in this attachment.
Despite this, the system should accommodate the use of any standard Type A,
modified Type A or Type F diplexer, modified to accommodate the extended L-Band
(XL-Band). This should generally be possible as these diplexers were specified for
multi-channel use, and should therefore be more than adequate for a single-channel
system.
The physical outline of the diplexer is shown in Attachment 1-8.
4.5 ELGA (Enhanced Low Gain Antenna)
4.5.1 ELGA Description
The ELGA is aimed at providing a nominal gain of 3 dBic above 20 degrees
elevation and 2 dBic between 5 and 20 degrees elevation. This low-elevation
performance distinguishes the antenna from the LGA originally defined in ARINC
741. To achieve this enhanced performance some form of beam steering is
expected to be required. Because of the low gain required the beams are relatively
broad when compared to an HGA.
 ARINC CHARACTERISTIC 781 - Page 249

ATTACHMENT 7
COMPACT SATCOM DEFINITION (SB200)

As described in Section 7.0, the ELGA may be controlled and powered using any
one of the following interfaces:
• The RF coaxial cable.
• A multi-pin connector. The multi-pin connector and its pin assignments are
the same as the connector on the HGA/IGA.
• A second coaxial cable, instead of the multi-pin connector.
The ELGA should also provide BITE information through the same chosen interface.
4.5.2 ELGA Form Factor
The ELGA footprint is shown in Figure 4, Figure 5 and Figure 6. This footprint
partially matches the footprint of the LGA, as defined in ARINC 741. The ELGA is
shorter, however, and does not use the rear pair of mounting screw holes.
4.5.3 ELGA Operation at High Ambient Conditions
Where system configuration 3 is adopted, the performance of the system should
provide continuous operation within the expected output power range when the
ambient air temperature is as an extreme. An acceptable duty cycle restriction could
then be applied as necessary and could consist of the CSDU restricting services to
retain cockpit functions.
The system should continue to provide ACARS messaging and 1 voice channel at
100% duty cycle as a minimum.
4.5.4 ELGA Connectors
The ELGA should be equipped with a TNC female connector for Tx and Rx radio
signals.
A second connector may be fitted for power, control and BITE. This connector
should be a multi-pin connector or a TNC female connector as described in section
7.0. If a multi-pin connector is used it should be identical to that defined for the HGA
in section 2.3.2.2 and attachment 1-12. If the ELGA contains two TNC connectors,
then they should be color coded.

Figure 4 – ELGA with single TNC female connector

ARINC CHARACTERISTIC 781 – Page 250

ATTACHMENT 7
COMPACT SATCOM DEFINITION (SB200)

Figure 5 – ELGA Footprint, with 2nd TNC connector

Figure 6 – ELGA footprint, with multi-pin connector

 ARINC CHARACTERISTIC 781 - Page 251

ATTACHMENT 7
COMPACT SATCOM DEFINITION (SB200)

4.6 Coaxial Cables

If an HLD is used (Configuration 1), the system should meet its requirements with
the following cable loss ranges:
Cable Loss (dB)
Tx cable, CSDU to HLD 6 to 18 dB (0 to 18 dB is desirable)
Rx cable, HLD to CSDU 6 to 25 dB (0 to 25 dB is desirable)
Antenna cable, HLD to ELGA 0 to 0.5 dB

If a DLNA is used (Configuration 2), the system should meet its requirements with
the following cable loss ranges:
Cable Loss (dB)
Tx cable, CSDU to DLNA 0 to 3 dB
Rx cable, DLNA to CSDU 6 to 25 dB (0 to 25 dB is desirable)
Antenna cable, DLNA to ELGA 0 to 0.5 dB

If the ELGA requires a second coaxial cable between the ELGA and CSDU, the
system should operate with cable losses in the range 0 to 25 dB.
If the installation is designed to allow power on a coaxial cable, then its DC
resistance should be no more than 0.6 Ohms.
If the HPA, DLNA and antenna are combined (Configuration 3), the system should
meet its requirements with the following cable loss ranges:
Cable Loss (dB)
Tx/Rx cable, CSDU to ELGA 0 to 18 dB

All RF losses should be measured at 1.6 GHz.

5.0 Interchangeability
The CSDU, SCM, HLD or DLNA and ELGA are designed as a functional set.
Individual LRUs are therefore not specified to be interchangeable with similar LRUs
from a different manufacturer. Interfaces between units are therefore not
standardized at the electrical signal level.
Equipment should, however, be manufactured and calibrated as individual units and
not as matched sets. Any individual unit may therefore be replaced without
replacing any other LRU.
The footprint and RF connector of the ELGA (but not the electrical interface or
performance) has commonality with the LGA, as defined in ARINC 741, to allow use
of existing aircraft provisioning. The ELGA is shorter, however, and does not use
the rear pair of mounting holes. A second optional connector position has been
defined, where the second connector may be a 2nd TNC or a multi-pin connector
with the same definition as that of the HGA.
The footprint, fixing holes, and all the RF connectors of the HLD are intended to be
compatible with the Type F DLNA footprint defined in Attachment 1-8. The optional
power/control connector of the HLD is the same as the Flange Mount HPA except a
different keying is used.
ARINC CHARACTERISTIC 781 – Page 252

ATTACHMENT 7
COMPACT SATCOM DEFINITION (SB200)

The connector and electrical interfaces of the CSDU are intended to be compatible
with the full-size (6 MCU) SDU, except that electrical details may differ on the
interface to the HLD (e.g. power and control over coaxial cables instead of ARINC
429).
6.0 Performance Criteria
The CSDU, SCM, HLD or DLNA and ELGA are designed as a functional set. The
performance criteria for individual units are not described in this document. The
complete system is required to comply with the requirements as set out in the
relevant Inmarsat System Definition Manual (SDM). Below follows a short selection
of requirements for information.
6.1 Transmitter Equipment Performance
The equipment is aimed at supporting the Inmarsat SB200 Evolution (Class 4)
Safety Service. The nominal EIRP required is 10 dBW. The transmit system is
equipped to reduce the EIRP below this level according to commands from the earth
station (back-off).
Table 1 – Worked Example of Transmitter Performance Criteria for Configuration 2
System Component Value Unit
EIRP 10.0 dBW
Ant Gain (min) 1.0 dB
Ant-DLNA Cable Loss 0.5 dB
DLNA Insertion Loss 0.8 dB
CSDU-DLNA Tx Cable Loss 3.0 dB
CSDU Output Power 13.3 dBW
CSDU Output Power 21.4 W

The transmit gain of the ELGA may vary as its beam position is changed while
tracking a satellite from an aircraft in motion. To maintain a more constant EIRP as
the antenna's beam position is changed, the system may make appropriate RF
power adjustments to compensate for the change in antenna gain.
If the antenna beam steering function uses attitude, then aircraft attitude rates of
change should be assumed to be up to 7.5 degrees per second.
The transmitter should operate over the frequency bands 1626.5 to 1660.5 and
1668.5 to 1675.5 MHz. This includes the extended L-band (XL-band) used by
Alphasat.
There is no intermodulation requirement, as this is a single channel system.
6.2 Receiver Equipment Performance
To support the Inmarsat SB200 Evolution (Class 4) Safety Service, the receiver
chain should provide a nominal G/T performance of better than -21 dB/K for
elevation angles above 5 degrees. (This is an approximation. Consult the Inmarsat
SDM for detailed requirements.)
The receiver system performance is intended to provide a packet error rate (PER) of
1x10-3 or better for SwiftBroadband packet-switched services and 1x10-2 or better for
SwiftBroadband circuit-switched voice.
 ARINC CHARACTERISTIC 781 - Page 253

ATTACHMENT 7
COMPACT SATCOM DEFINITION (SB200)

The receiver should operate over the frequency band 1518 to 1559 MHz. This
includes the extended L-band (XL-band) used by Alphasat.
7.0 Interwiring
This section deals specifically with wiring between the CSDU, HLD / DLNA and
ELGA. Wiring to other avionics in the aircraft is simplified as “aircraft interfaces” in
the figures in this section. Refer to section 4.1.3 of this attachment as well as
Attachment 1-3 and Attachment 1-5 (a, b and c) for the connector and pin allocation
detail.
The multi-pin connector on the HLD is defined to be the same as on the FMHPA
except that a different keying is used.
Aircraft installers should contact equipment manufacturers to determine which of the
wiring schemes presented in this section are appropriate for their equipment.
Notes on wiring configurations:
1. Power, ARINC 429 buses (labeled ‘A429’) and SCM signaling are all
shown as a single line in the drawings for simplicity. These are wire
pairs in reality.
2. The HLD connector definition has connections defined for both the
DLNA BITE Discrete and an ARINC 429 BITE bus. Whether both are
used is the manufacturer’s choice.
3. “SCM signaling” includes duplex RS422 connections.
4. The 2nd coaxial cable between the CSDU and the ELGA connects to
the CSDU bottom plug, insert 6 (see Attachment 1-5c).
7.1 Configuration 1 – Systems using a HLD
This system is suitable for aircraft where some cooling can be provided in the crown
of the aircraft. Because the HLD contains a power amplifier, it can compensate for
increased loss in the RF TX cable as specified in section 0 of this attachment. A
weight saving can be achieved this way.
The baseline interwiring method is shown in Figure 7. Power and HLD control and
BITE information is supplied through the coaxial cables. The ELGA should also
receive power, control and provide BITE information via the single coax from the
HLD.
The alternate interwiring method shown in Figure 8 allows the antenna and HLD to
be controlled via ARINC 429. The Antenna BITE ARINC 429 bus is fed to the HLD.
The intention of this BITE scheme is that the HLD receives BITE words from the
antenna, adds its own BITE words and then reports all of these to the SDU on one
ARINC 429 bus (marked ‘HLD BITE A429’ in the drawings). This scheme only
needs to be supported by manufacturers who offer an HLD, and who make provision
for ARINC 429 control of the antenna. Power to the HLD and the antenna may also
be supplied through the multi-pin connectors.
7.2 Configuration 2 – Systems using a DLNA
When using a standard DLNA, control of the antenna through the antenna RF
coaxial cable is normally not possible. Either a second coaxial cable or ARINC 429
control is required. The design of the specific ELGA will determine which of the two
methods applies.
Power is supplied to the DLNA through the multi-pin connector.
ARINC CHARACTERISTIC 781 – Page 254

ATTACHMENT 7
COMPACT SATCOM DEFINITION (SB200)

The loss in the RF TX cable needs to be kept low, as specified in section 0. This
configuration is suitable for aircraft where cooling of the HLD in the crown of the
aircraft is not possible. The power dissipation in the DLNA is much less than that of
the HLD.
The baseline interwiring method is shown in Figure 9. DLNA control and BITE
information is supplied via the antenna ARINC 429 interface. The ELGA should also
receive power, control and provide BITE information via the multi-pin connector.
The alternate interwiring method shown in Figure 10 makes provision for DLNA BITE
and control using discrete wires from the CSDU. Power to the DLNA may also be
supplied through the multi-pin connector.
7.3 Configuration 3 – Systems using a combined HPA, DLNA and Antenna
This system is suitable for aircraft with high or low cable losses. Because the
antenna contains a power amplifier, it can compensate for increased loss in the
coaxial cable as specified in section 0 of this attachment. A weight saving may be
achieved as only one cable is required between the two LRUs.
The interwiring method is shown in Figure 11.
Power

ELGA

RF RX **

HLD RF **
(DLNA + HPA)
RF TX **
Aircraft
Interfaces Low-
Power
CSDU

** Power, Control and BITE

connections to the HLD and
Power Signalling
ELGA are multiplexed through
the RF cables.

SCM

Figure 7 – Compact Satcom System - Configuration 1 - Baseline wiring

 ARINC CHARACTERISTIC 781 - Page 255

ATTACHMENT 7
COMPACT SATCOM DEFINITION (SB200)

Power Power

ELGA

RF RX
Antenna
RF
HLD
RF TX

Aircraft
Low- Power
Interfaces
Power
CSDU

MutliControl A429
HLD BITE A429 Antenna BITE A429

Power Signalling

SCM

Figure 8 – Compact Satcom System - Configuration 1 - Alternate wiring

Power Power

ELGA

RF RX
Antenna
RF
DLNA
RF TX

Aircraft
High- Power
Interfaces
Power
CSDU DLNA on/off discrete
DLNA BITE discrete

MutliControl A429
Antenna BITE A429

Power Signalling

SCM

Figure 9 – Compact Satcom System – Configuration 2 – Baseline wiring

ARINC CHARACTERISTIC 781 – Page 256

ATTACHMENT 7
COMPACT SATCOM DEFINITION (SB200)

Power Power

ELGA

RF RX
Antenna
RF
DLNA
RF TX

Aircraft
Interfaces High-
Power
CSDU DLNA on/off discrete
DLNA BITE discrete

Power, Control, BITE

Power Signalling

SCM

Figure 10 – Compact Satcom System – Configuration 2 – Alternate wiring

Power

ELGA, plus
HLD functions

RF, power, control & BITE

multiplexed on one RF cable
Aircraft
Interfaces
Low-Power
CSDU

Power Signalling

SCM

Figure 11 – Compact Satcom System – Configuration 3

 ARINC CHARACTERISTIC 781 - Page 257

ATTACHMENT 8
NETWORK SECURITY FOR SWIFTBROADBAND SAFETY SERVICES

1.0 INTRODUCTION
In 2009 Inmarsat announced its intention to offer safety services over
SwiftBroadband (SBB) as an alternative to the Classic Aero service in oceanic
regions.
This attachment contains security guidance for SwiftBroadband safety services that
is intended to facilitate the sharing of SDU resources with safety communications
and other lower-assurance applications such as EFBs and passenger Internet
access. This guidance is intended for the ARINC 781 system designer involved in
the development of the 2 MCU single channels Compact SDU or the 6 MCU, multi-
channel SDU. It provides detailed guidance that will assist in development of a
system design that is intended to satisfy regulatory requirements by providing
adequate risk mitigation against threats that could result in undetected corruption of
FANS messages, the loss of the FANS messaging service, or the loss of cockpit
voice services. Most of the requirements herein are not necessary for strict functional
compliance with the ARINC Characteristic 781 but were developed to support overall
system security. These requirements should be subject to the same verification,
validation, and testing as that of any other functional requirements.
Some sample architectures (i.e., reference designs) are presented and are then
used as a basis for a security analysis based on the process defined in EUROCAE
ED-202A: Airworthiness Security Process Specification (draft) and ED-203 (draft).
This security analysis enabled the development of recommended security
requirements for ARINC 781 systems supporting safety services over SBB. It is
expected that the ED-202A Security Level (SL) should be defined according to the
Design Assurance Level (DAL), as defined in the lastest version of RTCA DO-178:
Software Considerations in Airborne Systems and Equipment Certification and
RTCA DO-254: Design Assurance Guidance for Airborne Electronic Hardware for
each component in the system.
The reference architecture employs the use of separate physical processors to
achieve segregation. A manufacturer may choose to use an alternative design, such
as a single processor employing an ARINC 653-compliant operating system to
achieve the equivalent segregation, or a combination of methods e.g., employing
multiple physical processors where specified processors can support segregated
functions implemented by methods such as the use of ARINC 653. All
implementations should be supported by a security analysis to show that it provides
segregation equivalent to that provided by the reference architecture.
2.0 OBJECTIVES
When designing a secure system, it is important to first document the overall security
objectives. These objectives are typically based on the experience of the system
designer and security experts and guided by an understanding of the functional role
of the system, the threat environment in which it will operate, and its criticality level.
These general objectives are intended to be further refined and augmented during
the security analysis phase.
The following high-level objectives have been identified for ARINC 781 systems
supporting SBB safety services, including both compact and full-size SDUs. They
are not in ranked order and should all be taken into consideration for a system
design.
ARINC CHARACTERISTIC 781 – Page 258

ATTACHMENT 8
NETWORK SECURITY FOR SWIFTBROADBAND SAFETY SERVICES

1. The SDU software should remain Level D to the extent possible (the RTCA
DO-178 design assurance level). If assurance requirements necessitate any
Level C functions, they should be as small as possible.
2. The SB200 design should be able to support SBB safety services and an
EFB running on a single channel card, including support for required priority
and preemption for safety services.
3. SDU designs should ensure that security threats targeting the SDU or using
the SDU as an attack vector cannot cause any safety impact to the aircraft.
4. Security controls should not unduly complicate maintenance and operations
activities.
5. Data loading functions should be designed to preclude the creation of new
vulnerabilities that could be exploited by an attacker or malware directed at
the system software or that of any connected system.
6. Data loading operations should be performed only when explicitly enabled by
authorized maintenance personnel.
7. Packet Data Protocol (PDP) context control should be protected from
unauthorized manipulation.
8. Means should be provided to prevent spoofing of safety-related
communications.
9. Security measures should be designed to prevent attacks that would result in
the decreased or loss of availability of services (e.g., via resource
exhaustion).
10. SDU channel cards should act as transparent modems.
11. The SDU should provide a means for detecting when it is out of software
conformity and generate the appropriate fault notification.
The following security areas are explicitly not addressed by this security guidance:
1. Authentication of ACARS messaging endpoints. Other specifications
address this area (i.e., ARINC Specification 823: Data Link Security, Part 1,
ACARS Message Security).
2. Security requirements for ground systems.
3.0 ARCHITECTURE
The safety services to be delivered over SwiftBroadband include ACARS, cockpit
voice, and an IP Priority data service. The ACARS service packages ACARS
messages into IP packets for transmission between air and ground. For voice, the
first cockpit voice call is delivered using a circuit switched connection, while a
second cockpit voice call is delivered over IP. The ADS-C and CPDLC FANS Air
Traffic Control (ATS) applications utilize the ACARS service over VHF, HF, and
Inmarsat Classic Aero satcom links.
3.1 End-to-End ACARS System Architecture
Figure 1 is a block diagram describing the end-to-end architecture for the ACARS
service, where a single SBB channel (e.g., SB200) is used to deliver the ADS-C and
CPDLC FANS applications, as well as Electronic Flight Bag (EFB) services.
 ARINC CHARACTERISTIC 781 - Page 259

ATTACHMENT 8
NETWORK SECURITY FOR SWIFTBROADBAND SAFETY SERVICES

Aircraft

FANS Application (ADS or CPDLC)

FANS App

Communications Management Unit

CMU EFB
SDU

ACARS Aircraft Gateway

AAGW EFB I/F

BGAN Core

SBB Modem SBB Modem

Satellite Satellite

RAN Radio Access Network

SGSN Supporting GPRS Support Node

GGSN Gateway GPRS Support Node

AGGW ACARS Ground Gateway

ARINC/SITA ARINC/SITA

ANSP Air Navigation Service Provider’

Figure 1 – End-to-End ACARS System Architecture

Figure 1 shows those functions that are resident in the SDU, the aircraft, and the
BGAN Core network. The BGAN Core network, which provides SBB non-safety
communication services, provides standard 3G IP service which is then used by the
air and ground ACARS gateways (AAGW and AGGW) to encapsulate the ACARS
messages as a UDP datagram for transport over IP.
The ground infrastructure is assumed to be operating at the appropriate security
level. Authentication mechanisms between aircraft and ground are therefore not
required.
ARINC CHARACTERISTIC 781 – Page 260

ATTACHMENT 8
NETWORK SECURITY FOR SWIFTBROADBAND SAFETY SERVICES

3.2 Compact SDU Reference System Architecture

A reference architecture for an SB200 compact SDU (CSDU) capable of supporting
SwiftBroadband Safety Services and EFB communications on a single-channel card
is shown in Figure 2.
The key security features of the CSDU system architecture are:
• A hardware-segregated function developed to RTCA DO-254 or DO-178 Level C
controls and mitigates data access to the single channel card, providing
necessary separation and prioritization.
• Resource isolation on the single channel card further ensures separation.
• Data loading is only possible while in maintenance mode on the ground. During
data loading, all other data paths to the AISD processor should be disabled via
hardware logic based on the air-ground state and the data load enable discrete
input.
• EFB traffic will always have a lower priority than safety services.
• The EFB uses a pre-established background context that cannot be changed in
operation.
• Messages that would overflow a message queue are discarded.
 ARINC CHARACTERISTIC 781 - Page 261

ATTACHMENT 8
NETWORK SECURITY FOR SWIFTBROADBAND SAFETY SERVICES

Priority IP Ethernet
ACARS to / from
Cockpit Voice

ADL Ethernet
(Future)

EFB 1
EFB 2
CMU

BITE
SDU
Sw1 Sw2

ACD AISD
Processor Eth Driver Processor Eth Driver
eth0 eth0
BITE
IP IP

Data Load
ACARS Data Load
VoIP
Air
GW
GW

PS PS PS
IP IP
Channel
PPPoE / card PS
ethX
Telnet control
IP
EE
AISD Queue
ACD Queues
Data Arbitration

Control Data
Legend:
AC Domain
BITE AIS Domain
Channel Card
Mixed
CS
Segregation

RF Interface

Figure 2 – Architecture for SB200-S Terminal

The key features of this architecture are described in the following subsections.
3.2.1 Data Arbitration Function
The data arbitration function enforces traffic priority and preemption, and maintains
segregation of traffic between the AC and AIS domains up to the channel card
interface. Appropriate to mitigation of a major hazard, it should be developed to
DO-178/DO-254 Level C and should be segregated in both software and hardware
from the other SDU functions.
In the air-to-ground direction, the data arbitration function arbitrates between an AIS
domain data queue and separate data queues for packet-switched (PS) voice
(VoIP), ACARS, and Priority IP service. The ACD queues always have priority over
the AISD queue. Should any queue overflow, the existing data in the queue is then
discarded. The data queues should use separate memory spaces.
After connecting to the satellite network, the ACD processor automatically instructs
the channel card to create a PDP context specifically to carry data from the AISD.
ARINC CHARACTERISTIC 781 – Page 262

ATTACHMENT 8
NETWORK SECURITY FOR SWIFTBROADBAND SAFETY SERVICES

The data arbitration function marks the data for transmission through this context
based purely on the physical port from which it is received. This marking is achieved
by adding a header identifying the context that the channel card should use for
transmitting the data. The content of the data therefore cannot affect its routing.
The ACD processor similarly creates PDP contexts to be used for data packets
carrying CS, ACARS, and Ethernet data.
The ACD processor adds headers to data packets from the ACD which enable the
channel card to identify the data as Cockpit Voice, ACARS, or Priority IP service.
These headers are added by the EE (Ethernet Encapsulation) function that is part of
the networking protocol stack.
The mechanisms described above allow the channel to transmit data without ever
examining the actual payload data. It only examines the headers to determine the
PDP context to be used for transmission.
The parameters needed to establish the background context for the AISD are
contained in the Owner Requirements Table (ORT). These context parameters
include the Access Point Name (APN) and host name. The priority of this PDP
context is fixed. Neither the EFB nor the AISD processors have any control over the
PDP context and both should be agnostic to the characteristic or profile of the IP
connection. The context parameters cannot, therefore, be manipulated via an attack
from the EFB.
In the ground-to-air direction, the channel card sends data packets to the data
arbitration function with headers identifying the context through which the data was
received. The data arbitration function acts as a switch. It sends data to the AISD
processor or the ACD processor depending on the PDP context it originated from. In
the case of a data packet for the AISD, the data arbitration function removes the
header containing the PDP context identifier before sending the packet to the AISD
processor. In the case of packets for the ACD, the headers containing the PDP
context identifiers are not removed, as the ACD processor needs them to distinguish
between data packets for its different services.
To ensure that other hosts in the ACD cannot be made to inject malicious messages,
the link between the SDU and the ACARS system (e.g., the Communications
Management Unit (CMU) or Communications Management Function (CMF)) should
provide network isolation equivalent to that of a point-to-point ARINC 429
connection.
One possible implementation of the data arbitration function is as part of a Field
Programmable Gate Array (FPGA). Other methods may be possible (e.g., an
ARINC 653 operating system providing segregation) but should achieve a similar
level of segregation and robustness.
3.2.2 ACD (Aircraft Control Domain) Processor
As shown in Figure 2, the ACD processor provides all functions for the following
cockpit communications services:
• A circuit-switched (CS) voice channel
• A Voice over IP channel (VoIP)
• An ACARS Airborne Gateway (AAGW), with an associated port connecting to the
ACARS system (e.g., a CMU)
• An Ethernet interface for a Priority IP service (for unidentified future applications)
 ARINC CHARACTERISTIC 781 - Page 263

ATTACHMENT 8
NETWORK SECURITY FOR SWIFTBROADBAND SAFETY SERVICES

Control of the terminal also resides in the ACD processor. This includes some
functions not shown in Figure 2:
• Control of the antenna
• Control of the HPA
• ARINC 429 navigation data inputs for IRS, GNSS, and Aircraft ID information
• ORT
• Control of the channel card, including instructing the channel card to create
separate PDP contexts to be used for the various ACD and AISD services.
• Data loading (discussed under a separate heading)
• Interface to the Universal Integrated Circuit Card (UICC) (part of the SDU
Configuration Module (SCM))
3.2.3 AISD (Aircraft Information Services Domain) Processor
This processor is intended to provide connectivity to up to two EFBs. Because a
default background class context is pre-established by the ACD processor, no
support is provided for PPPoE or “Telnet” control of the channel card by the EFB or
the AISD processor. There should also be no exchange of control information
between the AISD and the ACD. Note that rather than being directly attached via
Ethernet, EFBs may be connected through an Aircraft Interface Device (AID) that
provides an additional layer of control over data transmission to and from the EFB
units. FAA Advisory Circular 20-173: Installation of Electronic Flight Bag (EFB)
Components, documents the regulatory requirements for EFB data interfaces.
The AISD functions should operate on a separate processor. It should not share
physical memory with the ACD. Alternative methods of achieving separation may be
possible (e.g. a single processor with an ARINC 653 operating system providing
segregation), but alternative solutions should achieve a similar level of segregation
and robustness as demonstrated by a security analysis.
3.2.4 PDP Contexts
The SwiftBroadband system uses the well-established concept of PDP contexts as
defined in the 3GPP system. A PDP context is a virtual bidirectional data pipe that is
established by negotiation between the channel card in the AES and the BGAN core
network. Multiple PDP contexts (up to 11) can be established over the same radio
bearer. This mechanism allows transmission of separated streams of data over a
single radio bearer.
At the time of establishing a PDP context, a PDP context identifier is agreed
between the AES and the core network. A header, which is added to transmitted
data packets, contains this PDP context header allowing the data to be routed
correctly at the receiving end. Each PDP context is associated with an Access Point
Name (APN) on the ground. Each PDP context is also allocated a priority level.
This association between a PDP context identifier and an APN and a priority level
exists for the duration of the PDP context.
PDP contexts can be created, modified, or destroyed as required at any time. This
is normally done by a controller instructing the channel card in the AES. The
channel card then negotiates the PDP context with the ground and reports back.
In an AES terminal, the ACD processor should set up the required PDP contexts for
ACARS and AISD IP data as soon as the channel card has connected to the
SwiftBroadband network. The APN for the ACARS PDP context is the AGGW. The
ARINC CHARACTERISTIC 781 – Page 264

ATTACHMENT 8
NETWORK SECURITY FOR SWIFTBROADBAND SAFETY SERVICES

ACD processor also associates this PDP context with the AAGW internally. In this
way, one PDP context with the correct priority level forms a virtual data pipe between
the AAGW and AGGW. This association should remain for as long as the terminal is
connected to the SwiftBroadband network for the purposes of providing safety
services.
Similarly, a durable association with a PDP context is set up connecting the AISD
processor to an appropriate APN which provides connectivity to the internet.
The primary (AMBE+2) voice channel is handled by special provision in the BGAN
network without the need to set up a PDP context. A secondary voice channel uses
VoIP, however, for which a special PDP context is created on-demand by the ACD
processor.
For the sake of network security, the ACD processor should manage the setup,
modification, and destruction of all PDP contexts on the channel card.
The control of the channel card, particularly the setup of PDP contexts, should be
robust. A robust bi-directional link between the ACD processor and the channel card
should be used for the purpose. The creation of a PDP context should be confirmed
by the channel card. The PDP context identifier agreed between the channel card
and the RAN (as described in the Inmarsat SDM) should be passed to the ACD
processor. This identifier should be used in the headers to identify the context used
for data packets in both directions. For this reason, the ACD processor should also
notify the data arbitration function of the PDP context identifier for the AISD.
3.2.5 PPPoE / Telnet Control
External equipment using the priority IP Interface may be used to control the creation
and properties of IP contexts by the channel card, utilizing the protocol described in
Attachment 5. In the case of an SB200 safety services terminal, it is important that
the PPPoE / Telnet messaging is handled in the ACD processor, and such
messages are not passed to the channel card for interpretation. The ACD processor
should then control the channel card, typically using a proprietary interface and
protocol.
This mechanism allows the ACD processor to moderate the control of PDP contexts.
In particular, the ACD processor should prevent the external equipment from
affecting PDP contexts which the external equipment did not create, such as the
context used for ACARS. In addition, only trusted equipment in the ACD should be
allowed to have PPPoE / Telnet control over PDP contexts.
If the external equipment does not specifically require PPPoE/Telnet control over
PDP contexts, the ACD processor may be configured to set up a background context
for the priority IP port automatically (as it does for the AISD). PPPoE/Telnet control
may be disabled in this case. To make provision for different avionics equipment
connected to the priority IP port, the following options should be configurable in the
secure ORT:
• Create a default background context for the priority IP port (enable / disable, and
PDP context parameters).
• Allow PPPoE/Telnet control over the priority IP port (enable / disable).
 ARINC CHARACTERISTIC 781 - Page 265

ATTACHMENT 8
NETWORK SECURITY FOR SWIFTBROADBAND SAFETY SERVICES

3.2.6 ACARS Airborne Gateway (AAGW)

This gateway receives one ACARS message at a time from the CMU/CMF. The
AAGW wraps ACARS messages into UDP packets as described in the Inmarsat
SDM. It exchanges packets directly with the AGGW, handling all the necessary
protocol, including keep-alive messages and position reporting.
3.2.7 Data Loading
ARINC 615A data loading is performed only through a port of the ACD processor.
Software part integrity is assumed to be assured by functions and processes
external to the SDU (such as the central data loading computer verifying the
software image before loading it to the SDU). All SDU subsystems, (e.g., ACD
processor, AISD processor, data arbitration function, and channel card) should be
individually or collectively data loaded through this interface. The ACD processor, in
turn, loads other processors in the SDU.
To ensure that data loading can only happen while the aircraft is in maintenance
mode and not during operation, data loading capability should be disabled under
control of the ACD processor during normal operation. No data flows should,
therefore, be possible over the data load lines while the system is in operation.
While data loading, all other data flows to the AISD processor should be disabled by
hardware logic based on the air-ground state and the data load enable discrete
input.
Data loading from the ACD processor to the AISD processor should use one-way
open-loop communication only. There should be no data path by which the AISD
behavior can influence the ACD processor. The AISD processor should not be able
to influence the data loaded by the ACD processor.
One possible implementation is for the ACD processor to write directly to the
program memory of the AISD processor with the AISD processor having read-only
access to this memory.
Out-of-conformity conditions for the loaded software should be detectable and
generate a fault when seen.
3.2.8 BITE
The ACD processor reports BITE information to the central maintenance function.
For this purpose, the AISD processor reports discrete BITE signals to the ACD
processor. The ACD processor reads these discrete signals by polling. No
interrupts are involved; therefore, BITE from the AISD processor cannot affect ACD
processor operation.
3.2.9 Channel Card
The channel card is considered to be a transparent modem. To maintain this
transparency it is required that:
• The channel card should not be able to be compromised by the content of
payload data. The channel card should, therefore, not examine the content of
payload data.
• There should be no mechanism (e.g., via addressing) by which the channel card
can be made to pass data from the AISD processor to the ACD processor.
• The process of examination of packet headers to determine the PDP context of
air-to-ground packets should be robust. A header, which is malformed or that
ARINC CHARACTERISTIC 781 – Page 266

ATTACHMENT 8
NETWORK SECURITY FOR SWIFTBROADBAND SAFETY SERVICES

does not match an established PDP context, should cause the packet to be
discarded.
• While it is essential for the channel card to analyze many protocol layers of
ground-to-air data to satisfy operation of the SBB system, the final payload IP
data should not be analyzed by the channel card. Out-of-range or unexpected
data within the PDP context identifier should not lead to malfunction of the
channel card. Any error during PDP context analysis should lead to discarding of
the data packet.
• The channel card should robustly implement the protocol described in the
Inmarsat SDM to ensure that ground-to-air data received over one PDP context
does not get passed on with an incorrect PDP context identifier resulting in the
data being routed to the wrong destination by the data arbitration function.
• The channel card, in conjunction with the RAN, should enforce the traffic priority
and preemption over the SBB air-interface as specified in the Inmarsat SDM.
4.0 SECURITY ANALYSIS
After the reference architecture was developed, a condensed security analysis was
performed based on the airworthiness security process defined in RTCA draft
document DO-326A (EUROCAE ED-202A). This process helps ensure that all
potential security threats have been accounted for and that the threats are
adequately mitigated when there is a potential safety impact due to a security failure.
An ARINC 811-based analysis was done to aid the system designer. This is
published in Appendix B, Security Analysis of the Satcom Ethernet Interfaces.
System designers should plan to conduct a full security analysis on their complete
design as part of the overall development process.
The process defined in RTCA DO-326A is comprehensive and is intended to cover
the end-to-end airplane design process from the airplane level down to the system
and item levels. It is intended to align closely with SAE ARP4754A. Because
ARINC 781 defines just one system, only a subset of the overall process was used.
At a high level, the analysis process consists of the following steps:
1. Identify the security scope to determine the points of entry to the system.
2. Identify the external threats that can attack those entry points and how they
can impact the system.
3. Determine the overall security architecture of the system, including the
potential vulnerabilities and any existing mitigations against the threats.
4. Determine security risks for the system, based on impact and likelihood of
successful attacks.
5. Identify threat conditions with a non-trivial safety impact, and mitigations that
reduce the risks to an acceptable level. Develop additional mitigations as
needed to address any remaining unacceptable risks.
6. Identify any external dependencies that contribute to the overall security of
the system including operational requirements.
 ARINC CHARACTERISTIC 781 - Page 267

ATTACHMENT 8
NETWORK SECURITY FOR SWIFTBROADBAND SAFETY SERVICES

Figure 3 shows the key questions to be answered as part of the security analysis.

Figure 3 – Security Analysis Questions

The analysis was performed against the reference architecture for a compact SDU
described previously in this Characteristic.
4.1 Assumptions and Operational Requirements
The assessment is based on the following key operational requirements for the
security environment. If these requirements are not met, the security assessment
does not apply:
1. Maintenance personnel will follow approved procedures.
This includes MRO personnel.
o The system designer, operator and regulator should agree on a
characterization of the likelihood and severity of maintenance personnel
errors; including the possibility that malware may be unknowingly carried
to the airplane on a maintenance terminal.
ARINC CHARACTERISTIC 781 – Page 268

ATTACHMENT 8
NETWORK SECURITY FOR SWIFTBROADBAND SAFETY SERVICES

2. Flight crews will follow approved procedures.

o The system designer, operator, and regulator should agree on a
characterization of the likelihood and severity of flight crew errors
including the possibility that malware may be unknowingly carried to the
airplane on a portable crew device such as a tablet.
3. Interfaced systems at higher assurance levels will not serve as a launching point
for attacks on the system.
o Higher-assurance systems will not be corrupted by attackers.
o Such systems may also not provide any protection to the SDU if attacks
are simply passed through to the SDU, thus, enabling the attack vector.
Any such dependencies should be evaluated for each installation.
4. System software is non-malicious and free of intentional flaws.
5. Physical access to the satcom systems controlled to the same degree as
physical access to installed on-board electronic systems in general. That is,
there are no special access physical control requirements, nor is access control
requirements relaxed.
6. Airline procedures are adequate to record satcom maintenance actions.
7. The security requirements of the ground infrastructure and satellite network are
outside the scope of this document.
4.2 Security Scope
The security scope of a system is defined by the security perimeter, hardware,
software, data assets requiring protection, and the external dependencies that define
additional security measures to be provided by external systems or entities. The
security perimeter is comprised of the external network interfaces and data flows that
may expose the system to attack.
For the CSDU, the security perimeter is enumerated below.
4.2.1 Interfaces
All interfaces on the SDU system should be treated as part of the security perimeter
since they are potential attack vectors.
Network interfaces on CSDU:
1. Interface to cockpit phone
2. ARINC 429 or ARINC 664 interface to ACARS application system, e.g. CMU
3. Ethernet interface for Priority IP service (bandwidth management)
4. Ethernet or ARINC 429 data loading interfaces
5. Two Ethernet interfaces for EFBs
6. ARINC 429 interfaces to RF subsystems (HF and VHF)
7. Multiple read-only ARINC 429 bus inputs for ADIRS, WoW, etc.
Multi-channel SDUs will have additional Ethernet interfaces to cabin (AISD) and
Passenger Information and Entertainment Services Domain (PIESD) systems.
These interfaces should be included in the analysis. However, it is noted that it is
not possible to attack ACD or AISD from PIESD via the normal data path since a
channel card cannot be made to communicate with another channel card (via the RF
splitter/combiner). Only the BITE and data load paths are considered in the
analysis.
 ARINC CHARACTERISTIC 781 - Page 269

ATTACHMENT 8
NETWORK SECURITY FOR SWIFTBROADBAND SAFETY SERVICES

Also, if ARINC 664 (deterministic Ethernet) is used for any interfaces, it would likely
be used instead of the standard Ethernet interfaces (i.e., an aircraft network would
likely use either deterministic Ethernet or regular Ethernet, but not both side-by-
side).
4.2.2 Assets
The assets characterize the system well enough to identify the potential targets of
attack. Assets include functions, data, and resources that are associated with
airworthiness or airworthiness security. These are the components of the system
that, if attacked, will cause an adverse effect on aircraft safety. For purposes of this
analysis, we are focused on the safety services to be carried over the SBB network
as they are managed by the SDU system on the airplane.
1. ACARS messages containing ATS or Airline Operational Communications
(AOC) messages
2. Cockpit voice calls, either circuit-switched or packet-switched (VoIP)
3. IP data to or from the cockpit (future use, not analyzed here)
4. ORT-based configuration data for the SDU
5. System software
6. The data arbitration function (listed separately due to its importance to the
security of the system)
7. Universal Subscriber Identity Module (USIM) (which operates on the UICC
within the SCM)
8. PPPoE client software hosted on external system
9. Data loading functions and controls (e.g., WoW input, manual analog switch
inputs)
10. BITE reporting
11. Security functions
EFBs, other cabin systems, and passenger data are excluded from this analysis
because, they are either under protection of systems external to the SDU, has no
safety impact, or both. Also specifically excluded are the ground systems
communicating with the airborne equipment; ground systems are treated as external
dependencies.
4.2.3 External Dependencies
External dependencies are elements, functions, systems, or processes that
contribute to the overall security of the system under analysis but are outside the
perimeter of the system. For the SDU, these include:
1. Inmarsat ground station systems
Ground station systems should adhere to aviation industry best practices for
mission critical IT systems, for example, the U.S. National Institute of
Standards and Technology (NIST) risk management framework, which is
used by the FAA for security evaluation of Comm/Nav/Surveillance ground
systems. Specific control measures should include, but are not limited to:
ARINC CHARACTERISTIC 781 – Page 270

ATTACHMENT 8
NETWORK SECURITY FOR SWIFTBROADBAND SAFETY SERVICES

• Systems should be audited on a regular basis for adherence to a

documented security policy.
• Firewall configurations should be audited regularly for correctness.
• Security monitoring systems should be used to provide real-time
detection of malware and intrusion attempts.
• Unauthorized connections initiated from the ground to the airplane
should be strictly controlled.
• User and administrative accounts should be regularly reviewed for
correct authorizations.
• Workstations used for general Internet access should be network-
segregated from the core critical systems supporting the airplanes.
• All logins should require strong authentication.
Identified deficiencies may require re-evaluation of the airborne side security
analysis.
2. Data loaders and portable maintenance terminals
Airlines and MROs should have processes in place to ensure that data
loaders and maintenance terminals do not become infected with malware and
are access-restricted to authorized and licensed maintenance personnel only.
3. In-flight Entertainment (IFE) systems
In a multi-channel system providing passenger Internet access, the IFE
system should provide packet filtering that limits attacks from PIESD that are
directed at the SDU.
4.3 Identification of Threats
This part of the analysis consists of developing the threat source profiles, threat
conditions, threat scenarios, and security objectives as part of the preliminary
security risk assessment.
4.3.1 Threat Source Profiles
A threat source profile describes the attacker population and the vectors by which an
attacker may attempt to compromise the system through the security perimeter.
Threats are either direct or indirect. Direct threats come from defined attacker
populations attempting to penetrate the security perimeter. Indirect threats are those
posed by malware that may execute an attack against an interface without the
participation or knowledge of the involved persons (e.g., flight crew or maintenance
crew using portable devices that connect to the airplane or ground systems). Such
external devices and systems are out of the configuration control of the satcom
system designer and should, therefore, be treated as untrusted. Attack vectors are
limited to those which cross the perimeter boundary (refer to Section 4.2.1 for
interfaces). Other vectors internal to the SDU have been proposed for consideration
but are secondary and should be treated as a sub segment of the appropriate
primary vector that traverses the perimeter. The likelihood rating is taken from
RTCA DO-326 and ranges from extremely improbable (pl) to frequent (pv). It is
based on the anticipated frequency of attack for that source and vector without
taking mitigations into consideration. Later in the analysis process, the design and
operational procedure risk mitigations are taken into account, and the system design
requirements are adjusted as needed until the mitigations reduce the risk to an
 ARINC CHARACTERISTIC 781 - Page 271

ATTACHMENT 8
NETWORK SECURITY FOR SWIFTBROADBAND SAFETY SERVICES

acceptable level based on impact and likelihood. For example, a risk of probable
(pIV) likelihood may be acceptable at level IV (minor) impact, but not acceptable at
level III (major) impact.
Note that time of exposure to a threat source is another variable to be considered.
Attackers onboard the aircraft have, at most, one flight segment to complete an
attack (and are able to attack only one aircraft), while attackers on the ground have
both significantly longer timeframes for an attack, plus the potential ability to impact
multiple aircraft simultaneously (i.e., all aircraft connected through a specific ground
station).
The assumptions stated above eliminate some threat source profiles from
consideration in this analysis. Also, some threat source profiles will not trace to a
threat condition, meaning they may present a security issue but not a safety issue.
These threat source profiles are nonetheless included in Table 1 for sake of
completeness, and are dispositioned accordingly.

Table 1 – Threat Source Profiles

Unmitigated Basic Attack
Source Attack Vector
Likelihood
General population Indirect attack by compromised [not considered in this analysis, as
ACD system on Ethernet IP Priority services have not yet
interface for IP Priority services been identified]
Maintenance personnel Indirect attack by malware on pIV
maintenance terminal or data (assumes normal controls in place
loader on data load interface by airline or MRO to keep malware
off of systems)
Flight crew Indirect attack by malware on pIV
EFB system via Ethernet (assumes normal controls in place
interfaces by airline to keep malware off of
portable EFB devices)
Internet users Via ground station to SDU pV
Authorized ground station Via ground station to SDU pIV
personnel
General population Indirect attack on SDU from pIV
malware on ground station
systems
General population Compromised or malware- pIV
infected attached system on
Ethernet interfaces to AISD
Passengers Compromised or malware- pV
infected attached system on
Ethernet interfaces to PIESD
(on multi-channel system only)
ARINC CHARACTERISTIC 781 – Page 272

ATTACHMENT 8
NETWORK SECURITY FOR SWIFTBROADBAND SAFETY SERVICES

4.3.2 Threat Conditions

A threat condition results when safety of the aircraft is adversely affected due to a
security failure (i.e., a successful attack executed by a threat). Two main threat
conditions are identified for SBB safety services:
1. Undetected corruption of FANS messages (includes spoofing)
2. Loss of availability of safety services
4.3.3 Threat Scenarios
Threat scenarios lay out all the elements necessary for an attack to be successful
and cause an impact to aircraft safety. The two scenarios below are mapped to the
threat conditions for SBB safety services. They include multiple threat source
profiles that map to the same threat condition.
Threat Scenario (1): Spoofed ACARS (FANS) messages
Element Description
Assets involved ACARS messaging, data arbitration function
Threat condition that results from Spoofed ACARS messages injected into system
attack (undetected corruption)
Vulnerabilities involved Inadequate separation between ACD and AISD
Vulnerable EFB software
Inadequate processes to prevent infection of portable
cockpit or maintenance devices
Operational events or conditions While in maintenance or operational mode, corrupted
involved data update loaded to EFB includes malware capable of
injecting spoofed ACARS messages to or from ATC or
While in maintenance mode, malware capable of
injecting spoofed ACARS messages attaches to data
load process and installs on AISD processor of SDU.
Attack may be launched when in operational mode.
While in operational mode, malware may contact a
command and control server on the Internet for attack
instructions.
Potential attacks Indirect threat: attackers cause malware to be loaded
onto EFB system, which attacks SDU’s ACD partition via
Ethernet interfaces, or
Attackers cause malware to be loaded into AISD
processor’s memory, which attacks SDU’s ACD partition
by attempting to inject spoofed messages, or
Attackers cause malware to be loaded into PIESD
processor’s memory, which attacks SDU’s ACD partition
by attempting to inject spoofed messages
Security countermeasures intended Data arbitration function in SDU
to intervene Pre-established PDP context for EFB side
Separate channel cards for AISD and PIESD in multi-
channel configurations
No PIESD support in single-channel systems
Airline processes for preventing malware infection of
EFBs
Airlines or MRO processes for preventing malware
infection of portable maintenance devices
 ARINC CHARACTERISTIC 781 - Page 273

ATTACHMENT 8
NETWORK SECURITY FOR SWIFTBROADBAND SAFETY SERVICES

Threat Scenario (2): Loss of Availability of SBB Safety Services

Element Description

Assets involved ACARS, cockpit voice, data arbitration function

Threat condition that results from Loss of safety service availability

attack

Vulnerabilities involved • Inadequate separation between ACD and

AISD
• Inadequate processes to prevent infection of
portable cockpit or maintenance devices
• Inadequate resistance of data arbitration
function to resource exhaustion

Operational events or conditions • While in maintenance mode, malware capable

involved of flooding or otherwise exhausting resources
for SBB services attaches to data load
process and installs on AISD processor of
SDU. Attack may be launched when in
operational mode.
• While in operational mode, malware may
contact a command and control server on the
Internet for attack instructions

Potential attacks • Indirect threat: attackers cause malware to be

loaded onto EFB system, which attacks an
SDU’s ACD partition via Ethernet interfaces,
or
• Attackers cause malware to be loaded into an
AISD processor’s memory, which attacks an
SDU’s ACD partition by attempting to flood it
with packets or connection requests, or
• Attackers cause malware to be loaded into a
PIESD processor’s memory, which attacks an
SDU’s ACD partition by attempting to flood it
with packets or connection requests
• Attackers on the ground attempt to flood the
forward link with traffic and starve bandwidth
ARINC CHARACTERISTIC 781 – Page 274

ATTACHMENT 8
NETWORK SECURITY FOR SWIFTBROADBAND SAFETY SERVICES

Threat Scenario (2): Loss of Availability of SBB Safety Services

Element Description

Security countermeasures intended • Data arbitration function in the SDU drops

to intervene overflow packets
• Pre-established PDP context for EFB side
prevents improper routing and prioritization,
and limits return link bandwidth utilization
• Ground systems are protected from
unauthorized access, and throttle traffic that
would fill the satellite link
• The channel card, data arbitration function and
Inmarsat ground station enforce priority and
preemption of safety service data.

4.3.4 Security Objectives

Security objectives at this stage of the analysis help define what is needed to
counter the threat scenarios that have been identified as needing mitigation.
• Attempts to inject false ACARS messages should be prevented.
• Attempts to flood the SDU from either air or ground to reduce availability of
bandwidth for safety services should be prevented.
4.4 Validation of the Security Architecture
This step demonstrates that the design requirements (as expressed in the reference
architecture in this document) will meet the security objectives. An adequate design
will possess certain soundness properties that support its ability to meet the
objectives. Each property below is followed by the architectural elements from the
reference architecture that supports it. (excerpted from RTCA DO-326).
• The architecture does not allow its security countermeasures to be bypassed,
and the countermeasures will always be invoked when they are intended to
be invoked.
o The data arbitration function resides in the main data path to control
all data transmissions. It cannot be bypassed. For other design
approaches (e.g., an ARINC 653-compliant operating system), the
designer should ensure the same level of control is achieved.
• The architecture does not allow the security countermeasures to be tampered
with.
o The data arbitration function does not act on the contents of packets
from the EFB/AISD side, and it is not network-addressable.
Therefore, an attacker is not able to modify the operation of this
function.
 ARINC CHARACTERISTIC 781 - Page 275

ATTACHMENT 8
NETWORK SECURITY FOR SWIFTBROADBAND SAFETY SERVICES

• The security countermeasures do not interfere with each other except as

intended.
o The primary countermeasures are distinct from each other and should
not present interference issues in an implementation.
• The architecture provides restorative means for establishing (or re-
establishing) the correct configuration of the architecture.
o A requirement for software conformity-checking enables alerting of a
mechanic to reload the SDU software.
4.5 Impact Classification of Threat Conditions
Impact of a threat condition is based on the adverse effect on safety without taking
likelihood into account. The following impact levels are taken from safety analyses
of FANS communications previously performed by experts for current aircraft models
(e.g., B787).

Threat Condition Impact Level

Undetected corruption of FANS messages III (major)
(includes spoofing) Spoofed FANS messages could result
in false CPDLC messages instructing
the flight crew to change heading or
flight level, causing a reduction in safety
margins.

Loss of availability of safety services IV (minor)

Loss of ACARS over SBB is mitigated
via fallback to ACARS over Classic
Aero Inmarsat service or HF radio in
oceanic regions.
ARINC CHARACTERISTIC 781 – Page 276

ATTACHMENT 8
NETWORK SECURITY FOR SWIFTBROADBAND SAFETY SERVICES

4.6 Preliminary Risk Assessment

Based on the attack likelihoods determined for the threat source profiles and the
aggregated impact levels for the threat conditions, the risk levels are determined as
follows:
Undetected corruption of FANS messages
Likelihood pIV / Impact III Unacceptable: determine effectiveness
of security countermeasures to reduce
likelihood to pIII or lower.
Countermeasures of Security
Assurance Level D are therefore
needed to reduce this threat likelihood
to an acceptable level of pIII
(“Remote”).
Loss of availability of safety services
Likelihood pIV / Impact IV Acceptable: no further
countermeasures are needed
Refer to DO-326, Table 11, “Risk Matrix” for details.

4.6.1 Risk Mitigation

The CSDU reference design in this document relies primarily on the data arbitration
function to mitigate most of the threats. This function should be developed to meet
the effectiveness requirements at Security Assurance level D. For multi-channel
SDUs, including those providing passenger access off-board, physical channel card
segregation provides the necessary partitioning and attack prevention. The IFE
system is treated as an external dependency that provides some measure of packet
filtering on passenger traffic to limit attacks on the SDU.
For Security Assurance Level D countermeasures, it is adequate to sufficiently
define the functional requirements needed to prevent the attacks in the threat source
profiles, and then conduct verification and vulnerability testing against the actual
implemented system to ensure that the requirements have been met. This should
also include robustness testing against denial of service attacks.
5.0 Considerations for Multi-Channel Swiftbroadband Systems
In order to provide maximum leverage of the SB200 design work and reduce
development costs, the reference design for a multi-channel system uses the core
SB200 design and adds channel cards as needed to support additional lower-
assurance cabin and passenger applications (e.g., in-flight Internet access).
For sake of completeness, three configurations of multi-channel AES equipment
have been identified, and are described in the following paragraphs. These
configurations are aimed at addressing network security concerns.
In all three configurations, the common resources (e.g., HPA and antenna) are
controlled by the ACD processor. Priority should always be given to safety services
in the allocation of these resources.
 ARINC CHARACTERISTIC 781 - Page 277

ATTACHMENT 8
NETWORK SECURITY FOR SWIFTBROADBAND SAFETY SERVICES

In all three configurations, the domains are segregated from each other by using
separate processors for each domain, with no shared memory. Other methods may
be possible (e.g., an ARINC 653 operating system providing segregation), but
alternative solutions should achieve a similar level of segregation and robustness.
In addition, the safe BITE and data loading principles, as described for the SB200
system, should be used.
The configurations shown below assume the use of multiple channel cards, where
each channel card provides a single SBB channel. Manufacturers may wish to
employ channel cards which can provide multiple SBB channels, provided
segregation is maintained where necessary. For example a multi-channel capable
card may not need to meet any segregation requirement if all the channels are used
for PIESD. If, however, a multi-channel card is to be used for data belonging to
separate network domains (ACD/AISD/PIESD), it should provide segregation
equivalent to that provided by using separate channels cards for each network
domain.
ARINC CHARACTERISTIC 781 – Page 278

ATTACHMENT 8
NETWORK SECURITY FOR SWIFTBROADBAND SAFETY SERVICES

Configuration 1:
Configuration 1, shown in Figure 4, uses a single-channel card for all cockpit
communications (ACD and AISD) using the architecture described above for SB200.
The other (one to three) channel cards may then be used for cabin communications
services (PIES).

Priority IP Ethernet
ACARS to / from
Cockpit Voice

ADL Ethernet

Cabin IP 1
Cabin IP 2
Phones
EFB 1
EFB 2
CMU

BITE

SDU
Sw1 Sw2 Sw3

Legend:

ACD Processor AISD PIESD AC

Processor Processor Domain
BITE
AIS
BITE
Domain
Data
Load
Data PIES
Load Domain

Segre-
Data gation
Load

Data
Arbitration
CS Data
Data
Data Ctrl
Load
Load
Ctrl Load Data BITE Data

Channel Card Channel Card

BITE Channel Card
Channel Card
CS

RF
Split / Combine

RF Interface

Figure 4 – Multi-Channel System Configuration 1

 ARINC CHARACTERISTIC 781 - Page 279

ATTACHMENT 8
NETWORK SECURITY FOR SWIFTBROADBAND SAFETY SERVICES

Configuration 2:
Configuration 2, shown in Figure 5, uses separate channel cards for each domain.
The ACD uses one channel card, the AISD uses one channel card, and the PIESD
uses the remaining one or two channel cards.

Priority IP Ethernet
ACARS to / from
Cockpit Voice

ADL Ethernet

Cabin IP 1
Cabin IP 2
Phones
EFB 1
EFB 2
CMU

BITE

SDU
Sw1 Sw2 Sw3

Legend:

ACD Processor AISD PIESD AC

Processor Processor Domain
BITE
AIS
BITE
Domain
Data
Load
Data PIES
Load Domain

Segre-
Data gation
Load

Data Data CS Data

Ctrl Ctrl
Load Load
Ctrl BITE Data BITE Data

Channel Card Channel Card Channel Card

BITE Channel Card
CS

RF
Split / Combine

RF Interface

Figure 5 – Multi-Channel System Configuration 2

ARINC CHARACTERISTIC 781 – Page 280

ATTACHMENT 8
NETWORK SECURITY FOR SWIFTBROADBAND SAFETY SERVICES

Configuration 3:
Configuration 3, shown in Figure 6, allocates one channel for ACD use and is
segregated from the other two domains. The AISD and PIESD share the remaining
channel cards. Segregation between the AISD and the PIESD is achieved by a
specialized Ethernet switch designed to provide protection to the AISD, either
internal or external to the SDU. The design of this switch is beyond the scope of this
document.

Priority IP Ethernet
ACARS to / from
Cockpit Voice

ADL Ethernet

Cabin IP 1
Cabin IP 2
Phones

EFB 1
EFB 2
CMU

BITE

SDU
Note: Sw2 can be internal or
Sw1 Sw2 external to SDU

ACD Processor PIESD & Legend:

AISD AC
BITE
Processor Domain

Data AIS
Load Domain

PIES
Domain

Segre-
gation
Data
Load

Data CS Data
Data
Ctrl
Load
Load
BITE Data

Channel Card Channel Card

BITE Channel Card
Channel Card
CS

RF
Split / Combine

RF Interface

Figure 6 – Multi-Channel System Configuration 3

 ARINC CHARACTERISTIC 781 – Page 281
ATTACHMENT 9
ATTACHMENT REFERENCE GUIDE

Attachment
Description
Number
1-1A General Configuration Overview – Single Satcom Installation
1-1B General Configuration Overview – Dual Satcom Installation
1-2A Satcom System Configuration – HPA Integrated in SDU
1-2B Satcom System Configuration – Optional Flange Mounted HPA
1-3 Standard Interwiring
1-4 Notes Applicable to Standard Interwiring
1-4A System Configuration Pins Definition and Interpretation
1-5 SDU Form Factor
1-5A SDU Top Plug Connector Layout
1-5B SDU Middle Plug Connector Layout
1-5C SDU Bottom Plug Connector Layout
1-6 SDU Configuration Module Form Factor
1-6A SDU Configuration Module Connector Layout
1-7A Small Flange Mount HPA Form Factor
1-7B Large Flange Mount HPA Form Factor
1-7C Flange Mount HPA Connector Layout
1-8 Diplexer/LNA Form Factor
1-8A Diplexer/LNA Connector Layout
1-9 Antenna Coverage
1-10 High Gain and Intermediate Gain Antenna Footprint
1-10A Close-up View of the Coaxial Interface for Top Mounted HGA and IGA
1-11 Low Gain Antenna Footprint
1-12 High Gain and Intermediate Gain Antenna Control Connector Layout
ARINC 429 Labels And Word Formats Used In The Aviation Satellite
2
Communications System
2A Antenna Configuration Data Reporting
2B Bit-Oriented Fault Reporting Protocol
3 Cockpit Voice – SAT Phone State Machine for Normal Operation
4-A ARINC 781 SDU Functions Matrix
4-B ARINC 781 SDU Interfaces Matrix
5 Ethernet Interface Control Document
6 ARINC 781 HPA Output Power Use Cases
7 Compact Satcom Definition (SB200)
8 Network Security For SwiftBroadband Safety Services
9 Attachment Reference Guide
ARINC CHARACTERISTIC 781 – Page 282
APPENDIX A
ACRONYMS

3D Three Dimensions
3GPP Third Generation Partnership Project
A/C Aircraft
AAC Airline Administrative Communications
AAGW ACARS Aircraft Gateway
ac Alternating current
AC Access Concentrator
ACARS Aircraft Communications Addressing and Reporting System
ACD Aircraft Control Domain
ACP Audio Control Panel
ACR Avionics Communication Router
ADIRS Air Data Inertial Reference System
ADL Airborne Data Loader
ADS-C Automatic Dependent Surveillance – Contract
ADSU Automatic Dependent Surveillance Unit
AEEC Airlines Electronic Engineering Committee
AES Aircraft Earth Station
AAGW ACARS Aircraft Gateway
AGGW ACARS Ground Gateway
AGC Automatic Gain Control
AISD Aircraft Information Services Domain
AM/PM Amplitude Modulation/Phase Modulation
AMBE Advanced Multi-Band Excitation (speech encoding algorithm)
AMCP Aeronautical Mobile Communications Panel
AMM Aircraft Maintenance Manual
AMR(S) Aeronautical Mobile-Satellite (Route) Service
AMS Audio Management System
AMSS Aeronautical Mobile Satellite Services
ANSP Air Navigation Service Provider
ANT Antenna
AOC Airline Operational Control
APC Airline Passenger Communications
APM Aircraft Personality Module
APN Access Point Name
AT Attention
ATC Air Traffic Control
ATG Air-to-Ground
ATE Automatic Test Equipment
ATLAS Abbreviated Test Language for All Systems
ATS Air Traffic Services
 ARINC CHARACTERISTIC 781 – Page 283
APPENDIX A
ACRONYMS

BABT British Approvals Board for Telecommunications

BER Bit Error Rate
BIT Binary Digit
BITE Built-In Test Equipment
BGAN Broadband Global Area Network
BNR Two's Complement Binary Notation
BP Bottom Plug
bps bits per second
BRI Basic Rate Interface
BSS Business Support System
BSU Beam Steering Unit
C Celsius
C/M Carrier-to-Multipath Ratio
C/No Carrier-to-Noise Density Ratio
CAIMS Centralized Airplane Information Management System
CCDF Complementary Cumulative Distribution Function
CCIR International Consultative Committee for Radio
CCS Cabin Communications System
CDM Configuration Data Module
CDU Control Display Unit
CEPT European Conference of Postal and Telecommunications Administrations
CFDS Centralized Fault Display System
CFR Code of Federal Regulations
CLI Command Line Interface
CMC Central Maintenance Computer
CMF Communications Management Function
CMU Communications Management Unit
CN Core Network
CODEC Coder/Decoder
CPD Cabin Packet Data
CPDF Cabin Packet-mode Data Function
CPDLC Controller/Pilot Data Link Communications
CR/LF Carriage Return/Line Feed
CRC Cyclic Redundancy Check
CS Circuit Switched
CSDU Compact SDU
CTU Cabin Telecommunications Unit
DAL Development Assurance Level
DLNA Diplexer/Low Noise Amplifier
dB Decibel
ARINC CHARACTERISTIC 781 – Page 284
APPENDIX A
ACRONYMS

dB/K Decibel per Kelvin

dbC Decibel relative to carrier
dBi Decibel relative to isotropic
dBic Decibel relative to isotropic, circular polarization
dBm Decibel relative to one milliwatt
dBW Decibel relative to one watt
dc direct current
DCN Data Communication Network
DHCP Dynamic Host Configuration Protocol
DIP Diplexer
DLNA Diplexer/Low Noise Amplifier
DoS Denial of Service
DP Distribution Partner
DTMF Dual Tone Multi-Frequency
ECAM Electronic Centralized Aircraft Monitoring
EDU Electronic Display Unit
EE Ethernet Encapsulation
EFB Electronic Flight Bag
EICAS Engine Indication and Crew Alerting System
EIRP Effective Isotropic Radiated Power
ELGA Enhanced Low Gain Antenna
EMI Electromagnetic Interference
EOT End of Text
EQID Equipment Identifier
ETX End of Text
EUROCAE European Organization for Civil Aviation Equipment
EVM Error Vector Magnitude
FAA Federal Aviation Administration
FANS Future Air Navigation System
FCC Federal Communications Commission
FDE Flight Deck Effect
FID Forward Identification Number (for Swift64 services)
FMC Flight Management Computer
FMHPA Flange-Mount HPA
FNN Fixed Network Node
FPGA Field-Programmable Gate Array
FPLMTS Future Public Land Mobile Telecommunications System
FT Functional Test
FW Failure Warning
G/T Gain to Noise Temperature Ratio
 ARINC CHARACTERISTIC 781 – Page 285
APPENDIX A
ACRONYMS

GES Ground Earth Station

GGSN Gateway GPRS Support Node
GHz Gigahertz (109 Hz)
GLONASS Global Navigation Satellite System
GND Ground
GNSS Global Navigation Satellite System
GPRS General Packet Radio Services
GPS Global Positioning System
GSDB GES-Specific Data Broadcast
GSM Global System for Mobiles
GTA Ground-to-Air
HDOP Horizontal Dilution of Precision
HAE Height above Ellipsoid
HF High Frequency
HGA High Gain Antenna
HLD High Power Amplifier/Low Noise Amplifier/Diplexer
HMI Human-Machine Interface
HPA High Power Amplifier
HPR High Power Relay
HSDU High Speed Data Unit
HSN Harmonics, Spurious, and Noise
Hz Hertz
I-2 Inmarsat-2 Satellite
I-3 Inmarsat 3 Satellite
I-4 Inmarsat 4 Satellite
I/Q In-Phase and Quadrature (Modulation)
IAI-2 Inmarsat Air Interface-2
ICAO International Civil Aviation Organization
ID Identification
IF Intermediate Frequency
IFE In-Flight Entertainment
IGA Intermediate Gain Antenna
IMEI International Mobile Equipment Identifier
IMEISV International Mobile Equipment Identifier Software Version
IMSI International Mobile Subscriber Identity
IMT-2000 International Mobile Telecommunications 2000
INS Inertial Navigation System
IP Internet Protocol
IRS Inertial Reference System
ISDN Integrated Services Digital Network
ARINC CHARACTERISTIC 781 – Page 286
APPENDIX A
ACRONYMS

ISO International Organization for Standardization

ITU International Telecommunication Union
kg/hr kilogram per hour
kHz kilohertz
kSym/s kilo symbols per second
LAN Local Area Network
L-band Portion of the microwave band of the electromagnetic spectrum ranging
approximately from 0.39 to 1.55 GHz
LED Light Emitting Diode
LES Land Earth Station
LESO LES Operator
LGA Low Gain Antenna
LNA Low Noise Amplifier
LPA Low Power Amplifier
LRU Line Replaceable Unit
LSB Least Significant Bit
mA milliampere
MAC Media Access Control (address)
MASPS Minimum Aviation System Performance Standards
MBS Multi-Bearer System
MCDU Multi-Purpose Control and Display Unit
MCU Modular Concept Unit
MEO Medium Earth Orbit
MFR Manufacturer
MHz Megahertz
MIL Military
M-ISDN Modular Integrated Services Digital Network
MOPS Minimum Operational Performance Standards
MP Middle Plug
MPDS Mobile Packet Data Service
MRO Maintenance and Repair Organization
ms millisecond
MSB Most Significant Bit
MTSAT Multifunction Transport Satellite
NCD No Computed Data
NCS Network Coordination Station
NIST National Institute of Standards and Technology
NOC Network Operations Center
NS Non-Safety
NVM Non-Volatile Memory
 ARINC CHARACTERISTIC 781 – Page 287
APPENDIX A
ACRONYMS

OEM Original Equipment Manufacturer

ORT Owner Requirements Table
PADT PPPoE Active Discovery Termination
PAPR Peak-to-Average Power Ratio
PBX Private Branch Exchange
PC Public Call
PCM Pulse Code Modulation
PCS Payload Control System
PDP Packet Data Protocol
PEP Peak Envelope Power
PER Packet Error Rate
PIES Passenger Information and Entertainment Services
PIESD Passenger Information and Entertainment Services Domain
PIM Passive Intermodulation
PIMBIT Passive Intermodulation Built-In Test
PLMN Public Land Mobile Network
POTS Plain Old Telephone Service
PPP Point-to-Point Protocol
PPPoE Point-to-Point Protocol Over Ethernet
PS Packet Switched
PSDN Packet Switched Data Network
Psid P-Channel used for satellite identification
PSTN Public Switched Telephone Network
PTT Push-to-Talk
QAM Quadrature Amplitude Modulation
QoS Quality of Service
QPSK Quadrature Phase Shift Keying
RAM Random Access Memory
RAN Radio Access Network
REN Ringer Equivalent Number
RDI Restricted Data Interface
RF Radio Frequency
RFU Radio Frequency Unit
RMP Radio Management Panel
RMS Root Mean Square
ROM Read Only Memory
RTP Real-time Transport Protocol
Rx Receive
SAL System Address Label
SARPs Standards and Recommended Practices
ARINC CHARACTERISTIC 781 – Page 288
APPENDIX A
ACRONYMS

SAS Satellite Access Station

satcom Satellite Communications
SBB SwiftBroadband
SBS Satellite Base Station
SCC Satellite Control Center
SCDU Satellite Control/Display Unit
SCM SDU Configuration Module
SDI Source/Destination Identifier
SDM Inmarsat System Definition Manual
SDU Satellite Data Unit
SELCAL Selective Calling
SGSN Supporting GPRS Support Node
SIP Session Initiation Protocol
SL Security Level
SLIC Subscriber Line Interface Circuit
SMART Standard Modular Avionics Repair and Test System
SMS Short Message Service
SNMP Simple Network Management Protocol
SSM Sign/Status Matrix
STX Start of Text
SU Signal Unit
SYN Synchronization
TBD To Be Determined
TCAS Traffic Collision Avoidance System
TCP/IP Transmission Control Protocol/Internet Protocol
TDM Time Division Multiplexed
TDMA Time Division Multiple Access
TE Terminal Equipment
TFT Traffic Flow Template
TFTS Terrestrial Flight Telecommunications System
TNC Threaded Neill-Concelman (RF connector)
TP Top Plug
TT&C Telemetry Tracking & Control
Tx Transmit
UDI Unrestricted Data Interface
UMS User Modifiable Software
UMTS Universal Mobile Telephone System
USIM UMTS Subscriber Identity Module
UT User Terminal
UTC Universal Time Coordinated
 ARINC CHARACTERISTIC 781 – Page 289
APPENDIX A
ACRONYMS

V Volts
VA Volt-Ampere
Vac Volts, alternating current
Vdc Volts, direct current
VHF Very High Frequency
VoIP Voice over IP
VPN Virtual Private Network
VSWR Voltage Standing Wave Ratio
W Watts
WAN Wide Area Network
WCDMA Wide-band Code Division Multiple Access
WG Working Group
WGS-84 World Geodetic System 1984
WRC-03 World Radio Communication Conference 2003
WOW Weight On Wheels
WSC Williamsburg SDU Controller
WSCI Williamsburg SDU Controller Interface
XL Band Extended L-band
ARINC CHARACTERISTIC 781 – Page 290

APPENDIX B
SECURITY ANALYSIS OF THE SATCOM ETHERNET INTERFACE

B-1 Introduction and Background

The increasing use of and importance in new airplane designs of airborne
networks based on standard Ethernet and IP protocols results in a significant
new arena of information systems security risks that must be understood and
adequately mitigated or controlled.
Readers of this appendix looking to jump ahead to specific design guidance are
directed to the sections “Step 2: Select and Implement Security Controls” and
“Specific ARINC 781 Implementation Architectures.”
COMMENTARY
This security analysis was produced in 2008 based on ARINC
Report 811 methodology. As of 2012, the recommended
methodology is EUROCAE ED-202/RTCA DO-326. This
analysis has been retained here, as it contains much useful
material, but users are cautioned that ARINC Report 811 is
not the preferred security process methodology where there
are potential impacts to safety.
B-2 Design Principles for Secure Airborne Networks
Certain guiding principles for design of secure and cost-effective airborne
networks should be taken into account when developing industry standards
specifications:
• Specifications must allow for a range of different network architectures
with common interfaces that meet the needs of the respective
manufacturers and their suppliers. These different architectures will
reflect varying levels of integration and sharing of components and
services across security domains, and will provide varying levels of
protection inherent in the network design.
• In an integrated airplane network architecture using shared resources,
security considerations take on greater significance than in one that
assumes physical isolation of domains
• Cost savings may be realized when onboard resources are shared, while
still meeting assurance requirements
• Security must be designed into the network in multiple layers, reflecting a
defense-in-depth approach. This means that security controls are
designed into both the network design as a whole, and also into individual
components.
• Airborne systems and networks whose failure do not impact safety of
flight (“minor” or less) may nonetheless impact airline business operations
if functioning in a degraded or non-working state. Such systems and
networks may process airline or passenger data requiring security
controls that maintain confidentiality, integrity, and/or availability.
This analysis is conducted in as objective a manner as possible using an ARINC
standard framework, and does not presuppose or limit itself to any specific
airborne network architectures in order to remain applicable to a broad range of
current and future implementations of the satcom Ethernet interface. However,
after the analysis sections, some sample architectures are presented to illustrate
the application of recommended security controls. The analysis methodology is
presented in the next section.
 ARINC CHARACTERISTIC 781 – Page 291

APPENDIX B
SECURITY ANALYSIS OF THE SATCOM ETHERNET INTERFACE

B-3 Analysis Methodology

ARINC Report 811: Commercial Aircraft Information Security Concepts of
Operation and Process Framework, defines a three step risk-based information
security process framework which can be employed to develop secure aircraft
information systems. It is intended to provide a high-level information security
process that organizations can tailor to suit business/operational needs, integrate
with existing operations, and apply in a consistent and repeatable manner across
heterogeneous aircraft information systems, which may be acquired from multiple
vendors. The intended audience includes all organizations (e.g., airlines, aircraft
and avionics suppliers, service providers, etc.) that specify, acquire, develop,
implement, test, operate, and maintain secure aircraft information systems.
Note: The reader is encouraged to become familiar with the
content of the ARINC Report 811.
This framework was first used when developing specifications for ACARS
message security (AMS).
The high-level risk-based information security process consists of three steps
and a review process (some text excerpted from ARINC Report 811).
Step 1:
Identify information security
needs and objectives

Step 2:
Select and implement
Security
securit y controls Review

Step 3:
Operate and manage
security controls

Figure 1
This analysis will also follow this framework, but will only focus on the activities of
Step 1, and to a limited extent, Step 2.
Step 1: “Identify information security needs and objectives” – consists of
performing the analysis necessary to enable determination of which security
controls are most appropriate to the system under consideration.
This step involves activities like:
• Asset identification – what information will the system process?
• Security categorization – how sensitive is the information?
• Risk assessment – what threats exist to the system? How likely are they
and how severe could their impact be?
• Policy identification – what policies, regulations, and laws must be taken
into account during system design and operation?
• Physical environment and assumptions – what assumptions can be made
that will affect the design of the security solution?
ARINC CHARACTERISTIC 781 – Page 292

APPENDIX B
SECURITY ANALYSIS OF THE SATCOM ETHERNET INTERFACE

• Security objectives – what fundamental objectives – including business

objectives as well as security objectives – drive the design of the security
solution?
Step 2: “Select and implement security controls” – consists of selecting
appropriate security controls, also referred to as safeguards or countermeasures,
and implementing them based on considerations like cost and security using the
security objectives and the results of the risk-based analysis performed in step 1.
Security controls include a set of management, operational, and technical
controls, where:
• Management controls focus on processes that are performed by an airline
to manage aircraft information system security to an acceptable level of
risk. Examples include configuration management and contingency and
recovery planning.
• Operational controls focus on processes that are performed by people.
Examples include use of identification badges and training airline
personnel in the proper operation of security systems.
• Technical controls include those mechanisms that are implemented
primarily in hardware, software, and firmware. Examples include
encryption (a cryptographic mechanism) and firewalls (a non-
cryptographic mechanism).
When possible, priority should be given to automated technical controls over
operational controls, allowing better security and reducing airline overhead to
administer operational security.
The risk-based security process facilitates selection and implementation of the
minimum set of security controls that support an airline organization in:
• Performing its mission (e.g., safe carriage of passengers/cargo, meeting
financial objectives of stakeholders).
• Maintaining its business operating functions (e.g., dispatch,
maintenance).
• Meeting its legal responsibilities (e.g., regulatory).
• Protecting individuals (e.g., crewmembers, passengers).
• Protecting its aircraft information systems consistent with airline security
policy.
Step 3: “Operate and manage security controls” – concerns the ongoing
work involved in maintaining the selected security controls once the system is in
operation. The operation and management of security controls might be the most
important step in the process to the airlines. This is especially true when steps
one and two are provided by other companies.
Complementary to these three steps is the “security review” process. Security
review consists of revisiting steps 1-3 to determine if the security needs and
objectives have changed, if the security controls remain appropriate, and if the
system is being operated securely and cost-effectively.
Refer to ARINC Report 811 for further decomposition and explanation of these
steps.
B-4 Security Analysis of Satcom Interfaces
 ARINC CHARACTERISTIC 781 – Page 293

APPENDIX B
SECURITY ANALYSIS OF THE SATCOM ETHERNET INTERFACE

This analysis is based on the characteristics of the information assets that will be
transmitted via the Inmarsat services. A security failure of the SDU could result
in exposure of confidential assets to unauthorized parties, compromise of the
integrity of those assets, impersonation of privileged communications, and/or the
inability to transmit those information assets to and from the ground. Security
controls or functions of the SDU and its Ethernet interfaces should therefore
enable resistance to such failures. Considering the mapping of user interfaces to
compatible Inmarsat services (ARINC 781, Table 3.3), the following analysis is
extended to all interfaces (SBB, Swift64, and Classic Aero). Indeed, all services
on SBB Ethernet are not available today and satcom should prevent security
failure when used with other services such as Classic Aero regardless of the
architecture of the aircraft.

The scope of the analysis is focused on the SDU and its neighbor systems, but
takes into consideration some of the potential threat vectors such as attacks
launched against the airplane from the ground.

Step 1: “Identify information security needs and objectives”

Step 1.1: “Asset identification and security categorization”
Although Inmarsat does not currently offer or support use of
SwiftBroadband for safety services, the service is targeted for use by
airlines for business operational communications that could have
significant impact to airline operations if unavailable. Other uses of the
service may be for passenger voice or data connectivity which, while not
critical to airline operations, would tarnish the airline’s reputation if
passenger communications are compromised or become unavailable.
Table 1 identifies at a high level the information assets carried by the SBB
service including future safety of flight services. A more detailed
breakdown into information sub-types is normally defined as part of the
analysis, but is probably not needed for purposes of this document.
ARINC Report 811 has a good example list of aircraft information types.
ARINC CHARACTERISTIC 781 – Page 294

APPENDIX B
SECURITY ANALYSIS OF THE SATCOM ETHERNET INTERFACE

Table 1
Information Type Description Owner Primary Domain
Airline operational Data such as aircraft Airline Airline Information Services
data position, or FOQA data (AIS)
used to maintain health
and dispatchability of the
aircraft
Engine monitoring Data collected by engine Airline Aircraft Control (AC)
data monitoring subsystem (originates in ACD but
and transmitted to engine transmitted by system in AIS
manufacturer and airline domain)
Cabin crew Data for applications such Airline AIS
application data as duty free on board,
cabin logbook. May
include passenger
personal data and credit
card numbers.
Pilot comms AOC-type messages Airline AC or AIS
Passenger comms Voice over IP (VoIP) calls, Passengers Passenger Information and
email, web Entertainment Services
(PIES)
SDU configuration Configuration and session Airline / AIS or PIES (See note)
data essential for service
operation of the SDU provider
(Inmarsat
Distribution
Partner)
Safety services Cockpit voice and data Airline AC

Security categorization provides an initial estimate concerning the importance of

the fundamental security services of confidentiality, integrity, and availability
within the system.
Table 2 shows the security categorization of the data types in Table 1. The
highest category is used when there are multiple sub-types of varying impact.
Note: The actual physical location of the interface may reside in
either – it is dependent on the particular architecture
chosen by the manufacturer. Due to the fact that it is an
interface to lower integrity networks on the ground, it is
often represented as being in the PIES domain.
 ARINC CHARACTERISTIC 781 – Page 295

APPENDIX B
SECURITY ANALYSIS OF THE SATCOM ETHERNET INTERFACE

Table 2

Security Category
Information Type
Confidentiality Integrity Availability
Airline operational data High Medium Medium
Engine monitoring data Medium High High
Cabin crew application data High Medium Medium
Pilot communications High Medium Medium
Passenger communications Low Low Low
SDU control and configuration High High Medium
SDU operational status Low Medium Medium
Safety services Medium High High

Notes:
1. Due to sensitivities to tracking of individual pilot actions, airline
operational data such as FOQA must be kept highly confidential
until it is processed and anonymized on the ground. Also, as
airlines more fully integrate the data feeds coming off of the
aircraft into their regular operations, they will rely on its availability
for operations.
2. The effectiveness of onboard applications (e.g. aircraft health
monitoring and prognostics functions) depends on the reliable
collection and off-aircraft transmission of the associated data.
Loss, corruption, alteration or reception of the data by
unauthorized entities can compromise the integrity of the data and
thus severely impact the effectiveness of the applications and their
value to the airline.
3. Cabin crew application data ratings reflect the sensitivity of
passenger personal and credit card data that might be present in
a “buy onboard” application, and reliance on transmission of cabin
logbook data to the ground to ensure quick turnaround at the
arrival gate.
4. Passenger communications, while possibly important to the
passenger, are rated “Low” to reflect the fact that an attack
against any of the categories would have minimal impact to the
airline, loss of goodwill chief among them.
5. A compromise of the SDU’s own configuration data (e.g. ORT)
would likely impact the other information types. Loss or non-
availability of this data would mean that the SDU could not
operate, and therefore no satcom service could be provided.
Likewise if its integrity were compromised, although this could also
have a financial impact as an attacker could manipulate the
configuration to use a more expensive class or type of service.
Adding the capability of the satcom to support safety services, the
integrity of the configuration needs to be assured.
ARINC CHARACTERISTIC 781 – Page 296

APPENDIX B
SECURITY ANALYSIS OF THE SATCOM ETHERNET INTERFACE

The primary domain mainly depends on the architecture of the Aircraft. The analysis
should be based on the most restrictive use of the satcom devices.

The connection between the different outputs identified in Table 3-3 and the different
domains are identified in the following table (including future support):

Inmarsat Service
Connected
User Interface Swift "Classic"
Swift64 Domain
Broadband Aero
Non - ATC 4-wire Analog +
X X ACD
Cockpit Voice discretes
ATC Cockpit 4-wire Analog +
X X ACD
Voice discretes
2-wire Analog
X X X
POTS/SLIC
Cabin Voice AISD/PIESD
CEPT-E1 X X X
ISDN X X X
ARINC 429
Non - ATC X
Data-2/Data-3 ACD
Cockpit Data
Ethernet/AFDX X X X
ARINC 429
X
ATC Cockpit Data Data-2/Data-3 ACD
Ethernet/AFDX X X
CEPT-E1 X X X
Cabin Data (inc. ISDN X X
Fax, Modem & Ethernet X X AISD/PIESD
Packet Data) 2-wire Analog
X X X
POTS/SLIC
 ARINC CHARACTERISTIC 781 – Page 297

APPENDIX B
SECURITY ANALYSIS OF THE SATCOM ETHERNET INTERFACE

Step 1.2.1: “Assess risk”

The risk assessment step consists of threat identification and
threat analysis. Table 3 identifies the system-specific threats.
This table is focused on security of the SDU, and does not
enumerate threats present in the ground infrastructure, e.g.,
Inmarsat Distribution Partner’s network or airline’s network,
although security of the overall system will rely heavily on controls
in place in the ground environment to restrict access to the
forward link (see assumption A.DP). The threat analysis portion
consists of estimating the likelihood and severity of each threat
identified, and has been combined into the same table for easier
reading. Because this document analyzes a specification rather
than being based on operational experience with deployed ARINC
781 systems, the analysis takes a conservative yet concerned
approach and is instead primarily based on the technical difficulty
of carrying out the threat, and assumes a population of motivated
attackers exists. It is certainly far more expensive to add/retrofit
security controls to deployed systems than to specify them up
front. Likelihood and Severity ratings for the parent threats (in
bold type) represent the highest rating of the child threats.
It should also be stressed that there is little to no inherent security
at layer 2 of the OSI model (the Media Access Control layer,
typically implemented as Ethernet), so security controls to counter
these threats must be implemented at higher layers as well as in
the physical environment. Once an attacker has direct access to
layer 2 of the network (i.e. plugging into the local segment), full
compromise of the system is possible. Also, many network-based
attacks would likely come from the cabin network (PIES domain)
and attempt to reach the cockpit network (AC or AIS domain).
The threats to each SDU interface should be identified. The following diagram
shows a proposed “worst case architecture.” It identifies all the interface services
with their domain of connection. The diagram does not present part segregation
but some main functions of the SDU that are linked together. The
“Administration, Configuration, Control, Dataloading, Monitoring, etc.” is a
representation of all the commands that can be sent to the different parts of the
satcom, for instance ORT, configuration of each channel card, RF power, priority,
etc. The purpose of the links is only to indicate an exchange of data, without any
consideration of the type of link for each kind.
COMMENTARY
The reader should note that some connection with AIS and PIES
may be shared, which has to be monitored closely.
 ARINC CHARACTERISTIC 781 – Page 298

APPENDIX B
SECURITY ANALYSIS OF THE SATCOM ETHERNET INTERFACE

Aircraft

SATCOM
Non ATC Cockpit Voice 4-wire Analog + discretes

ATC Cockpit Voice 4-wire Analog + discretes

ACD
ATC ARINC 429 Data-2/Data-3
Cockpit Data Ethernet / AFDX

ARINC 429 Data-2/Data-3

Non ATC Cockpit Data
Ethernet / AFDX
GROUND

2-wire Analog+POTS/SLIC

AISD
Cabin Voice CEPT-E1
ISDN

CEPT-E1

PIESD
ISDN
Cabin Data
Ethernet
Administration, 2-wire Analog+POTS/SLIC
Configuration, Control,
Dataloading,
Monitoring...

Administration,
Configuration, Control,
Dataloading,
Monitoring...

Figure 2
 ARINC CHARACTERISTIC 781 – Page 299

APPENDIX B
SECURITY ANALYSIS OF THE SATCOM ETHERNET INTERFACE

Table 3

Threat
Threat Description Likelihood Severity
Identifier

An authorized user may gain unauthorized access to

the aircraft system or to information controlled by the
T.ACCESS Likely Medium
aircraft system via user error, system error, or an attack
for malicious or non-malicious purposes

A disgruntled airline employee may eavesdrop on or

interfere with proprietary or sensitive data on the
airplane sent via the SBB service.
T.ACCESS.1 Unlikely Medium
Mitigated by use of application end-to-end encryption
(A.APPLICATION SECURITY)

A malicious or curious passenger may access the

system and interfere with its operation, cause increased
T.ACCESS.2 Likely Medium
cost to the airline due to unauthorized changes to
classes or contexts, or obtain free offboard access.

An individual other than an authorized user may gain

access to the aircraft system or to information controlled
T.ENTRY Highly likely Medium
by the aircraft system via system error or an attack for
malicious purposes

T.ENTRY.1 Control messages to the SDU may be spoofed. Highly likely Medium

Session traffic from trusted hosts may be

T.ENTRY.2 Likely Low
eavesdropped.

T.ENTRY.3 Status messages from the SDU may be spoofed. Highly likely Medium

Satcom integrity may be compromised by attack from

T.ENTRY.4 Highly likely High
the outside of the aircraft or PIESD.

The ACD may be compromised by attack from the

T.ENTRY.5 Highly likely High
PIESD.

The ACD may be compromised by attack using the high

T.ENTRY.6 speed Satcom function (SBB or Swift 64) through the Highly likely High
“Classic” Aero service.

Data exchanged between ground and ACD may be

T.ENTRY.7 Highly likely High
corrupted by an attacker from the PIESD.

Data exchanged between ground and ACD may be

T.ENTRY.8 Highly likely High
corrupted by an attacker from the PIESD .

The aircraft system resources may become exhausted

T.DOS due to system error, non-malicious user actions, or Highly likely High
denial-of-service (DoS) attack.

An attacker may cause exhaustion of all 11 primary

T.DOS.1 contexts by the generation of bogus PDP setup Highly likely High
messages (PADI->PADS).
ARINC CHARACTERISTIC 781 – Page 300

APPENDIX B
SECURITY ANALYSIS OF THE SATCOM ETHERNET INTERFACE

Threat
Threat Description Likelihood Severity
Identifier
An attacker or non-malicious user may generate bogus
T.DOS.2 or spurious traffic that saturates the channel or specific Highly likely High
contexts.

An attacker may inject bogus PADT control messages

T.DOS.3 Likely High
that cause shutdown of a context.

Communication between ACD and Ground may be

T.DOS.4 Highly likely High
denied by an attacker from the PIESD.

An attacker using the high speed satcom function (SBB

T.DOS.5 and Swift 64) may deny use of the "Classic" aero Highly likely High
service.

An attacker from the PIESD may deny communication

T.DOS.6 Highly likely Medium
between the AISD and Ground.

Security failures may occur as the result of problems

T.DEVELOP likely High
introduced during implementation of the aircraft system.

An attacker may intentionally introduce security flaws

T.DEVELOP.1 likely High
during the development of the SDU software.

Software with security flaws may be introduced into the

T.DEVELOP.2 process after development but before implementation likely High
on the aircraft.

The secure state of the aircraft system could be

T.FAILURE Highly likely High
compromised in the event of a system failure.

An attacker could compromise overall security of the

T.FAILURE.1 system by causing a failure in one component of that Highly likely High
system.

In the event of hardware failure, the security of the

T.FAILURE.2 Highly likely High
aircraft may be compromised.

The aircraft system may be delivered or installed in a

T.INSTALL Likely Medium
manner that undermines security.

An attacker may compromise a system that has been

T.INSTALL.1 Likely Medium
incorrectly configured at installation.

The security of the aircraft system may be reduced or

defeated due to errors or omissions in the
T.MAINTAIN Highly likely High
administration and maintenance of the security features
of the aircraft system.

An authorized maintenance tech may introduce an

T.MAINTAIN.1 obsolete software version in place of a newer one, Likely Medium
exposing vulnerabilities that were previously fixed.

Security features may be disabled by a technician

T.MAINTAIN.2 because they are preventing completion of work or Highly likely High
dispatch of the aircraft.

Security failures may occur because of improper

T.OPERATE Likely High
operation of the aircraft system.
 ARINC CHARACTERISTIC 781 – Page 301

APPENDIX B
SECURITY ANALYSIS OF THE SATCOM ETHERNET INTERFACE

Threat
Threat Description Likelihood Severity
Identifier
An authorized user of the system may intentionally force
T.OPERATE.1 Likely High
the operational system into an unsecure state.

An attacker may attempt compromise of the system

T.OPERATE.2 Likely High
during a less secure operating state.

Security-critical parts of the aircraft system may be

T.PHYSICAL subjected to a physical attack that may compromise Unlikely Medium
security.

An attacker with physical access to the equipment may

reconfigure the system to turn off security functions.
T.PHYSICAL.1 Unlikely Medium
Mitigated by existing aircraft physical access controls
(A.AIRCRAFT-ACCESS)

An attacker may install a tapping device to capture

network traffic.
T.PHYSICAL.2 Unlikely Medium
Mitigated by existing aircraft physical access controls
(A.AIRCRAFT-ACCESS)

Security relevant events may not be traceable to the

T.TRACEABLE Highly likely Low
user or process associated with the event.

An attacker may subvert the logging function of the SDU

T.TRACEABLE.1 Highly likely Low
in order to conceal or destroy evidence of his activities.

An attacker may assume another user’s identity while

T.TRACEABLE.2 performing malicious activity in order to conceal the Highly likely Low
source of the activity.

The threats in Table 3 are shown in risk grid format below in Figure 2. Mitigation
efforts and selection of security controls should of course focus first on the
threats in the red areas, then on the ones in the yellow areas.
ARINC CHARACTERISTIC 781 – Page 302

APPENDIX B
SECURITY ANALYSIS OF THE SATCOM ETHERNET INTERFACE

T.TRACEABLE T.ENTRY T.MAINTAIN

T.FAILURE
T.DOS
Highly Likely T.ENTRY
L
i
k T.INSTALL T.OPERATE .
e T.ACCESS T.DEVELOP

l Likely
i
h
o T.PHYSICAL
o
d Unlikely

Low Medium High

Severity

Figure 3

Step 1.2.2: “Identify policies”

This step identifies policies that may have an impact on the
selection of security controls for aircraft systems. Policies are
grouped into five major areas:
1. Airline information security policies
Because airlines will have different information security policies,
security specifications must remain flexible. But since networks
on airplanes using open Internet standards are a new thing, most
airlines’ policies are only written to address their internal networks
on the ground and have not yet been expanded to include
networks operating onboard the aircraft in their fleet.
2. National laws regarding import and export of cryptography
Designers of airplane systems that use cryptography must take
into account the restrictions that some countries have in place on
the import, use, and/or export of cryptography.
3. Lawfully authorized electronic surveillance (LAES, aka lawful
intercept)
Most governments around the world have laws that require
communications service providers to provide information about
communications or access to them for surveillance purposes,
upon presentation of a court order by a law enforcement agency.
These laws generally require that communication systems are
designed and implemented specifically to facilitate such access.
 ARINC CHARACTERISTIC 781 – Page 303

APPENDIX B
SECURITY ANALYSIS OF THE SATCOM ETHERNET INTERFACE

4. National and international laws regarding data privacy

Many countries have laws that govern how personally identifiable
data is to be protected in transit and in storage. This will primarily
impact systems that carry passenger or crewmember information.
5. National and international regulations governing
development and implementation of aircraft systems
These regulations govern how aircraft systems are to be designed
and implemented for use on aircraft. Although references to
security in these regulations are almost entirely focused on
certification of security controls around systems that affect safety
of flight, significant work is proceeding in various industry groups
(e.g., EUROCAE WG72) to develop standards for security
controls and assessment methodologies for non-safety-related yet
operationally critical systems. Research is also being conducted
under the auspices of various civil aviation authorities in this area.
Further discussion of these policy areas may be found in ARINC
Report 811.
Table 4 details some of the relevant policies.
ARINC CHARACTERISTIC 781 – Page 304

APPENDIX B
SECURITY ANALYSIS OF THE SATCOM ETHERNET INTERFACE

Table 4

Policy Identifier Policy Description

P.AIRLINE Airline information security policies

Per requirements of many pilots unions, operational data (e.g.,

P.AIRLINE.1 FOQA) that is identifiable to a specific pilot must be treated as highly
sensitive and protected from disclosure.

Passenger personal data will be protected from access by

P.AIRLINE.2
unauthorized parties.

Passenger credit card information will be encrypted end-to-end to

P.AIRLINE.3 comply with credit card merchant requirements (ref. Payment Card
Industry Data Security Standard (PCI DSS))

National and international laws regarding import and export of

P.EXPORT
cryptography

Use of cryptography in ARINC 781 systems may require system

developers, implementers, or owners to obtain licenses from
countries in which an equipped aircraft may operate. This may
P.EXPORT.1 include both landing and over flight situations. This requirement may
be mitigated if encryption is used only for authentication and not for
data transmission, or if the encryption function is built-in and not
accessible to users.

P.LAES Lawfully authorized electronic surveillance (aka lawful intercept)

Governments may require escrow or production to law enforcement

P.LAES.1
of encryption keys used to encrypt data.

Communications service providers may be required by law to build

facilities for electronic surveillance into their infrastructures to
facilitate easy access by law enforcement agencies.
P.LAES.2
Note: ETSI has published the most technical standards material for
lawful intercept, ref. document 102-232, et al.

P.PRIVACY National and international laws regarding data privacy

Personally identifiable information of passengers and crew members

may be required to be specially protected from disclosure.
P.PRIVACY.1
(see also P.AIRLINE.1 above, as it deals with privacy of pilot-
connected flight data.)

National and international regulations governing development and

P.REGULATION
implementation of aircraft systems

P.REGULATION.1 TBD

Step 1.2.3: “Determine physical environment and assumptions”

The third step in the risk assessment stage looks at the physical
environment and other existing controls in place that mitigate the
risk introduced by the threats listed in Table 3. The assumptions
must be true regardless of the architecture and the airline
operating it.
 ARINC CHARACTERISTIC 781 – Page 305

APPENDIX B
SECURITY ANALYSIS OF THE SATCOM ETHERNET INTERFACE

Table 5

Assumption ID Assumption Description

Existing aircraft access controls are assumed to be sufficient to

A.AIRCRAFT-ACCESS prevent unauthorized persons from gaining physical access to the
SDU.

Inmarsat distribution partners must implement security controls on

A.DP the ground segment to protect unauthorized access to the forward
link to the aircraft, and to limit spurious traffic from the Internet.

Existing mechanisms for digital signing, crating, and transmission of

software parts are assumed to be sufficient to ensure integrity and
A.SUPPLY-CHAIN-
authenticity (protect against malicious insertion of compromised
INTEGRITY
software at some point in the supply chain (e.g., Trojans, back
doors)).

Satcom software is assumed to be provided free of intentional flaws

A.DEVELOP
or malicious code

For flexibility of control, implementations will use an out-of-band

A.OOB-CONTROL
control line between DTE and MT.

Airlines and maintenance personnel are considered to be authorized

A.MAINTAIN
and trusted.

Airline and service provider personnel are assumed to be authorized

A.OPERATE
and trusted.

A.MAINTAIN and A.OPERATE: As airlines and maintenance personnel are

considered to be authorized and trusted, the threats identified T.MAINTAIN and
T.OPERATE.1 are not considered in this analysis. Misuse is considered for some
actions, but those are not supported by the satcom.
Those assumptions on the environment are used to define the threat scenarios to
be considered for the design of a secure satcom. Compared to the threats
identified in the Table 3, the remaining threats are:
• Provide integrity of the satcom from attack from the outside of the aircraft
• Provide integrity of the satcom from attack from the PIESD
• Protect the ACD from attack from AISD/PIESD
• Protect the ACD from attack from the high speed satcom function (SBB
and Swift64) through the “Classic” aero
• Provide integrity and availability of the data exchanged with ACD from
attack from the PIESD
• Ensure integrity of communication between ground and ACD
• Ensure integrity of communication between ground and AISD
• Provide integrity and availability of the data exchanged with AISD from
attack from the PIESD
• No satcom failure shall lead to a security breach
• No lack of security shall result from any given state of the system
ARINC CHARACTERISTIC 781 – Page 306

APPENDIX B
SECURITY ANALYSIS OF THE SATCOM ETHERNET INTERFACE

Step 1.3: “Characterize security objectives”

Information security objectives are high-level goals that guide the
selection of security controls. ARINC Report 811 defines 14
fundamental objectives that are common across most airplane
cabin systems.

Table 6

Objective ID Objective Description

Aircraft systems should use common security controls for purposes

O.COMMONCONTROLS of development cost reduction, simplicity, and centralized
management.

The overall cost of aircraft system security controls should be

O.COST minimized. Cost factors to consider include both development costs
and operation and maintenance costs.

Aircraft systems should employ multiple security controls to mitigate

O.DEFENSE-IN-DEPTH
each significant threat.

Development, operation, and maintenance of security controls for

O.EXISTING-LIFECYCLE aircraft systems should fit within the existing aircraft lifecycle (e.g.,
not force changes in maintenance schedules).

Security solutions for new systems should require as few changes as

O.EXISTING-SYSTEMS
possible to existing systems.

Security controls for aircraft systems should be flexible in order to

O.FLEXIBILITY permit a variety of different policies and procedures for their
operation.

Aircraft systems must provide effective operation to users performing

O.FUNCTION
authorized actions.

Aircraft systems should be designed to allow for regular adoption of

O.FUTURE-RESILIENCY
new security controls and technology.

Security controls for aircraft systems should require minimal

O.MINIMIZE-OVERHEAD
administrative and operational overhead.

O.MISSION- Security controls for aircraft systems should not inhibit airline mission
ACCOMPLISH accomplishment (i.e. delivery of passengers from point A to point B).

Security controls for aircraft systems should be based on open

O.OPEN-STANDARDS
standards.

Security controls for aircraft systems should protect airlines,

O.PUBLICPERCEPTION manufacturers, and suppliers from threats that may affect their
commercial image.

Security controls for aircraft systems should in no way compromise

O.SAFETY
the safety of the aircraft.

Security controls for aircraft systems should mitigate the risks to

O.SECURE aircraft systems to a level that is acceptable based on airline
business needs.

The main objective is to respond to O.SECURE with respect to other objectives as

constraints.
 ARINC CHARACTERISTIC 781 – Page 307

APPENDIX B
SECURITY ANALYSIS OF THE SATCOM ETHERNET INTERFACE

Step 2: “Select and implement security controls”

After the risk analysis has been completed per step 1, one can
then begin to select security controls that mitigate the identified
threats (table 3) while achieving the best balance in satisfying the
stated security objectives (table 6). Selection of security controls
for the satcom system should balance security needs with cost
and supportability limitations. Controls may also include network
design elements that provide isolation and segregation between
domains onboard the aircraft.
ARINC Report 811 may be consulted for descriptions of the
seventeen high-level control areas that guide the selection of
system-specific controls. They are comprised of technical,
operational, and management controls, which work together to
achieve security objectives.
The threat consequences are corruption, denial of service, loss of
data or disclosure. The controls implemented have to mitigate the
risk of those consequences considering the different threats
identified in Table 3 above and the assumptions in Table 5.
Table 7 shows the recommended security controls for ARINC 781
systems that address the major threats identified in Table 3 above.
ARINC CHARACTERISTIC 781 – Page 308

APPENDIX B
SECURITY ANALYSIS OF THE SATCOM ETHERNET INTERFACE

Table 7

Control Control Description and Suggested Implementation

Encrypt all control connections for transport of

Protect the internal control, monitoring, administration of the
AT commands from DTE to MT. Satcom
satcom. In particular, in case of channel card reconfiguration, it
should provide integrity and authorization
should be demonstrated that it cannot be disrupted by attack
control of “Administration, Configuration,
from ground or PIESD. Use of secure shell (SSH) to carry
Control, Dataloading, Monitoring...”. commands to the MT instead of telnet mitigates risk from the
following threats:
T.ENTRY.1
T.ENTRY.3
T.ENTRY.4
T.DOS.3

The system should recover gracefully when Prevents operation of the system in an unsecure state.
failure of a security function is detected, and Attackers often attempt to disable security systems first so that
shut down if repeated abnormalities are seen. activities can continue undetected. Mitigates risk defined by:
T.FAILURE.1

The system should be safe secure.

In case of component failure, it should not create a security
breach.
T.FAILURE.2

The system should provide aircraft security

During all operational mode of the satcom (shutdown, transitory
during all states of the system (considering the
shutdown, configuration phase, initialization phase, operational
different threats identified).
mode, abnormal mode, downloading), the satcom should not
enable a security breach of the aircraft.
T.OPERATE.2

The system should generate a maintenance Enables reactive detection of possible attacks against the
log entry when failure of a security function is system, i.e. does not directly prevent an attack but enables a
detected. response that may limit its severity or duration.

The satcom should support strict partitioning Use of separate physical communications paths (Ethernet
of traffic from AIS and PIES domains by interfaces, modems, and channel cards) minimizes the risk that
physical or equivalent logical separation an attacker can either subvert a shared component to gain
internal to the satcom, up to the RF module. access across the domain boundary, or flood a shared
component to reduce resources available to the other domain
(e.g., AIS, as attacker is most likely coming from PIES).
Mitigates risk defined by:

T.ACCESS.1
T.ENTRY.8
T.DOS
T.FAILURE.

The satcom should support strict partitioning

Use of separate physical communications paths (Ethernet
of traffic from ACD and AISD/PIESD by
interfaces, modems, and channel cards) minimizes the risk that
physical or equivalent logical separation
an attacker can either subvert a shared component to gain
internal to the satcom, up to the RF module.
access across the domain boundary, or flood a shared
component to reduce resources available to the other domain
(e.g., as attacker is most likely coming from PIESD).
Mitigates risk defined by:
T.ACCESS.1
T.ENTRY.7
T.DOS
T.FAILURE
 ARINC CHARACTERISTIC 781 – Page 309

APPENDIX B
SECURITY ANALYSIS OF THE SATCOM ETHERNET INTERFACE

Control Control Description and Suggested Implementation

The satcom should support strict partitioning
Use of separate physical communications paths to prevent
of traffic between “Classic” Aero and SBB/S64
disturbance of ACD communication. (This segregation permits
services
the previous control only when ACD use “Classic” Aero services,
but in the future ACD may use also include SBB service).
T.ENTRY.6
T.DOS

Satcom should support authenticated and Satcom should allow an authenticated and encrypted
encrypted communication between ground communication to go through the satcom between the ground
and AISD and the AISD (As suggested in the control deleted above, the
satcom may not be an end point of such a communication). It
protects communications from PIESD.

Satcom should support authenticated and Satcom should allow an authenticated and encrypted
encrypted communication between ground communication to go through the satcom between the ground
and ACD and the ACD (As suggested in the control deleted above, the
satcom may not be an end point of such a communication).
T.ENTRY.5

Satcom should support authenticated and Satcom should allow an authenticated and encrypted
encrypted communication between ground communication to go through the satcom between the ground
and PIESD and the PIESD

The justification of strict partitioning between ACD, AISD, and PIESD may not be
easy, but it has to be achieved in order to reduce the vulnerabilities of attack from
the PIESD.
Instead of having “SBB user sessions are authenticated and encrypted”
considering the different architectures, it is more useful for the satcom to have
authenticated and encrypted communications to go through satcom ACD or
AISD. Moreover, satcom may not be the only standard IP communication means
(as shown in Figure 6), and such authenticated and encrypted communication
should be common for all those means. This is the reason for authenticated and
encrypted communication to go through the satcom.
Satcom may also have to allow authenticated and encrypted communication
between ground and PIESD to go through the satcom in case of secure
communication for passenger is required by airlines/passenger.
According to Table 3-3 of Section 3, the cockpit data may be able to use SBB
services instead of “Classic” Aero, provided that SBB will not present more
vulnerabilities. To prevent this risk, a strict partitioning is required between
“Classic” Aero and SBB/S64, so that “Classic” Aero can still be used as it is
today.
The following drawings are illustrations of the different threats to illustrate the
need of these security measures.
 ARINC CHARACTERISTIC 781 – Page 310

APPENDIX B
SECURITY ANALYSIS OF THE SATCOM ETHERNET INTERFACE

Aircraft

SATCOM
NonNon
ATCATC
Cockpit Voice
Cockpit 4-4-wire
Voice Analog+
wire Analogdiscretes
+ discretes

ATC ATC
Cockpit VoiceVoice 4- wire Analog+ discretes
Cockpit

ACD
ATCATC ARINC
ARINC 429
429 Data
Data -2-2/ Data-3
/ Data
Cockpit
Cockpit DataData Ethernet/ AFDX
Ethernet

ARINC
ARINC 429429 Data
Data -2/ Data
- 2/Data -3
-3
Non Non
ATCATC Cockpit
Cockpit DataData
Ethernet/ AFDX
Ethernet
GROUND

2- wireAnalog
2-wire Analog+ POTS/ SLIC

AISD
Cabin Voice CEPT-E1

A IS
ISDN

CEPT-E1

P IESD
PIESD
ISDN
Cabin Data
Ethernet
Administration, 2- wire Analog
+ POTS/ SLIC
Configuration, Control,
Dataloading,
Monitoring...

Administration,
Configuration, Control,
From the outside of the aircraft
Dataloading,
Monitoring...
From the PIES

Figure 4 - Integrity
 ARINC CHARACTERISTIC 781 – Page 311

APPENDIX B
SECURITY ANALYSIS OF THE SATCOM ETHERNET INTERFACE

Aircraft

SATCOM
Non ATC Cockpit Voice 4- wire Analog + discretes

ATC Cockpit Voice 4- wire Analog + discretes

ACD
ATC ARINC
ARINC429
429Data -2/ Data-3
Data-2/
Cockpit Data Ethernet / AFDX

ARINC
ARINC429
429Data - 2/ Data-3
Data-2/
Non ATC Cockpit Data
Ethernet / AFDX
GROUND

2-wire
2- wireAnalog
Analog+ POTS/SLIC

AISD
Cabin Voice CEPT-E1
ISDN

CEPT-E1

PIESD
P SD
ISDN
Cabin Data
Ethernet
Administration, 2-wire
2- wireAnalog
Analog+ POTS/SLIC
Configuration, Control,
Dataloading,
Monitoring...

Administration, From the PIES

Configuration, Control,
Dataloading,
Monitoring...
Via SBB

Figure 5 – Protection of the Aircraft Control Domain (ACD)

ARINC CHARACTERISTIC 781 – Page 312

APPENDIX B
SECURITY ANALYSIS OF THE SATCOM ETHERNET INTERFACE

Aircraft

SATCOM
Non ATC Cockpit Voice 4- wire Analog + discretes

ATC Cockpit Voice 4- wire Analog + discretes

ACD
ATC ARINC 429 Data-2/ Data-3
Cockpit Data Ethernet / AFDX

ARINC 429 Data-2/ Data-3

Non ATC Cockpit Data
Ethernet / AFDX
GROUND

2- wire Analog+ POTS/ SLIC

AISD
Cabin Voice CEPT-E1
ISDN

CEPT-E1

PIESD
ISDN
Cabin Data
Ethernet
Administration, 2- wire Analog+ POTS/ SLIC
Configuration, Control,
Dataloading,
Monitoring...

Administration,
From the PIES
Configuration, Control,
Dataloading,
Monitoring...

Figure 6 – Protection of the AISD

The following section, “Specific ARINC 781 Implementation Architectures”,

illustrates some possible network designs and discusses the security profile and
related considerations of each.
B-5 Specific ARINC 781 Implementation Architectures
Three possible network implementation designs were discussed in the Security
sub-group meeting on January 29, 2007. The potential designs offer different
levels of logical and physical separation of network traffic of varying protection
requirements. Note also that the interface recommendations allow for setups as
simple as a single laptop connected to the SDU (per Section 3.2.4.1 in the main
document), so not all implementations will be of this higher complexity. Because
the selected network design contributes significantly to the inherent security of an
airborne system, careful consideration must be given to the pros and cons of
each when making implementation decisions. Meeting the objective of defense-
in-depth (see Step 1.3 above) helps ensure that network designs ranging in
complexity from simple (single Terminal Equipment connected directly to SDU) to
complex (multi-domain network) have adequate security implemented in each of
the components actually in use. For example, this means that a simple setup
with a single TE has an SDU that is reasonably protected from malicious
software that may be running on the TE (laptop) without the user’s knowledge.
Figure 7 below shows the major components of IFE, EFB, and Picocell all
connecting to a network file server (NFS) or switch/router module, with a single
connection to the satcom interface. These three components are of different
 ARINC CHARACTERISTIC 781 – Page 313

APPENDIX B
SECURITY ANALYSIS OF THE SATCOM ETHERNET INTERFACE

assurance levels and reside in different domains of the aircraft network, yet share
a common link to the satcom SDU. The NFS/switch/router would have to be able
to differentiate traffic by source and destination, to protect the SDU from attack
by unauthorized persons in the IFE (cabin) domain. Establishing separate
VLANs by source of traffic would provide some security against basic threats, but
should not be regarded as a complete solution as many switch implementations
do not adequately resist attacks against them, and therefore may allow an
attacker to inject traffic that jumps VLANs or cause the switch to fail into shared
hub mode. Without additional security controls in the SDU, the
NFS/switch/router is solely responsible for network defense of the SDU.
This design represents the likely most common implementation, and is made
more secure by use of separate communication paths inside the satcom SDU
with two Ethernet interfaces to receive connections from the switch from the AIS
and PIES domains.

Pico Cell

NFS / PPPoE
EFB Switch / SATCOM
Router

IFE

Figure 7

Figure 8 shows a design that establishes separate physical communication paths

for cockpit applications like EFB, and for cabin-related applications. Note again
that “Cockpit” as used here corresponds to the AIS domain, and “Cabin” refers to
the PIES domain (ref. ARINC Specification 664). The SDU should therefore offer
separate Ethernet interfaces that connect to separate modems and channel
cards. However, the cost of deploying a second NFS/switch/router may make
this design an unlikely proposition.
ARINC CHARACTERISTIC 781 – Page 314

APPENDIX B
SECURITY ANALYSIS OF THE SATCOM ETHERNET INTERFACE

NFS
EFB
Cockpit

PPPoE SATCOM
Pico Cell

NFS
IFE
Cabin

Figure 8
Figure 9 is similar in separation to the Figure 8 design, but uses two separate
SDUs. This design would go even more strongly against cost and weight
reduction objectives, while not achieving substantially lower risk than the design
above. Despite this, some airlines are considering this design, believing it to
offer redundancy that will enhance dispatchability of the aircraft.

NFS PPPoE
EFB SATCOM
Cockpit

Pico Cell

NFS PPPoE
IFE Cabin SATCOM

Figure 9
Absent additional security controls on the SDU Ethernet interface, the chief
security concern with the preceding designs is a complete reliance on the
security of the NFS / switch unit. This goes against the security objective of
defense-in-depth (O.DEFENSE-IN-DEPTH).
Another area of potential interest regards use of a standard interface for all
offboard links. Figure 10 below shows an example scenario for commercial
 ARINC CHARACTERISTIC 781 – Page 315

APPENDIX B
SECURITY ANALYSIS OF THE SATCOM ETHERNET INTERFACE

aircraft where multiple offboard links are present and routing intelligence is
implemented to select a specific link depending on application, flight phase, and
location requirements. All interfaces are via Internet standard layer 3 protocols
(IP, ICMP).
This includes the communications manager function that is instantiated
separately from the NFS/switch/router. It is responsible for securely managing
and controlling all offboard links.

Figure 10
B-6 Summary
This security analysis has enumerated the threats that may be introduced when
interfacing an ARINC 781 satcom SDU to an aircraft’s onboard data network via
an Ethernet interface, and lays out some recommended security controls to
mitigate those threats. Adherence to defense-in-depth and traffic segregation
principles means that a secure network design cannot rely on single points of
control; rather each component in the network must contribute to overall security.
For the satcom, this means that the Ethernet interface(s) must be segregated
from the “Classic” Aero channel and must support authenticated and encrypted
connections when needed for the different domains. It must ensure that
malicious cabin network activities or ground activities cannot interfere with these
higher sensitivity domains. Most importantly, the communication paths inside the
satcom must be fully segregated through to the channel cards to ensure
adequate separation of domain traffic.
ARINC CHARACTERISTIC 781 – Page 316

APPENDIX B
SECURITY ANALYSIS OF THE SATCOM ETHERNET INTERFACE

B-7 Explanation of terminology used for security categorization

Security categorization provides an initial estimate concerning the importance of
the fundamental security services of confidentiality, integrity, and availability
within the system.
Here confidentiality, integrity, and availability are defined as follows:
• Confidentiality – protection against unauthorized disclosure of
information.
• Integrity – protection against unauthorized modification or destruction of
information.
• Availability – protection against disruption of access to, or use of
information.
Note that integrity and availability have established meanings in the aeronautical
community, and their meaning in a security context is subtly different. Specifically
“security integrity” and “security availability” focus on the prevention of deliberate
attacks, whereas the aeronautical community has traditionally focused on the
prevention of accidental errors.
Security categorization looks at the potential impact of loss of each of the
services for each identified information type within the system, and ranks the
impact as either “none”, “low”, “medium”, or “high”.
Here "none" means that loss of the service would have no practical adverse
effect on operations. Examples of impacts that would be categorized as "none"
include:
• Aircraft operation: No degradation in mission capability.
• Assets: No maintenance action, scheduled or unscheduled, required for
airline assets.
• Financial: Negligible financial loss.
• Human: No discernible negative effect on passengers.
• Public perception: No negative effect on attitude of passengers in airline
services.
Here “low” means that loss of the service would have only a limited adverse
effect on operations. Examples of impacts that would be categorized as “low”
impact include:
• Aircraft operation: Slight degradation in mission capability to an extent
and duration that an airline is still able to perform its primary functions, but
with somewhat reduced effectiveness – for example increased crew
workload.
• Assets: Minor damage to airline assets.
• Financial: Minor financial loss.
• Human: Discomfort to passengers.
• Public perception: Distrust of service by airline customers
“Medium” means that loss of the service could have a serious adverse effect on
operations. Examples of impacts that would be categorized as “medium” impact
include:
 ARINC CHARACTERISTIC 781 – Page 317

APPENDIX B
SECURITY ANALYSIS OF THE SATCOM ETHERNET INTERFACE

• Aircraft operation: Degradation in mission capability to an extent and

duration that an airline is still able to perform its primary functions, but
with noticeably reduced effectiveness – for example heavy stress on crew
or flight delays.
• Assets: Significant damage to airline assets.
• Financial: Significant financial loss.
• Human: Limited physical harm to individuals.
• Public perception: Serious distrust of some passengers in air traffic,
disclosure of confidential airline operational data.
“High” means that loss of the service could have a severe or catastrophic effect
on operations. Examples of impacts that would be categorized as “high” impact
include:
• Aircraft operation: Serious degradation in or loss of mission capability so
that an airline is not able to perform one or more of its primary functions
for a period of time – for example flight interrupt or fleet re-route.
• Assets: Major damage to airline assets.
• Financial: Major financial loss.
• Human: Serious or catastrophic physical harm to individuals.
• Public perception: Total loss of confidence in air traffic by passengers,
disclosure of security information.
Note that in the above definitions, aircraft operation and human impacts are
closely related to the traditional focus of safety analysis, whereas asset, financial,
and public perception impacts are primarily airline business issues.
 AERONAUTICAL RADIO, INC.
2551 Riva Road
Annapolis, Maryland 24101-7435

SUPPLEMENT 1
TO
ARINC CHARACTERISTIC 781
MARK 3 AVIATION SATELLITE COMMUNICATION SYSTEM

Published: November 22, 2006

Prepared by the AEEC

Adopted by the Airlines Electronic Engineering Executive Committee: October 11, 2006
 SUPPLEMENT 1 TO ARINC CHARACTERISTIC 781 – Page a

A. PURPOSE OF THIS DOCUMENT

This supplement primarily provides updates as follows:
• Added clarifications for interchangeability and connector contact
arrangements.
• Added information concerning the external flange-mounted High Power
Amplifier (HPA).
• For the Type D DLNA, changed the transmit port to antenna port and transmit
port to receive port rejection.
• Added Section 3 SATCOM functions.
• Added Attachment 3 Cockpit Voice - Sat Phone State Machine for Normal
Operation.
• Added Attachment 4-A, ARINC 781 SDU Functions Matrix.
• Added Attachment 4-B, ARINC 781 SDU Interfaces Matrix.
• Added Attachment 5 Ethernet Interface.
B. ORGANIZATION OF THIS SUPPLEMENT
In the past, changes introduced by a supplement to an ARINC Standard were
identified by vertical change bars with an annotation indicating the change number.
Electronic publication of ARINC Standards has made this mechanism impractical.
In this document blue bold text is used to indicate those areas of text changed by
the current supplement only.
C. CHANGES TO ARINC CHARACTERISTIC 781 INTRODUCED BY THIS
SUPPLEMENT
This section presents a complete listing of the changes to the document introduced
by this Supplement. Each change is identified by the section number and the title as
it will appear in the complete document. Where necessary, a brief description of the
change is included.
1.1 Purpose of this Characteristic
The commentary has been deleted.
1.2 Relationship of This Document to Other ARINC Characteristics and Industry
Documents
List of ARINC characteristics updated.
1.4 Function of Equipment
Added the transmit frequency range is likely to be limited by the DLNA transmit filter.
1.7.2 Receiver Equipment Performance
Clarification of G/T achievement conditions.
1.8 Interchangeability
Editorial changes and clarifications made concerning functional doublets versus
matched pairs of equipment.
2.2.1.2 Connectors
SDU connectors’ type clarified.
SUPPLEMENT 1 TO ARINC CHARACTERISTIC 781 – Page b

2.2.1.4.1 Frequency Range

Section created to define SDU frequency range. Subsequent section were
renumbered.
2.2.1.5 RF Characteristics for SDU with External HPA
Commentary concerning the SDU RF characteristic added.
2.2.2 External Flange-Mounted High Power Amplifier (HPA)
Two subsections have been created.
2.2.2.1 General
Description of the external flange-mounted HPA updated.
2.2.2.2 RF Characteristic for External Flange-Mounted HPA
External Flange-mounted HPA RF characteristics defined.
2.2.4.3 Type D DLNA
This section and associated sub-sections have been updated regarding Type D
DLNA characteristic change.
2.3 Antenna Specification
Adapter Plate role has been clarified.
2.3.1.2 Ideal Antenna Coverage Volume
Throughput has been replaced by Availability.
2.3.2.6.4 Gain
The gain value has been defined.
2.3.2.6.13.1 Antenna Intermodulation Products in Satcom Receive Band
The antenna Intermodulation Products in satcom Receive Band has been defined.
2.3.2.6.13.2 Antenna Intermodulation Products in GNSS Band
The antenna Intermodulation Products in GNSS Band has been defined.
2.3.3.6.4 Gain
The gain value has been defined.
2.3.3.6.12.1 Antenna Intermodulation Products in Satcom Receive Band
The antenna Intermodulation Products in satcom Receive Band has been defined.
2.3.3.6.12.2 Antenna Intermodulation Products in GNSS Band
The antenna Intermodulation Products in GNSS Band has been defined.
2.3.5.1 Loss Between SDU and External HPA
Coaxial cable loss value between SDU and external HPA has been changed from
“19 to 25 dB” to “8 to 18 db.”
2.3.5.2 Polarization
Deleted commentary.
2.3.6 RF Installation Issues
New section added on RF installation concern.
 SUPPLEMENT 1 TO ARINC CHARACTERISTIC 781 – Page c

2.5.1 Primary Power Input

External HPA power consumption defined.
2.6 System Functions and Signal Characteristics
A reference to Attachment 1-4 has been added.
2.8 Cooling
Added paragraph on cooling for non-ARINC 600 devices.
2.8.1 SDU
Clarifications were added on cooling loss in Emergency situations.
2.8.2 Flange Mounted HPA
External HPA cooling has been defined.
2.10 System ATE and BITE Design
The title of the section has been modified and the subsections were renumbered.
3.0 Satcom Functions
This new section on Satcom functions was added. The subsections include
• Inmarsat Radio; Inmarsat Services, Management of Radio Interfaces.
• User Interfaces; Pilot System Interfaces for Voice Communication, Cockpit
Data, ISDN Interface, Ethernet, CEPT-E1, and POTS.
• Software Data Loader Interfaces.
• Miscellaneous; Dual, Configuration & Identification Data, and Security.
• Priority, Precedence, Preemption and Preference.
• Future Growth; AFDX, Fiber Optic, FANS/ATS over SwiftBroadband, and
Multi Frequency Band.
ATTACHMENT 1-1A - GENERAL CONFIGURATION OVERVIEW - SINGLE SATCOM
INSTALLATION
Revised diagram.
ATTACHMENT 1-1B - GENERAL CONFIGURATION OVERVIEW - DUAL SATCOM
INSTALLATION
Revised diagram.
ATTACHMENT 1-3 - STANDARD INTERWIRING
Interwiring was updated.
ATTACHMENT 1-4 - NOTES APPLICABLE TO STANDARD INTERWIRING
Interwiring notes have been changed mainly to reference ORT parameters and the
use of hybrid GPS/inertial data.
ATTACHMENT 1-4A - SYSTEM CONFIGURATION PINS DEFINITION AND
INTERPRETATION
This attachment has been changed to include the WOW logic select as multiplexed
pin-programming and to rearrange some parameters. A typo has been corrected
(WCSI became WSCI). This attachment has also been changed to mandate the use
of the SDU number pin to differentiate between left and right satcoms.
SUPPLEMENT 1 TO ARINC CHARACTERISTIC 781 – Page d

ATTACHMENT 1-5 - SDU FORM FACTOR

Quadrax inserts have been modified.
ATTACHMENT 1-5A - SDU TOP PLUG CONNECTOR LAYOUT
For ISDN and Ethernet ports, this attachment has been modified to replace A/B by
+/-.
TP06D is no longer a spare config pin.
ATTACHMENT 1-5B - SDU MIDDLE PLUG CONNECTOR LAYOUT
For Ethernet ports or Quadrax connectors, this attachment has been modified to
clearly replace A/B by +/-.
CP has been changed to Cockpit.
MP07C has now become a spare discrete.
The Quadrax connectors pin-out has been corrected.
ATTACHMENT 1-5C - SDU BOTTOM PLUG CONNECTOR LAYOUT
The optic fiber inserts’ attribute have been added.
ATTACHMENT 1-6A - SDU CONFIGURATION MODULE CONNECTOR LAYOUT
Editorial changes to SCM connector and pin-out have been made.
ATTACHMENT 1-7 - FLANGE MOUNT HPA FORM FACTOR
The HPA form factor has been changed.
ATTACHMENT 1-7A - FLANGE MOUNT HPA CONNECTOR LAYOUT
The HPA connector pin-out has been added.
ATTACHMENT 1-8A - DLNA POWER AND CONTROL CONNECTOR LAYOUT
The DLNA pin-out has been clarified.
ATTACHMENT 1-10 - HIGH GAIN AND INTERMEDIATE GAIN TOP MOUNT ANTENNA
FOOTPRINT MAXIMUM DIMENSIONAL OUTLINE
The keep-away zone wording has been clarified.
ATTACHMENT 1-12 - HIGH GAIN AND INTERMEDIATE GAIN ANTENNA CONTROL
CONNECTOR LAYOUT
SCRN has been replaced by Shield.
ATTACHMENT 2 - ARINC 429 LABELS AND WORD FORMATS USED IN THE AVIATION
SATELLITE COMMUNICATION SYSTEM
The list of modifications is the following:
• Figures 1, 2, and 3 on HPA/SDU communication protocol and associated
notes have been deleted.
• Notes # 1, 2, 3, 6, 7, 8, 10, 11, 12, 13, 16, 28, 30, 31, 34, 37, 39 and 42 have
been deleted and marked as unused.
• Notes 47, 48, 49, 50, 51, and 52 have been added and annotated on the
appropriate figures.
Reserved labels for SDU to Antenna manufacturer specific communications have
been defined and some minor editorial changes have been made.
 SUPPLEMENT 1 TO ARINC CHARACTERISTIC 781 – Page e

ATTACHMENT 2A - ANTENNA CONFIGURATION DATA REPORTING

Updated the label fields in the ARINC 429 words. Specified that the ETX and EOT
words must appear in bits 25-31 of the word. Revised Section 4, Configuration Data,
to note that all data is transferred using a subset of the ISO 8859-5 alphabet plus
addition of STX, ETX, EOT, and SYN as specified in ARINC429 part 1 Attachment 5.
ATTACHMENT 3 - COCKPIT VOICE - SAT PHONE STATE MACHINE FOR NORMAL
OPERATION
Added new attachment. The former Attachment 3, Attachment Reference Guide, is
now in Attachment 6.
ATTACHMENT 4-A - ARINC 781 SDU FUNCTIONS MATRIX
A matrix listing SDU functions has been added.
ATTACHMENT 4-B - ARINC 781 SDU INTERFACES MATRIX
A matrix listing SDU interfaces has been added.
ATTACHMENT 5 - ETHERNET INTERFACE
This attachment has been added.
ATTACHMENT 6 - ATTACHMENT REFERENCE GUIDE
This attachment, formerly Attachment 3, was updated.
APPENDIX 1 - ACRONYMS
The acronyms list has been updated.
 AERONAUTICAL RADIO, INC.
2551 Riva Road
Annapolis, Maryland 24101-7435

SUPPLEMENT 2
TO
ARINC CHARACTERISTIC 781
MARK 3 AVIATION SATELLITE COMMUNICATION SYSTEM

Published: November 15, 2007

Prepared by the AEEC

Adopted by the Airlines Electronic Engineering Executive Committee: September 26, 2007
 SUPPLEMENT 2 TO ARINC CHARACTERISTIC 781 – Page a

A. PURPOSE OF THIS DOCUMENT

This supplement primarily provides corrections or updates to:
• Transmit Frequency range of terminal is changed to 1626.5 to 1660.5MHz.
• Definition of G/T for antenna
• DLNA: Addition of historical summary, improved noise figure
• Addition of Type F DLNA
• Addition of intermodulation requirements for the DLNA to antenna cable.
• Definition of the frequency range used by different Inmarsat services
• GNSS Frequency Check Algorithm
• Ethernet Interface
• ORT items and configuration pins including additions to determine if GNSS
frequency management is required in SDU.
• Security requirements
• Attachment 1-3/1-5B – Addition of two I/O pins for SDU (previously spares)
• Attachment 1-4A – Addition of system configuration pins.
• Attachment 1-7A – External HPA connector type
• Attachment 1-8 – Addition of Type F DLNA Form factor
• Attachment 2A – Changes to antenna configuration data reporting.
• Attachment 5 – Ethernet Interface
• Attachment 6 – Addition of security analysis
B. ORGANIZATION OF THIS SUPPLEMENT
In the past, changes introduced by a supplement to an ARINC Standard were
identified by vertical change bars with an annotation indicating the change number.
Electronic publication of ARINC Standards has made this mechanism impractical.
In this document blue bold text is used to indicate those areas of text changed by
the current supplement only.
C. CHANGES TO ARINC CHARACTERISTIC 781 INTRODUCED BY THIS
SUPPLEMENT
This section presents a complete listing of the changes to the document introduced
by this supplement. Each change is identified by the section number and the title as
it will appear in the complete document. Where necessary, a brief description of the
change is included.
1.3 Inmarsat System Description
Deleted last sentence of fourth paragraph.
1.4 Function of Equipment
Deleted second paragraph.
1.6.4 Diplexer/Low Noise Amplifier (DLNA)
Added last sentence to first paragraph. Deleted last paragraph.
1.7.2 Receiver Equipment Performance
Changed method of determining G/T.
SUPPLEMENT 2 TO ARINC CHARACTERISTIC 781 – Page b

2.2.1.4.6 Harmonics, Discrete Spurious Emissions and Noise

Deleted ‘Type D’ before ‘DLNA’.
2.2.2.2 RF Characteristic for External Flange Mounted HPA
Editorial correction.
2.2.4 Diplexer/Low-Noise Amplifier (DLNA)
Added commentary explaining use of Type D DLNA. Added historical development
commentary.
2.2.4.2 Noise Figure/Gain
Changed noise figure for below 25° C and 70° C from 1.8dB to 1.2dB and 2.1dB to
1.6dB respectively.
2.2.4.3 Insertion Loss and rejection
Changed title from Type D DLNA. Deleted commentary.
2.2.4.3.2.1 Type D - Transmit Port to Antenna Port
Added new section title and moved text from Section 2.2.4.3.2 here.
2.2.4.3.2.2 Type F - Transmit Port to Antenna Port
Added new section.
2.2.4.3.3.1 Type D - Transmit Port to Receive Port (DLNA Output)
Added new section title and moved text from Section 2.2.4.3.3 here.
2.2.4.3.3.2 Type F - Transmit Port to Receive Port (DLNA Output)
Added new section.
2.2.4.5 DLNA Intermodulation
Added new section and commentary. Section was called DLNA Connectors – this
has been renumbered as Section 2.2.4.6.
2.2.4.5.1 Type F - DLNA Intermodulation Products in Satcom Receive Band
Added new section.
2.2.4.5.2 Type F - DLNA Intermodulation Products in GNSS Band
Added new section.
2.2.4.6 DLNA Connectors
Previously this was Section 2.2.4.5
 SUPPLEMENT 2 TO ARINC CHARACTERISTIC 781 – Page c

2.2.4.7 DLNA Form Factor

Added note. Previously this was Section 2.2.4.6
2.3.2.5.4 Receiver System Figure of Merit (G/T)
Changed method of determining G/T.
2.3.2.6.13.1 Antenna Intermodulation Products in Satcom Receive Band
Changed 1629.5 to 1626.5 MHz. Changed requirement to be consistent with new
method of determining G/T.
2.3.2.6.13.2 Antenna Intermodulation Products in GNSS Band
Changed 1629.5 to 1626.5 MHz.
2.3.3.5.4 Receiver System Figure of Merit (G/T)
Changed method of determining G/T.
2.3.3.6.12.1 Antenna Intermodulation Products in Satcom Receive Band
Changed 1629.5 to 1626.5 MHz.. Changed requirement to be consistent with new
method of determining G/T.
2.3.3.6.12.2 Antenna Intermodulation Products in GNSS Band
Changed 1629.5 to 1626.5 MHz.
2.3.5.2 DLNA to Antenna Cable
Added new section. Added intermodulation requirements to this cable,
2.3.5.3 Total transmit Loss Between SDU or HPA and Antenna
Added note that total loss can increase at bottom of band due to DLNA insertion
loss, Section renumbered.
2.3.5.4 Loss Between LNA and SDU
Section renumbered.
2.3.6 RF Installation Issues
In 2nd para, changed antenna to a reference.
3.1.1.4 SwiftBroadband
Comment added about supported streaming rates. Figure updated including
deleting 256 kbps streaming.
3.1.2.4.2 Frequency Allocations by Ground Stations
Added the Classic frequency range. Revised the Swift64 category A and B
allocations.
3.1.2.4.3 GNSS Frequency Management in the AES
Updated to explain use of ORT and configuration pins to control function. Added
methodology to set the ORT and configuration pins.
3.1.2.4.4 Recommended Frequency Check Algorithm in SDU
Added behavior of SDU if frequency check fails. Added reference to previous para.
3.2.4 Ethernet
SUPPLEMENT 2 TO ARINC CHARACTERISTIC 781 – Page d

Added sentence and commentary.

3.2.4.1 Purpose and Requirements of the Interface
Re-formatted list of services and added text on retrieving status of the SDU and
communications services/links and the interface should have adequate security for
the intended applications.
3.2.4.2 Interface Components
Deleted circuit switched service and added use of PPPoE to set up Swift64 and
SwiftBroadband Circuit Switched UDI data calls.
3.2.4.3 Interface Fundamentals
Revised the interface fundamentals for the “Routed Interface” and PPPoE.
3.2.4.4 Multiple Ethernet Interfaces
Added new sections.
3.4.2.1.3 ORT Contents
Extensive revisions to ORT Section C: Ethernet Ports Configuration. Added to ORT
Section E: Item 5 GNSS frequency check algorithm and item 9 weight on wheels
input configuration.
3.4.3 Security (and subsections)
Major revisions.
ATTACHMENT 1-3 – STANDARD INTERWIRING
Revised various pin assignments – key ones being: SDU MP01G, SDU MP02G,
HPA pins renumbered to reflect change in connector type, renamed Ethernet pins.
ATTACHMENT 1-4 – NOTES APPLICABLE TO STANDARD INTERWIRING
Minor revisions to note 7 and added new notes 36 and 37.
ATTACHMENT 1-4A – SYSTEM CONFIGURATION PINS DEFINITION AND
INTERPRETATION
Redefined TP6E from spare to WOW input presence and GNSS frequency check.
Removed DLNA Type from TP4F and TP4G and set codes 6, 7 and 9 to reserved for
future.
 SUPPLEMENT 2 TO ARINC CHARACTERISTIC 781 – Page e

ATTACHMENT 1-5B – SDU MIDDLE PLUG CONNECTOR LAYOUT

Revised to be consistent with changes to Attachment 1-3 Standard Interwiring.
ATTACHMENT 1-5C – SDU BOTTOM PLUG CONNECTOR LAYOUT
Revised to be consistent with changes to Attachment 1-3 Standard Interwiring.
ATTACHMENT 1-7A – FLANGE MOUNT HPA CONNECTOR LAYOUT
Changed connector type and renumbered pins.
ATTACHMENT 1-8 – DIPLEXER/LOW NOISE AMPLIFIER FORM FACTOR
Added figure for Type F.
ATTACHMENT 1-12 – HIGH GAIN AND INTERMEDIATE GAIN ANTENNA CONTROL
CONNECTOR LAYOUT
Connector is now applicable to IGA as well as HGA.
ATTACHMENT 2A – ANTENNA CONFIGURATION DATA REPORTING
Revisions to all subsections.
ATTACHMENT 2B – BIT-ORIENTED FAULT REPORTING PROTOCOL
Revised Fault Summary Word #9 for satcom Ethernet ports.
ATTACHMENT 5 – ETHERNET INTERFACE
Major revisions were made to this section. All are not noted in this description of
changes. Sections 5-7 contain all new material, but are not marked with track
changes in order to improve readability. The former material in Section 6 (ORT
Values Required for Ethernet Interface) has been moved and integrated into Section
3.2.4.1.
APPENDIX 2 – SECURITY ANALYSIS OF THE SATCOM ETHERNET INTERFACE
Added new appendix.
 AERONAUTICAL RADIO, INC.
2551 Riva Road
Annapolis, Maryland 24101-7435

SUPPLEMENT 3
TO
ARINC CHARACTERISTIC 781
MARK 3 AVIATION SATELLITE COMMUNICATION SYSTEM

Published: February 9, 2009

Prepared by the AEEC

Adopted by the AEEC Executive Committee: October 22, 2008

 SUPPLEMENT 3 TO ARINC CHARACTERISTIC 781 – Page a

A. PURPOSE OF THIS DOCUMENT

This supplement provides corrections or updates to:
 Flange Mount HPA
 Security Analysis of the Satcom Ethernet Interface
B. ORGANIZATION OF THIS SUPPLEMENT
In the past, changes introduced by a supplement to an ARINC Standard were
identified by vertical change bars with an annotation indicating the change number.
Electronic publication of ARINC Standards has made this mechanism impractical.
In this document blue bold text is used to indicate those areas of text changed by
the current supplement only.
C. CHANGES TO ARINC CHARACTERISTIC 781 INTRODUCED BY THIS
SUPPLEMENT
This section presents a complete listing of the changes to the document introduced
by this supplement. Each change is identified by the section number and the title as
it will appear in the complete document. Where necessary, a brief description of the
change is included.
1.7.1 Transmitter Equipment Performance
The table and notes have been updated to reflect which services Inmarsat operate
on each satellite generation Inmarsat 3 (I3) and Inmarsat 4 (I4).
2.2.1.4.2 RF Output Power
Updated to reference, Attachment 6 and values for HGA and IGA identified. The
Note was changed.
2.2.2 External Flange Mount HPA and Subsections
Major rewrite which introduces two types of external flange mount HPA being small
and large. Both are actively cooled although the large HPA has a ‘loss of cooling
mode’. The output power ratings of the HPAs are 22-35W, and 30-60W
respectively.
2.5.1 Primary Power Input
The table has been updated to define the input power of the external HPAs, as well
as for the SDU in ‘loss of cooling mode’.
2.8 Cooling
Reference to ARINC Specification 628 deleted and replaced by reference to
Sections 2.2.2.2 and 2.2.2.3.
2.8.2 Flange Mounted HPA
The cooling for the small and large mounted HPAs is defined as 50 and 72 kg/hr of
60° C (max) air with a 51mm of water pressure drop. A loss of cooling mode is
defined for the large HPA.
ATTACHMENT 1-2B – SATCOM CONFIGURATION – OPTIONAL FLANGE MOUNT HPA
‘Cable’ is changed to ‘installation loss’ in the note.
ATTACHMENT 1-6 – SDU CONFIGURATION MODULE FORM FACTOR
The position of the earth stud between the two views was contradictory. This has
been corrected.
SUPPLEMENT 3 TO ARINC CHARACTERISTIC 781 – Page b

ATTACHMENT 1-7A – SMALL FLANGE MOUNT HPA FORM FACTOR

New form factor figure is provided.
ATTACHMENT 1-7B – LARGE FLANGE MOUNT HPA FORM FACTOR
New form factor figure is provided.
ATTACHMENT 1-7C – FLANGE MOUNT HPA CONNECTOR LAYOUT
The connector layout figure is renamed from Attachment 1-7A to Attachment 1-7C.
ATTACHMENT 6 – ARINC 781 HPA OUTPUT POWER USE CASES
This attachment is new and the old Attachment 6 has been renamed Attachment 7.
This attachment defines ‘HPA RF power use cases’ which manufacturers may use to
dimension the size (in RF output power) of their HPAs depending on expected
applications.
APPENDIX B – SECURITY ANALYSIS OF THE SATCOM ETHERNET INTERFACE
This appendix has been updated by Airbus so it now reflects security needs on both
Boeing and Airbus aircraft. There are numerous changes that are not identified in
this description of changes, but are marked in blue bold in the actual text.
 AERONAUTICAL RADIO, INC.
2551 Riva Road
Annapolis, Maryland 24101-7435

SUPPLEMENT 4
TO
ARINC CHARACTERISTIC 781
MARK 3 AVIATION SATELLITE COMMUNICATION SYSTEM

Published: May 19, 2010

Prepared by the AEEC

Adopted by the AEEC Executive Committee: March 31, 2010

 SUPPLEMENT 4 TO ARINC CHARACTERISTIC 781 – Page a

A. PURPOSE OF THIS DOCUMENT

This supplement adds new material on Passive Intermodulation Built-In Test
(PIMBIT) and RF installation issues. The following areas have also been updated:
• ORT contents
• Attachment 1-3 Standard Interwiring
• Attachment 1-4 Notes Applicable to Standard Interwiring
• Attachment 2B Bit-Oriented Fault reporting Protocol
• Attachment 5 Ethernet Interface.
B. ORGANIZATION OF THIS SUPPLEMENT
In the past, changes introduced by a supplement to an ARINC Standard were
identified by vertical change bars with an annotation indicating the change number.
Electronic publication of ARINC Standards has made this mechanism impractical.
In this document blue bold text is used to indicate those areas of text changed by
the current supplement only.
C. CHANGES TO ARINC CHARACTERISTIC 781 INTRODUCED BY THIS
SUPPLEMENT
This section presents a complete listing of the changes to the document introduced
by this supplement. Each change is identified by the section number and the title as
it will appear in the complete document. Where necessary, a brief description of the
change is included.
2.3.6 RF Installation Issues
Commentary was revised. Material was added on some best practices to obtain a
low PIM installation of a SwiftBroadband satcom system and general maintenance
guidelines for aluminum aircraft fuselages.
3.4.2.1.3 ORT Contents
Section B: Interfacing Systems Configuration was updated to include Data from
GNSS to SDU.
Section E: Miscellaneous Configuration Settings was updated to include PIMBIT.
3.7 Passive Intermodulation Built-In Test (PIMBIT)
The new material in this section and its subsections is applicable to multi-channel
system installations that support at least one SwiftBroadband channel. For the case
of multiple system installations, each system can be treated independently of the
others (in view of the assumed minimum propagation loss between the multiple
systems’ antennas).
ATTACHMENT 1-3 – STANDARD INTERWIRING
Changed MP06J and MP06K from “Spare ARINC 429 Input” to “Data from GNSS to
SDU”.
ATTACHMENT 1-4 – NOTES APPLICABLE TO STANDARD INTERWIRING
Broke Note 15 into Notes 15 and 16 and renumbered all remaining notes.
Revised Note 15 extensively regarding the GNSS data to include deleting Label 370
GNSS Height (HAE) from the Hybrid Inertial/GNSS Data column.
Revised Note 16 regarding the circuit breaker size and wire size limits.
SUPPLEMENT 4 TO ARINC CHARACTERISTIC 781 – Page b

ATTACHMENT 1-5B
Pins MP6J and MP6K assigned to “Data from GNSS to SDU”.
ATTACHMENT 2B – BIT-ORIENTED FAULT REPORTING PROTOCOL
In Fault Summary Word #7 for satcom table, changed bit 20 from “Reserved” to
“HGA Over Temperature”.
In Fault Summary Word #9 for satcom table, changed:
• Bit 21 to “Data from GNSS to SDU”
• Bit 22 to “Reserved for PIM Failure”
• Bits 23, 28 and 29 to “reserved”.
ATTACHMENT 5 – ETHERNET INTERFACE
New and updated material.
The following material is archived for future consideration and revision.
4.4.1.1 AT Command Timeouts
Activation and modification commands can take quite a while to execute over
the air. A context activation (+CGACT) with maximum retries can take almost 3
minutes; context modification (+CGCMOD) can take 1 minute. In an
environment where there are many processes sharing the same unit,
commands by these other users may delay execution (that is, commands from
all clients might be executed serially).
An application should tolerate a fairly long delay before declaring the
connection as invalid (say, 5 minutes). The user application may decide to
declare the operation has failed before that time, but should still give the side
AT handler a chance to respond.
If an application gives up on a side AT command, it is recommended that it
close the socket and connect a new one. Note that if the timeout is caused by
too many commands having been queued up at the same time, opening a new
connection and sending the command again will probably not result in a quick
response.
 SUPPLEMENT 4 TO ARINC CHARACTERISTIC 781 – Page c

arincSwift_v1-0_MIB
Basic SNMP v2 imporrts Conformity according
SNMPv2 based OIDs
to other
ARINC standards

SNMPv2-CONF RFC1212 MIB RFC-1155-SMI ARINC 763

arincSwift SNMPv2-SMI RFC1213 MIB PPP-LCP-MIB ARINC 664
SNMPv2-TC RFC1215 MIB ARINC 811

asLinks

aslInfos

asliSatLockState
aslServices
asliSatID

aslsServiceNumbers
asliLinkEntryNumbers

aslsServiceTable
asliLinkTable
PK aslsServiceIndex
PK asliLinkIndex
aslsServiceName
aslsServiceAvailablility I1 asliLinkMainLinkIndex
aslsServiceMaxChannels I2 asliLinkServiceIndex
aslsServiceMaxBW I3 asliLinkContrInterfaceIndex
I4 asliLinkPhysIntefaceIndex
asVersion asliLinkReleaseType
asliLinkReleaseReason
asuda<Vendor> asliLinkUp
asvMajorVersion RFC1213-MIB asliLinkChannelNo
- ifIndex asliLinkChannelCardNo
asvMinorVersion asliLinkBeamID
asuda<Vendor> asliLinkContextID
PPP-LCP-MIB asliLinkIpAddress
asliLinkCurAllocBW
asUserDefArea
- pppLinkStatusPhysicalIndex
asliLinkTxTrafficVol
asuda<Vendor>
asliLinkRxTrafficVol
asliLinkSatSigQual

asSystem asUnits asuSDUAvailable

asuSDU

asuSduConfig asuSduInfo asuSduTraps

assConfig asuSCMAvailable

assSelfTestAvailable
asuSCM
asscTrapActivation
assSelfTest
asuScmConfig asuScmInfo asuScmTrap
asscTrapDest (DNS / IP)

asscTrapDestPort asuDLNAAvailable
asssTestcaseTable
assInfos ARINC Swift MIB Structure
PK asssTestcaseIndex
asuDLNA

asssTestCaseName asuDlnaConfig asuDlnaInfo asuDlnaTrap

assTraps
assiHealthStatus

asssTestCommand asuAntennaAvailable
assiVendor
asstHealthStatusTrap
asssTestUpTime
assiHWPN asuAntenna
asstLinkReleaseTrap
asssTestStatus
asuAntConfig asuAntInfo asuAntTrap
assiSerialNumber
asstLinkBeamIDTrap
asssTestLastResult
assiHWFunction asu<TBD>Available
asstServiceAvailabilTrap
asssTestReturnCode Future units
assiShortName can be added here
asu<TBD>
asssTestReturnMessage
 AERONAUTICAL RADIO, INC.
2551 Riva Road
Annapolis, Maryland 24101-7435

SUPPLEMENT 5
TO
ARINC CHARACTERISTIC 781
MARK 3 AVIATION SATELITE COMMUNICATION SYSTEM

Published: June 15, 2012

Prepared by the AEEC

Adopted by the AEEC Executive Committee: May 02, 2012

 SUPPLEMENT 5 TO ARINC CHARACTERISTIC 781 – Page a

A. PURPOSE OF THIS DOCUMENT

This supplement provides corrections or updates to:
• The definition of SwiftBroadband safety services
• The definition of SB200 (compact satcom system)
• Extended L band tuning range changes
• Tightening of HPA 7th order IM requirement
• Relaxation in Type F DLNA Tx to Rx port rejection
• Clarification of audio levels
• Additional HPA RF power use cases
• Cleanup to the definition of the Ethernet interface.
• Other miscellaneous changes
B. ORGANIZATION OF THIS SUPPLEMENT
In the past, changes introduced by a supplement to an ARINC Standard were
identified by vertical change bars with an annotation indicating the change number.
Electronic publication of ARINC Standards has made this mechanism impractical.
In this document, blue bold text is used to indicate those areas of text changed by
the current supplement only (with the exception of Attachment 7 (SB200)) which is a
new attachment and is not marked.
C. CHANGES TO ARINC CHARACTERISTIC 781 INTRODUCED BY THIS
SUPPLEMENT
This section presents a complete listing of the changes to the document introduced
by this supplement. Each change is identified by the section number and the title as
it will appear in the complete document. Where necessary, a brief description of the
change is included.
1.1 Purpose of this Characteristic
Added paragraph indicating that this Characteristic specifies equipment operating in
the L-band.
1.3 Inmarsat System Description
Added “L-band” terminology to distinguish the service being described from Ku-band
and Ka-band services.
Added capabilities description of the Alphasat satellite.
Added description of the different SwiftBroadband classes.
Added commentary on anticipated future introduction of Extended L-band.
1.4 Function of Equipment
Changed frequency ranges to include Extended L-band.
Added paragraph to explain the need for equipment purchasers to specify the exact
configuration of the ARINC 781 product required.
Added commentary cautioning against adding filters to protect Iridium.
1.5 Airborne Avionics Configuration
Added Enhanced Low GAIN Antenna to list of equipment defined in this
Characteristic.
SUPPLEMENT 5 TO ARINC CHARACTERISTIC 781 – Page b

1.6.1 Satellite Data Unit (SDU)

Added explanation of 2 MCU and 6 MCU SDU form factors.
1.6.5 HPA LNA Diplexer (HLD)
Added new section.
1.6.6 Enhanced Low Gain Antenna (ELGA)
Added new section.
1.6.6 Intermediate Gain Antenna (IGA)
This section renumbered.
1.6.7 High Gain Antenna (HGA)
This section renumbered.
1.7.1 Transmitter Equipment Performance
Deleted LGA from Table 1-1.
Deleted Note 3 from Table 1-1.
Added EIRP for ELGA to Table 1-1.
Clarified the use of spot/regional beams for Classic Aero in Table 1-1, Note 1.
1.7.2 Receiver Equipment Performance
Added G/T requirement for ELGA.
2.1 Introduction
Added statement that interchangeability standards for the CSDU, ELGA and HLD
are defined in Attachment 7.
2.2 Form Factors, Connectors, and Pin Coding
This section expanded to refer to 6 MCU, SDU, and 2 MCU SDU.
2.2.1.4.5.1 Intermodulation Products
Tightened 7th order intermodulation specification for SwiftBroadband equipment.
2.2.4 Diplexer/Low-Noise Amplifier (DLNA)
Updated the commentary on the development history of the DLNA.
2.2.4.3.3.2 Type F - Transmit Port to Receive Port (DLNA Output)
Relaxed Type F DLNA TX to RX port rejection.
2.3.3.6.11 L-band System Physical Isolation
Added “L-band” to section title.
2.3.4 Enhanced Low Gain Antenna
Changed section title to “Enhanced Low Gain Antenna.”
Added reference to Attachment 7 for ELGA characteristics.
3.1.1.1 General
Refined the description of the extents of the Inmarsat radio function.
3.1.1.4 SwiftBroadband
Major update to reflect addition of SwiftBroadband safety, including a new service
tree figure, an updated overall SwiftBroadband architecture figure, and an updated
Table 3-2 (Forward and Return Bearer Types).
 SUPPLEMENT 5 TO ARINC CHARACTERISTIC 781 – Page c

3.1.2.4.2 Frequency Allocations by Ground Stations

Deleted the commentary about a potential new Swift64 category as this is no longer
being considered.
3.1.2.5 Mapping User Interfaces to Radio Interfaces
This section renumbered.
Updated Table 3-3 to reflect addition of SwiftBroadband safety.
3.1.2.6 Selection of Inmarsat Services, Satellites, and Ground Stations
This section renumbered.
Added “Alphasat” to the “satellite type in use” list.
3.2.1.1 Introduction
Added paragraph on the need for consistency between audio output levels of
satellite voice services and that of VHF radio services.
Deleted references to SAT Radio.
3.2.1.2.1 MCDU
Reworded paragraph describing MCDU menus that are specified by the airframe
manufacturers and when MCDU menus can be specified by the avionics equipment
manufacturers.
3.2.1.2.3 AMS
Paragraph expanded and rewritten to clarify all audio input and output
characteristics.
3.2.1.3 Call Annunciation
Added text describing caller line identification for SwiftBroadband safety voice
operation.
3.2.1.7 SAT Phone using SwiftBroadband
Updated to reflect addition of SwiftBroadband safety.
3.2.1.8 SAT Radio
Added note that SAT Radio has not been implemented but that this section has been
retained for reference.
3.2.2 Cockpit ACARS Data
“ACARS” added to title. Updated to reflect that the same interface is used for both
Classic Aero and SwiftBroadband.
3.4.2.1.3 ORT Contents
ORT items added for:
Item C/17 Cockpit Ethernet Port
Item D/14 Cockpit Headset Audio Gain
Item D/15 Cockpit Headset Sidetone Gain
Item G/1 Safety Channel Identifier
Item G/2 Position Reporting Service
Item G/3 Safety Channel Access Class (0-15)
Item G/4 ACARS Data APN
Item G/5 Voice over IP APN
SUPPLEMENT 5 TO ARINC CHARACTERISTIC 781 – Page d

Item G/6 AGGW DNS Lookup Name

Item G/7 Aircraft Type
3.4.2.3 AES ID
Updated to reflect that SwiftBroadband safety uses this parameter as its primary
addressing mechanism.
3.4.2.5 IMSI and IMEI(SV) (SwiftBroadband)
Updated to reflect that SwiftBroadband non-safety uses these parameters as its
primary addressing mechanism.
3.4.2.6 Addressing for SwiftBroadband Safety Services
New section added.
3.4.2.7 Aircraft Type
This section renumbered.
3.6.3 FANS/ATS over SwiftBroadband
Commentary deleted and replaced by note stating that FANS/ATS over
SwiftBroadband is now specified in the main body of this document.
3.6.4 Multi-Frequency Band
Section deleted.
3.7.3.1 Frequencies reserved for PIMBIT.
Added reference to Alphasat Satellite.
ATTACHMENT 1-3 STANDARD INTERWIRING
Modified SDU TP71 and SDU BP06 to accommodate SB200 interfaces.
ATTACHMENT 1-4A – SYSTEM CONFIGURATION PINS DEFINITION AND
INTERPRETATION
Added SwiftBroadband safety activation to TP6E.
ATTACHMENT 1-5A – SDU TOP PLUG CONNECTOR LAYOUT
Modified TP71 (coaxial contact) to accommodate SB200.
ATTACHMENT 1-5C – SDU BOTTOM PLUG CONNECTOR LAYOUT
Modified BP06 (coaxial contact) to accommodate SB200.
ATTACHMENT 2 – ARINC 429 LABELS AND WORD FORMATS USED IN THE
AVIATION SATELLITE COMMUNICATIONS SYSTEM
Edited to remove references to Globalstar and ICO.
ATTACHMENT 5, Section 2.3.4, Streaming Class
Updated streaming data rates and added description of SBB X-stream mode.
ATTACHMENT 5, Section 3.3.11.3.1, Parameters Field for SBB
Deleted STREAM256K option name.
Added XSTREAM option name and sample AT string for SBB X-Stream service.
ATTACHMENT 5, Section 3.3.11.3.3, Parameter Field for ISDN
Changed MPDS to ISDN.
 SUPPLEMENT 5 TO ARINC CHARACTERISTIC 781 – Page e

ATTACHMENT 5, Section 3.3.11.4, Paragraph Not Used

Added section title (was previously blank).
ATTACHMENT 5, Section 3.3.11.5, Hunt Group Syntax for Service Names
Changed STREAM256K to STREAM128K
ATTACHMENT 5, Section 4.2.4.2, Welcome Message
Added commentary that provisions should be included in the terminal to disable or
modify the welcome message.
ATTACHMENT 5, Section 4.3.2.1, Additional Secondary Context
Figure updated: deleted PPPoE1.
ATTACHMENT 5, Section 4.3.2.2, Modify PDP Context
Figure updated: deleted “‘AT+CGEQREQ,”.
ATTACHMENT 5, Section 4.4.1, AT Command Interface Support
+CMS ERROR changed from “M” to “O” in last column.
ATTACHMENT 5, Section 4.4.2.1.1, Set Command
Editorial change: “Session” corrected to “Session ID”.
ATTACHMENT 5, Section 5.3.2.2.1.2, Object Behavior
Added entry for SBB X-Stream.
ATTACHMENT 5, Section 5.3.2.2.2.1, Object Structure
Added range for Negotiated Bandwidth.
Added range for Beam ID.
Added note identifying values for expected maximum/ideal values for Link Signal
Quality.
ATTACHMENT 5, Section 5.3.2.4.1.1, Information Sub Branch for the SDU Unit
Related Objects
Corrected units for items 30, 31, and 32.
ATTACHMENT 5, Section 5.3.2.4.4.1, Information Sub Branch for the Antenna Unit
Related Objects
Changed range for “.asuAntInfoGain(10)”. Added note that “-1” indicates invalid
antenna gain for this object identifier.
ATTACHMENT 6 – HPA OUTPUT POWER USE CASES
Added explanation on how to calculate HPA output power with worked example.
Added commentary advising of the need to consider peak-to-average ratio.
ATTACHMENT 7 – COMPACT SATCOM DEFINITION (SB200)
Added new attachment describing a new compact SBB product.
ATTACHMENT 8 – Attachment Reference Guide
This attachment renumbered to make space for the new Attachment 7.
APPENDIX A – Acronyms
Updated acronym list.
 AERONAUTICAL RADIO, INC.
2551 Riva Road
Annapolis, Maryland 24101-7435

SUPPLEMENT 6
TO
ARINC CHARACTERISTIC 781
MARK 3 AVIATION SATELITE COMMUNICATION SYSTEMS

Published: December 5, 2012

Prepared by the AEEC

Adopted by the AEEC Executive Committee: October 4, 2012

 SUPPLEMENT 6 TO ARINC CHARACTERISTIC 781 – Page a

A. PURPOSE OF THIS DOCUMENT

This supplement provides new contents as follows:
• New Attachment 8, Security Recommendations for SwiftBroadband Safety
Services
• Update to Section 3.4.3, Security
• Other miscellaneous changes
B. ORGANIZATION OF THIS SUPPLEMENT
In the past, changes introduced by a supplement to an ARINC Standard were
identified by vertical change bars with an annotation indicating the change number.
Electronic publication of ARINC Standards has made this mechanism impractical.
In this document, blue bold text is used to indicate those areas of text changed by
the current supplement. Attachment 8 is a new attachment added by Supplement 6.
Bolding is omitted for readability.
C. CHANGES TO ARINC CHARACTERISTIC 781 INTRODUCED BY THIS
SUPPLEMENT
This section presents a complete listing of the changes to the document introduced
by this supplement. Each change is identified by the section number and the title as
it will appear in the complete document. Where necessary, a brief description of the
change is included.
1.2 Relationship of this Document to Other ARINC Standards and Industry
Documents
Updated list of referenced documents.
3.2.4 Ethernet
Commentary added to stress that the Ethernet interface was designed for non-safety
applications only, and that it has not been determined if this interface definition is
suitable for the SBB Safety Priority IP service.
3.4.3 Security
This section is essentially being replaced by the new Attachment 8, Network Security
Recommendations Analysis. This section is revised to include only high-level points
on security, and includes references EUROCAE ED-202/RTCA DO-326 and
Attachment 8.
Section 3.4.3 is based on ARINC Report 811, the content of which differs from
EUROCAE ED-202/RTCA DO-326.
ATTACHMENT 5, SECTION 3.3 – PROTOCOL OPERATION FOR BGAN CONTEXT SETUP,
PPPOE DISCOVERY
Corrected the table which delineates the PPPoE Discovery sequence so that it is
consistent with RFC 2516.
ATTACHMENT 7, SECTION 4.1.3 – CSDU SERVICES AND FEATURES
Corrected the comments for “Cabin Data” and “Security” (added references
Attachment 8).
ATTACHMENT 8 – NETWORK SECURITY ANALYSIS FOR SWIFTBROADBAND
SAFETY SERVICES
This attachment added by Supplement 6.
SUPPLEMENT 6 TO ARINC CHARACTERISTIC 781 – Page b

ATTACHMENT 9 – ATTACHMENT REFERENCE GUIDE

This attachment renumbered to make space for the new Attachment 8.
APPENDIX A – ACRONYMS
Updated acronym list.
APPENDIX B – SECURITY ANALYSIS OF THE SATCOM ETHERNET INTERFACE
Added commentary at the end of Section B-1 that clarifies that the foundation of the
security analysis in Appendix B is based on ARINC Report 811 methodology which
does not address safety services. The current recommended methodology can be
found in EUROCAE ED-202/RTCA DO-326.
 ARINC Standard – Errata Report
1. Document Title
(Insert the number, supplement level, date of publication, and title of the document with the error)

2. Reference

Page Number: Section Number: Date of Submission:

3. Error
(Reproduce the material in error, as it appears in the standard.)

4. Recommended Correction
(Reproduce the correction as it would appear in the corrected version of the material.)

5. Reason for Correction (Optional)

(State why the correction is necessary.)

6. Submitter (Optional)
(Name, organization, contact information, e.g., phone, email address.)

Please return comments to fax +1 410-266-2047 or [email protected]

Note: Items 2-5 may be repeated for additional errata. All recommendations will be evaluated by the staff. Any
substantive changes will require submission to the relevant subcommittee for incorporation into a subsequent
Supplement.

[To be completed by IA Staff ]

Errata Report Identifier: Engineer Assigned:

Review Status:

ARINC Errata Form

March 2012
 Project Initiation/Modification proposal for the AEEC
Date Proposed: Click here to enter a date.

ARINC Project Initiation/Modification (APIM)

1.0 Name of Proposed Project APIM #: ___________
(Insert name of proposed project.)
1.1 Name of Originator and/or Organization
(Insert name of individual and/or the organization that initiated the APIM)

2.0 Subcommittee Assignment and Project Support

2.1 Suggested AEEC Group and Chairman
(Identify an existing or new AEEC group.)
2.2 Support for the activity (as verified)
Airlines: (Identify each company by name.)
Airframe Manufacturers:
Suppliers:
Others:
2.3 Commitment for Drafting and Meeting Participation (as verified)
Airlines:
Airframe Manufacturers:
Suppliers:
Others:
2.4 Recommended Coordination with other groups
(List other AEEC subcommittees or other groups.)

3.0 Project Scope (why and when standard is needed)

3.1 Description
(Insert description of the scope of the project.)
3.2 Planned usage of the envisioned specification
Note: New airplane programs must be confirmed by manufacturer prior to
completing this section.

New aircraft developments planned to use this specification yes ☐ no ☐

Airbus: (aircraft & date)
Boeing: (aircraft & date)
Other: (manufacturer, aircraft & date)
Modification/retrofit requirement yes ☐ no ☐
Specify: (aircraft & date)
Needed for airframe manufacturer or airline project yes ☐ no ☐
Specify: (aircraft & date)

Page 1 of 3
Updated: March 2012
 Mandate/regulatory requirement yes ☐ no ☐
Program and date: (program & date)
Is the activity defining/changing an infrastructure standard? yes ☐ no ☐
Specify (e.g., ARINC 429)
When is the ARINC standard required?
______(month/year)__________
What is driving this date? _______(state reason)_____________________
Are 18 months (min) available for standardization work? yes ☐ no ☐
If NO please specify solution: _________________
Are Patent(s) involved? yes ☐ no ☐
If YES please describe, identify patent holder: _________________
3.3 Issues to be worked
(Describe the major issues to be addressed.)

4.0 Benefits
4.1 Basic benefits
Operational enhancements yes ☐ no ☐
For equipment standards:
(a) Is this a hardware characteristic? yes ☐ no ☐
(b) Is this a software characteristic? yes ☐ no ☐
(c) Interchangeable interface definition? yes ☐ no ☐
(d) Interchangeable function definition? yes ☐ no ☐
If not fully interchangeable, please explain: _________________
Is this a software interface and protocol standard? yes ☐ no ☐
Specify: _________________
Product offered by more than one supplier yes ☐ no ☐
Identify: (company name)
4.2 Specific project benefits (Describe overall project benefits.)
4.2.1 Benefits for Airlines
(Describe any benefits unique to the airline point of view.)
4.2.2 Benefits for Airframe Manufacturers
(Describe any benefits unique to the airframe manufacturer’s point of view.)
4.2.3 Benefits for Avionics Equipment Suppliers
(Describe any benefits unique to the equipment supplier’s point of view.)

5.0 Documents to be Produced and Date of Expected Result

Identify Project Papers expected to be completed per the table in the following
section.

Page 2 of 3
Updated: March 2012
5.1 Meetings and Expected Document Completion
The following table identifies the number of meetings and proposed meeting days
needed to produce the documents described above.

Mtg-Days Expected Start Expected

Activity Mtgs
(Total) Date Completion Date
Document a # of mtgs # of mtg days mm/yyyy mm/yyyy

Document b # of mtgs # of mtg days mm/yyyy mm/yyyy

Please note the number of meetings, the number of meeting days, and the
frequency of web conferences to be supported by the IA Staff.

6.0 Comments
(Insert any other information deemed useful to the committee for managing this
work.)
6.1 Expiration Date for the APIM
April/October 20XX

For IA staff use only

Date Received: : Click here to enter a date. IA staff :
Potential impact:
(A. Safety B. Regulatory C. New aircraft/system D. Other)
Resolution:
Authorized, Deferred, Withdrawn, More Detail Needed, Rejected)
Assigned to SC/WG:

Completed forms should be submitted to the AEEC Executive Secretary.

Page 3 of 3
Updated: March 2012