gr-mcp-docs/reference/cospas-sarsat/a-series/a003.md

---
title: "A003: C/S A.003 Issue 3 - Rev.8"
description: "Official Cospas-Sarsat A-series document A003"
sidebar:
  badge:
    text: "A"
    variant: "note"
# Extended Cospas-Sarsat metadata
documentId: "A003"
series: "A"
seriesName: "Operational"
documentType: "operational"
isLatest: true
issue: 3
revision: 8
documentDate: "October 2025"
originalTitle: "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](https://www.cospas-sarsat.int/en/documents-pro/system-documents)

---

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

![Image 1 from page 1](/images/cospas-sarsat/A-series/A003/A003_page_1_img_1.png)


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

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

2.
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](/images/cospas-sarsat/A-series/A003/A003_page_43_img_1.png)

3-1

3.
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

4.
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

5.
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

6.
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](/images/cospas-sarsat/A-series/A003/A003_page_92_img_1.png)

![Image 2 from page 92](/images/cospas-sarsat/A-series/A003/A003_page_92_img_2.png)

![Image 3 from page 92](/images/cospas-sarsat/A-series/A003/A003_page_92_img_3.png)

![Image 4 from page 92](/images/cospas-sarsat/A-series/A003/A003_page_92_img_4.png)

![Image 5 from page 92](/images/cospas-sarsat/A-series/A003/A003_page_92_img_5.png)

![Image 6 from page 92](/images/cospas-sarsat/A-series/A003/A003_page_92_img_6.png)

![Image 7 from page 92](/images/cospas-sarsat/A-series/A003/A003_page_92_img_7.png)

![Image 8 from page 92](/images/cospas-sarsat/A-series/A003/A003_page_92_img_8.png)

![Image 9 from page 92](/images/cospas-sarsat/A-series/A003/A003_page_92_img_9.png)

![Image 10 from page 92](/images/cospas-sarsat/A-series/A003/A003_page_92_img_10.png)

![Image 11 from page 92](/images/cospas-sarsat/A-series/A003/A003_page_92_img_11.png)

![Image 12 from page 92](/images/cospas-sarsat/A-series/A003/A003_page_92_img_12.png)

![Image 13 from page 92](/images/cospas-sarsat/A-series/A003/A003_page_92_img_13.png)

![Image 14 from page 92](/images/cospas-sarsat/A-series/A003/A003_page_92_img_14.png)

![Image 15 from page 92](/images/cospas-sarsat/A-series/A003/A003_page_92_img_15.png)

![Image 16 from page 92](/images/cospas-sarsat/A-series/A003/A003_page_92_img_16.png)

![Image 17 from page 92](/images/cospas-sarsat/A-series/A003/A003_page_92_img_17.png)

![Image 18 from page 92](/images/cospas-sarsat/A-series/A003/A003_page_92_img_18.png)

![Image 19 from page 92](/images/cospas-sarsat/A-series/A003/A003_page_92_img_19.png)

![Image 20 from page 92](/images/cospas-sarsat/A-series/A003/A003_page_92_img_20.png)

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](/images/cospas-sarsat/A-series/A003/A003_page_97_img_1.png)

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

2.
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](/images/cospas-sarsat/A-series/A003/A003_page_105_img_1.png)

![Image 2 from page 105](/images/cospas-sarsat/A-series/A003/A003_page_105_img_2.png)

![Image 3 from page 105](/images/cospas-sarsat/A-series/A003/A003_page_105_img_3.png)

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](/images/cospas-sarsat/A-series/A003/A003_page_108_img_1.png)

![Image 2 from page 108](/images/cospas-sarsat/A-series/A003/A003_page_108_img_2.png)

![Image 3 from page 108](/images/cospas-sarsat/A-series/A003/A003_page_108_img_3.png)

![Image 4 from page 108](/images/cospas-sarsat/A-series/A003/A003_page_108_img_4.png)

![Image 5 from page 108](/images/cospas-sarsat/A-series/A003/A003_page_108_img_5.png)

![Image 6 from page 108](/images/cospas-sarsat/A-series/A003/A003_page_108_img_6.png)

![Image 7 from page 108](/images/cospas-sarsat/A-series/A003/A003_page_108_img_7.png)

![Image 8 from page 108](/images/cospas-sarsat/A-series/A003/A003_page_108_img_8.png)

![Image 9 from page 108](/images/cospas-sarsat/A-series/A003/A003_page_108_img_9.png)

![Image 10 from page 108](/images/cospas-sarsat/A-series/A003/A003_page_108_img_10.png)

![Image 11 from page 108](/images/cospas-sarsat/A-series/A003/A003_page_108_img_11.png)

![Image 12 from page 108](/images/cospas-sarsat/A-series/A003/A003_page_108_img_12.png)

![Image 13 from page 108](/images/cospas-sarsat/A-series/A003/A003_page_108_img_13.png)

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](/images/cospas-sarsat/A-series/A003/A003_page_111_img_1.png)

A-12

2.
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](/images/cospas-sarsat/A-series/A003/A003_page_112_img_1.png)

![Image 2 from page 112](/images/cospas-sarsat/A-series/A003/A003_page_112_img_2.png)

![Image 3 from page 112](/images/cospas-sarsat/A-series/A003/A003_page_112_img_3.png)

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.
- END OF ANNEX A -
mail@cospas-sarsat.int

![Image 1 from page 113](/images/cospas-sarsat/A-series/A003/A003_page_113_img_1.png)

![Image 2 from page 113](/images/cospas-sarsat/A-series/A003/A003_page_113_img_2.png)

![Image 3 from page 113](/images/cospas-sarsat/A-series/A003/A003_page_113_img_3.png)

![Image 4 from page 113](/images/cospas-sarsat/A-series/A003/A003_page_113_img_4.png)

![Image 5 from page 113](/images/cospas-sarsat/A-series/A003/A003_page_113_img_5.png)

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](/images/cospas-sarsat/A-series/A003/A003_page_115_img_1.png)

B-3

2.
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.
2.
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

1.
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
1.  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
2.  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

2.
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
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 1DAY PERIOD ENDING AT 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

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

3.
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
1.  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]
2.  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

4.
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
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

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)
1.  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

5.
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
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.  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)
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),
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
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

D-13

6.
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

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

8.
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

9.
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

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](/images/cospas-sarsat/A-series/A003/A003_page_153_img_1.png)

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](/images/cospas-sarsat/A-series/A003/A003_page_156_img_1.png)

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](/images/cospas-sarsat/A-series/A003/A003_page_173_img_1.png)

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.

<?xml version="1.0" encoding="UTF-8" standalone="no"?>

<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 <?xml version="1.0" encoding="UTF-8" standalone="yes"?>
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                 <REFBE>
012                     <REFBE\_ID>9C62BE29630F1D0</REFBE\_ID>
013                     <REFBE\_Name>QMS MEO TOULOUSE</REFBE\_Name>
014                 </REFBE>
015                 <REFBE>
016                     <REFBE\_ID>9C02BE29630F0A0</REFBE\_ID>
017                     <REFBE\_Name>QMS MEO MASPALOMAS</REFBE\_Name>
018                 </REFBE>
019             </REFBE\_List>
020         </QMS\_Report\_AncilData>
021         <ProbDetr>
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         </ProbDetr>
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         <LocAr>
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         </LocAr>
063         <TimeR>
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         </TimeR>
069         <EHE>
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         </EHE>
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                 <REFBE>
085                     <REFBE\_ID>9C62BE29630F1D0</REFBE\_ID>
086                     <REFBE\_Name>QMS MEO TOULOUSE</REFBE\_Name>
087                 </REFBE>
088             </REFBE\_List>
089         </QMS\_Report\_AncilData>
090         <ProbDetr>
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         </ProbDetr>
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                 <REFBE>
136                     <REFBE\_ID>9C02BE29630F0A0</REFBE\_ID>
137                     <REFBE\_Name>QMS MEO MASPALOMAS</REFBE\_Name>

J-26

138                 </REFBE>
139             </REFBE\_List>
140         </QMS\_Report\_AncilData>
141         <ProbDetr>
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         </ProbDetr>
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                 <REFBE>
187                     <REFBE\_ID>9C62BE29630F1D0</REFBE\_ID>
188                     <REFBE\_Name>QMS MEO TOULOUSE</REFBE\_Name>
189                 </REFBE>
190             </REFBE\_List>
191         </QMS\_Report\_AncilData>
192         <ProbDetr>
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         </ProbDetr>
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         <LocAr>
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         </LocAr>
234         <TimeR>
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         </TimeR>
240         <EHE>
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         </EHE>
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