MCP/gr-mcp-docs
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity
gr-mcp-docs/reference/cospas-sarsat/a-series/a003.md
Ryan Malloy 4ed92efd69 refactor: move spec references out of published site 
Cospas-Sarsat specification summaries moved to reference/ for internal
use only. Links updated to point to official cospas-sarsat.int site.

The extracted images remain in public/ for use in other pages.
2026-02-13 05:03:09 -07:00

332 KiB
Raw Permalink Blame History

title description sidebar documentId series seriesName documentType isLatest issue revision documentDate originalTitle
A003: C/S A.003 Issue 3 - Rev.8 Official Cospas-Sarsat A-series document A003
badge
text variant
A note
A003 A Operational operational true 3 8 October 2025 C/S A.003 Issue 3 - Rev.8

📋 Document Information

Series: A-Series (Operational) Version: Issue 3 - Revision 8 Date: October 2025 Source: Cospas-Sarsat Official Documents

COSPAS-SARSAT SYSTEM MONITORING AND REPORTING C/S A.003 Issue 3 – Revision 8

Image 1 from page 1

COSPAS-SARSAT SYSTEM MONITORING AND REPORTING History Issue Revision Date Comments

Approved by the Cospas-Sarsat Council (CSC-11).

Approved by the Cospas-Sarsat Council (CSC-13).

Changes to annexes agreed at JC-9.

Approved by the Cospas-Sarsat Council (CSC-17).

Approved by the Cospas-Sarsat Council (CSC-19).

Approved by the Cospas-Sarsat Council (CSC-21).

Approved by the Cospas-Sarsat Council (CSC-23).

Approved by the Cospas-Sarsat Council (CSC-25).

Approved by the Cospas-Sarsat Council (CSC-27).

Revised Annexes B, E, H and J agreed at JC-16.

Approved by the Cospas-Sarsat Council (CSC-31).

Approved by the Cospas-Sarsat Council (CSC-33).

Approved by the Cospas-Sarsat Council (CSC-35).

Approved by the Cospas-Sarsat Council (CSC-37).

Approved by the Cospas-Sarsat Council (CSC-39).

Approved by the Cospas-Sarsat Council (CSC-41).

Approved by the Cospas-Sarsat Council (CSC-43).

Approved by the Cospas-Sarsat Council (CSC-45).

Approved by the Cospas-Sarsat Council (CSC-47).

Approved by the Cospas-Sarsat Council (CSC-49).

Approved by the Cospas-Sarsat Council (CSC-51).

Approved by the Cospas-Sarsat Council (CSC-53).

Issue Revision Date Comments

Approved by the Cospas-Sarsat Council (CSC-55).

Approved by the Cospas-Sarsat Council (CSC-57).

Approved by the Cospas-Sarsat Council (CSC-59).

Approved by the Cospas-Sarsat Council (CSC-61).

Approved by the Cospas-Sarsat Council (CSC-62).

Approved by the Cospas-Sarsat Council (CSC-64)

Approved by the Cospas-Sarsat Council (CSC-66)

Approved by the Cospas-Sarsat Council (CSC-67)

Approved by the Cospas-Sarsat Council (CSC-69)

Approved by the Cospas-Sarsat Council (CSC-71)

Approved by the Cospas-Sarsat Council (CSC-73)

TABLE OF CONTENTS Page

  1. INTRODUCTION .............................................................................................................. 1-1 1.1 Overview and Background .......................................................................................... 1-1 1.2 Objectives .................................................................................................................... 1-1 1.3 Scope of Document ..................................................................................................... 1-2 1.4 General Description ..................................................................................................... 1-2 1.5 Reference Documents .................................................................................................. 1-4
  2. METHODOLOGY AND PROCEDURES FOR CONTINUOUS MONITORING AND OBJECTIVE ASSESSMENT OF COSPAS-SARSAT SYSTEM STATUS ................. 2-1 2.1 Introduction ................................................................................................................. 2-1 2.2 Methodology ............................................................................................................... 2-1 2.3 Monitoring Procedures and Data Transmission Requirements ................................... 2-2 2.4 Data Analysis .............................................................................................................. 2-5 2.5 Evaluation Criteria, Assessment Procedure and Follow-up Actions ........................ 2-13
  3. SYSTEM SELF-MONITORING ...................................................................................... 3-1 3.1 Ground Segment Self-Monitoring ............................................................................... 3-1 3.2 Space Segment Self-Monitoring ............................................................................... 3-36 3.3 Monitoring of System Performance Related to SARP and SARR/MSG Instruments ................................................................................................................................... 3-37
  4. BEACON PERFORMANCE MONITORING ................................................................ 4-1 4.1 Description of Beacon Monitoring .............................................................................. 4-1 4.2 Beacon Monitoring Requirements ............................................................................... 4-1
  5. INTERFERENCE MONITORING .................................................................................. 5-1 5.1 Effects of Interference on the System ......................................................................... 5-1 5.2 Monitoring 406 MHz Interference with the LEOSAR System ................................... 5-1 5.3 Suppression of 406 MHz Interference ......................................................................... 5-2 5.4 Notification of 406 MHz Interference ......................................................................... 5-2
  6. REPORTING ON SYSTEM STATUS AND PERFORMANCE ................................... 6-1 6.1 Scope and Objectives of Reporting ............................................................................. 6-1 6.2 Space Segment ............................................................................................................ 6-1 6.3 Ground Segment .......................................................................................................... 6-2 6.4 Beacon Population ....................................................................................................... 6-9 6.5 False Alert Rate ........................................................................................................... 6-9 6.6 Interference ................................................................................................................ 6-10 6.7 406-MHz Beacon Message Processing Anomalies ................................................... 6-11 6.8 Distress Incident Report of SAR Events Assisted By Cospas-Sarsat Information ... 6-11 6.9 Collecting and Reporting Data for SAR Event Analysis .......................................... 6-11

LIST OF ANNEXES Page ANNEX A SYSTEM STATUS AND OPERATIONS AND DISTRESS INCIDENT REPORT FORMATS ....................................................................................... A-1 1. Format of Report on System Status and Operations .................................. A-1 2. Tool for Reporting SAR Events ............................................................... A-12 ANNEX B 406-MHz INTERFERENCE MONITORING AND REPORTING ............. B-1 1. Status of LEOLUT Monitoring Capabilities ............................................. B-1 2. ITU Interference Report Forms ................................................................. B-3 ANNEX C PERFORMANCE PARAMETERS FOR SYSTEM SELF-MONITORING ...................................................................................... C-1 ANNEX D ANOMALY NOTIFICATION MESSAGES .................................................. D-1 1. LEOLUT Availability Status Messages .................................................... D-2 2. GEOLUT Availability Status Messages .................................................... D-4 3. LEOLUT Accuracy Status Messages ........................................................ D-6 4. MEOLUT Accuracy Status Messages ....................................................... D-8 5. MEOLUT Location Probability Status Messages ................................... D-11 6. MEOLUT Detection Probability Status Messages .................................. D-13 7. MEOLUT Local Antenna Availability Status Messages ......................... D-14 8. MEOLUT Timeliness Status Messages ................................................... D-15 ANNEX E PERFORMANCE MEASURES FOR THE COSPAS-SARSAT STRATEGIC PLAN ....................................................................................... E-1 ANNEX F DATA COLLECTION FOR ANALYSIS OF 406 MHz BEACON MESSAGE PROCESSING ANOMALIES ...................................................... F-1 ANNEX G COLLECTING AND REPORTING DATA FOR SAR EVENT ANALYSIS ......................................................................................................... G-1 1. Procedure for Collecting Cospas-Sarsat Data on SAR Incidents .............. G-1 2. Data to Be Collected and Reported ............................................................ G-2 ANNEX H REPORTING OF MCC/SPOC COMMUNICATION TEST ....................... H-1 ANNEX I COSPAS-SARSAT GROUND SEGMENT SYSTEM TEST .......................... I-1 ANNEX J QMS AUTOMATED REPORTING SYSTEM ............................................... J-1

LIST OF TABLES Page Table 2.1: Template for the LEOLUT Status Table (Availability and Accuracy) ................................. 2-15 Table 2.2: Template for the GEOLUT Availability Table ..................................................................... 2-15 Table 2.3: Template for the MEOLUT High Level Status Table .......................................................... 2-16 Table 2.4: Template for the MEOLUT Detailed Status Table ............................................................... 2-17 Table 2.5: Template for the MCC Status Table ..................................................................................... 2-31 Table 3.1: LUTs Designated to Monitor MSG Satellites ....................................................................... 3-38 Table 3.2: Synthesis of SARR/MSG System Performance ................................................................... 3-38 Table 3.3: Synthesis of SARP System Performance (Frequency Parameters) ...................................... 3-39 Table 3.4: Synthesis of SARP System Performance .............................................................................. 3-39 Table 6.1: Example for Reporting False Alert Rate by Beacon Model ................................................. 6-10 Table B.1: 406-MHz Interference Report Format ................................................................................... B-4 Table C.1: LEOSAR and MEOSAR System Performance Parameters .................................................. C-1 Table C.2: GEOSAR System Performance Parameters .......................................................................... C-4 Table C.3: Number of Points Transmitted by a Distress Beacon ........................................................... C-5 Table F.1: Data Collection for Analysis of 406 MHz Beacon Message ................................................. F-2 Table G.1: Satellite Pass Log .................................................................................................................. G-4 Table G.2: Satellite Pass Log .................................................................................................................. G-4 Table G.3: Satellite Pass Log .................................................................................................................. G-4 Table H.1: Monthly Report on Success of MCC Messages Sent to SPOCs ........................................... H-1 Table I.2: Expected LEOLUT and MCC Processing for System Level Test .......................................... I-8 Table I.3: Expected GEOLUT and MCC Processing for System Level Test ........................................ I-11 Table I.4: Specific MCC Processing for Messages Transmitted in System Level Test ......................... I-15

LIST OF FIGURES Page Figure 2.1: LEOLUT Availability Assessment, Status Reporting and Follow-up Actions ..... 2-20 Figure 2.2: GEOLUT Availability Assessment, Status Reporting and Follow-up Actions .... 2-22 Figure 2.3: LEOLUT Location Accuracy Assessment, Status Reporting and Follow-Up Actions ............................................................................................................................ 2-32 Figure 6.1: System Availability ................................................................................................. 6-3 Figure 6.2: Operational Status of Ground Segment Equipment ................................................ 6-8 Figure A.1: Information Graphic on Sources of False Alerts ................................................. A-11 Figure B.1: Coverage Area of LEOLUTs Performing 406-MHz Routine Interference Monitoring ............................................................................................................................. B-2 Figure J.1: General Architecture of the QMS Automated Reporting System (QARS) .............. J-1

1-1

INTRODUCTION 1.1 Overview and Background The Cospas-Sarsat System forms an integral part of search and rescue (SAR) capabilities throughout the world. The elements of the System, provided by a number of countries, consist of: a) 406-MHz beacons; b) a Space Segment comprising: • Cospas and Sarsat Low Earth Orbiting (LEOSAR) satellites with Search and Rescue Repeaters (SARR) and Search and Rescue Processors (SARP) payloads, • Medium Earth Orbiting (MEOSAR) satellites with Search and Rescue Repeater (SARR) instruments carried on Global Navigation Satellite System (GNSS) satellites, • Geostationary Earth Orbiting (GEOSAR) satellites with Search and Rescue Repeater (SARR) instruments; and c) a Ground Segment comprising: • Local User Terminals (LUTs), including LEOLUTs, MEOLUTs, and GEOLUTs, • Mission Control Centres (MCCs). To ensure coherent and reliable System operation, performance standards and monitoring procedures are required to determine if all System elements are operating in the desired manner. In addition to this routine and periodic System monitoring, Cospas-Sarsat implemented a Quality Management System (QMS). The procedure for continuous monitoring and objective assessment of the System described in section 2 of this document is an integral part of the QMS. If anomalies are detected in System operation, procedures for the notification of anomalies and for reporting on System performance provide all those involved in Cospas-Sarsat related activities, including Space Segment Providers, Ground Segment Providers, SAR services, national authorities and, when appropriate, manufacturers of Cospas-Sarsat equipment and the users of Cospas-Sarsat emergency beacons, with the necessary information so that corrective action can be taken. 1.2 Objectives The Cospas-Sarsat Quality Policy, as provided in document C/S P.015 “Cospas-Sarsat Quality Manual”, states that Cospas-Sarsat is committed to maintaining a System that provides accurate, timely and reliable distress alert and location data. To ensure the quality of alert data, Cospas- Sarsat shall maintain and continually improve its QMS and will endeavour to: a) maintain focus on search and rescue requirements; and b) understand and apply internationally recognised quality management principles.

1-2

Cospas-Sarsat is committed to a philosophy of quality and, to that end, will continue to facilitate the development of the skills of System providers and customers to: a) operate and utilize the System to its full potential; and b) endeavour to meet the Cospas-Sarsat quality objectives. The purpose of System monitoring is to: a) detect anomalies in the performance of System elements; and b) ensure the integrity and the validity of data provided to SAR services. To achieve the general objective of System monitoring and to maintain high quality System operations as described above, abnormal conditions must be identified by the Space Segment Providers and by each operator of Ground Segment equipment commissioned in the Cospas-Sarsat System. This also requires that, whenever possible, the detection of anomalies be performed automatically by the LUT or the MCC. Detected anomalies should be notified as appropriate to operators of Space Segment and Ground Segment elements. In addition, the evolution of System performance must be assessed and reported as required to avoid unacceptable degradations. 1.3 Scope of Document This document details the elements of the System which should be monitored, how such monitoring should be performed, and the applicable standards. It describes the procedures to be followed when anomalies are detected in the operation of the System's elements. This document also addresses the reporting requirements on System status and operations and the QMS operating and monitoring requirements. 1.4 General Description 1.4.1 Monitoring Cospas-Sarsat Space and Ground Segments The System monitoring procedures described in this document are designed to provide each Space Segment and Ground Segment operator with efficient tools for the quality control of System operations. For each System element, the baseline performance is established during the commissioning of Ground Segment elements and during the post-launch testing of satellite payloads. They are re-established periodically to serve as references for the detection of anomalies. The monitoring of individual elements of the Cospas-Sarsat System (Space Segment units, Ground Segment equipment or distress beacons) is the responsibility of the provider of that element or of the Administration authorising the use of the beacon. Upon signature of the Standard Letter of Notification of Association with the International Cospas- Sarsat Programme as a Ground Segment Provider (contained in document C/S P.002), all Operators of Cospas-Sarsat equipment agree to ensure that the data provided to SAR services is reliable and that the System is operating at its optimum performance level. Specifically, signatories assume the responsibility to:

1-3

a) adhere to the technical specifications and operating procedures set by the Council for the purpose of ensuring adequate System performance; b) endeavour to deliver, in accordance with procedures agreed with the Council, distress alert and location information received through the Cospas-Sarsat Space Segment to appropriate search and rescue authorities; and c) provide, as agreed with the Council, appropriate performance data in order to confirm compatibility of its Ground Segment equipment with the System. Therefore, in the course of conducting normal Cospas-Sarsat operations, all LUT and MCC operators should endeavour to verify that the System is operating normally and should be alerted about degraded System performance or abnormal conditions. Section 2 of this document provides a QMS methodology for continuous monitoring of key Performance Parameters, as identified in document C/S P.016, the Cospas-Sarsat Strategic Plan, and for objective assessment of System status. The function described in section 3 is referred to as “System Self-Monitoring”. It should be performed routinely, as part of the monitoring activities of individual Ground Segment elements. When anomalies are detected by a Space Segment or a Ground Segment operator, a notification message is sent to all interested Cospas-Sarsat operators. Annex C provides further tools for MCC self-monitoring. 1.4.2 Monitoring Cospas-Sarsat Distress Beacons The monitoring of distress beacon performance is an important part of the overall Cospas-Sarsat System monitoring since the beacon initiates the distress alert and its good performance is essential for the success of the SAR operation. This monitoring should be performed by all Administrations world-wide. Cospas-Sarsat distress beacons are designed to operate with the Cospas-Sarsat satellite system and Cospas-Sarsat has defined a specific type-approval procedure for these beacons. This is complemented by the definition of a comprehensive monitoring programme developed to assist Administrations in ensuring their reliable performance. The integrity of the Cospas-Sarsat System is the result of routine monitoring activities performed individually by each Space Segment and Ground Segment Provider. However, to ensure System integrity, the long term evolution of System performance should be assessed by gathering statistical information on the status and operation of the System elements and reporting this data, together with the detected anomalies, for every twelve-month period.

1-4

1.5 Reference Documents a. C/S A.001 Cospas-Sarsat Data Distribution Plan, b. C/S A.002 Cospas-Sarsat Mission Control Centres Standard Interface Description, c. C/S A.005 Cospas-Sarsat Mission Control Centre (MCC) Performance Specification and Design Guidelines, d. C/S A.006 Cospas-Sarsat Mission Control Centre Commissioning Standard, e. C/S P.002 Procedure for the Notification of Association with the International Cospas- Sarsat Programme by States Non-Party to the Cospas-Sarsat Agreement, f. C/S P.015 Cospas-Sarsat Quality Manual, g. C/S P.016 Cospas-Sarsat Strategic Plan, h. C/S S.007 Handbook of Beacon Regulations, i. C/S S.011 Cospas-Sarsat Glossary, j. C/S T.001 Specification for Cospas-Sarsat [First-Generation] 406 MHz Distress Beacons, k. C/S T.002 Cospas-Sarsat LEOLUT Performance Specification and Design Guidelines, l. C/S T.003 Description of the Cospas-Sarsat Space Segment, m. C/S T.005 Cospas-Sarsat LEOLUT Commissioning Standard, n. C/S T.006 Cospas-Sarsat Orbitography Network Specification, o. C/S T.007 Cospas-Sarsat [First-Generation] 406 MHz Distress Beacon Type Approval Standard, p. C/S T.009 Cospas-Sarsat GEOLUT Performance Specification and Design Guidelines, q. C/S T.010 Cospas-Sarsat GEOLUT Commissioning Standard, r. C/S T.018 Specification for Cospas-Sarsat Second-Generation 406 MHz Distress Beacons, s. C/S T.019 Cospas-Sarsat MEOLUT Performance Specification and Design Guidelines, t. C/S T.020 Cospas-Sarsat MEOLUT Commissioning Standard, u. C/S T.021 Cospas-Sarsat Second-Generation 406 MHz Distress Beacon Type Approval Standard, v. C/S T.022 Cospas-Sarsat System Beacon Specification and Design Guidelines.

  • END OF SECTION 1 -

2-1

METHODOLOGY AND PROCEDURES FOR CONTINUOUS MONITORING AND OBJECTIVE ASSESSMENT OF COSPAS-SARSAT SYSTEM STATUS 2.1 Introduction The Cospas-Sarsat Quality Management System (QMS) objectives stated in the “Cospas-Sarsat Quality Manual” (document C/S P.015) are to: a) ensure that Cospas-Sarsat consistently provides accurate, timely and reliable distress alert and location information to search and rescue authorities; and b) continually improve the overall Cospas-Sarsat System Performance. In order to accomplish these objectives, Cospas-Sarsat has decided to develop and implement a procedure for continuous monitoring and objective assessment of the status of System components, to include: • detailed monitoring procedures and data transmission requirements, • tools based on a standard set of requirements for the analysis of data, • standard evaluation criteria and assessment methodology, • standard reporting procedures and follow-up actions. 2.2 Methodology The status of System components shall be monitored on a continuous basis using 406 MHz transmissions of known reference beacons, including orbitography beacons. The transmissions from designated reference beacons, received by LEOSAR satellites for each orbit, shall be processed and sent by each LEOLUT to its associated MCC, in accordance with document C/S T.002. The transmissions from designated reference beacons relayed by MEOSAR satellites shall be processed and sent by each MEOLUT to its associated MCC in accordance with section “Transmitting Data to the MCC” in document C/S T.019. Each GEOLUT shall send alert messages to its associated MCC every 20 minutes with the transmissions from the designated reference beacon in the GEOSAR satellite footprint, in accordance with document C/S T.009. For every LUT, the associated MCC shall send messages for the designated reference beacons to the appropriate nodal MCC, in accordance with procedures defined in document C/S A.001.

2-2

Every day, each nodal MCC shall run an automated data analysis and an assessment procedure on the basis of Cospas-Sarsat standard evaluation criteria. This assessment may result in various follow-up actions, including: • warnings addressed to the responsible provider or operator of a non-conforming System component, • modifications to the status statements of System components posted on the Cospas-Sarsat website, • suppression of unreliable data from non-conforming System components. The performance and status of reference beacons used for the monitoring and assessment procedure shall be periodically re-evaluated and confirmed by the Cospas-Sarsat Participants responsible for their operation. A reference beacon that is used for calibration of a LUT should not also be used to perform QMS for that LUT, if its use for calibration would bias its use for QMS (e.g., a reference beacon should not be used for both Doppler location accuracy assessment and orbit updates for the same LEOLUT). 2.3 Monitoring Procedures and Data Transmission Requirements The procedures and data transmission requirements described in this section concern the minimum System-wide monitoring and assessment process performed in accordance with Cospas-Sarsat Quality Management System (QMS) requirements. Space and Ground Segment Providers or Operators can perform any additional monitoring and assessment procedure that is deemed appropriate for their own QMS requirements. 2.3.1 LEOSAR Data Requirements LEOLUTs commissioned in the Cospas-Sarsat System shall process the global and local mode data which result from the McMurdo and Longyearbyen (see beacon IDs provided on the Cospas- Sarsat website) orbitography beacon transmissions, as received during all passes of all operational LEOSAR satellites. The alert and location data obtained for the McMurdo and Longyearbyen orbitography beacons shall be forwarded via the associated MCC to the nodal MCC of the DDR. If combined LEO/GEO processing has been implemented at a LEOLUT, the alert message provided for the McMurdo and Longyearbyen orbitography beacons shall not include combined LEO/GEO processing data. MCCs shall not merge or suppress redundant alert data received from multiple LEOLUTs for the McMurdo and Longyearbyen orbitography beacons. All alert messages received from operational LEOLUTs for these beacons shall be forwarded to the appropriate nodal MCC. Nodal MCCs shall include alert messages in QMS LEOLUT availability and location accuracy analysis regardless of the Doppler Position Footprint Validation specified in the figure entitled “Algorithm to Determine

2-3

if Computed Position is Inside LEOSAR, MEOSAR or GEOSAR Satellite Footprint” of document C/S A.002 “Cospas-Sarsat Mission Control Centres Standard Interface Description”. In a contingency situation MCCs shall not transmit QMS data to the backup nodal MCC. 2.3.2 MEOSAR Data Requirements 2.3.2.1 Designated QMS Reference Beacons Reference beacons shall be used for the data collection and QMS assessment process, as described below. Reference beacons designated for use for QMS are denoted “designated QMS reference beacons”. Reference beacon providers should coordinate at a regional level the placement of designated QMS reference beacons and shall coordinate the transmission schedule and transmission frequency at a Programme level through the Secretariat in order to: a) maximize usability for multiple MEOLUTs; b) minimize the impact on other reference beacon transmissions; and c) minimize the impact on the operational System. The responsible nodal MCC should encourage MEOLUT providers in its DDR to designate as many appropriately placed reference beacons as necessary to ensure that MEOLUT performance is assessed for the entire DCA. Moreover, the responsible nodal MCC shall: • send a SIT 605 message when the status, geographical location or transmission characteristics of a designated reference beacon changes, and • notify the Secretariat, to allow appropriate changes to be made to the Cospas-Sarsat website. The responsible nodal MCC shall send a SIT 605 message and notify the Secretariat when: • a reference beacon is designated to monitor a MEOLUT in its DDR, or • a reference beacon is no longer designated to monitor a MEOLUT in its DDR. A reference beacon used for QMS for a given MEOLUT shall not also be used for calibration of the same MEOLUT, if its use for calibration would bias QMS results. As practical, at least one designated reference beacon should be located near the edge of the MEOLUT’s Declared Coverage Area (DCA) or at least 1,000 km from the MEOLUT, so that the MEOLUT performance reported for the designated QMS reference beacon is a reasonable reflection of the performance within its DCA. The Cospas-Sarsat web page for QMS shall list the reference beacons used for each MEOLUT and the DCA for each MEOLUT.

2-4

Each designated QMS reference beacon shall meet specific performance requirements (including the transmission repetition period (TRP) and other transmission characteristics) for either a First Generation Beacon (FGB) contained in document C/S T.001 and/or a Second Generation Beacon (SGB) contained in document C/S T.018, except as modified by document C/S T.022 “Cospas-Sarsat System Beacon Specification and Design Guidelines”. Each reference beacon shall also be adequately monitored by the provider, in accordance with document C/S T.022 “Cospas-Sarsat System Beacon Specification and Design Guidelines”. Alternative reference beacons may be designated for each MEOLUT, to enable QMS analysis to be performed in the event that a designated QMS reference beacon fails. 2.3.2.2 MCC Requirements The associated MCC shall forward all alerts received from a MEOLUT for designated QMS reference beacons to the appropriate nodal MCC, in a SIT 142 or 145 message, as appropriate, as specified in document C/S A.002; these alerts shall be forwarded to the nodal MCC regardless of whether a designated QMS reference beacon transmits in self- test mode. The reference beacons used for QMS shall be configurable in each MCC. When a nodal MCC is being backed up by another nodal MCC, MCCs shall not transmit QMS data to the backup nodal MCC. 2.3.3 GEOSAR Data Requirements The reference beacons to be used in each GEOSAR satellite footprint for the data collection and assessment process, for which beacon IDs are provided on the Cospas-Sarsat website are: • Toulouse time reference beacon for GEOLUTs in the MSG satellite footprint, • Edmonton reference beacon for GEOLUTs in the GOES East and GOES West satellite footprints, • Kerguelen reference beacon for GEOLUTs in the INSAT satellite footprint. GEOLUTs commissioned in the Cospas-Sarsat System shall produce for every 20-minute time slot starting from the hour, one alert message for the transmissions of the designated reference beacons in the GEOSAR satellite footprint. MCCs shall not suppress redundant alert data received from multiple GEOLUTs for the designated beacons. All alert messages received from GEOLUTs for these beacons shall be forwarded to the appropriate nodal MCC. In a contingency situation MCCs shall not transmit QMS data to the backup nodal MCC. Note: An alternative reference beacon may be designated in each GEOSAR satellite footprint for the purpose of this monitoring procedure. However, all of the designated reference

2-5

beacons should meet specific performance requirements and be adequately monitored by the provider, in accordance with the relevant sections of documents C/S T.006 “Cospas- Sarsat Orbitography Network Specification” and C/S T.022 “Cospas-Sarsat MEOLUT Reference Beacon Specification and Design Guidelines”. 2.3.4 Reference Beacon Unavailability If a designated QMS reference beacon becomes non-operational (as declared in a SIT 605 message by the MCC responsible for the beacon), then the QMS continuous monitoring process will no longer use that beacon. If a beacon used for QMS monitoring becomes non-operational and an alternative beacon is designated (as specified in section 2.3.1, 2.3.2, or 2.3.3) and is operational, then: a) the MCC responsible for the alternative beacon shall declare in a SIT 605 message that the alternative designated beacon is to be used for the specified QMS monitoring, as appropriate; b) the appropriate LUTs shall send alert messages for the alternative designated beacon instead of the non-operational beacon to the associated MCC; c) MCCs shall send alert messages for the alternative designated beacon instead of the non- operational beacon to the associated nodal MCC; and d) nodal MCCs shall perform QMS monitoring of the indicated component sub-system, as appropriate, using the alternative designated beacon instead of the non-operational beacon. If a beacon used for QMS monitoring becomes non-operational and no alternative designated beacon is operational, then the appropriate QMS monitoring process shall be suspended by the associated nodal MCC until a designated beacon is available. 2.4 Data Analysis The data analysis requirements are described in the following sections of this document. The requested data analysis shall be performed by each nodal MCC, and results in the production on a daily basis of: a) availability ratios for each: • LEOLUT / LEOSAR satellite combination, • MEOLUT (including location probability, detection probability, and antenna availability), • GEOLUT in a GEOSAR satellite footprint; b) accuracy ratios for each LEOLUT / LEOSAR satellite combination, and each MEOLUT; c) timeliness ratios for each MEOLUT; and d) EHE (expected horizontal error) ratio for each MEOLUT.

2-6

2.4.1 LEOSAR Data Analysis 2.4.1.1 For each LEOLUT in the nodal MCC’s DDR, collect all solutions from operational LEOSAR satellites for the designated reference beacons for the analysis time period. The minimum required fields for each solution are: • Latitude Side A, • Longitude Side A, • Latitude Side B, • Longitude Side B, • Number of Points, • Window Factor, • Cross Track Angle (CTA), • Satellite, • Time of Closest Approach (TCA), • 15 Hex Beacon ID. 2.4.1.2 Generate a set of passes (satellite and time frame) within the analysis period when the designated reference beacon was visible to operational LEOSAR satellites for at least 120 seconds (4 beacon bursts). The minimum required fields for each pass are: • Satellite, • Time of First Visibility (AOS), • Time of Last Visibility (LOS). 2.4.1.3 Perform LEOLUT Location Accuracy analysis as follows: a) Identify and record the type of each solution as nominal or marginal (see document C/S T.002, section entitled “Performance Requirements”, for definitions of these terms), b) Compute and record the location error (minimum error Side A or Side B) with respect to the known location of the designated reference beacon, c) Compute daily for each LEOLUT in the DDR and each operational LEOSAR satellite, a LEOLUT / LEOSAT accuracy ratio, using the nominal Doppler solutions received during the last three days for the designated reference beacons (i.e., between Day-3, 00:00 UTC and Day 0, 00:00 UTC). The accuracy ratio for LEOLUT(i) and LEOSAT(j) is defined as follows: R.X (i,j) = N Loc (E ≤ X km) / N Loc,

2-7

where: N Loc = total number of Doppler locations with nominal solutions, obtained for the designated reference beacons during the time period Day-3, 00:00 and Day 0, 00:00, N Loc (E ≤ X km) = number of Doppler locations with nominal solutions obtained for the designated reference beacons during the time period Day-3, 00:00 and Day 0, 00:00 with a distance to the true position of the beacons less than or equal to X km. Only the first nominal solution received from a LEOLUT for a specific beacon event should be used to compute location accuracy. Note: the computation should be performed at Day 0 + 14:00 hour (UTC) to take into account the maximum delay between the last LEOSAT(j) pass over the designated reference beacons during the period and the actual tracking of LEOSAT(j) by LEOLUT(i). This period is based on analysis showing that 99% of solutions were received by the LUT within 14 hours of satellite detection. d) LEOLUT accuracy ratios shall be computed for X = 5 km, 10 km and 20 km. 2.4.1.4 Perform LEOLUT Availability Analysis as follows: Compute daily, for each LEOLUT in the DDR and each operational LEOSAR satellite, a LEOLUT / LEOSAT availability ratio, using the data received during the last three days for the designated reference beacons (i.e., between Day-3, 00:00 UTC and Day 0, 00:00 UTC). The availability ratio for LEOLUT(i) and LEOSAT(j) is defined as follows: Av (i,j) = N available (i,j) / N expected (i,j), where: N available (i,j) = number of orbits of LEOSAT(j) over the designated reference beacons between Day-3, 00:00 UTC and Day 0, 00:00 UTC for which valid alert messages with a Doppler location were produced by LEOLUT(i), N expected (i,j) = total number of orbits of LEOSAT(j) over all of the designated reference beacons between Day-3, 00:00 UTC and Day 0, 00:00 UTC, where the beacon was visible to the satellite for at least 120 seconds. Note: The LEOLUT availability and accuracy ratios are calculated daily, using data collected over the three consecutive days that precede the computation (Day-3, 00:00 UTC to Day-1, 24:00 UTC). The computation should be performed at Day 0 + 14:00 hours (UTC) to take into account the maximum delay between the last

2-8

LEOSAT(j) pass over the designated reference beacons during the period and the actual tracking of LEOSAT(j) by LEOLUT(i). 2.4.2 MEOSAR Data Analysis 2.4.2.1 For each MEOLUT in the nodal MCC’s DDR, collect all solutions for the designated FGB and SGB QMS reference beacons for the analysis period, except solutions that contain data from a satellite that is not commissioned or not available for operational use. Further limitations on data included in the analysis are provided below, as appropriate. All processing thresholds (at a minimum-elevation angles, the rates that identify criteria for success, the frequency of reporting, and the duration of the analysis period) shall be configurable. The frequency of reporting and the duration of the analysis period shall be independently configurable. MEOLUT detection probability is calculated based on a 48-hour analysis period. All other MEOSAR metrics are calculated based on a 24-hour analysis period. All MEOSAR metrics shall be computed daily at 00:30 UTC, for the preceding 24- or 48-hour period that ended at 00:00 UTC. 2.4.2.2 MEOLUT Location Accuracy 2.4.2.2.1 Location Accuracy Single Burst Solutions For each MEOLUT in the DDR, compute the ratio of the number of solutions with DOA location generated for the designated QMS reference beacons that are accurate within X km vs. the total number of associated solutions with DOA location, where Time_First and Time_Last (i.e., respectively, Message Fields 14a and 14b per document C/S A.002) are within the analysis period, and Time_Last – TimeFirst < 2.5 seconds. This computation shall be performed for each designated reference beacon separately and for all designated reference beacons of a given generation together. The computation shall be performed for values of X as follows: • for both FGBs and SGBs, X1 = 5 km and X2 = 20 km. The accuracy ratios for single burst locations for beacon N (i.e., “SB_LocAcc_X_BeaconN”) are defined as:

2-9

SB_LocAcc_X1_BeaconN = number of single burst solutions for beacon N with DOA location with an error ≤ X1 km total number of single burst solutions for beacon N with DOA location and SB_LocAcc_X2_BeaconN = number of single burst solutions for beacon N with DOA location with an error ≤ X2 km total number of single burst solutions for beacon N with DOA location The accuracy ratios for single burst locations for all reference beacons of a given generation (FGB or SGB) (i.e., “SB_LocAcc”) are defined as: SB_LocAcc_X1_AllBeacons (FGBs or SGBs) = number of single burst solutions for all reference beacons with DOA location with an error ≤ X1 km total number of single burst solutions for all reference beacons with DOA location SB_LocAcc_X2_AllBeacons (FGBs or SGBs) = number of single burst solutions for all reference beacons with DOA location with an error ≤ X2 km total number of single burst solutions for all reference beacons with DOA location 2.4.2.2.2 Location Accuracy Multi-Burst Solutions For each MEOLUT in the DDR, compute the ratio of the number of solutions with DOA location generated for the designated QMS reference beacons that are accurate within X km vs. the total number of associated solutions with DOA location, where Time_First and Time_Last are within the analysis period, and 2.5 seconds < (Time_Last – Time_First) < (600 seconds for FGBs or 300 seconds for SGBs). This computation shall be performed for each designated reference beacon separately and for all designated reference beacons of a given generation taken together. The computation shall be performed for values of X as follows: • for FGBs, X3 = 5 km and X4 = 20 km. • for SGBs, X3 = 1 km and X4 = 20 km. The accuracy ratios for multi-burst locations for beacon N (i.e., “MB_LocAcc_X_BeaconN”) are defined as: MB_LocAcc_X3BeaconN = number of multi −burst solutions for beacon N with DOA location with an error ≤ X3 km total number of multi −burst solutions for beacon N with DOA location and

2-10

MB_LocAcc_X4_BeaconN = number of multi −burst solutions for beacon N with DOA location with an error ≤ X4 km total number of multi −burst solutions for beacon N with DOA location The accuracy ratios for multi-burst locations for all reference beacons of a beacon generation FGB or SGB (i.e., “MB_LocAcc”) are defined as: MB_LocAcc_X3_AllBeacons (FGBs or SGBs) = number of multi −burst solutions with DOA location for all reference beacons with an error ≤ X3 km total number of multi −burst solutions for all reference beacons with DOA location and MB_LocAcc_X4_AllBeacons (FGBs or SGBs) = number of multi −burst solutions for all reference beacons with DOA location with an error ≤ X4 km total number of multi −burst solutions for all reference beacons with DOA location 2.4.2.3 MEOLUT Location Probability 2.4.2.3.1 Location Probability Single Burst Solutions For each MEOLUT in the DDR, per designated QMS reference beacon, compute the number of beacon TRPs within the analysis period for which a DOA location was received, where Time_First is within TRP, (Time_First – Time of First Transmission within the TRP) < 2.5 seconds, and (Time_Last – Time_First) < 2.5 seconds vs. the total number of TRPs in the analysis period. (Note that the TRP may differ for different reference beacons used for a given MEOLUT.) This computation shall be performed for each designated reference beacon separately and for all reference beacons of a given generation together. The probability of location ratios for single burst locations are defined as: SB_PLoc_BeaconX = sum (number of TRPs with DOA location for beacon X) number of TRPs for beacon X and SB_PLocAllBeacons (FGB or SGB) = sum (number of TRPs with DOA location for all designated reference beacons) number of TRPs for all designated reference beacons 2.4.2.3.2 Location Probability Multi-Burst Solutions For each MEOLUT in the DDR, per designated QMS reference beacon, compute the number of beacon transmission repetition periods within the analysis period for which at least one DOA location was received, where Time_First and Time_Last are each within the TRP, and 2.5 seconds < (Time_Last – Time_First) < (600 seconds for FGBs or 300

2-11

seconds for SGBs) vs. the total number of TRPs in the analysis period. This computation shall be performed for each designated reference beacon separately and for all reference beacons of a given generation together. The probability of location ratio for multi-burst locations is defined as: MB_PLoc Beacon X = sum(number of TRPs with at least one DOA location for beacon X) number of TRPs for beacon X and MB_PLocAllBeacons (FGBs or SGBs) = sum(number of TRPs with at least one DOA location for all designated reference beacons) number of TRPs for all designated reference beacons 2.4.2.4 MEOLUT Detection Probability For each MEOLUT in the DDR, per designated QMS reference beacon, compute the number of beacon transmission repetition periods within the analysis period for which at least one burst was detected, where Time Last is within the TRP. This computation shall be performed for each designated reference beacon separately and for all reference of a given generation of beacons together. The probability of detection ratios is defined as: ProbDetr_BeaconX = sum(number of TRPs with a detection for beacon X) number of TRPs for beacon X and ProbDetrAllBeacons (FGBs or SGBs) = sum(number of TRPs with a detection for all designated reference beacons) number of TRPs for all designated reference beacons 2.4.2.5 MEOLUT Local Antenna Channel Availability (for Networked MEOLUTs) For each MEOLUT in the DDR that networks with another MEOLUT, compute the ratio of DOA locations generated for all designated reference beacons that contain data from at least 3 of its own (i.e., non-networked) antenna channels vs. the total number of solutions with associated DOA locations, where Time_First and Time_Last are within the analysis period, Time_Last – TimeFirst < (600 seconds for FGBs or 300 seconds for SGBs), and the number of non-networked antenna channels is Total_Antenna_Channels – Networked_Antenna_Channels (i.e., respectively Messages Fields #81 and #80, per document C/S A.002). Exclude solutions with DOA location if Networked_Antenna = 99 (not available) or 98 (equal or greater than 98) or Total_Antennas = 99 (equal to or greater than 99).

2-12

The local antenna ratio is defined as: LocAr = number of DOA locations with data from at least 3 non −networked antenna Channels total number of solutions with DOA location 2.4.2.6 MEOSAR System Timeliness For each MEOLUT in the DDR, for operational beacon solutions received by the nodal MCC within the analysis period, compute the ratio of solutions received within 10 minutes* of Time_Last vs. the total number of solutions received by the nodal MCC. The timeliness ratio is defined as: TimeR = number of solutions received within 10 minutes of Time_Last total number of solutions received

  • For nodal MCCs, the threshold is 5 minutes. 2.4.2.7 Quality of Location Expected Horizontal Error For each MEOLUT in the DDR, compute the ratio of the number of solutions with DOA location generated for all designated reference beacons for which the EHE is larger than the true location error vs. the total number of associated solutions with DOA location, where Time_First and Time_Last are within the analysis period, and (Time_Last – Time_First) < 600 seconds for FGBs or 300 seconds for SGBs. The EHE quality ratio is defined as: QualEHEAllBeacons (FGBs or SGBs) = number of solutions for all designated reference beacons with DOA location for which EHE > true location error number of solutions for all designated reference beacons with DOA location 2.4.3 GEOSAR Data Analysis 2.4.3.1 Data Collection For each GEOLUT in the nodal MCC’s DDR, collect all solutions for the designated reference beacon for the analysis time period. Decode the 30-hexadecimal beacon message to determine the validity of the message. If the first protected field of the beacon message is not valid (per document C/S T.009, section entitled “Beacon Message Validation”), then the associated alert message should not be counted as received. 2.4.3.2 GEOLUT Availability Analysis Perform GEOLUT Availability Analysis as follows:

2-13

Compute daily, for each GEOLUT in the DDR a GEOLUT / GEOSAT availability ratio, using the valid alert messages received for each 20-minute slot on Day 0 between 00:00 UTC and 24:00 UTC for the designated reference beacon. The availability ratio for GEOLUT(i) and GEOSAT(j) is defined as follows: Av (i,j) = N available (i,j) / N expected (i,j), where: N available (i,j) = number of 20-minute time slots for which GEOLUT(i) produced valid alert messages for the time period Day-1, 00:00 UTC and Day-1, 24:00 UTC for the designated reference beacon, N expected (i,j) = 72 (for one designated reference beacon in the satellite footprint). Note: The GEOLUT availability ratio is computed daily using data collected during the day that precedes the computation (Day-1, 00:00 to 24:00 UTC). The computation should be performed at Day 0 + 30 minutes in order to allow time for transmission to the nodal MCC. 2.5 Evaluation Criteria, Assessment Procedure and Follow-up Actions 2.5.1 Assessment Methodology and Status Tables A set of evaluation criteria is used to determine, on the basis of the ratios described in section 2.4, the status of a LUT (for LEOLUTs and GEOLUTs, this is the conformity of alert data from a given LUT when processing data from a given satellite). If the appropriate evaluation criteria are met, the status of the LUT is shown as “Green” (i.e., in conformity) in the appropriate status table posted on the Cospas-Sarsat website. If the appropriate evaluation criteria are not met for a LEOLUT or GEOLUT, notification is sent to the Ground Segment Provider responsible for the non-conforming LUT via a SIT 605 message and the status is shown as “Red” (i.e., non-conforming) in the appropriate status table on the Cospas-Sarsat website. If the appropriate evaluation criteria are not met for a MEOLUT, then the status is shown in the appropriate status table on the Cospas-Sarsat website as either “Yellow” (i.e., non-conforming, moderate degradation) or “Red” (i.e., non-conforming, significant degradation). Templates of the status tables for LEOLUTs, GEOLUTs and MEOLUTs (high level status and detailed status) are provided below in Tables 2.1, 2.2, 2.3 and 2.4. On a daily basis, the nodal MCC shall update the “Last Update” date on the Cospas-Sarsat website for each status table for which it does not provide an automatic update via QARS to confirm that the LUT and MCC status depicted is correct.

2-14

The status tables for LEOLUTs, GEOLUTs, MEOLUTs and MCCs are updated by means of a QMS Automated Reporting System (QARS) that provides an interface between nodal MCCs and the Cospas-Sarsat website to display QMS status information determined by the nodal MCCs. The QARS provides an automated means of reporting QMS status information, as well as a web-based interface for manual update of QMS status by MCC operators. For each QMS status table, the nodal MCC shall provide daily updates, either automatically (per format specified in section J.2 of Annex J) or manually via the web-based interface.

2-15

Table 2.1: Template for the LEOLUT Status Table (Availability and Accuracy) XXX DDR Last Update: 30-11-2018 12:59:28 (GMT 00:00) LUT Name MCC Name LUT ID Sarsat-X Sarsat-Y Sarsat-N Cospas-X Cospas-Y Cospas-N Availability Accuracy Availability Accuracy Availability Accuracy Availability Accuracy Availability Accuracy Availability Accuracy LEOLUT_

MCC_1

Red Red Red Red Red Red Red Red Red Red Red Red LEOLUT_

MCC_2

Red Red Green Green Red Red Green Green Green Green Red Green LEOLUT_

MCC_3

Red Red Green Green Green Green Green Green Green Green Green Green LEOLUT_ N MCC_N

Red Red Green Green Green Green Green Green Green Green Green Green Table 2.2: Template for the GEOLUT Availability Table XXX DDR Last Update: 30-11-2018 12:54:43 (GMT 00:00) LUT Name MCC Name LUT ID GEOSAT_X GEOSAT_Y GEOSAT_N GEOLUT_1 MCC_1 nnnn Green n/a n/a GEOLUT_2 MCC_2 nnnn n/a Green n/a GEOLUT_N MCC_N nnnn n/a n/a Green

2-16

Table 2.3: Template for the MEOLUT High Level Status Table LUT Name MCC Name LUT ID Beacon Generation Detection Probability Location Probability Location Accuracy Location EHE Quality Local Antenna Availability System Timeliness MEOLUT_1 MCC_1

FGB Green Yellow Red n/i n/a Green MEOLUT_2 MCC_2

FGB Green Red Green+ Green Yellow Green MEOLUT_2 MCC_2

SGB Green Green Green Green n/a Green

2-17

Table 2.4: Template for the MEOLUT Detailed Status Table LUT Name LUT ID Reference Beacon Name Detection Probability Location Probability Location Accuracy Location EHE Quality* Local Antenna Avail- ability* System Time- liness* Single burst Multi burst Single burst Multi burst X1 X2 X3 X4 MEOLUT_1 LUT_1 RefBe1 (FGB) Green Yellow Green Yellow Yellow Red Yellow n/i n/a Green MEOLUT_2 LUT_2 RefBe1 (FGB) Green Green Yellow Green Green Green Green n/a n/a n/a MEOLUT_2 LUT_2 RefBe2 (FGB) Yellow Yellow Red Green Green Green Green n/a n/a n/a MEOLUT_2 LUT_2 All FGBs Green Yellow Red Green Green Green Green Green Yellow Green MEOLUT_2 LUT_2 RefBe1 (SGB) Green Green Green Green Green Green Green Green n/a Green MEOLUT_2 LUT_2 RefBe2 (SGB) Green Green Green Green Green Green Green Green n/a Green MEOLUT_2 LUT_2 All SGBs Green Green Green Green Green Green Green Green n/a Green Notes: This information is only provided to Cospas-Sarsat participants and Ground Segment Providers. Names and associated Hex IDs for reference beacon are provided on the Cospas-Sarsat website.

  • Statistics for Location EHE Quality and Local Antenna Availability are only provided for all designated reference beacons combined. System Timeliness statistics are only provided for all operational beacons. If multiple reference beacons are designated for a MEOLUT, then totals for “all” beacons are provided on a separate line. For each component status, the associated ratio and the two numbers used to derive the ratio are also provided on the corresponding Cospas-Sarsat website display.

2-18

Table 2.1 shows that LEOLUT 1 availability ratios are poor (“Red” status) for all LEOSAR satellites. LEOLUT 1 availability ratios are constantly below the Cospas-Sarsat availability requirement and the LEOLUT should be considered not operational. All LEOLUTs on Table 2.1 show a non-conforming "Red" status for the Sarsat X satellite. This indicates that the Sarsat X satellite or payload does not satisfy the availability requirement of the Cospas-Sarsat System. However, it is important to note that no alert data is suppressed on the basis of a "Red" non-conforming availability status. Table 2.1 shows that LEOLUT 1 provides no location data for all LEOSAR satellites, or unreliable location data that are suppressed by the nodal MCC in accordance with the procedures described in section 2.5.4. In Table 2.1, Sarsat X shows a “Red” status for all LEOLUTs: no reliable location data can be derived from Sarsat X and this data is therefore suppressed, or the Sarsat X payload is not operational and provides no data to any LEOLUT in the System. Table 2.1 also indicates that LEOLUT 2 does not provide reliable location data when tracking Sarsat N and the Doppler location in the alert messages is suppressed in accordance with the procedure described at section 2.5.4. The corresponding availability status for the LEOLUT 2 / Sarsat N combination in Table 2.1 is also shown as non- conforming (Red). Table 2.3 shows the status of MEOLUT 1 as “Red” for location accuracy (with the 5 km accuracy for multi-burst solutions shown as “Red” in Table 2.4), and location data will be suppressed for MEOLUT 1 due to its “Red” status for accuracy. Table 2.3 also shows the status of MEOLUT 2 as “Red” for location probability ((with the location probability for multi-burst solutions shown as “Red” in Table 2.4 for one designated reference beacon); no data is suppressed for MEOLUT 2, since suppression occurs only when the status is “Red” for location accuracy. The status of MEOLUT 1 is shown as “n/i” (in grey color) for Location EHE Quality in Table 2.3 and 2.4, indicating that insufficient data is available. The status of MEOLUT 1 is shown as “n/a” for local antenna availability, indicating that the MEOLUT is not networked. The status of MEOLUT 2 is shown as “Yellow” for local antenna availability, indicating partial conformity. Note: If no component status is “n/i”, then the overall status is the lowest status for any component status, where the components are “single-burst” and “multi-burst” for Location Probability, and “single-burst / X1 km”, “single-burst / X2 km”, “multi-burst / X3 km”, “multi-burst / X4 km” for Location Accuracy. 2.5.2 LEOLUT Availability Assessment, Status Reporting and Follow-Up Actions The LEOLUT availability ratio shall be greater than or equal to 80%.

2-19

If this availability criterion is met, the status of the LEOLUT(i) / LEOSAT(j) combination shown in the LEOLUT availability table posted on the Cospas-Sarsat website is "Green" (see Table 2.1: Template for the LEOLUT status Table (Availability and Accuracy)). If this availability criterion is not met, the nodal MCC shall notify the associated MCC, using the SIT 915 message template provided at Annex D. If the availability criterion is met after a SIT 915 (warning) message was sent for the previous reporting period, no message should be sent to confirm the return to conformity. If the availability ratio for LEOLUT(i) and LEOSAT(j), computed as described in section 2.4 over a 3-day period, remains constantly below the availability criterion for 4 successive days, LEOLUT(i) shall be declared non-conforming in respect of LEOSAT(j). The nodal MCC shall: a) inform all MCCs and the Cospas-Sarsat Secretariat using a SIT 605 message (see sample at Annex D); and b) update the LEOLUT availability table posted on the Cospas-Sarsat website for the LEOLUT / LEOSAT combination to “Red”. If the LEOLUT non-conformity is corrected, the availability status for the LEOLUT / LEOSAT combination shall be returned to "Green" as soon as the availability criterion is met. The nodal MCC shall: a) inform all MCCs and the Cospas-Sarsat Secretariat using a SIT 605 message (see sample at Annex D); and b) update the LEOLUT availability table posted on the Cospas-Sarsat website. The process described above is depicted in Figure 2.2. Note: It is recognised that the 3-day data requirement to compute the availability ratio may introduce a 3-day latency after the LEOLUT non-conformity is corrected. This latency is considered acceptable in the case of LEOLUT availability, noting that: • no data is suppressed as a consequence of the "Red" availability status, and • the "Red" availability status for a LEOLUT / LEOSAT combination does not affect the availability status of other LEOSAT combinations for the same LEOLUT.

2-20

NODAL MCC COMPUTES LEOLUT(i) / LEOSAT(j) AVAILABILITY FOR 3 PREVIOUS DAYS LEOLUT(i) / LEOSAT(j) AVAILABILITY > 80%? Yes NODAL MCC SENDS AN AVAILABILITY WARNING MESSAGE TO THE LEOLUT OPERATOR / GROUND SEGMENT PROVIDER FOR THE LEOLUT(i) /LEOSAT(j) COMBINATION USING SIT 915 MESSAGE TEMPLATE PROVIDED AT C/S A.003, ANNEX D DU = DU + 1 LEOLUT(i) / LEOSAT(j) STATUS = RED DU: DAYS OF UNAVAILABILITY DU = 4 ? No NODAL MCC DECLARES LEOLUT(i) IS NOT CONFORMING IN RESPECT OF LEOSAT(j) PROCESS BEGINS DU = 0 LEOLUT(i) / LEOSAT(j) STATUS = GREEN Yes NODAL MCC UPDATE AVAILABILITY TABLE POSTED ON THE COSPAS- SARSAT WEB SITE FOR LEOLUT(i) / LEOSAT (j) COMBINATION TO RED LEOLUT(i) / LEOSAT(j) STATUS = RED? LEOLUT(i) / LEOSAT(j) AVAILABILITY > 80%? No No Yes No Yes NODAL MCC CHANGES AVAILABILITY STATUS FOR LEOLUT(i) / LEOSAT (j) COMBINATION TO GREEN NODAL MCC SEND A MESSAGE IN A SIT 605 FORMAT TO ALL MCCs AND THE SECRETARIAT USING MESSAGE TEMPLATE PROVIDED AT C/S A.003, ANNEX D NODAL MCC SEND A MESSAGE IN A SIT 605 FORMAT TO ALL MCCs AND THE SECRETARIAT USING MESSAGE TEMPLATE PROVIDED AT C/S A.003, ANNEX D (Note: This decision tree is valid only when the LEOSAR space segment is operational) Figure 2.1: LEOLUT Availability Assessment, Status Reporting and Follow-up Actions

2-21

2.5.3 GEOLUT Availability Assessment, Status Reporting and Follow-up Actions The GEOLUT availability ratio shall be greater than or equal to 80 %. If this availability criterion is met, the status of the GEOLUT(i) / GEOSAT(j) combination shown in the GEOLUT availability table posted on the Cospas-Sarsat website is “Green” (see Table 2.2: Template for the GEOLUT Availability Table). If this availability criterion is not met, the nodal MCC shall notify the associated MCC, using the SIT 915 message template provided at Annex D. If the availability criterion is met after a SIT 915 (warning) message was sent for the previous reporting period, no message should be sent to confirm the return to conformity. If during a period of 4 successive days, the availability ratio for the GEOLUT remains constantly below the availability criterion, the GEOLUT shall be declared non- conforming. The nodal MCC shall: a) inform all MCCs and the Cospas-Sarsat Secretariat using a SIT 605 message (see sample at Annex D); and b) update the GEOLUT availability table posted on the Cospas-Sarsat website for the GEOLUT / GEOSAT combination to “Red”. If the GEOLUT non-conformity is corrected the availability status for the GEOLUT / GEOSAT combination shall be returned to "Green" as soon as the availability criterion is met. The nodal MCC shall: a) inform all MCCs and the Cospas-Sarsat Secretariat using a SIT 605 message (see sample at Annex D); and b) update the GEOLUT availability table posted on the Cospas-Sarsat website. The process described above is depicted in Figure 2.3.

2-22

NODAL MCC COMPUTES GEOLUT(i) / GEOSAT(j) AVAILABILITY FOR THE PREVIOUS DAY GEOLUT(i) / GEOSAT(j) AVAILABILITY ≥ 80%? Yes NODAL MCC SENDS AN AVAILABILITY WARNING MESSAGE TO THE GEOLUT OPERATOR / GROUND SEGMENT PROVIDER FOR THE GEOLUT(i) /GEOSAT(j) COMBINATION USING SIT 915 MESSAGE TEMPLATE PROVIDED AT C/S A.003, ANNEX D DU = DU + 1 GEOLUT(i) / GEOSAT(j) STATUS = RED DU: DAYS OF UNAVAILABILITY DU = 4 ? No NODAL MCC DECLARES GEOLUT(i) IS NOT CONFORMING IN RESPECT OF GEOSAT(j) PROCESS BEGINS DU = 0 GEOLUT(i) / GEOSAT(j) STATUS = GREEN Yes GEOLUT(i) / GEOSAT(j) STATUS = RED? GEOLUT(i) / GEOSAT(j) AVAILABILITY ≥ 80%? No No Yes No Yes NODAL MCC CHANGES AVAILABILITY STATUS FOR GEOLUT(i) / GEOSAT (j) COMBINATION TO GREEN NODAL MCC SEND A MESSAGE IN A SIT 605 FORMAT TO ALL MCCs AND THE SECRETARIAT USING MESSAGE TEMPLATE PROVIDED AT C/S A.003, ANNEX D NODAL MCC SEND A MESSAGE IN A SIT 605 FORMAT TO ALL MCCs AND THE SECRETARIAT USING MESSAGE TEMPLATE PROVIDED AT C/S A.003, ANNEX D NODAL MCC UPDATE AVAILABILITY TABLE POSTED ON THE COSPAS- SARSAT WEB SITE FOR GEOLUT(i) / GEOSAT (j) COMBINATION TO RED (Note: This decision tree is valid only when the GEOSAR space segment is operational) Figure 2.2: GEOLUT Availability Assessment, Status Reporting and Follow-up Actions

2-23

2.5.4 LEOLUT Location Accuracy Assessment, Status Reporting and Follow-up Actions 2.5.4.1 Location Accuracy Warning The 5-km accuracy ratio shall be greater than or equal to 95%. The 10-km accuracy ratio shall be greater than or equal to 98%. If these two criteria are met, the status of the LEOLUT(i) / LEOSAT(j) combination shown in the LEOLUT accuracy table posted on the Cospas-Sarsat website is "Green" (see Table 2.1: Template for the LEOLUT Status Table (Availability and Accuracy). If either of these two criteria is not met the nodal MCC shall notify the associated MCC, using the SIT 915 message template provided at Annex D. The status of the LEOLUT(i) / LEOSAT(j) combination shown in the LEOLUT accuracy table posted on the Cospas- Sarsat website is not changed. If these two criteria are met after a SIT 915 (warning) message was sent for the previous reporting period, no message should be sent to confirm the return to conformity. 2.5.4.2 Unreliable Alert Data Filtering If the 5-km accuracy ratio falls below 60% or the 20-km accuracy ratio falls below 80%, (i.e., R.5 (i,j) < 0.6 or R.20 (i,j) < 0.8) for a LEOLUT(i) / LEOSAT(j) combination: a) the nodal MCC shall: i. process alert messages provided by LEOLUT(i) when processing LEOSAT(j) based only on the 406 MHz beacon message - the Doppler solution data shall not be distributed, ii. inform all MCCs and the Secretariat using the SIT 605 message template provided at C/S A.003, Annex D, iii. update the LEOLUT accuracy table posted on the Cospas-Sarsat website to show a “Red” accuracy status for the LEOLUT / LEOSAT combination, iv. update the LEOLUT availability table to show a “Red” availability status for the LEOLUT / LEOSAT combination; and b) the associated MCC shall upon receipt of the above SIT 605 message from its nodal MCC: i. process alert messages provided by its LEOLUT(i) when processing LEOSAT(j) based only on the 406 MHz beacon message - the Doppler solution data shall not be distributed, ii. continue to send to the nodal MCC QMS data with Doppler solution data,

2-24

iii. send a SIT 915 informing the nodal MCC that the alert data for the LEOLUT(i) and LEOSAT(j) combination is being suppressed. 2.5.4.3 Resuming LEOSAR Green Accuracy Status If the LEOLUT non-conformity is corrected, as soon as the LEOLUT(i) / LEOSAT(j) accuracy ratios for 5 km (R.5 (i,j)) and 10 km (R.10 (i,j)) meet respectively the 95% and 98% accuracy criteria, a) the nodal MCC shall: i. inform all MCCs and the Secretariat using the SIT 605 message template provided at C/S A.003, Annex D, ii. resume the distribution of Doppler solution data provided by LEOLUT(i) when processing LEOSAT(j), iii. update the LEOLUT accuracy table posted on the Cospas-Sarsat website to show a “Green” accuracy status for the LEOLUT / LEOSAT combination, iv. provided the corresponding availability ratio is also met, update the LEOLUT availability table on the Cospas-Sarsat website to show a “Green” availability status for the LEOLUT / LEOSAT combination; and b) the associated MCC shall upon receipt of the above SIT 605 message from its nodal MCC: i. resume the distribution of Doppler solution data provided by its LEOLUT(i) when processing LEOSAT(j), ii. send a SIT 915 informing the nodal MCC that the alert data with Doppler solution data for the LEOLUT(i) and LEOSAR(j) combination has resumed. Note: It is recognised that the 3-day data requirement to compute the accuracy ratio may introduce a 3-day latency for resuming Doppler location data distribution after the LEOLUT nonconformity is corrected. This latency is considered acceptable, noting that: i. the “Red” status for a LEOLUT / LEOSAT combination does not affect the accuracy and availability status of other LEOSAT combinations for the same LEOLUT, ii. Doppler location data suppression is implemented after several days of warning and on the basis of continuous evidence of very serious deficiencies concerning the reliability of this location data, therefore, sufficient evidence of a return to conformity must be available, and iii. the 3-day latency does not impact the case of LEOLUT returning to normal operation after a total interruption of operation (e.g., for maintenance), as

2-25

the accuracy ratio computed on a single day of location accuracy data should indicate conformity with the accuracy ratio requirements. The process described above is depicted in Figure 2.4. 2.5.4.4 LEOLUT Location Accuracy Processing with No QMS Alert Data If no QMS alert data is received for a LUT/satellite pair, then the current location accuracy status should be maintained until alert data becomes available and the normal QMS analysis process allows assessment of the status. 2.5.4.5 LEOSAR and GEOSAR Satellite Availability When the Space Segment Provider sends a SIT 605 message providing notification of a problem that significantly affects LEOSAR or GEOSAR satellite availability (e.g., satellite downlink transmission interruption), the Space Segment Provider shall log in to the Cospas-Sarsat website and force the satellite column to red for the associated QMS availability and/or accuracy matrix. Each LUT/satellite pair shall retain its computed QMS status. When the Provider sends a SIT 605 message indicating that normal satellite availability has resumed, the Provider shall log in to the Cospas-Sarsat website and re-establish the computed QMS state for the satellite column of the associated QMS availability and/or accuracy matrix, as appropriate. 2.5.5 MEOLUT Assessment, Status Reporting and Follow-up Actions 2.5.5.1 Reporting Status Changes Prior to the first assessment of the MEOLUT status for a metric, the status is assumed to be “Green”. Status changes (e.g., “Green” to “Red”, “Red” to “Yellow”) are computed by comparing the previous status to the new status. The status “Green+” is treated the same as the “Green” status unless otherwise noted. The nodal MCC shall update the Cospas-Sarsat website to show the new status for a metric when: a) the status of a metric changes, including a change to or from the “Green+” status; b) insufficient data is available to assess a metric for which sufficient data was available in the previous analysis period; or c) sufficient data is available to assess a metric for which insufficient data was available in the previous analysis period.

2-26

If the status for location accuracy or location probability changes to “Red” or from “Red”, the nodal MCC shall send a SIT 605 message to all MCCs and the Secretariat using the appropriate template provided in Annex D. For any other change in status to “Red” or “Yellow”, the nodal MCC shall send a SIT 915 message to the associated MCC using the appropriate template provided in Annex D. For all other status changes, a SIT 915 or 605 message is not required and the associated MCC should review the Cospas-Sarsat website to see if the status for a metric has returned to conforming (“Green”, “Green+”) status. The associated MCC should review the Cospas-Sarsat website for information about location accuracy, probability of location, and detection probability for individual, designated reference beacons. 2.5.5.2 MEOLUT Location Accuracy If at least 20 DOA locations each from single-burst solutions and from multi-burst solutions were included in the analysis for all designated reference beacons of a beacon generation (FGB or SGB), together, use the location accuracy ratios (i.e., SB_LocAcc_X_AllBeacons (FGB or SGB) and MB_LocAcc_X_AllBeacons (FGB or SGB)), computed for all designated reference beacons together, to determine the location accuracy status as follows: Burst Type Location Error (km) Status FGB Criteria SGB Criteria Single burst X1 Green + ≥ 0.90 ≥ 0.95 Green ≥ 0.75 ≥ 0.80 Yellow 0.50 ≤ P<0.75 0.55 ≤ P<0.80 Red < 0.50 < 0.55 X2 Green + ≥ 0.90 ≥ 0.90 Green ≥ 0.90 ≥ 0.90 Yellow 0.80 ≤ P < 0.90 0.80 ≤ P < 0.90 Red < 0.80 < 0.80 Multi burst X3 Green + ≥ 0.95 ≥ 0.97 Green ≥ 0.90 ≥ 0.92 Yellow 0.65 ≤ P < 0.90 0.70 ≤ P < 0.92 Red < 0.65 <0.70 X4 Green + ≥ 0.90 ≥ 0.90 Green ≥ 0.90 ≥ 0.90 Yellow 0.80 ≤ P < 0.90 0.80 ≤ P < 0.90 Red < 0.80 < 0.80

2-27

The location accuracy status of the MEOLUT to be shown in Table 2.3 must be defined per beacon generation as follows: • Green+: all parameters meet Green+ status, • Green: all parameters meet either Green or Green+ status, but not all parameters meet Green+ status, • Red: one or more parameters are Red status, • Yellow: not Green+, Green or Red. For each beacon generation, if the location accuracy status changes from “Green+”, “Green” or “Yellow” to “Red”, then: a) the nodal MCC shall: i. process alert messages provided by the MEOLUT only based on the 406 MHz beacon message and not distribute the DOA solution data, ii. report the status change (to include SIT 605 notification) as specified in section 2.5.5.1 above; and b) upon receipt of the related SIT 605 message from the nodal MCC, the associated MCC shall: i. process alert messages provided by the MEOLUT only based on the 406 MHz beacon message and not distribute the DOA solution data, ii. continue to send DOA solution data for designated reference beacons to the nodal MCC, iii. send a SIT 915 message informing the nodal MCC that DOA solution data is being suppressed for the MEOLUT. For each beacon generation, if the location accuracy status changes from “Red” to “Green+”, “Green” or “Yellow”, then: a) the nodal MCC shall: i. resume the distribution of DOA solution data for the MEOLUT, ii. report the status change (to include SIT 605 notification) as specified in section 2.5.5.1 above; and b) upon receipt of the related SIT 605 message from the nodal MCC, the associated MCC shall: i. resume the distribution of DOA solution data for the MEOLUT, ii. send a SIT 915 message informing the nodal MCC that DOA solution data is no longer being suppressed for the MEOLUT.

2-28

For any other changes in location accuracy status, the nodal MCC shall report the status change as specified in section 2.5.5.1 above. If fewer than 20 DOA locations each from single burst solutions and from multi-burst solutions were included in the analysis*, then the current location accuracy status shall be maintained and the status on the C/S website shall be marked with “n/i” to indicate the lack of current data. The nodal MCC shall update the Cospas-Sarsat website to show the location accuracy ratios per designated reference beacon, for single burst and multi-burst solutions, for the X1, X2, X3 and X4 km thresholds (as applicable), the two numbers used to compute each ratio, and the status associated with each ratio; the status is based on the corresponding location accuracy threshold specified above (e.g., if the FGB single burst location accuracy ratio within 5 km for a designated reference beacon is ≥ 0.90, then the corresponding status is “Green+”). If a ratio is not available (i.e., the number of associated solutions is zero), then it shall be shown as “n/i”. Note: (*) Having an insufficient number of solutions included in the analysis is an indication of either a severe degradation of the MEOLUT performance (no beacon bursts received), or the consequence of the unavailability of QMS reference beacons (no beacon bursts transmitted) and requires immediate attention of the MEOLUT operator. 2.5.5.3 MEOLUT Location Probability Use the location probability values for all designated reference beacons of a given generation together (i.e., SB_PLoc_AllBeacons (FGB or SGB) and MB_PLoc_AllBeacons (FGB or SGB), per section 2.4.2.3) to determine the location probability status as follows: Burst Type Status FGB Criteria SGB Criteria Single burst Green ≥ 0.90 ≥ 0.95 Yellow 0.65 ≤ P < 0.90 0.70 ≤ P < 0.95 Red < 0.65 < 0.70 Multiple burst Green ≥ 0.98 ≥ 0.98 Yellow 0.73 ≤ P < 0.98 0.73 ≤ P < 0.98 Red < 0.73 < 0.73 The location probability status of the MEOLUT to be shown in Table 2.3 must be defined per beacon generation as follows: • Green: all parameters meet Green status , • Red: one or more parameters are Red status , • Yellow: not Green or Red.

2-29

If a location probability status changes, the nodal MCC shall report the status change as specified in section 2.5.5.1 above. The nodal MCC shall update the Cospas-Sarsat website to show the location probability ratios per designated reference beacon, for single burst and multi-burst solutions, the two numbers used to compute each ratio, and the status associated with each ratio; the status is based on the corresponding detection probability threshold specified above. If a ratio cannot be determined (e.g., a reference beacon is not available), then the status shall be shown as “n/i". 2.5.5.4 MEOLUT Detection Probability Use the detection probability ratios (i.e., “DetProbr” per section 2.4.2.4) to determine the detection probability status as follows: Status FGB Criteria SGB Criteria Green ≥ 0.99

0.99 Yellow 0.97 ≤ P < 0.99 0.97 ≤ P < 0.99 Red < 0.97 < 0.97 The detection probability status of the MEOLUT to be shown in Table 2.3 must be defined per beacon generation as follows: • Green: all parameters meet Green status, • Red: one or more parameters are Red status, • Yellow: not Green or Red. If the detection probability status changes, the nodal MCC shall report the status change as specified in section 2.5.5.1 above. The nodal MCC shall update the Cospas-Sarsat website to show the detection probability ratio per designated reference beacon, and the two numbers used to compute each ratio. If a ratio cannot be determined (e.g., a reference beacon is not available), then the status shall be shown as “n/i". 2.5.5.5 MEOLUT Local Antenna Channel Availability If at least 20 DOA locations were included in the analysis, then use the MEOLUT antenna channel ratio (i.e., “LocAr” per section 2.4.2.5) to determine the local antenna availability status as follows: • Green: ratio ≥ 0.95, • Red: ratio < 0.80, • Yellow: not Green or Red.

2-30

The local antenna availability status of the MEOLUT to be shown in Table 2.3 must be defined per beacon generation. If the local antenna channel availability status changes, the nodal MCC shall report the status change as specified in section 2.5.5.1 above. If fewer than 20 DOA locations were included in the analysis, then the status shall be shown as “n/i” on the Cospas-Sarsat website. If no data is available for this ratio because the MEOLUT does not process networked data, then the status shall be shown as “n/a” on the Cospas-Sarsat website. 2.5.5.6 MEOSAR System Timeliness If at least 20 solutions were included in the analysis, then use the MEOSAR System timeliness ratio to determine the timeliness status as follows: • Green: ratio ≥ 0.95, • Red: ratio < 0.80, • Yellow: not Green or Red. The timeliness status of the MEOSAR system to be shown in Table 2.3 must be defined per beacon generation. If the timeliness status changes, the nodal MCC shall report the status change as specified in section 2.5.5.1 above. If fewer than 20 solutions were included in the analysis, then the status shall be shown as “n/i” on the Cospas-Sarsat website. 2.5.5.7 Quality of Location Expected Horizontal Error If at least 20 DOA locations were included in the analysis, then use the EHE quality ratios to determine the EHE Quality status as follows: • Green: ratio < 0.98 and ratio > 0.92, • Red: ratio ≥ 0.99 or ratio ≤ 0.91, • Yellow: not Green or Red. The location EHE quality status of the MEOLUT to be shown in Table 2.3 must be defined per beacon generation. The nodal MCC shall update the Cospas-Sarsat website to show the EHE quality ratio per MEOLUT, and the two numbers used to compute each ratio. If the EHE quality status changes, the nodal MCC shall report the status change as specified in section 2.5.5.1

2-31

above. If fewer than 20 solutions were included in the analysis, then the status shall be shown as “n/i” on the Cospas-Sarsat website. 2.5.6 MCC Availability MCCs’ operational or non-operational status is shown on the Cospas-Sarsat website in the MCC status table illustrated at Table 2.4. When an MCC requires backup, the nodal MCC shall update the MCC status table posted on the C/S website. A SIT 605 message shall be sent to all MCCs and the Secretariat confirming the backed-up status of the failed MCC. The website MCC status table shall be updated by the nodal MCC as soon as the failed MCC returns to normal operations. The backup MCC shall inform all MCCs and the Secretariat of the change of status of the failed MCC, using a SIT 605 message. The nodal MCC shall update daily the “Last Report Date” on the Cospas-Sarsat website for the MCC status table to indicate the time at which the MCC status was last assessed. In addition, the nodal MCC shall provide the time of the last MCC status change in the “Comments” column per MCC. Table 2.5: Template for the MCC Status Table MCC OPERATIONAL BACKED UP COMMENTS MCC 1 √ MCC 2 √ Temporary backup by MCC 3 MCC 3 √ MCC 4 √ MCC N √

2-32

Figure 2.3: LEOLUT Location Accuracy Assessment, Status Reporting and Follow-Up Actions

  • END OF SECTION 2 -

Image 1 from page 43

3-1

SYSTEM SELF-MONITORING This section describes the self-monitoring methodology for the ground and space segments of the Cospas-Sarsat System. The continuous monitoring described in section 2 provides an objective method to monitor LUT location accuracy, LUT availability and MCC availability on an ongoing basis. However, this does not replace the need for periodic detailed analysis of each element of the Cospas-Sarsat System. This section describes the various performance parameters. For the LEOSAR system, they are generally estimated with reference to a standard pass of a satellite over a beacon (i.e., a pass with a maximum beacon to satellite elevation angle of at least 8) or for satellite passes over LEOLUTs at elevation angles over 5. 3.1 Ground Segment Self-Monitoring Ground Segment operators should monitor the performance of the LEOSAR and GEOSAR elements of the Cospas-Sarsat system. This self-monitoring should be performed by analyzing a set of parameters that address issues indicative of the overall performance of the system. Monitoring of these performance parameters can identify system anomalies that have the potential of degrading system performance and lead to non-conformity in LEOLUT and GEOLUT availability and LEOLUT accuracy. Timely identification and correction of these anomalies ensures system integrity. Some of the performance parameters described below are measured against baseline values. These baseline values should be measured when each Ground Segment component is installed, or whenever there is any significant change to the relevant parts of the Space Segment or Ground Segment. In addition, document C/S A.005 “Cospas-Sarsat MCC Performance Specification and Design Guidelines”, requires an MCC to monitor additional System elements in its national ground segment including LUT/MCC communication networks, the MCC itself and connections to external communication networks. 3.1.1 LEOSAR System Performance Parameters The LEOSAR performance parameters are organized into two tiers. Tier one performance parameters are those parameters that every Ground Segment Operator that operates a LEOLUT should monitor because of their direct relationship to alert data accuracy, timeliness and reliability. Tier one performance parameters include: • LEOSAR System Timing, • Sarsat SARP Time Calibration Accuracy, • Sarsat SARP Frequency Calibration Accuracy,

3-2

• Sarsat SARR Frequency Calibration Accuracy, • LEOSAR Satellite Orbit Data Accuracy. Tier two performance parameters are those parameters that should be checked by every Ground Segment Operator that operates a LEOLUT and has the necessary tools to perform this monitoring. Tier two performance parameters include: • LEOSAR Received Downlink Power Level, • Loss of Carrier Lock, • SARP Throughput, • PDS Data Recovery Rate, • Number of Single Point LEOSAR Alerts, • SARP Bit Error Rate, • LEOSAR SARR Bit Error Rate, • LEOSAR Pass Scheduling Accuracy. The following sections provide a detailed description of these performance parameters. In addition, Annex C provides a summary of these performance parameters and can be used by ground segment operators as a quick reference for the operational self-monitoring of the LEOSAR system. 3.1.1.1 LEOSAR System Timing The LEOSAR System Timing is measured from the end of a satellite pass until the time when an incident alert is sent to an RCC or SPOC. Indicator: The ability to transmit the incident alert data generated by a LEOLUT to the appropriate RCC or SPOC within a shorter time of the end of a satellite pass indicates an improved capability in the system to maintain the level of service required by the objective. Rationale: This performance parameter ensures that the LEOSAR System Timing information is routinely verified and distributed. Definitions: The LEOSAR System Timing measures the time from the end of a LEOSAR satellite pass over a LEOLUT to the time when the incident alert message is sent to the appropriate RCC or SPOC by the National MCC.

3-3

TLOS = Time of Loss of Signal of the LEOSAR satellite at the LEOLUT TMCCTX = Time when the MCC transmits the incident alert message to the selected destination The LEOSAR System Timing is then: LST = ( TMCCTX - TLOS ) Metric(s): The LEOSAR System Timing is measured in seconds. Reporting Criterion: If the LEOSAR System Timing is more than twenty minutes (1200 seconds) for any incident alert, then a System Anomaly notification message should be generated. Data Collection Process: Every time the MCC transmits an incident alert message based on a LEOSAR detection, it should determine the LEOSAR System Timing associated with that alert. Data Verification Process: The LEOSAR System Timing should be computed automatically by each MCC, using the data available to it from the LUT. This data is not normally verified by the Operator. Relevant Documents: C/S A.005, C/S T.002. Action: If a LEOSAR System Timing anomaly is reported, the MCC operator should check on the LUT and MCC processing times associated with the alert. If there is no problem with the actual processing time, then the MCC operator should check on the time required for communication of the incident alert data at various stages in the processing of the alert. Comments: The Cospas-Sarsat alert notification time is the time elapsed from beacon activation until the first alert message is delivered to the appropriate RCC. However, this alert notification time includes: • the waiting time until a satellite passes over the beacon and transmits the beacon data to a LUT, and • the MCC to RCC communication times, which are not specific to the Cospas-Sarsat system and cannot be easily measured.

3-4

Therefore, to assess the Cospas-Sarsat system performance, the LEOSAR System Timing is defined above as the time elapsed from the end of the pass on which the beacon was detected until the alert data is ready for transmission from a Cospas-Sarsat MCC to the appropriate RCC or SPOC. In the 406 MHz system, the LEOSAR System Timing does not include the waiting time or the satellite storage time. These times can be: • estimated by MCCs on the basis of statistics of real transmissions, • measured by analyzing the results of a system exercise, or • estimated by computer simulations using an analytical model describing the satellite constellation, the Cospas-Sarsat LUT/MCC network, and a specific geographical distribution of beacons. The LEOSAR System Timing does include the LUT processing time, the LUT/MCC data transfer time, and the MCC processing time. 3.1.1.2 Sarsat SARP Time Calibration Accuracy The SARP Time Calibration Data Accuracy reports when the SARP Time Calibration Data for a Sarsat LEOSAR satellite changes by an amount that is larger than the established criterion. Indicator: The fewer times the SARP Time Calibration Data Accuracy reports an anomaly, the better the quality of the calibration data that is available to the system, and the more accurate the beacon location estimates produced by the system. Rationale: This performance parameter ensures that the SARP Time Calibration Data for each Sarsat LEOSAR satellite is monitored to determine when the system has difficulty maintaining this data. Metric(s): The SARP Time Calibration Data Accuracy is measured in seconds. Reporting Criterion: The criterion for a SARP Time Calibration Data Accuracy anomaly is ten milliseconds. If (DRTIME > 0.010), then a SARP Time Calibration anomaly should be reported.

3-5

Data Collection Process: Every time the Sarsat LEOSAR satellite SARP Calibration Data are upgraded in the system, the LEOLUT or the MCC should propagate the old SARP Rollover Time to the time of the new SARP Time Calibration data and should compare the resulting SARP Rollover time values. If the values differ by more than the specified criteria, then the LEOLUT should report a SARP Time Calibration Data Accuracy anomaly to the host MCC. Data Verification Process: The SARP Calibration Data Accuracy should be checked by each LEOLUT or MCC whenever new SARP Calibration Data is received by that system. This data is not normally verified by the Operator. Relevant Documents: C/S A.005, C/S T.002, C/S T.003. Action: If a SARP Calibration Data Accuracy anomaly is detected from a single LUT for all satellites, the LUT operator should review the SARP Calibration data and SARP Calibration processing on that LUT. If a SARP Calibration Data Accuracy anomaly is detected from a single satellite for all LUTs, the LUT operator should review the SARP Calibration data for that satellite. Comments: This performance measure provides information about the reliability of the Sarsat LEOSAR satellite SARP Calibration Data processing in the Cospas-Sarsat system. This information assists in the understanding of the accuracy of the beacon location estimates generated by the Cospas-Sarsat system. The SARP Calibration Data applies only to the Sarsat LEOSAR satellites. The Cospas LEOSAR satellites report the beacon message time and frequency in a different format, and do not require any SARP Calibration Data. 3.1.1.3 Sarsat SARP Frequency Calibration Accuracy The SARP Frequency Calibration Data Accuracy reports when the SARP Frequency Calibration Data for a Sarsat LEOSAR satellite changes by an amount that is larger than the established criterion.

3-6

Indicator: The fewer times the SARP Frequency Calibration Data Accuracy performance parameter reports an anomaly, the better the quality of the calibration data that is available to the system, and the more accurate the beacon location estimates produced by the system. Rationale: This performance parameter ensures that the SARP Frequency Calibration Data for each Sarsat LEOSAR satellite is monitored to determine when the system has difficulty maintaining this data. Definitions: The SARP Calibration Data for a Sarsat LEOSAR satellite are the data values that describe the internal operation of the Search and Rescue Processor (SARP) on-board the satellite. This data is used to compute the time each beacon message is received at the satellite, and the received frequency of each beacon message. This SARP Calibration Data consists of the timer Rollover Time and the frequency of the Ultra-Stable Oscillator (USO) in the SARP instrument (refer to the Description of the Payloads Used in the Cospas-Sarsat LEOSAR system, document C/S T.003, for a more complete description of the Sarsat SARP Calibration). USOO = USO frequency in previous SARP Calibration data USON = USO frequency in new SARP Calibration data The USO frequency difference is then: DUSO = | USON – USOO | Metric(s): The SARP Frequency Calibration Data Accuracy is expressed in Hertz. Reporting Criterion: The criterion for the SARP Frequency Calibration Data Accuracy is 0.05 Hz. If (DUSO

0.05), then a SARP Time Calibration anomaly should be reported by the MCC. Data Collection Process: Every time the Sarsat LEOSAR satellite SARP Calibration Data are upgraded in the system, the LEOLUT or the MCC should compare the old USO Frequency to the new USO Frequency. If the values differ by more than the specified criteria, then a SARP Frequency Calibration Data Accuracy anomaly should be reported by the host MCC.

3-7

Data Verification Process: The SARP Calibration Data Accuracy should be checked by each LEOLUT or MCC whenever new calibration data is received by that system. This data is not normally verified by the Operator. Relevant Documents: C/S A.005, C/S T.002, C/S T.003. Action: If a SARP Calibration Data Accuracy anomaly is detected from a single LUT for all satellites, the LUT operator should review the SARP Calibration data and SARP Calibration processing on that LUT. If a SARP Calibration Data Accuracy anomaly is detected from a single satellite for all LUTs, the LUT operator should review the SARP Calibration data for that satellite. Comments: The SARP Calibration Data applies only to the Sarsat LEOSAR satellites. The Cospas LEOSAR satellites report the beacon message time and frequency in a different format, and do not require any SARP Calibration Data. 3.1.1.4 Sarsat SARR Frequency Calibration Accuracy The Sarsat SARR Frequency Calibration Data Accuracy reports when the SARR Frequency Calibration Data for a LEOSAR satellite changes by an amount that is larger than the established criterion. Indicator: The fewer times the SARR Frequency Calibration Data Accuracy performance parameter reports an anomaly, the better the quality of the calibration data that is available to the system, and the more accurate the beacon location estimates produced by the Combined LEO-GEO processing. Rationale: This performance parameter ensures that the SARR Frequency Calibration Data for each LEOSAR satellite is monitored to determine when the system has difficulty maintaining this data. Definitions: The SARR Frequency Calibration Data Accuracy (SFCDA) for a LEOSAR satellite describes the stability of the SAR Repeater on-board the satellite. This data is used to calibrate the received frequency of each beacon message, for the Combined LEO-GEO Processing in a LEOLUT. This SARR Calibration Data is the measured frequency offset

3-8

of the data received through the SAR Repeater on the satellite (refer to MF# 64, defined in the Annex “Message Fields Descriptions” of C/S A.002). SFO = Received frequency in previous SARR Calibration data SFN = Received frequency in new SARR Calibration data SFCDA = | SFN – SFO | Metric(s): The SARR Frequency Calibration Data Accuracy is expressed in Hertz. Reporting Criterion: The criterion for the SARR Frequency Calibration Data Accuracy is 1.0 Hz. If (SFCDA > 1.0), then a SARR Time Calibration anomaly should be reported by the MCC. Data Collection Process: Every time the LEOSAR satellite SARR Frequency Calibration Data are upgraded in the system, the LEOLUT or the MCC should compare the old SARR Frequency to the new SARR Frequency. If the values differ by more than the specified criteria, then a SARR Frequency Calibration Data Accuracy anomaly should be reported by the host MCC. Data Verification Process: The SARR Frequency Calibration Data Accuracy should be checked by each LEOLUT or MCC whenever new calibration data is received by that system. This data is not normally verified by the Operator. Relevant Documents: C/S A.002, C/S A.005, C/S T.002. Action: If a SARR Calibration Data Accuracy anomaly is detected from a single LUT for all satellites, the LUT operator should review the SARR Calibration data and SARR Calibration processing on that LUT. If a SARR Calibration Data Accuracy anomaly is detected from a single satellite for all LUTs, the LUT operator should review the SARR Calibration data for that satellite. Comments: The SARR Calibration data is only produced by a LEOLUT that has a calibrated reference beacon within the local footprint of the LEOSAR satellites while they are being tracked by the LEOLUT. This data is normally measured by the Canadian LUTs and distributed through the Cospas-Sarsat system by the Canadian MCC once a week. The anomaly

3-9

criterion is based on the assumption that each change of the SARR Frequency Calibration Data will be within a week or less of the previous update. If there is a longer period of time between updates, then the magnitude of the change may be larger than the criterion value. 3.1.1.5 LEOSAR Orbit Data Accuracy The Orbit Data Accuracy reports when the orbital data for a LEOSAR satellite changes by an amount that is larger than the established criterion. Indicator: The fewer times the Orbit Data Accuracy reports an anomaly, the better the quality of the orbit ephemeris data that is available to the system, and the more accurate the beacon location estimates produced by the system. Rationale: This performance parameter ensures that the orbit data for each LEOSAR satellite is monitored to determine when the system has difficulty maintaining this data. Definitions: The orbital elements of a LEOSAR satellite are the data values that describe the orbital path of the satellite and the position of the satellite at a specified time. These orbital elements consist of an Epoch Time and six numerical data values. In the definition below, the Earth-Fixed format is used for the comparison of the orbital elements. (The data values may be specified in any of a number of data formats, and other formats may be used internally in the system to store this information; the details of the formats that are actually used are irrelevant to the validation of this Performance Measure.) EPOCHO = Epoch time of previous orbital elements EPOCHN = Epoch time of new orbital elements POS(i)O = Satellite position vector based on old orbital elements, propagated forward to the time EPOCHN POS(i)N = Satellite position vector based on new orbital elements, at time EPOCHN VEL(i)O = Satellite velocity vector based on old orbital elements, propagated forward to the time EPOCHN VEL(i)N = Satellite velocity vector based on new orbital elements, at time EPOCHN DPOS = SquareRoot ( Sum ( POS(i)O - POS(i)N )2 ) DVEL = SquareRoot ( Sum ( VEL(i)O - VEL(i)N )2 )

3-10

Metric(s): The Orbit Accuracy is measured as both position accuracy and velocity accuracy: • the position accuracy is measured in kilometres, • the velocity accuracy is measured in meters per second. Reporting Criterion: The criteria for the generation of an Orbit Accuracy anomaly on the position and velocity vectors are five kilometres and five meters per second, respectively. If (DPOS > 5.0) or if (DVEL > 5.0), then an anomaly should be reported by the MCC. Data Collection Process: Every time the LEOSAR satellite orbital elements are upgraded in the system, the LEOLUT or the MCC should propagate the old orbit data to the time of the new orbit data and should compare the resulting position and velocity vectors. If the vectors differ by more than the specified criteria, then an Orbit Data Accuracy anomaly should be reported by the host MCC. Data Verification Process: The Orbit Data Accuracy should be checked by each LEOLUT or MCC whenever new orbit data is received by that system. This data is not normally verified by the Operator. Relevant Documents: C/S A.005, C/S T.002. Action: If an Orbit Data Accuracy anomaly is detected from a single LEOLUT for all satellites, the LEOLUT operator should review the Orbit data and Orbit data processing on that LEOLUT. Comments: As noted in the LEOLUT Specification and Design Guidelines, “in the event of a scheduled satellite manoeuvre (as described in document C/S A.001), the LEOLUT may not be able to maintain accurate orbital elements. When such an event changes the satellite position by more than two kilometres since the previously tracked pass, this accuracy requirement is waived ....” (C/S T.002, paragraph 5.1.3) In the event of a scheduled satellite manoeuvre, the requirement that the LEOLUT should generate a System anomaly notification message is also waived. This performance parameter provides information about the reliability of the LEOSAR satellite orbital data processing in the Cospas-Sarsat system. This information assists in

3-11

the understanding of the accuracy of the beacon location estimates generated by the Cospas-Sarsat system. 3.1.1.6 LEOSAR Received Downlink Power Level The Received Downlink Power Level is maintained separately for each combination of satellite and LUT ground station. Indicator: If the power level of the 1544.5 MHz satellite downlink signal received by the LUT increases, then the system is better able to receive and decode the beacon messages in the signal. Rationale: This performance parameter provides for the monitoring of the satellite downlink signal and ensures that the quality of the satellite signal will be monitored regularly. It also provides data to assist with the detection of interfering signals in the downlink frequency band. Definitions: The Downlink Power is measured in dB, using the AGC value at the LUT receiver; it is assessed separately for each combination of satellite and LUT. For the LEOSAR system, the measurement is made for each satellite pass above five degrees elevation, and for the GEOSAR system the measurement is made over each one-hour period. MRP = Maximum Received Power The Baseline Value is assessed on the basis of measurements made over a one-week period of normal system operation. It is computed as ten dB lower than the average over this period: BMRP = Average ( MRP ) – 10 Metric(s): The Received Downlink Power Level is measured in decibels (dB). Reporting Criterion: If the Received Downlink Power Level is less than the Baseline Value (as indicated above), then a System anomaly notification message should be generated. Data Collection Process: The LUT should monitor the downlink signal at all times when it is tracking a satellite and record the AGC level at regular intervals. The level corresponding to the maximum

3-12

signal level over each observation period should then be converted to dB. If the level is below the baseline, then an anomaly should be reported. Data Verification Process: The Downlink Power Level data should be processed independently by each LUT; it is not verified by the Operator. Relevant Documents: C/S A.005, C/S T.002, C/S T.009. Action: If a Received Downlink Signal Power Level anomaly is detected from a single LUT for all satellites, the LUT operator should review the satellite receive equipment and processing. If a Received Downlink Signal Power Level anomaly is detected from a single satellite for all LUTs, the LUT operator should report this to the MCC responsible for coordination with the satellite operator. 3.1.1.7 LEOSAR Loss of Carrier Lock The Loss of Carrier Lock is maintained separately for each combination of satellite and LUT ground station. Indicator: When the duration of Loss of Carrier Lock is reduced, that indicates that the downlink signal is being received better at the LUT, and the LUT will be better able to extract beacon messages and measure the time and frequency of each message. Rationale: This performance parameter provides for the monitoring of the LEOSAR satellite downlink signal and ensures that the quality of the satellite signal will be monitored regularly. Definitions: The Loss of Carrier Lock is assessed separately for each combination of satellite and LUT. For the LEOSAR system, the measurement is made for each satellite pass while the satellite is above five degrees elevation, and for the GEOSAR system the measurement is made over each one-hour period. DCLL = Total Duration of Losses of Carrier Lock

3-13

The Baseline Value is assessed on the basis of measurements made over a one-week period of normal system operation. It is computed as ten percent higher than the average over this period: BCLL = 1.1 * (Average duration of Loss of Carrier Lock per Pass) Metric(s): The duration of Loss of Carrier Lock is measured in seconds. Reporting Criterion: If the Loss of Carrier Lock on any satellite pass is greater than the Baseline Value (as indicated above), then a System anomaly notification should be generated. Data Collection Process: The LUT should monitor the downlink signal at all times when it is tracking a satellite and record every Loss of Carrier Lock. After every LEOSAR satellite pass, or every hour for a GEOLUT, the LUT should determine the cumulative duration of loss of lock. If the value is greater than the baseline, then an anomaly should be reported. Data Verification Process: The Loss of Carrier Lock data should be processed independently by each LUT; it is not verified by the MCC Operator. Relevant Documents: C/S A.005, C/S T.002, C/S T.009. Action: If a Loss of Carrier Lock anomaly is detected from a single LUT for all satellites, the LUT operator should review the satellite receive equipment and processing. If a Loss of Carrier Lock anomaly is detected from a single satellite for all LUTs, the LUT operator should report this to the MCC responsible for coordination with the satellite operator. 3.1.1.8 SARP Throughput The SARP Throughput is the percentage of the number of expected messages from the system reference beacons actually received in the PDS during a LEOSAR satellite pass over a reference beacon. It is maintained separately for each combination of LEOSAR satellite and LEOLUT ground station.

3-14

Indicator: When the SARP Throughput improves, it shows that the system is better able to receive and process the distress beacon data and to generate the necessary incident alerts. Rationale: This performance ensures that each LUT monitors the data received from the known reference beacons, and reports whenever it does not receive the expected data. Definitions: #EXP = Number of messages expected from a reference beacon on a given pass. (This is based on the known position of the beacon and the known satellite orbital data. Annex C, Table C.3 lists the number of measurements expected from a beacon at various positions relative to the over-flying satellite.) #RCV = Number of messages received from the beacon on the actual satellite pass The throughput is then the percentage of the expected messages that are actually received by the LUT: THRU = 100 * #RCV / #EXP Metric(s): The SARP Throughput is expressed as a percentage of the number of messages that are expected to be received by the LUT. Reporting Criterion: The criterion for issuing a SARP Throughput anomaly report is 70%: If (THRU < 70%), then a System anomaly notification message should be generated. Data Collection Process: Every time a LUT processes data from a LEOSAR satellite that has passed over a reference beacon since the last pass tracked by that LUT, it should compute and verify the SARP Throughput. Data Verification Process: The SARP Throughput should be computed by each LEOLUT, using the data it receives from the LEOSAR satellites. This data is not normally verified by the Operator. Relevant Documents: C/S T.002.

3-15

Action: If a SARP Throughput anomaly is detected from a single LUT for all satellites, the LUT operator should review the satellite receive equipment and processing. If a SARP Throughput anomaly is detected from a single satellite for all LUTs, the LUT operator should report this to the MCC responsible for coordination with the satellite operator. 3.1.1.9 PDS Data Recovery Rate The PDS Data Recovery Rate is the percentage of expected data from the Processed Data Stream (PDS) signal from the satellite SARP processors that is actually recovered during a LEOSAR satellite pass. It is maintained separately for each combination of LEOSAR satellite and LEOLUT ground station. Indicator: When the PDS Data Recovery Rate increases, the LUT is better able to reliably receive and process the beacon signals through that channel, and to generate the incident alert data required by the system. Rationale: This performance parameter ensures that each LUT monitors the data received from the on-board SARP instruments on each LEOSAR satellite, and reports whenever it does not receive the expected data. Definitions: #EXP = Number of messages expected in the PDS from the SARP instrument on a given LEOSAR satellite pass. (This is based on the known position of the LEOLUT and the known satellite orbital data and SARP downlink signal characteristics, and computed for the time while the satellite is more than 5º elevation above the local horizon.) #RCV = Number of messages received from the SARP on the actual satellite pass The PDS Data Recovery Rate is then the percentage of PDS messages actually received by the LEOLUT, over the satellite pass: DRR = 100 * #RCV / #EXP Metric(s): The PDS Data Recovery Rate is expressed as a percentage of the total number of PDS messages expected to be received by the LEOLUT over the satellite pass.

3-16

Data Collection Process: For every pass of a LEOSAR satellite with an operational SARP instrument that is tracked by a LEOLUT, the LUT should compute the duration of the time that the satellite will be above 5º elevation, and from that should calculate the number of PDS beacon messages that it expects to receive during the pass. At the pass, the LUT should count the number of PDS messages actually received, and it should compute and verify the PDS Data Recovery Rate. Data Verification Process: The PDS Data Recovery Rate should be computed by each LEOLUT, using the data it receives from the LEOSAR satellites. This data is not normally verified by the Operator. Relevant Documents: C/S T.002, C/S T.003. Action: If a PDS Data Recovery Rate anomaly is detected from a single LUT for all satellites, the LUT operator should review the satellite receive equipment and processing. If a PDS Data Recovery Rate anomaly is detected from a single satellite for all LUTs, the LUT operator should report this to the MCC responsible for coordination with the satellite operator. 3.1.1.10 Number of Single Point LEOSAR Alerts The Number of Single-Point Alerts is measured over a one-day period and is maintained separately for each combination of LEOSAR satellite and LEOLUT ground station. Indicator: When the Number of Single-Point Alerts detected by a LEOLUT decreases, it demonstrates that the LUT is processing the beacon messages better, and the capability of the system to cope with the actual volume of active beacons is improving. Rationale: This performance parameter ensures that each LUT monitors the data received through the LEOSAR satellites and reports how frequently it receives a Single-Point Alert. This is significant, since a Single-Point Alert does not provide enough data to enable the LUT to compute a location estimate. Definitions: #SPA = Number of Single-Point Alerts detected by the LEOLUT on each satellite pass.

3-17

#SPD = Number of Single-Point Alerts detected by the LEOLUT in one day. The baseline criterion for a Number of Single-Point Alerts is 50 % above the measured daily average: BSPD = 1.5 * ( Average of #SPD over a week or more of normal operation ) Metric(s): The Number of Single-Point Alerts is measured as an actual count of Single-Point Alerts per day. Reporting Criterion: If (#SPD > BSPD), then an anomaly should be reported by the MCC. Data Collection Process: Every time a LUT processes data from a pass of a LEOSAR satellite, it should report the Number of Single-Point Alerts detected to the host MCC. Data Verification Process: The Number of Single-Point Alerts should be accumulated by the MCC for each combination of LEOSAR satellite and LEOLUT, using the data received from the LEOLUT. This data is not normally verified by the Operator. Relevant Documents: C/S A.005, C/S T.002. Action: If a Number of Single-Point Alerts anomaly is detected by all LUTs and all satellites that are monitoring a selected geographical region, the LUT operator should determine whether there may actually be a large number of beacons activated and generating single- point alerts within the region. If a Number of Single-Point Alerts anomaly is detected from a single LUT for all satellites, the LUT operator should review the satellite receive equipment and processing. If a Number of Single-Point Alerts anomaly is detected from a single satellite for all LUTs, the LUT operator should report this to the MCC responsible for coordination with the satellite operator. 3.1.1.11 SARP Bit Error Rate The SARP Bit Error Rate, based on nominal solutions for known beacons. It is maintained separately for each combination of LEOSAR satellite and LEOLUT ground station.

3-18

Indicator: When the SARP Bit Error Rate decreases, the LUT is demonstrating an improved capability to receive the beacon signals through the SARP data channel. Rationale: This performance parameter ensures that each LUT monitors the data received from the LEOSAR satellites and reports the bit error rate of the data received through the SARP data channel. Definitions: A reference beacon is one of the Orbitography or Reference beacons operated by the Cospas-Sarsat participants. A nominal solution is a solution that is computed from measurements of more than three beacon transmissions, with the Time of Closest Approach spanned by the data and with the Cross-Track Angle between 1° and 20°. #BITS = Number of data bits in the first protected data field of the beacon message, including both the data bits and the BCH code bits #ERR = Number of correctable bit errors reported by the BCH code processing of those messages The Bit Error rate is then: BERR = #ERR / #BITS The baseline Bit Error Rate is 30% above the measured average: BBERR = 1.3 * (Average bit error rate over one week of normal operation) Metric(s): The Bit Error Rate is measured as the fraction of the total number of bits analysed. Reporting Criterion: If the BERR exceeds the baseline (as defined above), then a Bit Error Rate anomaly should be reported by the MCC. Data Collection Process: The LEOLUT should compute the SARP Bit Error Rate for every message that is received through the SARP data channel and that is used to generate a nominal solution for any of the known reference beacons and should report it to the host MCC at the end of each satellite pass. The MCC should maintain the SARP Bit Error Rate statistics for each combination of LEOSAR satellite and LEOLUT. If the SARP Bit Error Rate for any satellite pass exceeds the baseline value, then an anomaly should be reported to the Nodal MCC.

3-19

Data Verification Process: The SARP Bit Error Rate data should be accumulated by the MCC for each combination of LEOSAR satellite and LEOLUT, using the data received from the LEOLUT. This data is not normally verified by the MCC Operator. Relevant Documents: C/S A.005, C/S T.002. Action: If a Bit Error Rate anomaly is detected from a single LUT for all satellites, the LUT operator should review the satellite receive equipment and processing. If a Bit Error Rate anomaly is detected from a single satellite for all LUTs, the LUT operator should report this to the MCC responsible for coordination with the satellite operator. 3.1.1.12 LEOSAR SARR Bit Error Rate The SARR Bit Error Rate is based on nominal solutions for known beacons. It is maintained separately for each combination of LEOSAR satellite and LEOLUT ground station. Indicator: When the SARR Bit Error Rate decreases, the LUT is demonstrating an improved capability to receive the beacon signals through the SARR data channel. Rationale: This performance parameter ensures that each LUT monitors the data received from the LEOSAR satellites and reports the bit error rate of the data received through the SARR channel. Definitions: A reference beacon is one of the Orbitography or Reference beacons operated by the Cospas-Sarsat participants. A nominal solution is a solution that is computed from measurements of more than three beacon transmissions, with the Time of Closest Approach spanned by the data and with the Cross-Track Angle between 1° and 20°. #BITS = Number of data bits in the first protected data field of the beacon message, including both the data bits and the BCH code bits #ERR = Number of correctable bit errors reported by the BCH code processing of those messages

3-20

The Bit Error rate is then: BERR = #ERR / #BITS The baseline Bit Error Rate is 30% above the measured average: BBERR = 1.3 * (Average bit error rate over one week of normal operation) Metric(s): The Bit Error Rate is measured as the fraction of the total number of bits analysed. Reporting Criterion: If the BERR exceeds the baseline (as defined above), then a Bit Error Rate anomaly should be reported by the MCC. Data Collection Process: The LEOLUT should compute the SARR Bit Error Rate for every message that is received through the SARR data channel and that is used to generate a nominal solution for any of the known reference beacons and should report it to the host MCC at the end of each satellite pass. The MCC should maintain the SARR Bit Error Rate statistics for each combination of LEOSAR satellite and LEOLUT. If the SARR Bit Error Rate for any satellite pass exceeds the baseline value, then an anomaly should be reported to the Nodal MCC. Data Verification Process: The SARR Bit Error Rate data should be accumulated by the MCC for each combination of LEOSAR satellite and LEOLUT, using the data received from the LEOLUT. This data is not normally verified by the MCC Operator. Relevant Documents: C/S A.005, C/S T.002. Action: If a Bit Error Rate anomaly is detected from a single LUT for all satellites, the LUT operator should review the satellite receive equipment and processing. If a Bit Error Rate anomaly is detected from a single satellite for all LUTs, the LUT operator should report this to the MCC responsible for coordination with the satellite operator. 3.1.1.13 LEOSAR Pass Scheduling Accuracy The Pass Scheduling Accuracy is maintained separately for each combination of LEOSAR satellite and LEOLUT ground station.

3-21

Indicator: The lower the gap that the Pass Scheduling Accuracy Quality Indicator reports show between the predicted time of Acquisition of Signal (AOS) or Loss of Signal (LOS) of a LEOSAR satellite pass and the actual time of the event, then the better the LUT satellite reception equipment is working. Alternately, it may indicate that the LUT has better orbit ephemeris data for the satellites. Note that the LUT may not predict the times of AOS or LOS at the horizon, so it is not an indicator of a problem if the actual reception begins before the predicted time of AOS, or if it continues beyond the predicted time of LOS. Rationale: This performance parameter ensures that each LUT is monitored to determine when the LUT does not track a LEOSAR satellite pass as scheduled. Definitions: A scheduled pass is a LEOSAR satellite pass over the LEOLUT that was included in the pass tracking schedule of that LUT. TAOSP = Predicted time of Acquisition of Signal of the satellite over the LUT TLOSP = Predicted time of Loss of Signal of the satellite over the LUT TAOSA = Actual time of Acquisition of Signal of the satellite over the LUT TLOSA = Actual time of Loss of Signal of the satellite over the LUT TAOSOFF = TAOSA - TAOSP TLOSOFF = TLOSA - TLOSP Metric(s): The Pass Scheduling Accuracy is measured in seconds. Reporting Criterion: The criterion for an anomaly is two seconds; if TAOSOFF is greater than two seconds or if TLOSOFF is less than minus two seconds, then a Pass Scheduling Accuracy anomaly should be reported by the MCC. Data Collection Process: On each scheduled LEOSAR satellite pass, the LEOLUT should note when the signal is first received from the LEOSAR satellite and when the signal is last received from the satellite and should compare these times with the predicted times of AOS and LOS. If the time offsets do not meet the specified criteria, then the LEOLUT should report a Pass Scheduling Accuracy anomaly to the host MCC.

3-22

Data Verification Process: The Pass Scheduling Accuracy should be checked by each LEOLUT on every scheduled LEOSAR satellite pass. Relevant Documents: C/S A.005, C/S T.002. Action: If a Pass Scheduling Accuracy anomaly is detected from all LUTs for all satellites, the MCC operator should review the satellite pass schedule processing. If a Pass Scheduling Accuracy anomaly is detected from a single LUT for all satellites, the LUT operator should review the satellite receive equipment and processing. If a Pass Scheduling Accuracy anomaly is detected from a single satellite for all LUTs, the LUT operator should review the satellite orbital element and pass scheduling data for that satellite. 3.1.2 GEOSAR System Performance Parameters The GEOSAR performance parameters are organized into two tiers. Tier one performance parameters are those parameters that every Ground Segment Operator with a GEOLUT should monitor because of their direct relationship to alert data accuracy, timeliness and reliability. Tier one performance parameters include: • GEOSAR System Timing, • GEOSAR Rate of Reception of Beacon Messages, • GEOSAR Frequency Stability of Beacon Transmissions. Tier two performance parameters are those parameters that should be checked by every Ground Segment Operator who operates a GEOLUT and has the necessary tools to perform this monitoring. Tier two performance parameters include: • Carrier to Noise Ratio, • GEOSAR Bit Error Rate. The following sections provide a detailed description of these performance parameters. In addition, Annex C provides a summary of these performance parameters, and can be used by ground segment operators as a quick reference for the operational self-monitoring of the GEOSAR system.

3-23

3.1.2.1 GEOSAR System Timing The GEOSAR System Timing is measured from the time of the first message received for this integration of the beacon signal until the time when the incident alert is sent to an RCC or SPOC. Indicator: A reduced time to transmit the incident alert data generated by a GEOLUT to the appropriate RCC or SPOC indicates a greater system ability to maintain the level of service required of the system. Rationale: This Performance Parameter ensures that the GEOSAR System Timing information is routinely verified and reviewed. Definitions: The GEOSAR System Timing measures the time from the first reception of a beacon message from a GEOSAR satellite to the time when a National MCC sends the resulting incident alert message to the appropriate RCC or SPOC. TDET= The time when the first message of the integration that decoded the beacon message was received at the GEOLUT from the GEOSAR satellite, as reported in the incident alert message TMTX = The time when the responsible MCC transmits the incident alert message to the selected destination The GEOSAR System Timing is then: GT = (TMTX – TDET) Metric(s): The GEOSAR System Timing is expressed in seconds. Reporting Criterion: If the GEOSAR System Timing is more than thirty minutes (1,800 seconds) for any incident alert, then a Quality Management anomaly report is generated. Data Collection Process: For each GEOSAR alert message transmitted by an MCC to an RCC or SPOC, the MCC determines the GEOSAR System Timing associated with that alert.

3-24

Data Verification Process: The GEOSAR System Timing is computed automatically by each MCC, using the data available to it in the SIT message. This data is not normally verified by the Operator. Relevant Documents: C/S A.003, C/S A.005, C/S T.009. Action: If a GEOSAR System Timing anomaly is reported, MCC personnel should check on the LUT and MCC processing times associated with the alert. If there is no problem associated with the actual processing time, then MCC personnel should check on the time required for communication of the incident alert data at various stages in the processing of the alert. Comments: The GEOSAR System Timing is an assessment of the entire GEOSAR system. It is not an assessment of the performance of the GEOSAR satellite, the GEOLUT, the MCC, or the individual communications links that comprise the system. 3.1.2.2 GEOSAR Rate of Reception of Beacon Messages The GEOSAR Rate of Reception of Beacon Messages is a measure of the ability of the GEOSAR system to detect and extract messages from known reference beacons and from distress beacons. It is maintained for selected beacons with the operational combination of satellite and LUT ground station. The beacons that are used for the monitoring of the Rate of Reception of Beacon Messages must be beacons that remain active for a significant length of time. System reference beacons are ideal for this purpose. However, any operational beacon may be used, as long as it has continued to be active for a period of at least eight hours. In order to ensure beacon stability, the data should not be used for any beacon during the first one hour after activation. Indicator: If the Rate of Reception of Beacon Messages at the LUT increases, this indicates that the system is better able to receive and decode the beacon messages in the signal. Rationale: This performance parameter provides for the monitoring of the beacon messages transmitted through the satellite and ensures that the quality of the satellite signal will be monitored regularly. It also provides data to assist with the detection of malfunctioning beacons and of interfering signals, in both the uplink and the downlink frequency bands.

3-25

Definitions: The Rate of Reception of Beacon Messages is measured by taking the count of the messages sent by the GEOLUT to the MCC as a percentage of the total number of messages transmitted by the beacon over the measurement period (based on the known repeat rate of the beacon); it is assessed separately for each selected beacon with the operational combination of satellite and LUT. This measurement is made over each four- hour period. Any beacon that remains active for a period of eight hours or more may be selected for the measurement of this performance indicator. A reference beacon is one of the Orbitography or Reference beacons operated by the Cospas-Sarsat participants, as listed in C/S A.001. The period from one message transmission to the next is listed, for each reference beacon, in C/S A.001. For any other beacon, the period between transmissions is specified in C/S T.001 as 50 seconds. The monitoring period normally lasts four hours. DUR = Duration of the monitoring period (in seconds) PER = The period between transmissions of the selected beacon (in seconds) The number of messages expected during the monitoring period is an integer: #EXP = INT (1 + DUR / PER) The number of messages actually received at the GEOLUT is: #RCV = The actual received message count for the monitoring period The Rate of Reception of Beacon Messages is then: RRATE = 100 * #RCV / #EXP Metric(s): The Rate of Reception of Beacon Messages is measured as a percentage of the total number of messages transmitted by the beacon during the monitoring period. Reporting Criterion: If the Rate of Reception of Beacon Messages is less than 75% or greater than 105%, then a System anomaly notification message should be generated. Data Collection Process: The GEOLUT extracts all beacon messages from the downlink signal at all times while it is operational. This Performance Indicator is computed by monitoring the messages received at the MCC from the selected beacons during the normal operation of the system.

3-26

Data Verification Process: The Rate of Reception of Beacon Messages data should be processed independently by the MCC for each LUT; it is not verified by the Operator. Relevant Documents: C/S A.005, C/S T.001, C/S T.006, C/S T.009, C/S T.022. Action: If the Rate of Reception of Beacon Messages is below the established baseline for a significant number of beacons, the LUT operator should review the satellite receive equipment and processing; if no problem is found, MCC personnel should report the anomaly to the MCC responsible for coordination with the reference beacon operator and with the satellite instrument provider, to assist in determining if there is a problem with those components of the system. If the Rate of Reception of Beacon Messages is out of range for any operational beacon, the MCC personnel should notify the beacon owner, to determine if there has been a beacon malfunction. A beacon malfunction may result in excessive drain on the beacon’s battery, and a failure during a subsequent distress incident. 3.1.2.3 GEOSAR Frequency Stability of Beacon Transmissions The GEOSAR Frequency Stability of Reference Beacon Transmissions is maintained for selected beacons with the operational combination of satellite and LUT ground station. Indicator: When the GEOSAR Frequency Stability of Beacon Transmissions is improved, that indicates that the downlink signal is being received better at the LUT, and the LUT will be better able to extract beacon messages and measure the time and frequency of each message. Rationale: This performance parameter provides for the monitoring of the GEOSAR satellite uplink and downlink signals and ensures that the quality of the GEOSAR data will be monitored regularly. Definitions: Any beacon that remains active for a period of eight hours or more may be selected for the measurement of this performance indicator. A reference beacon is one of the Orbitography or Reference beacons operated by the Cospas-Sarsat Participants, as listed in C/S A.001. For each selected beacon, the measurement is made over each four-hour period.

3-27

FRM = Measured frequency of each transmission received from the beacon FRAV = Average of all measured frequencies over the monitoring period The GEOSAR Frequency Stability of Beacon Transmissions is then: MAXFD = Maximum difference of any measured frequency from the average Metric(s): The GEOSAR Frequency Stability of Beacon Transmissions is measured in Hertz. Reporting Criterion: If the GEOSAR Frequency Stability of Beacon Transmissions over any monitoring period is greater than 2.0 Hz for a reference beacon or greater than 5.0 Hz for an operational distress beacon, then a System anomaly notification should be generated. Data Collection Process: The GEOLUT extracts all beacon messages from the downlink signal at all times while it is operational. This Performance Indicator is computed by monitoring the messages from the selected beacons during normal operation of the system. The GEOSAR Frequency Stability of Beacon Transmissions is computed by the MCC after every four hours of GEOLUT reception from the beacon. If the value exceeds the criterion, then an anomaly should be reported. Data Verification Process: The GEOSAR Frequency Stability of Beacon Transmissions data should be processed independently by the MCC for each LUT; it is not verified by the MCC Personnel. Relevant Documents: C/S A.005, C/S T.006, C/S T.009. Action: If a GEOSAR Frequency Stability of Beacon Transmissions anomaly is detected, the LUT operator should review the satellite receive equipment and processing; if no problem is found, MCC personnel should follow up on the beacon involved. For a reference beacon, the MCC personnel should report the anomaly to the MCC responsible for coordination with the reference beacon operator or with the satellite operator, to assist in determining if there is a problem with those components of the system. For an operational beacon, the MCC personnel should report the anomaly to the owner of the beacon, since an unstable transmit frequency may result in reduced accuracy of the Doppler location processing during a distress incident.

3-28

Comments: The criterion of 2.0 Hz is based on the GEOLUT Commissioning Standard. This is based on the assumption that all reference beacons will be sufficiently stable to achieve this criterion. For operational beacons, which have a lower specification for frequency stability, a criterion of 5.0 Hz is proposed. 3.1.2.4 GEOSAR Carrier to Noise Ratio The GEOSAR Carrier to Noise Ratio (CNR) is based on integrated beacon messages for selected Orbitography or Reference beacons. It is maintained for each identified reference beacon, for the operational combination of satellite and LUT ground station. Indicator: When the GEOSAR Carrier to Noise Ratio increases, the LUT is demonstrating an improved capability to receive the beacon signals through the GEOSAR data channel. If the CNR decreases, it is an indication that the quality of the signal has degraded, or that there is more noise in the environment. Rationale: This performance parameter ensures that each GEOLUT operator monitors the data received from the GEOSAR satellites and reports the Carrier to Noise Ratio of the data received through the downlink channel. Definitions: A reference beacon is one of the Orbitography or Reference beacons operated by the Cospas-Sarsat participants. One or more such beacons should be selected for this monitoring at each GEOLUT. A successful integration is a message that has satisfied the requirements for the integration of a valid beacon message, as defined in document C/S T.009. CNRB = the ratio of the strength of the downlink carrier signal to the ambient noise level in each beacon message received by the GEOLUT and sent to the MCC #MSG = the number of beacon messages received from the selected beacon by the GEOLUT during the monitoring period (The actual algorithm for computing the CNR is to be determined by the GEOLUT manufacturer. As long as a consistent algorithm is used, the details of how it is computed need not defined in this specification.) The average Carrier to Noise Ratio performance indicator is then: ACNRB = SUM(CNRB) / #MSG

3-29

Since the C/N0 is in decibels, a logarithmic value, the method for taking the average entails taking the inverse log of each value, computing the average of the resulting values, and computing the log of the resulting average. The baseline Carrier to Noise Ratio is 20% below the measured average over a week of normal operation: BCNR = 0.8 * (Average CNRB over one week of normal operation) To establish the baseline, administrations should consult with other GEOLUT operators to ensure that the baseline is consistent with the performance of other GEOLUTs under similar circumstances (for example, the same models of beacon, satellite, and GEOLUT). Metric(s): The Carrier to Noise Ratio is measured, in dB-Hz, as the average of the ratio of the carrier strength to the ambient noise level in the downlink signal received by the GEOLUT during each monitoring period. Reporting Criterion: If the ACNRB is less than the baseline value (as defined above), then a Carrier to Noise Ratio anomaly should be reported by the MCC. Data Collection Process: The GEOLUT should compute the GEOSAR Carrier to Noise Ratio for every valid message that is received through a GEOSAR satellite from any selected beacon and should report the average CNR for each selected beacon to the host MCC. The MCC should maintain the GEOSAR Carrier to Noise Ratio statistics for each selected beacon for each combination of GEOSAR satellite and GEOLUT. If the GEOSAR Carrier to Noise Ratio for any combination is less than the baseline value for that combination, then an anomaly should be reported. Data Verification Process: The GEOSAR Carrier to Noise Ratio data should be accumulated by the MCC for each selected beacon for each combination of GEOSAR satellite and GEOLUT, using the data received from the GEOLUT. This data is not normally verified by the MCC Operator. Relevant Documents: C/S A.005, C/S A.006, C/S T.009. Action: If a Carrier to Noise Ratio anomaly is detected, the LUT operator should review the satellite receive equipment and processing. The ambient noise environment should also be reviewed. Data should be analyzed for different beacons for the same satellite and for

3-30

different satellites for the same beacon, as possible, in order to determine if the problem is due to the satellite or the beacon. If the Carrier to Noise Ratio is consistently lower for a particular satellite, then the anomaly should be reported to the MCC responsible for coordination with the satellite instrument provider, so that the satellite performance can be reviewed, to determine if there is any problem with the satellite. If a reference beacon shows a consistent anomaly, notify the reference beacon operator via its associated MCC. Comments: The GEOSAR Carrier to Noise Ratio performance indicator, as noted above, is to be determined by the manufacturer of the GEOLUT equipment used by each Cospas-Sarsat Ground Segment Provider. The details of the computation of the Carrier to Noise Ratio are not specified here; as long as a consistent algorithm is used in each GEOLUT, the comparison of the data with the baseline value should bring any anomaly to the attention of the MCC personnel. 3.1.2.5 GEOSAR Bit Error Rate The GEOSAR Bit Error Rate is based on integrated beacon messages for selected beacons. It is maintained for each identified reference beacon, for the operational combination of satellite and LUT ground station. Indicator: When the GEOSAR Bit Error Rate decreases, the LUT is demonstrating an improved capability to receive the beacon signals through the GEOSAR data channel. Rationale: This performance parameter ensures that each LUT monitors the data received from the GEOSAR satellites and reports the bit error rate of the data received through the downlink channel. Definitions: A reference beacon is one of the Orbitography or Reference beacons operated by the Cospas-Sarsat participants. A successful integration is a message that has satisfied the requirements for the integration of a valid beacon message, as defined in document C/S T.009. #BITS = Number of data bits in the first protected data field of the beacon message, including both the data bits and the BCH code bits #ERR = Number of correctable bit errors reported by the BCH code processing of those messages

3-31

The Bit Error rate for each message is then: BERGSAR = #ERR / #BITS The number of messages analysed over the four-hour monitoring period is #MSG. The average Bit Error Rate performance indicator is then: ABERGSAR = SUM(BERGSAR) / #MSG The baseline Bit Error Rate is 30% above the measured average: BBERR = 1.3 * (Average bit error rate over one week of normal operation) To establish the baseline, administrations should consult with other GEOLUT operators to ensure that the baseline is consistent with the performance of other GEOLUTs under similar circumstances (for example, the same models of beacon, satellite, and GEOLUT). Metric(s): The Bit Error Rate is measured as the fraction of the total number of bits analysed during each monitoring period. Reporting Criterion: If the ABERGSAR exceeds the baseline (as defined above), then a Bit Error Rate anomaly should be reported by the MCC. Data Collection Process: The GEOLUT should compute the GEOSAR Bit Error Rate for every valid message that is received through a GEOSAR satellite from any selected beacon and should report it to the host MCC. The MCC should maintain the GEOSAR Bit Error Rate statistics for each combination of GEOSAR satellite and GEOLUT. If the GEOSAR Bit Error Rate for any system exceeds the baseline value, then an anomaly should be reported. Data Verification Process: The GEOSAR Bit Error Rate data should be accumulated by the MCC for each combination of GEOSAR satellite and GEOLUT, using the data received from the GEOLUT. This data is not normally verified by the MCC Operator. Relevant Documents: C/S A.005, C/S T.006, C/S T.009, C/S T.022. Action: If a Bit Error Rate anomaly is detected, the LUT operator should review the satellite receive equipment and processing. The ambient noise environment should also be

3-32

reviewed. Data should be analyzed for different beacons for the same satellite and for different satellites for the same beacon, as possible, in order to determine if the problem is due to the satellite or the beacon. If the Bit Error Rate is consistently higher for a particular satellite, then the anomaly should be reported to the MCC responsible for coordination with the satellite instrument provider, so that the satellite performance can be reviewed, to determine if there is any problem with the satellite. If a reference beacon shows a consistently anomaly, notify the reference beacon operator via its associated MCC. Comments: The GEOSAR Bit Error Rate performance indicator, as defined above, is not a true bit error rate, but it is a reasonable estimate with the available data. This Bit Error Rate performance indicator is measured at the operational elevation of the GEOSAR satellite, as seen from the GEOLUT. For a more complete assessment of the significance of the Bit Error Rate, it is necessary to consider the carrier to noise ratio of the signals from each beacon that is measured. The Bit Error Rate performance indicator is an assessment of the entire GEOSAR system; it is not an assessment of the performance of the individual beacons, the GEOSAR satellite, the GEOLUT, or the MCC. 3.1.3 MEOSAR System Performance Parameters 3.1.3.1 MEOLUT Location Accuracy for opportunity beacons The MEOLUT Location Accuracy for opportunity beacons is measured as the difference between the GNSS encoded position and the independent position. Indicator: A certain proportion of large location errors indicates that the MEOLUT location algorithms are not adapted to the operational beacons already deployed. Rationale: This parameter ensures that the locations produced by a MEOLUT are accurate enough, particularly in the case of real alerts. Definitions: For the given MEOLUT, collect all beacon messages from operational MEOSAR satellites for the operational beacons for the analysis time period. Among all located alerts keep only the ones with beacon messages: • that contain an encoded position (not default value), • that are complete,

3-33

• with one of the following protocols: Standard Location Protocol, National Location Protocol and RLS Location Protocol, • not in test location protocol, • containing a normal mode preamble, • for which the encoded position indicates a position within the Declared Coverage Area (as defined in document C/S T.019) of the MEOLUT. The beacons for which some of the messages are satisfying all those conditions are named the “retained located alerts”. Perform MEOLUT Location Accuracy analysis as follows: a) for each identified beacon, compute the reference position of the beacon by linearly interpolating the encoded position at the time stamp corresponding to the last burst TOA of the independent position; b) for each identified beacon, compute the distance between the independent location and the associated reference location computed at step (a); and c) compute daily for each MEOLUT in the DDR a MEOLUT accuracy ratio, using all independent location estimates for all retained located alerts that are within the DCA of the MEOLUT received during the last [one] day[s] (i.e., between [Day-1], 00:00 UTC and Day 0, 00:00 UTC). Metric(s): The accuracy ratio for the MEOLUT is defined as follows: RatioAccOpportunity = N Loc (E ≤ [30 km]) / N Loc, where: N Loc = total number of DOA locations obtained for the retained located alerts during the designated time period N Loc (E ≤ [30] km) = Subset of the NLoc DOA locations for which the distances to the reference positions are less than or equal to [30] km. Reporting Criterion: If the accuracy ratio is less than [95] %, then a System anomaly notification message should be generated. Data Collection Process: The MEOLUT extracts all located alerts at all times while it is operational, and it keeps only the ones corresponding to the “retained located alerts”.

3-34

Data Verification Process: The MEOLUT Location Accuracy data for beacons of opportunity should be checked by each MEOLUT whenever it produces new independent MEOSAR location data. This data is not normally verified by the Operator. Relevant Documents: C/S T.019. Action: Each anomaly in the MEOLUT Location Accuracy data for beacons of opportunity should be investigated, on a case by case basis. 3.1.4 MCC Self-Monitoring The document C/S A.005 “Cospas-Sarsat MCC Performance Specification and Design Guidelines”, requires an MCC to monitor the following System elements in its national ground segment: LUTs, LUT/MCC communication networks, the MCC itself and connections to external communication networks. a) Baseline requirements In order to achieve this objective, the MCC shall be provided with the necessary information, including that described in sections 3.1.1 and 3.1.2 concerning the LEOLUT self-monitoring and the GEOLUT self-monitoring, and in section 3.1.3.1 which concerns LUT/MCC and external communication networks. Ground Segment Providers are encouraged to make arrangements with national RCCs and SPOCs in their service area to assess periodically the effectiveness of Cospas-Sarsat alert data distribution. This can be achieved by cooperation between MCCs and SPOCs or RCCs to ensure that sufficient feed-back information is provided by SAR services. Anomalies in the MCC operations should be detected by the MCC itself whenever possible, in particular to avoid distributing unreliable or corrupted data. If such detection fails, the other MCCs with which it communicates in accordance with the “Cospas-Sarsat Data Distribution Plan” (C/S A.001), should endeavour to detect these anomalies and should notify the observed anomalies to the transmitting MCC. b) Monitoring of MCC Operations An MCC’s compliance with the above requirements can be verified by: i. analysing an associated LUT’s performance parameters described in sections 3.1.1 and 3.1.2, or receiving the appropriate status information and warnings generated at the LUT level; and

3-35

ii. monitoring of its communication links with its LUTs, its national RCCs and associated SPOCs, and with other MCCs as described in section 3.1.3.1. 3.1.4.1 LUT/MCC Communication Links Monitoring a) Link Failures The MCC should monitor communication links between the MCC and its associated LUTs, which should achieve 100% availability. MCCs which do not have automatic detection of link failure should be kept aware of each satellite-pass processed by the LEOLUT and monitor the time delay between the forecasted loss of signal at the LEOLUT and the reception of alert data from that pass. If no data is received at LOS + 30 minutes, the MCC should verify the availability of the communication link. In addition, MCCs should monitor the following quality indicator to detect any anomalies in the LUT/MCC links: LUT/MCC data transfer time. b) Integrity of Data The MCC shall verify the integrity of alert data it receives, which includes monitoring: • the number of received alerts with reference to the number of alerts sent by the LUT and/or the sequence of messages, and • the percentage of messages received from the LUTs with format errors and/or out of range data. Any significant discrepancy of these parameters should be detected, and the anomaly corrected, or appropriate actions should be undertaken at MCC level to eliminate the corrupted data from the alert data distributed to SAR services. 3.1.4.2 MCC to MCC Communication Links a) Link Failures Communication link failures observed by an MCC shall be notified to the corresponding MCC with a view to: • correcting the anomaly, or • switching to available backup links. b) Integrity of Data Any detected loss of messages exchanged between MCCs should be notified to the transmitting MCC and investigated. However, such loss may remain unnoticed, depending on the communication link protocol, and the assessment of communication link performance may require periodic testing.

3-36

All MCCs should monitor the percentage of messages received with format errors or out- of-range data for each communication link and report to the originating MCC, as appropriate. 3.1.4.3 MCC to RCC/SPOC Communication Links a) Link Failures Communication link failures observed by an MCC shall be notified to the corresponding RCC/SPOC and alternative alert data distribution procedures should be used, as appropriate. b) MCC/SPOC Communication Test The purpose of the following test is to identify to IMO and ICAO SPOCs that are non- responsive to Cospas-Sarsat distress alert messages. Each MCC shall perform a monthly communication test with each SPOC in its service area. The test shall include a transmission of a test message from the MCC to the SPOC and an acknowledgement of the message by the SPOC/RCC operator (i.e., an automatic acknowledgement is not acceptable) to the MCC. However, MCC-SPOC communication links that have been successfully used operationally at least once (with the messages acknowledged by a SPOC/RCC operator) during the month may be reported as already tested. A successful communication test requires that the manual acknowledgement from the SPOC/RCC be received within 30 minutes and the test message should clearly reflect this requirement. The test should be undertaken at various times throughout the day. c) Reporting of MCC/SPOC Communication Tests Each MCC should report results of the MCC/SPOC communication test to the Cospas- Sarsat Secretariat, who will provide a summary report to IMO COMSAR as part of the annual Cospas-Sarsat status report. MCCs should report on a monthly basis (after each communication test) using the format provided at Annex H to this document. All reports should be focused on non- functionality, but a report should be submitted even if all communication tests are successful. 3.2 Space Segment Self-Monitoring The general health of the spacecraft is routinely monitored by the spacecraft provider, using telemetry data, to detect out-of-specification conditions. Information on anomalies which could significantly degrade System performance or limit the operation of a SAR payload will be provided to all Ground Segment operators via the MCC network and to the Cospas-Sarsat Secretariat, in accordance with the procedures defined in the

3-37

C/S A.001. When notified of a change in status of any of the payloads, the Secretariat will update the Space Segment Status on the C/S website and in document C/S A.001. Any Ground Segment operator who detects anomalies in the performance of the Space Segment during routine System monitoring activities and has confirmed that such anomalies are not due to its Ground Segment equipment, shall inform the relevant Space Segment Provider. Analysis of Space Segment anomalies will be coordinated among the relevant Space Segment Providers and possible corrective action (e.g., switch to backup payload) will be taken, as appropriate. Information on anomalies which could significantly degrade System performance, that are detected during tests and confirmed by the relevant Space Segment Provider, will be provided to all Ground Segment operators via the MCC network, in accordance with the procedures defined in C/S A.001. 3.3 Monitoring of System Performance Related to SARP and SARR-MSG/MTG Instruments This test activity allows the monitoring, on an annual basis, of the performance of Cospas-Sarsat satellite instruments commissioned by CNES. The monitoring is performed either directly with operational data, or with test data using specific test scripts generated by the Toulouse beacon simulator and replicating appropriate distress beacon messages. The monitoring concerns the SARP instruments onboard operational Sarsat satellites, and the SARR instruments onboard operational MSG/MTG satellites. It consists of repeating a significant part of the initial commissioning tests.

3-38

3.3.1 GEOSAR SARR/MSG Monitoring Data used for evaluating the system performance of the METEOSAT Second Generation (MSG) GEOSAR satellites are retrieved from the designated GEOLUT for each MSG satellite, as listed in the Table 3.1. 6Table 3.1: LUTs Designated to Monitor MSG Satellites Satellite GEOLUT MSG-1 Abu Dhabi MSG-3 Ankara MSG-4 Toulouse Table 3.2 provides a synthesis of system performance assessed for the SARR/MSG instruments. 7Table 3.2: Synthesis of SARR/MSG System Performance Parameter MSG-x MSG-y Throughput at 37 dBm Processing Threshold (37 dBm) Processing Performance (32 dBm) • Throughput measured at 37 dBm: probability to retrieve a valid message for each single transmitted message, i.e., the ratio of the number of received valid messages over the number of transmitted messages. The throughput is calculated with the data available from test T-1 (see document C/S R.011). • Processing Threshold: the value of beacon power for which the GEOLUT is able to provide a valid message for each beacon event 99% of the time (see test T-1 in document C/S R.011). The specification is 37 dBm. • Processing Performance: the value of beacon power for which the GEOLUT is able to provide a valid message for each beacon event in less than 5 minutes 95 % of the time (see test T-2 in document C/S R.011). The specification is 32 dBm. 3.3.2 LEOSAR SARP Monitoring Data used for evaluating LEOSAR SARP system performance are retrieved from the Toulouse LEOLUTs. Tables 3.3 and 3.4 provide a synthesis of the system performance assessed for the SARP instruments.

3-39

The assessment of the “Threshold for a 75% access probability” parameter is optional. Tests with a variable EIRP will not be performed in case of schedule difficulties when implementing the yearly monitoring. When available, the location performance derived from both SARP and SARR instruments are also evaluated and provided. 8Table 3.3: Synthesis of SARP System Performance (Frequency Parameters) Satellite USO Mean Frequency USO Frequency Drift/Day Frequency Bandwidth Sxx ….. Syy • USO Mean Frequency: mean frequency of the onboard Ultra-Stable Oscillator, calculated as the average value of the USO frequency measurements provided by the LEOLUT over a 2-month period. The instrument specification is 10 MHz +/- 5 Hz for SARP-3 and 5,203,205 Hz +/-2.5 Hz for SARP-2. • USO Frequency Drift/Day: this parameter is calculated also using the USO frequency measurements provided by the LEOLUT over a 2-month period; it is the standard deviation of the observed drifts, reduced to a one-day duration. The USO frequency Drift/Day thus calculated cannot be directly compared to the instrument specification (Drift/Day less than 1 MHz for SARP-3 and 0.5 MHz for SARP-2) due to ground segment contribution but is expected to be lower than 15 MHz. • Frequency Bandwidth: this parameter is derived from the histogram of frequencies measured for all the beacons (operational + test beacons) over a 3-day period. The specification is 80 kHz [406.010 – 406.090 MHz] for SARP-3 and 40 kHz [406.010 – 406.050 MHz] (Mode 2) for SARP-2. 9Table 3.4: Synthesis of SARP System Performance Criterion Sxx …. …. …. Syy Dating accuracy (10 ms) Instrument sensitivity (- 131/- 134 dBm) Dynamic range (23/29 dB) Probability to provide a valid solution (95 %) Access probability (75%) Probability to retrieve a complete message

3-40

Criterion Sxx …. …. …. Syy Probability of Doppler processing Probability to provide a location better than 5 km - SARP (95%) SARP/SARR (95%) Accuracy of Doppler location - SARP SARP/SARR Ellipse error mean radius - SARP SARP/SARR Threshold for a 75 % access probability (optional test) • Dating accuracy: this parameter is calculated using the dates of the Toulouse orbitography beacon bursts provided by the LEOLUT. More precisely, it is the standard deviation of the dating error observed for all the bursts of the Toulouse beacon over a 1-week period. The system specification is 10 ms (see document C/S T.003). • Instrument sensitivity: this parameter is derived from the histogram of the levels (in dBm) received on-board the instrument for all beacons (operational + test beacons) over a 3- day period. The sensitivity is the lower level plotted on the histogram. The instrument specification is -131 dBm for SARP-2 and -134 dBm for SARP-3. • Dynamic range: this parameter is also derived from the histogram of the levels (in dBm) received on-board the instrument for all beacons (operational + test beacons) over a 3- day period. The dynamic range is the difference between the higher and the lower levels plotted on the histogram. The instrument specification is 23 dB for SARP-2 and 29 dB for SARP-3. • Probability to provide a valid solution: the specification is a probability better than 95% to provide a valid solution (15 Hex identification provided) for a beacon transmitting with a 37 dBm output power (with a whip antenna) and for satellites passes with elevation above 5°. The statistical analysis is done through beacon messages transmitted with the Toulouse beacon simulator over a 2-day period. • Access probability or throughput: this is the probability to retrieve a valid message for each single transmitted message in the same conditions as above. The specification is 75% at 37 dBm (see document C/S T.002). The expected value is higher than 90%. The statistical analysis is done through beacon messages transmitted with the Toulouse beacon simulator over a 2-day period. • Probability to retrieve a complete message: this is the probability to retrieve a complete message for each transmitted message in the same conditions as above. There are no specifications for this parameter. The statistical analysis is done through beacon messages transmitted with the Toulouse beacon simulator over a 2-day period.

3-41

• Probability of Doppler processing: this is the probability to retrieve at least 4 messages per pass, in the same conditions as above. The specification is 95% at 37 dBm (see document C/S T.002). The statistical analysis is done through beacon messages transmitted with the Toulouse beacon simulator over a 2-day period. • Probability to provide a Doppler location with an accuracy better than 5 km: the specification is a probability better than 95% to provide a Doppler location with an accuracy better than 5 km for a beacon transmitting with a 37 dBm output power (with a whip antenna) and for satellites passes with elevation above 5°. The statistical analysis is done through beacon messages transmitted with the Toulouse beacon simulator over a 2- day period. When available, the location performance derived from both SARP and SARR instruments is also provided. • Accuracy of Doppler location: average value of the error made when processing the location. The statistical analysis is done through beacon messages transmitted with the Toulouse beacon simulator over a 2-day period. When available, the location accuracy derived from both SARP and SARR instruments is also provided. • Ellipse error mean radius: the average value of the ellipse error radius parameter provided by the LEOLUT. The statistical analysis is done through beacon messages transmitted with the Toulouse beacon simulator over a 2-day period. When available, the ellipse error mean radius derived from both SARP and SARR instruments is also provided. • Threshold for a 75% access probability (optional parameter): the value of beacon power for which the LEOLUT is able to provide a valid message for each beacon event 75% of the time. The expected value is about 23 dBm. The statistical analysis is done through beacon messages transmitted with the Toulouse beacon simulator with variable emission powers over a 1-day period.

  • END OF SECTION 3 -

4-1

BEACON PERFORMANCE MONITORING 4.1 Description of Beacon Monitoring Beacon monitoring and reporting consists of two parts: a) monitoring of beacon performance and reporting anomalies to interested parties; and b) monitoring of non-distress beacon activations, or operational false alerts, and determining the cause of activation. Beacon anomalies include: a) non-activation of beacons in distress situations, or in circumstances where a beacon should have been automatically activated; b) anomalies related to actual beacon activation; and c) anomalies detected during mandatory or routine inspections of installations by responsible authorities. Administrations should monitor beacon anomalies and exchange information with other Administrations who have type-approved the same type of beacon (see document C/S S.007). This exchange of information should be done as soon as practical and contain data that is useful in determining if the anomaly is a local problem or a global concern. Operational false alerts may have a variety of origins and their elimination is of interest to all users. Distress alert statistics should identify the cause of operational false alerts. Each operational false alert should be categorised as being caused either by beacon mishandling, beacon malfunction, mounting failure, environmental conditions, maintenance activation, voluntary activation, or unknown circumstances. 4.2 Beacon Monitoring Requirements All Cospas-Sarsat Participants should monitor the operation of beacons to determine the number of beacon anomalies or operational false alerts such as listed below: All information should be recorded by Administrations and reported as provided for in Annex A to this document. 4.2.1 Anomalies A malfunctioning beacon is any operational beacon that does not conform to the specifications of document C/S T.001.

4-2

Some examples of anomalies that may indicate malfunctioning beacons are: • non-activation of beacon in distress situation or in circumstances where it should have been automatically activated, • non-detection or location of an active beacon, • a beacon that transmits more than ten consecutive bursts with an average period of 45 seconds or less, • a beacon that transmits more than 30 bursts with an inverted frame sync pattern in an 8- hour period, • other anomalies detected during manufacturers' testing or inspection performed by Administrations on equipment installed on board ships or aircraft. 4.2.2 Operational False Alerts In the following categories: a) Beacon mishandling: activations caused by the mishandling of the beacon by a person who did not intend to transmit a distress signal; b) Beacon malfunctions: activations caused by beacon (electronics including battery) malfunctions; c) Mounting failures: activations caused by mounting failures or release mechanism malfunctions; d) Environmental conditions: activations caused by extreme weather conditions where the beacon functioned properly; e) Maintenance activations: activations caused by a person who activates a beacon for testing during maintenance and intended to transmit a distress signal in a non- distress situation; f) Voluntary activations: activations caused by a person who intended to transmit a distress signal in a non-distress situation other than during maintenance; and g) Unknown: confirmed beacon activations where the cause could not be determined, or no feedback information was received from the SAR authorities. 4.2.3 Notification of Beacon Anomalies All Cospas-Sarsat Participants should work with appropriate national Authorities to reduce the number of beacon anomalies. In this purpose, one or more of the following individuals and/or organisations should be notified when a beacon anomaly is detected: a) Beacon Owner: The owner/user should be notified of the problem and the importance of having the beacon serviced, as well as the potential for the beacon not working correctly when required. The owner/user may be contacted using identification information embedded in the beacon (e.g., radio call sign, tail number,

4-3

MMSI, etc.), the registration information if the beacon is registered, or using the manufacturer to trace the owner. b) Beacon Manufacturer: The manufacturer of the beacon should be notified of the problem. The manufacturer can be traced through the information embedded in the beacon message (e.g., C/S Type Approval Number), or through the registration information. The manufacturer can then detect systemic problems and take preventive and/or corrective action as necessary. c) National Type Approval Authority: The national type-approval authority, or mandating authority, should be notified so that it may track beacon malfunctions and take appropriate action if required. d) Cospas-Sarsat: Cospas-Sarsat Participants should be notified in accordance with the format in Annex D so that they may make appropriate recommendations concerning the type approval of the affected beacon model(s). Since the determination of the cause of false alerts is totally dependent on the feed-back information received from national RCCs and SPOCs, national Administrations should encourage their RCCs and SPOCs to provide timely information which describes the cause and disposition of each beacon activation, when an alert is received from their associated MCC.

  • END OF SECTION 4 -

5-1

INTERFERENCE MONITORING 5.1 Effects of Interference on the System The 406 MHz band has been allocated by the International Telecommunication Union (ITU) for distress alerting using low power emergency position indicating radiobeacons: nevertheless, there are unauthorised signal sources in various areas of the world radiating signals in the 406.0 - 406.1 MHz band which interfere with the Cospas-Sarsat System. These sources are not 406 MHz beacons but operate either in the 406 MHz band or at some other frequency and produce spurious emissions in the 406 MHz band. Interferers degrade the performance of the on-board 406 MHz SAR processor (SARP) and reduce the probability of detecting real beacon messages. In the case of Sarsat satellites, interferers also degrade the signal relayed by the on-board 406 MHz repeaters (SARR) and mask actual beacon messages. A few strong interferers (i.e., > 5 Watts) located in an area about the size of a continent can virtually jam the satellites and prevent distress beacons in that area from being located. Unless immediate steps are taken to locate and remove these unauthorised interference transmissions, lives could be lost when strong interferers mask the 406 MHz distress signals. Conventional land-based interference monitoring methods are not suitable for an international satellite system providing global coverage. Fortunately, the Cospas-Sarsat satellite system itself can be used to detect and locate many of the interference sources world-wide, if the interference signals are monitored at suitably equipped earth receiving stations (i.e., LEOLUTs with 406 MHz interference monitoring capability). 5.2 Monitoring 406 MHz Interference with the LEOSAR System Sarsat satellites have 406 MHz repeaters for retransmitting emissions received from Earth in the band 406.0-406.1 MHz. As a result, the time/frequency pairs of interference emissions can be measured at LEOLUTs specially equipped to perform this processing. 406 MHz interferers generally transmit continuous signals for a long period of time as compared to the short, one-half second beacon bursts. These near continuous signals produce a Doppler curve which is used to compute the interferer location. Unlike the processing of distress beacon emissions, no identification code can be extracted from an interfering signal, since its modulation, if any, would not be in the correct format. Emissions from a single interference source must be identified by location. The coverage area for processing unauthorised emissions is limited to the reception area of the LEOLUT. Therefore, a network of interference monitoring LEOLUTs at selected locations is desirable in order to provide an interference monitoring capability over a larger area. Annex B shows the location and coverage area of LEOLUTs currently monitoring 406 MHz interference.

5-2

5.3 Suppression of 406 MHz Interference The following actions have been taken by the ITU or Cospas-Sarsat regarding 406 MHz interference: a) the ITU has set up a framework for protecting the 406 MHz band as described in Recommendation ITU-R SM.1051-4 “Priority of Identifying and Eliminating Harmful Interference in the Band 406.0 - 406.1 MHz”; b) the ITU has requested countries participating in Cospas-Sarsat to monitor the 406 MHz band for interference; c) the ITU has developed forms for the “Information report concerning interference” and the “Feedback report concerning the interference source”. These forms are shown in Annex B; d) the Cospas-Sarsat Council encourages countries/territories installing new LEOLUTs to incorporate an option in their LEOLUTs for monitoring 406 MHz interference and to utilise this capability routinely; e) the Cospas-Sarsat Council has approved LEOLUT specifications which include optional 406 MHz repeater processing for interference monitoring; f) the Cospas-Sarsat Council has requested the Secretariat to provide information on 406 MHz interference to user organizations, such as IMO and ICAO, including the list and locations of interference sources reported by Cospas-Sarsat Participants; and g) the Cospas-Sarsat Council has agreed a form for reporting persistent 406 MHz interferers. This form is shown in Annex B and includes the data required by (c) above. 5.4 Notification of 406 MHz Interference Ground Segment operators are encouraged to provide monthly interference reports on persistent interferers to the Cospas-Sarsat Secretariat using the reporting format as presented in Annex B at Table B.1, and to provide reports to the ITU in accordance with their national procedures and the ITU requirements. Ground Segment operators are encouraged to extend their reporting to the entire geographic area of visibility of their LEOLUTs, and not to limit themselves to their MCC service area. An interferer is persistent when it has been detected by 10% or more of the available Sarsat satellite passes at or above a 5-degree elevation angle (measured from the interference source) and when it has been observed by the reporting MCC no less than 10 times (10 distinct satellite passes) per month over the reporting period. Table B.1 in Annex B provides more details on reporting criteria. A persistent interferer case should remain open and should continue to be reported until there are no emissions for a period of 60 days. After that time, the case should be considered closed. When an interferer significantly degrades System performance, Ground Segment operators are also encouraged to inform the search and rescue authorities in the area where the interferer is located.

  • END OF SECTION 5 -

6-1

REPORTING ON SYSTEM STATUS AND PERFORMANCE 6.1 Scope and Objectives of Reporting Cospas-Sarsat is an evolving system, partly through changes in technology, and also as more countries become associated with the Programme (as User States or Ground Segment Providers), or simply make use of the System. It is therefore essential to assemble basic information for keeping track of the evolution of the System and its world-wide performance and use, in order to form the necessary basis for future planning activities in Cospas-Sarsat. The status of the System (including Space Segment, Ground Segment and beacons), and a summary of its performance and the history of detected anomalies, should be reported by all Participants, as appropriate, for every twelve-month period, in accordance with the format provided in section A-1 of Annex A to this document. These reports, after being aggregated by the Secretariat into a single document, are reviewed by the Joint Committee and submitted to the Council. The annual reports therefore form the basis used for updating widely distributed documents such as the “Cospas-Sarsat System Data” document and “Information Bulletin”. 6.2 Space Segment Information on the Space Segment status and its operation is to be provided only by the Space Segment Providers. Such information should cover: • operational spacecraft, • 406 MHz payloads, • other payloads when applicable (e.g., 406 MHz repeaters), • the readiness and launch schedule of new spacecraft and payloads, • significant events affecting the Space Segment, e.g., changes in payload configuration of operational satellites, periodic software resets (watchdog timeouts). All Participants should be kept informed of the current status of the Space Segment. In order to accomplish this, Space Segment Providers shall inform all Ground Segment operators whenever there is a change to the status of any SAR payload as soon as possible. A change in status can be the commissioning (with or without limitations), de-commissioning, or change in configuration of a SAR payload. The Secretariat should also be notified of the change in status in order to update the Space Segment status on the Cospas-Sarsat website, using the format defined at Annex J.

6-2

6.3 Ground Segment 6.3.1 MCCs and LUTs The annual reports should cover the operational status of MCCs and of associated LUTs (if any) for the 406 MHz processed frequency band. Information on the availability of Ground Segment equipment should also be reported as defined in section 6.3.3. It is important that information on the upgrading of existing MCCs and LUTs, and about the implementation of MCCs and LUTs by new participating countries is included. Such developments may have an impact on other Ground Segment Providers, and the information is vital for planning an orderly evolution of the MCC communication network. For the same reasons, reports from MCC operators should also include information on the number of 406 MHz beacon signals reported to RCCs within the MCC service area. 6.3.2 Other Ground Segment Sub-Systems The annual reports should include information on the status and performance of sub-systems such as orbitography and reference beacons and the Sarsat time reference beacon. Malfunctioning orbitography and reference beacons should be reported in almost real-time. 6.3.3 Calculation of LUT / MCC Availability Availability (A) is expressed as a percentage and is calculated by dividing the amount of operational time (OT) by the time required to be in operation (OTR). The time required to be in operation (OTR), expressed in hours, is 24 times the number of days in the reporting period inclusive of all maintenance downtime. The operational time (OT) is OTR minus the system downtime (DT) reported in hours. Downtime is that period of time when a system fails to perform its basic functions as described below. Therefore, availability (A) is calculated as: A = (OT/OTR) * 100 = (1 - (DT/OTR)) * 100 6.3.3.1 MCC System Availability MCC system availability measures the probability of an MCC performing all its basic functions of receiving and processing LUT/MCC data and communicating with other MCCs as presented in Figure 6.1. An MCC's basic functions are described in Cospas- Sarsat Mission Control Centre (MCC) Performance Specification and Design Guidelines (C/S A.005). Specifically, a Cospas-Sarsat MCC must be able to: a) receive and process (e.g., validate, geosort, filter) all alert and system data from national LUTs and foreign MCCs in accordance with Cospas-Sarsat Data

6-3

Distribution Plan (C/S A.001) and Cospas-Sarsat Mission Control Centre Standard Interface Description (C/S A.002); b) monitor the Cospas-Sarsat System in accordance with Cospas-Sarsat System Monitoring and Reporting (C/S A.003); c) archive and retrieve alert data and information; and d) maintain communications links. 4Figure 6.1: System Availability 6.3.3.2 LEOLUT Data Availability LEOLUT data availability measures the probability of receiving complete and accurate LEOLUT data at the MCC as shown in Figure 6.1. Whenever LEOLUT data is not received at the MCC, downtime is measured from LOS of the last successful satellite pass to AOS of the next successful satellite pass. Part of LEOLUT data availability is a LEOLUT’s ability to perform basic functions. The basic functions of a LEOLUT are those specified in Cospas-Sarsat Local User Terminal Performance Specification and Design Guidelines (C/S T.002) and national requirements. If any basic function or requirement is not performed by the LEOLUT and the function has an impact on the operational data to the SAR forces, the LEOLUT data should be considered unavailable. The LEOLUT's basic functions are further described as the capability to: a) maintain ephemeris, acquire, track and receive the downlink signal from Cospas- Sarsat satellites; b) demodulate 406 MHz repeated (as required) and 406 MHz processed data stream channel (PDS) signals; c) maintain and update the required time and frequency references; d) process 406 MHz PDS data in the format specified in Cospas-Sarsat Space Segment Description (C/S T.003); e) decode and error correct 406 MHz PDS data; Beacon Availability Satellite Availability SAT BCN LUT MCC MCC COM COM LUT Data Availability MCC Availability

Image 1 from page 92

Image 2 from page 92

Image 3 from page 92

Image 4 from page 92

Image 5 from page 92

Image 6 from page 92

Image 7 from page 92

Image 8 from page 92

Image 9 from page 92

Image 10 from page 92

Image 11 from page 92

Image 12 from page 92

Image 13 from page 92

Image 14 from page 92

Image 15 from page 92

Image 16 from page 92

Image 17 from page 92

Image 18 from page 92

Image 19 from page 92

Image 20 from page 92

6-4

f) process 406 MHz repeated (as required) signals; g) calculate Doppler positions for all 406 MHz signals; h) provide the data (required by C/S A.002) and an interface to national MCCs; and i) raise alarms and warnings for any anomalous condition. 6.3.3.3 GEOLUT Data Availability GEOLUT data availability measures a GEOLUT’s ability to perform its basic functions. As specified in document C/S T.009, “Cospas-Sarsat GEOLUT Performance Specification and Design Guidelines”, the basic functions of the GEOLUT are as follows: a) receive the downlink signal from the selected GEOSAR satellite(s); b) demodulate 406-MHz repeated signals; c) maintain and update the required time and frequency references; d) decode, process and error correct 406-MHz repeated signals; e) provide the data (required by document C/S A.002) and an interface to national MCCs; and f) raise alarms and warnings for any anomalous conditions. When a GEOLUT fails to perform any basic function and the function has an impact on the operational data to the SAR forces, downtime is measured from the time of initial failure until the time that the GEOLUT successfully performs all its basic functions. Calculation of GEOLUT data availability shall take into account the GEOLUT’s ability to distribute alerts successfully to the associated MCC for operational beacons and designated reference beacons. 6.3.4 Determining the Status of Operational Ground Segment Equipment The status of Ground Segment equipment, as reported by the respective Ground Segment operators, is compiled annually and presented by the Secretariat in widely distributed documents such as the “Cospas-Sarsat System Data” and “Cospas-Sarsat Information Bulletin”. To ensure that these reports reflect the true status of the Cospas-Sarsat System, there is a requirement to identify those components of the System which have reached full operational capability (FOC) but no longer function or could cause adverse effects on System operations. System components which are so identified are to be considered as commissioned, but not operational. In addition, System components should not continue to be operated in an initial operation capability (IOC) status for a period greater than one year. If Ground Segment equipment does not attain FOC status within one year, then it is to be considered as under development. Additional information on extended operation of equipment in an IOC status is contained in documents C/S T.005, “LEOLUT Commissioning Standard”, C/S T.020, “MEOLUT Commissioning Standard”, C/S T.010, “GEOLUT Commissioning Standard” and C/S A.006, “MCC Commissioning Standard”.

6-5

6.3.4.1 Procedure for Determining the Status of Operational Ground Segment Equipment In addition to the annual reports submitted by Ground Segment operators, several other methods can be used for determining equipment status. These include: • periodic monitoring by Ground Segment operators as described in section 3, • periodic tests on a regional or global level, or • reporting of anomalies by nodal MCCs (as part of their regular System monitoring, including daily QMS objective monitoring as described in section 2). An annual System test of alert processing will be conducted in January of each year, as described in Annex I. Each Ground Segment operator should report on their ground segment processing and, in addition, each nodal MCC should review the results of the performance of the ground segment processing in their DDR based on the traffic flow that was observed. Ground Segment operators and nodal MCC operators should report test results, indicating whether the expected processing described in Tables I.2 and I.3 successfully occurred and giving details on any failures. The Joint Committee, using the information provided as noted above and the guidelines described below, will review the status of all commissioned Ground Segment equipment on an annual basis and present their recommendations to the Council. Figure 6.2 presents an overview of the procedure to be used for determining and reporting the status of Cospas-Sarsat Ground Segment equipment (GSE). The figure depicts activities involved for equipment which is operational in either an IOC or FOC status. The associated nodal MCC shall downgrade the status of the GSE to “commissioned, not operational” (CNO) if: a) it has been non-operational for more than forty-five (45) consecutive days; or b) operational status was not maintained for more than six months (180 days) within any one-year period. If the status of the GSE has been downgraded to CNO, the associated nodal MCC shall notify all MCCs and the Secretariat of the status change using a SIT 605 message. The procedure to be followed when the status of an MCC is downgraded to CNO is described in section “Long-Term Backup and Restoration of Operations” in document C/S A.001. The procedure to recover the operational status of an MCC is specified in section 6.3.4.2 in this document. 6.3.4.2 Recover Operational Status of a CNO GSE When the GSE Operator determines that a CNO GSE is ready to resume operations:

6-6

a) the GSE Operator shall coordinate with the associated nodal MCC to establish what testing is needed to demonstrate GSE compliance with the relevant Cospas- Sarsat commissioning standard, based on the cause of the original failure and on the modifications made to the GSE; b) the GSE Operator shall prepare a partial or full Commissioning Report (as appropriate), and provide it to the associated nodal MCC; c) the associated nodal MCC shall review the Report, and complete it, in the case of a CNO MCC; and d) once the nodal MCC determines that the Report and CNO GSE performance are satisfactory, the Report shall be submitted to the Joint Committee, per specified procedures for Commissioning Report submission. After completion of these tasks: a) in the case of a CNO MCC, the MCC Operator may begin operating the MCC in IOC status, in coordination with the associated nodal MCC; and b) in the case of a CNO LUT, the MCC associated with the CNO LUT and the associated nodal MCC shall coordinate the distribution of QMS solution data to the nodal MCC, and the nodal MCC shall ensure nominal (Green) status for a period of at least seven (7) days before the LUT begins operating in IOC status. Once the associated nodal MCC confirms that GSE performance is satisfactory for a time period that the associated nodal MCC determines is appropriate, the associated nodal MCC shall declare the GSE at full operational capability (FOC). Whenever GSE enters IOC status after being in CNO status (or enters FOC status), the associated nodal MCC shall notify all MCCs using a SIT 605 message and update the GSE status associated with the Quality Management System (QMS) on the Cospas-Sarsat website. 6.3.4.3 Guidelines for Determining the Status of Operational Ground Segment Equipment If there is a problem with a particular Ground Segment component that is noted from System or QMS monitoring, a Participant’s annual report, or from periodic exercises, careful consideration should be used when making a determination of its status and each case should be reviewed considering the following general guidelines: • the effect of the problem on SAR operations, • the expected duration of the problem, • the impact on the integrity of the Cospas-Sarsat System, • the impact on other Ground Segment equipment. For example, if an MCC consistently provides an invalid value for a field in distress alert messages which is not required for message processing, there is probably a negligible impact on SAR forces. In cases such as this, no change in the equipment status would probably be necessary as the mission of the System is not affected.

6-7

The expected duration of the problem also has to be determined. A situation where equipment does not meet specifications for a short period may be acceptable. However, equipment failing to operate according to specifications for long durations should be declared as “commissioned, not operational”. Similar to the impact on SAR operations, the impact on the integrity and credibility of the System should also be considered in the reporting of System status. Consideration should be given to the status of implementation of System changes reported by each Ground Segment operator in its annual report as per Annex A, section 1.4, in particular the status of critical changes, to assist in determining the status of the operation Ground Segment equipment. Lastly, the impact of a problem in the equipment of one Ground Segment operator on the equipment of other operators should be considered. The failure to follow prescribed specifications by one Ground Segment operator should not negatively impact on others.

6-8

5Figure 6.2: Operational Status of Ground Segment Equipment

Image 1 from page 97

6-9

6.4 Beacon Population It is essential to regularly update beacon population figures (maritime, aeronautical, land mobile and test) in order to assess in due time any future adjustments which might be required in the ground segment capacity. The beacon population should be assessed in accordance with the Cospas-Sarsat definitions for EPIRBs, ELTs and PLBs. For similar reasons, changes in the national regulatory situation should be reported, including the possible impact on beacon population forecasts. An estimate of total beacon population is calculated by dividing the registered beacon population by the registration rate at time of detection. The registration rate is calculated by comparing the number of detections to the number of detected beacons that are registered. Total Beacon Population = Total Registered Beacon Population Registration Rate where: Registration Rate = Number of Detected Beacons that are Registered Total Number of Detected Beacons In order to provide the best possible estimate of total beacon population, Administrations should consider use of a standard registration rate of 70% when the calculated registration rate equals zero, or is less than 40%, unless they have knowledge from other sources that the low number was an accurate depiction of the real registration rate. Unless otherwise noted, the calculation of the registration rate shall exclude uncorroborated MEOSAR alerts. Each Cospas-Sarsat Participant should also provide the list of nationally approved beacon models to the Secretariat. This list will be maintained by the Secretariat for distribution to Cospas-Sarsat Participants. Administrations participating in Cospas-Sarsat will thereby have access to additional information about the performance of beacons type approved in their country but used in other areas. Each Cospas-Sarsat Participant should include a narrative summary of beacon anomalies in its annual report for inclusion in the Cospas-Sarsat Report on System Status and Operations. All Cospas-Sarsat Participants should provide a summary of their 406 MHz carriage requirements regulations, coding, registration requirements, etc. to the Secretariat for inclusion in document C/S S.007, “Handbook of Beacon Regulations”. 6.5 False Alert Rate The false alert rate should be calculated in three ways, i.e., one percentage to show the false alert rate as a function of the beacon population, a second percentage to show the false alert rate as a function of total alerts transmitted to SAR authorities, and a third series of percentages to show false alert rates as a function of specific beacon models. The procedures for calculating each of the three false alert rates are described below.

6-10

6.5.1 False Alert Rate as a Function of Beacon Population The false alert rate as function of the total beacon population can be viewed as a method of tracking false alerts from a Cospas-Sarsat System perspective. The rate should be calculated by dividing the number of false alerts and undetermined alerts occurring world- wide with the reporting Participant’s country code(s), by the estimated total beacons with the Participant’s country code(s), as reported at section 1.3.2 of the Report on System Status and Operations provided at Annex A. This calculation should be provided for each type of beacon (EPIRBs, ELTs and PLBs). 6.5.2 False Alert Rate as a Function of the Total Number of Alerts The false alert rate calculated as a function of the total number of alerts can be viewed as representing the SAR response perspective. This rate should be calculated by dividing the number of false alerts and undetermined alerts transmitted to SAR authorities in the reporting Participants service area, by the number of total alerts transmitted to the SAR authorities in the service area. The data for this calculation is provided in section 2.1 of the Report at Annex A. 6.5.3 False Alert Rates as a Function of Beacon Model The false alert rate for each beacon model is used as a first step for identifying possible problems with specific variants of beacon models. This rate is calculated by dividing the number of false alerts attributed to a given beacon model variant (e.g., beacon model, type and activation method) transmitted to SAR authorities in the reporting Participant’s service area, by the estimated total number of beacons of that model, type and activation method with the Participant’s country code. Participants are encouraged to conduct further analysis on those models which exhibit high false alert rates with a view to identifying their causes. Caution is advised in drawing conclusions in respect of possible beacon problems from this data since experience has shown that false alerts can be caused by factors not related to beacon design. A hypothetical example for reporting these statistics is provided below at Table 6.1. 10Table 6.1: Example for Reporting False Alert Rate by Beacon Model Model Name TAC Beacon Type / Activation Method Estimated Number of Beacons Number of False Alerts False Alert Rate ModelA

ELT / Manual

2.0% ModelA

ELT / Auto

12.5% ModelB

EPIRB / Manual

5.0% 6.6 Interference Experience has shown that interference is a threat to System integrity and that eliminating it is a long-term effort. In order that Cospas-Sarsat can ascertain the global status of interference at 406 MHz, it is necessary that LUT operators who perform routine monitoring of interference in

6-11

the 406 MHz band report on a monthly basis to the Secretariat and to ITU as specified in section 5. The Secretariat should summarise data on persistent interference in its annual report on System status and operations and present this information to international organizations (IMO, ICAO and ITU) on an annual basis. 6.7 406-MHz Beacon Message Processing Anomalies Processing anomalies which occur during 406-MHz beacon message processing may have a detrimental impact on System integrity. In an effort to minimise this negative impact, MCC operators should collect and analyse processing anomalies as a function of all MCC processed messages, with a view to determining which type of alerts are a source of the anomalies. The analysis of processing anomalies should be reported according to the guidelines provided at Annex F. 6.8 Distress Incident Report of SAR Events Assisted by Cospas-Sarsat Information To assess the effectiveness of the contribution being made by the Cospas-Sarsat System to search and rescue world-wide, information on distress incidents should be provided by MCCs at least on a monthly basis using the on-line tool available on the Cospas-Sarsat website (www.cospas- sarsat.int) and described in the format given at Annex A, section A-2 of this document. 6.9 Collecting and Reporting Data for SAR Event Analysis On occasions, Cospas-Sarsat may be asked to provide information on the performance of the System in respect of specific search and rescue events. The Cospas-Sarsat Council has approved a procedure for interested parties to request this information from Cospas-Sarsat, this procedure is provided at Annex G. Annex G also provides guidelines to Ground Segment operators for collecting and reporting the necessary data to the Cospas-Sarsat Secretariat for analysis. All data should be accompanied with a covering letter that summarises the information provided. The letter should also provide a narrative description of the status of the operator’s Ground Segment equipment during the time period of the event analysis. Ground Segment operators may, on an annual basis, undertake a SAR event analysis of an incident of their choosing and report their findings to the Joint Committee.

  • END OF SECTION 6 -

A-1

ANNEX A SYSTEM STATUS AND OPERATIONS AND DISTRESS INCIDENT REPORT FORMATS 1. FORMAT OF REPORT ON SYSTEM STATUS AND OPERATIONS DEADLINE TO SUBMIT THIS REPORT: xx March 20xx Date of report: dd mm 20xx Origin: country name Time period: 1 January to 31 December 20xx 1. SYSTEM STATUS AND DEVELOPMENT SCHEDULE Note: This section to be greyed out if the “Origin” country is not a Space Segment Provider. 1.1 Space Segment 1.1.1 Status of operational spacecraft / payloads LEOSAR Satellites Name Comments Status of Payloads SARR SARP (Local & Global) [As identified by the spacecraft Provider] MEOSAR Satellites Name Status of Spacecraft Status of Payloads [Identified by the Spacecraft Provider] GEOSAR Satellites Name Comments GEOLUTs Status of Payloads Location [As identified by the spacecraft Provider] 1.1.2 Report on significant events (changes in payload configuration of operational satellites, changes in location of operational satellite, etc.) 1.1.3 Readiness and launch schedule of new spacecraft / payloads

A-2

1.2 Ground Segment Note: This section to be greyed out if the “Origin” country is not a Ground Segment Provider. 1.2.1 LUT availability Notes: (1) This section to be greyed out if the “Origin” country is not a LUT Operator. (2) Availability is expressed as a percentage and is calculated by dividing the amount of time in operation by the time required to be in operation. See C/S A.003, section “Calculation of LUT / MCC Availability” for complete instructions. (3) For non-phased-array MEOLUT availability, the results should be reported channel by channel, and based on the number of channels available during the same period. 1.2.2 Report on significant LUT events Notes: As a guide for this section report: (1) Current operational status as of 31 December 20xx. (2) Orbit vector update method (see the section of C/S A.001 entitled “LEOLUT Orbit Vector Update Method”). (3) Any issues impacting operational status during the course of the year. (4) Any issue impacting availability, i.e., hardware failures, loss of power and communications, etc. (5) Any significant preventative maintenance and software upgrades undertaken. 1.2.3 MCC availability Note: (1) Availability is expressed as a percentage and is calculated by dividing the amount of time in operation by the time required to be in operation. See C/S A.003, section “Calculation of LUT / MCC Availability” for complete instructions. 1.2.4 Report on significant MCC events Notes: As a guide for this section report: (1) Current operational status as of 31 December 20xx. (2) Any issues impacting operational status during the course of the year. (3) Any issue impacting availability i.e., hardware failures, loss of power and communications, etc. (4) Any significant preventative maintenance and software upgrades undertaken. 1.2.5 Report on MCC backup procedure test results Notes: (1) Provide a summary of test results undertaken by the MCC operator according to the existing backup procedures and agreements. (2) Include the period of backup, e.g., 12 hours or 24 hours. (3) Include time required to switch to backup.

A-3

1.2.6 Other Ground Segment sub-systems (orbitography / reference and time reference beacons, etc.) 1.2.7 Schedule of new Ground Segment equipment installation / commissioning 1.3 Beacon Population 1.3.1a Percentage of detected beacons with own country code that are registered (excluding uncorroborated MEOSAR alerts) Beacon Type Number of Detections Number of Detected beacons that are Registered Calculated Registration Rate (%) EPIRB ELT 3 ELT(DT) PLB SSAS Beacon Total 1.3.1b Percentage of detected beacons with own country code that are registered (uncorroborated MEOSAR alerts only) Beacon Type Number of Detections Number of Detected beacons that are Registered Calculated Registration Rate (%) EPIRB ELT 3 ELT(DT) PLB SSAS Beacon Total 1.3.1c Report on Uncorroborated Alerts Distribution by MCCs to RCCs and SPOCs Beacon Type UAs not transmitted to RCCs and SPOCs UAs transmitted to RCCs and SPOCs Total UAs Feedback for RCCs and SPOCs (optional) 1- Per MEOLUT Process. Anomaly Rate Capability only 2- Per Beacon Registration only 3-Other only Multiple Conditions Met (any combination of 1, 2, or 3) Actual Activation Not Actual Activation Undeter- mined FGB

A-4

FGB ELT(DT) SGB SGB ELT(DT) 1.3.2 National beacon population Total Beacon Population = Total Number of Beacons in the Beacon Register / Registration Rate (per section 1.3.1.a above). Non-registered = Beacon Population – Registered. Notes: (1) Test beacons are those beacons that have been coded as such. (2) In cases where the calculated registration rate was very low (e.g., less than 40%), Administrations should use a standard (nominal) registration rate of 70%, unless they have knowledge from other sources that the low number was an accurate depiction of the real registration rate. (3) The ELT category excludes ELT(DT)s. Note: (1) Some Administration beacon registration forms request this information and thus some countries can provide this data. 1.3.3 Changes in regulatory status Note: Administrations should refer to document C/S S.007 and report any changes to the information for their country contained therein. 1.4 Status of Implementation of System Changes The status of implementation of Ground Segment changes shall be reported by each Ground Segment Provider 12 weeks prior to each Joint Committee meeting. Depending on the annual meeting schedule, this submission deadline might be different from the document C/S P.011 requirement that each Participant submit their Annual Report on System Status and Operations to the Secretariat by the end of the month of February. MCC operators shall submit their compliance with implementation deadlines for Ground Segment changes listed in an Excel spreadsheet, developed based upon agreed changes described in the Joint Committee Report and approved by the Council. Beacon Type Beacons in the Register Registration Rate (%) Total Beacon Population Non-registered EPIRB ELT 3 ELT(DT) PLB SSAS Beacon Test Beacon NA NA Total

A-5

SYSTEM OPERATIONS 2.1 Number of Beacon Activations Reported to RCCs/SPOCs within the MCC Service Area (The total number of alerts with location and those detect-only alerts which have been properly validated by the MCCs) Notes: Ground Segment Providers (and User States if possible) are to report the number of beacon activations reported to RCCs/SPOCs within their search and rescue region (SRR). ALERT CLASSIFICATION EPIRB ELT 4 ELT (DT) PLB Sub-Total Total Distress Alerts False Alerts Unfiltered Processing Anomalies Operational False Alerts 1 (Beacon Activations) Beacon Mishandling 5 Beacon Malfunction Mounting/Interface to Avionics Failure Environmental Conditions Maintenance Activations Voluntary (non-maintenance) Activations Unknown Undetermined TOTAL Notes: (1) See Appendix B.1 for classifications of Cospas-Sarsat alerts and Appendix B.2 for examples of operational false alerts associated with each classification. (2) Report the total number of alerts with location and those detect-only alerts which have been properly validated by the MCCs. (3) Same beacon ID involved in separate incidents at different times will be counted multiple times.

Image 1 from page 105

Image 2 from page 105

Image 3 from page 105

A-6

(4) The ELT category excludes ELT(DT)s. (5) Optionally, Beacon Mishandling category may be split into additional subcategories (e.g., commercial users, recreational users, maintenance agents, etc.) in a separate table. 2.2 Report on Significant Events or Anomalies during Period of Operation Notes: As a guide for this section report: (1) Number of lives saved with respect to incidents identified as “DISTRESS ALERTS”, per section 2.1. (2) Any Cospas-Sarsat Model Course training provided for LUT/MCC/RCC personnel. (3) Commissioning of new LUTs/MCCs. (4) Operations from an MCC backup site. (5) Any issues concerning satellite manoeuvre/QMS/leap second change, etc. (6) Provision of beacon detection information to any international authority on a regular basis, e.g., Australia providing ICAO on a monthly basis all ELT detections by the Australia/New Zealand ground segment. 2.3 Report on Beacon Anomalies Notes: (1) Non-activation of beacons. Attach a narrative report for each case presented. (2) Operational false alerts (count is provided in section 2.1). Where possible, provide the data according to Appendix B.1 in order to better track the false alert problem. (3) Other beacon anomalies. Where possible, provide the 15 hexadecimal beacon identifier, the beacon type, the country code, first and last detection, average repetition rate, and calculated frequency. 2.4 False Alert Rate 2.4.1 Cospas-Sarsat System operation perspective false alerts world-wide with Participant’s country code(s) + undetermined alerts world-wide with Participant’s country code(s) = ----------------------------------------------------------------------------------------------------------------- estimated total number of beacons with Participant’s country code(s) Participant’s Country Code Beacon Number of False Alerts World-wide + Undetermined Alerts World-wide Estimated Number of Beacons False Alert Rate (%) EPIRB ELT 2 ELT(DT) PLB Totals Note: (1) Estimated number of beacons can be obtained from section 1.3.2, Beacon Population. (2) ELT category excludes ELT(DT)s. 2.4.2 SAR response perspective from MCCs and User States / RCCs (False alerts, undetermined alerts and total alerts can be obtained from the Table in section 2.1.) 2.4.2.1 MCC reports

A-7

false alerts + undetermined alerts transmitted to RCCs/SPOCs in Participants service area = --------------------------------------------------------------------------------------------------------- total number of alerts transmitted to RCCs/SPOCs in Participants service area Number of False Alerts + Undetermined Alerts Transmitted to SPOCs Total Number of Alerts False Alert Rate (%) 2.4.2.2 RCC reports false alerts + undetermined alerts received for RCC/SPOC SRR = --------------------------------------------------------------------------------------------------------- total number of alerts received for RCC/SPOC SRR Number of False Alerts + Undetermined Alerts Received from the MCC Total Number of Alerts False Alert Rate (%) 2.4.3 False alert rate by beacon model Model Name (1) TAC (2) Beacon Type / Activation Method (3) Estimated Number of Beacons (4) Number of False Alerts False Alert Rate Notes: (1) Beacon model name. (2) Cospas-Sarsat Type Approval Certificate number. (3) Beacon type and activation method (e.g., EPIRB/Automatic, ELT/Manual, etc.). Each combination of beacon model / activation method should be reported on a separate line. (4) Estimated total number of beacons of that model, type and activation method with Participant’s country code(s). 2.5 Report on Educational and Regulatory Actions to Reduce False Alerts Note: (1) Provide a summary of actions undertaken by the Participant working with their national Administrations, and with the Administrations of the SRRs within its MCC service area as applicable, to reduce the number of false alerts and to reduce the impact of false alerts.

A-8

APPENDIX A.1 - CLASSIFICATION OF COSPAS-SARSAT ALERTS False Alerts Distress Alerts Undetermined Alerts Received by SAR Authorities Unfiltered Processing Anomalies Beacon Activations Anomalies (Operational False Alerts) Beacon Mishandling (resulting in an unintended situation):  Improper installation procedure / location,  Improper testing and maintenance,  Improper use,  Improper disposal of beacon. Beacon Malfunction:  Faulty activation switch, i.e., gravity activated, magnetic, mercury, or crash,  Water ingress,  Transmitting distress signal while in test position,  Electronics malfunction. Mounting/Interface to Avionics Failure:  Strap or bracket failure,  Release mechanism malfunction for EPIRB,  Faulty mounting magnet for externally mounted ELT,  Avionics-beacon interface malfunction for ELT(DT). Environmental Conditions:  Extreme weather conditions. Maintenance Activations:  Intentional activation for testing purposes by a person performing maintenance. Unknown: (Confirmed Beacon Activations)  No feedback received on why beacon was activated,  Investigation into beacon activation cause was inconclusive. Voluntary Activations:  Non-declared tests other than those done by a person performing maintenance,  Malicious activations.

Image 1 from page 108

Image 2 from page 108

Image 3 from page 108

Image 4 from page 108

Image 5 from page 108

Image 6 from page 108

Image 7 from page 108

Image 8 from page 108

Image 9 from page 108

Image 10 from page 108

Image 11 from page 108

Image 12 from page 108

Image 13 from page 108

A-9

APPENDIX A.2 - EXAMPLES OF OPERATIONAL FALSE ALERTS Beacon Mishandling Improper installation procedure / location Exposed to sea action or ship’s work, beacon activated by sea spray or wave, crewman bumped beacon, equipment struck beacon, beacon installed upside down, improperly placing beacon into bracket. Improper testing and maintenance Failure to follow proper testing procedures, negligence, poor beacon testing instructions, aircraft in situ test. Inspection by authorised inspector: accidental activation during vessel equipment inspection. Repair by owner (usually unauthorised) or authorised facility: causing damage to beacon, activation during battery change, changing of hydrostatic release while servicing beacon. Improper removal from bracket: inspection, test, cleaning, or safe keeping without switching off. Beacon shipped to / by retailer, owner, repair facility (in transit): shipped while armed, improperly packed, improperly marked, rough handling. Maintenance of craft: mechanical, electronic, wash down, painting, winterization. Beacon stored improperly: stored while armed. Improper use Accidental activation: beacon activated operationally in an attempt to perform self-test or beacon activated in an attempt to ascertain beacon ID or 24-bit address from a local receiving device and beacon signal was unintentionally transmitted to satellite. Improper disposal of beacon Beacon sold with craft for scrap, discarded as trash, abandoned. Beacon Malfunction Faulty activation switch, i.e., gravity activated, magnetic, mercury, or crash Hard landing, excessive craft vibration. Water ingress Water leakage due to manufacturing defect, cracked casing, faulty seal. Transmitting distress signal while in test position Transmitted non-inverted frame sync while in test mode. Electronics malfunction Non-GNSS electronics malfunction. Mounting/Interface to Avionics Failure

A-10

Strap or bracket failure Strap failure, mounting bolts sheared, retainer pin broken, beacon fell out of bracket. Release mechanism malfunction Premature release of hydrostatic release. Faulty mounting magnet for externally mounted ELT Switch magnets not effective. Avionics-Beacon Interface malfunction Activation of an ELT(DT) as a result of failure or out of tolerance condition experienced by aircraft interface module. Environmental Conditions Extreme weather conditions Hurricane / cyclone conditions, vessel knocked down, aircraft overturned, heavy seas, ice build-up. Maintenance Activations For testing purposes by a person performing maintenance Voluntary Activations Non-declared tests Activation of beacon for test, without proper notification or agreement of authorities other than those done by a person performing maintenance. Malicious activations, hoax Unknown (Confirmed Beacon Activations) No feedback received on why beacon activated Investigation into beacon activation cause was inconclusive

A-11

APPENDIX A.3 – INFORMATION GRAPHIC ON SOURCES OF FALSE ALERTS Figure A.1: Information Graphic on Sources of False Alerts

Image 1 from page 111

A-12

TOOL FOR REPORTING SAR EVENTS All annual SAR incident reports should be sent by MCC operators to the Secretariat by an email attachment. See respective instructions below: INSTRUCTIONS Attached to this email you should find a blank template file entitled: ‘SAR_IMS.zip’ (provided by the Secretariat). If there is no attachment, please contact your IT support provider as some firewalls may block zip files. Right click ‘Save As’ and save the file locally to your desktop or documents folder. Right Click on the file stored on your local computer and select ‘Extract Here’ (or extract using your favorite compression utility). You should now have a file ‘SAR_IMS.mde on your computer. Open this file in MS-Access by double clicking or launch MS- Access and manually open file. (Please ignore any security warning in MS-Access and click Open).

Image 1 from page 112

Image 2 from page 112

Image 3 from page 112

A-13

A Main Menu will launch. From the main menu, click ‘Incidents’ and enter all events for the entire year from January 1 to December 31 20XX. When complete, locate your locally completed ‘SAR_IMS.mde’ file and compress as ‘SAR_IMS.zip’. Email compressed SAR_IMS.zip to: mail@cospas-sarsat.int with ‘20XX SAR Incident Reports’ included in the subject line.

Image 1 from page 113

Image 2 from page 113

Image 3 from page 113

Image 4 from page 113

Image 5 from page 113

B-1

ANNEX B 406-MHz INTERFERENCE MONITORING AND REPORTING 1. STATUS OF LEOLUT MONITORING CAPABILITIES The following Cospas-Sarsat LEOLUTs are capable of monitoring 406-MHz interference, using special equipment in the LEOLUT, in conjunction with the 406 MHz repeater on Sarsat satellites. The coverage area of LEOLUTs performing 406-MHz routine interference monitoring is shown at Figure B.1. Code Location Ground Segment Provider/Operator Status

Algiers Algeria Routine monitoring

El Palomar Argentina Routine monitoring

Rio Grande Argentina Routine monitoring

Brasilia Brazil Routine monitoring

Recife Brazil Routine monitoring

Churchill Canada Routine monitoring

Edmonton Canada Routine monitoring

Goose Bay Canada Routine monitoring

Ottawa Canada Available

Easter Island Chile Available

Punta Arenas Chile Available

Santiago Chile Routine monitoring 4121.2 Beijing China (P.R. of) Routine monitoring 2271.2 Toulouse France Routine monitoring

Penteli Greece Routine monitoring 4771.2 Hong Kong Hong Kong - China Routine monitoring

Bengaluru India Routine monitoring

Lucknow India Routine monitoring

Jakarta Indonesia Routine monitoring

Bari Italy Routine monitoring

Abuja Nigeria Unavailable

Spitsbergen Norway Routine monitoring

Karachi Pakistan Routine monitoring

Callao Peru Routine monitoring

Doha Qatar Routine monitoring

Nakhodka Russia Routine monitoring 4031.2 Jeddah Saudi Arabia Periodic monitoring *

Singapore Singapore Periodic monitoring *

Cape Town South Africa Routine monitoring

Maspalomas Spain Routine monitoring 4161.2 Dapinding ITDC Available 5671.2 Bangkok Thailand Routine monitoring 2711.2 Ankara Türkiye Routine monitoring

Abu Dhabi UAE Routine monitoring

B-2

Code Location Ground Segment Provider/Operator Status

Lee-on-Solent UK Routine monitoring 3037.8 Alaska USA No routine monitoring 3667.8 Florida USA Routine monitoring 3667.8 Florida USA No interference data provided 3381.2 Guam USA Routine monitoring 3387.8 Hawaii USA No routine monitoring

Maryland (LME) ** USA Routine monitoring

Haiphong Viet Nam Routine monitoring Notes: * Periodic monitoring: the LEOLUT can be set by the MCC operator to a special operating mode to check for 406 MHz interference periodically as needed. ** LME (LEO/MEO support Equipment) reports interference when the USA uses it operationally. Routine monitoring: the LEOLUT automatically monitors each scheduled Sarsat satellite pass above 5 for 406-MHz interference. Figure B.1: Coverage Area of LEOLUTs Performing 406-MHz Routine Interference Monitoring Satellite: Altitude - 850 km, Elevation angle – 5° degrees

Image 1 from page 115

B-3

ITU INTERFERENCE REPORT FORMS (From Recommendation ITU-R SM.1051-4) 2.1 Information report concerning interference a. Mean latitude and longitude, b. Probable search radius from mean location. Country. Nearest city, c. Frequencies, d. Number of observations (total and number since last report), e. First and last date of occurrences, f. Modulation characteristics, g. Times and days-of-week of occurrences, h. Other details. 2.2 Feedback report concerning the interference source a. Latitude and longitude, b. Fundamental frequency of offending source (this may be outside the band), c. Type of equipment, d. Cause of interference, e. Action taken.

B-4

1Table B.1: 406-MHz Interference Report Format (Part 1) Reporting Period (DD Month – DD Month YY) Site ID Number 2 Location Search Area (probable search radius from mean location) (km)

Mean Latitude (d°, 100th of d°) Mean Longitude (d°, 100th of d°) Mean Detected Freq. (MHz) 9 Modulation Character 3 Impact on System 4 Monthly Detection Ratio 5,6 (minimum reported: xx%) Dates of Observations Times and Days of Week of Occurrences Number of Observations (number since last report and total) Other Details

Country Nearest City Direction from Nearest City Distance (km) First Date Last Date Date Day of Week Start Time End Time Current Period 6 (minimum reported: nn/month) Total

MID

Text Text NE,W, SW, etc. nn nn nn.nn nnn. nn 406. nnn N/ME/ PE H/ M/ L 0.nn YYMM DD YYMM DD YYMM DD Sn, Mo, Tu, etc. HH: MM HH: MM nn Nnnn Text MID

etc. Note: See next page.

B-5

Table B.1: 406-MHz Interference Report Format (Part 2) (see Note 7) Status (open/closed) 1-opn, 0-clsd Location (Confirmed) Narrative, including the identification of the source, as available Country Nearest City Latitude (d°, 1000th of d°) Longitude (d°, 1000th of d°) Type of Equipment Assigned Frequency (MHz) Assigned Frequency Band (MHz) Class of Emission Power Characteristics Cause of Interference Action Taken Other Data

Text Text nn.nnn nnn.nnn

Notes:

  1. Reporting should be provided in Excel format on a monthly basis. Minimum data is required for the following columns: 1, 2, 3, 6, 7, 8, 9, 13, 14, 19 and 20. Fields for which data is not available can be left blank.

Site ID number consists of two parts: 3-digit country code according to ITU MID code of the country of reporting authority plus 6 digits, assigned by the authority to the site. The reporting MCC should label a given interferer with the same Site ID in consecutive reports. 3. Type of modulation of main carrier: N – emission of unmodulated carrier, ME- emission of modulated carrier, PE- emission of pulses (data optional for Part 1, supplied in case of availability). 4. High: Reducing throughput of reference beacon in case of mutual visibility by 50% and more, Medium – by 25-50%, Low –less than 25%. 5. Monthly detection ratio DR = N1/(N1+N2), where: N1 – number of passes over emitter at/above 5 degrees, with at least 1 location; N2 – number of passes over emitter at/over 5 degrees, with no location. 6. Interferers with DR > 0.1 and with no less than 10 separate observations (10 distinct satellite passes) per month by the reporting MCC over the current reporting period are the ones that should normally be reported. However, given the different levels of interference in various parts of the world, MCCs may adjust their reporting criteria in order to keep the number of interferers reported at a reasonable level. The criteria used shall be indicated in the report (header of columns 12 and 19). An interferer that remains below the chosen reporting criteria over a given reporting period may still be reported in order to ensure continuity with previous reports. MCCs are encouraged to use their judgment to ensure the continuity of the content of their reports over time and to give a meaningful account of the interferers located in their region. 7. These items depend on feedback report concerning interference source. This is normally provided after the site has been closed and emissions have been stopped. 8. The radius of the Search Area (column 6) may be computed using the standard deviations of latitude and longitude. 9. Mean Detected Frequency (column 9): When more than one frequency is observed, the frequency nearest to the current operational band(s) is to be reported. Other frequencies will be listed in Other Details (column 21). 10. Other Details (column 21): Include in separate attachment, as needed.

  • END OF ANNEX B -

C-1

ANNEX C PERFORMANCE PARAMETERS FOR SYSTEM SELF-MONITORING 2Table C.1: LEOSAR and MEOSAR System Performance Parameters Ref. Performance Parameter Criteria Anomaly Conditions Comments 3.1.1.1 LEOSAR System Timing 20 min PT > 1200 Processing time for each incident alert reported PT = (TMTX – TLOS) TMTX = Time of MCC transmission TLOS = Time of Loss of Signal 3.1.1.6 Received Down-link Power Level Baseline – 10dB MRP < B. – 10dB Measured at elevations above 5º from the LEOLUT (See note 1) MRP = Maximum Received Power at LEOLUT receiver, based on AGC value (See note 2) 3.1.1.7 Loss of Carrier Lock Baseline + 10% DCL > B + 10% Measured at elevations above 5º from the LEOLUT (See note 1) DCL = duration (above five degrees) when carrier lock is not maintained (See note 2) 3.1.1.8 SARP Throughput 70% THRU < 70% Standard pass over orbitography or reference beacon (See note 1) THRU = #REC / #EXP Data points from Ref. Beacon #REC = Number received #EXP = Number expected 3.1.1.9 406 MHz PDS Data Recovery Rate 80% DRR < 80% Measured at elevations above 5º from the LEOLUT (See note 1) DRR = #REC / #EXP #REC = Number received #EXP = Number expected 3.1.1.10 Number of Single Point Alerts Baseline + 50% #SPA > B. + 50% Average per satellite during one day of operation (See note 3) #SPA=number of single point alerts (See note 2) 3.1.1.11 SARP Bit Error Rate Baseline + 30% ABERSAR P > B. + 30% Measured on PDS beacon messages received during each pass (See note 1) ABERSARP = average bit error rate in SARP messages, measured as defined in paragraph 3.1.1.11 of C/S A.003 (See note 2) 3.1.1.12 SARR Bit Error Rate Baseline + 30% ABERSAR R > B + 30% Measured on SARR beacon messages received during each pass (See note 1) ABERSARR = average bit error rate in SARR messages, measured as defined in paragraph 3.1.1.12 of C/S A.003 (See note 2) 3.1.1.13 Pass Scheduling Accuracy 2 seconds AAOS > PAOS+ 2 ALOS < PLOS – 2 For every predicted satellite pass (See note 1) AAOS = actual AOS of pass ALOS = actual LOS of pass PAOS = predicted AOS PLOS = predicted LOS Notes: (1) These Performance Parameters shall be measured and reported separately for each combination of LEOSAR satellite and LEOLUT. (2) The baseline value for each of these Performance Parameters shall be measured over a period of at least one week of normal system operation. (3) This Performance Parameter shall be measured on each LEOSAR satellite pass over the LEOLUT and shall be checked daily. An anomaly shall be reported for any day when the Parameter value exceeds the criterion.

C-2

Table C.1: LEOSAR and MEOSAR System Performance Parameters (Cont.) Ref. Calibration Factor Criteria Anomaly Conditions Comments 3.1.1.2 Sarsat SARP TCAL 10 ms EDAO > 10 ms For each SARP TCAL update (See note 5) (See note 1) 3.1.1.3 Sarsat SARP FCAL .05 Hz EUSO > .05 Hz For each SARP FCAL update (See note 5) (See note 2) 3.1.1.4 Sarsat & Cospas SARR Frequency Calibration 1 Hz EFR > 1 Hz For each SARR FCAL update (See note 5) (See note 3) 3.1.1.5 Sarsat & Cospas Orbit Vectors 5 km 5 m/sec POFFS > 5 km VOFFS > 5 m/s For each orbit data update (See note 5) (See note 4) 3.1.1.6 MEOSAR Orbit Vectors 30 km default 50 km default (if the satellite was manoeuvred since previous orbit vectors processed) PDEL > 30 km PDEL > 50 km For each orbit data update provided to the MCC (See note 4) Notes: (1) Sarsat Time Calibration Calculation: EDA0 = | DA0n-DA0o | DA0 = rollover time, seconds DA0n = DA0 at present check DA0o = DA0 at previous check + 2N*k*Nf/Fro k = Number of rollovers from previous to present check N = 23 for SARP-2 and SARP-3 Nf = 99360 for SARP-2, Nf = 200000 for SARP-3 Fro = USO frequency at previous check, Hz (2) Sarsat SARP Frequency Calibration Calculation: EUSO = | Frn – Fro | / Nd Fro = USO frequency at previous check, Hz Frn = USO frequency at present check, Hz Nd = # days from previous to present check (3) Sarsat SARR Frequency Calibration Calculation: EFR = | OFN – OFO | / Nd OFO = frequency offset at previous check, Hz OFN = frequency offset at present check, Hz Nd = # days from previous to present check (4) Orbit Vector Calibration Calculation: AOFFS = | PoAOS – PnAOS | / Nd LOFFS = | PoLOS – PnLOS | / Nd PoAOS = AOS computed with previous orbit vectors PnAOS = AOS computed with present orbit vectors PoLOS = LOS computed with previous orbit vectors PnLOS = LOS computed with present orbit vectors Nd = # days from previous to present check If the LEOSAR satellite has recently performed an orbit manoeuvre, then no Orbit Vector Calibration Calculation anomaly should be reported. PDEL = (Position difference for previous orbit vectors propagated to PnETime vs Position of present orbit vectors) DOFFS (Days Offset) = PoETime – PnETime (in seconds) / 86400 PoETime = Epoch time for previous orbit vectors

C-3

PnETime = Epoch time for present orbit vectors MCCs shall be capable of validating MEOSAR orbit vectors based on a configurable threshold (PDEL) per satellite. (5) These Calibration Factors shall be measured and reported separately for each combination of LEOSAR satellite and LEOLUT.

C-4

3Table C.2: GEOSAR System Performance Parameters Ref. Performance Parameter Criteria Anomaly Conditions Comments 3.1.2.1 GEOSAR System Timing 30 min GT > 1800 Processing time for each incident alert reported GT = (TMTX – TDET) TMTX = Time of MCC transmission TDET = Time of initial detection 3.1.2.2 GEOSAR Rate of Reception of Beacon Messages 75% RRATE < 75% #EXP = Number of expected messages #RCV = Number of received messages RRATE = 100* #EXP / #RCV (See note 1) 3.1.2.3 GEOSAR Frequency Stability of Beacon Transmissions 2.0 Hz (Ref) 5.0 Hz (distress) MAXFD > 2.0 or MAXFD > 5.0 MAXFD = Maximum difference of measured beacon frequency from average (See note 1) 3.1.2.4 GEOSAR Carrier to Noise Ratio Baseline - 20% ACNRB < B - 20% (See note 2) ACNRB = Average Carrier to Noise Ratio in GEOSAR messages from the selected beacon (See note 1) 3.1.2.5 GEOSAR Bit Error Rate Baseline + 30% ABERGSAR

B + 30% (See note 2) ABERGSAR = Average bit error rate in GEOSAR messages (See note 1) Notes: (1) These Performance Parameters shall be measured over a period of four hours of system operation. (2) The baseline value for this Performance Parameter shall be measured over a period of at least one week of normal system operation.

C-5

4Table C.3: Number of Points Transmitted by a Distress Beacon CTA (Beacon to Satellite) Max Elevation Angle Cospas/ Sarsat Cospas Satellites (1000 km Altitude) Sarsat Satellites (850 km Altitude) 0 Degree Horizon 5 Degrees Horizon 0 Degree Horizon 5 Degrees Horizon Duration of Pass (min) No. of Points Duration of Pass (min) No. of Points Duration of Pass (min) No. of Points Duration of Pass (min) No. of Points

90.0/90.0 17.6

14.9

13.4

82.6/81.5 17.6

14.9

13.4

75.4/73.3 17.5

14.8

13.4

68.6/65.7 17.5

14.8

15.9

13.3

62.2/58.7 17.4

14.7

15.9

13.2

56.4/52.5 17.3

14.6

15.8

13.1

51.1/46.9 17.2

14.5

15.7

46.3/42.0 17.1

14.3

15.6

12.8

42.0/37.7

14.2

15.4

12.6

38.1/33.8 16.8

15.2

12.4

34.6/30.0 16.7

13.7

15.1

12.2

31.4/27.4 16.5

13.5

14.8

11.9

28.5/24.6 16.2

13.2

14.6

11.6

25.9/22.2

12.9

14.3

11.2

23.5/19.9 15.7

12.6

10.9

21.3/17.8 15.4

12.2

13.7

10.4

19.2/15.9 15.1

11.7

13.3

9.9

17.3/14.1 14.7

11.2

12.9

9.4

15.6/12.5 14.3

10.7

15.5

8.7

13.9/10.9 13.9

10.1

12.3/9.4 13.4

9.4

11.5

7.1

10.8/8.1 12.9

8.6

10.9

6.1

9.4/6.8 12.3

7.7

10.5

4.7

8.1/5.5 11.7

6.6

9.4

2.6

6.8/4.3 10.9

5.2

8.5

NA NA

5.6/3.2 10.1

7.5

NA NA

4.4/2.1 9.2

NA NA 6.2

NA NA

3.3/1.0 8.1

NA NA 4.5

NA NA

2.2/0.0 6.7

NA NA 0.6

NA NA

1.1/NA

NA NA NA NA NA NA

0.1/NA 1.6

NA NA NA NA NA NA Note: * = For orbitography beacons, multiply number of points by 1.6.

  • END OF ANNEX C -

D-1

ANNEX D ANOMALY NOTIFICATION MESSAGES The System anomaly notification message is transmitted according to the guidance contained in section 3.1.1 of this document and the section of the document C/S A.001 entitled “Contingency Procedures”. For messages to be transmitted to all MCCs, use SIT 605 format. For messages to be transmitted to specific MCCs, use SIT 915 format. Example of System Anomaly Message to all MCCs: /00001 00000/2270/94 123 1845 /605/xxx0 (where xxx is the MCC to which this message is transmitted) /SYSTEM ANOMALY NOTIFICATION MESSAGE (Include narrative text here to describe System anomaly concerning performance parameters, quality indicators, or calibration factors) /ENDMSG Example of System Anomaly Message to a specific MCC or Ground Segment Provider: /00001 00000/2270/94 123 1845 /915/3660 /SYSTEM ANOMALY NOTIFICATION MESSAGE (Include narrative text here to describe System anomaly concerning performance parameters, quality indicators, or calibration factors) /LASSIT /ENDMSG

D-2

LEOLUT AVAILABILITY STATUS MESSAGES 1.1 SIT 915 Warning Message [DATE: HHHH UTC, DD MONTH YEAR] FROM: XXMCC TO: YYMCC SUBJECT: LEOLUT AVAILABILITY STATUS WARNING MESSAGE

  1. IN ACCORDANCE WITH COSPAS-SARSAT QMS PLEASE BE ADVISED THAT THE FOLLOWING LEOLUT AND SATELLITE COMBINATION IS NOT MEETING THE REQUISITE AVAILABILITY CRITERION FOR THE 3 DAY PERIOD ENDING AT XXXX UTC, DD MONTH YEAR. LEOLUT [NAME & ID] AND SATELLITE [ID] [AVAILABILITY: XX PERCENT] LEOLUT [NAME & ID] AND SATELLITE [ID] [AVAILABILITY: XX PERCENT] ETC
  2. REQUEST A CHECK FOR THE CAUSE OF THE REDUCED AVAILABILITY. REGARDS 1.2 SIT 605 Status Message (Advising non-conformity) [DATE: HHHH UTC, DD MONTH YEAR] FROM: XXMCC TO: ALL MCCS SUBJECT: LEOLUT AVAILABILITY NON-CONFORMITY STATUS MESSAGE
  3. IN ACCORDANCE WITH COSPAS-SARSAT QMS PLEASE BE ADVISED THAT THE FOLLOWING LEOLUT AND SATELLITE COMBINATION(S) IS NOT MEETING THE REQUISITE AVAILABILITY CRITERION FOR THE 3 DAY PERIOD ENDING AT XXXX UTC, DD MONTH YEAR. LEOLUT [NAME & ID] AND SATELLITE [ID] LEOLUT [NAME & ID] AND SATELLITE [ID] ETC
  4. THE CORRESPONDING CHANGE HAS BEEN MADE TO THE C/S WEBSITE. REGARDS

D-3

1.3 SIT 605 Status Message (Advising return to normal operations) [DATE: HHHH UTC, DD MONTH YEAR] FROM: XXMCC TO: ALL MCCS SUBJECT: LEOLUT AVAILABILITY CONFORMITY STATUS MESSAGE

  1. IN ACCORDANCE WITH COSPAS-SARSAT QMS PLEASE BE ADVISED THAT THE FOLLOWING LEOLUT AND SATELLITE COMBINATION AVAILABILITY HAS RETURNED TO NORMAL AS OF DATE: XXXX UTC, DD MONTH YEAR. LEOLUT [NAME & ID] AND SATELLITE [ID] LEOLUT [NAME & ID] AND SATELLITE [ID] ETC.
  2. THE CORRESPONDING CHANGE HAS BEEN MADE TO THE C/S WEBSITE. REGARDS Note: Reference to XXMCC will be the nodal MCC supporting the MCC responsible for the LEOLUT.

D-4

GEOLUT AVAILABILITY STATUS MESSAGES 2.1 SIT 915 Warning Message [DATE: HHHH UTC, DD MONTH YEAR] FROM: XXMCC TO: YYMCC SUBJECT: GEOLUT AVAILABILITY STATUS WARNING MESSAGE

  1. IN ACCORDANCE WITH COSPAS-SARSAT QMS PLEASE BE ADVISED THAT THE FOLLOWING GEOLUT AND SATELLITE COMBINATION(S) IS NOT MEETING THE REQUISITE AVAILABILITY CRITERION FOR THE 1 DAY PERIOD ENDING AT XXXX UTC, DD MONTH YEAR. GEOLUT [NAME & ID] AND SATELLITE [ID] [AVAILABILITY: XX PERCENT] GEOLUT [NAME & ID] AND SATELLITE [ID] [AVAILABILITY: XX PERCENT] ETC
  2. REQUEST A CHECK FOR THE CAUSE OF THE REDUCED AVAILABILITY. REGARDS 2.2 SIT 605 Status Message (Advising non-conformity) [DATE: HHHH UTC, DD MONTH YEAR] FROM: XXMCC TO: ALL MCCS SUBJECT: GEOLUT AVAILABILITY NON-CONFORMITY STATUS MESSAGE
  3. IN ACCORDANCE WITH COSPAS-SARSAT QMS PLEASE BE ADVISED THAT THE FOLLOWING GEOLUT AND SATELLITE COMBINATION(S) IS NOT MEETING THE REQUISITE AVAILABILITY CRITERION FOR THE 1DAY PERIOD ENDING AT XXXX UTC, DD MONTH YEAR. GEOLUT [NAME & ID] AND SATELLITE [ID] GEOLUT [NAME & ID] AND SATELLITE [ID] ETC
  4. THE CORRESPONDING CHANGE HAS BEEN MADE TO THE C/S WEBSITE. REGARDS

D-5

2.3 SIT 605 Status Message (Advising return to normal operations) [DATE: HHHH UTC, DD MONTH YEAR] FROM: XXMCC TO: ALL MCCS SUBJECT: GEOLUT AVAILABILITY CONFORMITY STATUS MESSAGE

  1. IN ACCORDANCE WITH COSPAS-SARSAT QMS PLEASE BE ADVISED THAT THE FOLLOWING GEOLUT AND SATELLITE COMBINATION AVAILABILITY HAS RETURNED TO NORMAL AS OF DATE: XXXX UTC, DD MONTH YEAR. GEOLUT [NAME & ID] AND SATELLITE [ID] GEOLUT [NAME & ID] AND SATELLITE [ID] ETC
  2. THE CORRESPONDING CHANGE HAS BEEN MADE TO THE C/S WEBSITE. REGARDS Note: Reference to XXMCC will be the nodal MCC supporting the MCC responsible for the GEOLUT.

D-6

LEOLUT ACCURACY STATUS MESSAGES 3.1 SIT 915 Warning Message [DATE: HHHH UTC, DD MONTH YEAR] FROM: XXMCC TO: YYMCC SUBJECT: LEOLUT LOCATION ACCURACY STATUS WARNING MESSAGE

  1. IN ACCORDANCE WITH COSPAS-SARSAT QMS PLEASE BE ADVISED THAT THE FOLLOWING LEOLUT AND SATELLITE COMBINATION(S) IS NOT MEETING THE REQUISITE LOCATION ACCURACY CRITERION AT XXXX UTC, DD MONTH YEAR. LEOLUT [NAME & ID] AND SATELLITE [ID] [THE PERFORMANCE FOR THIS COMBINATION IS R.5: xx PERCENT, R.10: yy PERCENT ] LEOLUT [NAME & ID] AND SATELLITE [ID] [THE PERFORMANCE FOR THIS COMBINATION IS R.5: xx PERCENT, R.10: yy PERCENT ] ETC
  2. REQUEST A CHECK FOR THE CAUSE OF REDUCED LOCATION ACCURACY. REGARDS 3.2 SIT 605 Status Message (Advising Non-Conformity) [DATE: HHHH UTC, DD MONTH YEAR] FROM: XXMCC TO: ALL MCCS SUBJECT: LEOLUT LOCATION ACCURACY NON-CONFORMITY STATUS MESSAGE
  3. IN ACCORDANCE WITH COSPAS-SARSAT QMS PLEASE BE ADVISED THAT THE FOLLOWING LEOLUT AND SATELLITE COMBINATION IS NOT MEETING THE REQUISITE LOCATION ACCURACY CRITERION AS AT XXXX UTC, DD MONTH YEAR. LEOLUT [NAME & ID] AND SATELLITE [ID] [THE PERFORMANCE FOR THIS COMBINATION IS R.5: xx PERCENT, R.20: yy PERCENT] LEOLUT [NAME & ID] AND SATELLITE [ID] [THE PERFORMANCE FOR THIS COMBINATION IS R.5: xx PERCENT, R.20: yy PERCENT]
  4. THE CORRESPONDING CHANGES TO THE LOCATION ACCURACY AND AVAILABILITY STATUS HAVE BEEN MADE TO THE C/S WEBSITE AND DOPPLER

D-7

SOLUTION DATA FOR THE LEOLUT AND SATELLITE COMBINATION(S) IS (ARE) BEING SUPPRESSED AT THE NODAL MCC. 3. THE ASSOCIATED MCC SHALL SUPPRESS DOPPLER SOLUTION DATA FOR THE LEOLUT AND SATELLITE COMBINATION(S), EXCEPT FOR QMS DATA TO BE SENT TO THE NODAL MCC. THE ASSOCIATED MCC SHALL SEND A SIT 915 TO THE NODAL MCC WHEN SUPPRESSION IS TURNED ON. REGARDS 3.3 SIT 605 Status Message (Advising Return to Normal Operations) [DATE: HHHH UTC, DD MONTH YEAR] FROM: XXMCC TO: ALL MCCS SUBJECT: LEOLUT LOCATION ACCURACY CONFORMITY STATUS MESSAGE

  1. IN ACCORDANCE WITH COSPAS-SARSAT QMS PLEASE BE ADVISED THAT THE FOLLOWING LEOLUT AND SATELLITE COMBINATION LOCATION ACCURACY [AND AVAILABILITY] HAS RETURNED TO NORMAL AS AT XXXX UTC, DD MONTH YEAR. LEOLUT [NAME & ID] AND SATELLITE [ID] LEOLUT [NAME & ID] AND SATELLITE [ID] ETC
  2. THE CORRESPONDING CHANGE HAS BEEN MADE TO THE C/S WEBSITE AND DOPPLER SOLUTION DATA FORTHE ABOVE LEOLUT AND SATELLITE COMBINATION(S) IS/ARE NO LONGER BEING SUPPRESSED AT THE NODAL MCC.
  3. THE ASSOCIATED MCC SHALL RESUME THE DISTRIBUTION OF DOPPLER SOLUTION DATA PROVIDED BY THE ABOVE LEOLUT AND SATELLITE COMBINATION(S). THE ASSOCIATED MCC SHALL SEND A SIT 915 TO THE NODAL MCC WHEN DISTRIBUTION HAS RESUMED. REGARDS Note: Reference to XXMCC will be the nodal MCC supporting the MCC responsible for the LEOLUT.

D-8

MEOLUT ACCURACY STATUS MESSAGES 4.1 SIT 915 Message (Status Changed from Green+ or Green to Yellow) FROM: XXMCC TO: YYMCC SUBJECT: MEOLUT LOCATION ACCURACY NON-CONFORMITY YELLOW STATUS

  1. IN ACCORDANCE WITH COSPAS-SARSAT QMS PLEASE BE ADVISED THAT THE FOLLOWING MEOLUT IS NOT MEETING THE REQUISITE LOCATION ACCURACY CRITERION AS OF 0000 UTC, DD MONTH YEAR (REPORTING PERIOD END TIME). MEOLUT [NAME & ID] THE PERFORMANCE IS SINGLE BURST R.5: [xx] PERCENT, R.20: [xx] PERCENT MULTIPLE BURST R.5 [XX} PERCENT, R.20 [XX} PERCENT MEOLUT [NAME & ID] THE PERFORMANCE IS SINGLE BURST R.5: [xx] PERCENT, R.20 [XX] PERCENT MULTIPLE BURST R.5 [XX} PERCENT, R.20 [XX} PERCENT ETC
  2. THE C/S WEBSITE HAS BEEN UPDATED FOR THE STATUS CHANGE(S).
  3. REQUEST IDENTIFICATION OF THE CAUSE OF NON-CONFORMING LOCATION ACCURACY. REGARDS 4.2 SIT 605 Status Message (Status Changed to Red) FROM: XXMCC TO: ALL MCCS SUBJECT: MEOLUT LOCATION ACCURACY NON-CONFORMITY RED STATUS
  4. IN ACCORDANCE WITH COSPAS-SARSAT QMS PLEASE BE ADVISED THAT THE FOLLOWING MEOLUT IS NOT MEETING THE REQUISITE LOCATION ACCURACY CRITERION AS OF 0000 UTC, DD MONTH YEAR (REPORTING PERIOD END TIME). MEOLUT [NAME & ID] THE PERFORMANCE IS SINGLE BURST R.5: [xx] PERCENT, R.20: [xx] PERCENT MULTIPLE BURST R.5 [XX} PERCENT, R.20 [XX} PERCENT MEOLUT [NAME & ID] THE PERFORMANCE IS SINGLE BURST R.5: [xx] PERCENT, R.20 [XX] PERCENT MULTIPLE BURST R.5 [XX} PERCENT, R.20 [XX} PERCENT

D-9

ETC 2. THE C/S WEBSITE HAS BEEN UPDATED FOR THE STATUS CHANGE(S). DOA SOLUTION DATA FOR THE MEOLUT[S] IS (ARE) BEING SUPPRESSED AT THE NODAL MCC. 3. THE ASSOCIATED MCC SHALL SUPPRESS DOA SOLUTION DATA FOR THE MEOLUT, EXCEPT FOR QMS DATA TO BE SENT TO THE NODAL MCC. THE ASSOCIATED MCC SHALL SEND A SIT 915 TO THE NODAL MCC WHEN SUPPRESSION IS TURNED ON. 4. THE ASSOCIATED MCC IS REQUESTED TO IDENTIFY THE CAUSE OF NON- CONFORMING LOCATION PROBABILITY. REGARDS 4.3 SIT 605 Status Message (Status Changed from Red to Green+ or Green) FROM: XXMCC TO: ALL MCCS SUBJECT: MEOLUT LOCATION ACCURACY CONFORMITY STATUS

  1. IN ACCORDANCE WITH COSPAS-SARSAT QMS PLEASE BE ADVISED THAT LOCATION ACCURACY HAS RETURNED TO NORMAL FOR THE FOLLOWING MEOLUT AT 0000 UTC, DD MONTH YEAR (REPORTING PERIOD END TIME). MEOLUT [NAME & ID] MEOLUT [NAME & ID] ETC
  2. THE C/S WEBSITE HAS BEEN UPDATED FOR THE STATUS CHANGE(S). DOA SOLUTION DATA FOR THE MEOLUT[S] IS (ARE) NO LONGER BEING SUPPRESSED AT THE NODAL MCC.
  3. THE ASSOCIATED MCC SHALL RESUME THE DISTRIBUTION OF DOA SOLUTION DATA PROVIDED BY THE ABOVE MEOLUT(S). THE ASSOCIATED MCC SHALL SEND A SIT 915 TO THE NODAL MCC WHEN DISTRIBUTION HAS RESUMED. REGARDS 4.4 SIT 605 Message (Status Changed from Red to Yellow) FROM: XXMCC TO: ALL MCCS SUBJECT: MEOLUT LOCATION ACCURACY NON-CONFORMITY YELLOW STATUS (CHANGE FROM RED STATUS)
  4. IN ACCORDANCE WITH COSPAS-SARSAT QMS PLEASE BE ADVISED THAT THE FOLLOWING MEOLUT IS NOT MEETING THE REQUISITE LOCATION ACCURACY

D-10

CRITERION AS OF 0000 UTC, DD MONTH YEAR (REPORTING PERIOD END TIME), BUT IS NO LONGER IN THE RED STATUS. MEOLUT [NAME & ID] THE PERFORMANCE IS SINGLE BURST R.5: [xx] PERCENT, R.20: [xx] PERCENT MULTIPLE BURST R.5 [XX} PERCENT, R.20 [XX} PERCENT MEOLUT [NAME & ID] THE PERFORMANCE IS SINGLE BURST R.5: [xx] PERCENT, R.20 [XX] PERCENT MULTIPLE BURST R.5 [XX} PERCENT, R.20 [XX} PERCENT ETC 2. THE C/S WEBSITE HAS BEEN UPDATED FOR THE STATUS CHANGE(S). DOA SOLUTION DATA FOR THE MEOLUT[S] IS (ARE) NO LONGER BEING SUPPRESSED AT THE NODAL MCC. 3. THE ASSOCIATED MCC SHALL RESUME THE DISTRIBUTION OF DOA SOLUTION DATA PROVIDED BY THE ABOVE MEOLUT(S). THE ASSOCIATED MCC SHALL SEND A SIT 915 TO THE NODAL MCC WHEN DISTRIBUTION HAS RESUMED. 4. THE ASSOCIATED MCC IS REQUESTED TO IDENTIFY THE CAUSE OF NON- CONFORMING LOCATION PROBABILITY. REGARDS

D-11

MEOLUT LOCATION PROBABILITY STATUS MESSAGES 5.1 SIT 915 Message (Status Changed from Green to Yellow) FROM: XXMCC TO: YYMCC SUBJECT: MEOLUT LOCATION PROBABILITY NON-CONFORMITY YELLOW STATUS

  1. IN ACCORDANCE WITH COSPAS-SARSAT QMS PLEASE BE ADVISED THAT THE FOLLOWING MEOLUT IS NOT MEETING THE REQUISITE LOCATION PROBABILITY CRITERION AS OF 0000 UTC, DD MONTH YEAR (REPORTING PERIOD END TIME). MEOLUT [NAME & ID] THE PERFORMANCE IS SINGLE BURST: [xx] PERCENT, MULTI-BURST: [xx] PERCENT MEOLUT [NAME & ID] THE PERFORMANCE IS SINGLE BURST: [xx] PERCENT, MULTI-BURST: [xx] PERCENT ETC
  2. THE C/S WEBSITE HAS BEEN UPDATED FOR THE STATUS CHANGE(S).
  3. REQUEST IDENTIFICATION OF THE CAUSE OF NON-CONFORMING LOCATION PROBABILITY. REGARDS 5.2 SIT 605 Status Message (Status Changed to Red) FROM: XXMCC TO: ALL MCCS SUBJECT: MEOLUT LOCATION PROBABILITY NON-CONFORMITY RED STATUS
  4. IN ACCORDANCE WITH COSPAS-SARSAT QMS PLEASE BE ADVISED THAT THE FOLLOWING MEOLUT IS NOT MEETING THE REQUISITE LOCATION PROBABILITY CRITERION AS OF 0000 UTC, DD MONTH YEAR (REPORTING PERIOD END TIME). MEOLUT [NAME & ID] THE PERFORMANCE IS SINGLE BURST: [xx] PERCENT, MULTI-BURST: [xx] PERCENT MEOLUT [NAME & ID] THE PERFORMANCE IS SINGLE BURST: [xx] PERCENT, MULTI-BURST: [xx] PERCENT ETC
  5. THE C/S WEBSITE HAS BEEN UPDATED FOR THE STATUS CHANGE(S).
  6. THE ASSOCIATED MCC IS REQUESTED TO IDENTIFY THE CAUSE OF NON- CONFORMING LOCATION PROBABILITY. REGARDS

D-12

5.3 SIT 605 Status Message (Status Changed from Red to Green) FROM: XXMCC TO: ALL MCCS SUBJECT: MEOLUT LOCATION PROBABILITY CONFORMITY STATUS

  1. IN ACCORDANCE WITH COSPAS-SARSAT QMS PLEASE BE ADVISED THAT LOCATION PROBABILITY HAS RETURNED TO NORMAL FOR THE FOLLOWING MEOLUT AT 0000 UTC, DD MONTH YEAR (REPORTING PERIOD END TIME). MEOLUT [NAME & ID] MEOLUT [NAME & ID] ETC
  2. THE C/S WEBSITE HAS BEEN UPDATED FOR THE STATUS CHANGE(S). REGARDS 5.4 SIT 605 Message (Status Changed from Red to Yellow) FROM: XXMCC TO: ALL MCCS SUBJECT: MEOLUT LOCATION PROBABILITY NON-CONFORMITY YELLOW STATUS (CHANGE FROM RED STATUS)
  3. IN ACCORDANCE WITH COSPAS-SARSAT QMS PLEASE BE ADVISED THAT THE FOLLOWING MEOLUT IS NOT MEETING THE REQUISITE LOCATION PROBABILITY CRITERION AS OF 0000 UTC, DD MONTH YEAR (REPORTING PERIOD END TIME), BUT IS NO LONGER IN THE RED STATUS. MEOLUT [NAME & ID] THE PERFORMANCE IS SINGLE BURST: [xx] PERCENT, MULTI-BURST: [xx] PERCENT MEOLUT [NAME & ID] THE PERFORMANCE IS SINGLE BURST: [xx] PERCENT, MULTI-BURST: [xx] PERCENT ETC
  4. THE C/S WEBSITE HAS BEEN UPDATED FOR THE STATUS CHANGE(S).
  5. REQUEST IDENTIFICATION OF THE CAUSE OF NON-CONFORMING LOCATION PROBABILITY. REGARDS

D-13

MEOLUT DETECTION PROBABILITY STATUS MESSAGES 6.1 SIT 915 Message (Status Changed to Yellow or Red) FROM: XXMCC TO: YYMCC SUBJECT: MEOLUT DETECTION PROBABILITY NON-CONFORMITY [YELLOW or RED] STATUS

  1. IN ACCORDANCE WITH COSPAS-SARSAT QMS PLEASE BE ADVISED THAT THE FOLLOWING MEOLUT IS NOT MEETING THE REQUISITE DETECTION PROBABILITY CRITERION AS OF 0000 UTC, DD MONTH YEAR (REPORTING PERIOD END TIME). MEOLUT [NAME & ID] THE PERFORMANCE IS [xx] PERCENT, MEOLUT [NAME & ID] THE PERFORMANCE IS [xx] PERCENT, ETC
  2. THE C/S WEBSITE HAS BEEN UPDATED FOR THE STATUS CHANGE(S).
  3. REQUEST IDENTIFICATION OF THE CAUSE OF NON-CONFORMING DETECTION PROBABILITY. REGARDS

D-14

MEOLUT LOCAL ANTENNA AVAILABILITY STATUS MESSAGES 7.1 SIT 915 Message (Status Changed to Yellow or Red) FROM: XXMCC TO: YYMCC SUBJECT: MEOLUT LOCAL ANTENNA AVAILABILITY NON-CONFORMITY [YELLOW or RED] STATUS

  1. IN ACCORDANCE WITH COSPAS-SARSAT QMS PLEASE BE ADVISED THAT THE FOLLOWING MEOLUT IS NOT MEETING THE REQUISITE LOCAL ANTENNA AVAILABILITY CRITERION AS OF 0000 UTC, DD MONTH YEAR (REPORTING PERIOD END TIME). MEOLUT [NAME & ID] THE PERFORMANCE IS: [xx] PERCENT MEOLUT [NAME & ID] THE PERFORMANCE IS: [xx] PERCENT ETC
  2. THE C/S WEBSITE HAS BEEN UPDATED FOR THE STATUS CHANGE(S).
  3. REQUEST IDENTIFICATION OF THE CAUSE OF NON-CONFORMING LOCAL ANTENNA AVAILABILITY. REGARDS

D-15

MEOLUT TIMELINESS STATUS MESSAGES 8.1 SIT 915 Message (Status Changed to Yellow or Red) FROM: XXMCC TO: YYMCC SUBJECT: MEOLUT TIMELINESS NON-CONFORMITY [YELLOW or RED] STATUS

  1. IN ACCORDANCE WITH COSPAS-SARSAT QMS PLEASE BE ADVISED THAT THE FOLLOWING MEOLUT IS NOT MEETING THE REQUISITE TIMELINESS CRITERION AS OF 0000 UTC, DD MONTH YEAR (REPORTING PERIOD END TIME). MEOLUT [NAME & ID] THE PERFORMANCE IS: [xx] PERCENT MEOLUT [NAME & ID] THE PERFORMANCE IS: [xx] PERCENT ETC
  2. THE C/S WEBSITE HAS BEEN UPDATED FOR THE STATUS CHANGE(S).
  3. REQUEST IDENTIFICATION OF THE CAUSE OF NON-CONFORMING TIMELINESS. REGARDS

D-16

MEOLUT LOCATION EHE QUALITY STATUS MESSAGES 9.1 SIT 915 Message (Status Changed to Yellow or Red) FROM: XXMCC TO: YYMCC SUBJECT: MEOLUT QUALITY OF LOCATION EHE NON-CONFORMITY [YELLOW or RED] STATUS

  1. IN ACCORDANCE WITH COSPAS-SARSAT QMS PLEASE BE ADVISED THAT THE FOLLOWING MEOLUT IS NOT MEETING THE REQUISITE LOCATION EXPECTED HORIZONTAL ERROR (EHE) CRITERION AS OF 0000 UTC, DD MONTH YEAR (REPORTING PERIOD END TIME). MEOLUT [NAME & ID] THE PERFORMANCE IS: [xx] PERCENT MEOLUT [NAME & ID] THE PERFORMANCE IS: [xx] PERCENT ETC
  2. THE C/S WEBSITE HAS BEEN UPDATED FOR THE STATUS CHANGE(S).
  3. REQUEST IDENTIFICATION OF THE CAUSE OF NON-CONFORMING QUALITY OF LOCATION EHE. REGARDS
  • END OF ANNEX D -

E-1

ANNEX E PERFORMANCE MEASURES FOR THE COSPAS-SARSAT STRATEGIC PLAN Performance Measures are numbered by Goal and Objective e.g., PM 1.2 relates to Goal 1, Objective 2 PM 1.1 Performance Measure: Delivery of distress alerts to appropriate SPOCs Goal and Objective: Goal 1 - Continuous and Effective System Operations. Objective 1 - Deliver distress alerts to the appropriate SPOCs. Indicator: Percentage of monthly MCC to SPOC communication link tests that succeed. Rationale: Enables more effective coordination of SAR and helps to support IMO and ICAO SAR plans. Definitions: Appropriate SPOC means a SPOC that: • is identified based on SAR plans and in consultation with administrations, and • is listed in the data distribution plan. • “Success” means that at least one message sent to a SPOC by its associated MCC is acknowledged by the SPOC operator within 30 minutes. Tests are performed monthly. Metric(s): Percentage = the number of SPOCs with successful monthly communication tests with its associated MCC / the number of SPOCs tested. Data Collection Process: Results of monthly SPOC test are sent from the MCC to the Secretariat, using the format defined in document C/S A.003. The test results include an indication of whether the SPOC operator provided a manual acknowledgement of the message within 30 minutes. Reporting Schedule: The Secretariat reports annually to the Joint Committee, the Council, ICAO and IMO. Data Verification Process:

E-2

MCCs shall report test results in a database format to ensure that test results per communications path are tabulated properly. The Secretariat will review test results over time to look for reporting anomalies. Relevant Documents: C/S A.003, C/S A.001 and C/S A.002. Resources Required: Estimate about 4 hours per month per MCC to test and report on about 25 SPOC communication paths. (The time required will vary by MCC depending on number of SPOC communications paths to be tested.) This time estimate includes verification that new communications paths are added to the test and obsolete paths are removed from the test. Comments: /

E-3

PM 1.2 Performance Measure: LEOSAR Alert location accuracy Goal and Objective: Goal 1 - Continuous and Effective System Operations. Objective 2 - Maintain or improve location accuracy. Indicator: Percentage of Doppler solutions accurate to within 5 km. Rationale: Accurate locations reduce search time which allows more lives to be saved. Definitions: The indicator is based on the accuracy of all Doppler solutions provided by LEOLUTs for reference beacons as specified in C/S A.003. Metric(s): Percentage = number of Doppler locations within 5 km / total number of Doppler locations * 100. Data Collection Process: Data is sent by MCCs to the associated nodal MCC as part of QMS monitoring specified in document C/S A.003. Nodal MCCs report monthly or quarterly to the Secretariat in an Excel/database format, as below, for each LUT and satellite pair, the total number of Doppler locations and the number of Doppler locations within 5 km. DDR South West Pacific DDR Period 1 Jan 2013 to 31 Jan 2013 Beacons Longyearbyen & McMurdo Expected Number of Detections 28 x 31 = 868 (for two beacons) LEOLUT ID LUT Name Satellite Number of Detections Received Number of Detections within 5 km 5 km Accuracy Percentage Number of Detections Outside 5 km

Bundaberg S07

Bundaberg S08

…

Wellington S11

Wellington S12

… Reporting Schedule: Secretariat reports annually to Joint Committee and Council. Data Verification: Nodal MCC to ensure that the sample size for each LUT and satellite pair does not exceed the number of available passes.

E-4

Relevant Documents: C/S T.002 and C/S A.003. Resources Required: Nodal MCCs to develop an automated and/or manual procedure to extract required location accuracy data in an Excel/database format. Estimate about 4 days effort to develop an automated data extraction procedure and 2 hours quarterly for an analyst to provide the required data to the Secretariat. Comments: The summary data provided to the Secretariat can be reviewed by satellite (for all LUTs) and LUT (for all satellites) to identify long-term performance issues for specific satellites or LUTs.

E-5

PM 2.4 Performance Measure: Implementation status of QMS continuous monitoring processes Goal and Objective: Goal 2 - A Comprehensive Management Structure to Support System Evolution and Ensure Program Continuity. Objective 4 - Establish a Quality Management System. Indicator: Percentage of Ground Segment Providers that have successfully implemented QMS continuous monitoring. Rationale: The implementation of QMS continuous monitoring processes is a key element in accomplishing the Cospas-Sarsat quality objective to ensure Cospas-Sarsat consistently provides accurate, timely and reliable distress alert and location information to search and rescue authorities. QMS monitoring allows Cospas- Sarsat to automatically assess the performance status of LUTs and MCCs, thereby encouraging higher performance standards and the full implementation of other QMS requirements. Definitions: To be counted as having “Successfully implemented the QMS continuous monitoring processes,” a Ground Segment provider must ensure that the required data as defined in C/S A.003 for their LUT(s) and MCC, is regularly and reliably transmitted to the appropriate nodal MCC. In addition, a nodal MCC must collect and analyze data to determine the status of a Ground Segment component (LUT or MCC) as specified in C/S A.003, and report results on the QMS status board on the website. Metric(s): The number of MCCs routinely providing QMS continuous monitoring results on the QMS status board, divided by the total number of MCCs at FOC status. Data Collection Process: Data is obtained through observation of the QMS status board on the website. Reporting Schedule: Secretariat reports on an annual basis to Council. Data Verification and Validation Process: Not applicable. Relevant Documents: C/S A.003, C/S P.015 and C/S A.005. Resources Required: Approximately 2 hours annually for the Secretariat to complete the report. Comments: /

E-6

PM 4.3 Performance Measure: Cospas-Sarsat assisted SAR events Goal and Objective: Goal 4 - Participants, Users and Customers use and operate the System to its full potential. Objective 3 - Ensure Participants’ awareness of the System and Programme to realize their full potential. Indicators: 1. Number of SAR events annually where Cospas-Sarsat assisted. 2. Number of SAR events annually where Cospas-Sarsat provided the only alert. Rationale: Cospas-Sarsat’s purpose is to assist in the saving of lives; this measure is directly related to that purpose. Rescue of persons in distress is a critical concern of Cospas-Sarsat’s stakeholders, customers and users. Therefore, this measure will demonstrate the relevance of the Cospas-Sarsat System. Definitions: A Cospas-Sarsat assisted event is defined as any situation in which persons are in distress, and SAR authorities acknowledged that the Cospas-Sarsat System assisted SAR operations by providing the only alert, first alert or supporting data in that SAR event. Cospas-Sarsat provided the only alert is defined as any situation in which persons are in distress, and SAR authorities acknowledged that the Cospas-Sarsat System provided the only alert. Metric(s): Number of SAR events reported annually by MCCs where Cospas-Sarsat provided assistance. Number of SAR events reported annually by MCCs where Cospas-Sarsat provided the only alert. Data Collection Process: Based on feedback provided by SAR authorities, MCCs report the number of SAR events to the Secretariat on a quarterly basis. Reporting Schedule: The Secretariat reports annually to the Joint Committee, Council, IMO and ICAO. Data Verification Process: MCCs should verify data provided by SAR authorities. The Secretariat distributes a draft of the annual report at the JC and asks for comments. MCCs should then check their own numbers in conjunction with SAR events map. Relevant Documents:

E-7

C/S A.003 and C/S R.007. Resources Required: Reporting procedure is already in place and data are available in the Annual Report on System Status and Operations. Comments: Most of this data will be collected by agencies that are not a part of the Cospas- Sarsat System. – END OF ANNEX E –

F-1

ANNEX F DATA COLLECTION FOR ANALYSIS OF 406 MHz BEACON MESSAGE PROCESSING ANOMALIES Reporting Period (DD Month YY – DD Month YY):

Reporting MCC:

Total number of processed messages (NNNNN):

Number of single point LEOSAR message processing anomalies:

Number of MEOSAR message processing anomalies:

Number of GEOSAR message processing anomalies:

Number of single point LEOSAR processing anomalies filtered:

Number of MEOSAR processing anomalies filtered:

Number of GEOSAR processing anomalies filtered:

The tabular structure outlined below can be used to assist Ground Segment operators track the data required to derive the number of processed messages, processing anomalies and filtered processing anomalies to be reported (see above). This table, if used, would provide a foundation for more detailed analysis if required. Along with this table, the following data may be useful in analysing LEOSAR message processing anomalies: a) Calculated Doppler location for both A and B solutions; b) Bias frequency as measured by the LEOLUT and/or GEOLUT; c) LUT solution data, including time, frequency of data points used; d) Dot plots; e) Beacon information : • beacon manufacturer and model, • beacon transmit frequency, • beacon EIRP and antenna characteristics; and f) Characterisation data/analysis conducted on interferers and the event. Along with this table, the following data may be useful in analysing MEOSAR message processing anomalies: a) Calculated DOA location for this solution; b) Beacon frequency as measured by the MEOLUT; c) LUT solution data, including time, frequency of data points used; d) Dot plots (if available); e) Beacon information: • beacon manufacturer and model,

F-2

• beacon transmit frequency, • beacon EIRP and antenna characteristics, f) Characterisation data/analysis conducted on interferers and the event. 1Table F.1: Data Collection for Analysis of 406 MHz Beacon Message Beacon Message Received Beacon Message Transmitted No of Points/ Integration LUT Satellite Processing Channels Day and Time of Beacon Msg received Visibility Time (LEO) MCC Ref No Reason for not Passing MCC Validation Location Data, Lat Location Data, Long Number of Corrected Errors in the Message Approx Power (dBm) Approx C/N0 (dB) Cause Message Filtered

2*

9*

11* 12* 13* 14* 15* 16* 17* 30 Hex 30 Hex nn nnnn S,C,G,I n1) Hr/Min/ Year/ Month/ Day min nnnn n2) nnnn (+=N, -=S) nnnnn (+=E, -=W) 0/1/2 nn nn a3) Y/N Note: * represents optional fields in the table Table Entry Codes 1)

SARP

SARR

MEOSAR

GEOSAR 2)

Passed MCC validation

Country code <200, >780, or unallocated country code between 200 and 780

Protocol code

Baudot characters

Binary coded decimal fields

Encoded latitude and longitude

Beacons whose message indicate the use of SART 9 GHz homer#

Non-assigned Cospas-Sarsat type approval number

Wrong BCH

Other nationally defined

Supplementary data bits 3) H High bit error rate C Synchronisation errors I Interference L LUT not performing to specification S Satellite payload instruments not performing to specification B Beacon not performing to specification M MCC not performing to specification # At the time that this table was created there were no Cospas-Sarsat type approved beacons which used the 9 GHz SART transponder as their only homing device. Consequently, at least one MCC filters alert messages which indicate that this type of beacon is used.

  • END OF ANNEX F -

G-1

ANNEX G COLLECTING AND REPORTING DATA FOR SAR EVENT ANALYSIS 1. PROCEDURE FOR COLLECTING COSPAS-SARSAT DATA ON SAR INCIDENTS The Cospas-Sarsat Council agreed the following procedure for collecting Cospas-Sarsat data on particular SAR incidents (see CSC-15/SR Annex 5). Further rationale for conducting SAR analyses can be found in section entitled “Quality Management System Review” of document C/S P.015 “Cospas-Sarsat Quality Manual”. 1.1 Any Representative of a Cospas-Sarsat Participating Country with direct interest in a particular SAR incident, or representatives from international organisations with responsibilities on SAR matters (ICAO and IMO), may discuss with the Chair of the Council, either directly or through the Secretariat, the need for collecting data concerning particular SAR incidents from one or several Ground Segment operators. 1.2 Administrations from countries not participating in the Cospas-Sarsat System should address any requests for Cospas-Sarsat data on SAR incidents to one of the Cospas-Sarsat Ground Segment Providers, ICAO or IMO. Any such request should be conveyed immediately to the Chairperson of the Council, directly or through the Secretariat. 1.3 The Council Chair, if satisfied that it would be appropriate, will instruct the Secretariat to ask the appropriate MCC operators to provide the required data. 1.4 The Secretariat will collate all relevant data provided by the Cospas-Sarsat MCCs. 1.5 The Council Chair, after consultation with other Parties' Representatives, will establish an ad-hoc group of experts from the MCC operators involved. The group will analyse the available Cospas-Sarsat data, either by correspondence or as a splinter group during a regular Cospas-Sarsat meeting. They will forward their conclusions to the Secretariat for distribution to, and consideration by, the Parties and the MCC operators involved. 1.6 Their conclusions /recommendations shall be reviewed by the Council (or by the Parties if the matter is urgent) along with any further comments from the MCC operators involved The Chair of the Council will direct the Secretariat on the release of the collected Cospas- Sarsat incident data, the conclusions of the analysis by the Cospas-Sarsat experts and/or any official Cospas-Sarsat comments, to the requesting Cospas-Sarsat Participant or the responsible international organisation (ICAO or IMO), as appropriate.

G-2

DATA TO BE COLLECTED AND REPORTED A general description of the data to be provided to the Secretariat for SAR event analysis is included below. All data is to be provided as available in the specific Ground Segment equipment, when possible, the data should be provided in an electronic format, preferably as comma delimited text files or Microsoft Access database tables, accompanied by a description of the data format provided. The information described in the following paragraphs should be provided, to the extent that such data is available that may relate to the event or beacon(s) of interest: 2.1 General a) status of all associated Ground Segment equipment during the time of the event, including the status as declared under QMS; b) status of all Space Segment equipment during the time of the event (Space Segment Providers); c) throughput and accuracy of data from orbitography beacons (France, USA, and others as possible) during the time of the event; d) 15 character beacon hexadecimal identification(s) for all beacon(s) that may be associated with the SAR event; e) list of other SAR incidents detected/reported during the time period of analysis f) all available information about interference detected during the time period of analysis. 2.2 MCC Data a) input and output messages that relate to the specific beacon ID(s) of interest, received from or sent to other MCCs; b) formatted input from any associated LEOLUT, MEOLUT, or GEOLUT; and c) registration information for the beacon(s) of interest, including that the beacon was not registered, if applicable. 2.3 LEOLUT Data a) pass schedule and tracking result summary for requested period; b) dot plots, as available, (.bmp, .jpg, or .pcx formats if possible) for LEOLUTs capable of local-mode reception of beacon associated with SAR event; and c) solution information such as time of data points received and used, as available.

G-3

2.4 MEOLUT Data a) satellite tracking schedule and the satellite pass log for the requested period (in the format shown in Table G.1); b) raw data for the requested period for all beacons of interest (in the format shown in Table G.2); c) solution data for all beacons of interest (in the format shown in Table G.3); and d) dot plots, as available, (.bmp, .jpg, or .pcx formats if possible) for MEOLUT channels capable of reception of data relayed from beacon associated with the SAR event of interest. 2.5 GEOLUT Data a) time of first and last detection for specific beacon ID; b) average frequency bias of beacon transmissions; and c) any noted anomalies or irregularities with beacon transmission or processing. 2.6 Additional LUT Data If any of the following data is available from the LEOSAR, GEOSAR or MEOSAR systems, it should also be provided. a) the frequency and time measurement of each beacon burst provided by the SARR and SARP channels, whether or not a beacon message is decoded and validated; b) the beacon power measurement for each beacon burst provided by the SARP channel, whether or not a beacon message is decoded and validated; c) the C/No ratio for each beacon burst provided by the SARR channel, whether or not a beacon message is decoded and validated; d) the beacon locations and related solution data calculated by the LUT, whether or not a beacon message is decoded and validated; e) the satellite orbit vectors, and time calibration (TCAL) settings used in the processing of the above data; f) the solution data for all 406 MHz signals detected, whether interferers, or partial or corrupted beacon bursts; g) power spectrum data for 406 MHz signals detected by the LUT, whether interferers, or partial or corrupted beacon bursts; and h) the log files that capture the status of the LUT during the time period that the LUT tracked the satellite.

G-4

1Table G.1: Satellite Pass Log LUT ID Antenna ID Sat ID AOS_Time (Acquisition of Signal) (UTC) LOS_Time (Loss of Signal) (UTC) Duration (minutes) Azimuth at AOS (deg) Elevation at AOS (deg) Azimuth at LOS (deg) Elevation at LOS (deg)

yyyy-mm-dd hh:mm:ss.x yyyy-mm-dd hh:mm:ss.x xxx.xx xxx.x xx.x xxx.xx xx.x 2Table G.2: Satellite Pass Log Burst number (as collected) Raw/ Full 36 Hex message Beacon Hex ID Time of beacon burst received (UTC) FOA (Hz) Freq Offse t (Hz) TOA (UTC) Time Offset (sec) C/N0 (dB/Hz) Bit rate (bps) Antenna ID Sat ID Satellite Position Satellite Velocity Correction (normalization) value (dB) Px Py Pz Vx Vy Vz yyyy-mm-dd hh:mm:ss.x yyyy-mm-dd hh:mm:ss.x 3Table G.3: Satellite Pass Log Time stamp of first burst used for location (UTC) Time stamp of last burst used for location (UTC) Time of location computation (UTC) Beacon Hex ID Number of bursts used8 Data used T/F/D Antenna IDs Number of packets used to compute location Number of satellites tracked Sat IDs DOP (*) JDOP (*) Quality factor (0-999) Location methodology Lat (deg) Long (deg) Error (km)

  • END OF ANNEX G -

H-1

ANNEX H REPORTING OF MCC/SPOC COMMUNICATION TEST NOTE: Please submit by email as an MS Access document to mail@cospas-sarsat.int. An MS Access template is available at www.cospas-sarsat.org 4Table H.1: Monthly Report on Success of MCC Messages Sent to SPOCs

  • END OF ANNEX H -

Image 1 from page 153

I-1

ANNEX I COSPAS-SARSAT GROUND SEGMENT SYSTEM TEST The following System test will be conducted to help confirm the operational status of commissioned LEOLUTs, MEOLUTs, GEOLUTs and MCCs in the Cospas-Sarsat System. Expected MEOLUT processing results are not currently analysed. Expected MCC processing results do not reflect the impact of MEOSAR data or modifications to MCC processing rules for LGM MCCs, unless noted otherwise. Table I.1 identifies the test messages that will be transmitted by a beacon signal simulator generator or test beacon. Operational beacons are used to allow LEOLUTs, GEOLUTs and MCCs to automatically transmit specific data through the System without requiring modifications. A country is specified under the column “Test Bcn” when the test requires that the message be transmitted from a specific geographical location. For LEOSAR testing a single LEOSAR satellite shall be used for receiving all test signals. The satellite selected shall have a fully functional SARP and SARR. Table I.2 identifies expected LEOLUT and MCC processing and Table I.4 identifies the expected MCC message distribution based on the solutions produced by LEOLUTs, with no MEOLUT or GEOLUT data being available to the MCC. Table I.3 identifies possible GEOLUT and MCC processing, assuming no LEOLUT or MEOLUT data being available at the MCC. MCC processing may differ from the results depicted in these Tables and still conform to Cospas- Sarsat specifications in some conditions, including the following: • Data for a specific test is reported to the MCC from another satellite prior to the expected satellite (e.g., GEOSAR or MEOSAR data is reported prior to expected LEOSAR data). • Global data is processed by the MCC in a different order than it was transmitted, for a series of tests involving the same beacon ID. • Combined LEO/GEO processing generates a Doppler location from two (2) transmitted bursts. • LGM MCC processing differs from expected MCC processing based on rules for LEOSAR/GEOSAR (LG) only MCCs (e.g., LGM MCCs continue to send alerts after position is confirmed while LG only MCCs filter alerts once ambiguity is resolved.) In such instances the Ground Segment operator should analyse the MCC output to confirm MCC processing. GEOLUT processing might differ from the information presented in Table I.3 and still conform to Cospas-Sarsat specifications in the following conditions: Multiple uplink bursts for a specific test do not result in confirmed beacon messages, due to the nature of the GEOLUT integration process.

I-2

The uplinked data for a specific test is outside the footprint of the GEOSAR satellite tracked by a GEOLUT (e.g., a GEOLUT tracks GOES-West, which can not detect data uplinked from Toulouse). A GEOLUT sends invalid data to the MCC in accordance with section “Beacon Message Processing” of document C/S T.009. In such cases the GEOLUT operators should analyse the received results to evaluate their correctness. The Test Coordinator may change the country codes used to test SSAS beacons, provided that: • the Test Coordinator submits the proposed country code changes prior to the Joint Committee meetings along with the resultant changes to Tables I.1 through I.4 of document C/S A.003, Annex I, • there is at least one country represented from each Data Distribution Region (DDR), • both the countries that are affected by the change and their host nodal MCC agree to the proposed change during the test planning phase, • all MCCs are notified of the changes prior to the test and are provided with a list of the new 406 beacon messages that will be used, and • all MCCs are provided with changes to Tables I.1 through I.4 that apply for that test.

I-3

Table I.1: List of 406 MHz Test Messages to be Generated by Beacon Simulator to Support System Level Test Ref. Num Test Bcn (Pass) Date/ Time Transmitted 30 Hex Code; Default 15 Hex Id, bits 26-85 (9 bit Frame Synchronisation) Number of Bursts; Transmit Freq. Comments

(1) TBD CC7478A69A69A68C0D498FE0FF0F61 98E8D34D34D34D1

406.025 Test Objectives : LUT, MCC beacon message validation. Two (2) bit errors at bits 44, 48. Invalid country code.

(1) TBD 96E9B93089C14CDE5215B781000D6D 2DD37261138299B

406.025 Test Objectives : LUT, MCC beacon message validation. Spare protocol code in bits 37-40.

USA (1) TBD 96EA0000D8894D7CAD91F79F3C0010 2DD40001BF81FE0

406.025 Test Objectives: LUT, MCC beacon message validation. USA National Location Protocol coded beacon with invalid encoded position in PDF-1 and default encoded position in PDF-2.

USA (1) TBD 56E30E1A4324920310DBC000000000 ADC61C348649240

406.025 Test Objectives: LUT, MCC beacon message validation. 4 bit errors in BCH-1 (bits 103-106). LUT filtering bad points for Doppler processing. 56E30E1A4324920310DBC000000000

406.029 Same Id as above. Frequency changed. 56E30E1A4324920310DBC000000000

406.025 Same Id as above. Frequency changed. 56E30E1A4324920310DBC000000000

406.029 Same Id as above. Frequency changed. 56E30E1A4324920310DBC000000000

406.025 Same Id as above. Frequency changed.

USA (1) TBD 96E20000007FDFFC4AE03783E0F66C 2DC4000000FFBFF

406.025 Test Objectives: MCC.Processing. USA EPIRB with Doppler position in Greenbelt, no encoded position.

Image 1 from page 156

I-4

Ref. Num Test Bcn (Pass) Date/ Time Transmitted 30 Hex Code; Default 15 Hex Id, bits 26-85 (9 bit Frame Synchronisation) Number of Bursts; Transmit Freq. Comments

FRANCE (2) TBD 96E20000002B803713C8F78E010D07 2DC4000000FFBFF

406.025 Test Objectives: LEO/GEO LUT combined processing. MCC Processing. USA EPIRB with Encoded position in Toulouse, no Doppler position. 96E20000002B803713C8F78E010D07

406.026 Same Id as above. Frequency changed.

USA (3) TBD 96E200000027299899463701261BF1 2DC4000000FFBFF

406.025 Test Objectives: MCC Ambiguity Resolution. USA EPIRB with Encoded position in Greenbelt, no Doppler position.

USA (4) TBD 96E200000026A99CDA28B780230987 2DC4000000FFBFF

406.025 Test Objectives: MCC Post Ambiguity Resolution. USA EPIRB with Encoded position near Greenbelt, no Doppler position.

FRANCE (1) TBD 8E340000002B803231B3F68C421815 1C68000000FFBFF

406.028 Test Objectives: LUT Beacon Message Processing, MCC Ambiguity Resolution. French ELT with Encoded and Doppler positions in Toulouse. Encoded position is (43.551, 1.466). 8E340000002B803231B3F68E011E5C 1C68000000FFBFF

406.028 Encoded position updated to (43.559, 1.482).

FRANCE (2) TBD 8E3401000026A999F853B683E0F00E 1C68000000FFBFF

406.028 Test Objectives: LUT Beacon Message Processing, MCC Post Ambiguity Resolution. French ELT with Encoded position in Greenbelt and Doppler position in Toulouse. Default encoded position in PDF-2. Encoded position (38.50, 76.75) is outside the LEO satellite footprint. One (1) bit error at bit 48 in PDF-1. 8E3401000027299DBB3D3601261D99 1C68000000FFBFF

406.028 Encoded position updated to (38.996, 76.851.) One (1) bit error at bit 48 in PDF-1 and two (2) bit errors at bits 141 and 143 in BCH-2. 8E3401000027299DBB3D3601261D93 1C68000000FFBFF

406.028 One (1) bit error at bit 48 in PDF-1.

I-5

Ref. Num Test Bcn (Pass) Date/ Time Transmitted 30 Hex Code; Default 15 Hex Id, bits 26-85 (9 bit Frame Synchronisation) Number of Bursts; Transmit Freq. Comments

(1) TBD 8E361100007FDFFDD859F683E0FC0E 1C6C000000FFBFF

406.025 Test Objectives: LUT beacon message validation, MCC no Doppler processing. French EPIRB with default encoded position in PDF-1. No Doppler or encoded position present. Two (2) bit errors at bits 44 and 48 in PDF-1. Two (2) bit errors at bit 133 and 134 in BCH-2. 8E360011107FDFFDD859C600000075 1C6C000000FFBFF

406.025 Three (3) bit errors at bits 52, 56 and 60 in PDF-1. Fixed bits 107-110 are invalid.

FRANCE (2) TBD 8E360000002B80368171368E011E5C 1C6C000000FFBFF

406.025 Test Objective: MCC Encoded position processing. Encoded position in Toulouse.

USA (3) TBD 4E360000007FDFFFDCAB7683E0F00E 9C6C000000FFBFF

406.025 Test Objectives: LUT Doppler processing beacon validation, MCC Position Conflict and three point Doppler processing. Doppler position in Greenbelt. Short message with no errors and superfluous data in bits 113 – 144. 4E360000007FDFFFDCAB7683E0F00E 9C6C000000FFBFF

406.025 Short message with superfluous data in bits 113 – 144.

FRANCE (4) TBD 8E360000007FDFFDD859D683E0FE29 1C6C000000FFBFF

406.025 Test Objective: MCC beacon message validation, beacon message matching and Ambiguity Resolution. MCC should use Doppler position to resolve ambiguity despite an error in fixed bit 107. The standard location protocol beacon message does not conform to fixed bit requirements (bits 107 – 110). Doppler position in Toulouse.

USA (1) TBD 96E8000007815201C84BB4810007CB 2DD000003F81FE0

406.037 Test Objective: LUT beacon message validation. MCC Position Conflict Processing. Doppler position in Greenbelt, encoded position in Florida (30, -82). Complete confirmed beacon message. 96E8000007815201C84BB4810F0255 2DD000003F81FE0

406.037 Encoded position updated to (30, -82.003). 96E8000007815201C84BB4810F0241 2DD000003F81FE0

406.037 Two (2) bit errors at bits 140 and 142 in BCH-2. 96E8000007815201C84BB4810F0253 2DD000003F81FE0

406.037 Two (2) bit errors at bits 142 and 143 in BCH-2.

I-6

Ref. Num Test Bcn (Pass) Date/ Time Transmitted 30 Hex Code; Default 15 Hex Id, bits 26-85 (9 bit Frame Synchronisation) Number of Bursts; Transmit Freq. Comments

USA (2) TBD 96E8000007815201C84BB4810007CB 2DD000003F81FE0

406.037 Test Objective : LUT beacon message validation. MCC Ambiguity Resolution. Doppler position in Greenbelt, encoded position in Florida (30, -82). Complete confirmed beacon message. 96E8000007815201C84BB4810F0255 2DD000003F81FE0

406.037 Encoded position updated to (30, -82.003).

(1) TBD D6E10E1A4324920458B9D555555555 ADC21C348649240

406.022 Test Objective: MCC beacon message validation. USA Orbitography beacon with a pattern of “01” in the long message. No bit errors.

(1) TBD 96E400000026E9985C84F683E0F00E 2DC8000000FFBFF

406.025 Test Objective: LUT beacon message validation. USA Standard Location Protocol ELT with encoded position (38.750, -76.750) in PDF-1 and PDF-2. Three (3) bit errors at bits 88, 96 and 104 in BCH-1. 96E411110026E9995D85F683E0F00E 2DC8000000FFBFF

406.027 USA Standard Location Protocol ELT with encoded position (38.750, -76.750) in PDF-1 and PDF-2. Four (4) bit errors at bits 44, 48, 52 and 56 in PDF-1. 96E411101026E9995D85F683E0F00E 2DC8000000FFBFF

406.025 USA Standard Location Protocol ELT with encoded position (38.856,-76.750) in PDF-1 and PDF-2. Four (4) bit errors at bits 44, 48, 52 and 60 in PDF-1.

(1) TBD 8E38540009B54CE1D106371408066B 1C7000003F81FE0

406.025 Test Objective: LUT beacon message validation. French National Location Protocol ELT with encoded position (38.856, -76.931). Three (3) bit errors at bits 42, 44 and 46 in PDF-1.

(1) TBD D6E6C0000000000A7E0CAFE0FF0146 ADCD80000000001 (0 1101 0000)

406.027 Test Objective: LUT beacon message validation for LUTs in local coverage area of test beacon. USA Serialized User Aircraft Address coded beacon with no encoded position. The last 8 bits of the frame synchronization are inverted.

I-7

Ref. Num Test Bcn (Pass) Date/ Time Transmitted 30 Hex Code; Default 15 Hex Id, bits 26-85 (9 bit Frame Synchronisation) Number of Bursts; Transmit Freq. Comments

FRANCE (1) TBD 96EB0000492E031219DC370D300F1D 2DD60000BF81FE0

406.017 Test Objective: LUT beacon message processing, Doppler processing with bad frequency. MCC distribution based on encoded position. USA National Location Protocol PLB with encoded position (36.76; 3.08) in Algeria. 96EB0000492E031219DC370D300F1D 2DD60000BF81FE0

406.022 Same Id as above. Frequency changed. 96EB0000492E031219DC370D300F1D 2DD60000BF81FE0

406.027 Same Id as above. Frequency changed. 96EB0000492E031219DC370D300F1D 2DD60000BF81FE0

406.032 Same Id as above. Frequency changed.

USA (1) BFC0270F000002CA2F4015FFFFFFFE 7F804E1E0000059

406.022 Test Objective: MCC beacon message validation. Doppler position in Greenbelt. Multiple invalid beacon messages which decode as an orbitography beacon.

FRANCE (1) TBD ABDCF423F0A1C2520276F69F400819 57B9E847E0FFBFF

406.037 Test Objective: SSAS Processing Argentina Country Code - Doppler position in Toulouse, encoded position in South Africa (- 33.881, 18.500).

FRANCE (1) TBD A37C5161502B4036D69136CA420129 46F8A2C2A0FFBFF

406.037 Test Objective: SSAS Processing – Thailand Country Code - Doppler position in Toulouse, encoded location in Toulouse.

FRANCE (1) TBD 99CCBDE3102BC03083033630822F69 33997BC620FFBFF

406.037 Test Objective: SSAS Processing – China Country Code – Doppler Position in Toulouse, encoded location in the Toulouse.

USA (1) TBD A5DCA2C2A098D3095DCB7681E9B0B3 4BB9458540FFBFF

406.037 Test Objective: SSAS Processing Algeria Country Code - Doppler in USA, encoded location in Australia (-24.758, 152.412).

USA (1) TBD 8F4C87A23026E99AB3EC36BAE6A5B7 1E990F4460FFBFF

406.037 Test Objective: SSAS Processing – the Netherlands Country Code - Doppler Position in USA, encoded location in USA.

USA (1) TBD 911C6C81C026E99DAF0F3696258F9E 2238D90380FFBFF

406.037 Test Objective: SSAS Processing Russia Country Code - Doppler Position in USA, encoded location in USA.

I-8

5Table I.2: Expected LEOLUT and MCC Processing for System Level Test Ref. Num Message to be Transmitted by LEOLUT (Default 15 Hex Id, bits 26-85) Doppler Position Encoded Position Comments

CC7469A69A69A68C0D498FFFFFFFFF (98E8D34D34D34D1) n/a n/a LEOLUT corrects two bit errors and sends corrected message to MCC. Bits 113 to 144 are set to all “1" because PDF- 2 is not confirmed. MCC Action code: Sw0 + Invalid Data -> Aw0. MCC suppresses message distribution because the country code is invalid and there is only one burst (see note 1).

96E9B93089C14CDE5215B7FFFFFFFF 2DD37261138299B n/a 39.000 N 76.900 W LEOLUT sends unconfirmed complete message with bits 113 - 144 all set to 1 to MCC. MCC Action code: Sw0 + Invalid Data -> Aw0. MCC suppresses message distribution due to spare protocol code (see note 1).

96EA0000D8894D7CAD91F79F3C0010 (2DD40001BF81FE0) 38.995 N 76.851 W 98.123 N 77.500 W LEOLUT sends confirmed complete message to MCC. MCC Action code: Sw0 + I2 -> Aw2. MCC sends SIT 125 alert based on the “A” and “B” Doppler positions. Even though the encoded position is invalid there are two or more points available for processing (see notes 1).

56E30E1A4324920310DBC0FFFFFFFF (ADC61C348649240) 38.995 N 76.851 W n/a LEOLUT sends invalid confirmed message with bits 113 - 144 all set to 1 to MCC. MCC ignores bits beyond short message. MCC Action code: Sw0 + I2 -> Aw2. MCC sends SIT 125 alert based on the “A” and “B” Doppler positions. Even though there are 4 bit errors in the message there are two or more matching points available for processing (see note 2).

96E20000007FDFFC4AE03783E0F66C (2DC4000000FFBFF) 38.995 N 76.851 W n/a LEOLUT sends confirmed complete message to MCC. MCC Action code: Sw0 + I2 -> Aw2. MCC sends SIT 125 alert based on the “A” and “B” Doppler positions.

96E20000002B803713C8F78E010D07 (2DC4000000FFBFF) n/a 43.559 N 1.483 E LEOLUT sends confirmed complete message to MCC. Frequency difference between the two points prevents combined LEO/GEO LUT processing. MCC Action code: Sw2 + I3 -> Aw4. MCC sends SIT 123 alert based on the encoded position (see notes 3 and 4).

96E200000027299899463701261BF1 (2DC4000000FFBFF) n/a 38.995 N 76.851 W LEOLUT sends confirmed complete message to MCC. MCC Action code: Sw4 + I3 -> Aw7. MCC sends SIT 124 alert based on the match of the encoded position and previous Doppler position (see notes 3 and 4).

96E200000026A99CDA28B780230987 (2DC4000000FFBFF) n/a 38.500 N 76.800 W LEOLUT sends confirmed complete message to MCC. MCC Action code: Sw7 + I3 -> Ct0. MCC filters this alert because ambiguity has been resolved (see notes 3 and 4). MCC should also note the position conflict to previous locations.

8E340000002B803231B3F68E011E5C (1C68000000FFBFF) 43.559 N 1.482 E 43.559 N 1.482 E LEOLUT sends updated, confirmed complete message for Standard Location Protocol beacon to MCC. MCC Action code: Sw0 + I7 -> Aw7. MCC sends SIT 127 alert based on the match of the encoded and Doppler positions (see notes 3 and 4).

8E3400000027299DBB3D36FFFFFFFF (1C68000000FFBFF) 43.559 N 1.482 E 39.000 N 76.750 W (invalid) LEOLUT sends valid long message to MCC; however, bits 113 to 144 are set to all “1" because PDF-2 is not confirmed. The encoded position is invalid because it is outside the LEO satellite footprint (see note 5). MCC Action code: Sw7 + I2--> Ct0. LG only MCC filters this alert because ambiguity has been resolved.(see notes 3 and 4).

I-9

Ref. Num Message to be Transmitted by LEOLUT (Default 15 Hex Id, bits 26-85) Doppler Position Encoded Position Comments

8E360000007FDFFDD859F6FFFFFFFF (1C6C000000FFBFF) n/a n/a LEOLUT corrects beacon message from burst number one and sends corrected valid message to MCC, however, bits 113 to 144 are set to all “1" because PDF-2 is not confirmed. MCC Action code: Sw0 + I1 -> Aw1. MCC sends SIT 122 alert based on the country code of the beacon (see notes 3 and 4).

8E360000002B80368171368E011E5C (1C6C000000FFBFF) n/a 43.559 N 1.482 E LEOLUT sends confirmed complete beacon message to MCC. MCC Action code: Sw1 + I3 -> Aw3. MCC sends SIT 122 alert based on the encoded position (see notes 3 and 4).

4E360000007FDFFFDCAB7683E0F00E ( 9C6C000000FFBFF) 38.995 N 76.851 W n/a LEOLUT computes Doppler location, and sends most recent valid message with bits 113 to 144 set to all “0" to MCC. MCC Action code: Sw3 + I2 -> Aw4. MCC sends SIT 126 based on the “A” and “B” Doppler positions (see notes 3 and 4).

8E360000007FDFFDD859D6FFFFFFFF (1C6C000000FFBFF) 43.559 N 1.482 E n/a LEOLUT sends invalid beacon message to MCC with bits 113 to 144 set to all “1". MCC Action code: Sw4 + I2 -> Aw7. MCC sends SIT 127 alert based on the match of the Doppler positions (see notes 3 and 4).

96E8000007815201C84BB4810007CB 2DD000003F81FE0 38.995 N 76.851 W 30.000 N 82.000 W LEOLUT sends the first message (only complete confirmed message) to MCC and computes Doppler position. MCC Action code: Sw0 + I4 -> Aw4. MCC sends SIT 126 alert based on the “A” and “B” Doppler positions and the encoded position (see notes 3 and 4).

96E8000007815201C84BB4810F0255 2DD000003F81FE0 38.995 N 76.851 W 30.000 N 82.003 W LEOLUT sends the updated, confirmed complete message to MCC and computes Doppler position. MCC Action code: Sw4 + I4 -> Aw6. MCC sends SIT 127 alert based on the match of the Doppler positions (see notes 3 and 4).

D6E10E1A4324920458B9D555555555 (ADC21C348649240) n/a n/a LEOLUT sends orbitography beacon message without correcting the long message. MCC suppresses message distribution because beacon type is orbitography.

n/a n/a n/a LEOLUT suppresses beacon alert because no valid message exists and no match available for invalid messages.

n/a n/a n/a LEOLUT suppresses beacon alert because message has 3 bit errors and is not confirmed.

n/a n/a n/a LEOLUT suppresses beacon messages due to the inverted frame synchronization.

96EB0000492E031219DC370D300F1D (2DD60000BF81FE0) n/a 36.76 N 3.08 E LEOLUT sends confirmed complete message to MCC. No Doppler location is calculated due to bad frequency. MCC Action code: Sw0 + I3 -> Aw3. MCC sends SIT 122 alert based on the encoded position (see notes 3, 4 and 6).

BFC0270F000002CA2F4015FFFFFFFF 7F804E1E0000059 38.995 N 76.851 W N/A LEOLUT performs invalid beacon message processing and provides Doppler location at Greenbelt. Ground segment equipment should not suppress the alert. MCC Action code: Sw0 + I2 -> Aw2. MCC sends SIT 125 alert based on the “A” and “B” Doppler positions; even though there are uncorrectable bit errors in the PDF-1 there are two or more matching points available for processing (see note 2). Due to uncorrectable bit errors in PDF-1, no processing is based on beacon message.

ABDCF423F0A1C2520276F69F400819 (57B9E847E0FFBFF) 43.559 N 1.482 E 33.881S 18.500E LEOLUT sends complete confirmed message to the MCC. The encoded position is invalid because it is outside the LEO satellite footprint (see note 5). MCC Action code: Sw0 + I2 -> Aw2. MCC sends SIT 125 alert based on the routing procedures for SSAS alerts.

I-10

Ref. Num Message to be Transmitted by LEOLUT (Default 15 Hex Id, bits 26-85) Doppler Position Encoded Position Comments

A37C5161502B4036D69136CA420129 (46F8A2C2A0FFBFF) 43.559 N 1.482 E 43.560N 1.467E LEOLUT sends complete confirmed message to the MCC. MCC Action code: Sw0 + I7 -> Aw7. MCC sends SIT 127 alert based on the routing procedures for SSAS alerts.

99CCBDE3102BC03083033630822F69 (33997BC620FFBFF) 43.559 N 1.482 E 43.548N 1.464E LEOLUT sends complete confirmed message to the MCC. MCC Action code: Sw0 + I7 -> Aw7. MCC sends SIT 127 alert based on the routing procedures for SSAS alerts.

A5DCA2C2A098D3095DCB7681E9B0B3 4BB9458540FFBFF 38.995 N 76.851 W 24.758S 152.412E LEOLUT sends complete confirmed message to the MCC. The encoded position is invalid because it is outside the LEO satellite footprint (see note 5). MCC Action code: Sw0 + I2 -> Aw2. MCC sends SIT 125 alert based on the routing procedure for SSAS alerts.

8F4C87A23026E99AB3EC36BAE6A5B7 (1E990F4460FFBFF) 38.995 N 76.851 W 38.996N 76.861W LEOLUT sends complete confirmed message to the MCC. MCC Action code: Sw0 + I7 -> Aw7. MCC sends SIT 127 alert based on the routing procedures for SSAS alerts.

911C6C81C026E99DAF0F3696258F9E 2238D90380FFBFF 38.995 N 76.851 W 38.84 N 76.84 W LEOLUT sends complete confirmed message to the MCC. MCC Action code: Sw0 + I7 -> Aw7. MCC sends SIT 127 alert based on the routing procedures for SSAS alerts. Notes:

See document C/S A.001, Table “Protocol Validation for 406 MHz Alert Messages”.

See document C/S A.001,Table “MCC Action Based on Message Field Content”.

See document C/S A.001, Figure “Unresolved Doppler Match Scenario (20 km circles)”.

See document C/S A.001, Table “Definition of the Input, Status and Action Words for 406 MHz Alerts”.

See document C/S A.001, Section “Encoded Position Footprint Validation”.

See document C/S A.001, Figure “South Central DDR Network Diagram”.

See document C/S A.001, Section “Alert Message Validation (Filtering Anomalous Data)”.

I-11

6Table I.3: Expected GEOLUT and MCC Processing for System Level Test Ref. Num Message to be Transmitted by GEOLUT (Default 15 Hex Id, bits 26-85) Encoded Position Comments

CC7469A69A69A68C0D498FFFFFFFFF (98E8D34D34D34D1) n/a GEOLUT corrects two bit errors and sends unconfirmed message with bits 113-144 all set to 1 to MCC. MCC Action code: Sw0 + Invalid Data -> Aw0. MCC suppresses message distribution because the country code is invalid and there is only one burst (see note 1).

96E9B93089C14CDE5215B7FFFFFFFF 2DD37261138299B 39.000 N 76.900 W GEOLUT sends unconfirmed complete message with bits 113 - 144 all set to 1 to MCC. MCC Action code: Sw0 + Invalid Data -> Aw0. MCC suppresses message distribution due to spare protocol code (see note 1)

96EA0000D8894D7CAD91F7FFFFFFFF or 96EA0000D8894D7CAD91F79F3C0010 (2DD40001BF81FE0) 98.133 N 77.500 W or 98.123 N 77.500 W GEOLUT sends unconfirmed message with bits 113 - 144 all set to 1 or confirmed complete message to MCC. MCC Action code: Sw0 + Invalid Data -> Aw0. MCC suppresses message distribution because the encoded position is invalid and there is no Doppler location (see note 1)

n/a n/a GEOLUT does not generate an alert due to uncorrectable PDF-1 bit errors

96E20000007FDFFC4AE037FFFFFFFF or 96E20000007FDFFC4AE03783E0F66C (2DC4000000FFBFF) n/a GEOLUT sends unconfirmed message with bits 113 - 144 all set to 1 or confirmed complete message to MCC. MCC Action code: Sw0 + I1 -> Aw1. MCC sends SIT 122 alert based on the encoded country code.

96E20000002B803713C8F7FFFFFFFF or 96E20000002B803713C8F78E010D07 (2DC4000000FFBFF) 43.500 N 1.500 E or 43.559 N 1.483 E GEOLUT sends unconfirmed message with bits 113 - 144 all set to 1 or confirmed complete message to MCC. MCC Action code: Sw1 + I3 -> Aw3. MCC sends SIT 122 alert based on the encoded position (see notes 3 and 4).

96E2000000272998994637FFFFFFFF or 96E200000027299899463701261BF1 (2DC4000000FFBFF) 39.000 N 76.750 W or 38.995 N 76.851 W GEOLUT sends unconfirmed message with bits 113 - 144 all set to 1 or confirmed complete message to MCC. MCC Action code: Sw3 + I3 -> Aw3. MCC sends SIT 123 alert based on the conflict of the encoded position with previous position (see notes 3 and 4).

96E200000026A99CDA28B7FFFFFFFF or 96E200000026A99CDA28B780230987 (2DC4000000FFBFF) 38.500 N 76.750 W or 38.500 N 76.800 W GEOLUT sends unconfirmed message with bits 113 - 144 all set to 1 or confirmed complete message to MCC. MCC Action code: Sw3 + I3 -> Aw3. MCC sends a SIT 123 (406 MHz position conflict – encoded location information only) because location is greater than 50 km from previous location information. (50 km is the threshold for LG only MCCs vs. 20 km for LGM MCCs) (see notes 3 and 4).

I-12

Ref. Num Message to be Transmitted by GEOLUT (Default 15 Hex Id, bits 26-85) Encoded Position Comments

8E340000002B803231B3F6FFFFFFFF or 8E340000002B803231B3F68C421815 or 8E340000002B803231B3F68E011E5C (1C68000000FFBFF) 43.500 N 1.500 E or 43.551 N 1.466 E or 43.559 N 1.482 E GEOLUT sends unconfirmed message with bits 113 - 144 all set to 1 or confirmed complete message for Standard Location Protocol beacon to MCC. MCC Action code: Sw0 + I3 -> Aw3. MCC sends SIT 122 alert based on the encoded positions (see notes 3 and 4).

8E3400000027299DBB3D36FFFFFFFF (1C68000000FFBFF) 39.000 N 76.750 W (invalid) GEOLUT sends unconfirmed message with bits 113 - 144 all set to 1 message to MCC. MCC Action code: Sw3 + I1 -> Aw0 or Sw3 + I3 -> Aw3 depending on whether the encoded position is within the GEO satellite footprint (see note 7). The MCC only sends the alert (Aw3) when the encoded position is within the GEO satellite footprint (see notes 3 and 4).

8E360000007FDFFDD859F6FFFFFFFF (1C6C000000FFBFF) n/a GEOLUT corrects beacon message and sends corrected valid message to MCC, however, bits 113 to 144 are set to all “1" because PDF-2 is not confirmed. MCC Action code: Sw0 + I1 -> Aw1. MCC sends SIT 122 alert based on the country code of the beacon (see notes 3 and 4).

8E360000002B8036817136FFFFFFFF or 8E360000002B80368171368E011E5C (1C6C000000FFBFF) 43.500 N 1.500 E or 43.559 N 1.482 E GEOLUT sends unconfirmed message with bits 113 - 144 all set to 1 or confirmed complete beacon message to MCC. MCC Action code: Sw1 + I3 -> Aw3. MCC sends SIT 122 alert based on the encoded position (see notes 3 and 4).

4E360000007FDFFFDCAB7683E0F00E (9C6C000000FFBFF) n/a GEOLUT sends unconfirmed or confirmed complete message with bits 113 to 144 set to all “0" to MCC. MCC Action code: Sw3 + I1 -> Aw0. MCC sends no alert (see notes 3 and 4).

n/a n/a GEOLUT does not generate an alert due to invalid beacon message.

96E8000007815201C84BB4810007CB or 96E8000007815201C84BB4FFFFFFFF (2DD000003F81FE0) 30.000 N 82.000 W GEOLUT sends unconfirmed message with bits 113 - 144 all set to 1 or confirmed complete message to the MCC. MCC Action code: Sw0 + I3 -> Aw3. MCC sends SIT 122 alert based on the encoded position (see notes 3 and 4).

96E8000007815201C84BB4810007CB or 96E8000007815201C84BB4810F0255 (2DD000003F81FE0) 30.000 N 82.000 W or 30.000 N 82.003 W GEOLUT sends, if confirmed, the updated complete message to the MCC. MCC Action code: Sw3 + I3 -> Aw0. MCC sends no alert (see notes 3 and 4).

I-13

Ref. Num Message to be Transmitted by GEOLUT (Default 15 Hex Id, bits 26-85) Encoded Position Comments

D6E10E1A4324920458B9D555555555 (ADC21C348649240) n/a GEOLUT sends orbitography beacon message without correcting the long message. MCC suppresses message distribution because beacon type is orbitography.

n/a n/a GEOLUT suppresses beacon alert because no valid message exists.

n/a n/a GEOLUT suppresses beacon alert because message has 3 bit errors and is not confirmed.

n/a n/a GEOLUT suppresses beacon messages due to the inverted frame synchronization.

96EB0000492E031219DC37FFFFFFFF or 96EB0000492E031219DC370D300F1D (2DD60000BF81FE0) 36.76667 N 3.086667 E or 36.76 N 3.08 E GEOLUT sends unconfirmed message with bits 113 - 144 all set to 1 or confirmed complete message to the MCC. MCC Action code: Sw0 + I3 -> Aw3. MCC sends SIT 122 based on the encoded position (see notes 3, 4 and 6).

n/a n/a GEOLUT does not generate an alert due to uncorrectable PDF-1 bit errors.

ABDCF423F0A1C2520276F6FFFFFFFF (57B9E847E0FFBFF) or ABDCF423F0A1C2520276F69F400819 33.881S 18.500E GEOLUT sends unconfirmed message with bits 113 - 144 all set to 1 or confirmed complete message to the MCC. MCC Action code: Sw0 + I3 -> Aw3. MCC sends SIT 122 alert based on the country code (SSAS procedure)

A37C5161502B4036D69136FFFFFFFF (46F8A2C2A0FFBFF) or A37C5161502B4036D69136CA420129 43.560N 1.467E GEOLUT sends unconfirmed message with bits 113 - 144 all set to 1 or confirmed complete message to the MCC. MCC Action code: Sw0 + I3 -> Aw3. MCC sends SIT 122 alert based on the country code (SSAS procedure)

99CCBDE3102BC030830336FFFFFFFF (33997BC620FFBFF) or 99CCBDE3102BC03083033630822F69 43.548N 1.464E GEOLUT sends unconfirmed message with bits 113 - 144 all set to 1 or confirmed complete message to the MCC. MCC Action code: Sw0 + I3 -> Aw3. MCC sends SIT 122 alert based on the country code (SSAS procedure)

A5DCA2C2A098D3095DCB7681E9B0B3 or A5DCA2C2A098D3095DCB76FFFFFFFF 24.758S 152.412E GEOLUT sends unconfirmed message with bits 113 - 144 all set to 1 or confirmed complete message to the MCC. MCC Action code: Sw0 + I3 -> Aw3. MCC sends SIT 122 alert based on the country code (SSAS procedure)

8F4C87A23026E99AB3EC36FFFFFFFF (1E990F4460FFBFF) or 8F4C87A23026E99AB3EC36BAE6A5B7 38.996N 76.861W GEOLUT sends unconfirmed message with bits 113 - 144 all set to 1 or confirmed complete message to the MCC. MCC Action code: Sw0 + I3 -> Aw3. MCC sends SIT 122 alert based on the country code (SSAS procedure)

I-14

Ref. Num Message to be Transmitted by GEOLUT (Default 15 Hex Id, bits 26-85) Encoded Position Comments

911C6C81C026E99DAF0F3696258F9E or 911C6C81C026E99DAF0F369FFFFFFF 38.84N 76.84W GEOLUT sends unconfirmed message with bits 113 - 144 all set to 1 or confirmed complete message to the MCC. MCC Action code: Sw0 + I3 -> Aw3. MCC sends SIT 122 alert based on the country code (SSAS procedure) Notes:

See document C/S A.001, Table “Protocol Validation for 406 MHz Alert Messages”.

See document C/S A.001,Table “MCC Action Based on Message Field Content”.

See document C/S A.001, Figure “Unresolved Doppler Match Scenario (20 km circles)”.

See document C/S A.001, Table “Definition of the Input, Status and Action Words for 406 MHz Alerts”.

See document C/S A.001, Section “Encoded Position Footprint Validation”.

See document C/S A.001, Figure “South Central DDR Network Diagram”.

See document C/S A.001, Section “Alert Message Validation (Filtering Anomalous Data)”.

I-15

7Table I.4: Specific MCC Processing for Messages Transmitted in System Level Test Reference Numbers 1 - 5 Receiving MCC Destination MCC(1) / SIT Number Test Reference Number

AEMCC Suppress Suppress SPMCC/125 SPMCC/125 SPMCC/125 ALMCC Suppress Suppress SPMCC/125 SPMCC/125 SPMCC/125 ARMCC Suppress Suppress USMCC/125 USMCC/125 USMCC/125 ASMCC Suppress Suppress AUMCC/125 AUMCC/125 AUMCC/125 AUMCC Suppress Suppress USMCC/125 USMCC/125 USMCC/125 BRMCC Suppress Suppress USMCC/125 USMCC/125 USMCC/125 CHMCC Suppress Suppress USMCC/125 USMCC/125 USMCC/125 CMC Suppress Suppress USMCC/125 USMCC/125 USMCC/125 CMCC Suppress Suppress USMCC/125 USMCC/125 USMCC/125 CNMCC Suppress Suppress JAMCC/125 JAMCC/125 JAMCC/125 FMCC Suppress Suppress USMCC/125 USMCC/125 USMCC/125 GRMCC Suppress Suppress FMCC/125 FMCC/125 FMCC/125 HKMCC Suppress Suppress JAMCC/125 JAMCC/125 JAMCC/125 IDMCC Suppress Suppress AUMCC/125 AUMCC/125 AUMCC/125 INMCC Suppress Suppress CMC/125 CMC/125 CMC/125 ITMCC Suppress Suppress FMCC/125 FMCC/125 FMCC/125 JAMCC Suppress Suppress USMCC/125 USMCC/125 USMCC/125 KOMCC Suppress Suppress JAMCC/125 JAMCC/125 JAMCC/125 NMCC Suppress Suppress FMCC/125 FMCC/125 FMCC/125 NIMCC Suppress Suppress SPMCC/125 SPMCC/125 SPMCC/125 PAMCC Suppress Suppress CMC/125 CMC/125 CMC/125 PEMCC Suppress Suppress USMCC/125 USMCC/125 USMCC/125 SAMCC Suppress Suppress SPMCC/125 SPMCC/125 SPMCC/125 SIMCC Suppress Suppress AUMCC/125 AUMCC/125 AUMCC/125 SPMCC Suppress Suppress USMCC/125 USMCC/125 USMCC/125 TAMCC Suppress Suppress JAMCC/125 JAMCC/125 JAMCC/125 THMCC Suppress Suppress AUMCC/125 AUMCC/125 AUMCC/125 TRMCC Suppress Suppress FMCC/125 FMCC/125 FMCC/125 UKMCC Suppress Suppress FMCC/125 FMCC/125 FMCC/125 USMCC Suppress Suppress NAT. PROC. NAT. PROC. NAT. PROC. VNMCC Suppress Suppress JAMCC/125 JAMCC/125 JAMCC/125 (1) Only the correct MCC destination is listed, an alert to the image position may also be generated.

I-16

Reference Numbers 6 - 10 (Table I.4 cont.) Receiving MCC Destination MCC(1) / SIT Number Test Reference Number

AEMCC SPMCC/123 SPMCC/124 Suppress SPMCC/127 Suppress ALMCC SPMCC/123 SPMCC/124 Suppress SPMCC/127 Suppress ARMCC USMCC/123 USMCC/124 Suppress USMCC/127 Suppress ASMCC AUMCC/123 AUMCC/124 Suppress AUMCC/127 Suppress AUMCC FMCC/123 USMCC/124 FMCC/124 Suppress FMCC/127 Suppress BRMCC USMCC/123 USMCC/124 Suppress USMCC/127 Suppress CHMCC USMCC/123 USMCC/124 Suppress USMCC/127 Suppress CMC FMCC/123 USMCC/124 FMCC/124 Suppress FMCC/127 Suppress CMCC USMCC/123 USMCC/124 Suppress USMCC/127 Suppress CNMCC JAMCC/123 JAMCC/124 Suppress JAMCC/127 Suppress FMCC NAT. PROC. USMCC/124 NAT. PROC. Suppress NAT. PROC. Suppress GRMCC FMCC/123 FMCC/124 Suppress FMCC/127 Suppress HKMCC JAMCC/123 JAMCC/124 Suppress JAMCC/127 Suppress IDMCC AUMCC/123 AUMCC/124 Suppress AUMCC/127 Suppress INMCC CMC/123 CMC/124 Suppress CMC/127 Suppress ITMCC FMCC/123 FMCC/124 Suppress FMCC/127 Suppress JAMCC FMCC/123 USMCC/124 FMCC/124 Suppress FMCC/127 Suppress KOMCC JAMCC/123 JAMCC/124 Suppress JAMCC/127 Suppress NMCC FMCC/123 FMCC/124 Suppress FMCC/127 Suppress NIMCC SPMCC/123 SPMCC/124 Suppress SPMCC/127 Suppress PAMCC CMC/123 CMC/124 Suppress CMC/127 Suppress PEMCC USMCC/123 USMCC/124 Suppress USMCC/127 Suppress SAMCC SPMCC/123 SPMCC/124 Suppress SPMCC/127 Suppress SIMCC AUMCC/123 AUMCC/124 Suppress AUMCC/127 Suppress SPMCC FMCC/123 USMCC/124 FMCC/124 Suppress JAMCC/127 Suppress TAMCC JAMCC/123 JAMCC/124 Suppress JAMCC/127 Suppress THMCC AUMCC/123 AUMCC/124 Suppress AUMCC/127 Suppress TRMCC FMCC/123 FMCC/124 Suppress FMCC/127 Suppress UKMCC FMCC/123 FMCC/124 Suppress FMCC/127 Suppress USMCC FMCC/123 FMCC/124 NAT. PROC. Suppress FMCC/127 Suppress VNMCC JAMCC/123 JAMCC/124 Suppress JAMCC/127 Suppress (1) Only the correct MCC destination is listed, an alert to the image position may also be generated.

I-17

Reference Numbers 11 - 15 (Table I.4 cont.) Receiving MCC Destination MCC(1) / SIT Number Test Reference Number

AEMCC SPMCC/122 SPMCC/122 SPMCC/126 SPMCC/127 SPMCC/126 ALMCC SPMCC/122 SPMCC/122 SPMCC/126 SPMCC/127 SPMCC/126 ARMCC USMCC/122 USMCC/125 USMCC/126 USMCC/127 USMCC/126 ASMCC AUMCC/122 AUMCC/122 AUMCC/126 AUMCC/127 AUMCC/126 AUMCC FMCC/122 FMCC/122 USMCC/126 USMCC/127 FMCC/127 USMCC/126 BRMCC USMCC/122 USMCC/122 USMCC/126 USMCC/127 USMCC/126 CHMCC USMCC/122 USMCC/122 USMCC/126 USMCC/127 USMCC/126 CMC FMCC/122 FMCC/122 USMCC/126 USMCC/127 FMCC/127 USMCC/126 CMCC USMCC/122 USMCC/122 USMCC/126 USMCC/127 USMCC/126 CNMCC JAMCC /122 JAMCC /122 JAMCC/126 JAMCC/127 JAMCC/126 FMCC NAT.PROC. NAT.PROC. USMCC/126 USMCC/127 NAT.PROC. USMCC/126 GRMCC FMCC/122 FMCC/122 FMCC/126 FMCC/127 FMCC/126 HKMCC JAMCC/122 JAMCC/122 JAMCC/126 JAMCC/127 JAMCC/126 IDMCC AUMCC/122 AUMCC/122 AUMCC/126 AUMCC/127 AUMCC/126 INMCC CMC/122 CMC/122 CMC/126 CMC/127 CMC/126 ITMCC FMCC/122 FMCC/122 FMCC/126 FMCC/127 FMCC/126 JAMCC FMCC/122 FMCC/122 USMCC/126 USMCC/127 FMCC/127 USMCC/126 KOMCC JAMCC/122 JAMCC/122 JAMCC/126 JAMCC/127 JAMCC/126 NMCC FMCC/122 FMCC/122 FMCC/126 FMCC/127 FMCC/126 NIMCC SPMCC/122 SPMCC/122 SPMCC/126 SPMCC/127 SPMCC/126 PAMCC CMC/122 CMC/122 CMC/126 CMC/127 CMC/126 PEMCC USMCC/122 USMCC/122 USMCC/126 USMCC/127 USMCC/126 SAMCC SPMCC/122 SPMCC/122 SPMCC/126 SPMCC/127 SPMCC/126 SIMCC AUMCC/122 AUMCC/122 AUMCC/126 AUMCC/127 AUMCC/126 SPMCC FMCC/122 FMCC/122 USMCC/126 FMCC/127 USMCC/127 USMCC/126 TAMCC JAMCC/122 JAMCC/122 JAMCC/126 JAMCC/127 JAMCC/126 THMCC AUMCC/122 AUMCC/122 AUMCC/126 AUMCC/127 AUMCC/126 TRMCC FMCC/122 FMCC/122 FMCC/126 FMCC/127 FMCC/126 UKMCC FMCC/122 FMCC/122 FMCC/126 FMCC/127 FMCC/126 USMCC FMCC/122 FMCC/122 NAT. PROC. FMCC/127 NAT. PROC. NAT. PROC. VNMCC JAMCC/122 JAMCC/122 JAMCC/126 JAMCC/127 JAMCC/126 (1) Only the correct MCC destination is listed, an alert to the image position may also be generated.

I-18

Reference Numbers 16 - 22 (Table I.4 cont.) Receiving MCC Destination MCC(1) / SIT Number Test Reference Number

18 - 20

AEMCC SPMCC/127 Suppress N/A SPMCC/122 SPMCC/125 ALMCC SPMCC/127 Suppress N/A NAT.PROC SPMCC/125 ARMCC USMCC/127 Suppress N/A USMCC/122 USMCC/125 ASMCC AUMCC/127 Suppress N/A AUMCC/122 AUMCC/125 AUMCC USMCC/127 Suppress N/A SPMCC/122 USMCC/125 BRMCC USMCC/127 Suppress N/A USMCC/122 USMCC/125 CHMCC USMCC/127 Suppress N/A USMCC/122 USMCC/125 CMC USMCC/127 Suppress N/A SPMCC/122 USMCC/125 CMCC USMCC/127 Suppress N/A USMCC/122 USMCC/125 CNMCC JAMCC/127 Suppress N/A JAMCC/122 JAMCC/125 FMCC USMCC/127 Suppress N/A SPMCC/122 USMCC/125 GRMCC FMCC/127 Suppress N/A FMCC/122 FMCC/125 HKMCC JAMCC/127 Suppress N/A JAMCC/122 JAMCC/125 IDMCC AUMCC/127 Suppress N/A AUMCC/122 AUMCC/125 INMCC CMC/127 Suppress N/A CMC/122 CMC/125 ITMCC FMCC/127 Suppress N/A FMCC/122 FMCC/125 JAMCC USMCC/127 Suppress N/A SPMCC/122 USMCC/125 KOMCC JAMCC/127 Suppress N/A JAMCC/122 JAMCC/125 NMCC FMCC/127 Suppress N/A FMCC/122 FMCC/125 NIMCC SPMCC/127 Suppress N/A SPMCC/122 SPMCC/125 PAMCC CMC/127 Suppress N/A CMC/122 CMC/125 PEMCC USMCC/127 Suppress N/A USMCC/122 USMCC/125 SAMCC SPMCC/127 Suppress N/A SPMCC/122 SPMCC/125 SIMCC AUMCC/127 Suppress N/A AUMCC/122 AUMCC/125 SPMCC USMCC/127 Suppress N/A ALMCC/122 USMCC/125 TAMCC JAMCC/127 Suppress N/A JAMCC/122 JAMCC/125 THMCC AUMCC/127 Suppress N/A AUMCC/122 AUMCC/125 TRMCC FMCC/127 Suppress N/A FMCC/122 FMCC/125 UKMCC FMCC/127 Suppress N/A FMCC/122 FMCC/125 USMCC NAT. PROC Suppress N/A SPMCC/122 NAT. PROC. VNMCC JAMCC/127 Suppress N/A JAMCC/122 JAMCC/125 (1) Only the correct MCC destination is listed, an alert to the image position may also be generated.

I-19

Reference Numbers 23 - 28 (Table I.4 cont.) Receiving MCC Destination MCC/SIT Number Test Reference Number

AEMCC SPMCC/125 SPMCC/127 SPMCC/127 SPMCC/125 SPMCC/127 SPMCC/127 ALMCC SPMCC/125 SPMCC/127 SPMCC/127 Natl Proc SPMCC/127 SPMCC/127 ARMCC Natl Proc USMCC/127 USMCC/127 USMCC/125 USMCC/127 USMCC/127 ASMCC AUMCC/125 AUMCC/127 AUMCC/127 AUMCC/125 AUMCC/127 AUMCC/127 AUMCC USMCC/125 THMCC/127 JAMCC/127 SPMCC/125 FMCC/127 CMC/127 BRMCC USMCC/125 USMCC/127 USMCC/127 USMCC/125 USMCC/127 USMCC/127 CHMCC USMCC/125 USMCC/127 USMCC/127 USMCC/125 USMCC/127 USMCC/127 CMC USMCC/125 AUMCC/127 JAMCC/127 SPMCC/125 FMCC/127 Natl Proc CMCC USMCC/125 USMCC/127 USMCC/127 USMCC/125 USMCC/127 USMCC/127 CNMCC JAMCC/125 JAMCC/127 Natl Proc JAMCC/125 JAMCC/127 JAMCC/127 FMCC USMCC/125 AUMCC/127 JAMCC/127 SPMCC/125 Natl Proc CMC/127 GRMCC FMCC/125 FMCC/127 FMCC/127 FMCC/125 FMCC 127 FMCC/127 HKMCC JAMCC/125 JAMCC/127 JAMCC/127 JAMCC/125 JAMCC/127 JAMCC/127 IDMCC AUMCC/125 AUMCC/127 AUMCC/127 AUMCC/125 AUMCC/127 AUMCC/127 INMCC CMC/125 CMC/127 CMC/127 CMC/125 CMC/127 CMC/127 ITMCC FMCC/125 FMCC/127 FMCC/127 FMCC/125 FMCC 127 FMCC/127 JAMCC USMCC/125 AUMCC/127 CNMCC/127 SPMCC/125 FMCC/127 CMC/127 KOMCC JAMCC/125 JAMCC/127 JAMCC/127 JAMCC/125 JAMCC/127 JAMCC/127 NMCC FMCC/125 FMCC/127 FMCC/127 FMCC/125 FMCC 127 FMCC/127 NIMCC SPMCC/125 SPMCC/127 SPMCC/127 SPMCC/125 SPMCC/127 SPMCC/127 PAMCC CMC/125 CMC/127 CMC/127 CMC/125 CMC/127 CMC/127 PEMCC USMCC/125 USMCC/127 USMCC/127 USMCC/125 USMCC/127 USMCC/127 SAMCC SPMCC/125 SPMCC/127 SPMCC/127 SPMCC/125 SPMCC/127 SPMCC/127 SIMCC AUMCC/125 AUMCC/127 AUMCC/127 AUMCC/125 AUMCC/127 AUMCC/127 SPMCC USMCC/125 AUMCC/127 JAMCC/127 ALMCC/125 FMCC/127 CMC/127 TAMCC JAMCC/125 JAMCC/127 JAMCC/127 JAMCC/125 JAMCC/127 JAMCC/127 THMCC AUMCC/125 National Proc AUMCC/127 AUMCC/125 AUMCC/127 AUMCC/127 TRMCC FMCC/125 FMCC/127 FMCC/127 FMCC/125 FMCC 127 FMCC/127 UKMCC FMCC/125 FMCC/127 FMCC/127 FMCC/125 FMCC/127 FMCC/127 USMCC ARMCC/125 AUMCC/127 JAMCC/127 SPMCC/125 FMCC/127 CMC/127 VMMCC JAMCC/125 JAMCC/127 JAMCC/127 JAMCC/125 JAMCC/127 JAMCC/127

  • END OF ANNEX I –

J-1

ANNEX J QMS AUTOMATED REPORTING SYSTEM J.1 General Architecture of the QMS Automated Reporting System (QARS) The QMS Automated Reporting System (QARS) provides an automated means of reporting daily QMS status on the Cospas-Sarsat website as determined by the nodal MCCs. The QARS is not an operational component of the Ground Segment, and MCCs exchange SIT messages to provide operationally relevant information based on QMS results. Figure J.1 shows the architecture for the QARS. Nodal MCCs daily assess the LEOLUT, GEOLUT, MEOLUT and MCC QMS status and daily provide the QARS with the results of the QMS assessment, either automatically using xml files per format of section J.2, or manually using a dedicated web-based interface. The web-based interface enables an xml file to be uploaded to the QARS. The QARS shall provide the overall status for MEOLUT Location Probability and MEOLUT Location Accuracy, based on the relevant component statuses. XML files are transmitted in only one direction, i.e., the nodal MCC uploads files on QARS server, but the QARS does not upload any data on the nodal MCC server, following the model of FTP- over-VPN connections implemented by MCCs, as defined in Annexes E and F of document C/S A.002. In response to a file uploaded on the QARS server, QARS provides the file update status (i.e., success or failure for its processing of the file, without verification of data consistency) to a designated email address for the nodal MCC. Figure J.1: General Architecture of the QMS Automated Reporting System (QARS)

Image 1 from page 173

J-2

J.2 XML Format for QMS and Space Segment Status Report Table J.1 describes selected XML message fields and schema components. If a MEOLUT has multiple associated QMS reference beacons, QMS statistics shall be reported in the XML file for the MEOLUT as follows: • one set of results for each reference beacon, and • one set for all beacons collectively. If a MEOLUT has only a single associated QMS reference beacon, only one set of QMS statistics shall be reported in the XML file because there is no difference between the “per- beacon” and the “all beacons collectively” statistics. Table J.1 – XML Format Selected Message Field and Schema Component Descriptions Message Field / Component Name Comments QMS_Report_List_SequenceNumber Sequence number for the current file, which contains a set of QMS reports generated by the nodal MCC. Incremented by one for each subsequent file. Note: QARS does not perform sequence number checking. QMS_Report_List_LastSequenceNumber Sequence number for the previous set of reports (i.e., file generated by the nodal MCC). QMS_Report_SequenceNumber Sequence number for the current report) generated by the nodal MCC. Incremented by one for each QMS report provided in the “[LEO/GEO/MEO] QMS_Report_List”. The sequence numbers for the “Report_List” (file) and “Report” are used to provide a reference to the nodal MCC when the QARS detects a problem in a QMS report. QMS_Report_LastSequenceNumber Sequence number for the previous report section generated by the nodal MCC. QMS_Report_AncilData Element name with ancillary data defining a group of fields to be referenced (i.e., applied) subsequently in the XML schema. Date_Report Date/time that the report (file) was generated by the nodal MCC. NodalMCC_ID Nodal MCC ID, per document C/S A.002 Message Field 2. LUT_ID LUT (Source) ID, per document C/S A.002 Message Field 11. Date_Window_End Date/time of the end of the reporting period. Date_Window_Begin Date/time of the start of the 24-hour period associated with the end of the reporting period (i.e., "Date_Window_End" – 24 hours). Does not reflect the start of a 48 or 72 hour reporting period. REFBE XML item to provide the designated reference beacon for which information is reported. To provide information for “all” designated reference beacons associated with a MEOLUT, multiple references to REFBE shall be provided within the XML schema item REFBE_List (see the sample file in section J.3). If a MEOLUT is associated with only one designated reference beacon, associated statistics shall only be provided once for the MEOLUT / beacon combination (see the sample file in section J.3). REFBE_ID 15-digit Hexadecimal designated reference beacon ID. Must match a beacon ID defined in the QARS database. REFBE_Name Name for the designated reference beacon ID, assigned by the nodal MCC.

J-3

“_Status Status for a QMS metric, where, for MEO QMS, “” corresponds to the metric name provided in section 2.5.5; e.g., “ProbDetr” for Detection Probability. “_Value Ratio for a QMS metric, where, for MEO QMS, “” corresponds to the metric name provided in section 2.5.5; e.g., “ProbDetr” for Detection Probability. In the XML schema, the subsequent element names provide the associated fields used to generate the ratio, where the numerator is listed first, as a “nonNegativeInteger" and the denominator is listed second, as either a “positiveInteger” or a “nonNegativeInteger". E.g., for Detection Probability, the numerator is “ProbDetr_SumTRP” and the denominator is “ProbDetr_TRP”. The ratio is set to “1.0” if the denominator is zero.

J-4

Please, contact the Secretariat to obtain an electronic current version of the XML file format below.

<xsd:schema xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns="urn:packet-schema" elementFormDefault="qualified" targetNamespace="urn:packet-schema">

<xsd:simpleType name="QMS_Status_Type">

<xsd:restriction base="xsd:string">

<xsd:enumeration value="Green_Plus"/>

<xsd:enumeration value="Green"/>

<xsd:enumeration value="Yellow"/>

<xsd:enumeration value="Red"/>

<xsd:enumeration value="n/i"/>

<xsd:enumeration value="n/a"/>

</xsd:restriction>

</xsd:simpleType>

<xsd:complexType name="REFBE_Type">

xsd:all

<xsd:element name="REFBE_ID" type="xsd:string"> </xsd:element>

<xsd:element name="REFBE_Name" type="xsd:string"> </xsd:element>

</xsd:all>

</xsd:complexType>

<xsd:element name="QMS_Report_AncilData">

xsd:complexType

J-5

xsd:all

<xsd:element name="Date_Report" type="xsd:dateTime"/>

<xsd:element name="NodalMCC_ID" type="xsd:positiveInteger"/>

<xsd:element name="LUT_ID" type="xsd:positiveInteger"/>

<xsd:element name="Date_Window_Begin" type="xsd:dateTime"/>

<xsd:element name="Date_Window_End" type="xsd:dateTime"/>

<xsd:element name="REFBE_List">

xsd:complexType

xsd:sequence

<xsd:element name="REFBE" type="REFBE_Type" minOccurs="1" maxOccurs="unbounded"/>

</xsd:sequence>

</xsd:complexType>

</xsd:element>

</xsd:all>

</xsd:complexType>

</xsd:element>

<xsd:element name="MEO_QMS_Report_List">

xsd:complexType

xsd:sequence

<xsd:element name="MEO_QMS_Report" minOccurs="1" maxOccurs="unbounded">

xsd:complexType

xsd:all

<xsd:element ref="QMS_Report_AncilData" minOccurs="1" maxOccurs="1"/>

<xsd:element name="ProbDetr" minOccurs="0" maxOccurs="1">

J-6

xsd:complexType

xsd:sequence

<xsd:element name="ProbDetr_Status" type="QMS_Status_Type"/>

<xsd:element name="ProbDetr_Value" type="xsd:decimal"/>

<xsd:element name="ProbDetr_SumTRP" type="xsd:nonNegativeInteger"/>

<xsd:element name="ProbDetr_TRP" type="xsd:positiveInteger"/>

</xsd:sequence>

</xsd:complexType>

</xsd:element>

<xsd:element name="SB_PLoc" minOccurs="0" maxOccurs="1">

xsd:complexType

xsd:sequence

<xsd:element name="SB_PLoc_Status" type="QMS_Status_Type"/>

<xsd:element name="SB_PLoc_Value" type="xsd:decimal"/>

<xsd:element name="SB_PLoc_SumTRP" type="xsd:nonNegativeInteger"/>

<xsd:element name="SB_PLoc_TRP" type="xsd:positiveInteger"/>

</xsd:sequence>

</xsd:complexType>

</xsd:element>

<xsd:element name="MB_PLoc" minOccurs="0" maxOccurs="1">

xsd:complexType

xsd:sequence

<xsd:element name="MB_PLoc_Status" type="QMS_Status_Type"/>

J-7

<xsd:element name="MB_PLoc_Value" type="xsd:decimal"/>

<xsd:element name="MB_PLoc_SumTRP" type="xsd:nonNegativeInteger"/>

<xsd:element name="MB_PLoc_TRP" type="xsd:positiveInteger"/>

</xsd:sequence>

</xsd:complexType>

</xsd:element>

<xsd:element name="SB_LocAcc" minOccurs="0" maxOccurs="1">

xsd:complexType

xsd:sequence

<xsd:element name="SB_LocAcc_5_Status" type="QMS_Status_Type"/>

<xsd:element name="SB_LocAcc_20_Status" type="QMS_Status_Type"/>

<xsd:element name="SB_LocAcc_5_Value" type="xsd:decimal"/>

<xsd:element name="SB_LocAcc_20_Value" type="xsd:decimal"/>

<xsd:element name="SB_LocAcc_5_NbSB" type="xsd:nonNegativeInteger"/>

<xsd:element name="SB_LocAcc_20_NbSB" type="xsd:nonNegativeInteger"/>

<xsd:element name="SB_LocAcc_NbSB" type="xsd:nonNegativeInteger"/>

</xsd:sequence>

</xsd:complexType>

</xsd:element>

J-8

<xsd:element name="MB_LocAcc" minOccurs="0" maxOccurs="1">

xsd:complexType

xsd:sequence

<xsd:element name="MB_LocAcc_5_Status" type="QMS_Status_Type"/>

<xsd:element name="MB_LocAcc_20_Status" type="QMS_Status_Type"/>

<xsd:element name="MB_LocAcc_5_Value" type="xsd:decimal"/>

<xsd:element name="MB_LocAcc_20_Value" type="xsd:decimal"/>

<xsd:element name="MB_LocAcc_5_NbMB" type="xsd:nonNegativeInteger"/>

<xsd:element name="MB_LocAcc_20_NbMB" type="xsd:nonNegativeInteger"/>

<xsd:element name="MB_LocAcc_NbMB" type="xsd:nonNegativeInteger"/>

</xsd:sequence>

</xsd:complexType>

</xsd:element>

<xsd:element name="LocAr" minOccurs="0" maxOccurs="1">

xsd:complexType

xsd:sequence

<xsd:element name="LocAr_Status" type="QMS_Status_Type"/>

<xsd:element name="LocAr_Value" type="xsd:decimal"/>

<xsd:element name="LocAr_NbDOA3Ant" type="xsd:nonNegativeInteger"/>

J-9

<xsd:element name="LocAr_NbDOA" type="xsd:nonNegativeInteger"/>

</xsd:sequence>

</xsd:complexType>

</xsd:element>

<xsd:element name="TimeR" minOccurs="0" maxOccurs="1">

xsd:complexType

xsd:sequence

<xsd:element name="TimeR_Status" type="QMS_Status_Type"/>

<xsd:element name="TimeR_Value" type="xsd:decimal"/>

<xsd:element name="TimeR_Nb105Min" type="xsd:nonNegativeInteger"/>

<xsd:element name="TimeR_Nb" type="xsd:nonNegativeInteger"/>

</xsd:sequence>

</xsd:complexType>

</xsd:element>

<xsd:element name="EHE" minOccurs="0" maxOccurs="1">

xsd:complexType

xsd:sequence

<xsd:element name="EHE_Status" type="QMS_Status_Type"/>

<xsd:element name="EHE_Value" type="xsd:decimal"/>

<xsd:element name="EHE_NbDOAOk" type="xsd:nonNegativeInteger"/>

<xsd:element name="EHE_NbDOA" type="xsd:nonNegativeInteger"/>

</xsd:sequence>

J-10

</xsd:complexType>

</xsd:element>

</xsd:all>

<xsd:attribute name="QMS_Report_SequenceNumber" type="xsd:positiveInteger" use="required"/>

<xsd:attribute name="QMS_Report_LastSequenceNumber" type="xsd:positiveInteger" use="required"/>

</xsd:complexType>

</xsd:element>

</xsd:sequence>

<xsd:attribute name="QMS_Report_List_SequenceNumber" type="xsd:positiveInteger" use="required"/>

<xsd:attribute name="QMS_Report_List_LastSequenceNumber" type="xsd:positiveInteger" use="required"/>

</xsd:complexType>

</xsd:element>

<xsd:element name="LEO_QMS_Report_List">

xsd:complexType

xsd:sequence

<xsd:element name="LEO_QMS_Report" minOccurs="1" maxOccurs="unbounded">

xsd:complexType

xsd:all

<xsd:element ref="QMS_Report_AncilData" minOccurs="1" maxOccurs="1"/>

<xsd:element name="Satellite_ID" type="xsd:nonNegativeInteger"/>

<xsd:element name="LEO_Accuracy" minOccurs="0" maxOccurs="1">

xsd:complexType

xsd:sequence

<xsd:element name="Accuracy_Status" type="QMS_Status_Type"/>

<xsd:element name="Accuracy_Value" type="xsd:decimal"/>

J-11

<xsd:element name="Accuracy_NLocX" type="xsd:nonNegativeInteger"/>

<xsd:element name="Accuracy_NLocTotal" type="xsd:nonNegativeInteger"/>

</xsd:sequence>

</xsd:complexType>

</xsd:element>

<xsd:element name="LEO_Availability" minOccurs="0" maxOccurs="1">

xsd:complexType

xsd:sequence

<xsd:element name="Availability_Status" type="QMS_Status_Type"/>

<xsd:element name="Availability_Value" type="xsd:decimal"/>

<xsd:element name="Availability_NAvailable" type="xsd:nonNegativeInteger"/>

<xsd:element name="Availability_NExpected" type="xsd:nonNegativeInteger"/>

</xsd:sequence>

</xsd:complexType>

</xsd:element>

</xsd:all>

<xsd:attribute name="QMS_Report_SequenceNumber" type="xsd:positiveInteger" use="required"/>

<xsd:attribute name="QMS_Report_LastSequenceNumber" type="xsd:positiveInteger" use="required"/>

</xsd:complexType>

</xsd:element>

</xsd:sequence>

J-12

<xsd:attribute name="QMS_Report_List_SequenceNumber" type="xsd:positiveInteger" use="required"/>

<xsd:attribute name="QMS_Report_List_LastSequenceNumber" type="xsd:positiveInteger" use="required"/>

</xsd:complexType>

</xsd:element>

<xsd:element name="GEO_QMS_Report_List">

xsd:complexType

xsd:sequence

<xsd:element name="GEO_QMS_Report" minOccurs="1" maxOccurs="unbounded">

xsd:complexType

xsd:all

<xsd:element ref="QMS_Report_AncilData" minOccurs="1" maxOccurs="1"/>

<xsd:element name="Satellite_ID" type="xsd:nonNegativeInteger"/>

<xsd:element name="GEO_Availability" minOccurs="0" maxOccurs="1">

xsd:complexType

xsd:sequence

<xsd:element name="Availability_Status" type="QMS_Status_Type"/>

<xsd:element name="Availability_Value" type="xsd:decimal"/>

<xsd:element name="Availability_NAvailable" type="xsd:nonNegativeInteger"/>

<xsd:element name="Availability_NExpected" type="xsd:positiveInteger"/>

</xsd:sequence>

</xsd:complexType>

</xsd:element>

</xsd:all>

J-13

<xsd:attribute name="QMS_Report_SequenceNumber" type="xsd:positiveInteger" use="required"/>

<xsd:attribute name="QMS_Report_LastSequenceNumber" type="xsd:positiveInteger" use="required"/>

</xsd:complexType>

</xsd:element>

</xsd:sequence>

<xsd:attribute name="QMS_Report_List_SequenceNumber" type="xsd:positiveInteger" use="required"/>

<xsd:attribute name="QMS_Report_List_LastSequenceNumber" type="xsd:positiveInteger" use="required"/>

</xsd:complexType>

</xsd:element>

<xsd:element name="Spacecraft_Report_AncilData">

xsd:complexType

xsd:all

<xsd:element name="Date_Report" type="xsd:dateTime"/>

<xsd:element name="MCC_ID" type="xsd:positiveInteger"/>

</xsd:all>

</xsd:complexType>

</xsd:element>

<xsd:simpleType name="Spacecraft_Status_Type">

<xsd:restriction base="xsd:string">

<xsd:enumeration value="Available_Testing"/>

<xsd:enumeration value="Initial_Operational_Capability"/>

<xsd:enumeration value="Full_Operational_Capability"/>

<xsd:enumeration value="Not_Operational"/>

<xsd:enumeration value="Limited_Operations"/>

J-14

<xsd:enumeration value="Turned_Off"/>

<xsd:enumeration value="Under_Test"/>

</xsd:restriction>

</xsd:simpleType>

<xsd:simpleType name="Spacecraft_Configuration_Type">

<xsd:restriction base="xsd:string">

<xsd:enumeration value="AGC"/>

<xsd:enumeration value="WFA"/>

<xsd:enumeration value="NFA"/>

<xsd:enumeration value="WFF"/>

<xsd:enumeration value="NFF"/>

<xsd:enumeration value="Turned_Off"/>

<xsd:enumeration value="Under_Test"/>

</xsd:restriction>

</xsd:simpleType>

<xsd:element name="SpacecraftLEO_Status_Report">

xsd:complexType

xsd:all

<xsd:element name="Satellite_ID" type="xsd:nonNegativeInteger"/>

<xsd:element name="SARR" type="Spacecraft_Status_Type"/>

<xsd:element name="SARP_Global" type="Spacecraft_Status_Type"/>

<xsd:element name="SARP_Local" type="Spacecraft_Status_Type"/>

<xsd:element name="Spacecraft_Comment" type="xsd:string"/>

<xsd:element name="Date_Begin" type="xsd:dateTime"/>

J-15

</xsd:all>

</xsd:complexType>

</xsd:element>

<xsd:element name="SpacecraftGEO_Status_Report">

xsd:complexType

xsd:all

<xsd:element name="Satellite_ID" type="xsd:nonNegativeInteger"/>

<xsd:element name="Spacecraft_Status" type="Spacecraft_Status_Type"/>

<xsd:element name="Spacecraft_Conf" type="Spacecraft_Configuration_Type"/>

<xsd:element name="Spacecraft_Comment" type="xsd:string"/>

<xsd:element name="Date_Begin" type="xsd:dateTime"/>

</xsd:all>

</xsd:complexType>

</xsd:element>

<xsd:element name="SpacecraftMEO_Status_Report">

xsd:complexType

xsd:all

<xsd:element name="Satellite_ID" type="xsd:nonNegativeInteger"/>

<xsd:element name="Spacecraft_Status" type="Spacecraft_Status_Type"/>

<xsd:element name="Spacecraft_Conf" type="Spacecraft_Configuration_Type"/>

<xsd:element name="Spacecraft_Comment" type="xsd:string"/>

<xsd:element name="Date_Begin" type="xsd:dateTime"/>

</xsd:all>

</xsd:complexType>

J-16

</xsd:element>

<xsd:element name="Spacecraft_Status_Report_List">

xsd:complexType

xsd:sequence

<xsd:element name="Spacecraft_Status_Report" minOccurs="1" maxOccurs="unbounded">

xsd:complexType

xsd:sequence

<xsd:element ref="Spacecraft_Report_AncilData" minOccurs="0" maxOccurs="1"/>

<xsd:element ref="SpacecraftLEO_Status_Report" minOccurs="0" maxOccurs="unbounded"/>

<xsd:element ref="SpacecraftGEO_Status_Report" minOccurs="0" maxOccurs="unbounded"/>

<xsd:element ref="SpacecraftMEO_Status_Report" minOccurs="0" maxOccurs="unbounded"/>

</xsd:sequence>

<xsd:attribute name="Spacecraft_Status_Report_SequenceNumber" type="xsd:positiveInteger" use="required"/>

<xsd:attribute name="Spacecraft_Status_Report_LastSequenceNumber" type="xsd:positiveInteger" use="required"/>

</xsd:complexType>

</xsd:element>

</xsd:sequence>

<xsd:attribute name="Spacecraft_Status_Report_List_SequenceNumber" type="xsd:positiveInteger" use="required"/>

<xsd:attribute name="Spacecraft_Status_Report_List_LastSequenceNumber" type="xsd:positiveInteger" use="required"/>

</xsd:complexType>

</xsd:element>

<xsd:element name="MCC_Report_AncilData">

J-17

xsd:complexType

xsd:all

<xsd:element name="Date_Report" type="xsd:dateTime"/>

<xsd:element name="MCC_ID" type="xsd:positiveInteger"/>

<xsd:element name="MCC_Name" type="xsd:string"/>

<xsd:element name="MCC_Country" type="xsd:string"/>

<xsd:element name="NodalMCC_ID" type="xsd:positiveInteger"/>

</xsd:all>

</xsd:complexType>

</xsd:element>

<xsd:simpleType name="MCC_Status_Type">

<xsd:restriction base="xsd:string">

<xsd:enumeration value="Full_Operational_Capability"/>

<xsd:enumeration value="Initial_Operational_Capability"/>

<xsd:enumeration value="Backed_Up"/>

<xsd:enumeration value="Not_Operational"/>

</xsd:restriction>

</xsd:simpleType>

<xsd:element name="MCC_Status_Report_List">

xsd:complexType

xsd:sequence

<xsd:element name="MCC_Status_Report" minOccurs="1" maxOccurs="unbounded">

xsd:complexType

xsd:all

J-18

<xsd:element ref="MCC_Report_AncilData" minOccurs="1" maxOccurs="1"/>

<xsd:element name="MCC_Status" type="MCC_Status_Type"/>

<xsd:element name="MCC_Comment" type="xsd:string"/>

<xsd:element name="Date_Begin" type="xsd:dateTime"/>

</xsd:all>

<xsd:attribute name="MCC_Status_Report_SequenceNumber" type="xsd:positiveInteger" use="required"/>

<xsd:attribute name="MCC_Status_Report_LastSequenceNumber" type="xsd:positiveInteger" use="required"/>

</xsd:complexType>

</xsd:element>

</xsd:sequence>

<xsd:attribute name="MCC_Status_Report_List_SequenceNumber" type="xsd:positiveInteger" use="required"/>

<xsd:attribute name="MCC_Status_Report_List_LastSequenceNumber" type="xsd:positiveInteger" use="required"/>

</xsd:complexType>

</xsd:element>

<xsd:element name="REFBE_Report_AncilData">

xsd:complexType

xsd:all

<xsd:element name="Date_Report" type="xsd:dateTime"/>

<xsd:element name="REFBE" type="REFBE_Type" minOccurs="1" maxOccurs="1"/>

<xsd:element name="NodalMCC_ID" type="xsd:positiveInteger"/>

</xsd:all>

</xsd:complexType>

</xsd:element>

J-19

<xsd:simpleType name="REFBE_Status_Type">

<xsd:restriction base="xsd:string">

<xsd:enumeration value="Available"/>

<xsd:enumeration value="Not_Available"/>

</xsd:restriction>

</xsd:simpleType>

<xsd:element name="REFBE_Status_Report_List">

xsd:complexType

xsd:sequence

<xsd:element name="REFBE_Status_Report" minOccurs="1" maxOccurs="unbounded">

xsd:complexType

xsd:all

<xsd:element ref="REFBE_Report_AncilData" minOccurs="1" maxOccurs="1"/>

<xsd:element name="REFBE_Status" type="REFBE_Status_Type" minOccurs="0"/>

<xsd:element name="REFBE_Comment" type="xsd:string"/>

<xsd:element name="Date_Begin" type="xsd:dateTime"/>

</xsd:all>

<xsd:attribute name="REFBE_Status_Report_SequenceNumber" type="xsd:positiveInteger" use="required"/>

<xsd:attribute name="REFBE_Status_Report_LastSequenceNumber" type="xsd:positiveInteger" use="required"/>

</xsd:complexType>

</xsd:element>

</xsd:sequence>

J-20

<xsd:attribute name="REFBE_Status_Report_List_SequenceNumber" type="xsd:positiveInteger" use="required"/>

<xsd:attribute name="REFBE_Status_Report_List_LastSequenceNumber" type="xsd:positiveInteger" use="required"/>

</xsd:complexType>

</xsd:element>

</xsd:schema>

J-21

J.3 – Sample File of QMS Status Report The following sample XML file was provided by the FMCC for MEOSAR QMS for the reporting period ending 26 May 2021 00:00 UTC. 001 002 <MEO_QMS_Report_List xmlns="urn:packet-schema" QMS_Report_List_SequenceNumber="64" QMS_Report_List_LastSequenceNumber="63"> 003 <MEO_QMS_Report QMS_Report_SequenceNumber="190" QMS_Report_LastSequenceNumber="189"> 004 <QMS_Report_AncilData> 005 <Date_Report>2021-05-26T00:30:01.374Z</Date_Report> 006 <NodalMCC_ID>2270</NodalMCC_ID> 007 <LUT_ID>2275</LUT_ID> 008 <Date_Window_Begin>2021-05-25T00:00:00.000Z</Date_Window_Begin> 009 <Date_Window_End>2021-05-26T00:00:00.000Z</Date_Window_End> 010 <REFBE_List> 011 012 <REFBE_ID>9C62BE29630F1D0</REFBE_ID> 013 <REFBE_Name>QMS MEO TOULOUSE</REFBE_Name> 014 015 016 <REFBE_ID>9C02BE29630F0A0</REFBE_ID> 017 <REFBE_Name>QMS MEO MASPALOMAS</REFBE_Name> 018 019 </REFBE_List> 020 </QMS_Report_AncilData> 021 022 <ProbDetr_Status>Green</ProbDetr_Status> 023 <ProbDetr_Value>1.0</ProbDetr_Value> 024 <ProbDetr_SumTRP>192</ProbDetr_SumTRP> 025 <ProbDetr_TRP>192</ProbDetr_TRP>

J-22

026 027 <SB_PLoc> 028 <SB_PLoc_Status>Green</SB_PLoc_Status> 029 <SB_PLoc_Value>0.9791666865348816</SB_PLoc_Value> 030 <SB_PLoc_SumTRP>94</SB_PLoc_SumTRP> 031 <SB_PLoc_TRP>96</SB_PLoc_TRP> 032 </SB_PLoc> 033 <MB_PLoc> 034 <MB_PLoc_Status>Yellow</MB_PLoc_Status> 035 <MB_PLoc_Value>0.9791666865348816</MB_PLoc_Value> 036 <MB_PLoc_SumTRP>94</MB_PLoc_SumTRP> 037 <MB_PLoc_TRP>96</MB_PLoc_TRP> 038 </MB_PLoc> 039 <SB_LocAcc> 040 <SB_LocAcc_5_Status>Green</SB_LocAcc_5_Status> 041 <SB_LocAcc_20_Status>Green_Plus</SB_LocAcc_20_Status> 042 <SB_LocAcc_5_Value>0.8510638475418091</SB_LocAcc_5_Value> 043 <SB_LocAcc_20_Value>1.0</SB_LocAcc_20_Value> 044 <SB_LocAcc_5_NbSB>80</SB_LocAcc_5_NbSB> 045 <SB_LocAcc_20_NbSB>94</SB_LocAcc_20_NbSB> 046 <SB_LocAcc_NbSB>94</SB_LocAcc_NbSB> 047 </SB_LocAcc> 048 <MB_LocAcc> 049 <MB_LocAcc_5_Status>Green_Plus</MB_LocAcc_5_Status> 050 <MB_LocAcc_20_Status>Green_Plus</MB_LocAcc_20_Status> 051 <MB_LocAcc_5_Value>0.974117636680603</MB_LocAcc_5_Value> 052 <MB_LocAcc_20_Value>1.0</MB_LocAcc_20_Value> 053 <MB_LocAcc_5_NbMB>414</MB_LocAcc_5_NbMB>

J-23

054 <MB_LocAcc_20_NbMB>425</MB_LocAcc_20_NbMB> 055 <MB_LocAcc_NbMB>425</MB_LocAcc_NbMB> 056 </MB_LocAcc> 057 058 <LocAr_Status>Green</LocAr_Status> 059 <LocAr_Value>1.0</LocAr_Value> 060 <LocAr_NbDOA3Ant>519</LocAr_NbDOA3Ant> 061 <LocAr_NbDOA>519</LocAr_NbDOA> 062 063 064 <TimeR_Status>Green</TimeR_Status> 065 <TimeR_Value>1.0</TimeR_Value> 066 <TimeR_Nb105Min>546</TimeR_Nb105Min> 067 <TimeR_Nb>546</TimeR_Nb> 068 069 070 <EHE_Status>Yellow</EHE_Status> 071 <EHE_Value>0.9826589822769165</EHE_Value> 072 <EHE_NbDOAOk>510</EHE_NbDOAOk> 073 <EHE_NbDOA>519</EHE_NbDOA> 074 075 </MEO_QMS_Report> 076 <MEO_QMS_Report QMS_Report_SequenceNumber="191" QMS_Report_LastSequenceNumber="190"> 077 <QMS_Report_AncilData> 078 <Date_Report>2021-05-26T00:30:01.374Z</Date_Report> 079 <NodalMCC_ID>2270</NodalMCC_ID> 080 <LUT_ID>2275</LUT_ID> 081 <Date_Window_Begin>2021-05-25T00:00:00.000Z</Date_Window_Begin>

J-24

082 <Date_Window_End>2021-05-26T00:00:00.000Z</Date_Window_End> 083 <REFBE_List> 084 085 <REFBE_ID>9C62BE29630F1D0</REFBE_ID> 086 <REFBE_Name>QMS MEO TOULOUSE</REFBE_Name> 087 088 </REFBE_List> 089 </QMS_Report_AncilData> 090 091 <ProbDetr_Status>Green</ProbDetr_Status> 092 <ProbDetr_Value>1.0</ProbDetr_Value> 093 <ProbDetr_SumTRP>96</ProbDetr_SumTRP> 094 <ProbDetr_TRP>96</ProbDetr_TRP> 095 096 <SB_PLoc> 097 <SB_PLoc_Status>Green</SB_PLoc_Status> 098 <SB_PLoc_Value>0.9791666865348816</SB_PLoc_Value> 099 <SB_PLoc_SumTRP>47</SB_PLoc_SumTRP> 100 <SB_PLoc_TRP>48</SB_PLoc_TRP> 101 </SB_PLoc> 102 <MB_PLoc> 103 <MB_PLoc_Status>Yellow</MB_PLoc_Status> 104 <MB_PLoc_Value>0.9791666865348816</MB_PLoc_Value> 105 <MB_PLoc_SumTRP>47</MB_PLoc_SumTRP> 106 <MB_PLoc_TRP>48</MB_PLoc_TRP> 107 </MB_PLoc> 108 <SB_LocAcc> 109 <SB_LocAcc_5_Status>Green</SB_LocAcc_5_Status>

J-25

110 <SB_LocAcc_20_Status>Green_Plus</SB_LocAcc_20_Status> 111 <SB_LocAcc_5_Value>0.8723404407501221</SB_LocAcc_5_Value> 112 <SB_LocAcc_20_Value>1.0</SB_LocAcc_20_Value> 113 <SB_LocAcc_5_NbSB>41</SB_LocAcc_5_NbSB> 114 <SB_LocAcc_20_NbSB>47</SB_LocAcc_20_NbSB> 115 <SB_LocAcc_NbSB>47</SB_LocAcc_NbSB> 116 </SB_LocAcc> 117 <MB_LocAcc> 118 <MB_LocAcc_5_Status>Green_Plus</MB_LocAcc_5_Status> 119 <MB_LocAcc_20_Status>Green_Plus</MB_LocAcc_20_Status> 120 <MB_LocAcc_5_Value>0.9770641922950745</MB_LocAcc_5_Value> 121 <MB_LocAcc_20_Value>1.0</MB_LocAcc_20_Value> 122 <MB_LocAcc_5_NbMB>213</MB_LocAcc_5_NbMB> 123 <MB_LocAcc_20_NbMB>218</MB_LocAcc_20_NbMB> 124 <MB_LocAcc_NbMB>218</MB_LocAcc_NbMB> 125 </MB_LocAcc> 126 </MEO_QMS_Report> 127 <MEO_QMS_Report QMS_Report_SequenceNumber="192" QMS_Report_LastSequenceNumber="191"> 128 <QMS_Report_AncilData> 129 <Date_Report>2021-05-26T00:30:01.374Z</Date_Report> 130 <NodalMCC_ID>2270</NodalMCC_ID> 131 <LUT_ID>2275</LUT_ID> 132 <Date_Window_Begin>2021-05-25T00:00:00.000Z</Date_Window_Begin> 133 <Date_Window_End>2021-05-26T00:00:00.000Z</Date_Window_End> 134 <REFBE_List> 135 136 <REFBE_ID>9C02BE29630F0A0</REFBE_ID> 137 <REFBE_Name>QMS MEO MASPALOMAS</REFBE_Name>

J-26

138 139 </REFBE_List> 140 </QMS_Report_AncilData> 141 142 <ProbDetr_Status>Green</ProbDetr_Status> 143 <ProbDetr_Value>1.0</ProbDetr_Value> 144 <ProbDetr_SumTRP>96</ProbDetr_SumTRP> 145 <ProbDetr_TRP>96</ProbDetr_TRP> 146 147 <SB_PLoc> 148 <SB_PLoc_Status>Green</SB_PLoc_Status> 149 <SB_PLoc_Value>0.9791666865348816</SB_PLoc_Value> 150 <SB_PLoc_SumTRP>47</SB_PLoc_SumTRP> 151 <SB_PLoc_TRP>48</SB_PLoc_TRP> 152 </SB_PLoc> 153 <MB_PLoc> 154 <MB_PLoc_Status>Yellow</MB_PLoc_Status> 155 <MB_PLoc_Value>0.9791666865348816</MB_PLoc_Value> 156 <MB_PLoc_SumTRP>47</MB_PLoc_SumTRP> 157 <MB_PLoc_TRP>48</MB_PLoc_TRP> 158 </MB_PLoc> 159 <SB_LocAcc> 160 <SB_LocAcc_5_Status>Green</SB_LocAcc_5_Status> 161 <SB_LocAcc_20_Status>Green_Plus</SB_LocAcc_20_Status> 162 <SB_LocAcc_5_Value>0.8297872543334961</SB_LocAcc_5_Value> 163 <SB_LocAcc_20_Value>1.0</SB_LocAcc_20_Value> 164 <SB_LocAcc_5_NbSB>39</SB_LocAcc_5_NbSB> 165 <SB_LocAcc_20_NbSB>47</SB_LocAcc_20_NbSB>

J-27

166 <SB_LocAcc_NbSB>47</SB_LocAcc_NbSB> 167 </SB_LocAcc> 168 <MB_LocAcc> 169 <MB_LocAcc_5_Status>Green_Plus</MB_LocAcc_5_Status> 170 <MB_LocAcc_20_Status>Green_Plus</MB_LocAcc_20_Status> 171 <MB_LocAcc_5_Value>0.9710144996643066</MB_LocAcc_5_Value> 172 <MB_LocAcc_20_Value>1.0</MB_LocAcc_20_Value> 173 <MB_LocAcc_5_NbMB>201</MB_LocAcc_5_NbMB> 174 <MB_LocAcc_20_NbMB>207</MB_LocAcc_20_NbMB> 175 <MB_LocAcc_NbMB>207</MB_LocAcc_NbMB> 176 </MB_LocAcc> 177 </MEO_QMS_Report> 178 <MEO_QMS_Report QMS_Report_SequenceNumber="193" QMS_Report_LastSequenceNumber="192"> 179 <QMS_Report_AncilData> 180 <Date_Report>2021-05-26T00:30:01.374Z</Date_Report> 181 <NodalMCC_ID>2270</NodalMCC_ID> 182 <LUT_ID>6601</LUT_ID> 183 <Date_Window_Begin>2021-05-25T00:00:00.000Z</Date_Window_Begin> 184 <Date_Window_End>2021-05-26T00:00:00.000Z</Date_Window_End> 185 <REFBE_List> 186 187 <REFBE_ID>9C62BE29630F1D0</REFBE_ID> 188 <REFBE_Name>QMS MEO TOULOUSE</REFBE_Name> 189 190 </REFBE_List> 191 </QMS_Report_AncilData> 192 193 <ProbDetr_Status>Red</ProbDetr_Status>

J-28

194 <ProbDetr_Value>0.78125</ProbDetr_Value> 195 <ProbDetr_SumTRP>75</ProbDetr_SumTRP> 196 <ProbDetr_TRP>96</ProbDetr_TRP> 197 198 <SB_PLoc> 199 <SB_PLoc_Status>Yellow</SB_PLoc_Status> 200 <SB_PLoc_Value>0.7708333134651184</SB_PLoc_Value> 201 <SB_PLoc_SumTRP>37</SB_PLoc_SumTRP> 202 <SB_PLoc_TRP>48</SB_PLoc_TRP> 203 </SB_PLoc> 204 <MB_PLoc> 205 <MB_PLoc_Status>Yellow</MB_PLoc_Status> 206 <MB_PLoc_Value>0.75</MB_PLoc_Value> 207 <MB_PLoc_SumTRP>36</MB_PLoc_SumTRP> 208 <MB_PLoc_TRP>48</MB_PLoc_TRP> 209 </MB_PLoc> 210 <SB_LocAcc> 211 <SB_LocAcc_5_Status>Red</SB_LocAcc_5_Status> 212 <SB_LocAcc_20_Status>Green_Plus</SB_LocAcc_20_Status> 213 <SB_LocAcc_5_Value>0.4647887349128723</SB_LocAcc_5_Value> 214 <SB_LocAcc_20_Value>0.9154929518699646</SB_LocAcc_20_Value> 215 <SB_LocAcc_5_NbSB>33</SB_LocAcc_5_NbSB> 216 <SB_LocAcc_20_NbSB>65</SB_LocAcc_20_NbSB> 217 <SB_LocAcc_NbSB>71</SB_LocAcc_NbSB> 218 </SB_LocAcc> 219 <MB_LocAcc> 220 <MB_LocAcc_5_Status>Yellow</MB_LocAcc_5_Status> 221 <MB_LocAcc_20_Status>Green_Plus</MB_LocAcc_20_Status>

J-29

222 <MB_LocAcc_5_Value>0.7720588445663452</MB_LocAcc_5_Value> 223 <MB_LocAcc_20_Value>0.9852941036224365</MB_LocAcc_20_Value> 224 <MB_LocAcc_5_NbMB>105</MB_LocAcc_5_NbMB> 225 <MB_LocAcc_20_NbMB>134</MB_LocAcc_20_NbMB> 226 <MB_LocAcc_NbMB>136</MB_LocAcc_NbMB> 227 </MB_LocAcc> 228 229 <LocAr_Status>Green</LocAr_Status> 230 <LocAr_Value>1.0</LocAr_Value> 231 <LocAr_NbDOA3Ant>207</LocAr_NbDOA3Ant> 232 <LocAr_NbDOA>207</LocAr_NbDOA> 233 234 235 <TimeR_Status>Green</TimeR_Status> 236 <TimeR_Value>1.0</TimeR_Value> 237 <TimeR_Nb105Min>207</TimeR_Nb105Min> 238 <TimeR_Nb>207</TimeR_Nb> 239 240 241 <EHE_Status>Yellow</EHE_Status> 242 <EHE_Value>0.7874395847320557</EHE_Value> 243 <EHE_NbDOAOk>163</EHE_NbDOAOk> 244 <EHE_NbDOA>207</EHE_NbDOA> 245 246 </MEO_QMS_Report> 247 </MEO_QMS_Report_List>

  • END OF ANNEX J –
  • END OF DOCUMENT –

Cospas-Sarsat Secretariat 1250 René-Lévesque Blvd. West, Suite 4215, Montréal, Québec H3B 4W8 Canada Telephone: + 1 514 500 7999 Fax: + 1 514 500 7996 Email: mail@cospas-sarsat.int Website www.cospas-sarsat.int