AERONAUTICAL COMMUNICATIONS PANEL (ACP) · 1.1 Following Recommendation 3/2 of the first meeting of...

(116 pages) ACP.1.WP.009.2.en.doc

AERONAUTICAL COMMUNICATIONS PANEL (ACP)

FIRST MEETING

Montréal, 10 to 18 May 2007

Agenda Item 2: Review of the draft Manual on Detailed Technical Specifications for the AMS(R)S

THE REPORT ON THE VALIDATION OF THE REQUIREMENTS IN THE AMS(R)S SARPs FOR IRIDIUM

(Presented by Rapporteur of Working Group M)

SUMMARY

This working paper presents the Draft Report on the Validation of the Requirements in the AMS(R)S SARPs for Iridium. Action by the ACP is in paragraph 3.

1. INTRODUCTION

1.1 Following Recommendation 3/2 of the first meeting of the Aeronautical Communications Panel (ACP) Working Group of the Whole (21 to 29 June 2005, Montreal, Canada) a Working Group M (WG-M) sub-group (“Iridium subgroup”) was established to develop a new Iridium technical manual in a timeframe that would support the applicability date of the new AMS(R)S Standards and Recommended Practices (SARPs) by November 2007; an implementation manual to provide guidance to States on commissioning the system, and identify any validation requirements associated with the Iridium technical manual and conduct appropriate validation, if necessary.

2. DISCUSSION

2.1 Under the terms of reference of the WG-M sub-group, as detailed in the sub-group report to this meeting, validation requirements associated with the information in Part II (Iridium) of the draft AMS(R)S manual were identified and appropriate validation was conducted. A supplemental report containing this technical validation has been developed.

International Civil Aviation Organization WORKING PAPER

ACP/1-WP/9 27/4/07 English only

ACP/1-WP/9

- 2 -

3. ACTION BY THE ACP

3.1 The ACP is invited to review the attached Draft Report on the Validation of the Requirements in the AMS(R)S SARPs for Iridium (Appendices A and B refer) and consider it along with the Draft Manual for the Aeronautical Mobile Satellite (Route) Service.

— — — — — — — —

Report on the Validation of the Requirements

in the AMS(R)S SARPs for Iridium

Revision 3.1

30 March 2007

Page 1 of 53

APPENDIX A ACP/1-WP/9Appendix A

Date & Version Change 09/01/06

v0.1 Draft document prepared by M. Meza 10/05/06

v0.2 Revised Draft prepared by M. Meza 10/26/06

v0.3 Revised Draft with IRD working group input by M. Meza 12/12/06

v0.4 Revised to add auto-dialer set up description, section 3.0, and fault detection and annunciation diagram per WG input

1/05/2007 v.0.5

Revised draft based on updated and finalized SARP language and additional Iridium data. (K. O’Keefe)

v.0.6 Draft revision resulting from WG-07 meeting in Tempe, AZ. v.1.0 Revisions following Tempe meeting and in preparation for WG-08.

V1.1 Revisions to include capacity study, 24 bit ICAO address handling and other issues identified during WG-07

v.2.0 Revised Draft for meeting IRD WG-8 V2.1 IRD-WG Meeting 8 edits and revisions. v.2.2 Revisions following Meeting 8 v.3.0 Submission to WG-M v.3.1 Modified Section 4 (30 March 2007)

Page 2 of 53

ACP/1-WP/9Appendix A

1. INTRODUCTION

1.1 Objective The objective of this technical report is to demonstrate that the Iridium Satellite Aeronautical Mobile Satellite (Route) Service (AMS(R)S) can meet or exceed the technical intent of the AMS(R)S Standards and Recommended Practices (SARPs).

This report is to be considered in conjunction with the SARPs as contained in Annex 10, Volume III, Part I, Chapter 4.

1.2 Scope This report directly compares the projected performance of the Iridium Satellite Network’s AMS(R)S with the technical and performance requirements outlined in the AMS(R)S SARPs.

1.3 Validation Methodologies Inspection

IA Inspection using common knowledge IB Inspection through use of prior analysis/documents MN Monitoring and/or measurement MD Manufacturer’s data

Test IT Integration test UT Unit Test FT Flight Test

Simulation, Comparison and Analysis A Analysis S Simulation C Comparison with similar device and/or system

No validation required (may include editorial inspection), NVR

2. COMPARISON OF AMS(R)S SARPS AND PROJECTED IRIDIUM PERFORMANCE

This section contains information provided by Iridium Satellite LLC regarding the Iridium satellite network’s conformity with AMS(R)S SARPs. Table 2-3 tabulates the AMS(R)S SARPs requirements and the associated Iridium-specific performance parameters.

Throughout this document, the Satellite Network Operations Provider may be referred to as Iridium, Iridium Satellite, or ISLLC. Refer to the list of definitions in Part 2 of the Technical and Implementation Manual for a description of a Satellite Communications Services Provider, Satellite Network Operations Service Provider, Terrestrial Network Services Provider and other terms related to provision of Iridium AMS(R)S.

Page 3 of 53


Example of a validation report Original Requirement The AES equipment shall operate properly in an interference environment causing a cumulative relative change in its receiver noise temperature (ΔT/T) of 25 per cent. [AMS(R)S SARPs, 4.3.3.1]

Requirement Validation: Validation Methods = A, Reference Annex A, WP-599 Validation Details: A 25% increase in receiver noise temperature is equivalent to a 1.0 dB link margin degradation. This additional degradation due to interference is accounted for in the Iridium link budget. The service links are designed to provide a 15 dB margin.

2.1 GENERAL 2.1.1 General Any mobile satellite system intended to provide AMS(R)S shall confirm to the requirements of this chapter. [AMS(R)S SARPs, 4.2.1] 2.1.1.1 Original Requirement(s): An AMS(R)S system shall support packet data service, or voice service, or both. [AMS(R)S SARPs, 4.2.1.1] Requirement Validation: Validation Methods = will be detailed in each section of this report Validation Details: Iridium currently provides voice and data services in the aviation sector. Iridium data is format neutral and can support both character and bit-oriented data traffic. Voice service is in use today on fixed and rotary wing aircraft. As detailed in the paragraphs below, the Iridium satellite network supports both voice and packet data service

2.2 RF CHARACTERISTICS

2.2.1 Frequency Bands Note – ITU Radio Regulations permit systems providing mobile-satellite service to use the same spectrum as AMS(R)S without requiring such systems to offer safety services. This situation has the potential to reduce the spectrum available for AMS(R)S. It is critical that States consider this issue in frequency planning an in the establishment of national or regional spectrum requirements.

Page 4 of 53


2.2.1.1 Frequency Bands Original Requirement(s): When providing AMS(R)S communications, an AMS(R)S system shall operate only in frequency bands which are appropriately allocated to AMS(R)S and protected by the ITU Radio Regulations. [AMS(R)S SARPs, 4.3.1.1]

Requirement Validation: Validation Methods = A Validation Details: The spectrum used for the Iridium satellite service is regulated according to Nos. 5.359, 5.364, 5.365, 5.366, and 5.367 of the Radio Regulations. No. 5.364 specifies sharing conditions and coordination requirements for MSS (Iridium) earth stations in the Earth-to-space direction. No. 5.365 requires coordination for space-to-Earth transmissions. The required coordinations have been carried out and the Iridium System service link spectrum was notified to the ITU-BR in 1998. An indication of this may be found in the ITU-BR International Frequency List (IFL), and thereby, the frequency assignments in the Notification are entitled to protection. The system was brought into use in the mid 1990’s. Coordination under No. 5.366 and 5.367 regarding use of satellite facilities on airplanes and use of the AMS(R)S on a primary allocation basis, respectively, have been carried out under the provisions of these regulations (No. 9.21). Finally, coordination with Fixed services in the countries indicated in 5.359 has also been carried out. This regulation encourages the indicated countries to not authorize additional fixed stations in the band.

2.2.2 Emissions 2.2.2.1 Interference to Other Systems Original Requirement(s): The total emissions of the AES necessary to meet designed system performance shall be controlled to avoid harmful interference to other systems necessary to support safety and regularity of air navigation, installed on the same or other aircraft. Note 1.— Harmful interference can result from radiated and/or conducted emissions that include harmonics, discrete spurious, intermodulation product and noise emissions, and are not necessarily limited to the "transmitter on” state.

Page 5 of 53


Note 2.— Protection requirements for GNSS are contained in Annex 10, Volume I. [AMS(R)S SARPs, 4.3.2.1] 2.2.2.2 Interference to AMS(R)S Equipment on Other Aircraft 2.2.2.2.1 Interference to AMS(R)S equipment on other aircraft Original Requirement Emissions from an AMS(R)S system AES shall not cause harmful interference to an AES providing AMS(R)S on a different aircraft. [AMS(R)S SARPs, 4.3.2.2.1] Note.— One method of complying with 4.3.2.2.1 is by limiting emissions in the operating band of other AMS(R)S equipment to a level consistent with the intersystem interference requirements such as contained in RTCA document DO-215. RTCA and EUROCAE may establish new performance standards for future AMS(R)S which may describe methods of compliance with this requirement.

Requirement Validation: Validation Methods = A; Reference Annex A, WP-599, FT, UT Validation Details: The Iridium SDU installed as the active RF component of the AES are designed to meet the emission requirements of RTCA DO-262. This together with a predefined AMS(R)S antenna to GNSS antenna isolation should ensure that AMS(R)S equipment can be operated simultaneously and independently from other communication and navigation equipment installed on the same or other aircraft. [AMS(R)S SARPs, 4.3.2 and sub-paragraphs]

Over 5,000 aircraft are in service with installed Iridium systems. Prior to certification of aircraft installations, ground and flight tests are conducted to ensure safety of flight and to validate that the system maintains electromagnetic compatibility with other systems on board the aircraft.

The Iridium SDU have been designed and tested to insure compliance with the emission limits set out in ITU-R Recommendation M.1343, “Essential technical requirements of mobile earth stations for global non-geostationary mobile-satellite service systems in the bands 1-3 GHz”, as well as national/regional type-approval specifications such as FCC Part 2 and Part 25 and ETSI EN301 441 specifications. FCC and ETSI measurements of standard Iridium SDU have shown that the Iridium SDU meets the specified emission limits.

Compliance of Iridium AES equipment emissions to existing protection requirements for various other onboard radio transceivers is summarized by two tables: Table 1 in Attachment 1 of WGA/14 WP-599 (see Annex A to this document) and Table 2-1 below. Table 1 of WP-599 provides a summary of the Iridium AES emissions MOPS relative to various onboard aviation CNS (communications, navigation and surveillance) equipment, as well as on other radio services (e.g., the Radio Astronomy Service). Since WP-599

Page 6 of 53


was written, the RTCA released DO-294A, which modified the methodology for analyzing interference from Transmitting Personal Electronic Devices (T-PED) to some of the radio services listed in Table 1 of WP-599. Therefore, Table 2-1 below has been provided to show how the MOPS for Iridium AES emissions comply with the methodology of Table 6-1 in DO-294A. It should be noted that Table 6-1 does not specify output emissions levels for transmitting devices; instead it specifies an aggregate input interference level from all possible devices and thus serves as an analytical tool for evaluating possible interference scenarios. Actual emissions limits for Iridium AES terminals are specified in DO-262, under which Iridium terminals are currently compliant. For further details on the derivation of values in Table 2-1, please refer to DO-294A.

Table 2-1: Summary of Iridium AES Emissions DO-294A Conformance

Frequency Range of

Operation (MHz)

Service Victim Channel

Bandwidth (kHz)

MOPS Required Sensitivity

(dBm)

Analytical Interference Threshold Emission

PSD (dBm/Hz)1

Iridium AES

MOPS HSN

(dBm)

Iridium AES

MOPS Meas. BW

(kHz)

Iridium AES

MOPS PSD

(dBm/Hz)

Margin (dB)3

75 Marker Beacon

10 -67 -94 -90 3 -125 31

108 – 112 ILS Localizer (Cat I DH)

6 -79 -112 -90 3 -125 13

108 – 112 ILS Localizer (limits of coverage)

6 -79 -104 -90 3 -125 21

108 – 112 VHF Data Broadcast

16 -87 -122.5 -90 3 -125 2.5

108 – 118 VHF Omnirange (VOR)

6 -93 -108 -90 3 -125 17

118 – 137 VHF Voice Comm.

6 -98 -113 -90 3 -125 12

118 – 137 VDL Mode 2

16 -98 -119.5 -90 3 -125 5.5

118 – 137 VDL Mode 3

16 -98 -119.5 -90 3 -125 5.5

329 – 335 ILS Glide Slope (Cat I DH)

2 -76 -103 -90 3 -125 22

329 – 335 ILS Glide Slope (Limits of coverage)

2 -76 -97.5 -90 3 -125 27.5

1030 Mode A/C transponder

6000 -73 -120 -90 3 -125 5

1030 Mode S transponder

6000 -74 -120 -90 3 -125 5

1090 TCAS interrogator2

[6000] [-74] [-125] -90 3 -125 0

1559 – 1610

GNSS L1 20000 -134.5 -139 -100 1000 -160 21

Page 7 of 53


Notes: 1. The Analytical Interference Threshold Emission PSD is derived from the

RTCA document DO-294A, Table 6-1, “Analytical Aggregate T-PED Interference Threshold PSD” column. Since the PSD values in that column represent the aggregate interference level from all possible interferers at the input to the victim receiver, those PSD values must be adjusted to represent the emission PSD from the single interference source (in this case, Iridium AES). The adjusted value is found from Equation 6.1 in DO-294A as:

PSDT = PSDI + LP – KME, where PSDT is the transmitted emission power spectral density for the Iridium

AES, PSDI is the input aggregate interference threshold power spectral density from DO-294A, Table 6-1, LP is the propagation loss between the Iridium AES antenna and victim receiver (which equals 52 dB, per DO-294A, table 5-4) and KME is the multiple equipment, aggregate interference factor (which equal 10 dB, per DO-294A, pg. 6.D-4).

2. The values for this service are in brackets in DO-294, Table 6-1.

3. Margin values in the last column are conservative estimates which make

assumptions about path loss, multiple equipment factors and actual equipment implementation. It should also be noted that the actual Iridium emissions typically perform better than the levels defined in the MOPS.

2.2.3 Susceptibility 2.2.3.1 Susceptibility Original Requirement(s): The AES equipment shall operate properly in an interference environment causing a cumulative relative change in its receiver noise temperature (ΔT/T) of 25 per cent. [AMS(R)S SARPs, 4.3.3.1]

Requirement Validation: Validation Methods = A, Reference Annex A, WP-599 Validation Details: A 25% increase in receiver noise temperature is equivalent to a 1.0 dB link margin degradation. This additional degradation due to interference is accounted for in the Iridium link budget. The service links are designed to provide a 15 dB margin.

Page 8 of 53


2.3 PRIORITY AND PREEMPTIVE ACCESS 2.3.1 Priority and Preemptive Access Original Requirement(s): Every aircraft earth station and ground earth station shall be designed to ensure that messages transmitted in accordance with Annex 10, Volume II, 5.1.8, including their order of priority, are not delayed by the transmission and/or reception of other types of messages. If necessary, as a means to comply with the above requirement, message types not defined in Annex 10, Volume II, 5.1.8 shall be terminated even without warning, to allow Annex 10, Volume II, 5.1.8 type messages to be transmitted and received. Note.— See ITU Radio Regulations No. 5.357A. [AMS(R)S SARPs, 4.4.1] Requirement Validation: Validation Methods = A, UT, and IT, Reference Annex B, WP-598 Validation Details: The Iridium system can support this requirement in a number of ways such as embedded priority within the messages or message header, separate channels for voice and data, and harmonization between the avionics and the ground equipment, such that the two components can exploit the fullest capabilities of the Iridium Network for voice and data services. Avionics designed according to DO-262 are one means of compliance with this requirement for the AES.

The basis for Iridium AMS(R)S Priority, Precedence, and Pre-emption (PPP) is the set of mechanisms designed for, and already implemented in, the Iridium Satellite Network for signaling and system management purposes. The Iridium Satellite Network utilizes two resource management functions, Acquisition Class control and Priority Class control, to assure access to communication channels for priority users.

The acquisition process is one of several protocols completed between an SDU and the satellite constellation for each call set up regardless if the call is mobile originated (from aircraft) or mobile terminated (to aircraft). For mobile originated call, the SDU will start the acquisition process once the call is placed. For mobile terminated call, the SDU will start the acquisition process upon the reception of a RING, indicating an incoming call from the GES.

Each satellite beam broadcasts which Acquisition Classes are allowed to acquire satellite resource on that beam. Only SDUs with the proper Acquisition Class (AC) are allowed to start the acquisition process. Acquisition Class ranges from 0-15. Default non-safety Iridium terminals use an Acquisition Class in the range of 0-9. AMS(R)S safety traffic will be assigned Acquisition Class 14.

Acquisition Class is mainly use for satellite load shedding. In a satellite beam with heavy traffic load, certain Acquisition Classes (e.g., AC0-9) will be shut down to prohibit further traffic load on the satellite. To ensure AMS(R)S safety traffic will get through, Iridium will not shut down AC14 for satellite load shedding.

Page 9 of 53


The Acquisition Class affects how calls initially gain access to the satellite constellation while Priority Class provides continued access for safety-related calls.

The Iridium Satellite Network allows for four levels of priority. Each satellite has priority queuing for both channel assignment of new calls and handoff order of in-progress calls. High priority calls, taking precedence, are queued before low priority calls.

The four Iridium priority levels are mapped to the four-level AMS(R)S priority structure as specified by Table 2-7 of RTCA DO-262.

Iridium Priority 3 (AMS(R)S #4, Distress, Urgency, highest priority); Iridium Priority 2 (AMS(R)S #3, Direction finding, Flight Safety); Iridium Priority 1 (AMS(R)S #2, Other Safety and Regularity of Flight); Iridium Priority 0 (AMS(R)S #1, AMSS Non-Safety, lowest priority).

In case of extreme system resource shortage, on-going low priority calls will be pre-empted by the system to allow access for higher priority call.

While the Iridium Acquisition Class Control and Priority Class Control provide internal system controls for internal PPP management, the Iridium AMS(R)S AES manufacturers and AMS(R)S service providers will need to provide the input/output queuing for call/message priority function at the Iridium network interfaces. These capabilities are intrinsic to the protocol machines that interface Iridium AMS(R)S with its external users, and reside in the AMS(R)S AES and GES.

Currently both the Acquisition Class and Priority Class are encoded on a SIM card; hence the Acquisition Class and Priority Class are associated with a SIM card and an SDU that uses that SIM card. For AMS(R)S, the acquisition class and priority class will need to be associated with each AMS(R)S call (type) and will be controlled by the protocol software that sets up the call.

2.3.2 Identification of Priority Original Requirement(s): All AMS(R)S data packets and all AMS(R)S voice calls shall be identified as to their associated priority. [AMS(R)S SARPs, 4.4.2]

Requirement Validation: Validation Methods = IA Validation Details: The Iridium system is designed to support identification of priority of messages. This can be accomplished in a number of ways such as embedded priority within the messages or message header. In this example the avionics and ground station are harmonized to enable this feature. Avionics designed according to DO-262 are one means of compliance with this requirement for the AES.

Page 10 of 53


2.3.3 Voice Priority Over Data

Original Requirement(s): Within the same message category, the Iridium AMS(R)S service shall provide voice communications priority over data communications.

[AMS(R)S SARPs, 4.4.3] Requirement Validation: Validation Methods = IA, UT Validation Details: The Iridium Network supports prioritization of voice over data via the avionics (terminal equipment). The Iridium Satellite Network supports voice and data services simultaneously. In addition, SBD does not utilize the same channel resources required for voice service. It is recommended for SDUs supporting voice and data service to provide, at a minimum, one voice and one data channel. This allows for simultaneous voice and data service and precludes the need for prioritization of voice over data services. Avionics designed according to DO-262 are one means of compliance with this requirement for the AES

2.4 SIGNAL ACQUISITION AND TRACKING

2.4.1 Ground Speed Original Requirement(s): The AES, GES and satellites shall properly acquire and track service link signals when the aircraft is moving at a ground speed of up to 1500 km/h (800 knots) along any heading. [AMS(R)S SARPs, 4.5.1]

2.4.1.1 Recommendation.— The AES, GES and satellites should properly acquire and track service link signals when the aircraft is moving at a ground speed of up to 2800 km/h (1500 knots) along any heading. [AMS(R)S SARPs, 4.5.1.1]

Requirement Validation: Validation Methods = FT, flight tested on NASA sounding rockets and the Concorde supersonic airliner (Reference Annex A, WP-599). Validation Details: The Iridium Satellite Network consists of fast moving LEO satellites and is hence designed to handle large Doppler frequency shift and Doppler rate of change. The signal acquisition and tracking functions are handled internally within the Iridium Satellite Network by the SDU and the satellites and are transparent to the Iridium users.

Page 11 of 53


Link synchronization is achieved by pre-correcting the SDU transmit timing and frequency so that uplink bursts arrive at the satellite in the correct time slot and on the correct frequency access for the assigned channel. This pre-correction is accomplished by adjusting the SDU timing and frequency in accordance with error feedback which is sent in the downlink maintenance messages by the satellite. The SDU will compensate for a maximum uplink carrier frequency Doppler shift of up to +/-37.5 KHz to achieve the specified uplink frequency of arrival requirements. The SDU receiver will accommodate a carrier frequency Doppler shift of up to +/-37.5 KHz.

Since the Iridium Satellite Network became operational, the Iridium SDUs have been demonstrated to maintain link connectivity in numerous test flights onboard jets and research rockets. A recent test involved the NASA Sounding Rocket was conducted in April 2004. An Iridium flight modem, consisted of an Iridium SDU and other electronics, sent data successfully and continuously from lift-off through 2 rocket stage burns, reaching a peak velocity of up to 1.5 km/sec (5400 km/h, or 3375 miles/hr, or 3884 knots), and only cut out when the rocket tumbled at apogee (120 km, or 396,000 ft). The flight modem reacquired after the first parachute deployed and data was sent until the rocket hit the ground with a reported force of 50 g’s. The Iridium link was maintained on impact and the flight modem continued to transmit for another 25 minutes. This and other demonstrations show that Iridium communication links are robust for high speed flights with large Doppler offset and Doppler rate of change.

2.4.2 Acceleration Relative to the Plane of the Satellite Orbit Original Requirement(s): The AES, GES and satellites shall properly acquire and track service link signals when the component of the aircraft acceleration vector in the plane of the satellite orbit is up to 0.6 g. [AMS(R)S SARPs, 4.5.2] 2.4.2.1 Recommendation.— The AES, GES, and satellites should properly acquire and track service link signals when the component of the aircraft acceleration vector in the plane of the satellite orbit is up to 1.2 g. [AMS(R)S SARPs, 4.5.2.1]

Requirement Validation: Validation Methods = FT, flight tested on NASA sounding rockets and Concorde, supersonic airliner (as detailed in Annex A, WP-599). Validation Details: Flight tests of the Iridium AES have indicated no impact on system operation of velocities in excess of 3000 knots.

Page 12 of 53


of 53

2.5 PERFORMANCE REQUIREMENTS

2.5.1 Designated Operational Coverage 2.5.1.1 Original Requirement(s): An AMS(R)S system shall provide AMS(R)S throughout its designated operational coverage. [AMS(R)S SARPs, 4.6.1.1]

Requirement Validation: Validation Methods = IA, Plotting on a map call records of voice and data traffic Validation Details: Iridium Satellite Network provides mobile communication with operational pole to pole coverage of the entire Earth. Based on observed traffic at extremely high northern and southern latitudes and oceanic and remote locations, Iridium can offer global coverage for AMS(R)S. Shown on the map below are actual locations (based on Iridium Geolocations provided in call detail records) of voice and data traffic over a one month (July 2006) period.


of 53

Page 14 of 53

July 2006 Voice and Data Call Locations


2.5.2 Failure Notification

2.5.2.1 Timely information on outages Original Requirement(s): In the event of a service failure, an AMS(R)S system shall provide timely predictions of the time, location and duration of any resultant outages until full service is restored. Note.— Service outages may, for example, be caused by the failure of a satellite, satellite spot beam, or GES. The geographic areas affected by such outages may be a function of the satellite orbit and system design, and may vary with time. [AMS(R)S SARPs, 4.6.2.1]

Requirement Validation: Validation Methods = IA and IB Validation Details: As an operational network serving subscribers all over the globe, the Iridium Satellite Network is being permanently monitored by its Network Operations Contractor, via the Gateway Operations and Management Centre, OMC. In addition to network monitoring, the OMC provides alarm notification.

In the event of a planned network outage due to maintenance, an unplanned outage due to a failed satellite, or an unplanned network outage, Iridium Satellite and the aviation satellite communications SP shall notify civil aviation authorities and air navigation service providers with timely network service impact information.

Currently, in the event of a satellite failure, Iridium Satellite issues system notifications which provide service outage and restoration information, and the aviation satellite communications SP provides information on the forecasted size and location of the service gap(s) and updates on service recovery.

The methods and processes in place provide adequate means for timely notification of the time, location and duration of network outages.

2.5.2.2 Failure notification within 30 seconds of detection Original Requirement(s): The system shall annunciate a loss of communications capability within 30 seconds of the time when it detects such a loss. [AMS(R)S SARPs, 4.6.2.2] Requirement Validation: Validation Methods = MN Validation Details: The Gateway Management System (GMS) manages the operations of the Iridium Satellite Gateway. The GMC consists of two Operations and Maintenance Centers. The

Page 15 of 53


OMC’s collect performance and usage statistics and provide fault management. The OMC’s are Unix platforms running HP Openview. Once a Gateway component, such as the Earth Terminal System (ETS), detects a fault condition it communicates the fault condition to the OMC via SNMP, ISDN, or X.25, as illustrated in the Iridium Network Fault Monitoring Diagram, shown below. Note: The SBD monitor and the OMC-R are separate monitors within the ops center, which are in addition to the OMC-G console. Each of the network sub-systems were tested to obtain the annunciation delay time, except for RUDICS. Testing of RUDICS fault annunciation would have an operational impact. A fault condition was created and the amount of time between the fault insertion and the fault annunciation was recorded. Each sub-system was exercised a number of times and the mean annunciation delay times listed in the table below:

Sub-System Time (sec) Fault Comments ET 2.4 Pedestal Disable ETS 8.2 E1 Disconnect NC 9.4 File System Full MOC 20.2 Link Down SBD 5.2 Cardiac Arrest/Misc D900 20.3 LTG RUDICS Not able to be tested As tested, the Iridium system detects and annunciates a loss of communications capability within 30 seconds.

Page 16 of 53


Iridium Network Fault Monitoring Diagram

2.5.3 AES Requirements Original Requirement(s): The AES shall meet the relevant performance requirements contained in 4.6.4 and 4.6.5 for aircraft in straight and level flight throughout the designated operational coverage of the satellite system. [AMS(R)S SARPs, 4.6.3.1] Recommendation.— The AES should meet the relevant performance requirements contained in 4.6.4 and 4.6.5 for aircraft attitudes of +20/-5 degrees of pitch and +/- 25 degrees of roll throughout the DOC of the satellite system. [AMS(R)S SARPs, 4.6.3.1.1]

Page 17 of 53


Requirement Validation: Validation Methods = Validation shall be provided in each sub-section of sections 2.5.4 and 2.5.5 for straight and level flight, FT (including F-16 and sounding rocket flights) for demonstration of functionality at the recommended pitch and roll attitudes Validation Details: The AES’s, which utilize the Iridium-provided L Band Transceiver (LBT), are capable of maintaining the link with the satellites at straight and level flight, as well as during high pitch and roll angle flight, throughout the global coverage area.

Each AES (SDU) uses an Iridium Satellite-provided LBT designed and built to Iridium Satellite specifications. This approach provides consistent linkage between the AES and the satellite constellation.

Iridium LBT’s have been installed on various aircraft, including high-performance fighter aircraft and sounding rockets.

Further validation of the ability of AES equipment to meet sections 4.6.4 and 4.6.5 of the SARP’s shall be demonstrated during acceptance testing.

There are four levels of acceptance testing required for the AES equipment

- Avionics Manufacturer system testing (lab, ground and flight test)

- Iridium Satellite testing

- Satellite Communications SP testing

- Aeronautical terrestrial network SP (e.g., ARINC and SITA) (Data only)

During the installation of the Iridium system aboard aircraft, it is usual practice to conduct both ground safety of flight testing and flight testing where the Iridium system is tested during higher than normal flight attitudes to insure the system functions properly while maintaining safety of flight.

Background

Flight Tests were conducted with an Iridium system installed on an F-16 and NASA sounding rockets. Test results demonstrated the Iridium system maintained service through a complete 360 degree roll, with voice dropping out when the airplane was flying upside down (180 degrees), plus or minus 60 degrees. Upon rolling out of the inverted position, the voice service was restored, without having to re-establish a new call.

Flight Tests were also conducted on a NASA sounding rocket which was flown in a nearly straight up (90 degrees) attitude, plus or minus 45 degrees. Test results demonstrated the Iridium SDU maintained service during the entire flight profile.

These two flight tests demonstrated the Iridium systems can provide service at extreme pitch and roll conditions.

Page 18 of 53


2.5.4 Packet Data Service Performance

2.5.4.1 Packet Data Service Performance Original Requirement(s): If the system provides AMS(R)S packet data service, it shall meet the standards of the following sub-paragraphs. Note. – System performance standards for packet data service may also be found in RTCA Document DO-270. [AMS(R)S SARPs, 4.6.4.1] 2.5.4.1.1 Sub-Network of the ATN An AMS(R)S system providing a packet-data service shall be capable of operating as a constituent mobile sub-network of the ATN. Note. – In addition, an AMS(R)S may provide non-ATN data functions.

[AMS(R)S SARPs, 4.6.4.1.1]

Requirement Validation: Validation Methods = A, MN Validation Details: The Iridium Sub-network is designed to operate as a constituent sub-network of the ATN. The Iridium sub-network coupled with the avionics, which are harmonized with the satellite communications SP ground processor provides

• encapsulation of messages to allow for seamless transport of character or bit oriented messages. ATN uses bit oriented protocol

• ICAO 24-bit address

The AMS(R)S SARPs require that an AMS(R)S system providing a packet-data service shall be capable of operating as a constituent mobile sub-network of the ATN. The role of the ATN is to define an environment within which reliable end-to-end data transfer may take place, spanning the airborne, air/ground and ground-based data subnetworks while providing interoperability among those networks. The Iridium Satellite Network supports the transparent transfer of data between adjacent internetwork entities. This includes the transparent transfer of global ATN addresses and quality of service information, as well as user data. The AMS(R)S subnetwork interface to an ATN router occurs within the ATN network layer, thus control information for the data link and physical layers is not passed from subnetwork to subnetwork. Hence, the subnetwork may utilize non-ATN conforming protocols within these layers while maintaining ATN protocol architecture conformance within the network layer. Whilst it is not strictly required to adopt a common standard subnetwork interface protocol for all air/ground subnetworks, it greatly simplifies the implementation and validation of the internetwork process since only a single communication software package is required to service the interface with the different air/ground subnetworks. The ISO 8208 packet level protocol has been adopted as the standard for this interface. A subnetwork interface protocol for

Page 19 of 53


an Iridium AMS(R)S has not yet been specified by ICAO. Thus, compliance of the Iridium Satellite Network with AMS(R)S SARPs requires the specification and development of an appropriate subnetwork interface protocol. [AMS(R)S SARPs 4.6.4.1.1]

The Iridium RUDICS and SBD data services are advantageous for different AMS(R)S applications. RUDICS offers the shortest call establishment time among all standard Iridium circuit-switch data services. SBD, though also based on circuit switch channels, offers a data transport service which has a number of characteristics very similar to a packet data call.

The following performance parameters are based on statistics accumulated over many years of Iridium Satellite Network operation. The chart in Figure 2-1 is based on measured SBD establishment delay data, both AES-to-Ground and Ground-to-AES. Figures 2-2 and 2-3 are based on measured RUDICS data, ground-to-AES and AES-to-Ground, respectively. The data were collected using auto-dialers. These charts show the data plotted over time (establishment delay) vs. percentages of total calls.

The Iridium data service RUDICS is based on circuit-switch mode. A data circuit is established and the channel stays up until the connection is torn down. The connection establishment time for a RUDICS call ranges from 10-14 sec. Once the circuit is established, the channel provides a reliable transport service of 2.4 kbps at a minimum, with a more typical throughput around 2.6 kbps.

Since the Iridium SBD service utilizes only the Access phase of the normal Iridium call establishment, it does not traverse the full path of the Iridium Gateway to the switch and hence has a shorter call establishment delay. SBD call can send data immediately as soon as the Acquisition process is completed, which on average is about 1.5 sec. Therefore, the average call establishment time is about 1.5 sec for AES-to-ground (MO) SBD and 3.6 sec for ground-to-AES (MT) SBD, assuming an average RING alert duration of 2.1 sec in a typical operating environment. Since SBD utilizes the signalling channel payload (with FEC protection) rather than the normal traffic channel payload, its average throughput is less than that of standard Iridium data services such as RUDICS and is around 1.2 kbps.

Since the Iridium Satellite Network provides AMS(R)S packet data service, it is expected to meet the delay and integrity requirements as demonstrated in the sub-paragraphs below. [AMS(R)S SARPs 4.6.4.1]

Page 20 of 53


Measured SBD Call Establishment Delay (G/A and A/G)

Figure 2-1

Measured RUDICS Ground to AES Call Establishment Delay

Figure 2-2

Page 21 of 53


Measured RUDICS AES to Ground Call Establishment Delay

Figure 2-3

2.5.4.1.2 Delay Parameters Note. – The term “highest priority service” denotes the priority which is reserved for distress, urgency, and certain infrequent network system management messages. The term “lowest priority service” denotes the priority used for regularity of flight messages. All delay parameters are under peak-hour traffic loading conditions. Within the Iridium network, aeronautical safety services is assigned AC-14 which is the highest acquisition class assigned outside of Iridium command and control. Aeronautical safety services provided using this acquisition class will meet or exceed measured results as shown in sub-paragraphs below which have been collected under normal and peak hour operating conditions.

2.5.4.1.2.1 Connection Establishment Delay Original Requirement(s): Connection establishment delay shall not be greater than 70 seconds [AMS(R)S SARPs, 4.6.4.1.2.1] 2.5.4.1.2.1.1 Recommendation – Connection establishment delay should not be greater than 50 seconds. [AMS(R)S SARPs, 4.6.4.1.2.1.1]

Page 22 of 53


Requirement Validation: Validation Methods = MN Validation Details: Based on accumulated Iridium satellite network performance statistics, the connection establishment delay of a RUDICS-based packet data call has been demonstrated to be less than 30 sec.; the connection establishment delay of a SBD-based packet data call has been demonstrated to be less than 9 sec. Refer to Figures 2-1, 2-2 and 2-3 for measured results. Measurements presented cover peak-hour traffic conditions.

2.5.4.1.2.2 Sub-network Service Data Unit (SNSDU) Original Requirement(s): In accordance with ISO 8348, data transit delay values shall be based on a fixed sub-network service data unit (SNSDU) length of 128 octets. Data transit delays shall be defined as average values. [AMS(R)S SARPs, 4.6.4.1.2.2]

2.5.4.1.2.3 Data Transit Delay, from-aircraft, highest priority Original Requirement(s): From-aircraft data transit delay shall not be greater than 40 seconds for the highest priority data service. [AMS(R)S SARPs, 4.6.4.1.2.3] 2.5.4.1.2.3.1 Recommendation. – Data transit delay, from-aircraft, highest priority. From-aircraft data transit delay should not be greater than 23 seconds for the highest priority data service. [AMS(R)S SARPs, 4.6.4.1.2.3.1]

2.5.4.1.2.3.2 Recommendation. – Data transit delay, from-aircraft, lowest priority. From-aircraft data transit delay should not be greater than 28 seconds for the lowest priority data service. [AMS(R)S SARPs, 4.6.4.1.2.3.2]

Requirement Validation: Validation Methods = A, MN Validation Details: With a sub-network service data unit (SNSDU) length of 128 octets, the Iridium satellite sub-network supports the following data transit delay values:

For RUDICS based packet data service, the data transit delay (average transfer delay) of a 128-byte payload has been demonstrated to be less than 1 sec. For SBD-based packet data service, the data transit delay of a 128-byte message has been demonstrated to be less than 3 sec., including call set-up time. Hence, the data transit delay of the highest

Page 23 of 53


priority packet has been demonstrated to meet this requirement regardless if it is from AES or GES (to the AES). Refer to Figures 2-4 and 2-5 which are measured results.

2.5.4.1.2.4 Data Transit Delay, to-aircraft, highest priority Original Requirement(s): To-aircraft data transit delay shall not be greater than 12 seconds for the highest priority data service. [AMS(R)S SARPs, 4.6.4.1.2.4] 2.5.4.1.2.4.1 Recommendation. – Data transit delay, to-aircraft, lowest priority. To-aircraft data transit delay should not be greater than 28 seconds for the lowest priority data service. [AMS(R)S SARPs, 4.6.4.1.2.4.1]

Requirement Validation: Validation Methods = A, MN Validation Details: With an SNSDU length of 128 octets, the Iridium satellite subnetwork supports the following data transit delay values:

For RUDICS based packet data service, the data transit delay (average transfer delay) of a 128-byte payload has been demonstrated to be less than 2 sec. For SBD-based packet data service, the data transit delay of a 128-byte message has been demonstrated to be less than 3 sec., including call set-up time. Hence, the data transit delay of the highest priority packet has been demonstrated to meet this requirement regardless if it is from AES or GES (to the AES). Refer to Figures 2-4 and 2-6 which are measured results.

Page 24 of 53


Measured SBD Data Transfer Delay (AES-to-Ground and Ground-to-AES)

Note: Transfer delay includes call set-up time of approximately 2 sec. Figure 2-4

Measured RUDICS Data Transfer Delay (AES-to-Ground)

Figure 2-5

Page 25 of 53


2.5.4.1.2.5 Data Transfer Delay ( 95th percentile), from-aircraft, highest priority Original Requirement(s): From-aircraft data transfer delay (95th percentile), shall not be greater than 80 seconds for the highest priority data service. [AMS(R)S SARPs, 4.6.4.1.2.5] 2.5.4.1.2.5.1 Recommendation. – Data transfer delay (95th percentile), from-aircraft, highest priority. From-aircraft data transfer delay (95th percentile) should not be greater than 40 seconds for the highest priority data service. [AMS(R)S SARPs, 4.6.4.1.2.5.1] 2.5.4.1.2.5.2 Recommendation. – Data transfer delay (95th percentile), from-aircraft, lowest priority. From-aircraft data transfer delay (95th percentile) should not be greater than 60 seconds for the lowest priority data service. [AMS(R)S SARPs, 4.6.4.1.2.5.2]

Requirement Validation: Validation Methods = A, MN Validation Details: Based on the earlier discussion and measured results, the 95th percentile transfer delay is demonstrated to be less than 15 seconds for the highest priority data service whether it is from-aircraft or to-aircraft.

The chart in Figure 2-4 is based on measured SBD establishment delay data, both AES-to-Ground and Ground-to-AES. Figure 2-5 is based on measured AES-to-Ground RUDICS data. The data were collected using auto-dialers. These charts show the data plotted over time (transfer delay) versus percentages of total calls.

[AMS(R)S SARPs, 4.6.4.1.2.5, 4.6.4.1.2.6]

2.5.4.1.2.6 Data Transfer Delay, 95th percentile, to-aircraft, highest priority Original Requirement(s): To-aircraft data transfer delay (95th percentile) shall not be greater than 15 seconds for the highest priority service. [AMS(R)S SARPs, 4.6.4.1.2.6] 2.5.4.1.2.6.1 Recommendation. – Data transfer delay (95th percentile), to aircraft, lowest priority. To-aircraft data transfer delay (95th percentile) should not be greater than 30 seconds for the lowest priority service. [AMS(R)S SARPs, 4.6.4.1.2.6.1]

Requirement Validation: Validation Methods = A, MN

Page 26 of 53


Validation Details: Based on the earlier discussion and the average data transfer delay value, therefore the 95th percentile data transfer delay is demonstrated to be less than 15 seconds for the highest priority data service whether it is from-aircraft or to-aircraft.

Refer to Figure 2-4 for SBD establishment delay data, both AES-to-Ground and Ground-to-AES. Figures 2-6 is based on measured Ground-to-AES RUDICS data. The data were collected using auto-dialers. These charts show the data plotted over time (transfer delay) vs. percentages of total calls.

[AMS(R)S SARPs, 4.6.4.1.2.5, 4.6.4.1.2.6]

Measured RUDICS Data Transfer Delay (Ground-to-AES)

Figure 2-6

2.5.4.1.2.7 – Connection Release Delay, 95th percentile Original Requirement(s): The connection release delay (95th percentile) shall not be greater than 30 seconds in either direction. [AMS(R)S SARPs, 4.6.4.1.2.7] 2.5.4.1.2.7.1 Recommendation. – The connection release delay (95th percentile) should not be greater than 25 seconds in either direction.

Page 27 of 53


[AMS(R)S SARPs, 4.6.4.1.2.7.1]

Requirement Validation: Validation Methods = A, MN Validation Details: Connection release delay for all calls has been demonstrated to be less than 2 sec. The chart in Figure 2-7 is based on measured SBD connection release delay times, both AES-to-Ground and Ground-to-AES. Figures 2-8 and 2-9 are based on measured RUDICS connection release delay times, Ground-to-AES and AES-to-Ground, respectively. The data were collected using auto-dialers. These charts show the data plotted over time (connection release delay) vs. percentages of total calls.

Measured SBD Connection Release Delay (AES-to-Ground and Ground-to-AES)

Figure 2-7

Page 28 of 53


Measured RUDICS Connection Release Delay (Ground-to-AES)

Figure 2-8

Measured RUDICS Connection Release Delay (AES-to-Ground)

Figure 2-9

Page 29 of 53


2.5.4.1.3 Integrity

2.5.4.1.3.1 Residual error rate, from-aircraft Original Requirement(s): The residual error rate in the from-aircraft direction shall not be greater than 10-4 per SNSDU. [AMS(R)S SARPs, 4.6.4.1.3.1] 2.5.4.1.3.1.1 Recommendation. – The residual error rate in the from-aircraft direction should not be greater than 10-6 per SNSDU. [AMS(R)S SARPs, 4.6.4.1.3.1.1] Requirement Validation: Validation Methods = A; IB; Reference Annex A, WP-599 Validation Details: Iridium’s data services employ the same error detection and error correction protocols to and from aircraft. The AMS(R)S SARPs specify packet data service integrity by residual error rate. It further defines residual error rate as the combination of the probabilities of undetected error, of undetected loss of a sub-network service data unit (SNSDU) and of an undetected duplicate SNSDU. Regarding probabilities of undetected loss and undetected duplicate, both the Iridium circuit switch data transport and the Iridium SBD protocol employ message sequence number and automatic repeat request (ARQ) retransmission at the Iridium protocol data unit (PDU) level. For SBD, message sequence number (MSN) is also applied at the SNSDU level. These mechanisms will ensure that the required probabilities for undetected loss and undetected duplicate of an SNSDU can be met. Probability of undetected error is the packet error rate. RUDICS employs a 24-bit frame check sequence, and the user payload field in an Iridium PDU is 248 bits. To transport a 128-byte data packet, it will take 5 Iridium PDUs. Analysis indicates the probability of a 128-byte data packet in error is about 3x10-7. Refer to Annex A, WP-599, Table 1, Acceptability Criteria Working Table, Ref. S, for analysis details for circuit-switched data.

The SBD service uses the Iridium signaling channel for data transport and is a guaranteed delivery service with multiple layers of error protection. It employs forward error control in the form of BCH coding in addition to selective ARQ. By design, the SBD data transport has a better packet error rate performance than the circuit switch data transport.

Page 30 of 53


Calculation of the residual error rate for SBD requires understanding the special message delivery protocol employed by SBD, which is separate than that used for circuit-switched data calls. This protocol results in each Iridium TDMA burst consisting of 160 SBD information bits, 20 SBD header bits and 234 other overhead bits. These 160 information bits are protected by a BCH(31,20) FEC code. This error correction coded data is then protected by a 16-bit CRC error detection code that is used in conjunction with a selective ARQ process. The word error performance of a double-error correcting BCH(31,20) code is found as:

, (Eq. 1) ( ) inb

ib

n

tiw pp

in

P −

+=

−⎟⎟⎠

⎞⎜⎜⎝

⎛= ∑ 1

1

where Pw is the word error probability, t is the error correcting capability of the code (=2), n is the code word length (=31) and pb is the channel bit error probability. For the minimum Iridium channel bit error rate specification of 10-2, substituting in the above values yields Pw = 3.65x10-3. At the output of the BCH decoding process, there are ten, 20-bit words (one header word, eight data words and one CRC word) that make up one SBD PDU being fed to the CRC-16 decoding process. The probability that none of these ten, 20-bit words has an error in it is found as

( )NwC PP −= 1 , (Eq. 2)

where N is the total number of words being fed into the CRC-16 decoder and in this case is 208. Using this and the value of Pw above, we find PC = 0.964 CRC-16 error detection codes have well-known capabilities, which include the ability to detect all single and double bit error combinations (as well as other combinations). Assuming there are errors, the probability of the CRC-16 code failing to detect these errors is given as 2-16. An upper bound for estimating the probability of an undetected SBD PDU error would then be the product of the probability that there is still at least one error at the output of the BCH error decoding process (1 – PC) and the probability that these uncorrected errors are also undetected by the CRC-16 decoder:

( )CSBD PP −≤ − 12 16 . (Eq. 3) After substituting the value for PC above, the probability of an undetected SBD PDU, PSBD, is found as 5.47x10-7. It should be noted that this is an upper bound since:

• The (1 – PC) factor includes single and double bit error combinations which the CRC-16 decoding process will detect, and

• The above analysis is calculated at receiver threshold (i.e., none of the Iridium 16 dB link margin is available).

The above value for PSBD is valid for both the aircraft transmit and receive directions. This analysis demonstrates that Iridium AMS(R)S packet data can provide a residual error rate no greater than 10-6 per SNSDU, whether it is from-aircraft or to-aircraft.

Page 31 of 53


2.5.4.1.3.2 Residual error rate, to-aircraft Original Requirement(s): The residual error rate in the to-aircraft direction shall not be greater than 10-6 per SNSDU. [AMS(R)S SARPs, 4.6.4.1.3.2] Requirement Validation: Validation Methods = A; IB; Reference Annex A, WP-599 Validation Details: The analysis in the previous section 2.5.4.1.3.1 demonstrates that Iridium AMS(R)S packet data meets this requirement and can provide a residual error rate no greater than 10-6 per SNSDU, whether it is from-aircraft or to-aircraft.

2.5.4.1.3.3 Connection resilience Original Requirement(s): The probability of a subnetwork connection (SNC) provider-invoked SNC release shall not be greater than 10-4 over any one-hour interval. Note. – Connection releases resulting from GES-to-GES handover, AES log-off or virtual circuit preemption are excluded from this specification. [AMS(R)S SARPs, 4.6.4.1.3.3] Requirement Validation: Validation Methods = A Validation Details: An ACARS air/ground subnetwork does not support priority distinctions among messages. However, external entities (e.g., an ACARS MU having multiple data input/output ports) can arrange the precedence of messages presented to the air/ground subnetwork for transmission, in accordance with the implied priority level associated with each port. Such an arrangement is incorporated in the architecture of FANS-1/A applications. FANS 1/A data links implement the mechanisms described above and have additional features to support certain ATS applications. The environment application interfaces support most ATN-compliant applications by emulating the ISO 8072 Transport Service. The application interface, in effect, provides a convergence function between the connection-oriented ISO 8072 Transport Service Interface and the connectionless ACARS protocol beneath it. Support of operational messages such as those specified for FANS 1/A datalink are expected to be transmitted by SBD which employs a connection-less protocol over the air-to-ground link. Connection resilience, therefore, is not applicable.

Page 32 of 53


Support of larger messages may use the RUDICS service which may employ a connection-oriented protocol over the air-to-ground link. Given a circuit-switched end-to-end dropped call rate of 0.33%, the vast majority of those dropped calls are due to RF related issues. Therefore, it is expected that the remaining gateway dropped calls are no greater than 10-4. Iridium connection resilience tests were conducted using auto-dialers that placed continuously running, 45-second calls. Dropped call statistics were collected on a daily basis for one year. Note: The application interface is referred to as “field application” within the Technical and Implementation Manual. 2.5.4.1.3.4 SNC provider-invoked reset Original Requirement(s): The probability of an SNC provider-invoked reset shall not be greater than 10-1 over any one-hour interval. [AMS(R)S SARPs, 4.6.4.1.3.4]

Requirement Validation: Validation Methods = N/A Validation Details: Iridium does not invoke resets of any kind to terminal equipment. This requirement does not apply.

2.5.5 Voice Service Performance 2.5.5.1 Voice Service Performance Original Requirement(s): If the system provides AMS(R)S voice service, it shall meet the requirements of the following sub-paragraphs. [AMS(R)S SARPs, 4.6.5.1] Note. – ICAO is currently considering these provisions in light of the introduction of new technologies. Requirement Validation: Validation Methods = per each sub-paragraph’s requirement validation Validation Details: Validation will be on a per sub-paragraph basis

Page 33 of 53


2.5.5.1.1 Call processing delay

2.5.5.1.1.1 AES origination Original Requirement(s): The 95th percentile of the time delay for a GES to present a call origination event to the terrestrial network interworking interface after a call origination event has arrived at the AES interface shall not be greater than 20 seconds. [AMS(R)S SARPs, 4.6.5.1.1.1] Requirement Validation: Validation Methods = A, MN Validation Details: Based on Iridium satellite network operational experience and performance statistics, most mobile-originated and mobile-terminated voice calls take 12 sec and 14 sec to set up, respectively. The chart in Figure 2-10 is based on measured AES-to-Ground call establishment delay data. The data was collected using auto-dialers. This chart shows the data plotted over time (transfer delay) vs. percentages of total calls. For Iridium AMS(R)S, the 95th percentile of the time delay for a GES to present a call origination event to the terrestrial network interworking interface after a call origination event has arrived at the AES has been demonstrated to be less than 20 seconds. [AMS(R)S SARPs, 4.6.5.1.1.1]

Measured Voice Call Establishment Delay (AES-to-Ground)

Figure 2-10

Page 34 of 53


2.5.5.1.1.2 GES origination Original Requirement(s): The 95th percentile of the time delay for an AES to present a call origination event at its aircraft interface after a call origination event has arrived at the terrestrial network interworking interface shall not be greater than 20 seconds. [AMS(R)S SARPs, 4.6.5.1.1.2]

Requirement Validation: Validation Methods = MN Validation Details: Based on Iridium satellite network operational experience and performance statistics, most mobile-originated and mobile-terminated voice calls take 12 sec and 14 sec to set up, respectively.

For Iridium AMS(R)S, the 95th percentile of the time delay for an AES to present a call origination event at its aircraft interface after a call origination event has arrived at the terrestrial network interworking interface is demonstrated to be less than 20 seconds. [AMS(R)S SARPs, 4.6.5.1.1.2]

Measurement of GES originated call establishment delay without going through the public switched telephone network (PSTN) presents a challenge. Therefore, an alternative measurement method has been conducted. First, call establishment delay statistics were collected for mobile-to-mobile calls within the Iridium network. These measurements include call origination and call termination establishment delays, but do not consist of any PSTN delays, since mobile-to-mobile calls take place completely within the Iridium network. Next, delay data was collected for mobile originated calls that were terminated at an automated call termination function at the back end of the Iridium switch. These delay measurements include call origination delay and, again, do not consist of any PSTN delay, since the call is originated and terminated within the Iridium network. The resulting GES origination delay to the AES terminal can then be calculated as the mobile-to-mobile call establishment delay, minus the mobile-to-switch establishment delay.

The chart in Figure 2-11 is based on measured Ground-to-AES call establishment delay data. The data was collected using auto-dialers. The 95th percentile delay was 18.3 seconds.

Page 35 of 53


Measured Voice Call Establishment Delay (Ground-to-AES)

Figure 2-11

2.5.5.1.2 Voice Quality

2.5.5.1.2.1 Overall intelligibility Original Requirement(s): The voice transmission shall provide overall intelligibility performance suitable for the intended operational and ambient noise environment. [AMS(R)S SARPs, 4.6.5.1.2.1]

Requirement Validation: Validation Methods = FT, MN Validation Details: The ISLLC test plan includes voice quality testing, including mean opinion scoring. The test plans of satellite communications SPs are expected to include voice quality testing for any unique aircraft configurations not covered by ISLLC testing.

The Iridium SDU incorporates a 2.4 kbps Advanced Multi-Band Excitation (AMBE) vocoder developed by Digital Voice System Inc. (DVSI). This vocoder is tailored to the

Page 36 of 53


Iridium communication channel and provides good quality audio performance with a nominal Mean Opinion Score (MOS) of 3.5 under typical non-aeronautical operating and channel conditions.

As Iridium terminals have been installed and successfully operated on various types of aircrafts including helicopters, the Iridium system has been demonstrated to meet requirements for overall intelligibility.

2.5.5.1.2.2 Transfer delay Original Requirement(s): The total allowable transfer delay within an AMS(R)S subnetwork shall not be greater than 0.485 second. [AMS(R)S SARPs, 4.6.5.1.2.2] Requirement Validation: Validation Methods = IB; Reference Annex A, WP-599 Validation Details: For the Iridium AMS(R)S voice service, a total voice call transfer delay within the AMS(R)S subnetwork of no greater than 0.375 second has been calculated. Refer to Annex A, WP-599, Table 1, Ref R.

2.5.5.1.2.3 Other effects on voice quality Recommendation. – Due account should be taken of the effects of tandem vocoders and/or other analog/digital conversions. [AMS(R)S SARPs, 4.6.5.1.2.3] Requirement Validation: Validation Methods = No Validation Required Validation Details: Testing and analysis cannot take into account all permutations of possible terminating equipment configurations. As the Iridium network is deployed operationally these issues must be addressed on an "as encountered" basis.

2.5.5.1.3 Voice Capacity 2.5.5.1.3.1 Voice capacity Original Requirement(s): The system shall have sufficient available voice traffic channel resources such that an AES- or GES-originated AMS(R)S voice call presented to the system shall experience a probability of blockage of no more than 10-2. Note. – Available voice traffic channel resources include all pre-emptable resources, including those in use by non-AMS(R)S communications. [AMS(R)S SARPs, 4.6.5.1.3.1]

Page 37 of 53


Requirement Validation: Validation Methods = A Validation Details: Based on the Communications Operating Concept and Requirements (COCR Study) for the Future Radio System, version 1.0, commissioned by the FAA and EuroControl, it is expected that Iridium AMS(R)S will have sufficient available voice traffic channel resources for oceanic and remote operations for both Phase 1 and 2 (projected out past the year 2025) such that an AES- or GES-originated AMS(R)S voice call presented to the system shall experience a probability of blockage of no more than 10-2.

Tables 6-17 and 6-18 of the COCR study provide Phase 1 and Phase 2 summaries of voice capacity requirements for four different service areas: airport (APT), terminal maneuvering area (TMA), en route (ENR) and oceanic, remote, polar (ORP). Included in these tables is the time to traverse a given service area. If an aircraft speed is assumed (250 knots for aircraft in the APT and TMA areas and 650 knots for the ENR and ORP areas), then an estimate of service area diameter can be found. This service area size can then be compared with the coverage area of an Iridium spot beam. Since the number of supported traffic channels within an Iridium spot beam is known, a determination can be made of whether the required voice traffic capacities can be met by Iridium.

APT TMA ENR ORP HD LD HD LD HD LD HD LD

Flight duration through service area (sec)1

870 450 334 519 675 900 2550 2550

Service area diameter (nmi)2

N/A N/A N/A N/A 122 163 460 460

Approximate no. of service areas within Iridium spot beam3

10 10 10 10 3 2 1 1

Traffic per service area (ccs/hr)4

94.63 22.18 23.02 12.94 34.93 15.33 .34 .17

Traffic per Iridium spot beam (ccs/hr)

947 222 230 130 105 31 0.34 0.17

Number of circuits required to meet traffic load, for GOS = 1%5

37 13 13 9 8 4 1 1

Table 2-2: Voice Capacity Requirements Notes:

1. Flight duration obtained directly from Table 6-17 of the COCR report. 2. For ENR and ORP regions, the service area size was calculated by multiplying average aircraft speed of 650 knots by flight duration. For the APT and TMA regions, service area cannot be found from flight duration, since aircraft are on ground.

Page 38 of 53


3. For ENR and ORP regions, the number of service areas per spot beam was found by dividing the area of a 216 nmi (400 km) diameter spot beam by the service area. For APT and TMA regions, an extreme limit of 10 such airports per spot beam was assigned. 4. The traffic data was obtained directly from call-second data from Table 6-17 of the COCR report, and divided by 100 to get cent-call-seconds (ccs). 5. The number of circuits was obtained from Erlang B tables, which provide the number of circuits needed to support a given traffic loading at a given grade-of-service (GOS). The SARPs have defined GOS = 1%.

The data provided in Table 2-2 is derived from Phase 1 capacity requirements from the COCR report. The Phase 2 requirements are actually less stringent than for Phase 1, so a capacity analysis using Phase 2 requirements is not necessary. Iridium currently uses 184 duplex frequency channels, with 4 user timeslots per channel, for a total of 736 circuits available across the system. Iridium’s capacity capabilities are well above the resulting number of required circuits as indicated in Table 2-2.

2.5.6 Security

2.5.6.1 Protection of Messages Original Requirement(s): The system shall provide features for the protection of messages in transit from tampering. [AMS(R)S SARPs, 4.6.6.1]

Requirement Validation: Validation Methods = A Validation Details: The Iridium Satellite Network, being an operational satellite service, employs various security measures against external attack and tampering. Iridium Channel Security The complexity of the Iridium network air interface makes message interception or tampering very difficult: To successfully monitor an L-band channel, an eavesdropper must be located within the transmit range of the SDU being monitored, approximately 10 to 30 km from the transmitting SDU in a ground-use scenario and approximately 250 to 350 km from an AES in flight. SDU downlink L-Band transmissions could be received over a much wider area. A single satellite beam covers an area of about 400 km in diameter. Air Interface The complexity of the Iridium air interface would make the challenge of developing an Iridium L-Band monitoring device very difficult. Among the complications are:

Page 39 of 53


• Iridium’s air interface is proprietary • Large, continually changing Doppler shifts • Frequent inter-beam and inter-satellite handoffs • Time-division multiplexed burst mode channels • Complicated modulation, interleaving and coding

Feederlink Interface A sophisticated monitoring device would be needed in the general proximity of an Iridium gateway to receive the feederlink channel. The complexity of the feederlink interface poses a formidable technical challenge for prospective eavesdroppers. Among the technical complications are:

• Large, continually changing Doppler shifts • High capacity, ~3 Mbps channels • High-gain tracking antenna required • Must reacquire new satellite every 10 minutes

Fraud Protection Fraud Protection is provided during the Access process. During this process, the gateway determines if the requesting SDU is providing its own geographical location. If true, the system requests a check of the geographical location provided by the requesting SDU with the Beam ID the SDU is using. If the beam coverage location associated with the Beam ID does not match with the SDU-provided location, the system sets a fraud flag. The system then sends the SDU the “Access Decision Notification” message with the indicator set to “access denied” and service is denied, with the exception of emergency calls. The Iridium authentication process is adapted without change directly from GSM specifications. The security measures employed by the Iridium Satellite Network are designed to provide a high level of protection of messages in transit from tampering. [AMS(R)S SARPs, 4.6.6.1] Note: There is nothing to prevent encryption at the field application level.

2.5.6.2 Protection Against External Attacks on Service Original Requirement(s): The system shall provide features for protection against denial of service, degraded performance characteristics, or reduction of system capacity when subjected to external attacks. Note.— Possible methods of such attack include intentional flooding with spurious messages, intentional corruption of system software or databases, or physical destruction of the support infrastructure. [AMS(R)S SARPs, 4.6.6.2]

Page 40 of 53


Requirement Validation: Validation Methods = A Validation Details: Refer to section 2.5.6.1 for additional measures for protection against external attacks. Beyond the Iridium authentication process, access to the Iridium network would be extremely difficult as outlined below. Physical Security The Iridium Gateway(s), its Master Control Facility, and its Telemetry, Tracking And Control stations are all secured facilities providing protection against unauthorized entry. These security aspects of the Iridium Satellite Network provide the same level of protection against certain types of denial of service, such as intentional flooding of traffic, as currently implemented in the GSM. The Iridium system has security measures in place at its gateways and facilities, as well as built-in protections in its air interface and authentication process that are designed to provide protection against external attacks on service. Note: Additional security measures are provided through the aviation centric networks (e.g., ARINC and SITA) which are outside the scope of this report.

2.5.6.3 Protection Against Unauthorized Entry Original Requirement(s): The system shall provide features for protection against unauthorized entry. Note. – These features are intended to provide protection against spoofing and “phantom controllers”. [AMS(R)S SARPs, 4.6.6.3]

Requirement Validation: Validation Methods = IB Validation Details: In order to safeguard the Iridium Satellite network, command and control of access to the Iridium constellation is limited to the Iridium Satellite Network Operations Centre (SNOC) and the Iridium Technical Support Centre (TSC), which access and load the constellation control software. Secure access is provided at the SNOC and TSC including 7x24 guards (SNOC only) with multiple-door badge access restrictions and password-protected Mission LAN access; firewalled connections also are in place to protect against unauthorized access.

Page 41 of 53


Outside of these sites, malicious corrupt software loading would require Iridium-specific tracking and command/control (TTAC) and Mission LAN hardware and software, which are not readily available. This equipment and software are rare and would be extremely difficult to obtain and properly configure to access the constellation. Additionally, the probability of unauthorized personnel being able to cause permanent damage to a satellite by uploading malicious software is mitigated due to the following factors: 1. Unauthorized personnel would need access to detailed information about software

product upload directories, command and verification formats, etc., that are specified in detailed procedures and checklists. Without this information, malicious software would not be accepted by the satellite.

2. The satellite commanding requirements are so esoteric that extensive training and

practice is required before an upload can be successfully performed. 3. The satellite itself has multiple computers, so that any malicious software would have

to be loaded to multiple satellite computers successfully in order to do any permanent damage.

The Iridium satellite network has measures in place that are designed to provide high levels of protection at the physical and network levels.

2.6 SYSTEM INTERFACES

2.6.1 ICAO 24-Bit Aircraft Address Original Requirement(s): An AMS(R)S system shall allow subnetwork users to address AMS(R)S communications to specific aircraft by means of the ICAO 24-bit aircraft address. Note. – Provisions on the allocation and assignment of ICAO 24-bit addresses are contained in Annex 10, Volume III, Appendix to Chapter 9. [AMS(R)S SARPs, 4.7.1] Requirement Validation: Validation Methods = A, UT, IT Validation Details: The aircraft SDU needs to be mapped to corresponding ICAO address(es) within the ground- based satellite communications SP processor. This is accomplished outside the Iridium sub-network. This mapping is initiated during the log-on stage, or hand-shake between the SDU and the ground based satellite communications SP processor.

During the FAA/ARINC CPDLC trials conducted in Miami, Florida, the service processor handling the traffic between the aeronautical (air-ground) and the terrestrial

Page 42 of 53


(ground-ground) networks did not support the implementation of addressing via the 24-bit ICAO address. The off-line service processor, set up in the FAA Technical centre currently does not support this addressing capability. Without having such a service processor in place, testing of this capability cannot take place.

Iridium commits to supporting this feature when the ATN network is deployed with this feature.

Both satellite communications SPs and terrestrial network SPs require that aircraft avionics are tested in accordance to their test plans prior to gaining access to their networks.

2.6.2 Packet Data Service Interfaces

2.6.2.1 ATN interface Original Requirement(s): If the system provides AMS(R)S packet data service, it shall provide an interface to the ATN. Note. – The detailed technical specification related to provisions of ATN-compliant sub-network service are contained in Section 5.2.5 and Section 5.7.2 of Doc 9705 – Manual of Technical Provisions for the Aeronautical Telecommunication Network. [AMS(R)S SARPs, 4.7.2.1]

Requirement Validation: Validation Methods = A Validation Details: The AMS(R)S SARPs require that an AMS(R)S system providing a packet-data service shall be capable of operating as a constituent mobile sub-network of the ATN. The Iridium Satellite Network supports the transparent transfer of data between adjacent internetwork entities. This includes the transparent transfer of global ATN addresses and quality of service information, as well as user data. A subnetwork interface protocol for an Iridium AMS(R)S has not yet been specified by ICAO. Thus, compliance of the Iridium Satellite Network with AMS(R)S SARPs requires the specification and development of an appropriate subnetwork interface protocol.

Iridium will work with its AMS(R)S service providers and AES manufacturers to ensure that the Iridium AMS(R)S system will allow subnetwork users to address AMS(R)S communications to specific aircraft by means of the ICAO 24-bit aircraft address. [AMS(R)S SARPs, 4.7.1] and will provide an interface to the ATN as well as a connectivity notification (CN) function. [AMS(R)S SARPs, 4.7.2.1, 4.7.2.2]

Aircraft avionics shall be tested in accordance with satellite communications SP test plan for avionics prior to approval and certification as a qualified safety services system for packet data services.

Page 43 of 53


2.6.2.2 Connectivity notification Original Requirement(s): If the system provides AMS(R)S packet data service, it shall provide a connectivity notification (CN) function. [AMS(R)S SARPs, 4.7.2.2]

Requirement Validation: Validation Methods = A Validation Details: The AMS(R)S SARPs require that an AMS(R)S system providing a packet-data service shall be capable of operating as a constituent mobile sub-network of the ATN. The Iridium Satellite Network supports the transparent transfer of data between adjacent internetwork entities. This includes the transparent transfer of global ATN addresses and quality of service information, as well as user data. A subnetwork interface protocol for an Iridium AMS(R)S has not yet been specified by ICAO. Thus, compliance of the Iridium Satellite Network with AMS(R)S SARPs requires the specification and development of an appropriate subnetwork interface protocol.

Iridium will work with its AMS(R)S service providers and AES manufacturers to ensure that the Iridium AMS(R)S system will allow subnetwork users to address AMS(R)S communications to specific aircraft by means of the ICAO 24-bit aircraft address. [AMS(R)S SARPs, 4.7.1] and will provide an interface to the ATN as well as a connectivity notification (CN) function. [AMS(R)S SARPs, 4.7.2.1, 4.7.2.2]

Aircraft avionics shall be tested in accordance with satellite communications SP test plans for avionics prior to approval and certification as a qualified safety services system for packet data services.

Page 44 of 53


Table 2-3 Iridium AMS(R)S System Parameters per ICAO AMS(R)S SARPs AMS(R)S

SARPs Reference

AMS(R)S SARP Contents

Iridium Subnetwork

Value1

Additional Comments on Performance

4.2 General N/A Placeholder 4.2.1 AMS(R)S shall conform to

ICAO Chapter 4 Yes -

4.2.1.1 Support packet data, voice, or both

Yes; Both

By design.

4.2.2 Mandatory equipage N/A for service provider

-

4.2.3 2 year's notice N/A for service provider

-

4.2.4 Recommendation consider worldwide implementation

N/A for service provider

-

4.3 RF Characteristics N/A Placeholder 4.3.1 Frequency Bands N/A Placeholder

4.3.1.1 Only in frequency bands allocated to AMS(R)S and protected by ITU RR

Yes; 1616-1626.5

MHz

-

4.3.2 Emissions N/A Placeholder 4.3.2.1 Limit emissions to control

harmful interference on same aircraft

Yes Analysis, unit testing, and aircraft installation testing Reference DO-294A

4.3.2.2 Shall not cause harmful interference to AMS(R)S on other aircraft

N/A Placeholder

4.3.2.2.1 Emissions shall not cause harmful interference to an AES providing AMS(R)S on a different airplane

Yes Analysis, unit testing, and aircraft installation testing Reference DO-262 and DO-294A

4.3.3 Susceptibility N/A Placeholder 4.3.3.1 Shall operate properly in

cumulative ΔT/T of 25% Yes Analysis and LBT design

4.4 Priority and Pre-emptive Access

N/A Placeholder

4.4.1 Priority and pre-emptive access

Yes Avionics compliance with RTCA DO-262 and Iridium network support of PPP

4.4.2 All AMS(R)S packets and voice calls shall be identified by priority


4.4.3 Within the same msg category, voice has priority over data


4.5 Signal Acquisition and Tracking

N/A Placeholder

4.5.1 Properly track signal for A/C at 800 kt. along any heading

Yes Verified by operational experience.

4.5.1.1 Recommendation for 1500 kts.

Yes Verified by flight test.

1 Iridium supplied values.

Page 45 of 53


AMS(R)S SARPs

Reference


Iridium Subnetwork

Value1


4.5.2 Properly track with 0.6 g acceleration in plane of orbit

Yes Verified by flight test.

4.5.2.1 Recommendation 1.2 g Yes Verified by flight test. 4.6 Performance Requirements N/A Placeholder

4.6.1 Designated Operational Coverage

N/A Placeholder

4.6.1.1 Provide AMS(R)S throughout Designated Operational Coverage

Yes Verified by operational experience.

4.6.2 Failure Notification N/A Placeholder 4.6.2.1 Provide timely predictions

of service failure-induced outages

Yes Currently provides

4.6.2.2 System failure annunciation within 30s

Yes Verified by sub-system testing

4.6.3 AES Requirements Placeholder 4.6.3.1 Meet performance in

straight and level flight Yes Supports flight envelope throughout DOC.

Compliance of 4.6.4 and 4.6.5 are provided in their respective sub-sections

4.6.3.1.1 Recommendation for +20/-5 pitch ant +/-25 roll

Yes Supports flight envelope throughout DOC. Compliance of 4.6.4 and 4.6.5 are provided in their respective sub-sections

4.6.4 Pkt Data Svc Performance N/A Placeholder 4.6.4.1 Requirements on AMS(R)S

packet data Yes See sub-sections.

4.6.4.1.1 Capable of mobile subnetwork in ATN

Yes Sub-network supports character and bit oriented protocols in support end-to-end system

4.6.4.1.2 Delay Parameters N/A Placeholder 4.6.4.1.2.1 Connection establishment

delay < 70 seconds Yes

< 30s RUDICS < 9s SBD

Iridium subnetwork performance verified by Auto-dialer data. Sub-network CDF 95%ile values charted in support of validation process

4.6.4.1.2.1.1 Recommendation Connection establishment delay < 50 seconds

Yes < 15s RUDICS

< 9s SBD

Iridium subnetwork performance verified by Auto-dialer data. Sub-network CDF 95%ile values charted in support of validation process

4.6.4.1.2.2 Transit delay based on SNSDU of 128 octets and defined as average values

Yes <1s RUDICS

<3s SBD

Iridium subnetwork performance verified by Auto-dialer data. Sub-network averaged values in support of validation process

4.6.4.1.2.3 From A/C highest priority < 40 seconds

Yes <1s RUDICS

<3s SBD


4.6.4.1.2.3.1 Recommendation from A/C highest priority < 23 seconds

Yes <1s RUDICS

<3s SBD


4.6.4.1.2.3.2 Recommendation from A/C lowest priority < 28 seconds

Yes <1s RUDICS

<3s SBD


4.6.4.1.2.4 To A/C high priority < 12 seconds

Yes <2s RUDICS

<3s SBD


Page 46 of 53


AMS(R)S SARPs

Reference


Iridium Subnetwork

Value1


4.6.4.1.2.4.1 Recommendation To A/C lowest priority < 28 seconds

Yes <2s RUDICS

<3s SBD


4.6.4.1.2.5 From A/C Data transfer delay 95%ile highest priority < 80 seconds

Yes <2s RUDICS

<6s SBD

Iridium subnetwork performance verified by current performance data. Sub-network CDF 95%ile values charted using auto-dialer data collected in support of validation process

4.6.4.1.2.5.1 Recommendation From A/C Data transfer delay 95%ile highest priority < 40 seconds

Yes <2s RUDICS

<6s SBD


4.6.4.1.2.5.2 Recommendation From A/C Data transfer delay 95%ile lowest priority < 60 seconds

Yes <2s RUDICS

<6s SBD


4.6.4.1.2.6 To A/C Data transfer delay 95%ile high priority < 15 seconds

Yes <2s RUDICS

<6s SBD


4.6.4.1.2.6.1 Recommendation To A/C Data transfer delay 95%ile low priority < 30 seconds

Yes <2s RUDICS

<1s SBD


4.6.4.1.2.7 Connection release time 95%ile < 30 seconds

Yes <2s RUDICS

<6s SBD


4.6.4.1.2.7.1 Recommendation connection release time 95%ile < 25 seconds

Yes <2s RUDICS

<6s SBD


4.6.4.1.3 Integrity N/A Placeholder 4.6.4.1.3.1 Residual error rate from

A/C < 10-4/SNSDU < 10-6 Verified by current performance data. (M)

4.6.4.1.3.1.1 Recommend RER from A/C < 10-6/SNSDU

< 10-6 Verified by current performance data. (M)

4.6.4.1.3.2 RER to A/C < 10-6 /SNSDU < 10-6 Verified by current performance data. 4.6.4.1.3.3 Pr{SNC provider invoked

release}< 10-4/hr SBD-N/A

RUDICS< 10-

4/hr

SBD is connectionless protocol for FANS1/A datalink and does not apply

4.6.4.1.3.4 Pr{SNC provider invoked reset}< 10-1/hr

NA Not applicable to Iridium Network

4.6.5 Voice Service Performance N/A Placeholder 4.6.5.1 Requirements for AMS(R)S

voice service Yes See sub-paragraphs for compliance

4.6.5.1.1 Call Delay Processing N/A Placeholder 4.6.5.1.1.1 AES call origination delay

95%ile < 20 seconds <16s Iridium subnetwork performance verified by

current performance data. CDF statistics provided for 95%ile value verification.

4.6.5.1.1.2 GES call origination delay 95%ile < 20 seconds

< 19s Iridium subnetwork performance verified by current performance data. CDF statistics provided for 95%ile value verification.

Page 47 of 53


AMS(R)S SARPs

Reference


Iridium Subnetwork

Value1


4.6.5.1.2 Voice Quality N/A Placeholder 4.6.5.1.2.1 Voice intelligibility suitable

for intended operational and ambient noise environment

Yes To be verified by AES manufacturer.

4.6.5.1.2.2 Total allowable transfer delay within AMS(R)S subnetwork < 0.485 second

< 0.375s Verified by current performance data.

4.6.5.1.2.3 Recommendation to consider effects of tandem vocoders

- Recommendation to take into account effects of tandem vocoders and other analog/digital conversions must be taken on a “as encountered” basis. Testing and analysis cannot take into account all permutations

4.6.5.1.3 Voice Capacity N/A Placeholder 4.6.5.1.3.1 Sufficient voice traffic

channel resources for Pr{blockage < 0.01} for AES or GES originated calls

< 0.01 Analysis provided for all regions based on FAA/EuroControl COCR study, Ver 1.0

4.6.6 Security N/A Placeholder 4.6.6.1 Protect messages from

tampering Yes -

4.6.6.2 Protect against denial of service, degradation, or reduction of capacity due to external attacks

Yes -

4.6.6.3 Protect against unauthorized entry

Yes -

4.7 System Interfaces N/A Placeholder 4.7.1 Address AMS(R)S by

means of 24 bit ICAO address

Yes By design.

4.7.2 Pkt Data Svc Interfaces N/A Placeholder 4.7.2.1 If the system provides

packet data service, it shall provide an interface to the ATN

Yes By design.

4.7.2.2 If the system provides packet data service, it shall provide an CN function

Yes By design.

Page 48 of 53


3. AUTO-DIALER SET UP DESCRIPTION Service quality is measured through the use of a number of devices, which are referred to as auto-dialers. These auto-dialers are deployed around the world and are configured to automatically place calls through the Iridium network. As each call is dialed, the system starts a timer, as the call process proceeds and the call is established the connection time is stopped and the total time to connect is recorded. If the call is dropped prematurely, the premature call is recorded, as well the recording of properly terminated calls. Test cycles cover peak-hour traffic conditions.

3.1 AES Terminated Voice Call Test Description For ground originated (or AES terminated, MT) voice calls to the AES, the auto-dialer is set up to place calls via modem over the Iridium network to an Iridium handset also connected to the auto-dialer computer. The auto-dialer is configured to pick up the call on the first detected ring. The Auto-dialer executes a script to place a call and to record call sequence timing from the computer and the telephone handset, via the digital peripheral link (DPL). The Auto-dialer collects the call sequence timing from the point at which the call is initiated, answered and hung up, based on the test set up configuration, Figure 3-1, shown below:

AES Terminated Voice Call Testing Configuration

Figure 3-1

Page 49 of 53


3.2 AES Originated Voice Call Test Description For AES originated (or mobile originated, MO) voice calls, the auto-dialer is set up to an Iridium telephone handset to place calls through the Iridium network to a telephone answering machine. The answering machine is configured to pick up the call on the first detected ring. The Auto-dialer executes a script to place a call and to record call sequence timing from the computer and the telephone handset, via the digital peripheral link (DPL). The Auto-dialer collects the call sequence timing from the point at which the call is initiated, answered by the answering machine and hung up, based on the test set up configuration, Figure 3-2, shown below:

AES Originated Voice Call Testing Configuration

Figure 3-2

3.3 SBD Data Call Test Description There are two scenarios for testing SBD data exchanges, AES to ground (MO), and ground to AES (MT). In both scenarios the auto-dialer is connected to an L band Transceiver (LBT) and to the SBD sub-system server via the gateway intranet. Both SBD transfers utilize the access channel for transfer of data.

Page 50 of 53


The Auto-dialer executes a script to send the data and to record transfer sequence timing from end to end from the AES (LBT) to the SBD sub-system and from the SBD sub-system server to the AES (LBT). The Auto-dialer collects the data transfer sequence timing from the point at which the call is initiated, answered and released, and checks the data to collect data transfer errors (data integrity), based on the test set up configuration, Figure 3-3, shown below:

SBD Data Exchange Testing Configuration

Figure 3-3

3.4 RUDICS Data Call Test Description There are two scenarios for testing RUDICS data calls, AES to ground (MO), and ground to AES (MT). In both scenarios the auto-dialer is connected to an L band Transceiver (LBT) and to the RUDICS server via the gateway intranet. During a AES to ground data call, the call is requested and set up in a normal calling setup sequence. During a ground to AES data call, the system first issues a ring alert to the AES. Upon receiving the ring alert, the AES places a call to the Gateway to complete the connection.

Page 51 of 53


This results in the call establishment delay being slightly longer for a ground to AES data call than an AES to ground data call. The Auto-dialer executes a script to place a call and to record call sequence timing from end to end from the AES (LBT) to the RUDICS server and from the RUDICS server to the AES (LBT). The Auto-dialer collects the call sequence timing from the point at which the call is initiated, answered and hung up, and checks the data to collect data transfer errors (data integrity), based on the test set up configuration, Figure 3-4, shown:

RUDICS Data Exchange Testing Configuration

Figure 3-4

Page 52 of 53


4. SATELLITE AVAILABILITY The following section provides supplementary information on the impact on coverage of a single satellite outage.

A study of this impact has been undertaken in RTCA SC-165/WG-3/WuP-573, with further refinement of that analysis detailed in Honeywell internal note IRIDIUM-EFCL-0143A (Annex C to this report). These analyses represent a more refined description of coverage loss due to satellite outage compared to a recent ITT analysis (IRD-SWG05-WP3) due to the inclusion of specific Iridium orbital mechanics and effects of Earth rotation not accounted for in the ITT analysis.

To account for the dynamics of a LEO system providing global coverage, availability analysis models can vary in complexity depending on assumptions made, especially when compared to that of a GEO system where coverage is static and given that polar coverage typically is not included in the availability model.

The analysis of Iridium coverage loss due to satellite outage in Annex C considers a satellite failure rate of six per year (out of 66 satellites in the constellation) as the estimate available prior to the initiation of Iridium service. However, since that time accumulated data regarding Iridium satellite failures indicates a failure rate of less than one per 18 months. It must also be noted that a satellite failure results in an outage that is both geographically limited and time-varying in location and size in a predictable and deterministic manner and such knowledge can be used to further mitigate the effects of an outage caused by a satellite failure. Moreover, there is not an acceptable way to predict the probability of a single satellite outage event and thus the limitations of using this probability in determining availability should be considered.

Page 53 of 53


Report on the Validation

of the Requirements in the

AM(R)S SARPs for IRIDIUM

ANNEXES

Annex A: Working Paper 599

Comparison of Iridium Aeronautical System to Draft Acceptability Criteria of WP-577

Annex B: Working Paper 598 Priority, Precedence and Preemption for AMS(R)S in the Iridium System Annex C: IRIDIUM-EFCL-0143A Effects on Iridium Availability Due to Satellite Failures

APPENDIX B ACP/1-WP/9Appendix B

leltaweel

Text Box

ANNEX A

WORKING PAPER 599

Comparison of Iridium Aeronautical System to Draft Acceptability Criteria of WP-577

January 1999

Page – i of Iridium AMS(R)S Validation Report Annex A

ACP/1-WP/9Appendix B

of 9

AMCP/WGA-WP/599

AERONAUTICAL MOBILE COMMUNICATIONS PANEL Working Group A Meeting No. 14

Phoenix, AZ, USA 19-Jan to 29-Jan 1999

Agenda Item 5 Next generation satellite system (NGSS) acceptability

Comparison of Iridium Aeronautical System to Draft Acceptability Criteria of WP577

Presented By: Iridium/AlliedSignal – E.F.C. LaBerge

Working Paper

SUMMARY

WGA/13, meeting in Brussels in July 1998, assigned a subgroup to develop a set of acceptability criteria for Next Generation Satellite Systems (NGSS) and to upgrade the first draft high level generic SARPs presented in Working Paper 540b. The subgroup report is detailed in AMCP/WGA-WP/577, presented during WGA/14. The current paper summarizes the compliance of the Iridium Aeronautical System with the draft Acceptability Criteria established in WP577.


of 9

1 Introduction 1.1 Working Paper AMCP/WGA-WP/577 presents the a portion of the report of the Acceptability Criteria and SARPs Drafting Subgroup. WP577 includes a matrix containing twenty eight criteria by which an NGSS system can be judged to be acceptable for AMS(R)S use. Once acceptability has been established, AMCP can be requested to authorize preparation of SARPs for such a system. 1.2 Table 1 presents the Acceptability Matrix of WP577 filled out with specific references to material that supports the ability of the Iridium Aeronautical System to meet the acceptability criteria. References are supplied to material submitted to WGA/13 and WGA/14, as well as to information included as attachments to the current paper. 2 Discussion 2.1 The Iridium Personal Communications system launched its first satellite in May 1997 and completed a full constellation of 66 operational satellites in May 1998. The system became operational in late summer 1998, and entered commercial service on November 1, 1998 with a full constellation of 66 satellites and 6 on-orbit spares. 2.2 The first telephone call using and engineering model of AES equipment was completed early in October 1998. Orders for single channel voice capable AES equipment have been received, with production on schedule for delivery during the first quarter of 1999. A series of demonstration flights was provided to WGA/14 members during the Phoenix meeting. Software upgrades to support the Priority, Precedence and Preemption capabilities required for AMS(R)S service will be uploaded to the space vehicles in early summer 1999. 2.3 As AlliedSignal moves forward with production of early AES equipment and the design and qualification of more advanced AES design, Iridium and Motorola are constantly adjusting the constellation to achieve optimum performance. Quantitative performance parameters, such as call setup delay and circuit reliability have improved markedly as the operators accumulate experience in controlling the constellation and associate ground infrastructure. 2.4 All of these events indicate that the Iridium Personal Communications System and Iridium Aeronautical System are functional and have moved beyond theoretical promises to real world performance. Several of the acceptability criteria, however, have not been thoroughly verified, but are amenable to analysis based on the partial results available to date. This paper includes such analyses as well as references to on-going testing. 3 Recommendation 3.1 The Iridium Aeronautical team of Iridium, Motorola and AlliedSignal request that WGA/14 review the information submitted in Table 1, the performance demonstrated to WGA/14 members by informal flight tests, the draft MOPS of WP600, and the commitments contained in WP602. Evaluating the total of this information, we request that WGA/14 find the Iridium Aeronautical Service to be acceptable for AMS(R)S and to recommend that AMCP/6 authorize fast track efforts on appropriate SARPs material.


of 9

Table 1: Acceptability Criteria Working Table

Ref Criterion Acceptability Level

Low Density Airspace Applications

Candidate System Compliance

Criteria Related to Institutional Issues of Coverage and Service

A Comply with the Radio Regulations of ITU and benefits from Radio Regulation protections for AMS(R)S.

Operating spectrum recognized as AMS(R)S

(The details of this issue applying to both the current AMSS and any NGSS are still under consideration by WGA as a whole and WGF)

Reference ITU footnote old 743

B Ensure Priority, Precedence and Preemption of AMS(R)S consistent with ITU and SARPs requirement

Inspection/Analysis of P3 implementation

WP-598

C Supplies AMS(R)S Service on non-discriminatory basis to all ATS/AOC organizations

Written commitment from satellite and/or subnetwork service provider

Iridium/AS commitment letter, WP602

D Commits to long term provision of AMS(R)S Written commitment by the service provider to have the service available for a period of at least 6 years after initial operating capability for AMS(R)S is declared by the service provider, and to provide 3 years written notification in advance of any cessation of service.


E Commits to the backward compatibilty of future technology transitions

Written commitment from the service provider that current technology will be supported for at least 3 yr, and that at least 3 yr notification will be provided on any technology enhancement which could require changes in ground or avionics infrastructure.

Iridium/AS commitment letter WP602


of 9




F Demonstrated commitment of service provider to international and national standards development and approval process.

Active participation and disclosure of design and operational details in recognized regulatory and advisory fora, including ICAO, RTCA , EUROCAE etc.

WP 539, WP540, ACSD Subgroup, Validation Subgroup, RTCA WG-1 MOPS preparation, RTCA WG-3, CEPT, ETSI

G Provides necessary documentation to regulatory and user community.

Written commitment by service provider and satellite system operator.to provide necessary documentation during the regulatory process.


H Provides non-discrimatory access to necessary communications technology

Written commitment of service provider/ avionics supplier/ satellite network operator to comply with patent policy established by AMCP/4 and AMCP/5.


I Provide near global coverage SARPs GM, 7.2.1.1.1 – declared by Service Provider

WP/536: Inmarsat > 95%, corresponding to coverage between +72o latitude

100%

WP-539, presented in Brussels

Criteria Related to Protection of Existing Communications, Navigation and Surveillance Services

J Control emissions so as to preclude interference with existing communications navigation, and surveillance, systems,

1) Detailed analysis has been provided to WGA regarding, at a minimum, the items listed below. ; and

2) Existence of a Draft MOPS or TSO or equivalent regulatory documentation covering the installation and required interference envirnoment.

WP-597, updated verision of SC-165/WG3-WP/532, having been harmonized with Delrieu & Chesto

1) NGSS aircraft-to-space-vehicle emissions shall not interfere with GNSS equipment operating in 1559-1605 MHz when the GNSS equipment is on the same aircraft or

Analysis covering applicable ICAO GNSSP interference levels at the GNSS receiver.

WP-597


of 9




on aircraft operating in the same airspace

2) NGSS aircraft-to-space-vehicle emissions shall not interfere with the operation of other AMS(R)S SATCOM equipment located on other aircraft operating in the same airspace.

Analysis indicating that the system emissions do not exceed applicable susceptibility levels as established in the current ICAO AMSS SARPs and in ITU M.1234

WP-600, Draft 4.3 of Iridium MOPS

Attachment 1.

3) NGSS aircraft-to-space-vehicle emissions shall not interfere with other non GNSS communications and navigation and surveillance equipment operating on the same aircraft or on aircraft operating in the same airspace

Analysis covering applicable ITU and ICAO susceptibility of ILS, VOR, VHF Comm, VDL, UHF Comm, DME, TCAS and Mode S, Radio Altimeters, MLS.


Attachment 1

K Exhibit protection against harmful interference from existing communications, navigation and surveillance systems.

1) Detailed analysis has been provided to WGA regarding, at a minimum, the items listed below. ; and

2) Existence of a Draft MOPS or TSO or equivalent regulatory documentation covering the installation and required interference envirnoment.


1) the NGSS shall operate as designed in the presence of in-band interfering signals from other out-of-band communications, navigation or surveillance systems on the same aircraft or on other aircraft in the same airspace in its space-vehicle-to-aircraft band which result in a total ΔT/T of [25%] or less, with no more than [6%] attributable to any single system.

Analysis indicating compliance with ITU M.1234, i.e., immunity to total interference causing ΔT/T of 25% and immunity to interference from a single source causing ΔT/T of 6% has been included in the system design.

Link budgets supporting this performance contained in WP-539, presented in Brussels

Attachment 2

2) the NGSS shall operate as designed in the presence of high level out of band interference generated by communications, navigation or surveillance systems on the same aircraft or on other aircraft in the same airspace, or from ground

Analysis indicating compliance with SARPs 4.2.3.4.2 "typical of normal operating conditions"

Analysis indicating compliance with GM

Attachment 2


of 9




installations transmitting into the same airspace. 2.4.4.1: example of +3 dBW/m2 at antenna, UHF frequencies

Analysis indicating compliance with MOPS 2.2.4.1.4: +3 dBm at receiver input, 470-1450 MHz & 1660.55-18000 MHz; scaling linearly in dB to in-band edges Shall withstand –27 dBW CW signal outside of receive band +75 MHz.

Criteria Related to Standardization of Communications Interfaces to Aircraft and Ground Services

L Supports standard inputs and outputs to the ATS/AOC provider

1) data ATN subnetwork complying with SARPs 4.7: ISO 8208 and J/L event

WP-600, Version 4.3 of draft Iridium MOPS

2) voice Supports internationally standardized telephony interfaces.

WP-539

M Supports standard inputs and outputs to the aircraft systems and pilots

1) data ATN subnetwork complying with SARPs 4.7: ISO 8208 and J/L event

WP-600, Version 4.3 of draft Iridium MOPS

2) voice Provides standardized analog voice interfaces.

[ still open ]

N AMS(R)S supply certain minimum functionality, consisting of either data services or voice services, or both, which meet the following criteria


of 9




1) data service GM 7.2.2.7: >35 bps user rate at D/U priority, 128-octet packets

Attachment 3

2) voice service SARPS 4.8.5: defined algorithm

(new vocoder validated as "statistically equivalent")

MOPS: statistically equivalent to existing SATCOM vocoder meeting the criteria established by RTCA SC-165 in approving the 4.8 kbps Aero I vocoder.

Quantitative evaluation not yet performed. RFP for vocoder testing released 1/5/99, responses received 1/18/99.

Qualitative in turboprop high noise environment demonstrated to WGA/14 by means of audible test file.

Criteria Related to the Technical Performance of the Candidate System to Ensure Suitability for AMS(R)S

Applications

Meets key AMS(R)S performance parameters

O Connection Establishment Delay SARPs 4.7.2.2: 70 seconds 12 second 95-%ile A/G, 35 seconds 95-%ile G/A

Attachment 3

P Voice Call Establishment Delay (95%)

1) Air to Ground GM 8.8.3: 23 seconds, 95% (using abbreviated procedure)

12second 95-%ile

Demonstration at WGA

Attachment 3

2) Ground to Air GM 8.8.3: 17 seconds, 95% 22 seconds 95-%tile

Attachment 3


of 9




Q 95% transfer delay for 128 octets

1) Aircraft to Ground, 128 octets, D/U priority SARPs 4.7.2.2: 80 seconds estimated 12 seconds 95-%tile @ 600 bps net user data rate if circuit setup required

2 seconds 95-%tile @600 bps net user data rate, no call setup

See Attachment 3

2) Ground to Aircraft, 128 Octets, D/U priority SARPs 4.7.2.2: 15 seconds estimated 22 seconds 95-%tile at current time not including terrestrial dialing and call setup.

R Voice transfer delay SARPs 4.8.4.2: <0.485 second 390 ms max, from WP-539. Qualitative experience of calls roughly confirm this value.

See Attachment 4.

S Integrity(Residual Packet Error Rate)

1 ) Air to Ground SARPs 4.7.2.3: <10-6 residual error rate, 128 octet packet

See SC-165/WG3-WP/ 528

Attachment 5

2 ) Ground to Air SARPs 4.7.2.3: <10-4 residual error rate, 128 octet packet

See SC-165/WG3-WP/ 528

Attachment 5

T Maximum aircraft speed, ground speed 750 kt (derived as a component of SARPs 4.2.3.4.5)

See SC-165/WG3-WP/531

Attachment 6


of 9




U Performance monitoring in support of ATN and flight standards

4.7.1.1.1 (new) requiring Connectivity events.

WP-600, draft 4.3 of Iridium MOPS

V Selective Addressing SARPs, Appendix 3, Item 3 requiring ICAO 24 bit addressing

WP-600, draft 4.3 of Iridium MOPS

Criteria Not Specified in AMSS SARPs

W Provides security against the following unauthorized activities

Overall level of security at equivalent to or better than current AMSS SARPS system.

See qualitative analysis in WP565

X Automatic log on System design permits automation of all required log on functions without pilot intervention.

Iridium system modifications to GSM-based mobile terminal registration, WP-539

Y Unrestricted access for distress/urgency communications

Written commitment by service provider. Iridium/AS commitment letter, WP602

Z Provides details on the design & documentation standards followed in designing the NGSSs

Written description of relevent standards from service/system design.

Iridium/AS commitment letter,WP602

AA Provides additional monitoring of system performance over and above the join/leave events described in current SARPS

Additional monitoring of 1) transfer delay and 2) long term availability over appropriate integration times

[ still open ]


Attachment 1 to WGA/14 WP-599 Page 1-1

Attachment 1 Simplified Analysis of Iridium AES Emissions on Common CNS Equipment

1 Introduction 1.1 Acceptance Criterion J of WGA/14 WP-577 requires that candidate systems indicate that system emissions comply with the emission levels of ITU M.1234 for interference to other communications systems, or otherwise fall below the applicable system susceptibility standards for CNS equipment specified by other standards. The acceptability level is determined by 1) a detailed analysis of various interfering items, and 2) existence of a draft MOPS or TSO or equivalent document. 1.2 This attachment presents a simplified analysis of the effects of Iridium AES emissions on common CNS equipment, thus satisfying the first requirement for acceptability. The second requirement is satisfied by WGA/14 WP-600, which presents the draft MOPS applicable to Iridium Aeronautical System AESs. 2 Discussion 2.1 Table 1 presents the emissions analysis, at least insofar as harmonics, discrete spurious and noise (HSN) are concerned. The first three columns reproduce the draft HSN requirements as stated in the draft MOPS of WP-600. The analysis is based on the MOPS requirements rather than measured Iridium performance because the MOPS requirements are not subject to modification by the AES equipment manufacturers, and, therefore represent minimum performance across all manufacturers. Note that the MOPS requirements, which are given in decibels relative to 1 Watt (dBW) are translated into decibels relative to 1 milliwatt (dBm) for comparison purposes. 2.2 At the current time, only AlliedSignal is manufacturing Iridium AES equipment. Current AlliedSignal Iridium AES equipment, such as that demonstrated during WGA/14 complies with these MOPS requirements. 2.3 The next three columns of the table provide key parameters of common CNS equipment. To date, this analysis includes the following CNS equipment: VHF Localizer, VHF Comm, UHF Glideslope, DME/TACAN, TCAS, Mode-S, and Inmarsat transmit and receive equipment (including maritime band operations). Most of the CNS requirements are taken from applicable MOPS or SARPs, with a few based on interviews with cognizant technical experts. As the analysis matures, all CNS requirements will be based on MOPS or SARPs. 2.4 The effects of Iridium AES emissions on Radio Astronomy naturally fall into this analysis, and are included here for completeness. As noted in Note 5 to Table 1, the Radio Astronomy analysis is considerably more complex than the simple sum of terms given in this table. WGA does not appear to be the proper forum to expand the full details of this analysis, therefore only the simplified summary results are shown.



2.5 The next three columns contain terms for either the gain of the transmit (Iridium) and receive (CNS) antennas and their spatial separation or the port-to-port isolation for antennas located on a common aircraft. For the completion of this analysis, port-to-port isoloations of –40 dB are assumed, consistent with DO-210C/D and current AMSS SARPs, but these assumptions are currently under review for systems operating other than L-band. 2.6 The final four columns compute the effective emissions in the CNS bandwidth, the CNS Carrier Power to Interference Ratio (C/I), expressed in decibels, an estimate of the C/I required for normal operation, and the margin provided by the Iridium AES. In the case of Iridium-on-Inmarsat interference, the required margin is chosen to match ITU recommendation M.1234 for interference between MSS systems. The Iridium Aeronautical System design meets the M.1234 recommendations on both the Inmarsat uplink and downlink. 2.7 The analysis shows that HSN emissions from the draft MOPS-compliant Iridium AES do not interfere with common CNS equipment. This conclusion is supported by qualitative experience with early Iridium AES equipment installed onboard a heavily instrumented SabreLiner containing most of the aforementioned CNS equipment. This aircraft was used for Iridium demonstration flights during WGA/14. 2.8 The Iridium AES satisfies the requirements of acceptability criterion J. 3 Recommendation 3.1 The Iridium Aeronautical team of Iridium, AlliedSignal, and Motorola request that WGA consider this attachment when considering the acceptability of the Iridium Aeronautical system for AMS(R)S communications.



Table 1: Simplified Analysis of Iridium AES Emissions on Common CNS Equipment Frequency Band/ CNS

System Meas. BW

(kHz)

LEO MOPS HSN

(dBW)

LEO MOPS HSN

(dBm)

CNS Freq. (MHz)

CNS Min.

Signal(dBm)

CNS BW

(kHz)

Gt or isolation

(dB)

Gr (dBi)

Path Loss+ PFD

(dB/m2)

Emissionin CNS band (dBm)

C/I (dB)

Req'd C/I

(dB)

Margin

0.01-1525 3 -120 -90 VHF Nav (ILS, VOR) source: DO-195/196

111.95 -86.0 2.0 -40.0 0.0 -131.8 45.8 36.0 9.8

VHF Comm source RTA-44D

135.95 -107.0 12.5 -40.0 0.0 -123.8 16.8 6.0 10.8

UHF Nav (GS) source: DO-192

334.95 -78.0 20.0 -40.0 0.0 -121.8 43.8 36.0 7.8

DME/TACAN source ARINC-709

1213 -90.0 1000.0 -40.0 0.0 -104.8 14.8 12.0note 1

2.8note 1

TCAS source: engineering

1090 -85.0 1000.0 -40.0 0.0 -104.8 19.8 12.0note 1

7.8note 1

MODE-S source: DO-181A

1030 -77.0 1000.0 -40.0 0.0 -104.8 27.8 12.0note 1

15.8note 1

1525-1559 3 -154 -124 Inmarsat Receive source: DO-210C/D

1559 -134.0 4.0 -40.0 0.0 -162.8 28.8 28.0note 2

0.8

1559-1565 1000 -131 -101 1565-1585 1000 -130 -100 GPS/GNSS source: WGA/14 ad hoc

1585 -116.5 1000.0 -40.0 0.0 -140.0 23.5 6.0note 3

17.5

1585-1605 1000 -130 -100 GLONASS/GNSS source: WGA/14 ad hoc

1605 -122.0 1000.0 -40.0 0.0 -140.0 18.0 6.0note 3

12.0

1605-1610 1000 -102 -72 High band GLONASS source WGA/14 ad hoc

1609.36 -122 1000 5 0 -72 -139.0 17.0 6.0note 4

11.0

1610-1614 1000 -80 -50 Radio Astronomy source ITUR-RA.769.1

1613.8 -208 0.001 -13 0 -81 -216.0note 5

8.0 0.0 8.0



Frequency Band/ CNS System

Meas. BW

(kHz)

LEO MOPS HSN

(dBW)

LEO MOPS HSN

(dBm)

CNS Freq. (MHz)

CNS Min.

Signal(dBm)

CNS BW

(kHz)

Gt or isolation

(dB)

Gr (dBi)

Path Loss+ PFD

(dB/m2)

Emissionin CNS band (dBm)

C/I (dB)

Req'd C/I

(dB)

Margin

1614-fopmin 30 -70 -40 fopmin -1628.5 30 -70 -40 1628.5-1631.5 30 -70 -40 Inmarsat Transmit (maritime/mobile) source: engineering

1626.5 -8 10.5 5 0 0 -39.6 31.6 28.0 3.6

1631.5-1636.5 100 -70 -40 Inmarsat Transmit (maritime/mobile) source: engineering

1636.5 -8 10.5 5 0 0 -44.8 36.8 28.0 8.8

1636.5-1646.5 300 -70 -40 Inmarsat Transmit (maritime/mobile) source: engineering

1646.5 -20 10.5 5 0 0 -49.6 29.6 28.0 1.6

1646.5-1660 1000 -88 -58 Inmarsat Transmit (AMSS/AMS(R)S) source: DO-210C/D

1660.5 -20 10.5 5 0 0 -72.8 52.8 28.0 24.8

1660-1670 1000 -88 -58 Radio Astronomy source: ITUR-RA.769.1

1660 -221 0.001 -13 0 -81 -222.0note 5

1.0 0 1.0

Notes: 1. All items identified by Note 1 are still under evaluation by AlliedSignal engineering and may require additional modifications to LEO MOPS HSN

specification.. Measured performance to date on SabreLiner indicates that current HSN specification is sufficient, even with reduced isolation. 2. 28 dB C/I approximately corresponds to a the ITU M.1234 equivalent ΔT/T of 6% for single entry interference. 3. WGA/14 Ad-Hoc subgroup on GNSS interference chose 6 dB interference protection margin as appropriate and consistent with GNSSP SARPs. 4. WGA/14 Ad-Hoc subgroup on GNSS interference chose to protect high band GLONASS in joint use airspace as opposed to on same aircraft. 5. Detailed analysis of Radio Astronomy interference will be presented to CEPT SE028 in February, and contains additional factors not included in this

spreadsieet. The indicated margins can not be derived by simple addition of the factors shown here.



Attachment 2 Simplified Analysis of Iridium AES Susceptibility to Emissions from Other Common

CNS Equipment 1 Introduction 1.1 Acceptance Criterion K of WGA/14 WP-577 requires that candidate systems indicate that system operate as designed in the presence of in-band interfering signals from other CNS systems on the same aircraft or in the same airspace, subject to the ITU M.1234 interference levels, and operate with high level out-of-band interferors, subjects to the current SARPs provisions. Furthermore, Criterion K requires existence of draft MOPS and/or TSO documentation covering installation in such an environment. 1.2 This attachment presents a simplified analysis of the effects of on-board emissions from common CNS equipment, thus satisfying the first requirement for acceptability. The second requirement is satisfied by WGA/14 WP-600, which presents the draft MOPS applicable to Iridium Aeronautical System AESs. 2 Discussion 2.1 The analysis of susceptibility is more difficult than the analysis of emissions performed in Attachment 1 to WP-599. A complete analysis of the susceptiblity requires that details of the operating parameters of other CNS equipment are known and properly accounted for. Although this analysis is underway, the details are not sufficiently mature to present at this time. 2.2 Nevertheless, real-world operating experience in a relatively small aircraft equipped with a full range of modern CNS equipment indicates that the early Iridium AES equipment is not susceptible to such interference. The AlliedSignal SabreLiner used to conduct the flight demonstrations during WGA/14 is equipped with VHF Comm, DME, TCAS, and Mode-S equipment. No interference effects on Iridium AES operations have been detected or reported during hundreds of flight hours of testing. This performance has been achieved despite the small separation of antennas on the fuselage, as demonstrated to the members of WGA/14 during the flight tests. Therefore, it is reasonable to say that no significant interference issue exists with the listed equipment. 2.3 The Iridium Aeronautical System has been designed to cope with in-band interference from other MSS systems in excess of that required by M.1234. Support for this design is contained in the detailed system link budgets presented to WGA/13 in WP-539. 2.4 There are, however, two potential interference problems which have been identified. First, older VHF Comm equipment may emit sufficient harmonic energy at the 11 and 13 harmnics to impact Iridium operations. Although this type of interference has not been observed in early tests, it is nevertheless a potential issue to Iridium AES equipment in much the same way it is a potential issue to existing Inmarsat equipment. The solution in both cases is the same. A low cost in-line low-pass filter with cutoff at approximately 500 MHz can be installed at the input to all VHF Comm antennas without affecting VHF performance. This filter may also be required to protect GNSS from similar VHF harmonic interference. (At least one manufacturer of modern VHF Comm equipment does not require such external protection.) 2.5 Previous experience by Inmarsat AES manufacturers in an extensive fleet of aircraft indicates that such modifications provide sufficient protection. Because the Iridium downlink signals levels are



significantly higher than the Inmarsat levels, this indicates that sufficient protection is readily available. 2.6 A second, more problematic source of interference into Iridium AES equipment comes from Inmarsat-equipped aircraft, or Inmarsat AES equipment on the same aircraft. The potential exists for severe interference to certain modes of Iridium operation from certain modes of Inmarsat operation. This comes about due to the very high EIRP levels (22 dBW – 34 dBW, per SARPs) required to access the Inmarsat satellites and the extensive spectrum allotted for Inmarsat in-band interference. 2.7 Current SARPs and MOPS allow Inmarsat AES equipment to emit a flat spectrum of –55 dBc/4 kHz over the 120 MHz with range 1614-1735 MHz. This 120 MHz band includes the entire Iridium band of 1616-1626.5 MHz. When measured in the Iridium band, this corresponds to a ΔΤ/T far in excess of the 24% single entry level of M.1234, and, therefore, far in excess of the acceptability criteria. 2.8 Such Inmarsat-on-Iridium interference can be dealt with in two ways. If Inmarsat AES operations can be limited to a frequency band somewhat about 1636 MHz, a relatively simple in-line filter can protect Iridium AES on the same aircraft, and simultaneously eliminate any Inmarsat effects in the lower Radio Astronomy and GNSS bands. At least one Inmarsat AES manufacturer is already testing such a modified filter. The framework for this limitation has already been brought forward to WGA/14 as WP-588. 2.9 Other than such a filter, the only remaining protection is through geometric separation, which, unfortunately, could reach several thousand feet in the worst case peak beam of an Aero H terminal. This does not mean that a "protection sphere" of this distance is required: only that the main-beam interference could extend this far. 2.10 The gradual migration of Inmarsat terminals to spot beam performance significantly reduces this problem due to the significantly lower requirements for Inmarsat EIRP. 2.11 Iridium and AlliedSignal wish to emphasize that this interference is caused solely by Inmarsat emissions which significantly exceed ITU M.1234 in the Iridium band. 2.12 A MOPS-compliant Iridium AES meets all of the specific requirements listed in Criterion K. 3 Recommendation 3.1 The Iridium Aeronautical team of Iridium, AlliedSignal, and Motorola request that WGA consider this attachment when considering the acceptability of the Iridium Aeronautical system for AMS(R)S communications. 3.2 The Iridium Aeronautical team also requests that WGA investigate means to reduce the unnecessary emission of Inmarsat AES equipment in the Iridium operational band.



Attachment 3 Analysis of Iridium Aeronautical Setup, Connection, and Throughput Metrics

1 Introduction 1.1 Acceptance Criteria N, O, P, and Q of WGA/14 WP-577 require that candidate systems meet certain standards in call setup, system connection, and end-user throughput. In each case, these metrics are established by the current SARPs. 1.2 This attachment presents a simplified analysis of the performance of the Iridium Aeronautical system with respect to these metrics. The analysis is based on a combination of draft MOPS requirements, system performance levels as described to WGA/13 in WP-539, and a very limited set of measured data from on-going flight tests. 1.3 Most of the metrics in question involve the transmission of packet data . As noted in WP-539, the Iridium Communications System is primarily designed around GSM-based circuit-mode communications. Aeronautical packet data will be transferred by establishing a circuit and transmitting all pending data packets via that circuit. Therefore, worst case throughput rates must include the establishment of a data circuit, although best case throughputs can assume use of a pre-existing circuit. After a predetermined interval during which no data is transmitted, the circuit will be released. 1.4 Despite the similarities between this method of providing packet data and conventional circuit mode data, such as fax and modem emulation, the packet data and circuit data functions are fundamentally different. The acceptability criteria address only packet data, as does this analysis. 2 Discussion

2.1 Call Setup Time, TSU

2.1.1 As explained to WGA/13 in WP-539, IRIDIUM aeronautical packet data services operate over an IRIDIUM circuit. Therefore, there are two major random components that contribute to transfer delay: call setup time and effective channel throughput. Of these components, the call setup time is the dominant factor. For an AES, call setup time is determined by the availability of local and satellite resources, and the quality of geolocation information available to the registration/access processing described earlier. WP-539 reported call setup times in both directions in the 17-20 seconds at the 95th percentile. These estimates of performance were based on Motorola simulations of system performance under conditions of heavy system load and non-existent geolocation information. They do not include allocations for the initial international telephone conversation to initiate the Ground-to-Air communications and they do not account for implementation of the Priority, Precedence and Preemption mechanisms discussed in WP-598. 2.1.2 Actual performance of call setup in the Air-to-Ground direction using early AES equipment has been significantly better than this simulated performance. Typical performance is running 5-8 seconds, as demonstrated to WGA/14 during SabreLiner test flights. Although this connection delay is characteristic of an unloaded constellation, we believe that it is near that to be expected by AMS(R)S service using Acquisition Class 14.


Attachment 3 to WGA/14 WP-599 Page 3-2 2.1.3 Actual call-setup performance in the Ground-to-Air directions using early AES equipment has been significantly worse than that predicted in WP-539. Current measurements indicate a 98th percentile value of approximately 35 seconds. This value, however, includes terrestrial call setup time, which can be conservatively estimated at 10 seconds. 2.1.4 For the purpose of this analysis, we will use a value of 22 seconds as a typical 95th percentile for call connection delay, realizing that this is based on assumed PSTN connection delays which do not apply to safety communications. Further data collection is in progress to better establish the factors influencing the current measurements. 2.1.5 Iridium is still a new service, with initial commercial activation on November 1, 1998. Motorola continues to tune constellation performance with the goal of improving customer metrics such as call setup time. Progress will continue to be monitored. 2.1.6 In summary, current measurements support a value for Ground-to-Air call setup delay of 22 seconds, slightly larger than the value given in WP-539. Current measurements also support a value for Air-to-Ground delay of approximately 12 seconds, significantly less than the value given in WP-539.

2.2 User Packet Data Rate, fpd 2.2.1 Iridium packet data services are designed to provide typical user throughput of 2400 bps over a wide range of satellite parameters and propagation environments. This performance is supported by the link budgets previously presented in WP-539. Current measurements on the constellation indicate that actual performance is better than the assumptions made in the link budgets. 2.2.2 Under worst case interference and multipath environments, the net user throughput using Iridium packet data will gracefully degrade to about 600 bps. This degradation in performance is supported by the link budgets in WP-539. The rapidly changing nature of LEO geometry ensures that such degraded service will be of only limited duration. 2.2.3 Although packet data test calls have been performed by Iridium LLC and Motorola engineers, the full suite of software supporting packet data operations has not yet been loaded in the satellites, Therefore, measured performance on Iridium packet data service is not yet available. 2.2.4 In summary, Iridium packet data services will provide typical net user throughput rates of 2400 bps, with graceful degradation to 600 bps, worst case.

2.3 Compliance With Acceptability Criteria 2.3.1 This section uses the values presented in the previous paragraphs to demonstrate compliance with Acceptability Criteria N, O, P, and Q. Criterion N1: End user data rate >35 bps for Distress/Urgency Communications 2.3.2 Given the values for TSU and fpd, and the defined packet length of 128 octets, or N=1024 bits:



F N

T NfSU

pd

=+( )

where F is the end user throughput in bps. Because the link budgets presented in WP-539 support 2400 bps data transfers under more than 99% of link conditions, fpd=2400 bps.

F =+

=1024

22 10242400

45 7( )

. bps , typical 95% throughput, assuming call setup is required.

2.3.3 If no call setup is required, the rate is 600 bps worst case and 2400 bps 99th percentile. 2.3.4 Eventually, we will be able to compute a true 95th percentile value based on the fact that some percentage of the D/U calls do not require call setup. If this percentage is as small as 1%, a sample computation shows: F95 0 99 45 7 0 01 2400 69 2= × + × =. . . . bps . 2.3.5 For specific applications where such delay is unacceptable, it is always possible to open a data circuit and leave it open for D/U communications. In this case, the sustained end user throughput is 2400 bps. 2.3.6 The Iridium Aeronautical System complies with Criterion N1. Criterion O: Connection establishment delay < 80 seconds. 2.3.7 Even taking the worst case measured data available to date, which indicates 35 seconds G/A including PSTN time, the connection establishment delay is well within the required 80 seconds. 2.3.8 The Iridium Aeronautical System complies with Criterion O. Criterion P: 95% Voice Call Establishment Delay 22 second A/G, 17 seconds G/A 2.3.9 As noted above, the Iridium communications system is currently achieving 12 seconds A/G and 22 seconds G/A. Although the G/A term is slightly longer than the acceptability criteria, it is comparable to the A/G requirement in the current SARPs. The actual A/G value is considerably better than the current SARPs. The average value of A/G and G/A delays currently achieved by Iridium is 17 seconds, less than the corresponding average of the SARPs values. 2.3.10 This performance is obtained without special rapid access provisions. 2.3.11 The Iridium Aeronautical System offers equivalent performance to the current SARPs, and should be judged acceptable in this regard. Criterion Q: 95% Transfer Delay for 128 Octets, 80 seconds A/G, 15 second G/A


Attachment 3 to WGA/14 WP-599 Page 3-4 2.3.12 The time to transfer 128 octets can be computed using the values of TSU and fpd used above.

T T Nft SU

pd

= + .

If a circuit must be established, TSU=12 seconds A/G, =22 seconds G/A. 2.3.13 With the RF link budgets given in WP-539 supporting 2400 bps operations more than 99% of the time, fpd = 2400 bps. Thus

T

T

t

t

= + =

= + =

12 10242400

12 4

22 10242400

22 4

.

.

sec, A / G

sec, G / A

Therefore, the Iridium Transfer Delay in the Air-to-Ground direction is only 16% of the SARPs time, while the Ground to Air Transfer delay is approximately 50% greater than the current SARPs requirement if call setup is required. 2.3.14 If call setup is not required, the transfer delay is 0.4 seconds. 2.3.15 These times are not expected to change significantly with constellation loading due to the priority and preemption mechanisms discussed in WP-598. These times are expected to decrease as constellation operations improve. 2.3.16 The Iridium Aeronautical System offers equivalent performance to equipment compliant with the current AMSS SARPs, and should be judged acceptable in this regard. 3 Recommendation 3.1 The Iridium Aeronautical team of Iridium, AlliedSignal, and Motorola request that WGA consider this attachment when considering the acceptability of the Iridium Aeronautical system for AMS(R)S communications. When considering these results, which are based on the first three months of commercial operations, WGA should recognize the continued effort now being expended to tune and improve constellation performance.



Attachment 4 Analysis of Iridium Voice Call Delay

1 Introduction 1.1 Acceptance Criterion R of WGA/14 WP-577 requires that candidate systems provide voice call delays on of 485 ms or less in each direction. This attachment presents a simplified analysis of the performance of the Iridium Aeronautical system with respect to this metric. The analysis is based on a combination of draft SARPs requirements and satellite geometry derivable from the FCC License application. 1.2 The Iridium constellation consists of 66 satellites, with eleven satellites occupying each of 6 orbital planes. The eleven satellites are evenly spaced within the planes. Once call-setup is complete, an Iridium voice call passes from the AES to the nearest satellite, then by intersatellite cross links around or across planes, as appropriate, and finally from a satellite down the the earth. For calls that terminate in an Iridium mobile terminal, this final link is an L-band link. For calls that terminate in the PSTN or private network, the final link is a K-band link. In either case, a voice call requires one uplink, one downlink, and up to eight crosslinks. Eight crosslinks are sufficient to move the signal around 1800 , i.e. to reach the point on the Earth's surface antipodal to the user. 1.3 We will estimate the delay by assuming the worst-case AES and GES vocoder delays of 125 ms, worst case uplink delays corresponding to satellites low on the horizon, and worst case cross-link delays between satellites separated by an Earth centered angle of 32.8o. This separation corresponds to the separation between two consecutive satellites in the same plane, and is larger than the maximum separation of 31.7o between orbital planes. 2 Discussion 2.1 The maximum range, ρ , to a satellite at an elevation angle of β is derived in Appendix B of Attachment 6 to this working paper as:

ρβ

β β= FH

IK −

LNM

OQP

−R rRcos

sin cos cos1 ,

where r is the Earth's radius and R is the orbital radius, assuming a circular orbit. Given the lowest line-of-site elevation angle provided by the Iridium is approximately 8o, as detailed in WP-539, and with the value of r = ×6 38 106. meters , and R r= + ×770 000, m = 7.15 10 m6 , we have ρ = ×2 46 106. m , and the uplink and

downlink transit times are τ τ ρu d c= = = × −8 21 10 3. sec . Similarly, the direct crosslink

path between two satellites separated by 32.8o is:

ρ θCL R= = × × × = ×2

22 715 10 4 04 106 6sin ( . .m) sin 32.8

2 m.

o



2.2 The associated crosslink time is:

τ ρCL

CL

c= = × −1346 10 3. sec.

2.3 The total one-way voice transfer delay is then: τ τ τ τ τ τv UL DL CL AES GESN= + + + +

= + + × + + × −( . . . )8 21 8 21 8 1346 125 125 10 3 sec= 374.1 msec

This value compares well with the very informal measurements conducted during an Iridium demonstration call at the December meeting of RTCA SC-165, WG-1. It also compares well with the two way delay estimated during demonstration flights. 3 Recommendation 3.1 The Iridium Aeronautical team of Iridium, AlliedSignal, and Motorola request that WGA consider this attachment when considering the acceptability of the Iridium Aeronautical system for AMS(R)S communications.



Attachment 5 Analysis of Iridium Packet Data Integrity

1 Introduction 1.1 Acceptance Criteria S1 and S2 of WGA/14 WP-577 requires that candidate systems provide high integrity packet data service to AMS(R)S users. This attachment includes the text of RTCA working paper SC-165/WG3-WP/528 which addresses this issue. This working paper was reviewed by RTCA SC-165, Working Group 3 on System Performance, and endorsed by that committee for consideration by WGA. 1.2 This attachment provides analytical evidence that the Acceptance Criteria are satisfied by Iridium AES equipment that is compliant with the Motorola Multi-Transceiver Unit Air Interface Specification (MXU-AIS). This document is heavily referenced by the draft MOPS under preparation by SC-165 WG-1, and presented to WGA/14 as WP-600. 1.3 Although Motorola has performed initial tests of packet data transfer through the Iridium constellation, the capability to perform this operation from a production mobile terminal, including early production AES equipment, is not yet implemented in the space vehicle software. The update to the space vehicle software is expected by late spring 1999, months in advance of data-capable AES equipment. 1.4 The residual packet error rates required by Criteria S1 and S2 are so small that they will require between 1000 and 62,000 hours of testing to verify through testing. Therefore, for the foreseeable future the analysis will be the principal source of performance verification. 2 Discussion See the attached paper, SC-165/WG3-WP/531. 3 Recommendations 3.1 RTCA SC-165, Working Group 3 endorses this paper for consideration by ICAO WGA in its assessment of the acceptability of the Iridium Aeronautical System for AMS(R)S services.



SC-165/WG3-WP/528a

MEMO Number IRIDIUM-EFCL-0134a DATE: 11 January 1999 TO: Iridium Systems Engineering File FROM: E.F.C. LaBerge SUBJECT: Integrity of AMS(R)S Packet Data Messages via Iridium Introduction

The integrity of a communications system can be defined as the probability that the system does not provide erroneous information to external users of the system. From the point of a satellite communications systems operating in an aircraft, this means that the data stream at the output of the AES in the direction of on-board users and the data stream at the output of GES in the direction of terrestrial users must be virtually error free. The current AMSS SARPs define this condition of "virtually error free" as a residual packet error rate of less than 10-6 in the "from-aircraft" direction and 10-4 in the "to aircraft direction".

The Iridium1 Aeronautical System complies with both requirements.

Description In the Iridium Aeronautical System, digital information, including both digitized

voice and user-generated packet data, is transferred between the AES and GES in 414 bit bursts. For data bursts, 102 bits are for used for preamble and link control overhead, 56 bits are for the IRIDIUM Radio Link Protocol (IRLP) overhead used to deliver data, 8 bits are overhead bits for the IRIDIUM Layer 2 Relay (I-L2R) Protocol Data Units (PDUs), and 248 bits (31 octets) are user bits. The 56 bits of of IRLP overhead include a 24-bit Frame Check Sequence or FCS. All data is transmitted at a rate of 50 kbps. Thus, each 8.28 ms frame of 414 bits can transfer 248 bits of Air-to-Ground Protocol data.

The GES verifies the payload data with the FCS before it is passed to an external user. If the checksum is not passed, the IRLP automatically retransmits the incorrect data until it is correctly received. Thus the internal Iridium protocols act as a Reliable Link Service. All of this activity is within the Iridium subnetwork, and is not subject to manipulation by either aeronautical or ground equipment associated specifically with the Iridium Aeronautical Services.

The Air-to-Ground protocol is a "sub-layer" within the Satellite Sub-Network Dependent Protocol (SSNDP) layer of the ISO stack that permits an aeronautical-specific entity within the AES to communicate directly with its peer within GES and vice versa. This permits data entering and exiting the Iridium system to be isolated from aero-specific requirements, except for the provision of P3. The Air-to-Ground Protocol, or AGP provides the mechanisms for controlling a number of 248 bit-packets transmitted by

1 Iridium and IRIDIUM are service and trademarks of Iridium, LLC. AIRSAT is a trademark of AlliedSignal, Inc.


Attachment 5 to WGA/14 WP-599 Page 5-3 the lower level Iridium protocols as a single logical entity. Each such AGP data unit (AGPDU), consisting of multiple 248-bit Iridium frames, contains its own 16-bit checksum.

User data is packed into the AGP by the AES or GES, depending on the data source, and unpacked from the AGP by the GES or AES. Thus each 128 octets of user information is protected by not one but two error detection mechanisms. Each 248 bits is protected by the Iridium FCS, while the entire AGPDU is protected by the 16-bit checksum.

Analysis

For an error to exist in the data output from the AGP to the user interface, two events must happen. First, an 248 bit Iridium PDU must pass the 24-bit FCS and be passed to the AGP as correct. Second, the erroneous Iridium PDU must be correctly assembled into an AGPDU, and the resultant AGPDU must pass its own 16-bit checksum, despite the fact that at least one of the Iridium PDUs is in error. Because the FCS and AGP check sum designed using separate checksum philosophies, the two events are independent. Therefore, the combination of events is extremely unlikely, as will now be demonstrated.

Consider the standard 128-octet user message defined as the standard by the current AMSS SARPs. This message contains 128 x 8 = 1024 user information bits, and requires

EQ. 1 240 8248

5×LMM

OPP = Iridium PDUs,

where indicates the "least integer greater than" function.

The probability that all 5 Iridium PDUs are transmitted without error is:

EQ. 2 Pr{ ( )no error in 5 PDUs} = −1 5pPDU ,

where pPDU is the probability that a single PDU is in error. Because of the 24-bit FCS, a simple approximation of pPDU is:

EQ. 3 pPDUN≈ = = ×− − −2 2 5 96 1024 8.

Using EQ. 2, we can find the probability that any errors occur in the 5 PDU message as:

EQ. 4

Pr{ Pr{

) . .

any error in 5 PDUs} 1- no error in 5 PDUs}

(1- 5.96 10-8

=

= − × ≈ × × = ×− −1 5 5 96 10 2 98 105 8 7



An expression similar to EQ. 3 applies to the AGP checksum as well. Thus, the probability of erroneous data passing the AGP checksum is:

EQ. 5 pAGPN≈ = = ×− − −2 2 1 53 1016 5.

Thus, the probability of both an erroneous data transmission via the Iridium protocol and an erroneously valid AGP checksum is:

EQ. 6 p pERROR AGP= × = ×Pr{any error in 5 PDUs} 4.55 10-12

Because the Iridium-based Air-Ground and Ground-Air links are entirely symmetric, the residual packet error rate, pERROR, given in EQ. 6 applies in both directions. This predicted performance provides several orders of magnitude of margin over the requirements of the current AMSS SARPs. This large margin is appropriate at this time, before any extensive experience with Iridium packet data transfer has been developed.



Attachment 6

Analysis of Iridium AES Doppler Performance 1 Introduction 1.1 Acceptance Criterion T of WGA/14 WP-577 requires that candidate systems provide service on aircraft operating at 750 knots. This attachment includes the text of RTCA working paper SC-165/WG3-WP/531 which addresses this issue. This working paper was reviewed by RTCA SC-165, Working Group 3 on System Performance, and endorsed by that committee for consideration by WGA. 1.2 This attachment provides analytical evidence that the Acceptance Criterion is satisfied by Iridium AES equipment that is compliant with the Motorola Multi-Transceiver Unit Air Interface Specification (MXU-AIS). The analysis concerns acquisition of the Iridium signal by the AES. This document is heavily referenced by the draft MOPS under preparation by SC-165 WG-1, and presented to WGA/14 as WP-600. Internal Motorola analyses not yet releasable to ICAO indicates that radio channel units have the ability to maintain track on the satellite signals at velocities of Mach 4 or accelerations up to 4g. 1.3 Current flight tests of the Iridium AES have indicated no impact on system operation of velocities in excess of 450 knots. One such call was received by SC-165 Working Group 1 at its December meeting. Current flight testing includes a NASA ER-2 research vehicle flying at altitudes in excess of 65,000 feet. This testing will include speed tests as well, but results are not available at this time. 1.4 Supersonic tests aboard the Concorde are planned for the near future as a cooperative effort between one the operator, Iridium, Motorola and AlliedSignal. 2 Discussion See the attached paper, SC-165/WG3-WP/531. 3 Recommendations 3.1 RTCA SC-165, Working Group 3 endorses this paper for consideration by ICAO WGA in its assessment of the acceptability of the Iridium Aeronautical System for AMS(R)S services.



SC-165/WG3-WP/531

MEMO Number IRIDIUM-EFCL-0135 DATE: 11 January 1999 TO: Iridium System Engineering File FROM: E.F.C. LaBerge SUBJECT: Doppler Requirements/Performance for Iridium Aeronautical

Note: This tech note is a reprint of the Doppler sections and appendices of IRIDIUM-EFCL-0110B, which is also designated SC-165/WG-1/WP _320, Rev 1, dated May 18, 1998. This version removes certain erroneous information concerning oscillator stability and concentrates on the Doppler tracking problem only.

Introduction This memo derives the ability of the specified +37.5 kHz tracking requirements of the Motorola Multichannel Unit Air Interface Spec (MXU-AIS) to support Iridium Doppler shifts corresponding to ground velocities in excess of 800 kt without modifications. In preparing this document I have incorporated WG-1 comments relating to the satellite geometry at the time of lowest elevation angle. This changes the frequency allocations slightly. I have also incorporated comments from the May 12-14, 1998 meeting of WG-1 regarding the effects of earth rotation. These effects were intentionally and explicitly left out of IRIDIUM-EFCL-0110A. This paper shows that inclusion of these effects has no impact on the analysis. The RTCA Working Paper version of this document has been stripped of its proprietary content..



Assumptions and Definitions The analysis here has been simplified from the true orbital dynamics of the IRIDIUM space vehicles. To establish the minimum and maximum space vehicle Doppler frequency, I have assumed a circular, polar orbit, and assumed that the orbital plane passes directly overhead of an avionics user. The orbital period is 100 minutes. The orbital altitude is 770 km. I have assumed a spherical Earth. Appendix A demonstrates that, in the worst case scenario, the component of aircraft velocity due to earth rotation does not affect the overall allocations. The main analysis therefore ignores the effects of earth rotation in its evaluation of the worst case scenario. Table 1 defines the various terms used in the analysis and in the appendices.

Analysis

Doppler Frequency of Space Vehicles Appendix A derives the Doppler frequency of the transmissions to/from the aircraft. Using the from aircraft direction as a reference, the Doppler frequency will be

Table 1: Definition of Terms for Doppler Frequency Analysis Term Definition Units Value R radius of the (circular) IRIDIUM orbit meters 7.148 x 106 m

r radius of the (spherical) Earth meters 6.378 x 106 m

ρ line of sight vector from the aircraft to the space vehicle

meters computed

)(tΘ Earth centered angle (ECA) of space vehicle as a function of time. 0=Θ corresponds to a space vehicle directly overhead. 0>Θ corresponds to a setting space vehicle. tω=Θ

degrees or radians computed

ω angular velocity of IRIDIUM space vehicles radians/sec 1.047 x 10-3 rad/sec

λ RF wavelength meters 0.1844 m @ 1626.5 Mhz

t time measured from satellite at zenith seconds computed

DSf Doppler frequency due to space vehicle motion

Hertz computed

SVV Space vehicle velocity vector, measured in an inertial frame

meters/sec computed

AV Aircraft velocity vector, measured in the frame defined by the rotating Earth

meter/sec computed

EV Velocity vector of a stationary user due to rotation of the Earth

meters/sec computed

υ Angular velocity of the Earth radians/sec 7.27221x 10-5 rad/sec

υ Angular velocity vector of Earth radians/sec

⎥⎥⎥

⎦

⎤

⎢⎢⎢

⎣

⎡

υ00

in Earth Centered

Iniertial coordinatess



positive when the space vehicle is rising above the horizon and negative when the space vehicle is setting, i.e., when Θ > 0. The Doppler frequency is given by EQ 1.

EQ. 1 f

V

Rr t

DSSV=

⋅

=−

ρλ ρ

ω ωλ ρ

sin

Since Θ = ωt , the Doppler frequency is minimum when the satellite is directly overhead (Θ = 0) and maximum when the satellite is on the horizon. The satellite is on the horizon when

EQ. 2 Θ = FH

IK =

−cos .1 26 84rR

The range to the satellite, ρ , can be expressed (see Appendix B) in terms of the elevation angle, β , as

EQ. 3 ρβ

β β= FH

IK −

LNM

OQP

−R rRcos

sin cos cos1 .

For the minimum elevation angle of 8o, ρ is 2.459 x 106 m. The value of the ECA, Θ , is given by the argument of the sine in EQ 3, is 19.92o. Substituting into EQ 1, with Θ = ωt :

EQ. 4 fDS =− × × ×

×= −

( . )( . )

.

7148 10 19.920 1844

35 87

6 m)(6.378 10 m)(1.047 10 rad / sec)sin( m)(2.459 10

kHz

6 -3

6

This value represents an unrealistic worst case. This value is the result of a satellite in an orbital plane passing directly over the user when the satellite is a 8o elevation angle. Because the in-plane spacing of IRIDIUM space vehicles is 32.7o, when one satellite is at an elevation angle of 8o, the next (or previous) satellite in the same plane is at an ECA, of 19.92o-32.7o = -12.78o, where the negative sign indicates that the satellite is behind the receiver. Now solving for β for this new ECA:

EQ. 5 ρ

βρ

= − + = ×

=FHG

IKJ =

−

R rR r

R o

2 2 6

1

2 1 689 10

20 55

cos .

cos sin .

Θ

Θ

m



Thus, with an in-plane satellite at 8o, there is a second, better satellite available at an elevation angle of 20.55o. The receiver will select this satellite due to better signal quality. Thus, the Doppler frequency is:

EQ. 6 fDS =− × × ×

×= +

( . )( . )

.

7148 10 12.780 1844

33 9

6 m)(6.378 10 m)(1.047 10 rad / sec)sin( m)(1.689 10 m

kHz

6 -3

6

But this is still not the worst case. The worst case occurs slightly before the time when the leading satellite descends to 8o and the trailing satellite rises to 20.5o, when the aircraft is midway between a setting and a rising satellite. The ECA for either satellite is then one half of the space vehicle spacing, or 16.35o. Computing the Doppler once again:

EQ. 7 fDS =− × × ×

×= +

( . )( . )

.

7148 10 16.350 1844

351

6 m)(6.378 10 m)(1.047 10 rad / sec)sin( m)(2.075 10 m

kHz

6 -3

6

This occurs when β is:

EQ. 8 βρ

=FHG

IKJ =

−cos sin . .41 16 35 13R o

This value is less than the Doppler frequency allowance of +37.5 kHz expressed in MXU200700. The remaining +2.4 kHz is allocated for vehicle motion.

These computations assume that the line of sight vector lies in the near-polar orbital plane. Under these conditions, Appendix A shows that the maximum contribution to the Doppler frequency due to Earth rotation occurs at the equator. The Doppler component is:

f rE=

⋅ ×≤ =

ρ υλ ρ( ) .31 5 167 m / sec

0.1884 m Hz

We will include this component with the satellite Doppler, for a total of 35.3 kHz, worst case.

For completeness, the case of the minimum elevation angle of 8.2o must still be considered. Using the IRIDIUM orbital parameters, it can be shown that the worst case elevation angle occurs only when the space vehicle is nearly due east or west of the receiver. In this case, the line of sight vector, ρ , and the space vehicle velocity vector, VSV , are nearly perpendicular and the Doppler frequency due to orbital motion is near zero. Actual computation yields a space vehicle Doppler frequency of 128 Hz at an 8o elevation angle.



When the line of sight vector lies due east or west, however, the component of the Doppler frequency due to earth rotation is maximized. This maximum value is given by

EQ. 9 f rE

o

= =υ

λcos .8 2 2437 Hz .

Doppler Allocation for Aircraft Velocity The residual allocation of +2.2 kHz can be expressed in terms of an aircraft

velocity by means of the classical Doppler frequency equation, also expressed in Appendix A..

EQ. 10 f vDA = −

cosαλ

,

where α is the angle between the aircraft velocity vector and the line of sight unit vector, and v is the magnitude of the aircraft velocity.

In the worst case, the aircraft velocity is exactly aligned with the satellite velocity and a direct addition takes place. In fact, because the worst case space vehicle velocity takes place at an elevation angle of 13.4o such a worst case combination would require that the aircraft simultaneously be climbing and reaching maximum velocity. Note that an elevation angle of 13.4o is equivalent to a climb of 7000 feet/minute at 300 kt. Simple physics argue against such a condition for most commercial and private aircraft. It is much more likely that the maximum aircraft velocity occurs in straight and level flight. In this case, the angle between the velocity vector and the line of sight is simply the elevation angle, β .

Knowing the worst case elevation angle for space vehicle Doppler and the maximum allowable frequency offset, EQ. 9 can now be used to solve for the maximum aircraft velocity.

EQ. 11 v

fDA=

= = =

λβcos

( .cos( .4)

2200 0 184413

426 Hz)( m) m / sec 828 kt

Thus, the allocation of +37.5 kHz for Doppler accounts for the simultaneous occurrence of a worst case satellite Doppler contribution velocity and an aircraft velocity in level flight of 828 kt.

In the "due East/West" case, which maximizes the effects of earth rotation and exposes the aircraft to the minimum elevation angle, the maximum Doppler due to aircraft motion is



EQ. 12 fV f

AC

A AC

= − − =

= = =

37500 2437 128 349356582 12 794

Hz m / sec ktλ ,

This is clearly sufficient for all purposes.

Tracking Mechanization Mike Andresen's presentation at the January 1998 IRIDIUM aeronautical system review provides evidence that the modem mechanization supports the frequency offsets and maneuvers assumed in this memorandum. This presentation is still Motorola / AlliedSignal confidential and proprietary, and may not be released at this time. Suffice it to say that the Doppler tracking and synchronization time tracking algorithms have sufficient bandwidth and dynamic range to track the frame-to-frame changes of Doppler frequency and time delay under conditions worst case aircraft dynamics in the range of 4g acceleration and Mach 4.



Appendix A: Space Vehicle Doppler Frequency Define the Earth Centered Inertical (ECI) coordinate frame as follows:

x-axis passing through the center of the spherical earth and the point defined by the intersection of the equator and the prime meridian at the time of the vernal Equinox. y-axis passing through the center of the spherical earth and the point defined by the intersection of the equator and the meridian of 90o East Longitude at the time of vernal Equinox. z-axis passing through the center of the spherical earth and the North Pole, and forming the axis of rotation for the Earth.

The origin of the x-y-z system is taken as the center of the spherical earth. The ECI is a non-rotating frame. The Earth Centered Earth Fixed (ECEF) coordinate frame is defined as a frame fixed with respect to the surface of the earth defined as follows:

x-axis passing through the center of the spherical earth and the point defined by the intersection of the equator and the prime meridian. y-axis passing through the center of the spherical earth and the point defined by the intersection of the equator and the meridian of 90o East Longitude. z-axis passing through the center of the spherical earth and the North Pole, and forming the axis of rotation for the Earth.

The ECEF frame rotates with respect to the ECI frame with an angular velocity of approximately 7.27 x 10-5 radians/sec. ECEF and ECI are aligned once every sidereal day. The satellite orbits are defined in ECI. The line of sight vector from the aircraft to the satellite is the vector difference.

EQ. A- 1 ρ = −S A .

The Doppler frequency is computed by the well-known formula:



EQ. A- 2 fD =⋅ρ ρ

λ ρ

Substituting

EQ. A- 3 f S A S AS A

D =− ⋅ −

−

( ) ( )λ

The only difficulty is in computing the aircraft velocity vector in the proper coordinate frame. Whether it is stationary or moving, we measure the aircraft velocity relative to the Earth's surface, i.e., in the ECEF frame. Fortunately, the Coriolis operator provides a direct means of computing the aircraft velocity in the ECI frame, where it can be combined with the know satellite position and velocity vectors.

EQ. A- 4

ddt

ddt

r

d Adt

d Adt

r

A V r

FIXED ROTATING

FIXED ROTATING

A

(*) (*) ( )

( ) ( ) ( )

( )

= + ×

= + ×

= + ×

ω

ω

ω

In this expression, the ECI aircraft velocity is A , while the velocity vector relative to the ground is VA . Substituting all of this into the Doppler computation:

EQ. A- 5 f

S V r

S V r

DA

A

=⋅ − − ×

=⋅ − ⋅ − ⋅ ×

ρ υλ ρ

ρ ρ ρ υλ ρ

( ( ))

( )

The numerator terms break out cleanly into a term due to only to satellite motion, a term to only to aircraft velocity, as measured in the ECEF frame, and a term due solely to Earth rotation. The total Doppler frequency is the arithmetic sum (or difference) of these values. By the definition of the dot-product, each of the terms depends on the cosine of the angle between the appropriate velocity vector and the line of sight vector.



The relative magnitudes of the terms are related to the magnitudes of the various velocities. The first term is due to satellite motion, and its magnitude is proportional to the space vehicle velocity. The orbital angular velocity, ω , is computed from the standard orbital mechanics as

EQ. A- 6 ω μ= =

×+ ×

=R3

14 2

6

3 986 106 378 770 10

0 00105( . / sec )(( . . )

. m m)

rad / sec3

3

The velocity is ωR = 7467 m / sec . The dot product achieves its maximum when the line of sight vector, ρ , lies in the orbital plane. In this case, the angle between the line of sight vector and the velocity vector is determined by only by the satellite position. For any line of sight vector which does not lie in the orbital plane, the dot product is reduced by the cosine of the angle between the line of sight vector and the orbital plane. The second term is due to aircraft velocity. The magnitude is proportional to the aircraft ground speed, which, for the moment, we will assume to be 750 kt, or 386 m/sec. Notice that the magnitude of this term is only 5% of the space vehicle velocity. If we make the reasonable assumption that the maximum velocity is attained during straight and level flight, the Doppler frequency is determined by the cosine of the elevation angle to the satellite and to cosine of the angle between the velocity vector and the orbital plane. The third term is due to Earth rotation, and is a function of the aircraft's latitude. The maximum value occurs at the equator. The maximum velocity is ωr = 464 m / sec. If all three components were co-planer, the maximum velocity would be the sum of the three terms, or about 44.2 kHz. The near-polar nature of the IRIDIUM orbits makes this impossible. The SV velocity is approximately 19 times larger than the assumed aircraft velocity, and approximately 16 times larger than the effects of Earth rotation. Therefore the SV component dominates the Doppler frequency. As noted above the SV component is maximized whenever the line of sight lies in the orbital plane. If we assume a true polar orbit, this means that the third term component υ × r is always perpendicular to the line of sight and the contribution of Earth rotation to the Doppler frequency is zero. Even when we relax the polar orbit assumption to the true IRIDIUM orbital inclination of 86.1o, the projection of υ × r into the orbital plane amounts to an effective in-plane velocity of only υ ϕ× =r ocos . ( .86 1 31 5 m / sec)cos , where ϕ is the aircraft latitude.1

If we constrain the line of sight to the orbital plane in order to maximize the Doppler contribution of the space vehicle velocity, we have the situation inError!

1 Assuming a spherical earth.



Reference source not found.. Using the nomenclature defined in Table 1 and Figure A-1, we have.

Figure A- 1: Geometry for SV Doppler Computation

EQ. A- 7 fD = −⋅ρ ρ

λ ρ

EQ. A- 8 ρωω

=LNM

OQP −

LNMOQP

R tR t

rcossin 0

EQ. A- 9 sin

cosρ

ω ωω ω

=−LNM

OQP −

R tR t

vac

EQ. A- 10 f

R tR t

r R tR t

v

D

ac

= −

LNM

OQP −

LNMOQP

FHG

IKJ ⋅

−LNM

OQP −

FHG

IKJ

cossin

sincos

ωω

ω ωω ω

λ ρ0

To evaluate the satellite component only, we assume the aircraft to be stationary,

vac =LNMOQP

00

. Then

R

r

ρ

β

v

Space Vehicle Orbit

Earth Surface



EQ. A- 11

f R t t Rr t R t tR Rr t r

Rr tR Rr t r

RrR Rr r

DS = −− + +

− +

=−

− += =

=−

− +

( cos sin sin ) ( cos sin )( cos )

sin( cos )

,

sin( cos )

2 2

2 2

2 2

2 2

2

2

2

12

12

12

ω ω ω ω ω ω ωλ ω

ωλ ω

ω

λ

t Earth Centered AngleΘ

Θ

Θ

Since both numerator and denominator are functions of Θ , we should check to find the minimum and maximum.

EQ. A- 12 dfdt

Rr R Rr r R rR Rr t r

DS =− + −− +

ω ωλ ω

2 2 2 2 2 2 2

2 2

22

32

cos ( cos ) sin( cos )

Θ Θ Θ,

which we set equal to zero to obtain the minimums. Note that the denominator is never zero, since R and r are not equal. Thus we can solve for the numerator equal to zero. After some algebra, we get an equation in cos2 Θ :

EQ. A- 13 0 2 2 2= − + +Rr R r Rrcos ( )cosΘ Θ

Using the quadratic formula:

EQ. A- 14 cos ( ) ( )Θ =

+ ± −R r R rRr

2 2 2 2

2

Because R > r, the plus sign yields a cosine greater than 1, and the only meaningful solution is uses the subtraction sign.

EQ. A- 15 cosΘ = =22

2rRr

rR

,

which is, of course, the equation of the right triangle when the space vehicle is on the horizon. Thus the maximum Doppler shift occurs on the horizon. From EQ A-4, the minimum magnitude of the Doppler shift occurs at Θ = 0 . The Doppler frequency induced by the satellite increases as the satellite approaches the horizon. Now return to the component due to aircraft motion, under the constraint that the line of sight vector remain in the orbital plane. Then



EQ. A- 16

fV

V

DAAC

AC

=⋅

=

ρλ ρ

α

λ

cos

where α is the angle between the line of sight vector, ρ ,and the aircraft velocity, VAC . Obviously, EQ. A-10 is maximum when α = 0, i.e. when the velocity lies along the line of sight. The maximum and minimum Doppler effects are therefore found for satellite positions near the horizon and for aircraft motion along, or very near, the line of sight to the satellite. Since the satellites lie above the local horizon, this implies that the maximum Doppler for a given aircraft velocity occurs during straight and level flight. Finally, a few words about the three dimensional generalization of the results of this appendix. In this appendix, we have assumed that the orbit is circular and that the aircraft is travelling in the orbital plane, although obviously not at the orbital radius. In fact, this is rarely the case. In the true three-dimensional case, the orbital plane is rotated in around the vertical axis of Figure A-1. In this case, both the line of sight vector and the orbital velocity are no longer co-planar. The effect of this rotation is decreasing the magnitude of the vector sum of aircraft and satellite velocities. Maximizing the aircraft Doppler component, which is still expressed by EQ. A-10, causes the aircraft velocity vector to lie along the line-of-sight vector, which, by definition, no longer lies in the orbital plane. Therefore the satellite-induced Doppler component is no longer maximum. Therefore, the current analysis, which assumes co-planar aircraft and satellite motion is the worst case, and is, in fact, the only case in which the scalar velocities can be directly added or subtracted.



Appendix B: Derivation of LOS range as a function of elevation angle Using the nomenclature of Figure A-1 and Table 1, we have, with the Law of Sines.

EQ. B- 1 ρπ βsin sin sin( )Θ

= =+

rB

R

2

Using the first and last ratio to solve for ρ;

EQ. B- 2 ρβ

=R

cossinΘ

Using the triangle, we have,

EQ. B- 3 π π β

π β

= + + +

= − +

Θ

Θ

B

B

2

2( )

Using EQ B-3 and the second and third ratios of EQ B-1:

EQ. B- 4 sin cos cos( )B rR

= = +β βΘ

So we can now write an equation for Θ;

EQ. B- 5 Θ = −−cos ( cos )1 rR

β β

Finally, combining EQ B-5 and B-2 gives the desired result:

EQ. B- 6 ρβ

β β= FH

IK −

LNM

OQP

−R rRcos

sin cos cos1 .


ANNEX B

WORKING PAPER 598

Priority, Precedence and Preemption for AMS(R)S in the Iridium System

January 1999

Page – i of Iridium AMS(R)S Validation Report Annex B


AMCP/WGA-WP/598

AERONAUTICAL MOBILE COMMUNICATIONS PANEL Working Group A Meeting No. 14

Phoenix, Arizona 19-29 January 1999

Agenda Item 5 Next generation satellite system (NGSS) acceptability

PRIORITY, PRECEDENCE AND PREEMPTION FOR AMS(R)S IN THE IRIDIUM SYSTEM

Presented by Iridium/AlliedSignal

(Prepared by R. Hobby and E.F.C. LaBerge)

1 INTRODUCTION 1.1 The aeronautical communications data and voice services to be offered by Iridium are described by four major categories, as follows. The first two categories (ATS and AOC) are referred to as "safety" communications; and the last two, as "non-safety" communications.

• ATS - Air Traffic Services - including air traffic control, and weather information provided by civil aviation administrations; e.g., the FAA.

• AOC - Aeronautical Operational Control - primarily communications from an aircraft operator's operational control center that affect the safety and regularity of flight.

• AAC - Aeronautical Administrative Communications - for example ticketing, special orders, passenger related information.

• APC - Aeronautical Public Correspondence - personal communications by/for passengers. 1.2 Safety services include circuit switched voice and packet data services. ATS and AOC communications require the system to support priority, precedence, and preemption. As used within this paper, these terms are defined as follows: 1.2.1 Priority - an attribute of a communication or communication channel that indicates its importance or urgency relative to other communications or communication channels carried in the system at the same time.

This paper describes the Iridium satellite communication system scheme for aeronautical priority, precedence, and priority (PPP), to support AMS(R)S and AMSS traffic in its implementation of an Aeronautical Mobile Satellite Service for aviation users.


AMCP/WGA-WP/598 -2-

1.2.2 Precedence - action taken by a network element of a system to order its work according to priority when faced with multiple simultaneous communication events, e.g., packets of higher priority enter a communication channel ahead of lower priority packets. 1.2.3 Preemption - action taken by a congested network element of a system to deny service to a lower-priority communication while handling higher-priority communications, or to remove resources from lower-priority communications in order to handle a new higher-priority communication. 1.3 The implementation of aeronautical PPP is captured as a set of design requirements that are currently being implemented for introduction into service in 1999. Functionality for aeronautical PPP is required in the avionics (AESs), the gateways (GESs) and the satellites. 2 THE IRIDIUM SYSTEM RESOURCE MANAGEMENT AND AERONAUTICAL PPP 2.1 The basis for aeronautical PPP is the set of mechanisms designed for, and already implemented in, the Iridium System for signaling and system management purposes. The commercial Iridium System utilizes two tiers of resource management to assure access to communication channels for priority users, and to protect the system from aberrant or fraudulent terminals. These tiers operate in temporal sequence for each call through the system and are common for all users. The implementations of these tiers have been modified to incorporate AMS(R)S in the system. They are: Tier 1 - Acquisition Class control, and Tier 2 - Priority Class control. 2.2 Tier 1 -- Acquisition Class. The Acquisition process is one of several protocols completed between a terminal and the satellite constellation for each call set up in either direction. Its purpose is to assure that overall system resources, at a macro level, remain available optimally and fairly to AMS(R)S users. For example, traffic accepted may need to be restricted or ‘throttled’ in accordance with a predicted, impending overload of the system resources, or due to a local or regional emergency. 2.2.1 Among the information exchanged between a terminal and its current serving satellite is the Acquisition Class, which will be one of the 16-level hierarchy of priorities arranged in descending order as follows: Acquisition Class User Identity 15 (highest) Iridium System use only (Satellite safety) 14 AMS(R)S 11, 12, 13 Reserved 10 Emergency Calls 0-9 (lowest) Regular MSS 2.2.2 At provisioning time, normal commercial terminals are randomly assigned an Acquisition Class in the range 0 through 9. This number is captured in the Subscriber ID. The first Acquisition Classes to be denied service are those in classes 0 through 9; then in order 10, 11, 12, 13, 14, until the only communications allowed are for the safety of the satellite itself. 2.2.3 A terrestrial emergency call from a mobile terminal (for example, a "911" call originating in the U.S.A., or "999" originating in the U.K., or "112" originating in GSM networks) will temporarily override the terminal's assigned Acquisition Class, and will, for the duration of that call, assign Acquisition Class 10. Acquisition Class 15 is reserved for use by the satellites and the network control center for use only when necessary to protect the one or more satellites in the constellation.


AMCP/WGA-WP/598 -3-

2.2.4 The highest-level Acquisition Class that can be assigned to a terminal (14), is assigned to all aeronautical terminals that are approved for AMS(R)S. Thus, AMS(R)S terminals are the last terminals to be denied service in the event of a system-threatening event. 2.2.5 The aeronautical terminals that are approved for AMS(R)S also support non-safety communications. All non-safety communications use an Acquisition Class in the range 0-9. 2.3 Priority Class. Each satellite has mechanisms that determine the priority of queuing for in-progress calls to be handed off among beams or the succeeding serving satellite. AMS(R)S traffic receives priority over non-AMS(R)S traffic in the beam-to-beam and satellite-to-satellite handoff process. 2.3.1 To allow the priority of a call to be maintained by the network for the duration of the call, during each inter-satellite handoff the priority code is included in the call overhead messaging between the satellites. The high (aero safety) priority calls are queued for handoff before those calls of lower priority. 2.3.2 Within the AMS(R)S Acquisition Class (number 14), three levels of precedence are defined. Consequently, AMSS communications are handled internally within the Iridium System with four levels of precedence: AMS(R)S #1, AMS(R)S #2, AMS(R)S #3 and AMSS Non-Safety). The fourth level, AMSS Non-Safety, is treated by the system as "normal" traffic corresponding to Acquisition Classes 0-9 of paragraph 2.2.1. The multiple levels of priority stemming from the Radio Regulations will be mapped into these four Iridium priority levels. 2.3.3 Taking into account the separate mechanisms that determine the resources initially needed to establish a call and the resources needed to maintain that call during its course (e.g., inter-beam and inter-satellite handoffs), the processing order established in each satellite is as follows: a) AMS(R)S Handoff Request b) AMS(R)S #1 Priority Aero Acquisition Request c) AMS(R)S #2 Priority Aero Acquisition Request d) AMS(R)S #3 Priority Aero Acquisition Request e) Lower Priority (Normal Call) Handoff Request f) Lower Priority (Normal Call) Acquisition Request. 3 ADDITIONAL PPP MANAGEMENT TIERS FOR AMS(R)S 3.1 Two additional tiers of PPP resource management have been added to the Iridium System specifically for AMS(R)S. These tiers are: Tier 3 - Preemption and Precedence, and Tier 4 - Input/Output Queuing for Call/Message Priorities. 3.2 Preemption and Precedence. Tier 3, preemption of system resources if necessary for safety communications traffic, and internal control mechanisms to assure precedence of AMS(R)S levels of precedence, are added features for AMS(R)S. The mechanization of preemption relies on the existing Acquisition Class protocol and features described in paragraph 2.2.


AMCP/WGA-WP/598 -4-

3.2.1 Noting the Acquisition Class hierarchy defined in paragraph 2.2.1, class number 14 is assigned to AMS(R)S, the highest-level class for Iridium System traffic. Acquisition Class 14 is given an additional attribute to cause the Iridium System to immediately clear calls of lower-level classes as necessary, in the same load-shedding order as previously described. Thus, the entire Iridium System's capacity is potentially available for AMS(R)S traffic. In the ultimate, extremely unlikely, situation all capacity can consumed by AMS(R)S #1 traffic. 3.2.2 As most traffic in the Iridium System will be made through individual single-channel commercial handset terminals, the clearing of a lower-level call is made via a shutdown/release command to the involved terminal. 3.2.3 The preemption process is completed within milliseconds, and adds no more than 250 milliseconds to the call setup delay that would have been experienced if preemption were not required. 3.2.4 It is to be noted that, because the identity and class of each terminal is involved in the Acquisition Class protocol for each call in either direction, only AMS(R)S terminals can invoke the AMS(R)S Acquisition Class, and then only for AMS(R)S traffic. 3.3 Input/Output Queuing for Call/Message Priorities. As the first three tiers of PPP management cater to a complete set of internal system controls, Tier 4 provides for the appropriate identification and establishment of precedence for AMS(R)S traffic presented to either an AES or a GES, in accordance with the priority levels defined for an AMS(R)S air/ground communications subnetwork. These capabilities are intrinsic to the protocol machines that interface the Iridium Aeronautical System with its external users, and reside in the AMSS AESs and GESs. The mapping of the input and output priority structures for data and voice are in accordance with the requirements of MASPS, MOPS and SARPs, and with ITU Radio Regulations. 4 SUMMARY 4.1 A complete set of mechanisms for handling PPP consistent with standards for aeronautical safety communications (AMS(R)S) has been designed for the Iridium Aeronautical System. These mechanisms take advantage of similar mechanisms for internal resource management already implemented in the Iridium System. 4.2 Regarding the preemptive features from the perspective of Radio Regulations, the actions for communications in the Earth-to-space (air-to-ground) and space-to-Earth (ground-to-air) directions are displayed in Figures 1 and 2, respectively.


AMCP/WGA-WP/598 -5-

Figure 1. Ground-to-Air Preemption Flow Chart

1. AMS(R)S voice and/or AMS(R)S packet-data traffic arrives at the AES from the flightdeck

2. The AES recognizes an AMS(R)S circuit/packet and signals the satellite that it eeds to establish AMS(R)S communications

Preempt a non-AMS(R)S call by sending a release

message to an MSS terminal

Connect AES and GES using available

resources YES NO

Are L-Bandresources

available forthis AMS(R)S

communication?

Figure 2. Air-to-Ground Preemption Flowchart

1. AMS(R)S voice and/or AMS(R)S packet-data traffic arrives at the GES2. The GES sends a message to the satellite constellation indicating the need for an AMS(R)S call, and its associated Q-level, for a specific aircraft3. The serving satellite sends a Ring Alert to the AES flightdeck4. The AES recognizes that this message is AMS(R)S, and signals to the satellite that it needs to set up an AMS(R)S call

Are L-bandresourcesavailable?

Preempt a non-AMS(R)Scall by sending a releasemessage to a MSSterminal

YESConnect AES and GES

NO


ANNEX C

IRIDIUM-EFCL-0143A

Effects on Iridium Availability Due to Satellite Failures

June 13, 1999 – modified January 25, 2000

Page – i of Iridium AMS(R)S Validation Report Annex C


Released to SC-165 WG-3 June 15 1999

MEMO Number IRIDIUM-EFCL-0143A DATE: June 13, 1999 modified Jan 25, 2000 TO: RTCA SC-165/WG-3 FROM: E.F.C. LaBerge SUBJECT: Effects on Iridium Availability due to Satellite Failures Introduction Tech note Iridium-EFCL-0138, released to SC-165/WG3 as SC-165/WG3-WP/534, used a novel method to provide a first order estimate the availability of the Iridium Communications System for aeronautical safety services. Although AlliedSignal and Iridium stand by that earlier document, it has generated sufficient questions that an update based on a more complete analysis is required. This tech note/working paper provides the first installment of such an analytical update. In this paper, we again focus on the effects of a total failure of an Iridium satellite. but extend our analysis based on the orbital dynamics of the satellites and the minimum elevation angle of 8.2o supported by the aeronautical link budgets presented previously to WG3. Background

The Iridium Communications System consists of satellites and related infrastructure including the master and backup control facilities, the Gateways and associated tracking, telemetry and control facilities. The space segment utilizes a constellation of 66 operational satellites in low-Earth orbit.

The satellites are located in six distinct planes in near polar orbit at an altitude of approximately 780 kilometers and circle the Earth approximately once every 100 minutes. The six co-rotating planes are spaced 31.6o apart in longitude, resulting in a spacing between Plane 6 and the counter-rotating portion of Plane 1 of 22o. Satellites are evenly spaced within each plane. Satellite positions in adjacent odd and even numbered planes are offset from each other by one-half of the satellite spacing. Figure 1 illustrates the Iridium constellation, with orbits drawn to scale on an idealized spherical Earth.

Page: 1 EFCL0143A Satellite Induce Outages saved 1/27/2000 9:04:00 PM printed 2/16/2005 9:02:00 AM



Figure 1: Iridium Constellation (orbits to scale) The Iridium Satellites are significantly closer to the Earth than geostationary

satellites that orbit at nominal altitudes of 35,800 kilometers. The low orbit of the satellites enable the Iridium System to maintain its link margins and provide effective communications with portable, hand-held Individual Subscriber Units (ISUs) as well as other L-Band subscriber equipment such as Iridium aeronautical terminals.

Each satellite includes three phased array antennas, each of which containing an array of transmit/receive modules) communicates with subscriber units through tightly focused antenna beams that form a continuous pattern on the Earth’s surface. The phased array antennas create a total of 48 spot beams for each satellite, arranged in the configuration shown in Figure 2 . These arrays are design to provide user-link service over the 1614-1626.5 MHz band. In the United States and most other countries, Iridium user links are licensed for only the upper portion of this band, 1621.35-1626.5 MHz The near polar orbits of Iridium Satellites cause the satellites to get closer together as the sub-satellite latitude increases. This orbital motion, in turn, causes the satellite coverage to increasingly overlap as the satellites approach the poles. A consistent sharing of load between satellites is maintained at high latitudes by selectively deactivating outer ring spot beams in each satellite. This beam control also results in reduced intersatellite interference.




Approximate SVvelocity vector

Figure 2- Iridium Space Vehicle Spot Beam Footprint The result of the composite pattern of all 48 spot beams is cap-shaped coverage area on the surface of the Earth with a roughly circular perimeter, as shown in Figure 3. The circular perimeter, with a flat-plane diameter of about 5000 km, is determined by the minimum elevation angle supported by the link budget. For Iridium, this minimum elevation angle is 8.2o.

~2500 km

Satellite

Sub-SatellitePoint

Figure 3: Iridium Single Satellite Coverage Cap, Sub-Satellite Latitude 0o, Shown

with Six Nearest Neighbors




The case illustrated by Figure 3 has the central satellite just passing over the equator and illustrates the case of minimum coverage overlap between adjacent satellite planes. With an inclination of 86.4o, the Iridium constellation orbits are nearly polar and can be approximated by meridians of longitude, as shown in Figure 1. Like meridians, the satellites approach each other at the poles, resulting in increasing overlap in coverage area as the sub-satellite latitude increases, as shown in Figure 4.

Figure 4: Iridium Single Satellite Coverage Cap, Sub-Satellite Latitude 45o, Shown with Six Nearest Neighbors Iridium manages this increasing overlap in coverage by selective deactivating spot beams in the overlap region to conserve constellation resources. Despite the fact that this deactivation occurs during normal operation, the deactivated spot beams are available as near-immediate back up should a particular satellite, or a particular spot beam on a particular satellite, be unable to provide user communications services. In the ultimate case, the near-polar orbits provide a six-fold redundancy for points near the Earth's poles. The effects of a satellite outage can be estimated by observing the changing shape of the "non-overlap" region as the sub-satellite latitude changes. We can clearly see this effect by comparing Figure 3 and Figure 4. We notice that the area is significantly smaller in the east-west dimension, and somewhat reduced in the north-south dimension. This means that fewer users will be affect by satellite outages (due to east-west shrinkage) and that the users who are affected will be affected for shorter periods of time (north-south shrinkage). We will shortly demonstrate that the increasing redundancy offered by the near-polar orbits eliminates the effects of a single satellite failure for users at latitudes above 60o North and 60o South. This is shown in detail in Figure 5.




LATITUDE 0o OUTAGE < 9 min LATITUDE 50o OUTAGE < 3 min

LATITUDE >62o NO OUTAGE LATITUDE 60o OUTAGE < 1 min

Figure 5: Effects Single Catastrophic Satellite Failures It is clear from Figure 3, Figure 4, and Figure 5 that the statistics of satellite outages depend heavily on the user latitude. It is less obvious, but still undeniable, that the statistics also depend on the longitude of the user with respect to the sub-satellite point. Both the likelihood that a user experiences a loss of service due to a satellite failure and the duration of any such outage are significantly reduced for users who a mid-way between the orbital planes. Furthermore, the inter-outage interval, i.e., the length of time between two consecutive outages depends significantly on the relative location of the user with respect to the sub-satellite point at the time of the initial outage. Users who experience limited-duration outages because they are west of the sub-satellite point at their latitude may experience a second outage, also of limited duration, during the next orbit. If the user is at the sub-satellite point or further east, however, the next outage will not occur for approximately 12 hours, that is until the Earth rotation carries him under the retrograde portion of the satellite orbit. This last point raises the question of how aircraft motion should be included in the computation of satellite outage effects. After considering a number of options, I have considered that, on the average, the most appropriate means for dealing with aircraft motion is to assume that the aircraft remains stationary during the outage and between outages. It is true that this is not strictly accurate. On the other hand, if we assume that an aircraft is equally likely to travel east as west, and equally likely to travel north as south, then relative aircraft motion cancels out. This seems appropriate, since the concept




of availability is itself related to long term averages and not instantaneous or short term computations. Analysis Methodology Computing the area of the circular coverage cap is a relatively straightforward exercise in calculus, but computing the area of single satellite coverage, as illustrated in Figure 3 and Figure 4, is not a tractable problem with a closed-form solution. Therefore, we will estimate the loss of availability due to a single satellite failure by approximating the total length of time that the failed satellite is the only satellite visible above the 8.2o mask angle. To compute this time, we follow a simple process:

1. select a user latitude 2. select a user longitude with respect to the sub-satellite point 3. for all satellite positions during the orbital repeat period check to see if

the failed satellite is the only visible satellite above the mask angle 4. accumulate all times for which the criteria of Step 3 is satisfied 5. repeat Steps 1-4 for user longitudes uniformly distributed about the

sub-satellite longitude. 6. repeat Steps 1-5 for user latitudes 0o to 90o.

To implement this process, we need to know the "orbital repeat period", that is, the interval over which the ground track repeats. As shown in Appendix A, this interval is almost exactly three days (72 hours). Consequently, we use a value of 72 hours, or 259,200 seconds, for the Step 3 computations. We compute the position of all seven satellites (one failed plus six nearest neighbors, as shown in Figure 3), once every ten seconds, and check for the conditions of Step 3 at each computation point. An aeronautical user experiences the worst-case elevation angle of 8.2o when he is due east (or west) of the satellite and his difference in longitude from the sub-satellite point is approximately two-thirds of the orbital plane spacing toward the next plane to the west (or east). If the user is any closer to the western (or eastern) plane, he will never switch to the low angle satellite. If he is closer to the eastern plane, the elevation angle will exceed the 8.2o minimum. Consequently, in Step 5, we examine 101 points evenly spaced in longitude over an angle of ± 5

8θ RA RA, where θ is the spacing of the right

ascending nodes of the orbital planes, or 32.7o. Results

Unavailability The result of the computation is a conditional unavailability, conditioned on the

user latitude , and the number of satellite failures, one, and averaged over all possible initial user longitude and over the orbital repetition interval. The conditional unavailability is plotted as a function of latitude in Figure 6. For the purpose of computing this curve, every outage indicated in the histograms of Appendix B was counted. This clearly provides an upper bound on the conditional unavailability, because




relatively short outages, will not be counted as unavailability. The additional curves in Figure 6 illustrate the conditional unavailability excluding outages short than 60 seconds and shorter than 100 seconds. The curves are, in order from top to bottom: all outages, outages greater than 60 seconds, outages greater than 100 seconds. There is obviously no significant difference over this range of definition of the terms "outage".

0 10 20 30 40 50 60 70 80 900

0.002

0.004

0.006

0.008

0.01

0.012

0.014

Observer Latitude (deg)

Pr[S

ervic

e O

utag

e | K

now

n O

utag

e, K

now

n La

titud

eElevation Mask Angle: 8.2 deg, tmin = [0 60 100]

Figure 6: Conditional Unavailability Given Known Latitude, Known Single Failure

To establish an availability value over a specific area of the Earth – North America or Western Europe, for example – we must integrate out the conditional dependence on latitude. That is:

U U( ) ( | , ) ( |Europe | single satellite failure Europe sec

sec

deg

deg

= p d d)zz τ α α τ α10

600

45

80

Λ

where pΛ ( | )α Europe is the probability density function of air traffic using Iridium within Europe as a function of latitude. Let us examine two possible scenarios.

First, assume that potherwise

MAX MINMIN MAX

Λ ( |α θ θθ θ θEurope) =

1

0−

≤ ≤RS|T|

, that is, assume

that the air traffic is uniformly distributed in latitude. Then we can numerically integrate any of the curves in Figure 6 to get an overall average unavailability,

. U(Europe|1 failure) = 0.0023 Under a more reasonable estimate that air traffic over Europe is concentrated between the latitudes of Paris (~48o N) and London (~52o N), we could model the traffic as a Gaussian distribution with mean 50o N and variance 25 degrees-squared. Then




pΛ ( | exp( ( ) )απσ

α µσ

µ

σ

ο

Europe) = 12

degrees2

2

2

2

2

2

50

25

−−

=

=

Again by performing the integration numerically, U . (Europe|1 failure) = 0.0068 Finally, we can compute the unavailability over a particular region, Europe in this example, by multiplying the conditional unavailability by the probability that a single failure occurs.1 Using the standard assumption of six satellite failures per year in a constellation of 66 satellites, we have: U U

U

( (

(

. . .

Europe) = Europe|single failure) Pr{single failure}

= Europe|single failure) 666 (uniform assumption)

= 0.0068 0.0909 = 6.2 10 (Gaussian assumption)-4

×

×

= × = ×

× ×

−0 0023 0 0909 2 1 10 4

Using the fundamental theorem of probability, then, we can estimate the availability as: A USAT = −

==

10 999790 99938..

(uniform) (Gaussian)

Outage Duration A byproduct of the methodology detailed earlier is a series of statistics of the duration of any outage as a function of latitude. These statistics can be directly derived from the histograms in Appendix B. Figure 7 illustrates the maximum, 95th percentile, mode and mean of the outage duration determined in this manner.

1 The second order effects, i.e. a second failure, effects of restoration time, etc. remain to be considered and are not covered in this tech note. Page: 8 EFCL0143A Satellite Induce Outages saved 1/27/2000 9:04:00 PM printed 2/16/2005 9:02:00 AM



0 10 20 30 40 50 60 70 80 900

100

200

300

400

500

600

O bs e rve r La titude (de g)

Out

age

Dur

atio

n (s

ec)|

Kno

wn

Out

age,

Kno

wn

Latit

ude

Ma x, 95% -ile , Mode , Me a n

Maximum

95%ile

Mode

Mean

Figure 7: Outage Duration Statistics




Appendix A Computation of Orbital Repeat Period

(revised 25 Jan 2000 to correct minor error in TGT)

From Kepler's equations of orbital motion for circular orbits:

T R=

=+ ××

=

2

2 6 378 770 103986 10

602713

3

6

14 2

πµ

π (( . . )( . / sec ).

m) m

sec

3

3

The number of orbits each day is thus:

NDay = =86400 14 335 sec / day

6027.13 sec / orbit orbits / day.

And the number of days before the ground track is repeated is:

TN NGT

Day Day

≈−

=

= ≈

1

10 335

30

, * "

..

greatest integer less than"

days




Appendix B

Unavailability Histograms U ( ) }τ τ= Pr{system outage duration = U

U U k p p p kNk

( | ,|

( ) ( | , , ) ( ) ( ) ( )

τ α θτ λ θ

τ τ α θ α θ

Λ Θ Φ

Λ ΘΘΛ

= , = = N) = Pr{ outage duration = latitude = , relative longitude = , N satellites failed}

==

∑zz1

66

The following histograms give U p( | , , ) ( )τ α θ θ θθ1

Θ

dz , where

, i.e., the initial user longitude is uniformly

distributed and symmetric with respect to the sub-satellite point.

p RA RA RAΘ ( )

.θ

θ θ θ=

≤ ≤RST−0 8 0 6250

1 - 0.625 otherwise

. θ

0 100 200 300 400 500 6000

0.5

1

1.5

2

2.5x 10

-3

Outage Duration in Seconds

U(D

urat

ion|

Kno

wn

Sin

gle

Fai

lure

, Kno

wn

Latit

ude)

Latitude: 0

0 100 200 300 400 500 6000

0.5

1

1.5

2

2.5x 10

-3


U(D

urat

ion|

Kno

wn

Sin

gle

Fai

lure

, Kno

wn

Latit

ude)

Latitude: 10




0 100 200 300 400 500 6000

0.5

1

1.5

2

2.5x 10

-3


U(D

urat

ion|

Kno

wn

Sin

gle

Fai

lure

, Kno

wn

Latit

ude)

Latitude: 20

0 100 200 300 400 500 6000

0.5

1

1.5

2

2.5x 10

-3


U(D

urat

ion|

Kno

wn

Sin

gle

Fai

lure

, Kno

wn

Latit

ude)

Latitude: 30

0 100 200 300 400 500 6000

0.5

1

1.5

2

2.5x 10

-3


U(D

urat

ion|

Kno

wn

Sin

gle

Fai

lure

, Kno

wn

Latit

ude)

Latitude: 40

0 100 200 300 400 500 6000

0.5

1

1.5

2

2.5x 10

-3


U(D

urat

ion|

Kno

wn

Sin

gle

Fai

lure

, Kno

wn

Latit

ude)

Latitude: 45

0 100 200 300 400 500 6000

0.5

1

1.5

2

2.5x 10

-3


U(D

urat

ion|

Kno

wn

Sin

gle

Fai

lure

, Kno

wn

Latit

ude)

Latitude: 48.333

0 100 200 300 400 500 6000

0.5

1

1.5

2

2.5x 10

-3


U(D

urat

ion|

Kno

wn

Sin

gle

Fai

lure

, Kno

wn

Latit

ude)

Latitude: 50

0 100 200 300 400 500 6000

0.5

1

1.5

2

2.5x 10

-3


U(D

urat

ion|

Kno

wn

Sin

gle

Fai

lure

, Kno

wn

Latit

ude)

Latitude: 51.666

0 100 200 300 400 500 6000

0.5

1

1.5

2

2.5x 10

-3


U(D

urat

ion|

Kno

wn

Sin

gle

Fai

lure

, Kno

wn

Latit

ude)

Latitude: 54.999




0 100 200 300 400 500 6000

0.5

1

1.5

2

2.5x 10

-3


U(D

urat

ion|

Kno

wn

Sin

gle

Fai

lure

, Kno

wn

Latit

ude)

Latitude: 60



AERONAUTICAL COMMUNICATIONS PANEL (ACP) · 1.1 Following Recommendation 3/2 of the first meeting of...

Documents

Transcript of AERONAUTICAL COMMUNICATIONS PANEL (ACP) · 1.1 Following Recommendation 3/2 of the first meeting of...